本書はドキュメントについてはもちろんのこと、たとえば人に伝える際にどうすればよいかやリモートワークで働く際に何を気をつけたらよいかといった、開発現場で遭遇する「コミュニケーション」つまり情報伝達の方法論をいろいろと教えてくれる一冊です。今回は私が印象に残った内容を思考の整理がてら紹介したいと思います。
なんとなくタイトルが気になって買ったのが最初でしたが、思ったより自分の知らない話題が多くて得るものは多かったです。また、なんとなく意識していたものに対して名前がついていたことを知れたのもまた収穫だったと思いました。
どんな本か
開発時に出会う情報伝達術についていろいろと体系的に指南してくれる一冊と思って良いでしょう。
まず最初は視覚的なコミュニケーション、つまり図の書き方についての細かい指南から始まります。資料内に書かれるさまざまな「ダイアグラム」の抽象度を揃える話から、データフロー図、アイコンの使い方や図示のアンチパターンまで、幅広い話題が扱われます。それぞれの話題は外観をつかむ目的で読むとよい粒度感になっており、紹介される手法について深く学んでみたい場合は、専用のサイトや専門書を紐解く必要はあるといった読後感です。
次に文章や口頭での会話のコミュニケーション技法について解説されます。読んでいて感じた注意点ですが、どちらかというとこの部は英語話者向けの話題が多いです。しかし個人的には9章のレトリックの三角形は、人に何かを伝える際によく語られる教養知識として重要なものだと思っており、これを知らなかった場合はぜひ読んでおくとよいと思いました。
さらにその次は、いわゆるドキュメント管理に該当する部です。ナレッジマネジメントと言ったりもしますが、これに関連するテクニックが紹介されます。ADRなどの技法も紹介されます。最近のドキュメント管理に関する話題を追いかけている方には、あまり目新しい話題はないかもしれません。が、「なんとなくこれ大事だと思っていたんだよね」というプラクティスに名前がついていたのか、と驚くことはできるのではないかと思います。
最後はリモートワークにおけるコミュニケーション技法について解説されます。同期コミュニケーションの利点やZoom疲れがなぜ発生するのか、あるいは非同期コミュニケーションの使いどころなどが書かれています。
開発者やアーキテクトは、さまざまな抽象レベルの技術的なコミュニケーションを日々取り続ける必要があります。一方で自身の時間も有限ですから、コミュニケーションに費やす時間は最小に抑えたいはずです。自分の伝えたいことが伝わり切らずに何度も同じような説明をするのは避けたいはずです。一度読んでおくと開発現場で役立つTipsがあるかもしれません。
組織におけるコミュニケーション課題に取り組みたい担当者は読んでみるとよいと思いました。この書籍には明日から使えそうなさまざまなプラクティスが豊富に同梱されていると同時に、こうした図鑑的な書籍を使うと、どこから手をつけていけば良いかの当たりを見つけやすいのではないかと思います。
印象に残ったTips
以降では、書籍を読んで印象に残ったTipsを紹介します。
C4モデル
ソフトウェアエンジニアをしているとよくアーキテクチャ図を書くことがあると思うのですが、扱う話題の抽象度を適切に保ちながら図を書くフレームワークといったところでしょうか。この手法では、抽象度をContext、Containers、Components、Codeの4つに分類し、図を作成していきます。
下記のサイトに詳しい解説と具体的な話がいろいろ記載されています。
最初にSystem Context図を書いて、システム間の連携やステークホルダーなどを整理しておきます。次にContainer図で、各システムの連携やステークホルダーが持つ「アプリケーション」と「データストア」に絞ってさらに関係性を具体化して記述します。Component図はContainer図で出てきた「アプリケーション」や「データストア」の中に具体的にどのようなコンポーネントがあるかを記述します。たとえば、どういうコントローラがあってどういうサービスを経由してデータストアにアクセスするか、などです。Code図は超具体的な話、たとえばクラス図などが記述されます。
私もこの手法を知ってから仕事で何度か試してみたのですが概ね好評そうです。デメリットとして、Code図を除けば3回、入れれば4回似たような話が繰り返されるので、少々説明が冗長に感じられることがあるかもしれません。アーキテクトとして使用したメリットとしては、自分の考えを階層構造にできるため、たとえば「Componentからは現場に任せよう」というような判断ができ、現場と自分の棲み分けを明確に線引きできるようになったかなとは思います。
図の書き方については、ほかにデータフロー図も紹介されており気になっています。最近関連する書籍が発売されて話題になっていたのでキーワードとしては知っていたのですが、少し学んでみようかと思い始めました。
認知バイアス系の話題
認知バイアスそれ自体があることは知っていたとしても、開発現場で具体的にどのような場面でどのようなバイアスをかかっているか整理しておくのは有益だと思いました。本書では確証バイアス、後出しバイアス、集団思考が紹介されています。
確証バイアス、とくにエコーチェンバーはよく発生しているかも知れないと思いました。新しい技術を調査したり、ADRを作成する際には、そのADR上でのやり取りでエコーチェンバーが発生しているというのは最近経験がありました。自分が同意できないと思う情報を意図的に探すようにし、メモしておくのが有効な手のようです。
後出しバイアスは、障害対応をしてポストモーテムをする際によく顔を出すかもしれません。このバイアスは、過去の出来事を振り返った時についつい過去の時点では予測可能だったと感じてしまう傾向を指しています。仮に実装時点で影響範囲をしっかり調査できていれば防げたかもしれない障害であったとしても、過去の時点でそれをできた可能性が高いと感じるのは後出しっぽいといったところでしょうか？
パースペクティブ駆動ドキュメンテーション
ここでいう「パースペクティブ」とは、特定のステークホルダーの懸念に対処する成果物の集合を指しています。PdMとかセールスとか、はたまたEMやほかの開発チームなどさまざまなステークホルダーがいるわけですが、彼らの懸念や課題意識単位でドキュメントを用意するという手法です。実現したい機能をPRDやDesign Docのように細かく分けて書いていくのもひとつ、パースペクティブ駆動ドキュメンテーションなのでしょうか。
定義はさておき、ここで学んだこととしては、特定の目的にだけ答えるドキュメントをナレッジマネジメントとして集積していくのがどうやらよさそうだという点です。全部の要求に対応した神ドキュメントを作って、それをひたすらメンテナンスしていくのもひとつの方法です。が、もうひとつの方法として、特定の課題や要望に答えるスナップショットのようなドキュメントを集積しておくのもありだと思った、ということです。
ジャストインタイムアーキテクチャ
これは「アーキテクチャの決定をできる限り先延ばしにする」という考え方です。YAGNIの原則と相性がよいとされています。つまり将来必要になると考えるものではなく、今必要だとわかっているものだけを決定し、ドキュメント化していく方法です。
アーキテクチャの決定をできる限り先延ばしにするこの方法は、なかなか周りに納得してもらえるとも限りません。なんとなく問題を先送りにしている感じがしますし、技術的負債を容易に生み出しそうな感じもするからです。しかし、経験則的には「先のことを悩んでいてもしょうがないので、今ある情報で一旦アーキテクチャを決めて前に進む」「今わかっている限りのものだけとりあえず決める」この方法は、まずまずうまくワークします。実際のところ、そもそも未来の予測は難しく、先の後出しバイアスのように過去を振り返ると「あのときに予測できたはず」と思えるものも、その時点ではほとんど予測できていないことが多いです。リリース後の見込み違いも多々発生します。
この辺りの議論は『Tidy First?』の3章で議論される経済性の話にも関連してきそうにも思いました。後日考えてみようと思います。
感想
知らない話も確かにいろいろ入っておりおもしろくはあったのですが、英語話者向けの話が多かったのと、全体的にサラッと紹介という構成になっていたことから、結局多くを流し読みしました。英語話者向けの部分については、私も仕事中は英語を使うので役に立ちそうとは思ったんですが、よくよく読んでみると向こうの大学で普通に教えられる内容かなあみたいな印象でした。なので、知的好奇心をそそられる類の書籍というよりは、即席で役に立つノウハウ本と思って読むのがいいのかなと思いはしました。
C4の整理の仕方は勉強になりました。たしかにアーキテクチャに関するドキュメントを書く際に、特にコンテナとコンポーネントのレベルで両者を混ぜ込んでしまい、無事に何の話題を扱っているかわからないドキュメントを書いてしまうことがあります。C4の分類に従いながら、今自分はどの抽象度の図を作り、文章を書いているのかを忘れないだけでも、日々のDesign Docなどがかなり見通しのいいものになると思います。
