組織としての不確実性を削減する|『エンジニアリング組織論への招待』第5章【読書感想】

より多くのチームが関わる「組織」という単位における「不確実性の削減」を考えていくのがこの第5章のテーマです。
本章も割と難しく、数式や図が多く用いられていました。
理解できた範囲だけを備忘録としてまとめます。

書名:『エンジニアリング組織論への招待』
著者名:広木大地
出版社:技術評論社

▼関連記事

組織の情報処理能力

「不確実性の削減」とは「情報を生み出す」ことの同意義でした。
市場の不確実性を効率よく仮説検証する能力を企業の情報処理能力と定義します。
市場の不確実性が高ければ高いほど、「情報処理必要量」が多くなります。
それに対して組織の持つ「情報処理能力」が上回れば「組織成果」につながります。

「エンジニアリングの不確実性」モデルでは、不確実性は環境不確実性と通信不確実性に分かれ、環境不確実性は目的不確実性と方法不確実性に分かれると定義してきました。

ガルブレイスの情報処理モデルでは、目的不確実性への対応によって「情報必要量」が決定し、方法不確実性への対処方法と通信不確実性への対処方法によって組織の「情報処理能力」が導かれると捉えることができます。

個人の総和が組織の能力にならない

組織の情報能力を考える上で重要なのは、「個人の情報処理能力の総和」が必ずしも「組織全体の情報処理能力」にはならないという点です。
組織がある構成員の情報能力を完全に発揮するためには、その中で行われるコミュニケーションが100%の完全な情報伝達であり、その構成員が完全に同一の目的・思惑で動いている必要があります。

しかし、現実的には人間は不完全で、完璧な情報伝達はできませんし、それぞれがそれぞれに思惑を持っています。そのため、組織の情報処理能力は人数が増えるほどにコミュニケーションの失敗が発生し、情報処理能力が減衰していきます。

理想的な情報処理の推移と現実の商法処理能力の推移の差が「コミュニケーションコスト」と呼ばれているものです。

コミュニケーションというのは「発信」と「到達」だけではなく「受信」の確認と行動変化による「正しく受信されたか」の確認が不可欠です。

コミュニケーションとは通信不確実性を減らす試みといえます。

エンジニア組織の情報能力を向上するには?

システムを構築していく組織における情報処理能力を考えるにあたって、重要なのは人間同士の関係性の問題です。
少人数ではうまくいっていたコミュニケーションでも、大人数になるとうまくいきません。

そのため、組織に構造が生まれます。誰と誰がコミュニケーションをし、誰と誰はあまりコミュニケーションをしないという形が生まれます。
そうなると、お互いの持っている情報が異なるといった「情報の非対称性」が発生し、情報処理能力が減衰します。

権限移譲

一人が考えて多数が実行するという組織の情報処理能力には限界があります。
組織の情報能力を上げるためには、組織の人数に応じて適切に権限の委譲を行う必要があります。

権限とは、その人が持つ会社の資産に関しての裁量あるいは自由度と言い換えることができます。

権限の委譲は、明示的で連続的なコミュニケーションが必要不可欠です。上司と部下の間のコミュニケーションは、権限と責任の期待値を揃えていくことによって初めて成立します。

一方で、権限にはそれに対する責任が伴います。これを「説明責任」といいます。
説明責任とは、与えられた権限に対して、何を行い、どのような結果をもたらしたのかという説明を、権限を付与した人に報告する責務のことです。

上司と部下の間で認識している権限とそれに伴う責任の不一致が生じると「情報の非対称性」によって組織の情報処理能力は低下します。これは上司の期待値と部下の上司に対する期待値が異なっている状態です。

情報の非対称性を解消できるのは明示的なコミュニケーションだけです。
何度も繰り返し権限について話し合い、具体的なケースを対象にコミュニケーションをしていくことによって、初めて権限委譲がなされたということを双方が認識できるようになります。

技術的負債

システムの内部構造を見ていない人にとって理解できないもののうちマイナスの価値になるものを「技術的負債」と定義します。

システムの内部構造とはシステムの表面的な機能を見ているだけでは知りうることができない、しかしソースコードの中をしかるべき人がじっと見れば読み解くことができる部分です。
この「見える/見えない」という情報の非対称性が、技術的負債が問題になる最大の理由と考えることができます。

エンジニアと経営者の情報非対称性

経営者の頭の中には「これから追加していきたい機能」があるかもしれませんが、それと同じものをエンジニアがイメージできているとは限りません。
エンジニアが想定している追加機能は、実際には追加しないかもしれないのです。

このように経営者とエンジニアの間において、想定する見積もりに誤差が出る理由はお互いの間に存在する情報の非対称性にあります。

  • 追加機能の情報非対称性
  • アーキテクチャが見えないという情報非対称性

という2つの情報非対称性こそが「技術的負債」の原因です。
情報の非対称性の解消はコミュニケーションです。

技術的負債を見える化する

「技術的負債」が見えてしまえば「技術的負債」ではなくなります。
正体の見えてしまった「技術的負債」は一般的に「非機能要件」と呼ばれています。
これは表面の機能には影響がないが、性能や拡張性、運用性といったことに関する要求によって生まれる要件です。

技術的負債に光を当てるためには、以下の二つの情報非対称性を解消していく必要があります。

  • アーキテクチャの複雑性:エンジニア走っていて経営者が知らないこと
  • 将来要件の不確実性:経営者走っていて、エンジニアが知らないこと

アーキテクチャ複雑性の可視化

多くの経営者は、プロダクトのコードを読み解くことができませんし、エンジニア同士の間でも技術的に何が複雑で何がそうでないのかという点の認識を揃えることは難しいです。
アーキテクチャ複雑性を可視化するためには、ツールなどを通じて自動的にどこがどれだけ複雑なのかを数値化することが要求されます。
そのための代表的な3つの方法があります。

循環的複雑度の可視化

「循環的複雑度」という指標を使えば、コードの中のロジックの複雑性を数値化することができます。
それによって、複雑すぎるコードがどこにあり、どの程度の複雑性を有しているのかを可視化することができます。

コード依存関係の分析

循環複雑度は「ある関数」の複雑さだけを数値化したもので、アーキテクチャの構造に伴う複雑性を示してはいません。
モジュール同士の依存関係から、どのモジュールに変更が入りやすくて、どのモジュールの変更を慎重にしなければならないかを推定することができます。

コードチャーンの分析

コードチャーンとは「誰が」「いつ」「どこを」「どのように」コードを修正したのかというリストです。
バージョン管理システムを使用している場合は、そのシステムのログに当たる情報がコードチャーンです。
この情報は、ソースコードの中身ではなく、そのコードを誰がどのように修正してきたのかという関係性から技術的負債の要素を探すことができます。

将来要件の不確定性を可視化

技術的負債の問題とは、経営者とエンジニアの間に存在する「認識の差」の問題です。
技術的負債は追加要件がないときは、問題が発生しません。
なので、今後どのような追加要件が発生しうるのか、どのようにシステムの構造を認識するのかというコンセンサスが重要です。

ユビキタス言語の作成

ユビキタス言語とは、ビジネスドメインを知る人々とプログラマー等、ステークホルダー間で共有する単語とその定義です。
ユビキタスは「どこでも」という意味です。

サービスを取り巻く諸概念を、日常語とは違う形で厳密に定義して、それを関係者で用いることでシステムの関係性のブレをなくしていく活動がユビキタス言語の作成です。

非機能要件の可視化

「理解できないのでやらせない」「理解できないのでやらせる」のどちらも禍根の残る不合理な選択です。
非機能要件であっても、そこへの投資規模を決め、今後の影響度から優先順位の高いものから処理をしていくという「見える化」をしなければなりません。

仮説と戦略の透明化

アーキテクチャとは、システムのどのポイントが変更しやすく、どのポイントが変更しにくいのかを見極めて構造として組み込むものです。
そのため、負のアーキテクチャである「技術的負債」は変更していくだろうと思っていたポイントがあまり変更しなかった時と変更しないだろうと思っているポイントが変更される時に生まれます。
たとえ仮説段階だとしても戦略や意思決定が透明に議論されていると、建設的な議論が生まれます。

あとがき

自分の説明を相手が理解できないのは相手の能力の問題だと決めるつけることは怠惰でしかない。

生徒だった頃、人と意思疎通がうまくできないのは相手の理解能力が乏しいからだと人のせいにしていましたが、本作を読むと、自分の説明力に問題があったのだと反省しました。

「技術的負債」の問題を解消することはとても困難なことです。
持っている知識や情報が違う人たちと認識をすり合わせないといけないので、結構な労力になります。

説明できる能力、難しいことをわかりやすく伝える力がとても重要だということがわかりました。
そのためにはまず、自分がどのような問題を抱えているのか、技術的負債の具体的な内容を口に出して説明できるレベルまで理解できるように努めます。

フォローお願いします