設計書・仕様書のレビュー観点｜見落としを防ぐチェックリスト

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。

設計書のレビューは何のためにする？

設計書に誤りがあると、そのまま作られてテストで見つかり、設計から作り直すことになりますよね。レビューは、その手戻りを前で止めるための作業なんです。

IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義書はバイブルであり，事あらばここへ立ち返るもの」という条があります。立ち返る先の文書だからこそ、誤りや抜けを早いうちに見つけておきたいわけですね。

5つの観点で見るレビュー観点チェックリスト

ここが大事なところです。5つの観点を順番に当てていくと、どの設計書でも同じように見られます。

観点1：抜け

まず、書かれているべき事が書かれているかを見ます。正常な動きだけでなく、入力が間違っていた時や、データが無い時の動きも書かれているか確かめましょう。

決まっていない事が「未定」と書かれているかも、抜けの観点で見ておきたい所です。デジタル庁のDS-100（デジタル・ガバメント推進標準ガイドライン）でも、未確定な要件はリスクになり得るので、その旨を要件定義書で明らかにするとしています。

観点2：あいまい

読む人によって受け取り方が変わる言葉が無いかを見ます。「十分に」「なるべく」「適宜」といった言葉は、具体的な条件に言い換えてもらいましょう。

例えばこんなやり取りです。

「検索結果は速やかに表示する、とありますが、何秒以内なら合格ですか？」
「そこはまだ決めていませんでした。発注側と相談して数字で書きます」

こうして聞くだけで、あいまいな所が「決める事」に変わります。

JIS Z 8301:2019（規格票の様式及び作成方法）では、要求事項は客観的に検証できるものだけを規定し、「十分に強い」のような表現を用いない、という原則が示されています。仕様書を書く時にも、そのまま使える考え方なんです。

観点3：矛盾

同じ設計書の中で、章によって書いてある事が違わないかを見ます。画面の設計とデータの設計のように、別の文書との食い違いも見逃しやすい所です。

矛盾を見つけるには、同じ項目を別の文書と並べて読むのが早道です。例えば画面の項目一覧とテーブル定義を横に並べ、名前・桁・必須かどうかを1行ずつ見比べてみてください。

観点4：実現できるか

書かれている事が、今の仕組みや期間、人手で作れるかを見ます。ここは作る側の経験が活きる観点なので、開発の担当者に入ってもらうと見つかりやすくなりますよ。

『作れるかどうかは作る人が判断すればいい』と思うかもしれません。でも、設計の段階で気づけば、要件を少し変えるだけで済むことも多いんです。

観点5：テストできるか

書かれた通りにできているかを、テストで確かめられるかを見ます。合否の基準が書けない仕様は、あとでテスト仕様書を作る時に困るんです。テストの書き方はテスト仕様書とは？で紹介しています。

要件定義書のレビューはどこが違う？

要件定義書は、発注側と開発側が「何を作るか」を決める文書ですよね。だから、技術的に正しいかより、業務の困りごとが解決するかを先に見るんです。

これは編集部が考えた目安です。要件定義書のレビューのチェックリストには、上の5観点に「業務の流れと合っているか」「非機能要件（性能やセキュリティなど）が書かれているか」を足しておくと安心ですよ。

要件定義書の中身は要件定義書とは？、設計書の種類は設計書とは？でまとめています。

作成者がレビューの前にしておくこと

レビューは、頼む側の準備で質が変わります。何も伝えずに「見てください」と渡すと、読む人はどこから手をつければいいか迷ってしまうんです。

設計書のレビューのやり方と進め方

『レビュー会議って、読み上げながら進めればいいの？』と迷う方も多いはずです。読み上げは丁寧ですが、時間がかかるので、事前に読んでおく形と組み合わせるのがおすすめなんです。

指摘の書き方のコツ

指摘は「どこが」「何が問題か」「どうしてほしいか」の3点で書くと伝わります。

「ここが変」だけだと、書いた人は何を直せばいいか迷ってしまいます。直してほしい形まで書いておくと、やり取りが1回で済みますよ。

直したあとの版の付け方は、仕様書の変更管理で紹介しています。

設計書レビューのよくある相談

知恵袋などで見かける相談を、内容をまとめて紹介します。

相談1：周りと比べて的外れな指摘ばかりしてしまう

設計書のレビューで、周りの人と比べて的外れな指摘ばかり出してしまい、レビューする力をつけたい、という相談です。

的外れになる原因は、何のための設計書かをつかむ前に、細かい所から読んでしまうことが多いんです。まず要件定義書で目的を確かめてから、5つの観点の順に読んでみてください。

『この指摘、的外れかも』と思ったら、質問の形で出す方法もあります。「4.2はこういう意味で合っていますか」と聞けば、相手を責める形になりません。

相談2：レビュー観点のリストが欲しい

ソフトウェア開発のレビュー観点のリストが欲しい、どこかで公開されていないか、という相談です。

公開されている観点を参考にするのもいいですが、自分たちの開発でよく起きる誤りを足していくのが一番役に立ちます。この記事の5観点を土台にして、過去のレビューで多かった指摘を書き足していきましょう。

相談3：読み上げながら補足するやり方でいい？

設計書を読み上げて、その場で補足しながら進めるレビューのやり方でいいのか、という相談です。

読み上げは、作成者の考えが伝わりやすい良さがあります。ただ、聞く側が受け身になりやすいので、事前に読んで指摘を持ち寄る形と組み合わせると、見落としが減りますよ。

相談4：設計書は「です・ます」と「である」のどちらで書く？

プログラムの設計書は、です・ます調とである調のどちらがいいのか、という相談です。閲覧数が多く、レビューで指摘されて迷う人も多いようです。

どちらが正しいという決まりはありません。レビューでは、1つの設計書の中で文体がそろっているかを見れば十分です。職場に書き方の決まりがあれば、そちらに合わせましょう。

レビューする力は仕事でどう活きる？

レビューは、人の書いた文書を読んで、誤りや抜けを見つける作業です。実は、自分で書くより多くの設計書に触れられるので、設計の力を伸ばす近道でもあるんです。

今の職場でレビュー担当を任せてもらい、経験を積むのも立派な道です。上流工程の仕事に進みたい人は、求人の仕事内容で「レビューや設計をどこまで任されるか」を比べてみると、次の一歩が見えてきますよ。

よくある質問

まとめ

あわせて読みたい

仕様書とは？意味と目的、設計書・要件定義書との違い

仕様書の書き方｜誰が読んでも同じに伝わる7つのコツ

設計書とは？システム開発の設計書の種類と役割