広木大地のレビュー一覧

■感想
ソフトウェアを作っていると色々と曖昧なもの・ことに出くわすが、それらを「不確実性」として説明しており、自身の経験と照らし合わせても納得できる論が多いと感じた。

■参考になったこと
・エンジニアリングは不確実性を減少させる活動
・不確実性＝①目的不確実性、②方法不確実性、③通信不確実性
・行...続きを読む動は外部から観察可能、状態は観察不可能。「考える」は行動、「悩む」は状態
・プロジェクトマネジメントとプロダクトマネジメントの違い（目的と対処すべき不確実性が異なる）

不確実性マネジメントについて拾い読みした。学びはあったが、出典が明記されていないため著者の意見と一般的な話の見分けがつかないこと、他の文献を読んでの学習が難しいことがマイナス。

スケジュールの最善ケースと最悪ケースの幅が、スケジュール不確実性である。このスケジュール幅を可視化して効率よく削減してい...続きを読むくことが重要。最後になって初めて幅が大きいと分かるのが最悪。

多点見積もりから求められる不安量＝見積もり偏差が大きいタスクから順に問題解決することで、スケジュール不安を早期に減らすことができる。

不安量の大きいタスクを、不安量の小さいタスクに分解することで、不安量を減らしたり、不安部分のみを切り出して先に対処するなどの対策が打てるようになる。

エンジニアリングと経営の両面から、組織がどのように利益や目標を追求すべきか/できるかを説いている。数的モデルも登場し、説得力があるように感じた

エンジニアリングの組織において生産性を高めたいので、読みました。エンジニアリングは不確実性を減少させる活動であるという定義はしっくりきました。ソフトウェアの開発は不確実性が最大の状態から、情報を積み上げてそれを削減していく。計画についても、間に合わせるではなく、完了予定を確定させていく、という考え方...続きを読む。アジャイルをするではなくアジャイルになる。ちゃんと計画・設計し、かつ仕様変更に対して俊敏に適応する。それでいて意思決定は遅らせる。プロジェクトにおいて不確実性の観点で優先順位を見極め、よいタイミングで確定させていく。そのためには、実績をもって見積り、計画を立てる。

組織における情報の透明性、
開発における見積りの不確実性を解決しようとしたときに、
どういうことを考えていけばいいのか、
最初の一歩の踏み出し方を教えてくれる本な気がしました。

どの章でも、どの問題でも、
まずは何がわかっていて、何がわかっていないのか、
無知の知ではないが、わかっていないことを知...続きを読むることを基礎としている気がします。

組織のマネージメントを考えたときに、
この本を読むことで知識の整理、行動の促進、自身の立ち位置の把握と、
振り返りを生むことが多い本だと思いました。

（以下抜粋。○：完全抜粋、●：簡略抜粋）
●「エンジニアリング」とは一体何でしょうか。
（中略）
私たちは、自分たちが日々行っている「エンジニアリング」とは一体何なのかをよく知らないということです。
（中略）
エンジニアリングとは、つまるところ、「実現」していくための科学分野だといえるでしょう。（P.10-11）
●不確実性コーン。プロジェクト初期においての見積もりは、見積もりに対して4倍から1/4の範囲で誤差があります。後半になればなるほどその誤差は減ります。つまり「実現」するエンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方なのです。（P.12）
●シャノンは、不確実性の量をエントロピーと呼びました。例として天気として、明日は晴れか雨だけだとします。明日は晴れが50%（雨が50%）の場合1bit、晴れが80％（雨が20%）の場合0.72bit、晴れが100%（雨が0%）の場合0bit。（本にはエントロピーの式がある）発生する確率が偏っているほど、不確実性の量は減っていくことがわかります。（P.15）
○全体論とシステム志向は、「人は、問題を個人の責任にしたり、全体像を見失った局所的最適な思考をしてしまう」ので、それが全体像ではないかもしれない、問題は関係性にあるのではないあかという視点と問題解決のための目を提供し、行動を促すものでした。（P.67）
○「情報の非対称性」と「限定的理性」、この2つが、組織における人間の不完全さを加速させ、組織に忍んでいる理不尽の増幅装置となってしまうのです。（P.69）
○「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それを隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るわけではありません。（P.72）
●メンターとメンティの関係性の条件。
・謙虚：お互いに弱さを見せられる
・敬意：お互いに敬意を持っている
・信頼：お互いにメンティの成長期待をもっている（P.81）
●「悩む」と「考える」の違い
（中略）
「悩んでいる」というのは、頭の中に様々なことが去来し、ぐるぐると思考がめぐり続け、もやもやが取れない状態だと考えています。
（中略）
この状態になったときには、サポートが必要dふぇ、共に考えるための戦略を立てていく必要があります。（P.87）
○メンターは、メンティの問題を直接解くことはできません。メンターができることは、問題を「簡単な問題に変換する」ことだけです。（P.96-97）
●認知フレームを発見する「キーワード」（P.101）
（それぞれの系で抜粋。相手の裏側を考えるのに非常に有効に思える）
こちら系　：この会社　：同じ側にいるように思えるが、実は一体感を持っていない。
あちら系　：あの部署は：同じくくりにいるはずなのに、向こう側と線引きしている。
極端系　　：いつも　　：ゼロ一で、グラデーションなしの物事判断
すべき系　：～すべき　：「～すべき」という枠組みの中で限定的に考えている
決めつけ系：どうせ　：感情的に決めていて、事実確認なしで推論している
●承認（アクノレッジメント）の3つの段階（P.112）
存在承認：挨拶を始め、相手がここにいることに対するメッセージ。
行動承認：行動に対して言葉で出して伝える。例えばほめること。
結果承認：できあがったものに対して主観を込めて伝える。ほめるより広い範囲への承認。
○マネジメントとは、対象となる○○の資源・資産・リスクを管理し、効果を最大化する手法（P.136）
○「アジャイル」状態とは、具体的にどのような状態でしょうか。それは以下のような状態のいのことを意味しています。
・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクを取れていて心理的安全性が高い
・課題・不安に向き合い不確実性の削減が効率よくできている
・チーム全体のゴール認識レベルが高い（P.141）
●SECIモデル（P.151）
共同化・表出化・連結化・内面化という各フェーズを繰り返していくことで、知識というものが発展的に組織的に蓄積されます。
・共同化：組織において共通の経験を積み重ねることで、暗黙的な経験的な知識が共有されているフェーズ。共同化を促すためには、経験や思い、信念などをストーリーテリングする場が必要になる。
（異なる人が独自に実施）
・表出化：体感的で明文化されていない経験的知識の共通点や抽象的な構造・類似点を見つけモデル化していく工程。これはメンタリング的な対話によって引き出されていく。
（構造化、類似点の抽出によりモデリング、文章化）
・連結化：複数の形式的な知識を積み重ねて、1つの知識体系を作るフェーズ。そのためには、形式知を共有・編集・結合させるような場が必要で、Wikiなどのシステムはそのようなことを目的としている。
（Wikiなどによる凝縮して他の人ができるようにする）
・内面化：形式知として生まれた知識体系を知識として覚えている状態から、実践や行動を通じて、体感的・身体的に「理解できた」という状態に変えるフェーズ
（文書化された知識を実践や行動に移すが、ゆっくりと見ながらでもよい練習している状態）
○「見積り」について考えてみましょう。ソフトウェア開発は同じことを二度と繰り返す必要が基本的にないので、毎回どこかしら初めての作業になります。そのため、作業見積もりというのはいい加減なもので、正解とは限りません。ですが、作業実績であればどうでしょうか。これは過去の実例なので正確な数値です。これをもとに将来を見通すほうが、より正確になるはずです。（P.177）
（アジャイルに限らず予測と実績を取得しておくことで、初めて改善できる。やるやらを考える時にも、なんのためにやるのか、測定できる何が改善されるのかを考えないといけないということ。）
○プロジェクト型チームはレスポンスタイムを最適化する。
プロダクト型チームはスループットを最適化する。（P.179）
●見積りは、あくまで予測です。しかし、この予測を「ノルマ」として扱ってしまった場合、それが達成できないときに能力や評価の問題にされる可能性が出てしまいます。
（中略）
予測を「ノルマ」にした途端、それを達成するための過負荷な労働が生まれ、クオリティは下がってしまいます。あるいは、スケジュールの予測精度はどんどんと下がってしまいます。このようなことを避けるために、エンジニアは次からは防衛的で悲観的なケースで見積りを行うとします。（P.190）
●2点見積り、3点見積り（P.193）
●エピック→テーマ→ストーリー→タスク（P.208）
○すでに成功しているビジネスであれば、公開されている情報からでもリーンキャンバスを再現することはできるでしょう。成功しているビジネス10個程度ピックアップして、そこからリーンキャンバスを想像するという練習を繰り返すと、プロダクトのもつ本質が見えてくるようになります。
　仮説検証における仮説は、十分な情報があるところとから導かれる正解ではありません。わずかな痕跡からでもよいのではっきりとした具体的なイメージをもつことで、はじめて仮説と現実の違いを認識することができます。（P.220）
○技術的負債は「見ることができない」（P.256）
●技術的負債というと抽象度が高く見ることができないが、解決方法を調査検討することで何が問題が見えてきます。見えてこればそれはただのタスクでしかありません。（P.264）
●システム外注における取引コスト
・探索のコスト：クオリティの高い外注先を探す、関係を構築するコスト
・交渉のコスト：契約条件をまとめるコスト
・監督のコスト：品質の監視、維持、検収をするコスト（P.276）

個人、チーム、組織それぞれの枠組みについて、不確実性を低減する（わからないことをわかるようにする）考え方に基づく適切な思考ツールを整理している感じだった。

一部の人だけでなく、全員の考え方を変えていかないと運用は難しそうなので、本書を読むだけでなく、ワークショップを開催するなどの意識合わせが必要に...続きを読むなると思う。

メンタリング（メンター、メンティ）について失敗例、成功例それぞれ詳しく説明されてるのはよかった。

読む人の立場によって関心ポイントが違いそう。

不確実性の解消方法という観点で戦略を整理する考え方は合理主義だなと思ったけど、経験主義的に運用するのが大事だなと。

全く予想してなかった思ったよりアカデミック寄りでした。でも全てを不確実性と向き合うためと考えるのはとても腑に落ちる。やはりマーケット不安重視のプロダクト向き組織とスケジュール不安重視のプロジェクト向きに組織での差が納得できた。興味があるセクションとあまり参考にならないセクションの差が激しかったものの...続きを読む読んで良かった。参考になった。

「エンジニアリング組織論への招待: 不確実性に向き合う思考と組織のリファクタリング」　広木大地　★★★★☆

前半は非常に面白かった。後半はすこしキツかったかな。
「アジャイル VS ウォーターホール」という図式自体が違うということは、目から鱗が落ちる思いだった。
アジャイルは方法論ではなく、状態な...続きを読むのだ、その状態を作るのが「経験主義」や「仮説思考」。まずやってみて、わからないことを減らすこと。
チームリーダーの諸君に読んでいただきたい一冊。
#引用
・わたしたちは「わからない」もの（「未来」と「他人」）に向き合うことを避けてしまうという習性がある。
・「わからない」ということは、それだけで自分自身を脅かす可能性を考えてしまう（「不安」）。そのようなものに、人は本能的に「攻撃」か「逃避」を選択してしまう。
・エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移行していく過程に行うすべてのことです。不確実性を下げるということは、つまり、「情報を生み出すこと｝にほかならない。
・「怒り」に変わる感情の、その原初的な思いは、気づ付けられたことによる「悲しみ」であって、それを伝えない限り、どんな理屈をこねて、正当化しようとしても相手の行動を変えることはできない。
・経験主義は、わからないを行動に変換し、一歩でも正解にたどり着くための思考の補助線なのです。
・経験主義は、自分のコントロールできるものを通じて、観測できるものを改善する発送です。
・仮説思考は、限られた情報の中から、大胆にモデルを推論し、そのモデルの確からしさを発見するための行動を促す思考様式です。
・コードレビューにおいては、「なぜ、そのようにしたのか？」ということを問いながら、できれば、その人自身が指摘のポイントに気がついてもらうことを促せるのがベストです。時間がなければ「自分はこっちのほうが、こういう理由でよいと思うけど、どう思う？」のように修正案をつけて、相手に考えさせるのが大切。
・人から与えられた説得による知識を「他者説得」、自分自身で気がついたことを「自己説得」といいます。メンタリングでは他者説得よりも自己説得を重視し、その獲得を促します。
・「考える」は行動で、「悩む」は状態なのです。「行動てきていないとき」は「悩み」を聞き出し、気づきを促して「考える」に変えていく必要があります。
・ポジティブな話を聞くときは早く細かくうずき、ネガティブな話や感情への共感を示すときは、ゆっくり深くうなずく。
・「共感」は「相手がそのような気持ちになった理由を理解する」ことです。
・「同感」は「自分が相手と同じ気持ちになること」でうす。
・傾聴において示すべきことは、「共感」であって「同感」ではない。
・能力は習慣の積分、習慣は行動の積分。習慣が能力に変われば、成果につながり、成果は自身となって次の行動を強化してくれます。
・アジャイルは”俊敏な”という形容詞であって、名詞ではない。「Do agile」ではなく「Be agile」。アジャイルは”する”ではなく”なる”。状態のこと。
・「アジャイルな」状態とは ・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクをとれていて心理的安全性が高い
・課題・不安に向かい合い不確実性の削除が効率よくできている
・チーム全体のゴール認識レベルが高い

・アジャイルソフトウェア開発宣言は「顧客との協調」「個人との対話」「動くソフトウェア」「変化への適応」を重視すべき
・不確実なことを減らすには、一番不確実なことから確かめていくこと。そうすれば、早く失敗するので、一番早く問題解決できます。
・システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう。
・組織階層の深さや地理的に離れた複数人が関わるコード、離職者の数、関わっている開発者の人数など、コミュニケーションコストが一般的に多くかかるであろう環境ほど、バグが多くなる傾向が発見された。

何だかエッセイだなという感じ。

アジャイルなチーム、学習するチーム、組織力学などエンジニアが取り巻く不確実性にどのように挑むかが述べてある。
数式で語っているところもあれば、なんだか出典がよく分からない図(筆者の図解?)で説明されている所もあり、説得力が上がったり下がったりして読みにくい。

考え...続きを読むの根底に貫いていることはなんとなくエンジニアには伝わる本だと思うんだけどなぁ。

様々な課題や感情が絡み合って、もつれた問題に対して、さまざまな理論を引用しながら、カテゴライズ、細分化して解きほぐし、解決可能な課題にしていく。個人個人の課題解決から、チーム、プロセス、組織の課題解決ヘと発展させていく。
知らなかった概念が数多く登場し、分かりやすく解説されているが、ちょっと盛り込み...続きを読むすぎて、断片的なイメージだったり、行間を読み解けないところがあって消化不良な感じ。特に中盤から後半にかけての、アジャイルや技術的な負債に関する洞察は、別の書籍に任せた方が良さそうかな。