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

Slide 1

Slide 1 text

エンジニアリング組織論〜不確実性に向き合う組織の現在と未来株式会社レクター/日本CTO協会広木大地

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

皆さんは仕事に対してどんなイメージを持っていますか

Slide 6

Slide 6 text

決められたタスクをこなすイメージ A

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

現在の仕事の多くは何かを”具体化”していくこと

Slide 9

Slide 9 text

仕事は”曖昧”で始まり”具体”で終わる。仕事の「はじめ」と「終わり」を考えてみる。仕事のはじめは何も決まっていなくて、モヤモヤとしている。だんだんと方針が定まってきて、実現されてくる。マニュアルでも契約でもソフトウェアでも、具体的で明確な表現物になって実現される。

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

組織も不確実性の削減するメカニズム社会の不確実性を”喰って”成長する装置が株式会社という生命の構造

Slide 15

Slide 15 text

不確実性を大きく下げるチーム =生産的不確実性という補助線をひくと生産的なチームとそうでないチームの形が見えてくる。 ❶マイクロマネジメント型 ❷エンパワーメントチーム型細かな指示まで上司が行う必要があるチーム曖昧な状態でも行動でき、任せられるチーム

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

より不確実なものから手をつける。クライアントへの確認やイメージの共有、市場リスクなどより危ういものから確認していく 100% 70% 70% 100% 時間クオリティ不確実なものから明らかにするやりかた確実なものから進めていくやりかた

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

1 2 人間が本質的にわからないものは 2つそれが不確実性の発生源となっている。未来：環境不確実性未来のことは誰も知り得ない。だから、不確実性を生み出す。マーケットの不確実性。他人：通信不確実性他人の頭の中を覗き込むことはできない。だから不確実性を生み出す。コミュニケーションの不確実性。

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

不確実性に対して ”たたかう”か”にげる” 攻撃的行動 Fight 回避的行動 Flight or

Slide 22

Slide 22 text

不確実性が脳にストレスをかける不確実性に向き合おうとすると怒ったり、逃げたりする反応が生まれそこからトラブルが生じる不安や恐怖怒りや攻撃回避や防衛不確実性トラブル

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

仕事における不確実性への向き合い早めにやった方がいいはずなのに、つい後ろ倒ししてしまうことはないか。上司に報告をしてフィードバックを受けるすれ違いのある部門との会話をして懸念を払拭する

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

1 3 2 ①心理的安全性のあるチーム ②疎結合なシステムと組織 ③システムの不可視性の可視化と対話他人の不確実性への向き合い方他人の不確実性コミュケーション

Slide 29

Slide 29 text

コミュニケーションとは何か？情報の非対称性の解消こそがコミュニケーション

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

ソフトウェアとコミュニケーションソフトウェアの人文的側面に着目すると立法プロセスのようなコミュニケーションそのもの複数人の認識をそろえながら機械的に処理できるほど明晰な文章を将来の不確実な変化に耐えられるように構成し、共同で継続的に管理する営みソフトウェア開発立法プロセス

Slide 32

Slide 32 text

誤解されがちな心理的安全性 “仲がよい”/”アットホームな”とは全く異なる概念心理的安全性とは    ‘’対人リスクを取っても問題ないという信念がチームで共有されている状態  「間違い」を認めても大丈夫「意見」を言っても大丈夫「助け」を求めても大丈夫 OK! OK! OK! 「ここにいても」大丈夫 OK!

Slide 33

Slide 33 text

心理的安全性は一人で創れるものではないアサーティブな言語化能力と問題解決を適切にファシリテーションすることで生まれる。優しすぎて意見を出せない上司うまく言語化できない部下

Slide 34

Slide 34 text

心理的安全性の四章限如何に意見が言えても、無責任で自分本位の意見だと意味がない。不安ゾーンぬるま湯ゾーン学習ゾーン無関心ゾーン心理的安全性高低高低責任

Slide 35

Slide 35 text

心理的安全性はなぜ生産性を上げるのか心理的安全性はプロジェクトリスクを早期に曝露させる。心理的安全性が高いチームが対人関係リスクをとって議論できるプロジェクトリスクを早期に発見・対応できるプロジェクトが成功する心理的安全性が低いチームが対人関係リスクをとって議論できないプロジェクトリスクに向き合えないプロジェクトが失敗するプロジェクトの不穏な匂い

Slide 36

Slide 36 text

プロジェクトリスクとはなにか。プロジェクトのもつ不穏な匂い (リスク事象ドライバー)がリスク事象を引き起こす。

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

組織のコミュニケーション量組織人数に対してリニアに情報処理能力はスケールしない

Slide 40

Slide 40 text

複雑性の増大に伴う開発工数の増加ソフトウェアの複雑性は、機能の組み合わせの数に比例する。

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

1 3 2 4 ソフトウェア開発の本質的な難しさブルックスの名著「人月の神話 ―狼人間を撃つ銀の弾はない」より筆者によるまとめソフトウェアはその規模に対して複雑さが非線形に増大します。基本的にソフトウェアというものは一度作られたものであれば、再利用できます。そのため、どんな人工構造物よりも複雑になります。複雑性ソフトウェアは、文化・業務・経済環境・商習慣、顧客行動などさまざまな点に連動して、変わり続ける必要があります。当初の計画通りのシステムが出来上がったとしてもそれは利用者の要望により変わり続けます。可変性ソフトウェアは、それ単独で意味を成すものではなく自分自身を動作させるハードウェアや、ネットワーク、OS、その他のシステムなどと連携しながら、同調することで初めて意味をなします。同調性ソフトウェアは、目に見えません。抽象的な概念の相互関係であり、それは一般に技術者にしか理解できない言語で記述されます。そのため、ソフトウェアの構造を他の構造物とは違い見ることができません。不可視性

Slide 43

Slide 43 text

見えないことが技術的負債の性質クルーシュテンの定義によると、技術的負債の性質はソフトウェアにおいて「見えない」「マイナスの価値」のものとなる。技術的負債の四象限ソフトウェアの性質を可視性と価値の正負によって 4つに分類するバグ技術的負債見える見えない新機能アーキテクチャ (開発者体験 ) 出典：フィリップ・クルーシュテン (2012) プラスの価値マイナスの価値

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

1 3 2 ①リアルオプション戦略と仮説検証 ②経験主義的プロセス ③頻度がつくり出す質未来の不確実性への向き合い方未来の不確実性高速な仮説検証

Slide 49

Slide 49 text

仮説法とは何か仮説検証という言葉が人口に膾炙しているが、仮説という考え方が理解されていないわずかな痕跡を元に大胆な予測を行い大胆な推測を行いそれが仮に真である場合証拠をさがす行動をする。

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

1 3 2 ①リアルオプション戦略と仮説検証 ②経験主義的プロセス ③頻度がつくり出す質未来の不確実性への向き合い方未来の不確実性高速な仮説検証

Slide 52

Slide 52 text

理性主義と経験主義わからないことを行動を通して経験し、それを知識として徐々に突き止める =経験主義理性主義的な問題解決  経験主義的な問題解決  わからなかったので、もう一度考えてみよう！わからなかったので、次に何をしたらわかるのか考えよう。

Slide 53

Slide 53 text

経験主義的プロセス固定するもの/変化させるものを反転させて「経験」を得られるようにする。リソース  納期  要求  リソース  納期  要求  固定する変化する 150pt 15pt 10pt 1ヶ月 1ヶ月あとどのくらい？

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

相対見積もりによってバイアスを取り除くタイムスロットを固定し、消費ポイントから期日を予測することで相対見積もりが可能になるリンゴ1個分あの猫は3個分くらいスケジュールコミットが厳しい環境ほど悲観的に見積もる。  コミットが緩い環境や担当者の責任感が強いほど楽観的に見積もる。 

Slide 56

Slide 56 text

見積もりは ”幅を持った予測 ”にする。楽観悲観リスク楽観悲観リスク楽観悲観不確実性をファーストクラスとしてプロジェクト管理の対象にする 1ヶ月後初期 2ヶ月後

Slide 57

Slide 57 text

プロジェクトを形作るものはなにか。プロジェクトのタスクとリスクプロジェクトタスクタスクは、プロジェクトを足し算で評価する。プロジェクトリスクリスクは、プロジェクトを掛け算で評価する。

Slide 58

Slide 58 text

1 3 2 リスクが早期発見されるほど成功する不安の大きい要素から先に取り組む。早めに関係者にプロトタイプやできたものを見せる。本番システムをつかって早期に検査する。逆に後半でリスクが爆発する方が問題が大きくなる。プロジェクト早期から、リスク要素に真正面から向き合うには、チームのコミットメントと心理的安全がなければむずかしい。

Slide 59

Slide 59 text

プロジェクト終了確率は対数正規分布足し算の世界は、正規分布に近づく。掛け算の世界は対数正規分布に近づく。正規分布対数正規分布

Slide 60

Slide 60 text

プロジェクト大規模化がリスクを増やすそのため可能なら小さな単位に分割したい。

Slide 61

Slide 61 text

プロジェクトスコープを小さく保つ規模が小さいとタスクの足し算の要素が支配的になり、大きいとリスクの掛け算が支配的になる正規分布対数正規分布大規模化細分化リスクの裾野が長くなりコントロールしにくくなる。

Slide 62

Slide 62 text

見積もり、コミットメント、ターゲット見積もりは本来は確率分布の形をしている。見積もりとして、表現されたものが 50％で完了するラインであれば楽観的な見積もりだし、 99%であれば悲観的すぎる見積もり。何%で終わる見積もりなのか。

Slide 63

Slide 63 text

見積もり、コミットメント、ターゲット見積もりを人々が口にするときに 3つの観点がバラバラなときトラブルが起こる。コミットメントはチームの努力目標。見積もりは確率分布。ターゲットはビジネスとして必要な時期。 60% 80% 努力目標はあったほうがいい。でも、外部に約束する時は、普通は十分な確率を見越して設定しないと企業価値が損なわれる。

Slide 64

Slide 64 text

1 3 2 ①リアルオプション戦略と仮説検証 ②経験主義的プロセス ③頻度がつくり出す質未来の不確実性への向き合い方未来の不確実性高速な仮説検証

Slide 65

Slide 65 text

ドラム式自動洗濯機の ”良さ” 新しい「当たり前」となる習慣の価値は、使う前にはわからない。手洗いの方がよく落ちるよ全自動は信用できない干すのは手間じゃない洗剤は自分で入れる

Slide 66

Slide 66 text

フロー効率を高める技術的投資継続的デリバリーを前提に自動化や効率化を徹底的に進めることで品質と価値効率を最大化する開発テストリリース開発リードタイムリードタイムプロダクト型プロジェクト型 CI/CDなどのデリバリー自動化への投資継続デリバリーを前提としたアーキテクチャ投資頻度は「質」に転化する。

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

失敗から学ぶ ≠ とりあえずやってみる失敗するかも知れないことをやるというよりも、失敗そのものを積極的に生み出す何でもかんでも闇雲にやる失敗が早期であればプロジェクトの被害は軽微早く失敗しろ失敗から学ぶ早く失敗しろ失敗から学ぶ

Slide 69

Slide 69 text

フェイルファストの原理から導かれる文化早期に”低コスト”で失敗を引き起こす仕掛けをつくる失敗から”次の行動”が導けるような仮説思考に基づくそれらを組織的にスケールできるようにする

Slide 70

Slide 70 text

フェーズ毎の「フェイルファストの原理」経営と組織文化プロダクトマネジメント開発中リリース後心理的安全性の投資リアルオプション戦略透明性ある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

Slide 71

Slide 71 text

エンジニアリングが導く未来の組織

Slide 72

Slide 72 text

エンジニアリング組織の変化職能別組織事業部組織ユニット型組織 CEO ビジネス組織技術組織事業部ビジネス組織技術組織 CEO 事業部事業部プロダクトチームプロダクトチームプロダクトチーム横軸組織

Slide 73

Slide 73 text

組織の「エマルション」が進むソフトウェアを事業に生かしていくことが当たり前になるにつれて、組織の中で溶け合う職能別組織  事業部組織  ユニット型組織  外注型組織 

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

一昔前の働き方って「非人間的」？「仕事が奪われる」そのとき、どんな仕事が奪われているのでしょうか。白物家電のない生活工場制手工業

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

コンピュータに働かせる領域を増やしヒトが働く領域の価値を上げる。

Slide 80

Slide 80 text

労働の移転：人から計算機へ旧来型組織   現代的ソフトウェア企業  

Slide 81

Slide 81 text

労働の移転：人から計算機へ旧来型組織   現代的ソフトウェア企業   均質なチーム多様なチーム

Slide 82

Slide 82 text

目的と手段のはしごが置き換わっていく不確実性が小さい”手段”の領域からコンピューターが置き換えていく目的手段目的手段目的手段目的手段目的手段不確実性小不確実性大

Slide 83

Slide 83 text

労働の移転：運営から成長への仕事の変化旧来型組織   現代的ソフトウェア企業   運営( Run the Business) 成長( Grow the Business ) 変革( Transform the Business) 成長( Grow the Business ) 変革( Transform the Business)

Slide 84

Slide 84 text

労働の移転：成長する組織の仕事のあり方旧来型組織   現代的ソフトウェア企業   官僚型職能別組織コマンド＆コントロールの目標管理メンバーシップ型人事制度全体論的多様性のあるチーム権限委譲と透明性のある OKR型目標ジョブディスクリプション型人事制度

Slide 85

Slide 85 text

不確実性に適応する力が求められる。 2020年版ものづくり白書  

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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