#Book [[📒「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術]] ## 第2章　「間違った失敗」から「正しい失敗」へ > [[🗃️透明性]]とは、チームのメンバー全員が現在の状況や進捗、課題について共通の理解を持つことです。透明性が高い組織では、情報がオープンに共有され、どのような状況かをすぐに把握できる状態が保たれます。すると問題が早期に発見され、迅速に対処することが可能になります。 ^ref-5735 ### 仕様と成果物の間に生まれるブラックボックスの原因 > コミュニケーション不足 エンジニアとプロダクト責任者間でのコミュニケーションが十分でないことが、多くの問題を引き起こす原因。計画段階での要望や変更が十分に伝えられていない、または誤解されている可能性がある ^ref-30598 > 要件の不明瞭さ 要件が不明瞭であったり具体性に欠ける場合、 エンジニアが独自の解釈 を加えて開発を進めてしまうことがある。これにより、最終的な製品がビジネスのニーズや期待と異なる結果になることがある ^ref-64781 > 変更管理の欠如 進行する中で新たな要望や変更が生じることはよくある。これらの変更が適切に管理されていない場合、スコープが不明確になったり変更が頻繁に起こり、変更管理が追いついていなかったりすることで期待される成果物と異なる結果が生じる可能性がある ^ref-60158 ↑の3点の原因は >組織デザインにおけるプロセス設計のミス ともいえます。誰にどれだけの権限と裁量を与えるのかが明確にされていないと、非常に細かい部分にまで責任者の確認が必要となり、[[🗃️認知負荷]]と[[🗃️リードタイム]]が大きくかかります。たとえ権限が明文化されていたとしても、どこでその確認を行うかという「場」の設計がされていなければ、タッチポイントが不明瞭になります。 ^ref-33817 > [[🗃️RACI]]は「Responsible（責任者）」「Accountable（説明責任者）」「Consulted（相談役）」「Informed（情報受領者）」の各頭文字を取ったものです。各タスクやプロセスに対して、これらのカテゴリに属する人々を特定することにより、誰が何を担当し、誰が最終的な決定権を持つかを明確にできます。 ^ref-63703 ### 失敗は、信頼関係による対話で回避できる > 「組織を変える5つの対話』（Douglas Squirrel、Jeffrey Fredrick著）には、組織に対してプラクティス（アジャイルやDevOps）が爆発的に普及・導入が進む中で、型だけが重視され、その中にある 人間関係が見落とされている という指摘があります。自分たちはそのまま行動していれば問題がなく、導入されるプラクティスが行動を手助けしてくれるというマインドでは危険です。 ^ref-38995 ❶信頼を欠いていては、自己開示と他者理解を目指せません。 ❷言葉にできない不安を感じていたら、無意識であっても防御的に行動してしまいます。 ❸WHYが共有されていないと、建設的に意見をぶつけ合うことができません。 ❹明確なコミットメントを避けるのは、自分に危害が及んだり恥ずかしい思いをしたりしそうなときです。 ❺説明責任を果たそうとしない限り、経験から学ぶことができません > Elephant in the Room（部屋の中の象）」というものがあります。これは「みんなが違和感を感じているのに、誰も指摘しない大きなこと」という意味です。解決するのにあまりにもハードルが高いことや、誰もが面倒だと思っていること、メンタルが削れそうな複雑な事象のことを、「部屋の中にいる象は誰しも気付いているにもかかわらず、追い出す難易度が高いので見て見ぬふりをする」ことを指します。 ^ref-62429 💭[[🗃️部屋の中の像]]というやつだ。 ### 嫌な報告こそ、相手を褒める、感謝する > まず失敗を 正直に報告できる 文化を醸成することが必要です。これは、失敗を恐れずに 報告できる環境 を整えることを意味します。失敗を共有することは、ほかのメンバーが同じ過ちを繰り返さないための予防策となります。 ^ref-40063 > 組織としては、第一歩として「 嫌な報告こそ、相手を褒める、感謝する」を徹底するのがよいでしょう。 　これには、 報告を受ける側が自らの失敗を積極的に報告すること が大事です。 ^ref-63391 💭Bad News Firstな文化を作っていくことは大事 ### エンジニアは、説明責任を果たすことで透明性を作っていく 説明責任❶見積り予測のズレをリカバリーするのは難しいので、早期に報告する 説明責任❷コミットメント（約束）と予測を分ける 説明責任❸見積り（予測）は4つの価値を理解する 説明責任❹隠された失敗をしないために、開発優先度を理解してもらう 説明責任❺障害対応時は、チーム外へ連絡・報告・相談を行う役割を作る 💭❶の[[🗃️説明責任]]を果たせているのだろうか？ ### 説明責任❶──見積り予測のズレをリカバリーするのは難しいので、早期に報告する > [[🗃️見積もり]]のズレを早期に報告すれば、早い段階で適切な対策を講じることができ、プロジェクト全体のリスクを軽減できます。 ^ref-31890 > [[🗃️アンチパターン]]として気を付けなければいけないのは、PMとエンジニアの間で進捗報告の粒度や開発速度に関する議論が増えると、エンジニアが見積りの際に 心理的バッファを多く取る傾向 が生まれる ^ref-58239 > [[🗃️自転車置き場の議論(パーキンソンの凡俗法則)|🗃️パーキンソンの法則]]が当てはまり、良い結果を生みません。パーキンソンの法則とは「仕事は与えられた時間をすべて使って膨張する」というもので、バッファを多く取ることで、必要以上の時間をかけてしまう可能性があります。 ^ref-56554 ### 説明責任❷──コミットメント（約束）と予測を分ける > コミットメントは見積りをもとにした詳細フェーズでの予測であり、[[🗃️ステークホルダー]]への明確な 約束 を意味します。[[🗃️見積もり]]には予測の幅やリスクが含まれますが、[[🗃️コミットメント]]は、それを踏まえたうえで現実的な達成可能性を考慮し、確実に実行することが求められます。 > [[🗃️見積もり]]をそのまま[[🗃️コミットメント]]とせず、見積り結果に基づいてリスク管理を行い、現実的なスケジュールやリソース配分を慎重に策定することで、プロジェクトの予測と現実のギャップを最小限に抑え、リスクを減らしていくことが重要です。 ^ref-60234 💭[[🗃️見積もり]]をして、それをそのまま[[🗃️目標]]としがちだけど、それをやってしまうと良くない気がする。[[🗃️見積もり]]と[[🗃️コミットメント]]は分けるべき。 ### 説明責任❸──見積り（予測）は4つの価値を理解する ① 施策の合否 を判断するための「見積り価値」 ② 納期・スケジュール の管理のための「見積り価値」 ③設計の センス やシステムの 複雑性 を検知するための「見積り価値」 ④自分たちの 予測精度 を上げるための「見積り価値」 ^ref-30317 ### 説明責任❹──隠された失敗をしないために、開発優先度を理解してもらう ①ソフトウェア開発の保守開発の重要性を理解してもらう > 保守開発はエンジニア以外には見えにくいため、 その重要性を説明するのはエンジニアの役割 です。たとえば、[[🗃️EOL]]（ End of Life）を迎えそうな製品がどれくらいあり、その際にどんなリスクが発生するかをエンジニア自身が説明し、保守開発の改修に必要な工数を確保することが求められます。 ^ref-19114 > 本来、[[🗃️リファクタリング]]とは、 未来の変更コストを軽減する活動 です。すべてのシステムをリファクタリングするわけではなく、将来的に変更が多く発生する可能性が高い部分、つまり効果が高いと見込まれる部分から優先的に進めるべき ^ref-8261 ②専門用語を使わずにていねいな言葉を使う > 「リファクタリングしました」という言葉の背後に隠されています。「あなたには理解できない重要な技術的作業を行いました」と言い換えることもできます。これがまさに「コードのリファクタリング」に関する問題です。多くの場合、それは非常に重要な作業を意味しますが、ほとんど怠けているのと区別がつかないことがあります。たとえば、理由もなく変数の名前を変更するようなことです。そして、これが私が「コードをリファクタリングしないでください」と言う理由です。 ^ref-10747 💭[[🗃️リファクタリング]]をすることが目的になると不信感につながる。なので、ちゃんと成し遂げたいことや、課題があってそれを達成するということを伝えないと行けない。だから[[🗃️リファクタリング]]します、しましたという説明は[[🗃️説明責任]]を果たしていないのと一緒かもしれない。 ③外部データを使ってスタンダードを伝える > 欠陥数の増加：低品質のコードは高品質のコードに比べて「15倍」も多くの欠陥を含んでいる • 問題解決時間の延長：低品質のコードで問題を解決するには平均で「124％」も多くの時間がかかる ^ref-57387 紹介リンク面白そう [技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） － Publickey](https://www.publickey1.jp/blog/24/post_301.html) ### 説明責任❺──障害対応時は、チーム外へ連絡・報告・相談を行う役割を作る > [[🗃️DiRT]]（ Disaster Recovery Training）と呼ばれる障害訓練を実施することです。DiRTでは、実際の環境を模した仮想環境で障害を発生させ、その対応をシミュレーションし、役割分担や対応手順を分析して課題点を洗い出し ^ref-13569 ### 2.3「繰り返される失敗」から「学べる失敗」へ #### 仮説検証ループの導入 [[🗃️BMLループ]] > 新しい機能や施策を導入する際には、具体的に「何を検証することで、この仮説が正しいかが証明できるか」を出発点とした学習目標を設定します。 ^ref-14996 > [[🗃️BMLループ]]を回す際は、同時に2つの改善を満たすような施策は推奨されません。バッチサイズ（1つの処理で回す量）として大きすぎます。これを [[🗃️Single Piece Flow]]（1つのサイクルで1つの仮説） といいます。 ^ref-30438 #### 障害の再発防止策から逃げない──ポストモーテムから失敗を学ぶ > [[🗃️ポストモーテム]]は障害から学び、より良いサービスを提供するためのドキュメントであり、現在や未来のチームメンバーやほかのエンジニアを対象に、障害の詳細な分析や再発防止策を共有するものです。 ^ref-6411 > [[🗃️ポストモーテム]]の実施にはステップがあります。まず、発生した障害の基本情報を記録します。たとえば、障害の発生日時、影響範囲、対応時間などです。次に、[[🗃️インシデント]]タイムラインを作成し、障害発生から解決までの時間軸を詳細に記録します。このタイムラインは、各ステップで何が起こったかを明確にするために重要です。その後、原因分析を行い、障害の直接的な原因と潜在的な根本原因を特定します。障害対応のプロセスを評価し、効果的だった点や改善すべき点を洗い出します。そして、同じ障害が再発しないように、具体的な再発防止策を策定します。最後に、分析結果と対策をチーム内および関係者全体で共有します。 ^ref-2711 > [[🗃️ポストモーテム]]は単なる障害の振り返りではなく、組織全体の学習と成長を促進するための重要なプロセスであり、 繰り返される失敗をなくす対策 となります。 ^ref-42131 ### 2.4「低リスクなムダな失敗」から 「リスクを取った学べる失敗」へ #### 工数や実装難易度でMVPをスライスしない >仮説に対する検証方法を[[🗃️MVP]]としてスライスするべきであり、工数や実装難易度でスライスしてはいけません。工数ベースで小さく作り、ムダな失敗を繰り返すのであれば、予算リスクを取って学べる失敗のほうが価値があります。 ^ref-52771 ### 2.5正しく失敗できれば、 失敗をコントロールできる > 失敗をコントローラブルにすることで得られる大きなメリットは「 時間」です。間違った失敗を正しい失敗へと置き換えていく作業は、最終的に「時間」をコントロールできることにつながり、プロジェクトをタイムリーに進めることができます。 > • 「隠された失敗」→「透明性のある失敗」 課題解決 にかかる時間をコントロールできる > • 「繰り返される失敗」→「学べる失敗」 再利用できない ムダな時間をなくすことができる > • 「低リスクなムダな失敗」→「リスクを取った学べる失敗」 ムダな 学習 時間を短縮できる ^ref-49010 💭[[🗃️透明性]]を持って、失敗から学んでいくことが大事