他社へ依頼していた業務システムの開発が止まり、Beekleで引き継いだ案件があります。
残っていたのは、完成していないシステム、途中の資料、会議記録、見積もり、顧客側の要望でした。何ができていて、何が未完成で、どこから直すべきかを説明できる一枚の仕様はありませんでした。
私は最初に新しい機能を作るのではなく、既存資料とコードから要求、具体的な利用場面、未確認事項を取り出し、PM on Railsへ組み直しました。要件の再整理にかかったのは三日余りです。その後、一つの二週間の開発サイクルを回し、PM on Rails上の管理進捗は約六〇％まで進みました。
速くなった理由は、生成AIがコードを書いたことだけではありません。何を作り、どう動けば完成かを先に結び直したことです。
引き継ぎ直後は、進捗率より「何を正解とするか」が分かりませんでした
止まった案件を引き継ぐ時、既存会社が示した進捗率をそのまま信じることはできません。画面があること、コードがあること、顧客が使えることは別だからです。
この案件でも、資料に書かれた要望、実装済みの画面、顧客が期待している動きの間に差がありました。そこで、まず次を分けました。
- 顧客が実現したいこと
- 利用者が実際に行う場面
- 現在のコードで動くこと
- 未実装のこと
- 動くが要望と違うこと
- 顧客に確認しなければ決められないこと
この区別がないまま開発を続けると、直した機能の数は増えても、完成へ近づいたかを判断できません。
既存資料を読み直すだけでなく、コードと画面へ突き合わせました
要件の再整理では、会議記録や仕様書だけをまとめ直したわけではありません。文章に書かれた要求を、実際の画面とコードへ一つずつ突き合わせました。
資料にあるが実装されていないものは未実装、実装されているが資料と違うものは差分、どちらにも根拠がないものは確認待ちとして分けました。判断できない箇所を、こちらの推測で完成扱いにはしませんでした。
PM on Railsでは、この結果を「何を実現したいか」「誰が何をしたいか」「どんな場面でどう動けばよいか」「何を作業するか」「何を確認したか」の順でつなぎました。
この作業により、開発者と生成AIに渡す単位が、曖昧な機能名ではなく、確認可能な利用場面になりました。
私の役割を、すべての実装ではなく設計と確認に絞りました
引き継ぎ案件では、私が全部のコードを書く方法も取れます。しかし、それでは案件が進んでも、会社の処理能力は私の時間に固定されます。
この案件では、私は主に要求と設計の確認、優先順位、顧客との認識差の判断を担当しました。実装は開発メンバーと生成AIに引き継ぎ、PM on Railsで作業と確認結果を追いました。
生成AIへは、単に「この機能を作って」と渡しません。対象となる利用場面、正常時、異常時、境界条件、既存コード、完了条件を一緒に渡します。実装後は、テスト結果や画面など、動いたことを確認できる証拠を残します。
私が見るのは、コードの行数ではなく、顧客と合意した利用場面が動いたかどうかです。
追加要求は、作業に入れる前に元の範囲と分けました
止まった案件では、引き継ぎ後にも新しい要望が出ます。小さな変更をそのまま作業へ混ぜると、当初の再構築に必要な工数と、新しく増えた工数が分からなくなります。
そこで、変更が出た時は次を残しました。
- 何が変わったか
- 当初から必要だったのか、後から増えたのか
- どの利用場面へ影響するか
- 工数、期限、金額への影響
- 今回入れるか、後へ送るか
- 誰が判断したか
これにより、開発が遅れた時に「作業者が遅い」で終わらず、見積漏れ、追加要求、認識差、手戻りを分けられます。
約60％は、完成率ではなくPM on Rails上の管理進捗です
この案件で示した約六〇％は、顧客が本番で利用できる状態が六〇％完成した、という意味ではありません。PM on Railsで定義した対象作業のうち、完了として確認できた割合です。
進捗率は、分母をどう決めるかで変わります。途中で要求が増えれば分母も変わります。そのため、数字だけでなく、完了した利用場面、未確認事項、顧客確認待ち、残る重大なリスクを一緒に見ます。
開発の速さを強調するために、確認前の機能を完成へ数えないことも重要です。
費用を抑えられたのは、作る範囲を決め直したからです
元のシステムは、一〇〇〇万円を超える規模で進められていました。Beekleでは案件の事情も踏まえ、その半分程度の予算で引き継ぎました。
同じものを安く作り直した、という説明ではありません。既存のコードと資料を使える部分は残し、直す部分と捨てる部分を分け、重要な利用場面から順に再構築しました。生成AIの開発支援も使いましたが、費用差の中心は、対象範囲と確認方法を整理し直したことです。
安く受ければ、どの案件でも利益が出るわけではありません。今回の条件が他の案件へそのまま当てはまるとも限りません。引き継ぎ前に、コードの状態、権利関係、資料、試験環境、顧客側の協力を確認する必要があります。
この案件はまだ完了事例ではありません
三日余りの要件再整理と、二週間で管理進捗約六〇％という数字は、途中経過です。システムの本番運用、顧客成果、保守負担まで確認して初めて、立て直しが成功したと言えます。
案件完了後には、お客様へ、引き継ぎ前後で何が変わったか、説明や確認の負担は減ったか、品質と速度をどう感じたかをインタビューする予定です。
現時点で確認できたのは、止まった案件でも、既存資料とコードを捨てず、要求から動作証拠までを組み直せば、開発を再び進められることです。
Beekleにご相談ください Beekleでは、AI活用や業務システム開発について、作るものの整理、費用感、進め方まで一緒に確認します。まだ曖昧な段階でも、最初に何を決めればよいかから相談できます。