エンジニアリング組織論〜不確実性に向き合う組織の現在と未来

エンジニアリング組織の未来 - 不確実性との向き合い方

デジタル時代の幕開けとともに、私たちの働き方は大きく変わろうとしていた。かつて、仕事とは決められたタスクをこなすことだと考えられていた時代がある。しかし、テクノロジーの進化とともに、その定義は徐々に変化を見せ始めていた。

広木は、この変化の波を最前線で経験してきた一人だった。ミクシィでアーキテクトとして技術戦略と組織構築に携わり、その後、技術と経営をつなぐアドバイザリーとして多くの企業の変革を支援してきた彼は、ある重要な気づきを得ていた。それは、現代の仕事の本質が「不確実性との戦い」だということだった。

仕事は常に曖昧な状態から始まる。プロジェクトの初期段階では、何も決まっていない。ただモヤモヤとした状態から、徐々に方針が定まり、具体的な形になっていく。この過程こそが「エンジニアリング」の本質だと広木は考えた。それは、単なるプログラミングやシステム構築以上の意味を持つものだった。

不確実性には大きく分けて二つの源がある。一つは「未来」に関する不確実性。誰も明日何が起こるかを正確に予測することはできない。もう一つは「他人」に関する不確実性。私たちは他人の考えを完全に理解することはできない。この二つの不確実性は、あらゆるプロジェクトや組織の課題の根源となっていた。

しかし、人は本能的に不確実性を避けようとする。それは、不確実性が脳にストレスを与えるからだ。体重計に乗るのを避けたり、テストを先延ばしにしたりする行動は、まさにこの不確実性への忌避反応の表れだった。

では、この不確実性にどう向き合えばいいのか。広木は三つの方法を提示する。

第一に、心理的安全性の確保だ。チームメンバーが失敗を恐れずに意見を言え、助けを求められる環境を作ることが重要だ。ただし、これは単に「仲が良い」状態とは異なる。お互いを高め合える関係性こそが求められる。

第二に、リアルオプション戦略と仮説検証の導入。小さな実験を重ね、早期に失敗から学ぶことで、リスクを最小化する。「フェイルファスト（早く失敗する）」の原則は、ここから生まれた。

第三に、経験主義的なプロセスの採用。机上の計算だけでなく、実際の経験から学び、改善を重ねていく方法だ。

さらに、組織のあり方そのものも変化を求められていた。かつての官僚的な組織構造は、急速に変化する環境には適応できなくなっていた。代わりに求められたのは、フラットで柔軟な「ユニット型組織」だった。

特に注目すべきは、組織の「エマルション（溶け合い）」という現象だ。技術部門とビジネス部門の境界が曖昧になり、両者が融合していく。この変化は、単なる組織改編以上の意味を持っていた。それは、仕事の本質的な変化を示唆していたのだ。

実際、労働の形態も大きく変わりつつある。単純な作業は徐々にコンピュータに移管され、人間には本質的なコミュニケーション能力や創造性が求められるようになってきた。これは、一見すると脅威に見えるかもしれない。しかし実際は、人間がより人間らしい仕事に集中できる機会でもあった。

興味深いのは、この変化が経営学とソフトウェア工学の融合をもたらしているという点だ。かつては別々の分野として考えられていた両者が、デジタル時代においては不可分な関係になりつつある。

最後に広木が強調するのは、この変化が決して終わりではないという点だ。むしろ、これは始まりに過ぎない。社会のソフトウェア化が進むにつれ、不確実性との付き合い方はますます重要になっていく。そして、それに適応できる組織だけが生き残っていくだろう。

未来の組織は、不確実性を恐れるのではなく、それを成長の機会として捉える必要がある。そのためには、従来の常識や慣習にとらわれない柔軟な思考と、失敗を恐れない勇気が必要だ。そして何より、組織のメンバー一人一人が、この変化を自分事として捉え、積極的に適応していく姿勢が求められる。

エンジニアリング組織の未来は、不確実性との共存にある。それは決して楽な道のりではないかもしれない。しかし、この変化を受け入れ、適切に対応できた組織こそが、次の時代を切り開いていけるのだ。これは、デジタル時代における組織の生存戦略であり、同時に、より人間らしい働き方への進化の過程でもある。

変化は既に始まっている。問題は、私たちがそれにどう向き合うかだ。不確実性を恐れるのではなく、それを受け入れ、活用する。それこそが、現代のエンジニアリング組織に求められる本質的な能力なのかもしれない。

Transcript

1. エンジニアリング組織論 〜不確実性に向き合う組織の現在と未来 株式会社レクター/日本CTO協会 広木大地
2. 広木 大地 1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに 入社。同社のアーキテクトとして、技術戦略から組織構築などに携わる。 同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。 現在は、株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、 多数の会社の経営支援を行っている。 著書『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリン グ』が第6回ブクログ大賞・ビジネス書部門大賞、翔泳社ITエンジニアに読んでほしい技術 書大賞2019・技術書大賞受賞。一般社団法人日本CTO協会理事。朝日新聞社社外CTO。 株式会社グッドパッチ社外取締役。スパイダープラス株式会社社外取締役。 自己紹介
3. 技術と経営の両面から ソフトウェアエンジニアリングを捉える
4. INDEX 本日のアジェンダ エンジニアリングと不確実性 不確実性に向き合う方法 エンジニアリング組織の過去と未来
5. 皆さんは仕事に対して どんなイメージを持っていますか
6. 決められたタスクを こなすイメージ A
7. 皆で話し合って物事を 具体化していくイメージ。 B
8. 現在の仕事の多くは 何かを”具体化”していくこと
9. 仕事は”曖昧”で始まり”具体”で終わる。 仕事の「はじめ」と「終わり」を考えてみる。 仕事のはじめは何も決まっていなくて、モヤ モヤとしている。だんだんと方針が定まってき て、実現されてくる。 マニュアルでも契約でもソフトウェアでも、具体 的で明確な表現物になって実現される。
10. この過程を「エンジニアリング」と 本書では定義しています。
11. この「エンジニアリング」の過程で、 減っているものはなんでしょうか。
12. 「不確実性」の削減こそが仕事の正体 その過程で行われるすべての行為を「エンジニアリング」と呼んでいる。 ＋情報 ー不確実性
13. プロジェクトも不確実性の削減過程 “不確実性コーン”はプロジェクトの本質的な意味を表現している。
14. 組織も不確実性の削減するメカニズム 社会の不確実性を”喰って”成長する装置が株式会社という生命の構造
15. 不確実性を大きく下げるチーム =生産的 不確実性という補助線をひくと生産的なチームとそうでないチームの形が見えてくる。 ❶マイクロマネジメント型 ❷エンパワーメントチーム型 細かな指示まで上司が行う必要があるチーム 曖昧な状態でも行動でき、任せられるチーム
16. 仕事で行っているのは 「不確実性の削減」だと捉えるとうまくいく
17. より不確実なものから手をつける。 クライアントへの確認やイメージの共有、市場リスクなどより危ういものから確認していく 100% 70% 70% 100% 時間 クオリティ 不確実なものから 明らかにするやりかた 確実なものから 進めていくやりかた
18. では、仕事における “不確実性”の究極的な 発生源は何か？
19. 1 2 人間が本質的にわからないものは 2つ それが不確実性の発生源となっている。 未来：環境不確実性 未来のことは誰も知り得ない。だから、不確実性を 生み出す。マーケットの不確実性。 他人：通信不確実性 他人の頭の中を覗き込むことはできない。だから不 確実性を生み出す。コミュニケーションの不確実性。
20. 不確実性に人が向き合うとき どう感じるか。
21. 不確実性に対して ”たたかう”か”にげる” 攻撃的行動 Fight 回避的行動 Flight or
22. 不確実性が脳にストレスをかける 不確実性に向き合おうとすると怒ったり、逃げたりする反応が生まれそこからトラブルが生じる 不安や恐怖 怒りや攻撃 回避や防衛 不確実性 トラブル
23. 日常における不確実性との向き合い 現在地点の事実を知るということに対しての ”忌避反応” 体重計に乗る テストを受ける
24. 仕事における不確実性への向き合い 早めにやった方がいいはずなのに、つい後ろ倒ししてしまうことはないか。 上司に報告をして フィードバックを受ける すれ違いのある部門との 会話をして懸念を払拭する
25. これらに向き合うとき、 人は「不安」を感じます。 いろんな方法で回避したり、 場合によっては怒りを覚えたりします。
26. ではどのようにして「不確実性」に 向き合うのか。
27. 2つの不確実性とどのように向き合うか。 未来の不確実性 他人の不確実性
28. 1 3 2 ①心理的安全性のあるチーム ②疎結合なシステムと組織 ③システムの不可視性の可視化と対話 他人の不確実性への向き合い方 他人の不確実性 コミュケーション
29. コミュニケーションとは何か？ 情報の非対称性の解消こそがコミュニケーション
30. コミュニケーション能力とは 情報の非対称性を解消できる力のこと 常識の距離が近いほど、会話は成立しやすい。 遠いほど難しい。より多くの非対称性を乗り越える力があ る人が「コミュニケーション能力」がある。
31. ソフトウェアとコミュニケーション ソフトウェアの人文的側面に着目すると立法プロセスのようなコミュニケーションそのもの 複数人の認識をそろえながら 機械的に処理できるほど明晰な文章を 将来の不確実な変化に耐えられるように 構成し、 共同で継続的に管理する営み ソフトウェア開発 立法プロセス
32. 誤解されがちな心理的安全性 “仲がよい”/”アットホームな”とは全く異なる概念 心理的安全性 とは
 
 ‘’対人リスクを取っても問題な いという信念がチームで共有さ れている状態
 「間違い」を認めても大丈夫 「意見」を言っても大丈夫 「助け」を求めても大丈夫 OK! OK! OK! 「ここにいても 」大丈夫 OK!
33. 心理的安全性は一人で創れるものではない アサーティブな言語化能力と問題解決を適切にファシリテーションすることで生まれる。 優しすぎて意見を出せない上司 うまく言語化できない部下
34. 心理的安全性の四章限 如何に意見が言えても、無責任で自分本位の意見だと意味がない。 不安ゾーン ぬるま湯ゾーン 学習ゾーン 無関心ゾーン 心 理 的 安 全 性 高 低 高 低 責任
35. 心理的安全性はなぜ生産性を上げるのか 心理的安全性はプロジェクトリスクを早期に曝露させる。 心理的安全性が高い チームが対人関係リスク をとって議論できる プロジェクトリスク を 早期に発見・対応できる プロジェクトが成功する 心理的安全性が低い チームが対人関係リスク をとって議論できない プロジェクトリスク に 向き合えない プロジェクトが失敗する プロジェクトの 不穏な匂い
36. プロジェクトリスクとはなにか。 プロジェクトのもつ不穏な匂い (リスク事象ドライバー)がリスク事象を引き起こす。
37. コード修正の心理的安全性を高める エンジニアの立場から見るとリリースで胃が痛くならない＝開発者体験の良さ
38. 疎結合なシステムと組織 構造的に型をつくることで、そもそも必要なコミュニケーション量を下げる コンテナリゼーション以前 コンテナリゼーション 以後
39. 組織のコミュニケーション量 組織人数に対してリニアに情報処理能力はスケールしない
40. 複雑性の増大に伴う開発工数の増加 ソフトウェアの複雑性は、機能の組み合わせの数に比例する。
41. ソフトウェアの本質的な困難性は それが見えないことにある。
42. 1 3 2 4 ソフトウェア開発の本質的な難しさ ブルックスの名著「人月の神話 ―狼人間を撃つ銀の弾はない」より筆者によるまとめ ソフトウェアはその規模に対して複雑さが非線形に増大しま す。基本的にソフトウェアというものは一度作られたものであ れば、再利用できます。そのため、どんな人工構造物よりも 複雑になります。 複雑性 ソフトウェアは、文化・業務・経済環境・商習慣、顧客行動な どさまざまな点に連動して、変わり続ける必要があります。当 初の計画通りのシステムが出来上がったとしてもそれは利用 者の要望により変わり続けます。 可変性 ソフトウェアは、それ単独で意味を成すものではなく自分自 身を動作させるハードウェアや、ネットワーク、OS、その他の システムなどと連携しながら、同調することで初めて意味をな します。 同調性 ソフトウェアは、目に見えません。抽象的な概念の相互関係 であり、それは一般に技術者にしか理解できない言語で記述 されます。そのため、ソフトウェアの構造を他の構造物とは違 い見ることができません。 不可視性
43. 見えないことが技術的負債の性質 クルーシュテンの定義によると、技術 的負債の性質はソフトウェアにおいて「見えない」「マイナスの価値」 のものとなる。 技術的負債の四象限 ソフトウェアの性質を可視性と価値の正負によって 4つに分類する バグ 技術的負債 見える 見えない 新機能 アーキテクチャ (開発者体験 ) 出典：フィリップ・クルーシュテン (2012) プ ラ ス の 価 値 マ イ ナ ス の 価 値
44. 見えないことによる情報の非対称性 エンジニアには悪いところがよく見える。非エンジニアには、表面しか見ることができない。
45. 情報の非対称性が コミュニケーションを不全にする。
46. 見えてしまえば、非機能要件のリスト 『ブレーメンの音楽隊』の怪物の様なもの
47. 情報非対称性が 技術的負債 現象の原因 エンジニアは見える、非エンジニアは見えない。この 情報非対称性：そのギャップを埋めるために生み出さ れた言葉が技術的負債。このコミュニケーション ギャップが技術的負債を「問題化」させるまで放置さ せてしまう原因。
48. 1 3 2 ①リアルオプション戦略と仮説検証 ②経験主義的プロセス ③頻度がつくり出す質 未来の不確実性への向き合い方 未来の不確実性 高速な仮説検証
49. 仮説法とは何か 仮説検証という言葉が人口に膾炙しているが、仮説という考え方が理解されていない わずかな痕跡を元に 大胆な予測を行い 大胆な推測を行い それが仮に真である場合 証拠をさがす行動をする。
50. リアルオプション戦略 “わからない”部分を最小のコストで実験し、明らかにすることで後出しジャンケンする。
51. 1 3 2 ①リアルオプション戦略と仮説検証 ②経験主義的プロセス ③頻度がつくり出す質 未来の不確実性への向き合い方 未来の不確実性 高速な仮説検証
52. 理性主義と経験主義 わからないことを行動を通して経験し、それを知識として徐々に突き止める =経験主義 理性主義的な問題解決
 経験主義的な問題解決
 わからなかったので、 もう一度考えてみよ う！ わからなかったので、次 に何をしたらわかるのか 考えよう。
53. 経験主義的プロセス 固定するもの/変化させるものを反転させて「経験」を得られるようにする。 リソース
 納期
 要求
 リソース
 納期
 要求
 固定する 変化する 150pt 15pt 10pt 1ヶ月 1ヶ月 あとどのくらい？
54. 経験主義的プロセス 机上の計算の積み上げによって予定するのではなく、実験から予測するプロセスに。
55. 相対見積もりによってバイアスを取り除く タイムスロットを固定し、消費ポイントから期日を予測することで相対見積もりが可能になる リンゴ1個分 あの猫は3個分くらい スケジュールコミットが厳しい環 境ほど悲観的に見積もる。
 コミットが緩い環境や担当者の 責任感が強いほど楽観的に見 積もる。

56. 見積もりは ”幅を持った予測 ”にする。 楽観 悲観 リスク 楽観 悲観 リスク 楽観 悲観 不確実性をファーストクラスとしてプロジェクト管理の対象にする 1ヶ月後 初期 2ヶ月後
57. プロジェクトを形作るものはなにか。 プロジェクトのタスクとリスク プロジェクトタスク タスクは、プロジェクトを 足し算で評価する。 プロジェクトリスク リスクは、プロジェクトを 掛け算で評価する。
58. 1 3 2 リスクが早期発見されるほど成功する 不安の大きい要素から先に取り組む。 早めに関係者にプロトタイプやできたものを見せる。 本番システムをつかって早期に検査する。 逆に後半でリスクが爆発する方が問題が大きくなる。 プロジェクト早期から、リスク要素に真正面から向き合うには、 チームのコミットメントと心理的安全がなければむずかしい。
59. プロジェクト終了確率は対数正規分布 足し算の世界は、正規分布に近づく。掛け算の世界は対数正規分布に近づく。 正規分布 対数正規分布
60. プロジェクト大規模化がリスクを増やす そのため可能なら小さな単位に分割したい。
61. プロジェクトスコープを小さく保つ 規模が小さいとタスクの足し算の要素が支配的になり、大きいとリスクの掛け算が支配的になる 正規分布 対数正規分布 大規模化 細分化 リスクの裾野が長くなり コントロールしにくくなる。
62. 見積もり、コミットメント、ターゲット 見積もりは本来は確率分布の形をしている。 見積もりとして、表現されたものが 50％で完了するラ インであれば楽観的な見積もりだし、 99%であれば悲 観的すぎる見積もり。 何%で終わる見積もりなのか。
63. 見積もり、コミットメント、ターゲット 見積もりを人々が口にするときに 3つの観点がバラバラなときトラブルが起こる。 コミットメントはチームの努力目標。 見積もりは確率分布。 ターゲットはビジネスとして必要な時期。 60% 80% 努力目標はあったほうがいい。 でも、外部に約束する時は、普通は十分な確率を見越して設定 しないと企業価値が損なわれる。
64. 1 3 2 ①リアルオプション戦略と仮説検証 ②経験主義的プロセス ③頻度がつくり出す質 未来の不確実性への向き合い方 未来の不確実性 高速な仮説検証
65. ドラム式自動洗濯機の ”良さ” 新しい「当たり前」となる習慣の価値は、使う前にはわからない。 手洗いの方が よく落ちるよ 全自動は 信用できない 干すのは 手間じゃない 洗剤は 自分で入れる
66. フロー効率を高める技術的投資 継続的デリバリーを前提に自動化や効率化を徹底的に進めることで品質と価値効率を最大化する 開発 テスト リリース 開発 リードタイム リードタイム プロダクト型 プロジェクト型 CI/CDなどのデリバリー自動化への投資 継続デリバリーを前提としたアーキテクチャ投資 頻度は「質」に転化する。
67. 67 © rector.inc フェイルファストの原理 シリコンバレーでは、 Fail Fast (早めに失敗しろ )という言葉がよく言われる。 さまざまな試行錯誤があってこそ、イノベーションを生む のだという話として表層的に捉えられていることが多い。 モダンなソフトウェアプロダクト開発においては、まさに この「早めに失敗する」という原理に基づいて 様々な技術/文化が発達し、その結果強靱で強力、高品質な プロダクト開発が行われている。
68. 失敗から学ぶ ≠ とりあえずやってみる 失敗するかも知れないことをやるというよりも、失敗そのものを積極的に生み出す 何でもかんでも 闇雲にやる 失敗が早期であれば プロジェクトの被害は 軽微 早く失敗しろ 失敗から学ぶ 早く失敗しろ 失敗から学ぶ
69. フェイルファストの原理から導かれる文化 早期に”低コスト”で失敗を引き起こす仕掛けをつくる 失敗から”次の行動”が導けるような仮説思考に基づく それらを組織的にスケールできるようにする
70. フェーズ毎の「フェイルファストの原理」 経営と組織文化 プロダクトマネジメント 開発中 リリース後 心理的安全性の投資 リアルオプション戦略 透明性あるOKR 仕事の明確化 コアの内製化 失敗の予算化 発信のオープン化 フェイルファスト マインドの育成 仮説法的なNSM リードタイム最適化 システム思考 データ駆動な仮説構築 ユビキタス言語の管理 仕様の直交性 形式手法等の仕様検査技術 優先順位算出の明文化 静的型/型推論の発展 CodeClimate/ Linter Churn analysis/静的解析 Security Shift Left DevOps / DevSecOps Microservices ユニットテストとCI API駆動開発 Trunk Based Development コンテナ化 / k8s化 継続的デプロイメント Blue Green Deployment Feature Toggle Dark Launch サーキットブレイカー フォルトインジェクション カオスエンジニアリング Infra as Code
71. エンジニアリングが導く未来の組織
72. エンジニアリング組織の変化 職能別組織 事業部組織 ユニット型組織 CEO ビジネス組織 技術組織 事業部 ビジネス組織 技術組織 CEO 事業部 事業部 プロダクトチーム プロダクトチーム プロダクトチーム 横軸組 織
73. 組織の「エマルション」が進む ソフトウェアを事業に生かしていくことが当たり前になるにつれて、組織の中で溶け合う 職能別組織
 事業部組織
 ユニット型組織
 外注型組織

74. 文字とコード。民主化するプログラミング かつて、文字が書ける書記官は高給取りで人材不足と言われていた。 文字がかける書記官 コードがかけるエンジニア
75. 異なる要素の 境界面に争いは生じる。 溶け合った後 には、争いは生じない。
76. 一昔前の働き方って「非人間的」？ 「仕事が奪われる」そのとき、どんな仕事が奪われているのでしょうか。 白物家電のない生活 工場制手工業
77. 未来からみると 私達の働き方は「非人間的」。
78. 働き方の変化はなぜ起きているか。 少ない労働力でより多くのことをコンピュータに任せて仕事をしていく必要がでてきている。 労働力が希少に 
 コンピュータが安く大量に 

79. コンピュータに 働かせる領域を増やし ヒトが働く領域の価値を上げる。
80. 労働の移転：人から計算機へ 旧来型組織 
 現代的ソフトウェア企業 

81. 労働の移転：人から計算機へ 旧来型組織 
 現代的ソフトウェア企業 
 均質なチーム 多様なチーム
82. 目的と手段のはしごが置き換わっていく 不確実性が小さい”手段”の領域からコンピューターが置き換えていく 目的 手段 目的 手段 目的 手段 目的 手段 目的 手段 不確実性小 不確実性大
83. 労働の移転：運営から成長への仕事の変化 旧来型組織 
 現代的ソフトウェア企業 
 運営( Run the Business) 成長( Grow the Business ) 変革( Transform the Business) 成長( Grow the Business ) 変革( Transform the Business)
84. 労働の移転：成長する組織の仕事のあり方 旧来型組織 
 現代的ソフトウェア企業 
 官僚型職能別組織 コマンド＆コントロールの目標管理 メンバーシップ型人事制度 全体論的多様性のあるチーム 権限委譲と透明性のある OKR型目標 ジョブディスクリプション型人事制度
85. 不確実性に適応する力が求められる。 2020年版ものづくり白書 

86. 経営学とソフトウェア工学を わけて考える時代の終わり。
87. 社会のソフトウェア化が進むと 人間には本質的なコミュニケーション能力 が求められてくる。