開発ノート：要件定義の曖昧さが招いた追加費用の失敗と実践的対策

プロジェクト背景と狙い

私は中小企業の社内SEとして、新規顧客管理システムのリプレイスPJを担当しました。従来のExcel運用に限界を感じ、初めてシステム 開発会社 選び方から始め、予算枠内での効率的な導入を目指したのです。クラウド型Webアプリを採用し、初期費用を抑えつつ将来的な機能追加を見据えたスコープを設定しました。しかし、要件定義の段階で曖昧なまま進めた結果、想定外の追加費用が発生し、予算オーバーの危機に直面しました。

要件定義の落とし穴と失敗例

要件定義で最も大きな誤りは、業務フローを口頭ベースでまとめただけだったことです。

• 顧客データの入力項目が細かく変動する点を見落とし

• イレギュラー対応（電話・メール併用）部分の想定を甘く見積もり

• 画面遷移パターンをドキュメント化せず
  これらの要因が重なり、開発中に「追加画面」「カスタム帳票対応」といった想定外作業が発生。結果的に費用 相場以上の見積が必要となりました。

失敗から得た教訓：ドキュメント化の徹底

口頭やExcelだけの記録では抜け・漏れが発生しやすいのは自明です。そこで学んだのは、以下のポイントでした。

1. 業務フロー図の作成：Visioや手書きでも構わないため、必ず「誰が」「何を」「どのタイミングで」行うかを図示。

2. ユースケース定義：主要な操作シナリオをユーザ視点で洗い出し、シナリオごとに必要な機能をリスト化。

3. 要件変更管理フロー：仕様変更時の評価基準（工数／影響範囲）と承認ルールを事前合意。
   これらを厳密に進めたことで、２回目以降のシステム 開発会社 選び方では見積もり精度を大幅に高められました。

コミュニケーション改善で予算管理

社内SEと開発ベンダー間の認識ギャップがコスト増の一因でした。特に以下の手法で改善を図ったところ、次フェーズでは大幅なコスト削減に成功。

• 定例すり合わせ会議：週1回の定例に加え、課題発生時の臨時MTGを設定

• オンラインホワイトボード活用：Miroなどでリアルタイムに画面イメージを共有

• 進捗可視化ツール：BacklogやJiraのガントチャートでタスク状況を公開
  これにより、「発注→見積→開発→レビュー」のサイクルが回りやすくなり、予定外の追加費用を未然に防げました。

ベンダーとの役割分担と契約条項

契約書段階で「仕様確定前の調査工数」「要件変更時の単価・手数料」を明示しておかなかったため、後から高額請求を受けました。以降は、以下を必ず盛り込んでいます。

• 調査・PoCフェーズの定義：要件確定前の試験的作業は別途見積もり

• 変更管理手数料：変更1項目あたりの定額手数料と時間単価

• 成果物納品形態：ソース納品／ドキュメント納品／動作確認項目リスト
  これにより、予算管理の透明性を高め、後続の交渉もスムーズに運びました。

テスト設計の失敗と再設計

最初のプロジェクトでは「開発完了後テスト」という流れで進めた結果、不具合が多発。修正対応のたびに追加コストが膨らみました。
そこで、次回から取り入れたのが以下のテスト戦略です。

• 単体テスト駆動開発（TDD）：コード品質を維持しつつデバッグ工数を削減

• 結合テストケースの早期作成：要件定義フェーズでテストケースを反映

• 自動テスト導入：Selenium／Cypressで回帰テストを自動化
  結果、自動化の初期投資は発生したものの、長期的には費用 相場を下回る品質維持コストを実現しました。

CI/CD導入でリリース管理を最適化

リリース作業が手動だと、ミスや遅延が頻発して追加作業が発生します。そこでGitHub Actionsを使ったCI/CDパイプラインを整備し、

1. プルリクエスト→自動ビルド＋自動テスト

2. ステージング環境への自動デプロイ

3. 本番環境への承認フロー付きデプロイ
   というプロセスを構築しました。この仕組みにより、リリースミスによる緊急対応コストをほぼゼロに削減でき、発注先にも高評価を得ました。

運用フェーズの保守体制の整備

プロジェクトがローンチしたら、開発会社との切り分けを明確にした“保守体制”を構築します。まずは次の３点を中心に進めましょう。

• 監視基盤の導入：CloudWatch／Azure Monitorでアプリケーションやインフラのメトリクスを収集し、CPU負荷やエラー率の閾値を超えたら自動アラートを発報。

• 定期レポートの自動化：週次・月次で「リクエスト数」「平均処理時間」「エラー発生割合」「コストトレンド」をダッシュボード化し、関係者へ自動配信。

• 運用マニュアル・Runbook整備：障害発生時の対応フローや再現手順をドキュメント化し、チーム間で常に最新版を共有。

これらを揃えることで、「何が」「いつ」「誰に」アラートを流し、誰が対応するかが明確になります。特にクラウド従量課金では、障害によるリトライ連鎖でコスト増が起こりやすいため、アラートから対応完了までの時間（MTTR）を短く抑えることが予算管理上も重要です。

インシデント対応とSLA管理

運用中の問題をいかに迅速に解決するかは、サービス品質の要です。開発会社との契約段階で以下を定義しておきましょう。

1. SLA（Service Level Agreement）：障害対応の最優先度（P1/P2）ごとに「初動対応時間」「復旧までの上限時間」を明記。

2. エスカレーションフロー：定例窓口／オンコール体制を明確化し、対応漏れを防止。

3. フィードバックループ：インシデント後に振り返り（Postmortem）を行い、原因究明と再発防止策を社内SEとベンダーで共有。

これらを契約書とRFPに落とし込むことで、万一の障害発生時もコストを無駄に増やさず、かつサービスレベルを担保できます。ベンダー選びでは、過去のSLA達成実績やオンコール体制の柔軟性も評価基準に含めてください。

継続的改善（PDCA）具体手法

運用が始まったら終わりではなく、PDCAサイクルを回し続けることが成功の鍵です。以下のステップを定期的に実行しましょう。

Plan：改善項目の設定

• 運用レポートをもとに「コスト高騰リソース」「エラー傾向」「パフォーマンス低下箇所」を洗い出し、優先度順にリスト化。

Do：改善策の実行

• キャッシュ戦略：頻繁に呼び出されるAPIはRedisやCDNキャッシュでオフロードし、サーバーレス実行回数を削減。

• メモリ／タイムアウト調整：Lambdaのメモリ割当をチューニングし、実行時間短縮とコスト最適化を両立。

Check：効果検証

• 改善前後のメトリクスを同じ条件下で比較し、「コスト削減率」「レスポンスタイム改善率」「エラー率削減率」を可視化。

Act：標準化・次フェーズ計画

• 有効だった施策を運用マニュアルに追加し、次期開発フェーズでの要件として反映。

このサイクルを四半期ごと、あるいは大規模リリース後に必ず回すことで、累積的にコスト削減と品質向上を実現できます。

コスト評価モデルと最終チェックリスト

最後に、これまでの取り組みを振り返り、コストと発注ベンダーを評価するモデルを提示します。

サーバーレスコスト評価モデル

ベンダー評価チェックリスト

• 要件定義力：業務フロー図・ユースケースを自社SEと共同で作成した実績

• 設計能力：アーキテクチャ設計書の完成度、セキュリティレビュー実施状況

• 開発品質：TDD／自動テスト導入率、バグ発生件数と対応スピード

• 運用支援：SLA達成率、オンコール体制とインシデント対応履歴

• コストマネジメント：予算内完了率、コスト削減施策提案の有無

これらを定量的に評価し、次回プロジェクトのシステム 開発会社 選び方に役立ててください。最後にもう一度