あらすじ
「コミュニケーションにおける不確実性を減らすには？」「技術的負債を解消する方法とは？」「経営陣とエンジニア間の認識のずれを解消するには？」
エンジニアリングにおける課題を解決する思考の整理方法やメンタリング手法を，さまざまな企業の技術組織アドバイザリーを務めている著者が解説。
若手を戦力として育て上げ，成長する組織を設計・運営するためにおすすめの1冊です。
感情タグBEST3
Posted by ブクログ
エンジニアリング組織がある場合には、営業を含め必読の本
人間が作り上げる組織ということを前提に組織マネジメントの要諦が表現されている。
不確実性を下げ、内発的動機をドライブし、本来の目的に立ち返った開発組織を作っていくために大半示唆に富んだ本
Posted by ブクログ
期待以上によかった。もう7年前になるが古びていないしシステム開発以外の仕事や日常生活でもハッとさせられる言葉が満載
P11 「理学」が物理学や化学のように世の中の自然の原理を見つけて、説明していく学問であるのに対して「工学」はそれらに依拠しながらも「何か役に立つものを」「実現していく」学問です。エンジニアリングとはつまるところ「実現」していくための科学分野だと言えるでしょう。
P19 学力テストは普通、論理的な思考を用いて行います。しかし人は、論理的思考を常に正しく運用できるわけではありません。とりわけ、他人が介在する問題について、わたしたちは感情的にならざるを得ない生き物です。仕事は通常、複数人で行います。そのため、人間関係や他人との共同作業をしていくうえで、意識的、無意識的に感情的になることがままあります。これを乗り越えて、問題を正しく認知する必要があります。
P37 わたしたちは、物事に取り組むときに、つい「どうやるか、どのくらいで終わるか」がわかっているような仕事を優先的に好んで行いがちです。そうすると、最後のほうに「道や廊下、どのくらいで終わるのか」わからないような不確実性の高い課題ばかり残ってしまい、完了時期がいつまでたってもわからないというような結果になってしまいます。これは、プロジェクトマネジメントにおいても同じことが言えます
P41 重要なのは、本来コントロールできないはずのものをあなたの行動で変化させようと試みる時には、その対象が「観察できる」必要があるということです。なぜなら「観察できない」ものはどんなに行動したとしても変わったのか変わらないのかわからないからです。
P65 問題解決のための眼、それは「視野」（広い狭い）「視座」（高い低い）「視点」（鋭い凡庸）の３つに分類できます。
P122 （何かを説明したときに「わかった？」と聞くのは）まったく意味のない行動だったと悟り、意図的に減らしていくようにしました。【中略】観測可能な行動を通じて理解を確認するには、たとえば「試しに一人でこれをやってみて」であるとか「代わりに自分の言葉で説明してみて」と行動を促すような方法があります。
P123 わたしがよく使う言葉として「能力は習慣の積分だ」というものがあります。習慣とは行動が染みついたものです。そのため「行動」や「習慣」は外からでもメンタリングの方法論を用いて成長を促すことができます。（習慣は行動の積分。習慣が能力に変われば成果につながり成果は自信となって行動を強化していく）
P136 プロジェクトは「はじめ」と「終わり」があり、それが高価をあげて「終了すること」が目的です。それに対して、プロダクトは「製品・サービス」ですので、そのプロダクトが継続的に収益を上げて損益分岐点を越えて発展することで「終了しないこと」が目的になります。【中略】このようにプロジェクトマネジャーとプロダクトマネジャーは本質的に異なる不安に対してアプローチする存在であるという違いがあるわけです。
P157 「合理的な理解」よりも「体感的な習熟」
P172 米国における俗語に「クールエイドを飲むな」という言葉があります。（誰かの思想信条を無批判に受け入れるな）【中略】アジャイルという言葉が誤解されている理由には、こうしたクールエイドを飲んでしまった人々にも問題があります。
P182 時間は、経営における重要な資源です。このことは一概に「早く終わる」ことが重要であるという意味ではありません。「どのくらいの時間がかかりそうなのかを、できる限り正確に知ることができる」ことが重要であるということを意味しています。
P210 本来、ソフトウェアプロダクトを提供する事業において「その日」にリリースされていないといけないという制約は、意図的に作らない限り生まれません。むしろ、本来のビジネスを総合的に考えると「何を作るのか」「それは市場に受け入れられるのか」といった不安がはるかに大きいウェイトを占めるケースのほうが多いのです。しかしスケジュール不安の大きい開発者と経営者という関係性がある場合には、まずはその「情報非対称性」を取り除くことが重要です。スケジュール以外にも重要なことがあるのだということを、お互いに気が付く必要があるからです。
P216 最初に構築した仮説から、一番の不安材料となるものを洗い出し「不確実性を下げられる存在」つまり顧客に当ててみることで初めて、仮説の不確実性が削減されます。（目的不確実性が下がっていくと大きなコストをかけられる 仮説構築⇒ユーザー調査⇒プロトタイプ検証⇒MVPリリース⇒小規模マーケティング⇒大規模マーケテイング）
P220 不確実なことを減らすには、一番不確実なことから確かめていくことです。そうすれば早く失敗できるので、一番早く問題解決できます。エンジニアリングとはそういうことです。それは「言うは易し行うは難し」の典型例とも言えます。【中略】人間には恐怖から逃げる仕組みが用意されているのでなかなか抗うことができません。「一人でできないのであれば複数人でやればよい」と考えると少しだけこのことが簡単になります。現実を直視し、不安に向き合えるようにチーム全体が個々人をサポートしていく状態になれば、仕事における不安に向き合うことができるようになります。⇒不安に向き合うフレームワークとしてのスクラム
P243 権限移譲のレベル
レベル１ 上司が部下に命令する ２上司が部下に説得する ３上司が部下に相談する ４上司が部下と合意する ５上司が部下に助言する ６上司が部下に尋ねる ７上司が部下に委任する cfデリゲーションポーカー
P250 （カニンガムの提唱した）「技術的負債」という言葉は、会計上も経営指標においても計上されるわけではない空想上の概念に過ぎません。「技術的負債」という言葉の定義もあいまいで、何をもって技術的負債ということができ、何を持って測定され、どのような返済手段があるのかといった議論も尽くされることなく、広く用いられるようになりました。その結果「技術的負債」という言葉の存在で何かを説明したと思い込む人々や、ソフトウェア開発における経営上の問題について関心を抱かない経営者によってむしろコミュニケーションを断絶する言葉になってしまっているケースがあるように思います。
P276 システム外注における取引コスト＝探索のコスト（外注先選定にかかるコスト）交渉のコスト（契約条件を決めるために必要なコスト）監督のコスト（外注先をマネジメントするコスト）
P277 （企業のコアコンピタンスとして内製で持つものと一時的に必要な機能や周辺領域を拡大するために外注するものの）線引きをシステムの構造（アーキテクチャ）として持つことで、上手に取引コストをコントロールできます。
P286 機能横断型組織＝新しい知見が生まれやすくなりビジネス上の意思決定が早くなる＝知の探索/機能別組織＝特定の領域の効率を上げていく＝知の深化
全ての業種においてこの「知の探索」と「知の深化」のバランスの見極めが必要です。
Posted by ブクログ
最後まで密度の濃い、目から鱗の内容であった。
エンジニアリング、メンタリング、アジャイル、など、フワッとした言葉を、明確に定義付けし、府に落ちた。
少しでも行動に移していく。
以下メモ。書ききれない。。
・エンジニアリング:実現のため不確実性の低い状態に効率良く移す全ての過程(不確実性の削減)18
・問題が解けないのは、問題が正しく明晰に記述できていないため。解決よりも先に、問題をはっきりさせる。経験主義の考え方と仮説思考が重要。21,50
・不確実性の高い物を優先して取り組む。効率よく不確実性を下げるプロセス。やりたくないもの。37
・出来ること:コントロール出来るものを操作し、観測できるものの結果を見る(経験主義)。42
・良いプログラムとは:視野、視点、視座を広く、鋭く、高く置いている。65
・コミュニケーションがうまくいかないのは、「情報の非対称性」と「限定合理性(極小最適)」が存在。
コミュニケーション能力:不確実性を減少させる能力
情報の透明性:意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるための取り組み。情報公開とは異なる。72
・・・
Posted by ブクログ
経営理論や組織開発のエッセンスが概ね網羅されている上に、個人でできることを起点に組み上げられていて実践しやすい。
著者の深い実践知が垣間見える名著。
Posted by ブクログ
エンジニア向きなタイトルではあるが、Chapter1と2は組織のマネジメントや不確実性を低減する思考法について書かれており組織のマネージャーにおすすめの内容。
Posted by ブクログ
まず、アジャイルやスクラムが何のために必要なのかを端的にまとめられている。また、不確実性や技術的負債といった曖昧に語られる言葉について分析、紹介している点、情報の非対称性から発生する限定合理的な行動という切り口からエンジニアリング組織に起こりがちな問題について説明している点など、良い点を挙げればキリがない。
エンジニア組織に関わるすべての人に読んでもらいたい一冊。
Posted by ブクログ
個人から組織まで様々な視点で抽象的なことから具体的なことまで書かれていてとても良かった。ベスト本です。エンジニア組織に関わる人なら全員読むべき本だと思いました！
Posted by ブクログ
不確実性が高いプロジェクトをどのようにドライブするか、各要素ごとにかなり丁寧に書いてある。
私はチームメンタリング部分を参考にしたかったため、それ以外は読み飛ばしたが、かなり具体的で参考になった。
メンタリング部分だけでも読む価値がありそう。
Posted by ブクログ
自分的には非常に良書だった。個人レベルの思考方法についてから入り、コミュニケーションを行う上でのメンタリングの重要性、チームにおける開発・マネジメント、組織の力学と徐々にスケールアップしていく流れも良かった。エンジニアリング組織で働く人の学びになる記述が多くある。特にメンタリングのところは、自分がメンティーの立場だったときに記述されていたようなコミュニケーションを実践できていなかった先輩も多かったし、自分がメンター的立場だったときを思い出すと発言や接し方を反省すべきところがたくさん思い返された。ところどころ、「～は○○といいます」みたいなところでは出典を出した方が良い気がしたのと、筆者の経験を踏まえた自身の考えなのか、出典のある定説なのか分からず、モヤモヤ感じるところもあったが、文章の納得性は非常に高いので、割と素直に理解・共感できた。また、節の中での項目間のつながりがよく分からず、伝えたいことが羅列されているように見えてしまう感もあった。その分を差し引いてもぜひ多くの人に読んで欲しい重要な知見が詰め込まれている。
Posted by ブクログ
予想に反して、所属している会社で起こっていること、行われていることのバックグラウンドを理解することに役立つ一冊だった。
個人的には本書で解説されたようなアジャイルムーブメントの背景は知らなかったので面白かった。
若手中堅向けな印象、OJTトレーナー研修で読むといいんじゃないかな。
本書終盤に謎の誤字(変換ミスのようなもの)が多いのはどうにも気になったけど本質を損なうものではなかった。
Posted by ブクログ
エンジニアリングとは不確実性を減らす作業という定義のもと、個人、対人、チーム、プロダクト、そして組織に対してどのように不確実性と対峙していくかということが丁寧に書かれている。
仕事は学力テストと違い答えのないものが多く、いかにして不確実性と向き合っていくかという観点で大変参考になる書籍だった。
特に以下の内容に気づきを得られた。
・人や組織は限定合理性によって対立する
・アーキテクチャは組織構造に影響を受ける
・技術的負債が溜まりやすくなるのも組織構造の問題
読んだ直後でまだ飲み込みきれていないので、
日を開けてもう一度読み直してみたいと思う。
Posted by ブクログ
エンジニアリングを、進めていく上でどのように組織を作っていくべきかについて網羅的に述べた本。最初は個々人の考え方(メンタリング)から始まり、最後は企業というひとつの大きな組織の中でどうしていくかまで話を広げていく。
個人的に面白いなと思ったのが、プロダクトを作る上で大事なのは「不確実性を減らしていくこと」であるので、不確実性を効率的に減らせるオプションを積極的に採用していくべきというものだった。
これにより、いくつか存在する不確かさ(不安)に対してうまく対処することができるというもの。
あまり自分はこの観点で考えたことがなかったので目新しかった。
また、やはりチームメンバーとのコミュニケーションは重要であるし、組織内に閉じた限定合理性をまでに止められるよう意思伝達は正確に行っていきべきだなと感じた。
メンタリングの際も、自分の考えを押し付けるのではなく、あくまで質問ベースで相手の気づきを促す………これはなかなか難しい。
その他にも、プロダクトの目標を再整理するためにリーンキャンバスを利用するというのはなるほどなと思った。
ちょうど今、少人数でこのようなプロダクト作りに取り組んでいるので積極的に試していきたい。
Posted by ブクログ
組織論のお勉強。すごくよくまとめられている。
スクラムは、経験的プロセス制御理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性と最適化とリスクの管理を行う。
…いずれにしても、現代においても経験主義的な発想というのは、しばしば抜け落ちがちで、「考えれば答えが出る」という学力テスト的な価値観が蔓延しているように思います。
パースは、人間の推論能力の方法として、従来の演繹法、経験主義で重視された帰納法に加えて、仮説法というものがあり、「これこそ、新しい諸観念を導入する唯一の論理的操作である」と述べました。
…仮説法は、「わずかな痕跡」から、それを説明可能とする大胆な思考展開・モデル化を行い、それを検証するための行動につなげる推論方法です。
仮説思考は、経験主義をさらに生産的な（不確実性を削減する）ものにするための「大胆な跳躍」をもたらします。そして、仮説は、今あるデータからは、演繹的・帰納的には導くことのできないものです。人間的な直感やひらめきによって、今までの情報や様々な偶然が積み重なって生まれる跳躍であって、天下り的な結論や合議による凡庸なアイデアは「仮説」にはなりえないのです。
■コミュニケーションの不確実性（ニクラス・ルーマン）
・他者理解の不確実性：人は他人や事象を完全には理解できない
・伝達の不確実性：コミュニケーションが到達するとは限らない
・成果の不確実性：仮に理解されたとしても予想されたように行動するとは限らない
…組織の人数が増えるにつれて、スケールするはずの情報処理能力が実際には線形に推移せず、徐々にそれよりも悪くなるのは、これら「情報の非対称性」と「限定合理性」が存在するからです。
■限定合理性
人間の能力には限界があります。すべての情報をすべての人が適切に処理できるわけではありませんし、同じように認知するわけでもありません。こうした認識範囲や能力の限界から、限られた範囲でしか合理的な行動が取れない性質が限定合理性です。個人的に最適な戦略が、全体にとって最適になるとは限らないのです。
「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それは隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るわけではありません。
「透明性」とは、つまり、継続したコミュニケーションや仕組みを通じて、コミュニケーションの不確実性を低く維持し、情報の非対称性が削減され、限定合理性の働きを弱められている状態のことをいうのです。
■「心理的安全性」を高めることで現れる影響
・率直に話すようになる
・考えが明晰になる
・意義ある対立が後押しされる
・失敗が緩和される
・イノベーションが促される
・組織内の障害ではなく目標に集中できるようになる
・責任感が向上する
■アジャイル
・アジャイル：目的地（ゴール）。環境に適応して、最も効率よく不確実性を減少させられている状態。理想状態なので、決して到達できない地点。
・アジャイルなチーム：目的に向かう集団。理想状態に向かって、前進しているチームの状態。ゴール認識のレベルが高くチームマスタリーを得ている。
・アジャイルな方法論：目的地に向かうための考え方。理想状態にチームが向かうために、お互いにメンタリングし、不確実性に向き合い、減少させるにはどうしたらよいか考えるための組織学習の方法論や考え方
・アジャイル（型）開発：目的地に向かう特定の移動手段。アジャイルな方法論を取り込んだある具体的なチームで実行されている開発プロセスのこと。移動中に状況に応じて書き換えられ、別のものに変化していく。
・アジャイル開発手法（アジャイルプラクティス）：移動手段の手引書に書かれていること。アジャイルな方法論を取り入れやすくするためのルールやフレームワークとしてまとめられている手法。多くの場合、状況に合わせてそこに書かれていることも変化させる必要があると書かれている。
ヴェロシティは、あくまで計画の予測可能性を高めることや、チームの健康状態を測るために使うべきです。
…
もしスプリントごとに見積りを行い、ヴェロシティを測定すれば、その値は妥当性のあるものになります。一方、ヴェロシティが上がったからといって、それは見積りの誤差があったことを示すだけです。チームは、ヴェロシティを上げることよりもむしろ、ヴェロシティが安定し、将来の予見可能性を上げることに投資をしていく必要があります。
■エンジニアリングの不確実性
・環境不確実性→目的不確実性…戦略
→方法不確実性…戦術
・通信不確実性 …兵站
実際のところ、どのようにアーキテクチャを組むのかというのは、ビジネス戦略上極めて重要な経営意思決定といえます。取引コストは、企業組織の境界線を決めるものです。システムにおいても同様で、内製領域と外部調達の領域を決めるのは、経営上不可欠な視点です。
Posted by ブクログ
他人と未来は分からない、という考えが一貫していてよかった。1章と2章は特に、他人に対してネガティブな感情を持った時、再度読み直したい。よい本！
Posted by ブクログ
読んでる途中だけど良書、
マネージャーや、リーダーなどの人は読んでおいて損はない、
ちょっと量が多いのでゆっくり読むか、いいとことって読むと良いとおもう
Posted by ブクログ
組織の動かし方、作り方のヒントを得られればと思い、購入した。
1周ですべてを理解するのは無理なので、何周もして少しずつ理解度を深めていきたい。
アジャイルについて勘違いしていたので、本書で書かれているアジャイルの起点を忘れずに、日々の業務で活用していこうと思う。
Posted by ブクログ
不確実性を下げることは情報を生み出すこと
エリジニアリングの本質はそれ
不確実性があるから人は不安になる
※思考のリファクタリング
①論理的思考の盲点
②経験主義と仮説思考
③システム思考
①で情報を生み出す
バイアスや思考パターンなど理解することで埋められる
②は結局やってみなければわからない
夏休みの宿題の自由研究や美術の課題のようなもの
着手すれば情報が増えて不確実性は減る
③は立場が違えば目的地が異なる
情報の非対称性を踏まえて
問いを考える
その際に認知フレームを揃えておくこと
レベル0 wish to be 願望 〜だったらなぁ
レベル1 have to be 義務 〜しなければならない
レベル2 want to be 欲求 〜したい
レベル3 will be 意思 〜になるぞ
レベル4 be going to be 必然 〜になっている
Posted by ブクログ
組織論は、問題と構造明らかにする作業であり、そこには、個人の考え方・偏見がある。そのうえで、問題を落とし所として解決するのではなく、根本的に両者のやりたいところはどこなのか？そこを見極め、納得して進める必要がある。また、技術と組織においては、望ましい役割、組織サイズなど変数がいくつもある。常に考えておくべきことは、傾聴とコミュニケーション。そしてリーダーの言ってることは抽象度が高いのは当たり前ということ。
Posted by ブクログ
■感想
ソフトウェアを作っていると色々と曖昧なもの・ことに出くわすが、それらを「不確実性」として説明しており、自身の経験と照らし合わせても納得できる論が多いと感じた。
■参考になったこと
・エンジニアリングは不確実性を減少させる活動
・不確実性＝①目的不確実性、②方法不確実性、③通信不確実性
・行動は外部から観察可能、状態は観察不可能。「考える」は行動、「悩む」は状態
・プロジェクトマネジメントとプロダクトマネジメントの違い（目的と対処すべき不確実性が異なる）
Posted by ブクログ
不確実性マネジメントについて拾い読みした。学びはあったが、出典が明記されていないため著者の意見と一般的な話の見分けがつかないこと、他の文献を読んでの学習が難しいことがマイナス。
スケジュールの最善ケースと最悪ケースの幅が、スケジュール不確実性である。このスケジュール幅を可視化して効率よく削減していくことが重要。最後になって初めて幅が大きいと分かるのが最悪。
多点見積もりから求められる不安量＝見積もり偏差が大きいタスクから順に問題解決することで、スケジュール不安を早期に減らすことができる。
不安量の大きいタスクを、不安量の小さいタスクに分解することで、不安量を減らしたり、不安部分のみを切り出して先に対処するなどの対策が打てるようになる。
Posted by ブクログ
エンジニアリングと経営の両面から、組織がどのように利益や目標を追求すべきか/できるかを説いている。数的モデルも登場し、説得力があるように感じた
Posted by ブクログ
エンジニアリングの組織において生産性を高めたいので、読みました。エンジニアリングは不確実性を減少させる活動であるという定義はしっくりきました。ソフトウェアの開発は不確実性が最大の状態から、情報を積み上げてそれを削減していく。計画についても、間に合わせるではなく、完了予定を確定させていく、という考え方。アジャイルをするではなくアジャイルになる。ちゃんと計画・設計し、かつ仕様変更に対して俊敏に適応する。それでいて意思決定は遅らせる。プロジェクトにおいて不確実性の観点で優先順位を見極め、よいタイミングで確定させていく。そのためには、実績をもって見積り、計画を立てる。
Posted by ブクログ
エンジニアリング、組織、開発手法、アーキテクチャに関する様々な問題、現代の考え方をまとめている本です。
具体的な手法が載っているわけではなく、「こうして軋轢・不和が起こる」「なぜそれが起こるのか」「解決されるために取り入れる考え方」ということを、これでもかというくらい詳しく紹介しています。
とにかく話題が豊富で、それぞれの用語や考え方をひたすら掘り下げているので、あくまで「納得する」ための本であって、これを有効に活用して具体的に…というものではありません。
・いいところ
現代のシステム開発に関わる考え方を、(著者の考える)背景も含めて理解することができます。
説明もかなり平易で、スラスラと読むことができます。
歴史的背景、著名な考え方・発言などを紹介してくれるため、単なる筆者の思い込みではなく、裏付けを元に理解することができます。
・悪いところ
話題が豊富すぎるため、節の単位で頻繁に話題が変わり、最後にまとめとしてそれらが繋がっている…気がするのですが、置いていかれます。きっと著者は相当頭がいいのだと思いますが、それぞれの節を結びつけて思考を理解するのはとても大変…というか私には無理でした。断片的にパーツ(節)ごとに理解はできるのですが、「結局どういうこと…？」という疑問が常に生じました。
どの用語につけても、定義や背景をひたすら掘り下げていくので、説明によっては冗長と感じるかもしれません。また、歴史的背景などとの結びつけを、あくまで著者の考えを元に行っているため、「そう考えるとうまくいく」のであって、話題によっては強引なこじつけと感じるかもしれません。
全体的には、一度は読んでおくとシステムやサービス、組織が生じる歪みを理解できるようになるためおすすめです。ただ、この本全体を通して全てを"一貫して"理解するのは相当至難の業だと思います。
Posted by ブクログ
全く予想してなかった思ったよりアカデミック寄りでした。でも全てを不確実性と向き合うためと考えるのはとても腑に落ちる。やはりマーケット不安重視のプロダクト向き組織とスケジュール不安重視のプロジェクト向きに組織での差が納得できた。興味があるセクションとあまり参考にならないセクションの差が激しかったものの読んで良かった。参考になった。
Posted by ブクログ
「エンジニアリング組織論への招待: 不確実性に向き合う思考と組織のリファクタリング」 広木大地 ★★★★☆
前半は非常に面白かった。後半はすこしキツかったかな。
「アジャイル VS ウォーターホール」という図式自体が違うということは、目から鱗が落ちる思いだった。
アジャイルは方法論ではなく、状態なのだ、その状態を作るのが「経験主義」や「仮説思考」。まずやってみて、わからないことを減らすこと。
チームリーダーの諸君に読んでいただきたい一冊。
#引用
・わたしたちは「わからない」もの（「未来」と「他人」）に向き合うことを避けてしまうという習性がある。
・「わからない」ということは、それだけで自分自身を脅かす可能性を考えてしまう（「不安」）。そのようなものに、人は本能的に「攻撃」か「逃避」を選択してしまう。
・エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移行していく過程に行うすべてのことです。不確実性を下げるということは、つまり、「情報を生み出すこと｝にほかならない。
・「怒り」に変わる感情の、その原初的な思いは、気づ付けられたことによる「悲しみ」であって、それを伝えない限り、どんな理屈をこねて、正当化しようとしても相手の行動を変えることはできない。
・経験主義は、わからないを行動に変換し、一歩でも正解にたどり着くための思考の補助線なのです。
・経験主義は、自分のコントロールできるものを通じて、観測できるものを改善する発送です。
・仮説思考は、限られた情報の中から、大胆にモデルを推論し、そのモデルの確からしさを発見するための行動を促す思考様式です。
・コードレビューにおいては、「なぜ、そのようにしたのか？」ということを問いながら、できれば、その人自身が指摘のポイントに気がついてもらうことを促せるのがベストです。時間がなければ「自分はこっちのほうが、こういう理由でよいと思うけど、どう思う？」のように修正案をつけて、相手に考えさせるのが大切。
・人から与えられた説得による知識を「他者説得」、自分自身で気がついたことを「自己説得」といいます。メンタリングでは他者説得よりも自己説得を重視し、その獲得を促します。
・「考える」は行動で、「悩む」は状態なのです。「行動てきていないとき」は「悩み」を聞き出し、気づきを促して「考える」に変えていく必要があります。
・ポジティブな話を聞くときは早く細かくうずき、ネガティブな話や感情への共感を示すときは、ゆっくり深くうなずく。
・「共感」は「相手がそのような気持ちになった理由を理解する」ことです。
・「同感」は「自分が相手と同じ気持ちになること」でうす。
・傾聴において示すべきことは、「共感」であって「同感」ではない。
・能力は習慣の積分、習慣は行動の積分。習慣が能力に変われば、成果につながり、成果は自身となって次の行動を強化してくれます。
・アジャイルは”俊敏な”という形容詞であって、名詞ではない。「Do agile」ではなく「Be agile」。アジャイルは”する”ではなく”なる”。状態のこと。
・「アジャイルな」状態とは ・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクをとれていて心理的安全性が高い
・課題・不安に向かい合い不確実性の削除が効率よくできている
・チーム全体のゴール認識レベルが高い
・アジャイルソフトウェア開発宣言は「顧客との協調」「個人との対話」「動くソフトウェア」「変化への適応」を重視すべき
・不確実なことを減らすには、一番不確実なことから確かめていくこと。そうすれば、早く失敗するので、一番早く問題解決できます。
・システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう。
・組織階層の深さや地理的に離れた複数人が関わるコード、離職者の数、関わっている開発者の人数など、コミュニケーションコストが一般的に多くかかるであろう環境ほど、バグが多くなる傾向が発見された。
Posted by ブクログ
企業はエンジニアリングで不確実を減らす活動をしているという視点は勉強になった。ソフトウェア関係の内容を含んだものは理解が難しかったので、考え方の参考程度にはしたい。
Posted by ブクログ
何だかエッセイだなという感じ。
アジャイルなチーム、学習するチーム、組織力学などエンジニアが取り巻く不確実性にどのように挑むかが述べてある。
数式で語っているところもあれば、なんだか出典がよく分からない図(筆者の図解?)で説明されている所もあり、説得力が上がったり下がったりして読みにくい。
考えの根底に貫いていることはなんとなくエンジニアには伝わる本だと思うんだけどなぁ。
