Web改修で困らないためのベンダー選定と設計書作りのポイント

最近増えている相談のひとつに、「過去に低コストで外部ベンダーに作成したシステムを改修したいが、設計書が残っておらず、担当者の退職やベンダー交代により改修が進められなくなった」というケースがあります。多くの場合、原因は技術そのものではなく、発注時の条件と成果物の揃え方にあります。
背景には「業者を見つける難しさ」と「品質とコストのトレードオフ」があり、価格を優先した結果として、設計書や標準化、運用に必要な成果物が後回しになりやすい構造があります。

この記事では、こうした状況が起きる理由を整理し、ベンダー選定時のコツと、同じ課題を繰り返さないための発注・設計・運用の考え方を解説します。

相談で多いのは「システム自体は動いているが、仕様が分からず変えられない」という状態です。具体的には、改修要望が出たものの、担当者やベンダー変更でシステムの仕様を理解している人が誰もいなくなり、検討が進まなくなるケースです。

現状の仕様が設計書として残っていないため、関係者が「何が正しい仕様か」を確認するところから始まります。次に、影響範囲を見積もるための材料が不足しているので、調査範囲が広がります。さらに、検証の基準や手順が定義されていないため、確認項目が増え、差し戻しが起こりやすくなります。結果として、作業量だけでなく関係者調整も増え、改修判断が遅くなります。
この状態は、技術力の問題というより「判断材料が残っていないこと」が引き金になっています。

価格が低い提案が悪いわけではありません。ただ、見積の内訳を見ると、削られやすいのは「動かすために最低限必要なもの」ではなく、「動いた後に維持するためのもの（運用）」です。

たとえば設計書は、画面の一覧や仕様の説明だけではなく、例外条件、判断基準、連携の責任範囲、運用手順まで含めて初めて保守に効きます。しかし、この範囲を揃えるには一定の工数が必要です。標準化（命名規則、共通処理、レビュー観点の統一）や、ログ設計、監視、復旧手順も同じです。
初期費用を下げて開発する場合、これらが「後でもなんとかなるもの」として扱われがちです。その結果、運用フェーズに入ってから確認作業や調整が増え、トータルの運用工数が増えるケースが起こります。

ベンダーを比較するとき、機能や画面イメージは見比べやすい一方で、長期運用の差は見えにくくなります。ここで効くのが「成果物を先に定義し、成果物で比較する」という考え方です。
ポイントは、設計書を「納品するかしないか」で聞くのではなく、「その設計書があることで、何を決められるようになるのか」を確認することです。たとえば、運用体制の役割分担、改修の進め方、障害時の切り分け手順、追加開発の見積根拠まで説明できるか、という観点です。

保守性に効く設計書は、少なくとも次の問いに答えられる状態を作ります。

• どの画面で、どの手順を通り、どんな例外があるか
• 主要データの意味と、更新タイミングは何か
• どの外部連携があり、どこまでがどちらの担当範囲か
• 性能・セキュリティ・運用体制の前提（許容値や手順）は何か
• リリース、一次対応、復旧の手順はどうなっているか

これらが追える形で残ると、担当変更が起きても「仕様確認→影響範囲見積→検証計画」の流れを作りやすくなります。

標準化（チームで共通として固めやすい箇所をまとめること）は、開発速度よりも「人が変わっても判断が揺れない」ことに効きます。
たとえば命名規則、共通処理（認証・エラー・ログ）、レビュー観点、テスト方針が揃っていると、改修時の確認の仕方が一定になります。逆にここが揃っていないと、改修のたびに調査観点が増えやすくなります。

比較の場では、次のような質問をすると、思想と成果物のイメージが見えやすくなります。

• 影響範囲の見積りは、どの情報を根拠に行いますか
• 例外条件はいつ洗い出し、どの成果物に残しますか
• レビュー観点は誰が定義し、運用でどう維持しますか
• 引き継ぎで必要になる資料と手順は何ですか

このとき、抽象的な回答だけで終わる場合は、成果物サンプルやテンプレート、運用資料の想定を求めると判断が進みます。

選定が終わっても、納品条件と受け入れ条件が曖昧だと成果物が揃いません。再発防止の観点では、発注時に次の3点を明文化するのが有効です。

・納品物（成果物）の範囲を明文化する
設計書は「初回に作って終わり」ではなく、改修時に更新される前提が重要です。標準化の範囲（命名、構成、レビュー観点、テスト方針）と、運用成果物（ログ設計、監視、一次対応・復旧手順）も、納品対象として明確にしておくと後工程が安定します。

・受け入れ条件を“確認可能な形”にする
非機能要件（性能、セキュリティ、運用）の許容値や、検証範囲と完了条件を、確認可能な形で定義します。ここが曖昧だと、受け入れ時の判断が割れやすく、差し戻しが増える要因になります。

・引き継ぎ前提を条件に入れる
引き継ぎ会の回数と対象（運用担当・開発担当）を決め、変更時に「誰が何を見て判断するか」を手順として残します。例外時の最終判断者を最上位管理者として定義するかどうかも含め、判断が止まりにくい形にします。

発注の前に自社側の前提が揃うと、提案内容と見積の比較が安定します。特に、目的、対象範囲、体制（承認と最終判断）、非機能要件、連携、運用（ログと一次対応）の前提を棚卸ししておくと、後から増えやすい確認作業と関係者調整を抑えやすくなります。

棚卸しの狙いは、完璧な要件定義を作ることではありません。「何を決めれば比較できるか」を先に揃えることです。ここが揃うほど、価格だけでなく、成果物と運用の観点でベンダーを見比べられるようになります。

「動くものを作る」だけなら、短期の判断で進めることもできます。しかし、Webシステムは運用が続くほど「変更できる状態」に価値が移ります。だからこそ、設計書・標準化・運用成果物を前提に、成果物でベンダーを比較し、納品条件と受け入れ条件を明文化しておくことが重要です。

LYZONでは、長期運用まで考慮した設計書作成、標準化の方針検討も含めたご支援が可能です。Webの改修を検討しているものの、現状の把握や判断軸の整理でお悩みの方はぜひ一度ご相談ください。