開発途中の仕様変更、どう進める？
ソフトウェアの開発中に、必要な処理の不足や、当初の方法では業務に合わない点が見つかることがあります。ただし、作業を追加する前に、何を修正するのか、費用は増えるのか、予定は変わるのかを双方で確認しておく必要があります。
この記事では、配送先の変更という架空の例を使い、要望の受付から修正版の確認までを説明します。企業側の担当者と開発側が、実施する内容、判断する人、完了とする条件を共有するための進め方です。
1. 何を、なぜ変えたいのかを確認する
ソフトウェアの変更を求められたら、まず利用者が何に困り、何を変えたいのかを双方で確認します。
例えば、担当者が注文を登録し、管理者の承認後に倉庫が出荷準備をするシステムを考えます。試用中に、承認後でも配送先を変えたい顧客がいるため、営業から「再承認ボタンが欲しい」と要望が出ました。ただし、先に決めるべきなのは、どの段階まで住所を変更でき、倉庫へ新しい住所をどう伝えるかです。対応の流れが決まらなければ、ボタンを追加しても問題は解決しません。
次に、これまでの合意内容と照らし合わせます。対応すると決めていたのに使えない場合は、要件を満たしていない箇所を確認して修正します。新しい要望なら、追加で必要な作業を整理します。資料の書き方が曖昧な場合は、時間や費用を話し合う前に認識をそろえる必要があります。
要望が明確になったら、開発側が修正箇所を洗い出し、ほかの機能やデータへの影響を調べます。
2. 要件の変更に伴う修正箇所を洗い出す
住所変更では、状況ごとの対応を決めます。例えば、運送会社への引渡し前なら営業が変更を申請し、倉庫は住所の確認が取れてから作業を再開します。引渡し後なら配送担当者へ依頼を回します。この対応が実際の業務に合うかは、企業側で確認する必要があります。
合意した流れをもとに、開発側は画面の住所、出荷伝票、倉庫への通知、配送サービスへ送るデータを確認し、修正箇所を特定します。画面が新しい住所でも、印刷済みの伝票が古いままなら誤配送につながります。「再承認」ボタンだけでなく、関連する情報や処理も確認することが大切です。
新しいルールを更新後の注文だけに適用するのか、出荷待ちの注文も含めるのかも確認します。既存の注文を含めるなら、保存済みデータと、新しい処理へ移す方法を開発側が調べる必要があります。利用前の担当者への案内も必要です。これらも時間や費用の見積りに含める作業です。
要望が明確であれば、開発側も必要な修正を具体的に検討できます。情報の整理方法は、要件分析とは？開発を明確に進めるための第一歩で紹介しています。
3. 対応方法、費用、承認者を決める
必要な修正が分かったら、対応方法を比較します。住所変更の申請と再承認を一通り開発する方法もあれば、倉庫の作業前だけ変更を認める方法もあります。公開予定を維持し、当面は担当者が変更の受付と処理を行う方法も考えられます。
それぞれに検討すべき点があります。一通り開発するなら設計と試験の時間が増えます。変更可能な段階を限定すれば開発を抑えられる場合がありますが、個別対応が必要なケースは残ります。手作業ならすぐにシステムを直さずに済む一方、担当者の負担が増え、管理が不十分だと見落としも起こります。依頼の発生頻度、誤った場合の影響、担当者が対応できる量を踏まえて判断します。
選ぶ前に、各案にかかる時間、費用の変更、予定済みの作業への影響をパートナーに確認します。見積りに必要な情報が足りなければ、追加調査の内容と回答時期を決めます。初期の概算は案を比較するためのものであり、完了日を確約するものではありません。
範囲や費用が変わる場合は、見積書にも変更内容を明記してもらいます。
依頼者は変更の必要性を説明し、技術側は作業とリスクを評価し、権限のある人が対応方法、予算、実施時期を承認します。複数部門から依頼が出る場合は、取りまとめ役が承認済みかどうかを確認してから開発側へ伝えます。検討中の要望が、そのまま着手指示として受け取られるのを防ぐためです。
4. 決定を記録し、対応の結果を確認する
承認後は、変更内容を共通の管理一覧に記録します。実施すること、今回は含めないこと、承認者、合意した時間と費用を明記します。保留や見送りの理由も残し、必要なときに判断の経緯を確認できるようにします。
関連する要件、受入条件、操作手順も更新します。開発、試験、サポートの担当者が、同じ最新版を使うようにします。チャットで決めただけで資料を直さないと、古い要件に沿って作業が進んでしまうことがあります。
修正を始める前に、確認方法を合意します。住所変更なら、変更可能な注文、運送会社へ引渡し済みの注文、同じ申請を二度送った場合などを試します。倉庫に承認済みの住所が届くこと、承認待ちの間は元の住所が残ること、再送で申請が重複しないことを確認します。これらの場面は、実際に選んだ対応方法に合わせて調整する必要があります。
修正版を受け取ったら、機能が表示されるかだけでなく、合意した場面で動作を確認します。システムの受入テスト、何を確認する？
進捗は「承認済み」「修正済み」「確認済み」を分けて管理します。緊急対応では、誰が修正を認め、どこを先に直し、何を追加確認するかを記録します。目の前の問題が解消しても、残った作業を完了まで追う担当者が必要です。
修正版を使い始めたら、元の問題が解消したか、手作業がまだ必要かを利用者に確認します。新たな要望は別の依頼として記録し、以前のどの変更に関係するかを明記します。完了したことと残ったことを把握し、予定や範囲が変わった理由も説明しやすくなります。
複数部門から要望が集まっているなら、共通の一覧と取りまとめ役を決めるところから始められます。具体的な要望をもとに、必要な修正、プロジェクトへの影響、進め方をFenixと一緒に整理できます。
