「センパイ,これは一目瞭然ですね」――。

 2001年ごろ,後輩と一緒にあるミドルウエア製品の評価をしていたときのことです。私のとったある行動に対して,後輩からこんな風に言われました。このことが,私の“メタ脳”を刺激するよい機会になりました。

 後輩は「フィージビリティ・スタディ(FS)」と呼ぶ作業をしていました。具体的には,ミドルウエア製品の可用性を評価するために,障害発生時の復旧・運用方式を検討していました。ここで後輩は,どこから手をつけてよいのか分からなかったようです。

 問題は,このミドルウエア製品を利用するには,いくつかのソフトウエア・コンポーネントを分散配置する必要があったことです。冗長化を図るわけですが,必然的にその構造は複雑になります。

 そこで私はこうアドバイスしました。「まずは検証項目を洗い出さなきゃ。図で書くと分かりやすいよ」。

 これが,後輩にとっては“目からウロコ”だったようです。そのあとの行動は極めて単純です。コンポーネントを分散配置したときの図(コンポーネント配置図)をホワイトボードに書き,障害が発生しそうな部分に「障害発生マーク」を一つずつ付けました。そのうえで,マークの付いた部分について,復旧・運用方法を考えていきました。

図解することで「MECE」を実現

 皆さんは「ミッシー(MECE:Mutually Exclusive Collectively Exhaustive)」という言葉をご存知でしょうか。簡単に言えば“モレなくダブリなく”という意味ですが,ITアーキテクトなら常に意識すべきキーワードだと思います。なぜなら,ITアーキテクトには死角は許されないからです。

 とはいえ,ITアーキテクトも所詮は人間です。一人でやっていたり,何も道具を使わなければミスするのも当然です。そこでMECEを実現するために有効な道具が“図解”であり,図解することで他の人と意識を共有しながら議論し,死角のないものを作れるわけです。

 つい最近,私の尊敬する技術者の方と話をする機会があり,そのとき彼も図解を駆使していることを知りました。それも私と同じく可用性や障害復旧方法の検証に,UMLを使っていたのです。「障害発生マーク」も付けており,何だかうれしくなりました(ただしコンポーネント配置図ではなくシーケンス図でしたが…)。

 ITアーキテクトなら技術検証をする機会も多いでしょう。技術検証で一番重要なのは「検証項目の洗い出し」だと私は考えます。検証する目的が明確になれば,おのずからしかりというわけです。

 そして「検証項目の洗い出し」には図解がとても有効です。私のオススメはやはり,UMLでしょうか。広く知られているUMLなら意思の疎通も図りやすいからです。皆さんは“図解”していますか?

=今回のキーセンテンス=

「構造や概念を図示し,議論をしよう。そのときはできるだけ標準的な表記法を利用しよう」


(高安 厚思=オープンストリーム)