設計書レビューで何を見る？注文訂正を画面と倉庫への明細でたどる方法

レビューは、目的と設計案のつながりを確かめる

ここでいう設計書レビューは、受け取った設計案が、実現したい仕事と合っているかを関係者で確かめる作業です。誤字や画面の配置を見るだけでなく、必要な情報が次の担当へ渡るか、通常と違う場面でどう扱うかも読み合わせます。

発注担当が、すべての技術的な設計を作り直す必要はありません。業務担当は、何が分かれば出荷準備を続けられるかを説明し、開発側は、画面と明細の関係や更新の条件を説明します。IT発注担当は、その説明が要求と設計案のどこに対応するかを整理し、未回答を残さず判断する相手へ返します。

文書がそろっていることと、仕事がつながることは別

営業画面、倉庫向けの明細、処理の説明がそれぞれ存在していても、同じ注文数量が同じ意味で使われるとは限りません。各文書を別々に読んで納得しても、受け渡しの箇所で違いが見つかることがあります。どの文書の何を対応させるかを開発側に示してもらい、一つの仕事を横断して読みます。

IPAの「機能要件の合意形成技法」は、関連する設計資料の整合と、目的・範囲に照らした共同レビューを扱っています。2008～2009年度の取り組みと2010年のガイドを紹介するアーカイブで、どの案件にも同じ書類や回数を求める規則ではありません。本稿では、関係する記載を結び付けて読む考え方を参考にします。

同じ注文を、要求文・画面・倉庫明細でたどる

最初に、「営業が注文数量の訂正を受け、倉庫が新しい数量で出荷準備できる」という一件を選びます。レビューに使う文書の版と、今回見る範囲も開発側と合わせます。古い画面案と新しい明細案を混ぜたまま、実装の不具合だと決めないためです。

1. 要求文で、最後にできてほしい仕事を読む。営業画面の数量を変えるところまでか、倉庫が訂正後の数量を知って準備できるところまでかを分けます。この例では、倉庫の仕事までを目的にしています。
2. 営業画面案で、どの注文をどう訂正するかを見る。訂正前後の数量と、操作後に何が表示される案かを確かめます。表示が変わることと、別の資料まで更新されることを同じに扱いません。
3. 倉庫へ渡す明細で、同じ注文の数量を読む。別の注文や品目、単位を見比べていないかを先に合わせます。数量が違うなら、値の意味や作られる時点が違う可能性も含め、開発側へ説明を求めます。
4. 明細を見た倉庫担当が、次に何を判断できるか聞く。訂正が入ったことをどう知り、古い明細と新しい明細をどう見分けるかを確認します。出荷準備が始まった後の扱いは、別の条件として倉庫責任者と開発側へ返します。

注文の仕事そのものがまだ説明できない段階なら、先に通常と例外の一件を、業務担当へ聞く方法で要求を整理します。当稿は、その後に受け取った設計案をどう読み合わせるかへ焦点を置きます。

図で、数量の違いと未記載の条件を読む

図で見る問い：営業画面案に訂正後の数量が書かれていれば、倉庫へ渡す明細も同じと考えてよいでしょうか。同じ注文数量の欄を見比べてください。記載が食い違う案と、数量の記載はそろうが例外が未確認の案を、別々の下書きとして示します。

解説図を原寸で見る

図から読む判断：数量の記載が違う案では、画面と明細の関係を説明してもらう必要があります。記載がそろう案でも、出荷準備を始めた後の訂正や、同じ訂正を重ねた場合の扱いまでは分かりません。書かれた数量が同じことだけを、設計全体の承認や実装成功にはしません。

次の行動：IT発注担当から開発側へ、明細が何を元にいつ更新される案かを聞き、倉庫責任者へ、その条件で出荷前の判断ができるかを確かめます。回答がない箇所と、回答に応じて直す文書を分けて残します。

二つの下書きで、分かる記載と未確認を分ける

違いは、書面に表れている数量の不一致と、書面だけでは決められない条件です。一方の値を黙って書き換える前に、どちらの記載が何を表す案なのかを確かめます。質問に対する回答もないまま、画面側か明細側のどちらが正しいかを発注担当だけで決めません。

指摘を、場所・質問・答える担当へ書き直す

「整合していません」「この設計で大丈夫ですか」だけでは、開発側が何を確認すればよいか分かりません。指摘する場所と、そこに書かれた値、知りたい条件を一つの質問へまとめます。文書名や版、欄の名前を使い、記号だけで相手に探させないようにします。

数量の記載が違うときの、質問の例

これは指摘文の例で、自動で出荷を止める機能が決まった意味ではありません。人の連絡・照合で扱う案か、システムの通知や制御が必要な案かも、業務への影響と開発側の回答から決めます。

書かれていない条件は、欠陥の原因と決めずに聞く

別の下書きでは画面と明細の数量がそろっていますが、出荷準備後の訂正条件が未確認です。このときは「訂正処理が壊れています」と指摘するのでなく、どこまでの訂正を受け付け、すでに準備した品物や古い明細をどう扱う案かを質問します。設計上未記載なのか、別の資料にあるのか、今回の対象外なのかを確かめます。

数量の意味や形式の説明が足りない場合は、値の意味・元情報・更新担当を確認する方法も参考にできます。当稿で全データ項目を決め直すのではなく、今の訂正で影響する欄を開発側と対応付けます。

回答後は、関係する設計案を同じ一件で読み直す

開発側から「直しました」と返ってきたら、どの記載をどう変えたかを見せてもらいます。画面の数量だけを変えたのか、明細を作る条件や倉庫への案内も変えたのかを分けます。回答の文章と、修正後の設計案が違っていないかも読み合わせます。

1. 回答と、変わった文書を結び付ける。質問ごとに回答者、回答の内容、対象の設計案と版を残します。保留の回答なら、決めるために何を調べるか、誰へ確認するかも記します。
2. 同じ注文訂正を、再びたどる。要求文、営業画面、倉庫明細、出荷前の判断を同じ条件で読みます。訂正前後の数量や、どの時点の明細かを、途中で別の例へ置き換えません。
3. 変えた条件に関係する例外も読む。訂正後の連絡方法を変えたなら、古い明細で準備を始めていた場合や、連絡が重なった場合をどう扱う案かも確認します。実装・実試験が必要な点は、その後に確かめる項目として分けます。
4. 決まった点と、残る点を分けて判断する。質問への回答が設計案へ反映された点、まだ未回答の条件、後で実際に動かして確認する点を混ぜずに残します。

IPAの「機能要件の合意形成ガイド 画面編」にも、画面に関係する情報を対応付け、資料から読み取れる動きを照合する例があります。本稿の注文と数量は独自の架空例で、同ガイドの図表や識別記号を複製したものではありません。文書の構成は、実際に使う設計資料に合わせて開発側へ説明してもらいます。

進む範囲と、保留する条件を分ける

レビューで分かるのは、提示された設計案が要求とどう対応し、どの条件が説明されたかです。設計を読んで納得したことと、実際のシステムで営業の訂正が倉庫へ届いたことは別です。実装後には、同じ仕事を動かして確かめる条件へつなげます。

未回答が出荷前の判断へ影響するなら、その範囲を保留する

訂正後の明細を見分ける条件が分からず、倉庫がどの数量で準備するか判断できないなら、その要求について承認を急ぎません。何を誰に聞けば判断できるか、回答でどの文書を見直すかを明確にします。すべての細部が同じ重さではありませんが、重要な未回答を誤字と同じ扱いで閉じないようにします。

希望の追加か、合意した要求の説明不足かを確認する

「出荷準備後も訂正したい」という回答が出たら、今回の要求に含めていた条件か、新たに相談する条件かを確認します。どちらかを推測で決めず、当初の目的と範囲、影響する業務を関係者で読み合わせます。必要な見直しと、今回進める範囲を説明してもらいます。

判断する人と、残る確認を引き継ぐ

IT発注担当だけで業務の許容範囲やすべての技術判断を引き受けず、倉庫責任者と開発側の回答をそろえます。社内で決めた判断者へ、読んだ設計案の版、確認できたこと、未回答とその影響を示します。この架空例では、実際の承認者や承認結果は決まっていません。

後から数量の扱いや受け渡しの条件を変えた場合は、関係する資料と、実装後に確認する条件も見直します。以前読んだ版の確認結果を、変更後の案全体へそのまま引き継がないことが大切です。

まとめ：同じ注文の数量を、倉庫の判断までたどる

設計書レビューは、受け取った資料の項目がそろっているかだけで終わらせず、実現したい仕事との対応を確かめます。この例では、営業が受けた数量訂正を、要求文・画面・倉庫向け明細・出荷前の判断までたどります。

記載が違う箇所と、まだ書かれていない条件を分け、場所・値・質問・回答する相手・判断への影響を具体的に返します。回答を関係する設計案へ反映し、同じ一件で読み直してから、決まった点と保留を分けてください。

最初の一歩：IT発注担当から開発側へ、「この注文数量を訂正した後、倉庫が見る明細は、どの記録を元にいつ更新される案ですか」と聞きます。倉庫責任者と一緒に、同じ数量をどの資料で確かめるかを合わせましょう。