『Communication Patterns』はソフトウェアエンジニアのためのコミュニケーションを改善するためのパターンを述べた書籍です。
文書、図の書き方だったり、口頭でのバーバル、ノンバーバルなやり取りだったり、リモート環境で起こりがちな非同期コミュニケーションだったり、色々なやり取りの仕方が書かれています。一応「パターン」はアレグザンダー系譜のパターンを指しているようですが、書きっぷりは"パターン"ではありません。
ドキュメンテーションに関しての内容は悪くはないのですが、特に目新しいものはありません。良いドキュメンテーション、陳腐化させないドキュメンテーションの書き方については、『Living Documentation』も網羅的で素晴らしいので、そちらを合わせて読むのがおすすめです。
Living Documentation
Living Documentationを少し紹介しておくと、「ドキュメンテーションとはナレッジを伝達すること」というコンセプトで、その点で『Communication Patterns』と共通しています。
外部ドキュメントと内部ドキュメント
ドキュメントには外部ドキュメントと内部ドキュメントがあります。
- 外部ドキュメント
- プロジェクトの選択した実装技術とは関係のない形でナレッジが表現される。つまり従来の共有フォルダにある個別のMS Office文書や、独自のデータベースを持つWikiなど。
- 内部ドキュメント
- 既存の実装技術を利用してナレッジを直接的に表現する。例えば、Javaの場合、Javadocに加え、アノテーションや言語識別子の命名規則を用いて、設計上の決定を宣言し説明することも含む。
当然ながら内部ドキュメントの方が、メンテナンスが忘れられることが少なく、ミスの検出も自動化しやすいので、できるだけ内部ドキュメントに寄せようというのがLiving Documentationの主張です。
型駆動ドキュメント
内部ドキュメントの中でも、強力な手段となるのが型設計をドキュメンテーションとしても使うということです。
例えば、以下のようなコードでは、このintが金額を表すものであることは伝わらないし、何の通貨かもわからない。なので、それを伝えるコメントが必要になります。
int amount = 12000; // EUR
一方でMoneyクラスを作れば、それを型で明示でき、これが金額であることがわかり、通貨はコードの一部になります。さらにIDE上では、Moneyにカーソルを合わせれば、Moneyのドキュメントがツールチップとして表示されます。
Money amount = Money.inEUR(12000)
型をドキュメントとしても使うと、コードのリファクタリングがほぼ同時にドキュメントのリファクタリングになることを意味し、ドキュメントが嘘をつく可能性が激減するので、その点において特に開発者の多い現場では有用なアイデアかと思います。
リモートのコミュニケーション
『Communication Patterns』の第4部は、コロナ禍を受けて、リモートでのパターンが充実しています。その中で主要なものを紹介します。
同期 vs 非同期
同期コミュニケーションか非同期コミュニケーションか?はリモートに限った話ではないですが、リモートでの同期コミュニケーションは、対面時よりも多くのエネルギーを必要とする研究結果もあり、より慎重に選択する必要があります。
原則は「会議やイベントは、可能な限り「非同期」で前提で考えて、必要な時のみ同期にする」とされています。同期が必要なとき、とは…
- チームビルディングやプロジェクトのキックオフなど、信頼関係の構築
- 問題に対する解決策や製品の新しいアイデアなど、アイデアの創出
非同期コミュニケーションは、過大評価されがちで下手くそな非同期コミュニケーションのコストは見えにくい問題があります。オンラインツールは対面コミュニケーションよりも摩擦を引き起こす可能性があります。そのため「期待」を設定することが重要であるとされています。
4つのWモデル
- Who?
- コミュニケーションに誰を含めるべきで、誰を含めるべきでないか？不必要な情報で人々を過剰に負担させたり、意思決定権を持つ人を除外したりしないこと。
- 誰が返答する責任があるか？返答が必要であれば、誰からか？関与する各人に何が必要かを明確にする。
- 返答が必要な人からの応答が得られるまで、議論や決定が進行しないようにする。
- What?
- 返答として何を期待しているか？返答を期待する場合、その返答はどのような形を取るべきか？これをコミュニケーションで明確にする。
- どのツールとワークフローを使用すべきか？これに関するコミュニケーション契約があるか？ツールとワークフローがコミュニケーションの目標を達成するために適していることを確認する。
- When?
- 日付、時間、タイムゾーンを毎回指定する。明日の終わりまでやできるだけ早くなどの表現は、特に人々が異なる勤務時間やタイムゾーンにいる場合には意味がない。
- Wah-Wah!
- レスがない場合どうなるか？期限を過ぎた場合の対応を明示する。
- レスが必要な理由を明確にする。例:「上記の日付と時間までにご連絡がない場合は、変更の必要がないと判断し、そのままクライアントにドキュメントを送信します」
リモートファースト
リモートワークの比率が増える中で、業務プロセスや意思決定がリモートワークを最適化することに基づいて行われ、すべての従業員に同じ成功のチャンスが与えられることを意味します。似た用語に「リモートフレンドリー」があるが、こちらはリモートワークのための施策をいろいろ打ちはしても、組織はオフィス中心である点が根本的にリモートファーストと異なります。
- リモートワークは単にサポートされるだけでなく、マネージャーを含む全員に推奨される。
- 組織のプロセスや意思決定は、リモートワークの最適化を基準に行われ、異なるタイムゾーンを考慮し、リモートワークを支援するために全てが設計される。
- 採用は、どこに住んでいるかではなく、彼らがその役割や会社に適しているかに焦点を当てる。
- アウトプットが勤務時間よりも重視される。従業員は、オフィスで遅くまで働いていることが見られることで管理層から評価を得ることはない。彼らの仕事の成果が重要である。(※著者はUKの方のようですが、日本以外でもこの傾向が少なからずある、というところが興味深い)
まとめ
『Communication Patterns』はパターン本ではないし、どこかで見聞きしたことのある内容が多いですが、本の構成や文章は非常に分かりやすく、この類の本を読んだことのない方にはおすすめの一冊です。