うちは昔から、他社で炎上したシステム開発を途中から引き継ぐことが多いです。
そのため、案件に入った最初の数日は「なぜこうなったのか」を調べることになります。コードを見る。仕様書を見る。実際の画面を触る。過去の会議記録を読む。お客さんに、本当は何をしたかったのかを聞く。
AIでコードを書く時代になって、実装そのものはかなり速くなりました。弊社が見る範囲では、昔のように単純に「作るのが遅すぎて終わらない」という案件は減ったように感じます。
でも、燃えた案件の原因を調べると、驚くほど昔と同じです。
設計不足。異常系の考慮不足。そして、その根にあるユースケースの定義不足です。
結局、一番上流にあるのは「誰が何をできるのか」が決まっていないこと
炎上案件を見ると、最初は問題がたくさんあるように見えます。
- 画面ごとに挙動が違う
- 権限がおかしい
- エラーになった後の戻り方がない
- 同じ操作を二回するとデータが壊れる
- 入力値の境界で想定外の動きをする
- テストが足りない
- 仕様書と実装が一致していない
ただ、掘っていくと、その多くが一つのところにつながります。
そもそも「誰が、どんな場面で、何をできる必要があるのか」が一覧になっていない。
例えば「申請機能を作る」だけでは足りません。
一般ユーザーが申請する。管理者が承認する。差し戻された本人が修正する。権限のない人は見られない。締切後は申請できない。すでに承認済みなら二重に処理しない。
こういう利用場面を一つずつ出して、初めてシステムの輪郭が見えます。
画面一覧や機能一覧だけでは、ここが抜けやすいです。ボタンがあることは分かっても、誰が、いつ、そのボタンを押してよいのかまでは決まりません。
ユースケースがないと、異常系も考えられない
「異常系」というと、サーバーが落ちた、APIが失敗した、通信が切れた、といった技術的なエラーを想像しがちです。
実際には、それ以外の方が多いです。
- 必須項目が空だったらどうするか
- 同じ申請を二回送ったらどうするか
- 途中で権限が変わったらどうするか
- 別の人が先に更新していたらどうするか
- 対象データが0件だったらどう見せるか
- 上限件数に達したらどうするか
- 外部サービスへの登録だけ失敗したら、どこまで戻すか
これを考えるには、先に通常時の流れが必要です。
「誰が何をする」というユースケースがあって、その正常な流れが決まる。そこで初めて、「途中で失敗したらどうする」「条件を満たさなかったらどうする」を考えられます。
だから自分は、異常系の設計不足も、かなりの割合でユースケース定義不足の結果だと考えています。
ユースケースがないと、テストも定義できない
テスト不足も同じです。
テストは、ただ数を増やせばいいわけではありません。
何が起きたら正しいのかが決まっていなければ、そもそも何をテストすればいいか決められません。
「ユーザーが申請できる」というユースケースがあれば、正常な入力で申請できることを確認できます。
さらに、必須項目がない場合、権限がない場合、締切を過ぎた場合、二重送信した場合、外部連携に失敗した場合まで定義されていれば、それぞれをテストにできます。
逆に、ユースケースがない状態で「テストを増やしてください」と言っても、開発者は今ある実装に対してテストを書くしかありません。
それでは、間違った仕様を正しく実装していることを確認するテストになってしまうことがあります。
要件から受入条件、実装、テストまでをどうつなぐかは、要件定義の完全ガイドでも詳しく整理しています。
AIは、定義されていない業務ルールを勝手に正解にはできない
AI時代になって、この問題はむしろ分かりやすくなったと思います。
AIはコードを書くのが速いです。画面もAPIもテストも、かなりの速度で作れます。
でも、「この会社では、承認後に誰が変更できるのか」「同じ処理を二回したとき、二回実行するのか無視するのか」「エラーになったとき、利用者に何をさせるのか」といった業務ルールは、書かれていなければAIにも分かりません。
それらしい動きは作れます。
でも、その「それらしい」が、その会社にとって正しいとは限りません。
むしろAIで実装が速くなった分、上流が曖昧なまま進めると、間違ったものが速く大量に出来上がる可能性があります。
「AIなら要件定義がいらない」ではなく、AIが実装できる形まで何を作るかを構造化する必要があります。弊社の生成AI受託開発でも、モデル選定より先に、対象業務、利用場面、評価条件を整理するところから始めています。
炎上案件を引き継ぐと、毎回かなり上流まで戻る
今も、止まった案件の巻き取りをしています。
こういう案件に入ったとき、コードのバグだけを直して終わることはあまりありません。
まず、誰がこのシステムを使うのかを洗い出す。次に、その人たちが何をできる必要があるのかを並べる。通常時、エラー時、境界条件を整理する。そこから受入条件とテストを作り直します。
現在の案件でも、自社で開発しているPM on Railsを使って、このユースケースの定義からやり直しました。
PM on Railsでは、要求、ユーザーストーリー、具体的なシナリオ、実装タスク、テスト結果をつなげて管理します。何のための機能なのか、どの条件を満たせば完成なのかを、実装から逆にたどれるようにしています。
以前に引き継いだ再構築案件でも、既存の資料とコードを集め、誰が何をできる必要があるか、通常時と異常時にどう動くかを整理し直してから開発を再開しました。その経緯は1,100万円超が投じられたシステムを、340万円で作り直しても採算が合う理由に書いています。
要件が固まっていないところから、この流れをどう実装とテストへつなぐかは、要件定義から伴走する開発でも紹介しています。
発注するときは、開発会社に「機能一覧」だけを作らせない方がいい
これからシステム開発やAI・DXを発注するなら、見積もりと画面一覧だけで進めない方がいいです。
少なくとも、開発会社に次のものを出してもらうことをおすすめします。
- アクター一覧：誰が使うのか
- ユースケース一覧：その人が何をできるのか
- 正常系：通常はどう進むのか
- 異常系・境界条件：失敗、権限不足、0件、上限、重複などでどうするのか
- 受入条件：何ができたら完成なのか
- テストと証拠：その完成条件を何で確認したのか
これがつながっていれば、途中で人が変わっても確認できます。AIに実装させる場合も、何を正解として作ればいいか渡せます。
逆に、この一覧がなく、「とりあえず画面を作りましょう」「動かしながら考えましょう」だけで進むと、後半で大量の抜けが見つかりやすくなります。
発注側でどこまで決め、開発会社に何を確認すればよいかは、システム開発の進め方 完全ガイド｜発注側のプロジェクト管理にまとめています。これからシステム開発やAI・DXを発注する方には、ぜひ一度読んでほしいです。
作り直しが、一番もったいない
システム開発で高くつくのは、最初にユースケースを整理する時間ではありません。
作った後に、「この人はこの操作をしてはいけなかった」「エラー時の戻り方がない」「そもそもこの業務では使えない」と分かり、画面、データ、API、権限、テスト、運用をまとめて直すことです。
一つの仕様変更に見えても、下流まで作ってしまった後なら、直す場所は何倍にも増えます。
AIで実装費を下げられる時代になっても、作り直しが無料になるわけではありません。
むしろ、作る速度が上がったからこそ、何を作るかを間違えないことの価値が上がっています。
AI時代でも、最初にやることは変わらない
モデルは変わります。開発ツールも変わります。コードを書く速度も、これからさらに上がると思います。
でも、システムを使うのは人です。
誰が、何をしたいのか。どんな条件なら実行できるのか。失敗したらどうするのか。何ができたら完成なのか。
ここを決めない限り、手書きで作ってもAIで作っても、最後は同じところで困ります。
炎上案件を何度も見てきて、結局ここに戻ってきます。
まず、誰が何をできるのかを全部出す。
そこから設計し、異常系を考え、テストに落とす。
地味ですが、これが一番安いです。