【ソフトウエアエンジニア編】“伝えたつもり”が実は伝わっていない問題の回避策

はじめに

「エンジニア」とひと口で言っても、ソフトウェアエンジニア、フロントエンドエンジニア、サーバーエンジニアなどなど、その種類は多様で、それぞれ現場で起こりやすいトラブルも異なってきます。

本連載ではPMOとして多くの開発現場を経験し、課題解決のサポートをしてきた甲州が、さまざまなエンジニアの現場をクローズアップしながら、よくあるトラブルの解決策や回避策を深掘りしていきます。

第1回目の舞台は、ソフトウェアエンジニアの現場です。システム開発において、プロジェクトの成否を左右する極めて重要な「土台」となるのが要件定義や基本設計です。ところが、上流工程で「決まったはず」の内容が、開発が進むにつれて「伝えていた内容と違う」「この機能は実は不要だった」などと覆され、結果として大量の手戻りが発生し、納期遅延やバグの原因となるケースは少なくありません。

では、開発前に固めたはずの要件定義は、なぜ形骸化してしまうのでしょうか。

PMO(Project Management Office)の視点から、ソフトウェアエンジニアが直面しやすい要件定義の落とし穴と、そうした事態を回避する方法策を分かりやすく解説します。現場リーダーを任されたエンジニアがPMOの視点を取り入れることで、開発現場はどのように変わるのか。実際の失敗事例をもとに、そのヒントを探っていきましょう。

要件定義が形骸化する最大の要因は
業務フローへの圧倒的な理解不足

ソフトウェアエンジニアが開発対象となる業務フローを十分に理解しないまま開発を進めると、要件定義は「机上の空論」となり、形骸化してしまいます。

よくある失敗例として、クライアントと以下のようなやり取りをしているケースが挙げられます。このような場合、後々トラブルに発展する可能性が高くなります。

このように、具体的な内容を十分に詰めないまま要件定義を確定してしまうと、それをもとに作成された基本設計書は、往々にして「歯抜け」になってしまいがちなのです。

歯抜けな設計書をもとに開発を始めると、後々「このケースではどう処理するのか」「このデータはどこから取得するのか」といった疑問が生じるでしょう。そこで慌ててクライアントに確認すると「そういう意図じゃなかったんですよね」「実はこういう例外パターンもあって」─というように、修正指示や追加要望が相次ぐことも珍しくありません。

その結果、設計書の修正を何度も繰り返すことになり、大量の手戻りやバグの発生、さらには納期遅延といった最悪の事態へと発展していきます。このような事態を防ぐには、エンジニアが単に「言われたことを了承する」のではなく、開発対象となるシステムの一般的な業務フローを理解しておくことが重要なポイントとなります。

業務フローの「標準」を知ることが重要

ソフトウェアエンジニアは、クライアントの要望をシステムに翻訳するプロフェッショナルであるべきです。そのためには、業界やサービスに共通する標準的な業務フローを把握しておきましょう。

以下は多くのエンジニアがイメージしやすい例を記載しましたが、関わっている業界や自社のシステムが関係する業務領域はすべてが一般化、標準化できるはずです。改めて自社システムが扱っている業務領域を振り返ってみましょう。

• ECサイトの場合
  商品の閲覧→カートへの追加→配送先の入力→決済処理→注文完了。
  さらに、バックエンドで倉庫へデータが連携されるまでの一連の流れを把握していることが重要です。
• 会計システムの場合
  見積書作成→契約書作成→発注書作成→請求書作成。
  加えて、それらに付随する添付書類が、どのタイミングで作成され、誰の承認を経て、どのように保管されるのかといったタイムライン全体への理解が求められます。

これらを把握していれば「この業務と次の業務の間には、一般的には〇〇の処理が必要ですが、御社ではどのように対応されていますか?」といった確認が可能になります。その結果、クライアントの指示だけでは抜け落ちている部分を洗い出し、歯抜けを防ぐための質問を能動的に行えるようになるのです。

【トラブル回避策】業務フローをドキュメント化して
ヒアリングに臨む

「曖昧な要件」や「設計の抜け漏れ」を防ぐ最も有効な対策は、ヒアリング前に業務フローを可視化し、ドキュメントとして準備しておくことです。

ここで言うドキュメントとは、詳細な設計書ではありません。それよりも一段階抽象度の高い「業務の流れ」や「情報の流れ」を整理したメモやフロー図など、簡素なもので十分です。具体的には、次のような内容をアウトプットしておきます。

• 一般的な業務の流れ(前述のECサイトや会計システムの例)
• 一般的なデータの流れ(どこで発生し、どこに蓄積されるのか)
• 一般的な条件分岐(Aの場合は◯◯、Bの場合は△△など)

これらを事前に可視化しておくことで、要件定義の精度は大きく向上します。真っ白なノートを手に「何か困っていることはありますか?」と尋ねるのではなく、一般的な業務フローをドキュメントとして提示し、「通常はこのような流れになりますが、相違はありませんか?」と問いかけることが重要です。

「事前のドキュメント化」は
明確な合意を生み出す

多くの現場では「打ち合わせ→業務フローのドキュメント化→要件定義」という順で業務フローの整理が行われています。しかし、実はこの順番こそが「伝えたつもり」を生む元凶となっています。

人は、目に見えない概念について議論すると、無意識のうちに自分に都合の良い解釈をしてしまいがちです。また、クライアントは日常業務で彼らにとって当たり前になっている工程や判断を、無意識に省略してしまうことも少なくありません。

その結果、認識のズレや説明不足が生じ、ヒアリング時には合意しているように見えても、実態は「不明確な合意」にとどまってしまうのです。

そこで重要になるのが、ヒアリング前のドキュメント化です。エンジニア主導で業務フローを作成し、それを叩き台として議論を進める「業務フローのドキュメント化→打ち合わせ→要件定義」というプロセスこそが「伝えたつもりが伝わっていない」というトラブルを防ぐ有効な手段となります。

業務内容を可視化した状態で打ち合わせに臨むことには、大きく分けて3つのメリットがあります。

1. 「歯抜け」の早期発見：
   業務内容を書き起こす過程で「ここのデータはどうやって繋がるんだ?」といった疑問が自然と湧いてきます。自分の中で論理がつながらない部分は、後に「歯抜け」として問題化する可能性が高い箇所です。打ち合わせ前にそれらを発見できるため、ピンポイントで深いヒアリングが可能になります。
2. 認識のズレの即時可視化：
   可視化されたドキュメントを前にすると、クライアントは「いや、うちはこの後に承認ステップがもう一段階ありますよ」といった具体的な指摘をしやすくなります。言葉の肯定理解のズレも、その場で解消できます。
3. 議論の拠り所(ベースライン)の確立：
   一度ドキュメントとして提示し修正を重ねた内容は、そのまま要件定義の土台となります。全員が同じ認識を共有した状態で議論を進めることで、後になって「そんなことは言っていない」というちゃぶ台返しを防ぐ強力な抑止力になります。

ヒアリングでは単にクライアントの要望を聞き取るだけでなく、「動くシステムの論理的な裏付け」を共に構築するという意識を持って臨むことが重要です。

【トラブル改善】要件定義の形骸化に気づいたら
全体像の見直しから始める

要件定義がうまく機能していないプロジェクトの多くは、全体像を把握・管理できていないことに起因します。

例えば、会計システムのような複雑な領域では「請求書の発行画面をどうするか」といった部分的な要件は定義されていても、「入金確認と消込の整合性をどのように担保するか」といった全体視点の要件定義が抜け落ちているケースはよくあります。このようなトラブルは、業務一覧の可視化と管理方法の見直しによって改善できます。

業務一覧を徹底的に可視化し
管理表を正しく活用する

要件定義の形骸化に気づいたら、まずは定義すべき業務・要件をすべて洗い出すことから始めましょう。例えば、プロジェクト全体で定義すべき要件が100個ある場合、次のようにユニット単位で分解して可視化します。業務や要件の粒度をそろえることが理想ですが、それよりも洗い出すことを優先して構いません。

• 要件No.1：会員登録フロー
• 要件No.2：ログイン認証
• 要件No.3：パスワード再発行

各要件を1つずつ整理した後は、進捗状況の管理方法も重要になります。「要件定義書の進捗は?」と聞かれた際に「未完了なので0％」「完成したので100％」といった2択の管理では不十分です。

要件を章や機能単位でさらに細分化し「決めるべき項目がどこまで消化されているか」を追える状態にすることで、初めて管理表が本来の役割を果たします。

【Tips】過去の業務をテンプレート化して
業務効率上げよう

私がソフトウェアエンジニアの現場でよく目にするのは、毎回真っ白なファイルからドキュメントを作成している非効率な状況です。多くのソフトウェアエンジニアは会計・EC・物流など、担当する業務領域がある程度固定化されていると思います。それにも関わらず、新しいプロジェクトが始まるたびに要件定義をゼロから作成するのは、非常にもったいないと言えます。

プロジェクト管理を効率化し、失敗を未然に防ぐための強力な手段が「ナレッジ(過去の業務内容)のテンプレート化」です。これは単に過去のドキュメントをフォルダに保存しておくことではなく、次のような取り組みを指します。

• テンプレート化：ヒアリングシート、基本設計書の構成案、非機能要件のチェックリストなど、標準フォーマットを用意する
• 標準化：用語の定義や業務フロー図の記載ルールを統一する
• 成功事例(骨子)の抽出：過去に成功したプロジェクトから「要件の網羅性」を抽出し、新規プロジェクトの叩き台として活用する

こうしたテンプレート化を徹底できている企業やチームは、実はそれほど多くありません。だからこそ取り組む価値があり、実践できれば大きな成果につながります。

テンプレート化は
「上流工程の抜け」を防ぎやすくする

例えば、会計システムのプロジェクトを新たに担当することになった場合、過去の成功事例をもとにした「会計システム要件定義テンプレート」が用意されていたらどうでしょうか。

「見積書から発注書への遷移において、端数処理のルールは確認していますか?」「履歴管理は、どのレベルまで必要ですか?」といった、過去にトラブルへ発展したポイントが、あらかじめヒアリング項目として組み込まれているはずです。こうすることで「上流工程での抜け」を構造的に防ぐことができます。

現場で蓄積されたナレッジをドキュメント化し、次のプロジェクトでも活用できる「型」へと昇華させる。この積み重ねが、業務効率とプロジェクト品質の双方を着実に向上させていきます。

おわりに

「伝えたつもり」を「伝わっている」に変えるためにエンジニアが意識すべきポイントは、以下の3点です。

1. 業務フローへの一般的な理解とドキュメント化
2. 徹底した業務の可視化と管理
3. テンプレートによる標準化

クライアントの言葉を鵜呑みにせず、一般的な業務フローに照らして隠れた要件を掘り起こすこと。
要件を細分化し、進捗管理表に落とし込んで徹底的な可視化を行うこと。
さらに、過去の経験を未来への資産としてテンプレート化し、プロジェクトを効率的に進める仕組みを作ること。

これらはすべて、PMOの視点である「プロジェクトを客観的に管理し、不確実性を排除する」ことにつながります。ぜひ、あなたの現場でも実践してみてください。