#Book [[📒「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術]] ## 感想 - 誰かに頼る運用ではなく、しくみを整えて組織として失敗が起きないようにしていくのが大事 - [[🗃️エビデンスベースドマネジメント|🗃️EBM]]じゃないけど、ちゃんと事実ベースでのコスト把握は大事な感じがした。 - [[🗃️リファクタリング]]は資産価値を高める活動 - [[🎫開発生産性をあげる改善って儲かるの？に答えられるようにする]]にも似たような話があった - ↑ができれば、[[🗃️類推見積り]]のように予測の質を高めることができて、再現性を高めることができるのかもしれない。 ## 7章 ### 7.1 失敗の原因は人ではなく、「しくみ」の欠如 > 失敗を指摘する際には個人ではなく事象を指摘することが重要です。 > • 成果を称える際は人を褒め、課題を指摘する際は事象を指摘する > • 褒める場合は「誰から」言われたか、課題の場合は「何を」言われたかが大切 ^ref-37767 💭[[📚第6章 文化を醸成する「恐怖」と向き合う技術②]]でも書いてあったやつだね。 #### ルールとしくみの違い >• ルール 特定の行動や手順を定めたガイドライン。 > たとえば、「コードレビューは他メンバー2名以上の承認が必要」とするルールなど。 > ルールは行動を促したり、抑制するために存在し、明確な指示としてメンバーに提供される >• しくみ ルールが自然に守られるような環境やプロセスを構築するもので、システムが一貫して機能するための全体構造を指す。 > たとえば、「2名の承認がないとコードがマージされない」という設定。このようなしくみがあると、意図的にルールを破ろうとしても自動的に阻止され、チーム全体が品質基準を守りやすくなる ^ref-48965 > ルールは行動を制限しますが、しくみはプロセス制御に基づきミスを防ぎ、ルールを自然に守れる環境を提供します。 ^ref-19750 💭ルールとしくみあまり意識したことがなかった #### しくみ=[[🗃️フィードバック]]制御で自動制御する > [[🗃️フィードフォワード制御]] > 望ましい結果を得るために事前に行動を調整する方法で、 ルールに似ている。 > たとえば「コードレビューが必要」というルールは、事前に行動を規定し、バグの発生を防ぐ働きを持っている > • [[🗃️フィードバック制御]] > システムの出力を監視し、その結果に基づいて調整する方法で、 しくみに対応する。 > たとえば、「Pull Requestを作成するとコードレビューが自動的に開始され、承認が2名以上でないとマージできない」という設定が挙げられる。こうしたしくみの制御により、開発者はルールを守ろうと意識しなくても、エラー表示によってマージの要件を意識できる ^ref-54593 >ルールよりもしくみ を整え、[[🗃️フィードバック制御]]を活用します。個人の意識に頼ることなくチームの失敗を減らし、プロセスの一貫性が維持されます。失敗の原因を「人」ではなく「しくみ」による制御の不備ととらえることで、チームは失敗を糧とした建設的な改善を進めていくことが可能になるでしょう。 ^ref-42725 >このようにルールは、「事前に設定された目標を達成するために何をすべきか」を明確に指示します。一方で、しくみは「目標を達成するためにシステム全体がどのように動くべきか」を 自動的に調整する役割 を担っています。ルールとしくみが異なるのは、前者が[[🗃️行動指針]]としての性格を持つのに対し、後者はその行動を 自然に導く環境を整える という点にあります。 ^ref-21784 ##### 💭自分なりに整理する - ルール => [[🗃️目標]]達成のために何をすべきかを明確に指示する([[🗃️行動指針]]) - 仕組み => [[🗃️目標]]を達成するために、システム全体がどのように動くべきか(環境整備) - ルール < 仕組み - 個人の意識に頼らずに、チームの失敗を減らすことにつながる。 #### 失敗からの学びを強化させる3つの仕組 ##### [[🗃️注意ベースの理論]] [[🗃️注意ベースの理論]]です。組織のパフォーマンスは、メンバーがどの情報や課題に注意を向け、どのようにリソースを割り当てるかによって大きく影響されるという考え方です。注意が「限られた資源」ととらえられるため、その配分によって組織の意思決定や行動の質が左右されます ^ref-2963 ##### [[🗃️注意の関与]] 特定の課題や失敗に対してどれだけの注意が持続的に向けられているかを意味する「[[🗃️注意の関与]]（ attentional engagement）」という概念も重要視されています。組織が一定の問題に対し、深く、そして長期的に関心を持ち続けることで、表面的な理解を超えて実質的な対策や改善が生まれやすくなります。 ^ref-17983 ##### [[🗃️警戒心]] さらに「[[🗃️警戒心]]（ vigilance）」も組織学習のための重要な要素です。これは組織が潜在的なリスクや問題に対して敏感であり続ける能力であり、過去の失敗に対してもこの警戒心を維持することで、同じ失敗の再発を防止し、組織としての学習効果を高められます。 　つまり、 注意の関与（ attentional engagement）と警戒心（ vigilance）の両方が持続するしくみを意図的に作り上げ、組織全体でこれをプロセスに組み込むことが、失敗の教訓を将来の成長へとつなげる鍵となるのです。 ^ref-45115 #### 継続的な学習を促進するプロセスは「記録」をすること > 制御理論に基づいた「しくみ」や[[🗃️注意ベースの理論]]（ attention-based view）を、本書のテーマに置き換えて考えると、「 失敗を正しく記録する」ことの重要性に気付きます。 ^ref-12542 #### 観測できないことは改善できない > 失敗データは、単に失敗した記録だけを残すのではなく、プロセス全体の予測データ、成功データ、失敗データのすべてを格納し、分析可能な状態にすることが求められます。これは、ソフトウェア開発での「予測の失敗」を可視化し、次回に活かすためです。 　[[👤Martin Fowler]]氏の言葉を借りれば、失敗というのは大小あるにしろベースとしては「予測」の失敗 です。 ^ref-17859 ### 7.3 [[🗃️ソフトウェア開発]]の工数予測と実測のデータ > [[🗃️開発プロセス]]を効果的に観測するためには、「[[🗃️リードタイム]]」と「[[🗃️スループット]]」の視点で分析することが役立ちます。 > • リードタイム > 横軸で見ていき、各開発案件のバリューストリーム（例：企画→設計→開発→QA→リリース）を指す > • スループット > 開発組織の総費用や総工数にあたるもの。 > たとえば、開発にかける予算を通期で見たとき、スループットを把握することは生産性向上に直結する ^ref-51365 #### [[🗃️バリューストリームマッピング|🗃️VSM]]は失敗の記録には向かない > [[🗃️バリューストリームマッピング|🗃️VSM]]には一点問題があります。プロセスの トラッキングが手動になりがち で、さらにその結果が一時的なスナップショットになる点です。つまり、継続的な記録として運用することには向きません。 ^ref-3702 #### [[🗃️財務諸表]]に近い[[🗃️開発生産性]]をトラッキングする > 多くの企業ではソフトウェア開発は企業の「[[🗃️ソフトウェア資産]]」として[[🗃️財務諸表]]に計上され、通常は「[[🗃️ソフトウェア仮勘定]]」として費用を一時的に蓄積します（ 図7-3-4）。この仮勘定には、プロジェクトごとの 勤怠や工数、給与単価に基づいたコスト が含まれます。ソフトウェアが完成して稼働を始めた時点で「[[🗃️ソフトウェア資産]]」として正式に計上されます。これは将来的に企業の成長に寄与する資産としての価値を持つためです。 ^ref-15801 > プロダクトの新規開発や[[🗃️リファクタリング]]、リプレイスなどは「資産化」される一方、日常的な運用のための[[🗃️ミーティング]]や障害対応などは「費用化」され、即時コストとして処理されます。資産化されたソフトウェアは、企業のバランスシートに無形資産として記載され、長期にわたり減価償却を通じて費用として認識されるため、短期的な収益への負担を和らげ、ソフトウェアの使用寿命に応じた費用処理が可能となります。 ^ref-42253 #### [[🗃️プロジェクト]]ごとに[[🗃️工数]]分布を分析していく > 今の事業規模に対して 開発費用が妥当なのかと、売上目標として今期の200％成長を目指す中で開発組織にかけるコストは今よりも どのぐらい増やすべきなのか です。 　データとしては前述した財務諸表のものを使えば問題ないでしょう。ポイントは次の2点です。 > • 対象のチームや部門が使った総工数（月別）とコスト、雇用形態といった従業員データ > • どんな開発区分に工数を使ったか（内訳） ^ref-40783 #### どんな開発区分に[[🗃️工数]]を使ったか > [[🗃️スループット]]的なデータの勘所は、事業に対しての開発コストを考えることですが、 人件費を減らすことではありません。できるだけ 費用化する作業を減らしていって、資産価値を上げるクリエイティブな開発に時間を割く環境を作る ことです。 ^ref-10975 #### 迅速に見積もられる[[🗃️類推見積り]] > [[🗃️類推見積り]]は、過去の類似[[🗃️プロジェクト]]のデータを参考にした時間の見積りで、チームの経験と実績に基づいて予測を立てる手法です。この手法は記録が蓄積されるほど正確性が増し、また 迅速に見積りが行える 点が特徴です。特に規模が大きいプロジェクト（1人月以上）ではその効果が顕著になります。 ^ref-9921 ### 7.4 [[🗃️仮説検証]]の失敗・成功のデータ > 一般システム理論を[[🗃️システム思考]]に変換し、事業を考えるということは、簡単にいえば、入力（ input）は何で構成されて（例：ヒト・モノ・カネ）、その入力によって事業モデルがどういった処理を行い、出力（ output）されるか（例：売上・利益）を考えることです。それを表現のプラクティスに落とし込んで、「 カスタマージャーニー」や「 [[🗃️ユーザーストーリーマッピング]]」を作り、ユーザーがサービスを利用するうえでの流れを把握していきます。 ^ref-40355 #### 事業の価値筋が予測できる変数を理解する > • [[🗃️KGI]]：事業やサービスが最終的に達成すべき目標（「何を達成したいか」） > • [[🗃️CSF]]：KGIを達成するために必要な重要な要因や活動（「何が成功に不可欠か」） > • [[🗃️KPI]]：KGIを達成するためのプロセスや活動の進捗を測定する指標（「どのように達成するか」） ^ref-1746