8. 業界で標準になっている表記技法を利用する
8番目のヒントは、アーキテクチャの情報を提示するときは、業界で標準になっている表記技法を利用するというものです。
Unified Modeling Language（UML）には、ソフトウェアシステムを表現するためのグラフィカルな表記技法が含まれます。ユースケース、クラス、シーケンス、コンポーネント、デプロイメントといったUML図は、ホワイトボードへのスケッチから洗練されたツールにまで広く使用されています。一部の表記法はオブジェクト指向の分析と設計のためのものですが、大部分の表記はテクノロジーに依存せず、メインフレーム、クライアントサーバ、ネット中心などのアーキテクチャの分析、設計、文書化に使用できます。
独自の表記法を使用している場合は、なぜ業界標準の方法を使用しないのかを自問する必要があります。独自の方法を使用するということは、聞き手に新しい表記法の学習と、内容の理解の両方を強いることになります。表記法は気にせず、内容だけに集中する方がはるかに楽です。
動的な動作を示そうとする図ではパターンに従わない例をよく見ますが、あいまいであり、誤解されやすくなります。一方、UMLのシーケンス図やコラボレーション図は実績があり、システムの動作が明確に示され、幅広い聞き手に理解してもらうことができます。
UMLはその表記法に習熟したIT分野の聞き手に対してのみ有効であると思うかもしれません。UMLはITプロフェッショナルが使用する共通言語なので、一般的にはそのとおりです。しかし、業務分野のパートナーでも、特定の問題を理解しようとするときには、シーケンス図やデプロイメント図に興味を示すことがあります。表記法と内容の両方を学習する必要がありますが、長い間使用されている表記法は簡単に理解できるものです。
9. 関連のある事実と図を組み込む
9番目のヒントは、関連のある事実と図をプレゼンテーションに組み込むことです。示すデータは、結論を支持する重要な証拠でなければなりません。
適切な事実に着目して選択するには、技巧と科学の両面が必要になることがあります。パフォーマンステストでの1秒間のトランザクション数、コールセンター最適化プロジェクトでの平均処理時間、アーキテクチャ計画立案でのソフトウェア製品群のアプリケーション数など、関連のある標準的な尺度が存在する場合があります。
標準的な尺度を利用できないときは、創造性を働かせてメッセージに適した尺度を見つける必要があります。私が気に入っている例の1つは、何年か前に行ったプロジェクトであり、そのときの顧客は、端末よりタイプライターの方が多く、データベースよりファイリングキャビネットの保管場所の方が多いという状況でした。この高収益の顧客を石器時代から抜け出させるためのビジネスケースを作成することは、重要な関係者がこれらの明白な事実を理解してしまえば、難しいことではありませんでした。
すべての事実を徹底的に調べて、聞き手への提示内容を補強する詳細な情報を見つける必要があります。結論を支持する証拠がなくては、聞き手に情報を伝えて、聞き手を説得したり納得させたりすることはできません。
10. 各論、総論、各論のパターンに従う
最後のヒントは、複雑な情報を示すときは、各論、総論、各論のパターンに従うというものです。このパターンは、個別の具体的な例から始めます。この例に基づいて、一般的な考察を行います。最後に、別の具体例を使って結論を示し、提案を補強します。
技術的な情報の説明を一般的な考察から始めてしまうと、観念的で聞き手に関係のないものになる可能性があります。聞き手にも関係があるかもしれない具体的な状況から始めると、聞き手を引き込むことができます。その後で一般的な考察を行えば、理解し、関心を持ってもらえます。最後に示す具体的な状況では、提案を繰り返し、聞き手が関連性を理解するのを助けます。
ある意味、この記事では各論、総論、各論のパターンを使用しています。重役にアーキテクチャの情報を伝えようとしていったんは失敗し、その後で成功した私の具体例を紹介してから、私が学習した10の一般的なヒントを示しました。そして、10のヒントで原則とパターンを解説するときには、他の具体例を使用しました。
まとめ
ソフトウェアアーキテクトとして成功するには、技術的な情報を関係者に効果的に伝える方法を身につける必要があります。アーキテクトならだれでも、同僚やパートナーや意志決定者に重要な情報を伝える最善の方法を見つけようと四苦八苦することがたびたびあるでしょう。
経験は最高の教師であり、身につける1番よい方法は実際に行動してみることです。また、同僚の失敗と成功から学ぶことも役に立ちます。今回は私が1人のアーキテクトとして、ときには苦労しながら適用方法を学習した、いくつかの原則とパターンを紹介しました。
この記事では、初心者向けの10のヒントについて解説しました。聞き手を知る、方法を選択する、コンテキストを設定する、情報の解像度を高める、といったヒントがありました。これは、技術的なコミュニケーションを向上させたいときにまず参考にするのに適したリストです。ただし、これがすべてではありません。記事の最後には、データと情報の提示に関する真のマスターであるEdward Tufteから提供されている資料を示してあります。
アーキテクチャの情報を関係者に説明するのに苦労したことがありますか？ アーキテクチャの情報を示すことはアーキテクトの重要な能力であると身にしみたことがありますか？ アーキテクチャの設計パターンと原則を利用してソリューションを作成し、そのソリューションを関係者に提示するための確立されたパターンと原則がないものかと考えたことがありますか？
いずれかの質問に対する答えが「はい」の場合は、次にアーキテクチャの情報を関係者に説明する必要があるときに、この10のヒントを役立ててみてください。後はあなたしだいです。
参考資料
データと情報を提示するための原則とパターンについてさらに詳しく知りたい読者は、Edward Tufteの著作から学ぶのが有効です。以下の彼のWebサイトでは、書籍、エッセイ、セミナーについての情報が提供されています。
