本書は「はじめに」で述べた通り、不確実性を組織の推進に変えることこそがエンジニアリングの本質と述べました。
そもそもエンジニアリングとは何か、というところに立ち戻りましょう。
エンジニアリング、「工学」とは。
工学とは数学と自然科学を基礎とし、ときには人文社会科学の知見を用いて、公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを目的とする学問である(p10)
つまり、何か役に立つことを作る、「実現」していかなければなりません。
そしてソフトウェアにおける「実現」とは、「なにかよくわかってないふわふわとしたほしいもの」を「目の前に見えるあるシステム」にすることであり、やはり「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです。(p11)と述べている。
ソフトウェア開発の不確実性コーンを例にしながら、実現をする学問であるエンジニアリングとは、不確実を確実に、曖昧を明確にすることが本質だということがよくわかります。
冒頭でも述べているように、エンジニアリングは不確実なことを実現することです。不確実性の発生源で書かれているように、不確実性、つまり「わからないこと」がどこから発生するのか。本書では以下のような分類が行われています。
情報
不安 <----- 不確実性 ------> 確実性
向き合う |
|___________未来 = 環境不確実性 -> 行動と観察
|___________他人 = 通信不確実性 -> コミュニケーション
(p17より)
学力テストと仕事を考える上で重要な観点を3つ紹介しています。
学力テストは「論理的思考」で解けるかもしれないが、仕事は（自分であれ他人であれ）「論理的思考でなくなる」場面があり、必ずしも自分の論理だけで正解にたどり着けないところが決定的に違い、これを「論理的思考の盲点」と呼んでいます。
心理学、認知科学、経済学、組織行動学などに形を変え、マネジメントを行う上での基礎的な考え方になっています(p21)
さて、論理的思考を「正しく」行うためには以下の前提が必要です。
- 事実を正しく認知できること
- 感情にとらわれず判断できること
「論理的に考える」ことに注目すると見えなくなりがちですが、論理的に考えるには、「非論理的に考えてしまう」瞬間を知ることが重要です(p24)
いくら論理を構築する能力が優れていても、自分の認知が歪んでしまえばその能力は活かすことができないというのは確かにその通りだと思います。自分がどういうときにイライラするのか、それとも暗黙の前提を考えてしまっていないか、そういう点に気づくことが大事ですね。
人間の錯覚や認識の間違い。メモ。
- 種族のイドラ ... 人間が本来持っている性質から錯覚や偏見
- 洞窟のイドラ ... 個々を取り巻く環境から、外の世界を知らずに一般的なことと決めつけて理解することから生じる偏見
- 市場のイドラ ... 言葉の不適切な使用から生じる誤解や偏見
- 劇場のイドラ ... 遠投や権威を無批判に受け入れて、誤った考えであっても信じてしまうことから生じる偏見
いずれも、常に「本当にそうか？」を問い続けて、自分で答えを出し続けることが大事ですね。
メモ。ひっかからないように。
- ゼロイチ思考 ... これがダメなら全部ダメだー！
- 一般化のしすぎ ... 主語が大きすぎ
- すべき思考 ... そのまんま
- 選択的思考 ... 心のフィルター、見たいものだけを見る
- レッテル貼り ... 一般化のしすぎのさらにエスカレートしたバージョン
- 結論の飛躍 ... 思い込みなような気がしますね
- 感情の理由付け ... 感情を根拠に自分の判断を正しいとする
- これはちょっと思い当たりますね。。。
自分の知識と行動に整合性が取れなくなったときに認知を歪ませる修正のことですね。
人間の脳が危機を察知し、生命を脅かされることから逃れるときの脳の器官が扁桃体らしいです。この危機から逃げるために「怒り」という感情を発生させるようです。アンガーマネジメントって言葉がありますよね。怒りを感じると、それはもうもちろん論理的な思考なんてできないでしょうから。。。自分はなぜ怒るのかを最近は考えるようにしています。
もちろん大人なので、その場で怒り散らしたりはしませんが、やっぱり怒ることはたまにあります。その場はやりすごしても、帰って家でぶつぶつイライラしています。それってやっぱり自分にとって大切にしてるものをないがしろにされたときなんですよね。
どういうときに自分が怒るかを知っておくことは大切です。
また、この怒りを怒りとしてぶつけるのではなく、悲しみとして他者に伝えるのが有効だとも述べています。
仕事を進めるにはこの2つの考え方が必要であると述べています。
- 足りない情報を自分自身で集め、確かめ、検証、考察し、その結果から解決を行う「経験主義」
- 限定された情報から、全体像を想定し答えを導き出す「仮説思考」
ニュートン以来の科学哲学の根底を支えると同時に、「アジャイル」や「リーン」といった現代的なソフトウェア開発プロセスの基礎的な価値観として参照されています。(p22)
コントロールできるかできないか、観測できるかできないか。この4象限で物事を考え、「やってみなければわからない」だけの論理ではなく、「コントロールできるもの」を操作し、「観測できるもの」の結果をみることでしか、前に進むことができないことを意味しているのです（p42）
仕事は正解が常にあるわけでもないし、情報が最初からすべて開示されているわけでもない。複雑に、システムのように絡み合っていう状態を解きほぐし、学力テストにレベルに"変換"して解く必要があり、それができないから難しいと感じるわけです。
ライフサイエンスやエコロジー、経営学、ソフトウェア開発に至るまで、広い分野で参照されています。(p22)
システム思考で大切なのは、システム全体を正しく理解すること。その考え方が2種類。
- 要素還元的思考（要素に注目）... ロジックツリー
- 全体論的思考（関係性に注目）... ネットワークトポロジ
たいていの物事は「なぜなぜ分析」であるように、ロジックツリーで単純には表せません。にもかかわらず「根本原因分析だ」と言って反省文を書いて、一側面しか見ていない対策をやるばかりに失敗を繰り返すことがあります。
問題解決のための眼を鍛えるための3つの観点。
- 視野 ... あるポイントからその問題を眺めたときに同時に把握できる領域の広さ。広い/狭い
- 視座 ... どこから眺めるか。高い/低い
- 視点 ... どの角度から見るか。鋭さ/凡庸さ
ここまで、エンジニアリングとは何か。そして思考を前に進めるための3つの考え方を見てきました。
- 論理的思考の盲点
- 経験主義と仮説思考
- 全体論とシステム思考
これは人間が本来持っている不完全さに対して、パッチをあてるような考え方です、（p67）
これに加えて、ソフトウェア開発はたいてい複数人のチームで行うため、コミュにケーションという不確実性が発生します。
- 他者理解の不確実性 … 人は他人や事象を完全には理解できない
- 伝達の不確実性 … コミュニケーションが到達するとは限らない
- 成果の不確実性 … 仮に理解されたとしても予想されたように行動するとは限らない
このコミュニケーションの不確実性によって、情報の非対称性を生みだします。また、それぞれが合理的に行動したとしても、全体としては不合理な行動を取ってしまうことを「限定合理性」と言います。（p68）
[https://qiita.com/hirokidaichi/items/195d42ee056ea85a3150:embed:cite]
まずメンタリングとは何か。対話を通じて、メンタリングする人の思考力を一時的に貸し出し、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を促し、成長させていく手法（p75）とある。
なぜメンタリングが必要かというと、ソフトウェア開発で個人が様々な問題にぶつかったとき、個人が本来発揮出来る実力を出せなくなってしまった場合、チームとしての生産性が低下するからだ。だからチームリーダーはチームメンバーを正しくメンタリングする必要がある。
ソフトウェア開発の以下の工程はメンタリングそのものであると言える。
- コードレビュー
- ペアプログラミング
- 障害時ハンドリング
上記のような工程では、メンタリングを受けるひとが成長を促すようなことを入れ込む必要がある。
メンタリングは「自ら考える人材を作る」ためのテクニックである。（p79）
人材タイプを以下の2つにわける。
- 依存型人材
- 問題を与えたれてから考える
- 問題と解決策を渡されてから動ける
- 自立型人材
- 自ら問題を発見し解決することができる
- 問題について、自分事として捉えている
もちろん自立型人材が望ましいが、すべてのひとがすべての分野、仕事について自立型で動いている場合は少なく、その境界を見つけることは難しい。その境界は上司と部下という関係における期待値の問題（p80）であるという。自分自身の「これならいける」というコンフォートゾーンにひとはなかなか変えられることができない。
自分で動いて問題を解決できた->だからもっとやりたい、というポジティブなフィードバックサイクルに入ると自己効力感が増す。逆に、頑張ってやってもすべて否定されるようなことがあれば「どうせやっても無駄だ」と負のフィードバックサイクルにも入るだろう。
メンタリングは自己効力感がコンフォートゾーンを増すように促すテクニックだと言える。
メンターとメンティとの関係には、チームギークに書かれているいる、謙虚・敬意・信頼が重要。
メンタリングは直接教えるティーチングと違い、自分自身で気づいたように思える。自ら獲得した知識のように感じる。だからこそ高い自己効力感を得られる。
他者説得と自己説得の違い。
| 他者説得 | 自己説得 |
|---|---|
| 他人が答えを伝える | 他人が質問で促す |
| 体感を伴なわない | 体感を伴う |
| 理解を確認できない | 行動の変化が発生しやすい |
自己説得、これはコーチングと呼ばれるものだ。質問によって自分で答えにたどり着けることで納得感も得られるし、自分でたどり着いたからこそ行動しようと思えるわけだ。
最後に「悩む」と「考える」の違い。悩むは状態で、考えるは行動。ぐるぐる頭の中で思考が回り続ける状態が悩んでいる状態で、このときにはサポートが必要。一方解決に向けて前向きに分析したり、具体化、抽象化しているときは前に進んでいる状況なのでそのままで良い。メンターはメンティーが「悩んでいる」ことを見抜く事が重要。だから「不安なことはない？」と問うことが重要だ。
さて実際にモヤモヤと悩んでいるひとが動けるようにするためにどのような問いかけをすべきかを考えていきます。モヤモヤしている問題を、「答えはまだわからない」が「明確に次にすべき行動がわかる」ような問題（p88）に変えることができる、そんな問いかけは何か。
そのための3つのテクニックが傾聴、可視化、リフレーミング。
うまく言ったもので、「迷い」「不安」などでいっぱい埋め尽くされてしまっているので、「悩み」になっている（p89）状態のことを水でいっぱいになったコップと表現し、その状態ではいくら助言しても入らない。この迷いや不安を取り除くものが傾聴だ。
傾聴と話を聞くことの違い。それは自分視点ではなく、相手視点に立つことだ。
| ただ話を聞くこと | 傾聴 |
|---|---|
| 「自分の」意見を言う | 「相手の」感情への共感を言動で表す |
| 「自分の」興味のあることを質問する | 「相手の」話の内容を「可視化」する |
| 「自分の」興味のないことには興味がなさそうな素ぶりをする | 「相手の」思考の「盲点」を探索しながら質問をする |
（p90-p91より）
2つめのポイント「可視化」が傾聴から出てきた。確かに傾聴の3要素は重要だと思う。まず「ふむふむちゃんと聴いてるよ」と示し、言っている内容を「つまりこういうこと？」と可視化し、「これってこの場合は考えた？」と盲点に近いところに気づける質問をする。そして「あー確かにーそれは考えてなかった、やってみます！」と行動できる。理想的だ。
いわゆる「ちゃんと聴いてる」感。友人との会話でもリアクションが与える影響は大きい。僕は結構わかりやすい人間なので「全然興味ないやろ」と突っ込まれることも多い。興味ないときは。（笑）
しぐさ、態度、表情、あいづちの1つ1つが相手へ様々な信号を送っていることを自覚する。なかなか自分では気づけないので、他者に指摘してもらうのが良い。
傾聴によって相手に話をしてもらい、共感を示すとだんだん問題が見えてくる。相手の視点を問題に向けさせるために「問題と私たち」という構図にすることを「可視化」と呼ぶ。
また、「感情的に固執してしまっている要素」を引き剥がして、問題が何であるかをはっきりさせていく（p95）工程を「明晰化」と呼ぶ。
ポイントだけ書いておく。
- 事実と意見をわける
- フォーカスポイントを見つけ、問題を分割する
- そもそも何をやっているのか
- ゴールは何か
- わからないとは何がわからないのか
- 選択肢を比較可能にする
- 選択肢は十分か
- 比較軸は何か
- 評価方法は何か
人は個別の認知フレームを持って物事を見ているため、それを変更する「リフレーミング」のテクニックを使って問題を解いていく。
認知フレームを発見する「キーワード」（p101）を列挙する
- こちら系 … この会社、この人、この部署
- あちら系 … あの会社、あの人、あの部署
- 極端系 … いつも、すべて、絶対
- すべき系 … 常識的に、普通
- 決めつけ系 … どうせ、〜に違いない
また、こういったキーワードが見つからない場合でも、前提の「確認」と「取り外し」をする（p102）ことも有効。
- 問題視している点を具体的に聞いていく質問
- 〜が問題なのは、そもそも何ででしたっけ？
- 〜がないと具体的にどう困るんでしたっけ？
- 解決策についての束縛条件を聞いていくような質問
- どうなったら解決されたと言えるんでしたっけ？
- よい解決策の条件は何でしたっけ？
この前提をがなかったらどうなるか？を考えることによってリフレーミングを促す。
また、問題の分割に近いが、問題が何で、そのうちコントロールできるものが何で、何をもって達成したと言えるのかと解きほぐすことも重要。
Googleが2012年に行った同社の労働改革プロジェクトにおいて、チームの生産性と最も強い関係性のある要因として「心理的安全性」があると発表された（p106）
心理的安全性とは
- 対人リスクを取っても問題ないという信念がチームで共有されている状態
- 自分のキャリアやステータス、セルフイメ時にネガティブな影響を与える恐れのなく、自分を表現し働くことができること
この心理的安全性をどう作っていけばいいのか。
「チームが機能するとはどういうことか」によると、心理的安全性を高めると現れるチームへの影響は以下のようなものがある。
- 率直に話すようになる
- 考えが明晰になる
- 意義ある対立が後押しされる
- 失敗が緩和される
- イノベーションが促される
- 組織内の障害でなく目標に集中できるようになる
- 責任感が向上する
いいことだらけだ！
つまり冒頭に出てきた「対人リスク」を考えると、これを言っても人間関係を壊すことはないだろう、と思い、良い点も悪い点も指摘できる状態が望ましい。
メンタリングと心理的安全性の関係を考えると、
- メンティの弱さ・メンティの失敗を開示してもらう
- 自分の弱さ・自分の失敗を開示する
という状況を作り上げていく必要がある（p110）
「怒られてしまうからなかなか質問しづらい」とか、「そんなこともできないの？とバカにされるかもしれない」と不安になっていくようではダメってことだし、逆にメンターから見ても自分自身の失敗や弱さを伝えることで関係を「心理的安全性」のある関係を構築していく必要がある。
- アクノレッジメント：承認
- メンティがした行動に対して、理解をし、受け入れ、感謝を伝えること
- ストーリーテリング
- メンターからメンティへの自己開示
アクノレッジメントには3段階ある。
- 存在承認 … ここにいてくれてありがとうというメッセージ。挨拶をする、笑顔である
- 行動承認 … ポジティブな行動を取ったときに言葉に出して伝える
- 結果承認 … できたものに対し主観を込めて伝える
アクノレッジメントは何をすればいいのか
- ちゃんと挨拶する
- 無視しないで話を聞く
- 相手に感謝を伝える
- 気にかけて話しかける
- 自分本位でなく相手本位で話をする
という、基本的なことが重要（p114）
メンター自身の失敗経験、学習経験をメンティに伝えるストーリーテリングはどういう点で有効なのか。
- 自己開示 … 話すことそのものが自己開示
- 感情の共有 … 感情を伝えることで共感してもらう
- 価値観の共有 … 物語を通じてメンティの価値観を変化させる
- 返報性の原理 … 話してもらったことで、メンティも自己開示しようと思う
対人関係における気づきのグラフモデルのこと。
| 自分はわかっている | 自分はわかっていない | |
|---|---|---|
| 他人はわかっている | 開放の窓 | 盲点の窓 |
| 他人はわかっていない | 秘密の窓 | 未知の窓 |
他者からフィードバックを受けることによって盲点の窓を開放の窓にする。
ストーリーテリングをすることによって秘密の窓を開放の窓にする。
開放の窓の領域を広げていくことで、未知の窓も開かれていく。これが成長を引き起こす。
メンタリングの目的として、メンティが自分で行動できることを目標とし、その手段として傾聴やリフレーミング、心理的安全性について見てきた。ここでは実際にメンティの行動を見て、「内心」を想像するということをせず、どのような行動をしているか、行動に対して言及することの重要性について述べている。
言葉を正しく使うためのSMARTというフレームワークが紹介されている。
- Specific（具体的な）
- Measureable（測定可能な）
- Achievable（到達可能な）
- Related（関連した）
- Time-Bound（時間制限のある）
わかった？のかわりに「できそう？」って聞くなぁ、どっちにしろ意味がないことには変わりない（笑）不安があるかどうかぐらいの確認にはなっている。
いい言葉だ。その通りだと思う。当たり前を増やすことが成長であり、当たり前にするには習慣化するしかない。なんでもそうだ。
メンタリングは自律的な人材を育てるために行うために必要なこと。
- 自分の気がつかなかった問題に気がつくようになる
- 認知の歪みによる感情と問題の癒着を切り離せる
- 答えではなく、次の一手を生み出す行動が取れるようになる
つまるところ自分で自分をメンタリングしていける状態（p127）である。
高いゴールを自ら掲げて、そのゴールによって自分の認知フレームが上に引っ張られる。このゴールの設定が高すぎてもダメだし、コンフォートゾーンにいながらできるような低いものでもダメで、この適切なゴール設定もメンタリングで重要なことである。ゴールには5段階のレベルが紹介されている。（p128）
| レベル | 助動詞 | 意味 |
|---|---|---|
| 0 | wish to be | 願望 |
| 1 | have to be | 義務 |
| 2 | want to be | 欲求 |
| 3 | will be | 意志 |
| 4 | be going to be | 必然 |
レベル1までのゴール認識では認知フレームは変わらない。レベル2ではじめて認知フレームが変わりはじめ、レベル3で行動が変わりはじめ、レベル4になると習慣が変わりはじめるため、このレベルにいることをゴールへのTime Machineに乗った状態と表現している。（p128）
国内ではアジャイル実践者数が圧倒的に少ないが、デンマークのような政府の電子化が進んだヨーロッパ諸国では、政府からのシステム発注自体がアジャイル開発での契約形態でなければ受注ができません。世界的にはアジャイルが主流な開発形態であるといえる状況（p132）だ。
なぜ日本では実践者数が少ないかを考察するにあたって、世界各国の文化的差異を数値によって比較するため、6つの次元で比較されている。
- PVI 権力格差許容度
- IDV 個人主義と集団主義
- MAS 成果主義傾向（男性性傾向）
- UAI 不確実性回避傾向
- LTO 実用主義傾向
- IVR 抑制的か充足的か
これによると日本が最もアジャイル導入の難しい国であるという結果になった。
なぜアジャイル開発が必要かというと、以下の2つの理由があげられる。
- ソフトウェアが大規模化・複雑化
- マーケットの不確実性に対応する
アジャイル開発はウォーターフォールに比べて3倍の成功率で、1/3の失敗率であるという結果も出ており、大規模開発こそアジャイル開発を採用すべきであることがわかる。
また、プロジェクトマネジメントとプロダクトマネジメントについての比較を引用してみよう。（p137）
| プロジェクトマネジメント | プロダクトマネジメント | |
|---|---|---|
| 目的 | 終了すること | 終了しないこと |
| 抱えている不安 | スケジュール不安 | マーケット不安 |
| 対処すべき不確実性 | 方法不確実性 | 目的不確実性 |
「終了」が来るプロジェクトと、「終了」が来てはいけないプロダクト、真逆だ。いずれも方法不確実性と目的不確実性を潰すように進めるが、ウォーターフォール型だと方法不確実性を潰して作っても目的不確実性を抑えることが難しい。だからアジャイル開発は段階的なアプローチによって実験、経験主義的に修正をしていく。
注意が必要なのは「ある時期にリリースされなければ、ビジネス価値が大きく減少してしまうような機能」を開発しているとき。（p139）マーケット不安よりスケジュール不安のほうが大きい場合、ウォーターフォールであれば再度計画に戻るが、アジャイル開発の場合はビジネス価値が大きく損なわれない最低限の機能を最初期に作る。
| 計画駆動 | アジャイル開発 | |
|---|---|---|
| 前提とする不安 | スケジュール不安 | スケジュール不安とマーケット不安 |
| 戦略 | 初期計画の精度を高める | 実験的に徐々に精度を高める |
| 変化 | 変化に弱い | 変化に強い |
| アプローチ | 理性主義的 | 経験主義的 |
（p140より）
プロダクトマネジメントが「プロダクトを終了させないこと」が目的であることから、必然的にプロダクトの価値を継続的に向上させるためのチームをどのように作るのか（p140）に着目することになる。chapter2で扱ったメンタリングの目的が「セルフマスタリー」を得ることから、チームが総体として、チーム自体のゴールに対して高い「ゴール認識」をもち、チーム自体がチームをメンタリングしている（p141）状態である、チームマスタリーである状態を目指す。
よくある言い回しとして、アジャイルを「する」ではなく、アジャイル「である」というのが正しい使い方。「アジャイルな状態」とは以下のような状態を意味している（p141）
- 情報の非対称性が小さい
- 認知の歪みが少ない
- チームより小さい限定合理性が働かない
- 対人リスクを取れていて心理的安全性が高い
- 課題・不安に向き合い不確実性の削減が効率よくできている
- チーム全体のゴール認識レベルが高い
とすると、ウォーターフォールが「方法不確実性」と「スケジュール不安」をスコープにすることに対して、アジャイルチームはそれに比べて「目的不確実性」と「マーケット不安」と、継続するチームマネジメントが対象とする「通信不確実性」と、多くをスコープにしているため、そもそも比較することが間違っている。
エンジニアリングが「方法不確実性」だけではなく、「目的不確実性」「通信不確実性」を減らすものだと理解しすると、「不確実性削減のシステム」を追加することが目的だと言える。
よって、アジャイルな方法論は、このような組織間の「限定合理性」と「情報の非対称性」の解消を試みるアプローチ（p143）である。
アジャイルの思想史を考える上で、デミング博士が来日し、日本に製造業への統計的な品質管理の方法を伝えたという。
| 知識 | 解説 |
|---|---|
| システムの理解 | 企業の製造・消費のプロセス全体をシステムとして捉えて、システムの個別要素の総和ではなく、関係性に着目したうえで、システムのスループットを向上させる必要があるということを示す |
| ばらつきに関する知識 | 測定によって、知識を得るという態度。統計学的な知識をもって、品質のばらつきが発生することと、個別の問題の原因となるものを見つけ出すための知識の両方を意味する |
| 知識の理論 | 知識がどのように得られるのあ、そしてそれをどのように展開していけばよいのかというPDCAに代用されるような組織学習のための知識 |
| 心理学に関する知識 | 特に「内発的動機理論」を強調した。各従業員が、自発的に目的を持って行動することが最も高いレベルの生産性を発揮するという、マネジメントにおける重要な心理学知見 |
デミングの4つの「深遠なる知識」（p145）
この思想が日本で広がり、高い生産性をもたらすようになったのち、アメリカのソフトウェア開発に広がっていった。
1978年、在庫は悪であるという着想から「Just In Time」の思想で、ちょうどぴったり作る方式が考案され、成功した。また方式だけではなく、徹底的に重要員のマインドにこだわった点も新しかった。
そして徹底した無駄の排除と現場須藤による改善であるトヨタ生産方式を秩序立てて、マニュアル化、パッケージ化したものがリーン生産方式だ。
生産方式が経営方法にも応用できるという考えから、ナレッジマネジメントの重要性が知られるようになる。組織における知識の広がりをモデル化したものがSECIモデルである。（p151）
- 共同化（Socialization）
- 暗黙知から暗黙知へ
- 組織において共通の経験を積み重ねることで、暗黙的な経験的な知識が共有されるフェーズ
- 経験や思い、信念などをストーリーテリングする場が必要
- 表出化（Externalization）
- 暗黙知から形式知へ
- 体感的で明文化されていない経験的知識の共通点や抽象的な構造・類似点を見つけモデル化していく工程
- メンタリング的な対話によって引き出されていく
- 連結化（Combination）
- 複数の形式的な知識を積み重ねて、１つの知識体系を作るフェーズ
- 形式知を共有・編集・結合させるような場が必要
- 内面化（Internalization）
- 形式知から暗黙知へ
- 形式知として生まれた知識体系を知識として覚えているという状態から、実践や行動を通じて、体感的・身体的に「理解できた」という状態に変えるためのフェーズ
これを繰り返して知識を発展的に組織内に蓄積していく。
「人間性の尊重」「組織学習の取り入れ」「システム論」「経験主義的」などの新しい価値観をベースとした、変化に対して適応的で「短い期間の工程を繰り返す」特徴をもった開発手法が生み出された。
| 開発手法 | 説明 |
|---|---|
| スクラム | 振り返りのためのフレームワーク。スクラムガイドがある。「計画」と「振り返り」の、Howに関する学習ループと、顧客に対して何を届けていくかのWhatに関する学習ループがある。 |
| エクストリームプログラミング | ソフトウェア開発の現場の仲の暗黙知を形式知とし、カタログ化していくことで生まれた手法。ドキュメントよソースコードを、組織開発の歯車になるよりも個人の責任と勇気を重んじる、人間中心のプロセス。 |
| 適応型ソフトウェア開発 | 「生命科学」「複雑系科学」「最強組織の法則」などをソフトウェア開発プロセスへと取り組んだ試み。「思索/コラボレーション/学習」という要素が重要。 |
| リーンソフトウェア開発 | ムダ（付加価値のないもの）、ムラ（不均一）、ムリ（過負荷な労働、不合理なストレス）を減らす。 |
- 日本は米国に、米国は日本に学んだ結果
- 組織学習をプロセスに組み込んだ
- 複数の軽量プロセスの総称
-
アジャイル開発は決まったプロセスである
-
アジャイル開発では切開をしない
-
アジャイル開発は優秀なメンバーが必要
-
アジャイル開発では中長期計画がない
-
アジャイル開発は開発者に決定権がある手法だ
本章で意識していた言葉の使い分け。（p174）
| 言葉 | 意味 |
|---|---|
| アジャイル | 目的地（ゴール）。環境に適応して、最も効率良く不確実性を減少させられている状態。理想状態なので、決して到達できない地点。 |
| アジャイルなチーム（自己組織化） | 目的地に向かう集団。理想状態に向かって、前進しているチームの状態。ゴール認識のレベルが高くチームマスタリーを得ている。 |
| アジャイルな方法論 | 目的に向かうための考え方。理想状態にチームが向かうために、お互いにメンタリングし、不確実性に向き合い、減少させるにはどうしたらよいか考えるための組織学習の方法論や考え方。 |
| アジャイル（型）開発 | 目的地に向かう特定の移動手段。アジャイルな方法論を取り込んだある具体的なチームで実行されている開発プロセスのこと。移動中に状況に応じて書き換えられ、別のものに変化していく |
| アジャイル開発手法（アジャイルプラクティス） | 移動手段の手引書に書かれていること。アジャイルな方法論を取り入れやすくするためのルールやフレームワークとしてまとめられている手法。多くの場合、状況に合わせてそこに書かれていることも変化させる必要があると書かれている。 |
ソフトウェア開発における不確実性を減らす考え方であり、ゴールがアジャイルである。
- 不安と向き合うこと
- 少人数の対話を重視する
- 役割を分けない
- 経験のみを知識に変える
- 意思決定を遅延する
- 勝ちの流れを最適化する
チームが同一の目的でありながら、チームの内部に二項対立が生まれる場合、そこには「不確実性」が隠れていることを示唆しています。それを対話と熟慮を通じて、対立をそもそもなかった状態に解消するような視点を得て、自分たち自身を再構築していくことを、フランスの哲学者、ジャック・デリダは「脱構築」と呼びました。（p180）
- 3つの不確実性
- 方法不確実性 … スケジュール予測と見積もりの手法
- 目的不確実性 … 要求と仮説検証の手法
- 通信不確実性 … 振り返りの手法
これら不確実なものに向き合うと、ひとは「不安」が生まれ、それを隠してしまう。不安によって隠れた不確実性をリストアップし、それらを比較しなければならない。
スケジュールマネジメントは、予定通り進むようにプレッシャーをかけることや、現場と経営の揉め事をなだめるように考えるひとがいるが、それは違う。効率よく「スケジュール不安」とその発生源である「方法不確実性」を削減するエンジニアリングである。
スケジュールマネジメントは次の３つの注目して改善を行うマネジメントのことである。
- 制約スラックを削減する … 依存関係によって理想工期に比べて発生する無駄のこと
- リソース制約 … 属人化状態
- 依存制約 … 作業間の依存関係、同時並行できない作業
- 調整コストや意思決定
- 見積もりの予測可能性を上げる
- プロジェクトバッファの消費を可視化し改善する
- プリンシパル・エージェント理論
- エージェンシースラック：「嘘をついたほうがトクになる」と思わせてしまうことで、適正価格より高い費用が必要になる、この差額のこと
- コントロールコスト：依頼者の利益が代理人の利益になるように監視やインセンティブの形で支払う必要があるコストのこと
- シグナリングコスト：代理人である情報をもつ側が情報を開示し、非対称性を解消するために支払うコストのこと
見積もりを悲観的にとるか楽観的にとるのかは、エンジニアの不安の量と関係する。不安が大きければ大きいほど悲観的に見積もりをとる。
「間に合うか、間に合わないか」ではなく、「スケジュール予測が収束していくかどうか」を管理しなければならない。
不確実性をリリース予測の幅として表現できれば、スケジュール不安は可視化でき、コントロールできる。「納期」に間に合うか間に合わないか、という観点だとエージェンシースラックが発生し、結果的にその日に間に合わなくなってしまう。
目的不確実性とは「何を作るか」の不確実性のこと。マーケット不安をなくすためにリーンキャンパスを使って仮説検証を行う。
スクラムにおけるイベントは、不確実性をなくすためのイベントである。
-
スプリント計画によってマーケット不安に向き合う
-
デイリースクラムによって情報の非対称性を減らす
-
スプリントレビューでスケジュール不安を減らす
-
レトロスペクティブで方法不確実性を減らす
組織という単位での不確実性の削減を考えていく。
似た言葉である労働生産性は、付加価値額/従業員数で出すことができるが、エンジニアという技術組織の付加価値は計測できず、企業全体で見るとしても、ソフトウェアという性質上簡単にコピーができるので、短期の人員数と売り上げには因果関係があるとは限らない。結果、ソフトウェア企業の労働生産性は「投資フェーズ」では低くなり、「回収フェーズ」では高くなってしまう。そのため生産性という言葉を技術組織の効率性を示す指標には向いていない。
市場の不確実性が大きいほど、情報処理必要量は大きくなる。保有するシステムと組織形態が大きいほど、情報処理能力も大きくなる。情報処理能力が、情報処理必要量を上回れば、組織成果となる。
情報処理必要量は目的不確実性、つまり戦略に一致する。情報処理能力は、方法不確実性（戦術）と通信不確実性（兵站）に値する。
個人の情報処理能力の総和が組織全体の情報処理能力に一致するためには、100%の完全な情報伝達があり、その構成員が完全に同一の目的・思惑で動く必要がある。通信不確実性が存在しない世界でしかありえない。これをコミュニケーションコストと呼ぶ。
組織の人数が増えるほど通信不確実性により、情報の非対称性が発生してしまう。
責任はあるが権限がない状態や、権限はあるが責任がない状態はいずれもうまくいかない。上司と部下の間で認識している権限と責任の不一致が生じると、情報の非対称性が生じ、組織の情報処理能力は低下してしまう。
ポイント。
- 明示的な権限と責任の異常を行う
- 権限と責任の不一致をなくす
- 権限同士の衝突を最小にする
- 権限の衝突解消レベルを最小にする
技術的負債という言葉は、会計上も経営指標においても計上されるわけではない空想上の概念である。経営者にとっては「負債」という言葉には資本としての意味合いもある。そのためエンジニアと経営者で抱くイメージが変わってしまう言葉である。
技術的負債は確かに存在している。システム開発が「何かをできる機能を作る」というここと同時に、「何かできないところを作る」作業であるという理解が必要不可欠である。そのため、システムを積み上げていくと、以前は簡単にできていたことが、難しくなったりすることが発生する。
「見える」「見えない」「プラスの価値」「マイナスの価値」の4象限で技術的負債を定義した。
| 見える | 見えない | |
|---|---|---|
| プラスの価値 | 新機能 | アーキテクチャ |
| マイナスの価値 | バグ | 技術的負債 |
ソフトウェア開発においてマイナスの価値となるもので、見えないものが技術的負債だ。逆の良いアーキテクチャ（設計）が変更に強いソフトウェアを作るのだから、納得がいく。
ここでいう「見えない」はシフトウェア・システムを概観から見ることができないだけであり、エンジニアが内部実装をよく見れば見ることはできる。しかしエンジニアしか見ることができないため、情報の非対称性が、経営者とエンジニアの間で発生してしまう。
つまり、技術的負債はエンジニアチームと経営者の間に存在する認識の差であって、システムの複雑性の増加そのものではないと考えるほうが、より「技術的負債」という言葉をめぐるアプローチとしては適切（p262）である。
経営者が頭の中で考えている「これから追加していきたい機能」はエンジニアには見えないし、「現状のアーキテクチャで追加しにくい機能」は経営者には見えない。エンジニアと経営者はこの情報非対称性があることの認識し、コミュニケーションをとっていかなければならない。
技術的負債は見えないからこそ技術的負債である。これらをコミュニケーション可能な形にすることで、技術的負債を管理可能なものにする。（p265）
-
技術的負債の可視化
-
アーキテクチャの複雑性
- 循環的複雑度の可視化 … コード中のロジックの複雑性
- 依存関係の分析 … モジュールの依存関係・依存度
- コードチャーンの分析 … バージョン管理システムのログ
-
将来要件の不確実性
- 非機能要件の具体化 … 保守性や性能等の非機能要件の具体化
- 仮説・戦略の透明化 … ビジネス的な仮説と戦略をエンジニアにも伝える
- ユビキタス言語の作成 … エンジニアと経営者が共通理解するための用語定義
-
こういったアプローチで、経営者、エンジニア双方歩み寄ることが重要。
プロダクトを内部のリソースで開発するか外部のリソースで使うかについて論じていく。
- 探索のコスト
- 取引相手を見つけるために支払うコスト
- クオリティの高い技術部隊を探すことは難しく、そのための関係構築のコストが必要
- 交渉のコスト
- 取引相手と交渉を行うために発生するコスト
- 監督のコスト
- 取引相手が契約した取引を履行するように監督と矯正を行うコスト
- 品質の監督、クオリティ維持の検収、外注先のマネジメント
企業内部に構成するための「内部化コスト」が高く、市場から手に入れるためにかかる「取引コスト」のほうが安い場合は、企業外部から調達することになる。
しかし実際は取引コストが高くなるため、最近はシステムを内製する組織が増えている。
しかし、すべて内製で作ったとしても、取引コストは０になるのか。前述の定義によればYesである。しかし、結局内部的な組織であっても、各組織が限定合理性をもって、組織どうして調達・交渉・監視という取引コストを支払ってしまっている。これを組織的負債とも呼べる。
実はシステムアーキテクチャと組織設計は「似ている」のではなく本質的に同じものである。
| システム | 企業活動 | |
|---|---|---|
| 動きやすい仕事 | 影響範囲が限定されていて、変更しやすい部分の機能開発 | 権限が異常され、ゴール認識が高い |
| 動きにくい仕事 | 影響範囲が広く、変更しにくい箇所の機能開発 | 権限のレベルを超えて、取引コストが高い |
| 決定要因 | アーキテクチャ | 組織構造 |
アーキテクチャと組織構造はお互いに影響を与え合う。アーキテクチャと組織構造の関係に対して理解し、コミュニケーションを通じて、アーキテクチャと組織構造の両方をビジネスの向かうべき方向に一致する（p293）必要がある。
組織構造も、アーキテクチャも「構造」が与える力は見えづらい。必要なのは妥協でも、政治でも、卓越した技術力でもなく、組織やビジネス、プロセス、そしてシステムへの「エンジニアリング」が必要である、ということで本書を締めくくる。