基本設計をスムーズに進めるための5つのポイント――要件定義書の読み合わせ、データ構造、IPO、外部接続：明日から使えるシステム開発プロジェクトの進め方 再入門（4）（1/3 ページ）

本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。今回は、「基本設計」をスムーズに進めるための5つのポイントについて解説する。

[橋爪幹人，ウルシステムズ]

連載目次

基本設計で重要な5点を見直そう

　システム開発プロジェクトの進め方をあらためて解説する本連載。これまでは以下について解説してきた

• 連載第1回「若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実」今のSIerが直面している問題点を提示し、本連載の意義や概要などを紹介
• 連載第2回「要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション」プロジェクトの具体的な進め方として要件定義の前に実践しておきたいことを紹介
• 連載第3回「要件定義をうまくこなすためのポイント――要件定義の完了条件と要求の引き出し方」要件定義工程をスムーズに運ぶためのコツを紹介

　今回は設計工程を取り上げる。要件定義でまとめた内容をうまく製造に反映するために押さえるべきポイントを解説する。

　ちなみに、設計工程は大きく2つのステップに分けられる。外部仕様を固める「基本設計（外部設計）」と内部仕様を固める「詳細設計（内部設計）」だ。今回は、より重要度の高い基本設計、中でも重要な5点――要件定義書の読み合わせ、業務担当者の時間確保、データ構造、IPO、外部接続に焦点を当てる。

設計の前に、要件定義書を読み“合わせる”

　設計工程では、さまざまな成果物を作成する必要がある。画面仕様や帳票レイアウト、処理シーケンス、論理データ構造……。要件定義工程で終えられなかった画面遷移構成やユーザー権限の整理を手掛ける場合も珍しくない。作成すべきものが多いため、ついつい作業の着手を焦ってしまいがちだ。

設計者が要件を正確に把握しているとは限らない

　しかし、急がば回れである。まずは要件定義書の確認から始めよう。設計を担当するメンバーが要件を正確に把握しているとは限らない。一般的なプロジェクトでは要件定義は少人数のチームでこなし、設計工程から一気にメンバーを増やす。要件定義を担当した会社とは別の会社が設計を担当するプロジェクトもある。設計段階で初めてプロジェクトの内容に触れるというメンバーは意外と多いのだ。

要件定義書には書かれていない情報がある

　「要件定義書を読んでもらえばいいのでは？」と思う読者もいるかもしれない。しかし、要件定義書には書かれていない情報がある。例えば、プロジェクトが前提としているビジネス的な背景や仕様検討の経緯といった情報はあえて記載しないことも多い。未決事項や要調整事項もたくさん残っている。要件定義時点でシステムの仕組みを完全にはデザインすることは困難だからだ。

　要件定義と設計の橋渡しを怠ると設計工程の効率が下がる。設計担当者は「どう設計していいのか分かりません。要件定義をやり直してください」と言い出すならまだ良い方だ。要件定義書に書かれていない事項が設計からスッポリと抜け落ちてしまう可能性もある。一番恐ろしいのは、担当者が勝手に解釈して設計してしまう場合だ。誤った設計は製造工程やテスト工程での手戻りを引き起こしかねない。

要件定義時点で発掘できなかった問題点も洗い出せる

　よって、設計工程の始めに要件定義書を各設計担当者に紹介する場を設ける。やることは単純である。設計メンバーを集めて要件定義書を頭から読んでいくだけだ。要件定義の担当者にも同席してもらい、設計担当者が実装を考えるに当たって確認しておきたい点に回答してもらう。やりとりを通して要件定義時点で発掘できなかった問題点も洗い出せるだろう。「何が決定していないのか」「これから何を検討すべきなのか」を明確に示せば設計担当者の納得感が違う。設計の進め方もより的確になる。

発注側の積極的な関与も欠かせない

　発注側の積極的な関与も欠かせない。設計担当者の業務やシステムの理解する手助けをする。「要件定義書を渡して、後はお任せ」といった丸投げはもっての他だ。要件定義と設計を別々の会社が担当する場合は、要件定義を担当する会社に設計以降のフォローをしてもらえるよう、契約で取り決めておこう。

リプレイスの場合は、既存システムの仕様や動作を調べる

　なお、既存システムをリプレイスする場合は、要件確認の一環として既存システムの仕様や動作を調べる。設計書を読むのはもちろんのこと、実際にシステムを触って細微な動作を確認したい。既存システムの検証環境のアカウントを設計者に配布して、いつでも動作を確認できるようにしておく。

“手戻り”の影響を極小化するための方法＝業務担当者の時間確保を依頼する

　設計工程を進めるに当たって最も避けたいのは“手戻り”である。システム開発に携わった人間であれば、多かれ少なかれ手戻りに悩まされた経験があるだろう。設計工程を進めるに当たって多くのマネジャーは「手戻りをゼロに抑えよう」と考えるが、あまり現実的とは言えない。要件定義時点でこれから作るシステムを完全にデザインすることは難しい。要件定義の内容にブレが出ることもある。

　となれば、手戻りの発生を案ずるよりも、素早く解決する方策を考える方が建設的だろう。結論から言えば、それは業務担当者の時間を確保することに行き着く。要件や設計が正しいかどうかは実際にシステムを利用する業務担当者にしか答えられない。要件が不明確だったり、漏れていたりした場合に、すぐに彼らの判断を仰ぐこと。それこそが“手戻りの影響を極小化するための方法”である。

業務担当者に迷惑は掛けたくないからこそ

　言うは易く行うは難し。業務担当者は通常業務をこなしながらプロジェクトに参加している。仕様の確認のために時間を割いてもらうのは容易ではない。しかも、要件定義工程ですでに多くの時間を割いている。設計工程でも頻繁に時間を求めるようでは、担当者の上長が怒りだしかねない。開発側としても業務担当者に迷惑は掛けたくないし、以前に議論した事項を持ち出すのは気が引けるものだ。

　では、どうするか。筆者は手戻りが発生したときに備えて、業務担当者の時間を前もって確保することを勧める。要件定義を終えた時点で積み残した課題から、設計工程において業務担当者にどの程度参画してもらう必要があるかを見積もる。もちろん、バッファーも十分に考慮しておく。設計工程に着手する段階で業務担当者に「これだけの時間をもらう可能性がある」と伝えるのだ。

発注側の情シスは、調整に積極的に協力しよう

　他人の時間は急には確保できないが、調整すれば何とか捻出できるものである。ある日突然、「仕様のレビューがあります。明日時間をとってください。それができないと設計が遅れて、期日内にリリースできません」と言うから問題なのだ。だから、あらかじめ調整しておくのである。

　「仕事がデキる」と言われるプロジェクトマネジャーはこうした調整に長けている。前もって業務側との時間調整を当たり前のように実施している。発注側の情報システム担当者は、こうした調整に積極的に協力し、開発会社がスムーズに設計できるよう業務部門に働き掛けるべきである。