📌前提条件

すでに稼働しているベースのシステムがある。

そこに対して、機能の「追加」や「変更」の設計を行う。

❌ 絶望1：概要設計を絶対に信じるな

「概要は、あくまで概要」です。要件がふわっとしすぎています。
それを真に受けて基本設計を進めると、後々絶対に痛い目に遭います。

概要から詳細に落とし込むときに、本来なら以下の情報を握っておかなければなりません。

・概要の目的・背景（なぜこの改修が必要になったか？）

・顧客のシステム理解度と温度感（システムを魔法か何かだと思っていないか？）

・ベースシステムのどこに影響するか（既存のどこを変えて、どこに問題が出るか？）

ですが、「概要段階だから詳細は後で詰めればいいじゃん🎵」というノリで作られた概要書からは、これらの情報は1つも得られないのがザラです。そんな状態で進めれば、後半に必ずボロが出ます。

例えば「1つの画面で項目を追加・変更した」とき、実は「別の画面」にも同じ変更が必要なケースがあります。

これが考慮漏れになる原因は「タスクの分断」です。

別の人が隣の画面を設計している。

自分自身が設計していても、概要書に記載がない。

個別にタスクが振られ、レビューも別々で実施されている。

これでは、自分の担当箇所がどこに影響しているか気づきようがありません。
レビューしてくれる人が、気づけばいいがそんなことあるのかな。

💡 対策：画面間の「共通項目対比表」を作る
画面ごとに共通項目があるか判断するための対比表が不可欠です。

⚠️ ここが落とし穴！

同じ項目なのに、入力形式が違う（プルダウンとテキストボックスなど）

同じ項目なのに、画面によって名前（ラベル）が違う

これらを横並びで確認できる対比表がないと、「画面ごとに共通項目がある」という事実にすら気づけません。

プロジェクトに参画した際、全体像やインフラ、環境の説明はほぼされず「全体の1/10くらいしかない資料」だけを渡されて「全体を把握して設計しろ」と言われることがあります。

インフラや外部連携について何も決まっていないのに「そこと紐付ける設計書を作れ」と言われても、超能力者ではないので不可能です。全体像がわからないから、画面間の共通項目にも気づけず、結果として考慮漏れの設計書が量産されてしまいます。

仕様の正解を知っているのは、大体マネージャーレベルの数少ない有識者だけです。
要件定義をした張本人たちですが、現場への落とし込みが浅く、問題山積みのまま設計者に丸投げされます。

設計者は必死に問題点を洗い出して質問しますが、マネージャーは忙すぎていつも時間が空いていません。

聞き出さないと進まないのに、話す時間がない。

いざ話せても、ドキュメント化された「図（業務フローやインフラ図）」がない（あるいは大枠すぎて荒い）ため、詳細な理解ができない。
言葉で矢継ぎ早に説明されても、理解が追いつかないことも多い。

仕様を簡単に図解して、サクッと編集できる共有ツールがあれば、
理解のアウトプットが容易にできるため、切実に欲しいところです。

足りない理解を必死に整理し、考え抜いた設計書を上司に提出しても、レビューで見てくれるのは「大枠の構成」や「てにをは（文字欠如）」くらい。本質のロジックや設計レベルまでは見てくれない気がしています。

それは顧客側も同じです。全く整合性が取れていない設計書でも、タスクの合間に確認しているためか、スルーして「OK」を出してきます。顧客も別の本タスクがあってその合間に確認しているのだから当然ではあるのだが。

複雑な制御の場合、「これで完璧だ」と思って設計書を書いても、「実際にコードを書いて動かしてみるまで、考慮漏れに気づけない」という限界があるのも事実です。ここをレビューの段階で100%抑え込むのは、かなり難しいと感じています。

ここでは、問題点を挙げましたが対策も必要です。
ですが、現段階ではそれは見つからない。改善点は上げることはできるけど。