新規開発の炎上を防ぐ!「最悪のケース」想定で変わったチーム開発

こんにちは!ウィルゲート開発室の水口です。

はじめに

今回TACT SEOの開発チームではリスクチェック機能の開発に取り組みました。7月上旬にファクトチェック機能をリリースし、7月下旬にはコピペチェック機能のリリースしました。

この開発を通じて、前半と後半で大きく異なるアプローチを取ったことで、多くの学びを得ることができました。今回は、開発プロセスの改善について振り返りを共有したいと思います。

プロジェクト概要

開発内容

振り返りの実施タイミング

KPT形式で、ファクトチェック開発(前半)とコピペチェック開発(後半)それぞれについて振り返りを行いました。

前半のファクトチェック開発で見えた問題点

ファクトチェック開発の前半では、不確実な部分の検証・実装への着手が遅れ、終盤まで課題が残る状況になってしまいました。

具体的には以下の要素について、検証や実装が後回しになってしまいました:

  • 新規機能のコアロジック実装
  • AIのアウトプット精度検証
  • AI利用コスト試算
  • 画面仕様などの不確定部分

結果として開発終盤にかけて高い負荷がかかってしまい、チーム全体が逼迫した状況に陥りました。

後半のコピペチェック開発で実践した対策

前半の反省を活かし、コピペチェック開発では以下の改善を実施しました。

開発計画時にリスクを想定する

前半のファクトチェックの開発では、大きな問題が発生しない想定で楽観的な計画を立てていました。後半のコピペチェックの開発では「最悪のケース」を想定した開発プロセスを実施しました。

開発プロセスの具体的手順:

まず、最終的に起こり得る最悪の結果を洗い出しました:

  • 機能が実現できない
  • 機能が使えない
  • 事業部の要求を満たせない

次に、その一歩手前で発生しうるより具体的なケースを洗い出しました:

  • 処理時間が許容範囲を超える
  • アウトプット品質が要求レベルを満たさない
  • AIのレスポンス精度が期待値を下回る
  • 利用コストが予算を大幅に超過する
  • 画面の操作性が複雑すぎてユーザーが使えない

そして、それぞれのケースに対する具体的な対策を事前に検討しました:

  • 処理時間超過 → ロジックを工夫し、時間がかかるロジックを排除
  • 品質不足 → 複数パターンで検証し、事業部関係者がレビュー
  • コスト超過 → 段階的なコスト試算、上限値の設定

この想定により、コピペチェック結果の精度や処理時間といった、プロジェクトの成否に直結する課題を早期に特定し、対策を講じることができました。

2. スケジュールへの組み込み

課題解決に必要な調査・検証時間を事前にスケジュールに含めることで、後手に回ることを防ぎました。

3. 要件の早期合意

コピペチェックのロジックやアウトプット品質など、要件に直結する箇所は開発に先行して調査を実施。事業部(CSなど)がイメージしやすい資料を作成し、確認・合意を進めました。

4. リリース週の調整

リリース週を事前に事業部と調整し、ヘルプ動画作成やプレスリリースといった事業部側の作業もリリーススケジュールに含めました。

5. 残課題の共有

朝会・夕会で残課題の状況、新しく見つかった課題や懸念点を共有。次の朝会・夕会までにどこまで対応するかを明確にしました。

改善の効果

稼働時間の変化で見る改善効果

実際に、ファクトチェック開発(前半)とコピペチェック開発(後半)でチームの稼働時間を比較すると、明確な違いが見えてきました。

ファクトチェック開発期間(前半)の特徴:

  • 開発終盤にかけて稼働時間が急激に増加
  • 特に開発終盤には一人当たり平均11時間を超える高負荷な日が発生
  • チーム全体の稼働時間が不安定で、予測しにくい状況

コピペチェック開発期間(後半)の特徴:

  • 稼働時間が比較的安定した(一人当たり平均8〜9時間程度)
  • 突発的な高負荷日が大幅に減少
  • チーム全体の作業ペースが一定に保たれた

これら数値からも、改善策の効果が明確に表れていることが分かります。

※赤が濃い箇所が高負荷

プロセス面での効果

  • 作業単位ではなく課題単位で管理したことで、対策の漏れをチームでカバーできた
  • 不確実な要素を早めに排除できたことで、開発の逼迫感が軽減
  • 朝会・夕会でのコミュニケーション機会を増やした結果、過度な残業をするケースがなくなった

実務面での効果

  • 人員的にも時系列的にも負荷が分散できた
  • これまでは新規開発期間中に停止していた運用保守開発やデータ分析などの業務も並行して進められた

今後に向けて

今回の新規開発で確立できた開発フローは、次回の新規開発でも継続していく予定です。

特に「最悪のケースを想定したリスク洗い出し」と「課題単位での管理」は、今後の開発プロジェクトの標準プロセスとして定着させていきたいと考えています。

まとめ

新規機能開発では、技術的な実装だけでなく、不確実性への対処が成功の鍵となります。今回の経験を通じて、事前のリスク想定と早期の課題解決がいかに重要かを改めて実感しました。

同じような開発プロジェクトに携わる方々の参考になれば幸いです。