企画・仕様による失敗

• 追加要件の対応
  • 機能を追加するということは、現在のスケジュールでは間に合わないということ。
    • いずれかの対応が必要となる
      • スケジュールを遅らせる
      • 他の機能を代わりに削る
  • 一旦仕様に組み込むかどうかの検討ステージに追加する
    • その機能がどれほど必要なのか
    • 開発へのインパクトはどのくらいか
  • 再調整した仕様やスケジュールは、再合意を取る。
• 顧客が本当に必要だったもの
  • 表面上の機能や要望だけではなく、「解決したい課題」が何かを理解する
• 成果物からブレークダウンする
  • タスクが漏れないようにする
  • チームが「何を作るべきかわかっていない」状態にしない。
• 対応OS、ブラウザなど動作環境の定義を忘れない
  • リリース時期の情勢の変化等に柔軟に対応する
    • 余裕を持って全体を俯瞰しておく
    • 最新情報にアンテナを張る
• 教育コストを見積もりに入れておく
  • アサインされる要員のスキルレベルも、工数見積りの大事な要素。
  • 一番早くできる人を基準にしない。
• ふんわり仕様で見積もりや仕様に認識齟齬が生まれる
  • ユーザが実際に利用するシーンをイメージする
  • 仕様を明確に記載する
    • 不要な機能や必要な機能が見えてくる
• 仕様書は正しく伝わるように文章や伝え方に気をつける
  • 複雑な仕様は、図にすることで理解しやすくなる
  • そもそも仕様自体をシンプルにすることを考える
    • 本当にその機能はいるのか、なぜ必要なのか
• 用語集を作ろう
  • 誤認識によるコミュニケーションエラーを避ける
  • チーム全体のドメイン知識の底上げ
  • みんなで育てる文化を醸成する
• 利用されるシーンを想定したテストデータを用意しよう
  • 実際の想定よりも、少ないテストデータで検証すると、意図しない大量のリクエストやUI崩れ、その他動作が重い、読み込みが遅いなどの問題も。

開発・設計の失敗

• 設計
  • なぜこのような設計にしたのかという情報を残し、伝えられる状態にしておく
  • 図に起こす
• 要員管理
  • アサインの権限を持つ上位レイヤーと、チーム内情の解像度を合わせておく
  • 何か起きてもカバーできるチーム体制を整えておく

進捗管理

• 進捗確認の会議で課題に気づけない理由
  • 課題が上がってこない
    • 考えられる原因
      • タスクの粒度が大きすぎる
      • 課題はあるけど、言えない空気感がある
  • 課題が上がっているけど、見えていない
    • 深掘りせず、アクションを起こさないまま、気づいたら放置してしまっている
  • 課題を見つけ用としていない
    • 実装は完了したけど、動作確認をしていない、もしくは不十分である
    • 単体テストを実装し、動作確認をするところまでをタスクに含めらていない
• 進捗管理はツールに任せて、課題が発生していないか、発生しそうな課題はないかに着目する
  • メンバーの言動に対して、アンテナを張ること。
    • 「今週あまり時間が取れていなくて、進捗が遅れています・・・」
      • 何か課題が潜んでいるかも？と、状況を見て必要なアクションを取っていく。
• 工数見積もり
  • メンバーにはそれぞれプロジェクト業務以外の業務の時間が存在する
    • 1日8時間プロジェクト業務ができることを前提とした見積もりにした場合、スケジュールに遅延が発生することになる
    • → プロジェクト以外の業務について認識しておく
      • 研修や目標・評価、採用活動、その他会議・・・
    • → アサインされたメンバーが掛け持ちなどをしている場合も考慮しておく
  • チームの生産力を把握する
    • 見積もりと実績を振り返り、軌道修正していくことで見積もりの正確性を上げていく
      • このチームは1週間で何ポイント分の作業が可能か
      • この作業は何ポイントか
• 心理的安全性
  • リーダーがメンバーに問題を追及しすぎたり、圧力的になると、課題の報告や相談がされなくなる
  • リーダー像
    • それぞれに合ったリーダー像を見つける
      • ダメなところをあえて曝け出していく
        • リーダーからメンバーに相談をしていくことで、「チームの課題と共に戦う参謀ポジション」に置く
        • 自分がチームを支えたという成功体験を持たせる
    • チームが協力し、チームの力を最大化できるようコミュニケーションしやすい健全なチームを作ること。
• 依頼する際に、重要度が高いほどお互いの状況や背景を相互理解できるように直接的なコミュニケーション方法に変えていく
• 計画
  • スケジュールはほとんどの場合が遅延するもの（ソフトウェア開発は難しいものと理解しておく）
    • 遅延をなくすのではなく、リスクと対策を事前に考えておく
    • 状況を見て柔軟に動きを変えられるようにしておくこと

評価

• 顧客がどのようなユースケースを持っているかを理解し、テスト戦略を立てる
• 顧客の利用シーンから、非機能要件を導き出す
  • 顧客がその機能を使う作業を、どのくらいの時間で完了しないといけないか
  • どのくらいの利用頻度なのか
• リリース直前は最小限しかソースコードは触らない
  • 全てのバグを修正しようとしない
    • 軽微なバグだからと修正したところ、思わぬところに影響が出てしまい、スケジュール遅延などを引き起こすリスクがある。
  • リリース直前は、割り切れるバグは修正せずに時期を見送る判断も大事。
    • 何を割り切り、何を修正すべきか、プロダクトとして何を重視しているのかを関係者間の認識を揃えておく。
• ログを仕様に盛り込んでおく
  • リリース後にさまざまな環境でユーザが利用し、発生するバグの再現方法の手がかりを知るために、必ずログを送るようにしておく。
• 振り返りにおいて、ヒトを原因にしない
  • チームの空気が悪くなる
  • ヒトはもともとやらかすものである
  • 再発防止策が検討できない