記事：アーキテクチャについてプレゼンする際の１０のコツ

Architecture Articles

developer.comよりJeff Ryan氏の記事について、要約とコメント

要約


アーキテクチャについてプレゼンする際の１０のコツ
Developer.com: Your Home for Java and Open Source Development Knowledge - Developer.com

かつて、幹部にアーキテクチャの説明をしようと、80頁のパワーポイント資料を作ったがうまく行かなかった。後にもう一度チャンスがまわってきたので、その時には、アーキテクチャの青写真を作る過程をサンプルと共に１枚の絵にまとめた。結果として、この方法はうまく行った。これがなぜうまく行ったのかということが分かったのはデータと情報のプレゼンテーションに関するEdward Tufte氏のセミナーに参加した時だった。Tufte氏のセミナーやその他から学んだ10個のコツをここにまとめておく。

  1. 聴き手のことを理解する（"Know Your Audience"）
  2. アプローチを丁寧に選ぶ（"Carefully Choose Your Approach"）
  3. 文脈を設定する（"Set the Context"）
  4. 情報の解像度を増やす（"Increase the Information Resolution"）
  5. データをユニバーサル・グリッド上に示す（"Show Data on a Universal Grid"）
  6. 小さい図をたくさん書く（"Use Small Multiples"）
  7. 内容が全てであると認識する（"Recognize that Content is King"）
  8. 業界標準の記法をうまく使う（"Leverage Industry Standard Notation Techniques"）
  9. 対応する事実と図とを組み合わせる（"Incorporate Relevant Facts and Figures"）
  10. 個別−普遍−個別パターンに従う（"Follow the Particular, General, Particular Pattern"）

聴き手のことを理解する（"Know Your Audience"）
  • 飛び抜けて知的だが、時間がほとんどなく、しばしば忍耐強くないような幹部がいる。そういう人が頭に浮かべる疑問に対する答えを１枚にまとめておくことで、議論がうまく進む。
  • 聴く人の視点から、「何がうれしいの？（WIIFM:What's In It For Me?）」と問うこと。
  • まず疑問を投げかけ、思考のプロセスに合わせて説明していくことで理解しやすくする。
アプローチを丁寧に選ぶ（"Carefully Choose Your Approach"）
  • コミュニケーションの媒介はホワイトボードから単なる会話までさまざまなものがある。
  • 多くの場合、聴く人を引きつけるにはホワイトボードが一番いい。書くのに合わせて情報は徐々に明らかになり、質問に対してもリアルタイムに書き込める。
  • 紙の方がいいこともある。回し読みや読み合わせの他、履歴を取ったりサインをもらったりするのにも使える。
  • すぐにスライドを作ってしまうのを見かけるが、他の手段も考えるべきだ。
文脈を設定する（"Set the Context"）
  • 過去に議論した内容であっても、聴き手に思い出させるのは発表者の義務。
  • 説明する情報に関しても文脈を設定するべき。それによって比較したり正しい枠組みで理解できるようになる。
  • パターンとしては、マスター・ディテールが使える。
情報の解像度を増やす（"Increase the Information Resolution"）
  • 情報の解像度（"Information Resolution"）とはあるページに含まれる情報の量
  • 人間はパワーポイントに良くある「箇条書き６つとちょっとした図」よりも多くのことを吸収できる。
  • １ページにまとめる方法がうまくいったのは、聴き手が瞬時に情報を把握し、詳細についてもっと聴きたいと思ったから。
データをユニバーサル・グリッド上に示す（"Show Data on a Universal Grid"）
  • ユニバーサル・グリッドを用いて、図を読みやすくする。
  • ここで言うユニバーサル・グリッドとは、n階層アーキテクチャに関する概念的な図を、同じ背景色で塗られた、同一のレイヤ分けの上にのせたもの。
小さい図をたくさん書く（"Use Small Multiples"）
  • スモール・マルティプルとは、オブジェクトないしオブジェクト群の変化を視覚的に示すために、小さい絵を１ページにまとめたもの。
  • 時間の経過に伴うシステムの変化を示すのもアーキテクトの仕事。
  • この小さい絵はユニバーサル・グリッド上に載せることができる。
内容が全てであると認識する（"Recognize that Content is King"）
  • プレゼンテーションは内容が全てで、中身がダメなら、他のコツは関係ない。
  • 内容がダメなプレゼンテーションに比べれば、方法はつたなくても、内容が優れている方がまし。
業界標準の記法をうまく使う（"Leverage Industry Standard Notation Techniques"）
  • UMLはシステムを表すのに優れた記法。
  • 自己流の記法では、聞き手は内容と同時に記法も学ばなければならない。
  • UMLは技術系の人間しか分からないと思われがちだが、ビジネス側の人でも興味が持てることもある。
対応する事実と図とを組み合わせる（"Incorporate Relevant Facts and Figures"）
  • データは結論を支える重要なエビデンス。
  • まずは標準的なメトリクスを考える（パフォーマンステストにおける１秒当たりのトランザクションなど）。
  • 標準的なものが無ければ、適切なメトリクスを考える必要がある。
  • 全ての事実は詳細な議論を支えるものでなければならない。
個別−普遍−個別パターンに従う（"Follow the Particular, General, Particular Pattern"）
  • 特定の具体例から始め、一般的な観察に進み、要点を強化する別の具体例で結論付ける。
  • 技術的な情報を一般的な観察から始めると、観念的すぎて聴き手に入っていかない。聴き手に関係のある具体例から始めれば、引き込むことができる。
  • この記事も個別-普遍-個別パターンに従っている。
サマリー

A successful software architect must learn how to effectively communicate technical information to stakeholders. Every architect will struggle at times in finding the best way to convey important information to peers, partners and decision makers.


ソフトウェア・アーキテクトとして成功するには、技術的な情報についてステークホルダと効果的にコミュニケーションする方法を学ばなければなりません。同僚やパートナ、決定権を持つ人に対して、重要な情報を伝える最も良い方法が何であるのかを考えるのに、アーキテクトは誰でも苦労しているのです。

  • 経験が重要だが、先達の知識も役に立つ。
  • この記事で示した内容は、技術的なコミュニケーションを改善する上でのスタート地点になる。

コメント

プレゼンテーション上達のブレイクスルーがあるとしたら、それは「自分が話したいことを相手が聴きたいとは限らない」ということを理解した時でしょうか。アーキテクトと呼ばれるような仕事を好んでする人種は、そもそも「そういう話」が好きな人たちな訳ですが、いきなり自分の興味から空中戦を展開し、理解してもらえずに「奴らは技術が分かっていない」とグチをこぼしているケースが少なからずあるように感じています。


Ryan氏が示しているのは、相手の認識に添いながら巧く自分のストーリーに引き込むための方法論であり、仕事に限らず、勉強会等でもアーキテクチャについて何らかのプレゼンテーションを行う時には、大いに参考にできるものなのではないでしょうか。原文にはユニバーサル・グリッドやスモール・マルティプルの具体的な図も載せられていますので、興味を持たれた方はぜひご参照下さい。


なお、技術系プレゼンに関しては、こちらでも重要なコツがまとめられています：