ものづくりの不確実性に向き合う「エンジニアリング組織論への招待」
だいたい6年前の2018年、社会人になってまだ間もないくらいの時に読んで、すこぶる感銘を受けた本です。
当時、新米プロダクトマネージャーとしてモバイルWebプロダクトの改善に奔走してた頃、なんか上手く仕事できないなー成果だせないなーと悩んでいたのですが、本書を読んで「自分に足りなかったのはこの考え方や！」とスッと腑に落ち、そこからうまく物事が好転し始めたんですよね。
ほんと読んでよかったと今も思っている一冊です。
振り返りも兼ねつつ、本書から印象に残った箇所を抜粋・コメントしていきます。
それは誰かの曖昧な要求からスタートし、それが具体的で明確な何かに変わっていく過程が実現で、その過程のすべてがエンジニアリングという行為です。 つまり、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです。
エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移していく過程に行うすべてのことです。 「不確実性を下げること」はつまり、シャノンの定義に従えば、「情報を生み出すこと」に他なりません。
この”エンジニアリング”の定義にハッとさせられたと共に妙に納得した。
不確実性というものはどこから生まれるのでしょうか。不確実性とはつまり「わからないこと」によって生まれます。人間にとって、本質的に「わからないこと」はたった2つしかありません。それは、「未来」と「他人」です。
情報を入手するために、行動を起こして、その結果を観察し、そこから問題解決を行う考え方を「経験主義」といいます。また、限定された情報であっても、その情報から全体像を想定し、それを確かめることで少ない情報から問題解決に向かう思考様式を「仮説思考」といいます。 この2つがなければ、行動が止まってしまい、答えに近づくことが難しくなるでしょう。
不確実性を生むのは「未来」と「他人」。
極論すれば、あらゆる前提から逃れて「良い」プログラムというものはありません。拡張性があるとか、読みやすいだとか、ドキュメントが充実しているといった表面的な要素が、そのまま「良さ」を作るわけではありません。 そのプログラムがある前提に基づいた問題解決策だから、その前提のもとに「良い」という判断ができるだけで、解決するべき問題の設定、そのモデル化、開発時の状況などによって、問題解決策は束縛されていて、前提とのマッチングによって、それが「良い」だとか「悪い」だとかが決まります。
筆者が考える決定的な違いは、「良い」プログラマには問題解決のための眼があるということです。眼が経験を有意義にも無為にもします。 眼が状況を判断し、自分がおかれている前提を正しく把握した設計を生み出し、良いプログラムを作り出します。
問題解決のための眼、それは「視野」「視座」「視点」の3つに分類できます。 「視野」とは、あるポイントからその問題を眺めたときに同時に把握できる領域の広さです。「視座」とは、どこから眺めるか。高い／低いで評価されるものです。視野がいかに広くても、視座が低ければさらに次元の高い問題を認識できないし、視座が高すぎても抽象論に終始しミクロな解決策が浮かびません。「視点」とは、どの角度から見るか。鋭さ／凡庸さでとらえるものです。問題の構造を把握して、解決策の筋を刺すときに問題の捉え方によってはシンプルになることがあります。普段は見えない角度から本質をえぐり出すのが「視点」の力です。
なるほど。
プロジェクトは、「はじめ」と「おわり」があり、それが効果を上げて「終了すること」が目的です。それに対して、プロダクトは「製品・サービス」ですので、そのプロダクトが継続的に収益を上げて、損益分岐点を超えて発展することで、「終了しないこと」が目的になります。 つまり、プロジェクトにとって最大のリスクは、「終了しないこと」つまり、納期を超過してしまうことと、完成の目処が立たなくなることです。ですので、プロジェクトマネージャーは「スケジュール不安」を減少させるように物事に取り組んでいきます。 一方、プロダクトにとっての最大のリスクは、「終了してしまうこと」です。顧客やマーケットに受け入れられず、採算が取れずに継続的にプロダクトの提供ができなくなってしまうことが問題となります。ですので、プロダクトマネージャーは、「マーケット不安」を減少させるように物事に取り組んでいきます。
頷きが止まらない定義。
「エンジニアリング」は不確実性を削減することです。しかし、削減するべき不確実性が何なのかわからなければ、つまり「見る」ことができなければ、それを管理することができません。どこにどんな不確実性が宿っているのかを深く観察する必要があります。
不確実性は、3つに大別されます。将来がわからないことから生じる方法不確実性と目的不確実性、それから、他人とのコミュニケーションの失敗や不足によって生じる通信不確実性です。 これらを継続的に削減するための仕組みがあれば、それによって物事は実現に進みます。
私たちがわからないことには、未来と他人があります。未来の不確実性は、ソフトウェアをどのように作るかという方法不確実性と何のためにソフトウェアを作るのかという目的不確実性に分かれます。また、他人の不確実性は通信不確実性といい、コミュニケーションが不確実であるために情報の非対称性や限定合理性が生まれてしまいます。
自分達が今向き合っている不確実性が何なのか。方法不確実性なのか、目的不確実性なのか、通信不確実性なのか。これを自己認識したうえで、対処しないといけない。
通信不確実性を極力削減するためには、大人数では難しくなります。できる限り少人数で、最も情報の多い対面でのコミュニケーションによって情報共有を行います。これによって、「情報の非対称性」を減らすように努めます。
組織の情報処理能力を考える上で重要なのは、「個人の情報処理能力の総和」が必ずしも「組織全体の情報処理能力」とはならないという点です。 ある情報処理能力をもった1人の能力と比較して、同じ能力をもった10人の組織の情報処理能力では、単純計算では10倍の情報処理能力をもつはずです。しかし、実際にはそういった線形的に能力が増えることはありません。人数が増えるほど、徐々にその想定とは乖離していきます。
理想的な情報処理能力の推移と現実の情報処理能力の推移の差が「コミュニケーションコスト」と呼ばれているものです。いかにして、この差を減らしていくのかが、組織のケイパビリティを向上させるために考えるべきことです。
コミュニケーションというのは、「発信」と「到達」だけではなし得ません。「受信」の確認と行動変化による「正しく受信されたか」の確認が不可欠です。なぜなら、コミュニケーションとは通信不確実性を減らす試みのことだからです。
通信不確実性を削減することも"エンジニアリング"の一環。
将来的に技術的負債になりにくいコードというものは存在していても、技術的負債にならないコードが存在するわけではありません。予想外の機能追加や、ビジネス目的の方針転換、人員数の増加など、様々な外的要因によって、技術的負債というものが蓄積されやすくなります。 開発者がその時点ですべきことは、YAGNI原則（you ain’t gonna need it ）に代表されるように、「今必要な機能をシンプルに作る」ことです。
システムに関して、エンジニアと非エンジニアの視点は、CTスキャンされた図像で人体を見ているか、肉眼で表面的に見ているかというくらいに違います。エンジニアだからこそ気がつく病魔の兆候も、非エンジニアには伝わりません。「技術的負債」というアナロジーが、経営者とエンジニアのコミュニケーションのために有用だと考えられ、生まれたのにもこのような非対称性が背景にあります。
シュミットの定義によれば、技術的負債（実際には、アーキテクチャ資本の資本コスト）はある機能を付け加えたいときに掛かるコストの差として表現されました。「理想的なシステム」との差です。 ここで、注意したいのは「技術的負債」という言葉が、経営者とエンジニアのコミュニケーションのために生まれたという点です。
システム内部に起こる「複雑性の増加」によって、機能追加が遅くなるという現象を経営者は理解しにくく、また数値化もしにくいので合理的判断がしづらいというコミュニケーション上の問題に、「負債」というメタファーを当てて、コミュニケーションを始めるために生まれた考え方でした。 つまり、「技術的負債」というキーワードで問うべきは、エンジニアチームと経営者の間に存在する認識の差であって、システムの複雑性の増加そのものではないと考えるほうが、より「技術的負債」という言葉をめぐるアプローチとしては適切だということです。
技術的負債が問題となるのは、それが見えないからです。経営者から見えるようにしてしまえば、管理可能なものになります。 技術的負債に光を当てるためには、2つの情報非対称性、つまり「エンジニアは知っていて、経営者が知らないこと」と「経営者は知っていて、エンジニアが知らないこと」を解消していく必要があります。前者は「アーキテクチャの複雑性」であり、後者は「将来要件の不確実性」です。
技術的負債に向き合うときの考え方、非エンジニアとしてはとても参考になりました。
この記事が気に入ったらサポートをしてみませんか？