ITアーキテクトは物事をどう見るべきか？：ITアーキテクト的発想のススメ（1）（1/2 ページ）

ITエンジニアのキャリアパスとして「ITアーキテクト」という職種が注目を集めている。プログラマやSEとは異なるスキルセットが必要とされる職種だが、最も大事なスキルは「複眼的な思考」だ。これは一体、どういった能力のことを指すのか？

[東山 靖弘（NTTデータ），＠IT]

ITアーキテクトに必要なのは「複眼的な思考」

　近年、ビジネスや社会インフラにおける情報システムの重要度は高まる一方だが、その複雑度も年々増している。次から次へと新しいシステムが開発され、システムの寿命もプロジェクトの期間も一昔前と比べると格段に短くなった。システムの機能は多様化し、かつてメインフレームで定型処理を行っていただけの時代とは異なり、ビジネス上のあらゆる要件が盛り込まれるようになった。

　その結果、情報システムの開発プロジェクトは複雑な問題を短期間で、しかも多種多様な関係者・専門家を巻き込んで処理しなくてはならなくなった。

　こうした中、「ITアーキテクト」の存在がクローズアップされている。ITアーキテクトとは一言でいうと、ビジネスとITの双方を理解し、ビジネス戦略に沿ったシステムのアーキテクチャを設計する存在のことだ。前述のように、開発プロジェクトでは多種多様な立場のステークホルダーが存在する。そして、それらをまとめ上げてプロジェクトをスムーズに進めていくためには、ITアーキテクトの「複眼的な思考」が求められるのである。

　では、「複眼的な思考」とは一体どのようなものなのだろうか？ 本連載ではこれをテーマに、ITアーキテクトにとって必要な物の見方・考え方を紹介していく。

開発現場での認識のズレ

　まずは、システム開発者であれば誰もが一度は経験している「開発現場での認識のズレ」の問題から話を始めよう。ITアーキテクトは、どのような物の見方・考え方でこの問題に対処すればいいのだろうか？

トラブル状況に対する認識のズレ

　例えば、オンライン受注システムでトラブルが発生した場面を想像してみてほしい。

• サポート部門

「インターネットからのアクセスを多数いただいているが、申し込みができないという問い合わせも多数寄せられている。どうなっているのか？」

• 販売店部門

「販売店からも申し込みができないという問い合わせが来ている」

• アプリ担当

「システムログを確認したところ、受発注システムの受注処理で異常が発生しているようです」

• インフラ担当

「在庫管理システムのデータベースでデッドロックが発生しています。原因はまだ分かっていません」

• 販売店部門

「そもそもインターネットでの申し込みが殺到すると、どうして販売店からの窓口が影響を受けるのか？ 分かるように説明してもらいたい！」

　トラブルの関係者がそれぞれの見地からトラブル事象を認識し、そのほかの関係者とコミュニケーションを取ろうとする。しかし、それぞれ見方が異なっているので、情報共有が思うように進まない。当然、解決策はなかなか見付からない。関係者たちのいら立ちは募り、復旧の見通しはいよいよ暗くなる……。

　このような場合、関係者間の認識のズレを解消し、最適な解決策を導き出すにはどうしたらいいのだろうか？ これが今回のテーマである。

　もう1つ例を挙げてみよう。下の図をご覧いただきたい（図1）。この図は、一体何を表現しているように見えるだろうか？

図1　システム構成図の一例

　この問いに対する答えとしては、例えば以下のようなものが考えられるだろう。

答え1

「これは業務アプリケーションのプロセスとデータストアだ」

図2　業務アプリケーションのプロセスとデータストア

　複数の業務プロセスから同一のデータを更新する処理が発生し、データベース上で競合している。ITアーキテクトはこのようなケースをあらかじめ想定し、業務仕様との整合性に配慮しながらこの競合問題の回避手段を考えなければならない。競合発生時のタイムアウトの実装や処理の再実行が解決策の1つとなる……。

答え2

「これは3階層で構成される一般的なWebシステム構成（Webサーバ、APサーバ、DBサーバ）だ」

図3　3階層のWebシステム構成

　Web層、AP（アプリケーション）層がそれぞれスケールアウト構成、DB（データベース）層がスケールアップ構成で実装されている。一般的によく採用されるアーキテクチャだ。異なるAPサーバからのトランザクション間でデータベースの同一レコードに対して競合が発生する可能性があるため、アーキテクトはその解決手段となる排他制御を考慮した設計を行わなくてはならない……。

答え3

「これは企業内システムの連携を表現している」

図4　企業内システム連携

　複数のチャネルシステム（例： eコマース向けシステム、販売店向けシステム）、受発注システム、在庫管理システムが連携している。異なるチャネルから流れてくる受注処理（トランザクション）間で、商品在庫をめぐる競合が発生する可能性がある。これに対しては、チャネルごとに在庫データを持たせるという解決策がある……。

　以上、図1からすぐに連想できそうなイメージを3つほど挙げてみた。皆さんは、幾つのイメージが頭に浮かんだだろうか？ 答え1〜3のような複数のイメージが浮かんだだろうか？

　この簡単なテストは、実はITアーキテクトに必要な「複眼的な思考」を試す格好の例なのである。トラブルを前にしたITアーキテクトは、本例で示した答え1〜3のように複数の見方で状況を認識し、関係者と最適な解決策を模索しなければならない。たった1つの見方に縛られていては、解決策を見いだせないばかりか、関係者間の調整もままならない。本連載のテーマである「ITアーキテクトの『複眼的な思考』」とは、このように1つの事象をさまざまな視点から見て、考えることなのである。

情報システムは立場により見え方が異なる

　面白いことに、情報システムはこのように複数の見方が同時にできてしまう性質を持っている。例えば、オンライン受注システムで以下のようなトラブルが発生したとする。

　インターネットからの受注処理が急増した結果、受発注システムから在庫管理システムへの処理要求が増加した。受発注システムでは、受注業務における（在庫管理システムへの）在庫割り当て要求の応答に遅延が発生している。在庫管理システムのデータベースではデッドロックが発生している。

　こうした状況を前にして、技術者は得てして「受注業務における（在庫管理システムへの）在庫割り当て要求の応答に遅延が発生している」や「在庫管理システムのデータベースではデッドロックが発生している」といったシステム内部の動作に着目してトラブルの事象を把握する。これは、先ほどの例でいえば「答え1」や「答え2」のようなミクロな視点から見たとらえ方だ。

　一方、業務部門の担当者は「インターネットからの受注処理が急増した結果、受発注システムから在庫管理システムへの処理要求が増加」といったマクロな視点で事象をとらえがちだ。これは、「答え3」のような物の見方だ。

　情報システムでは、こうした立場による見え方の違いが顕著であり、コミュニケーションを阻害する要因になりやすい。ITアーキテクトは、情報システムに対するさまざまな認識の違いの本質をしっかり理解し、あらゆる人々の立場に立った複眼的な思考で状況を把握しなければならないのである。