派生開発カンファレンス

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

株式会社レクター/日本CTO協会 広木大地

自己紹介広木 大地
1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに入社。同社のアーキテクトとして、技術戦略から組織構築などに携わる。
同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。
現在は、株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、多数の会社の経営支援を行っている。
著書『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリン
グ』が第6回ブクログ大賞・ビジネス書部門大賞、翔泳社ITエンジニアに読んでほしい技術書大賞2019・技術書大賞受賞。一般社団法人日本CTO協会理事。朝日新聞社社外CTO。
株式会社グッドパッチ社外取締役。

技術と経営の両面からソフトウェアエンジニアリングを捉える

INDEX
本日のアジェンダ

エンジニアリングと不確実性
不確実性に向き合う方法
エンジニアリング組織の過去と未来

皆さんは仕事に対してどんなイメージを持っていますかA
決められたタスクをこなすイメージ

B
皆で話し合って物事を具体化していくイメージ。

現在の仕事の多くは何かを”具体化”していくこと仕事は”曖昧”で始まり”具体”で終わる。
仕事の「はじめ」と「終わり」を考えてみる。

仕事のはじめは何も決まっていなくて、モヤモヤとしている。だんだんと方針が定まってきて、実現されてくる。

マニュアルでも契約でもソフトウェアでも、具体的で明確な表現物になって実現される。

この過程を「エンジニアリング」と本書では定義しています。

この「エンジニアリング」の過程で、減っているものはなんでしょうか。

「不確実性」の削減こそが仕事の正体
その過程で行われるすべての行為を「エンジニアリング」と呼んでいる。

＋情報ー不確実性

プロジェクトも不確実性の削減過程“不確実性コーン”はプロジェクトの本質的な意味を表現している。

組織も不確実性の削減するメカニズム
社会の不確実性を”喰って”成長する装置が株式会社という生命の構造不確実性を大きく下げるチーム=生産的不確実性という補助線をひくと生産的なチームとそうでないチームの形が見えてくる。

❶マイクロマネジメント型

細かな指示まで上司が行う必要があるチーム❷エンパワーメントチーム型

曖昧な状態でも行動でき、任せられるチーム

仕事で行っているのは「不確実性の削減」だと捉えるとうまくいく

より不確実なものから手をつける。
クライアントへの確認やイメージの共有、市場リスクなどより危ういものから確認していく

クオリティ

不確実なものから明らかにするやりかた

100%

70%
確実なものから進めていくやりかた

時間

70%

100%

では、仕事における“不確実性”の究極的な発生源は何か？

人間が本質的にわからないものは2つそれが不確実性の発生源となっている。

1 未来：環境不確実性

2

他人：通信不確実性

未来のことは誰も知り得ない。だから、不確実性を生み出す。マーケットの不確実性。

他人の頭の中を覗き込むことはできない。だから不確実性を生み出す。コミュニケーションの不確実性。

不確実性に人が向き合うときどう感じるか。

不確実性に対して”たたかう”か”にげる”

or

攻撃的行動

回避的行動

FightFlight不確実性が脳にストレスをかける
不確実性に向き合おうとすると怒ったり、逃げたりする反応が生まれそこからトラブルが生じる

回避や防衛

不確実性

不安や恐怖

トラブル

怒りや攻撃

日常における不確実性との向き合い
現在地点の事実を知るということに対しての”忌避反応”

体重計に乗る

テストを受ける

仕事における不確実性への向き合い早めにやった方がいいはずなのに、つい後ろ倒ししてしまうことはないか。

上司に報告をしてフィードバックを受ける

すれ違いのある部門との会話をして懸念を払拭する

これらに向き合うとき、人は「不安」を感じます。
いろんな方法で回避したり、場合によっては怒りを覚えたりします。

ではどのようにして「不確実性」に向き合うのか。

2つの不確実性とどのように向き合うか。

他人の不確実性

未来の不確実性他人の不確実性への向き合い方
1①心理的安全性のあるチーム

他人の不確実性

2②疎結合なシステムと組織コミュケーション

3③システムの不可視性の可視化と対話コミュニケーションとは何か？
情報の非対称性の解消こそがコミュニケーション

コミュニケーション能力とは情報の非対称性を解消できる力のこと

常識の距離が近いほど、会話は成立しやすい。
遠いほど難しい。より多くの非対称性を乗り越える力がある人が「コミュニケーション能力」がある。

ソフトウェアとコミュニケーション
ソフトウェアの人文的側面に着目すると立法プロセスのようなコミュニケーションそのもの

複数人の認識をそろえながらソフトウェア開発
機械的に処理できるほど明晰な文章を将来の不確実な変化に耐えられるように構成し、共同で継続的に管理する営み

立法プロセス誤解されがちな心理的安全性“仲がよい”/”アットホームな”とは全く異なる概念

OK!

「ここにいても」大丈夫

OK!

「意見」を言っても大丈夫

OK!

「間違い」を認めても大丈夫

心理的安全性とは‘’対人リスクを取っても問題ないという信念がチームで共有されている状態

OK!

「助け」を求めても大丈夫心理的安全性は一人で創れるものではない
アサーティブな言語化能力と問題解決を適切にファシリテーションすることで生まれる。

優しすぎて意見を出せない上司激しく捲し立てて言語化できない部下

心理的安全性の四章限如何に意見が言えても、無責任で自分本位の意見だと意味がない。
高心理
的安
全性

ぬるま湯ゾーン学習ゾーン

無関心ゾーン

不安ゾーン

低低

責任

高

心理的安全性はなぜ生産性を上げるのか
心理的安全性はプロジェクトリスクを早期に曝露させる。

心理的安全性が高い

心理的安全性が低い

チームが対人関係リスクをとって議論できるチームが対人関係リスクをとって議論できない

プロジェクトの不穏な匂い

プロジェクトリスクを早期に発見・対応できるプロジェクトリスクに向き合えない

プロジェクトが成功する

プロジェクトが失敗する

コード修正の心理的安全性を高める
エンジニアの立場から見るとリリースで胃が痛くならない＝開発者体験の良さ

疎結合なシステムと組織構造的に型をつくることで、そもそも必要なコミュニケーション量を下げる

コンテナリゼーション以前

コンテナリゼーション 以後

組織のコミュニケーション量
組織人数に対してリニアに情報処理能力はスケールしない複雑性の増大に伴う開発工数の増加
ソフトウェアの複雑性は、機能の組み合わせの数に比例する。

マイクロサービス化のスイートスポット
マーケットの不確実性が下がり、分割によって得られる効率が調整コストを超えるタイミング

ソフトウェアの本質的な困難性はそれが見えないことにある。

ソフトウェア開発の本質的な難しさ
ブルックスの名著「人月の神話―狼人間を撃つ銀の弾はない」より筆者によるまとめ1

複雑性

ソフトウェアはその規模に対して複雑さが非線形に増大します。基本的にソフトウェアというものは一度作られたものであれば、再利用できます。そのため、どんな人工構造物よりも複雑になります。

3

可変性

ソフトウェアは、文化・業務・経済環境・商習慣、顧客行動などさまざまな点に連動して、変わり続ける必要があります。当初の計画通りのシステムが出来上がったとしてもそれは利用者の要望により変わり続けます。

2

同調性

ソフトウェアは、それ単独で意味を成すものではなく自分自身を動作させるハードウェアや、ネットワーク、OS、その他のシステムなどと連携しながら、同調することで初めて意味をなします。

4

不可視性

ソフトウェアは、目に見えません。抽象的な概念の相互関係であり、それは一般に技術者にしか理解できない言語で記述されます。そのため、ソフトウェアの構造を他の構造物とは違い見ることができません。

技術的負債の四象限
ソフトウェアの性質を可視性と価値の正負によって4つに分類する

見えないことが技術的負債の性質

プ
ラスの価値

見える

見えない新機能アーキテクチャ(開発者体験 )

バグ

技術的負債

クルーシュテンの定義によると、技術的負債の性質はソフトウェアにおいて「見えない」「マイナスの価値」のものとなる。

マイナスの価値

出典：フィリップ・クルーシュテン(2012)

見えないことによる情報の非対称性
エンジニアには悪いところがよく見える。非エンジニアには、表面しか見ることができない。

情報の非対称性がコミュニケーションを不全にする。

見えてしまえば、非機能要件のリスト『ブレーメンの音楽隊』の怪物の様なもの

情報非対称性が技術的負債現象の原因
エンジニアは見える、非エンジニアは見えない。この情報非対称性：そのギャップを埋めるために生み出された言葉が技術的負債。このコミュニケーションギャップが技術的負債を「問題化」させるまで放置させてしまう原因。

未来の不確実性への向き合い方
1
未来の不確実性

2①リアルオプション戦略と仮説検証②経験主義的プロセス

高速な仮説検証3③頻度がつくり出す質仮説法とは何か
仮説検証という言葉が人口に膾炙しているが、仮説という考え方が理解されていない

わずかな痕跡を元に大胆な推測を行い大胆な予測を行いそれが仮に真である場合証拠をさがす行動をする。

リアルオプション戦略“わからない”部分を最小のコストで実験し、明らかにすることで後出しジャンケンする。

未来の不確実性への向き合い方
1
未来の不確実性

2①リアルオプション戦略と仮説検証②経験主義的プロセス

高速な仮説検証3③頻度がつくり出す質理性主義と経験主義わからないことを行動を通して経験し、それを知識として徐々に突き止める=経験主義

理性主義的な問題解決

わからなかったので、もう一度考えてみよう！

経験主義的な問題解決

わからなかったので、次に何をしたらわかるのか考えよう。

経験主義的プロセス
固定するもの/変化させるものを反転させて「経験」を得られるようにする。
固定する
要求

リソース

10pt

1ヶ月

15pt

1ヶ月

納期

150pt
あとどのくらい？

リソース
変化する

納期

要求

経験主義的プロセス
机上の計算の積み上げによって予定するのではなく、実験から予測するプロセスに。

相対見積もりによってバイアスを取り除く
タイムスロットを固定し、消費ポイントから期日を予測することで相対見積もりが可能になる

リンゴ1個分

スケジュールコミットが厳しい環境ほど悲観的に見積もる。

コミットが緩い環境や担当者の責任感が強いほど楽観的に見積もる。

あの猫は3個分くらい見積もりは”幅を持った予測”にする。
不確実性をファーストクラスとしてプロジェクト管理の対象にする
プロジェクト初期

プロジェクト後半

未来の不確実性への向き合い方
1
未来の不確実性

2①リアルオプション戦略と仮説検証②経験主義的プロセス

高速な仮説検証3③頻度がつくり出す質ドラム式自動洗濯機の”良さ”
新しい「当たり前」となる習慣の価値は、使う前にはわからない。

手洗いの方がよく落ちるよ

全自動は信用できない

干すのは手間じゃない

洗剤は自分で入れる

フロー効率を高める技術的投資
継続的デリバリーを前提に自動化や効率化を徹底的に進めることで品質と価値効率を最大化する
リードタイムプロジェクト型

開発

テスト

リリース

継続デリバリーを前提としたアーキテクチャ投資
CI/CDなどのデリバリー自動化への投資
プロダクト型開発

リードタイム

頻度は「質」に転化する。

フェイルファストの原理
シリコンバレーでは、Fail Fast (早めに失敗しろ)という言葉がよく言われる。
さまざまな試行錯誤があってこそ、イノベーションを生むのだという話として表層的に捉えられていることが多い。
モダンなソフトウェアプロダクト開発においては、まさにこの「早めに失敗する」という原理に基づいて様々な技術/文化が発達し、その結果強靱で強力、高品質なプロダクト開発が行われている。

© rector.inc

60失敗から学ぶ ≠ とりあえずやってみる
失敗するかも知れないことをやるというよりも、失敗そのものを積極的に生み出す

早く失敗しろ失敗から学ぶ

何でもかんでも闇雲にやる

早く失敗しろ失敗から学ぶ

失敗が早期であればプロジェクトの被害は軽微フェイルファストの原理から導かれる文化
早期に”低コスト”で失敗を引き起こす仕掛けをつくる
失敗から”次の行動”が導けるような仮説思考に基づくそれらを組織的にスケールできるようにするフェーズ毎の「フェイルファストの原理」
経営と組織文化

プロダクトマネジメント

開発中

リリース後

心理的安全性の投資

仮説法的なNSM

静的型/型推論の発展

コンテナ化 / k8s化

リアルオプション戦略

リードタイム最適化

CodeClimate/ Linter

継続的デプロイメント透明性あるOKR

システム思考Churn analysis/静的解析

Blue Green Deployment

仕事の明確化

データ駆動な仮説構築

Security Shift Left

Feature Toggle

コアの内製化ユビキタス言語の管理

DevOps / DevSecOps

Dark Launch

失敗の予算化

仕様の直交性Microservices

サーキットブレイカー

発信のオープン化

形式手法等の仕様検査技術

ユニットテストとCI

フォルトインジェクション

フェイルファスト

優先順位算出の明文化

API駆動開発

カオスエンジニアリング

Trunk Based Development

Infra as Code

マインドの育成エンジニアリングが導く未来の組織エンジニアリング組織の変化
職能別組織

事業部組織

事業部

CEOCEO事業部

技術組織

ユニット型組織

事業部

横軸組
織

プロダクトチーム
プロダクトチームビジネス組織
技術組織

ビジネス組織プロダクトチーム組織の「エマルション」が進む
ソフトウェアを事業に生かしていくことが当たり前になるにつれて、組織の中で溶け合う

外注型組織

職能別組織

事業部組織ユニット型組織

文字とコード。民主化するプログラミング
かつて、文字が書ける書記官は高給取りで人材不足と言われていた。

文字がかける書記官

コードがかけるエンジニア

異なる要素の境界面に争いは生じる。
溶け合った後には、争いは生じない。

一昔前の働き方って「非人間的」？
「仕事が奪われる」そのとき、どんな仕事が奪われているのでしょうか。

白物家電のない生活

工場制手工業未来からみると私達の働き方は「非人間的」。

働き方の変化はなぜ起きているか。
少ない労働力でより多くのことをコンピュータに任せて仕事をしていく必要がでてきている。

労働力が希少にコンピュータが安く大量にコンピュータに働かせる領域を増やしヒトが働く領域の価値を上げる。

人からコンピュータに置き換わっている
旧来型組織

現代的ソフトウェア企業

人からコンピュータに置き換わっている
旧来型組織
均質なチーム

現代的ソフトウェア企業
多様なチーム目的と手段のはしごが置き換わっていく
不確実性が小さい”手段”の領域からコンピューターが置き換えていく
不確実性大

不確実性小

目的

手段

目的

手段

目的

手段

目的

手段

目的

手段

人からコンピュータに置き換わっている
旧来型組織

現代的ソフトウェア企業変革( Transform the Business)

変革( Transform the Business)

成長( Grow the Business )成長( Grow the Business )運営( Run the Business)

人からコンピュータに置き換わっている
旧来型組織

現代的ソフトウェア企業

官僚型職能別組織

全体論的多様性のあるチーム

コマンド＆コントロールの目標管理

権限委譲と透明性のある OKR型目標

メンバーシップ型人事制度

ジョブディスクリプション型人事制度

不確実性に適応する力が求められる。

2020年版ものづくり白書

経営学とソフトウェア工学をわけて考える時代の終わり。

社会のソフトウェア化が進むと人間には本質的なコミュニケーション能力が求められてくる。