どうもタスです。
僕の仕事は「社内SEの経験を通してユーザーに対して思うこと」でお話ししたとおり、社内SEを行っています(もう5年になります)。
特に要件定義から設計作業を行うことが多く、設計作業はレビュアーを担当することが多いです。
設計レビューは設計書の品質が決まる大事な作業で、この作業を疎かにすると良い設計書は作成できません。
良い設計書ができないとなると、設計以後、後続の工程にあたるプログラミング作業や保守作業に影響を与えることはもちろん、将来、当機能に改修が入った場合や不具合が発生した場合など、機能の見直しのための設計書確認で苦労することになります。
後で痛い目に合うってことです。
そこで今回は、設計レビュアーを対象に、良い設計書を作成するために意識するべき設計書レビューの重要なポイントを4つに絞ってお伝えします。
本記事は未経験者やレビュー経験が浅い方を対象としており、熟練者はあまり面白味がないかもしれませんが、自らの作業を顧みる気持ちで見て頂ければと思います。
この記事の目次
設計レビューとは？
レビューとは
システム開発において、作成された仕様書やコードなどの成果物を開発者とは別の人が詳細に調べ、仕様や要求を満たす内容になっているか、誤りや不具合が無いか、資源の浪費や不必要な冗長さ、極端な低性能などの問題が無いかなどについて開発者にフィードバックする工程をレビューという。 – IT用語辞典 e-Word
といい、設計レビューとは、設計書や検討資料など設計工程で作成する様々な資料について、確認及び検討して、作成者に問題点や検討した方が良い点などをフィードバックすることを言います。
目的は、良い資料を作成することです。
良い設計書とは？
良い設計書を考える前に、悪い設計書を考えてみます。
例えば、勤怠管理システムを開発するとして、その要件の中に「休みは時間単位で取れること」があったとします。
それなのに、休みを取る最小単位が「午前・午後休」であったら、要件を満たしていないですよね？
また、設計書が誤字脱字だらけだったり、同じような内容があちこちに書かれていたり、さらには何が言いたいか分からない文章になっていたりすると、それを読む側としては「結局、これはどんな機能なの…？」と混乱してしまいます。
そうなると、真っ先に思い浮かぶのは、その後工程であるプログラミングにおいて、プログラマーは機能の意図を理解するのが難しいですよね。
さらに、保守工程などで機能改修や不具合対応等があった際に、機能調査を行おうと設計書を見ても、その設計書を理解するところから始まってはなんとも非効率です。
むしろ、そんな設計書を見るくらいであれば、無い方がマシです。
ということで、少なくとも機能要件は全て満たしていて、なお且つ誰が見ても分かり易い設計書になっていることが良い設計書であると言えます。
設計レビューを行うための重要なポイント
そこで、以下では良い設計書にするためにレビュアーが意識するべき重要なポイントを4点に絞ってお伝えします。
要件を満たす内容になっているか
設計フェーズは、要件定義で利用者の目的とそれを実現するための要件を明確にしたものについて、具体的にシステム化まで落とし込む作業のことを言い、その方法を検討し、且つプログラマーにそれらを伝える資料（設計書）を作成する作業が主になります。
よって、要件が1つでも盛り込まれていない内容で設計書を作成してしまった場合、誤った仕様をプログラマーに伝えてしまい、その仕様でプログラミングすることで結果的に利用者が望む機能にならないことになってしまいます。
そのためには、どのような要件があるかをレビュー前に明確にしておく必要があります。
その要件とは、要件定義で決まった内容だけではなく、それを実現するために必要な処理やデータ構造などの要件も明確にする必要があるのです。
また、自分であればその要件をシステム化するために、どのように機能化するかをイメージしておくことも大事です。
何のイメージもなくレビューを始めると、処理イメージが設計書に引っ張られる場合があるからです。
レビュー時は、それらの内容を箇条書き等にまとめておき、設計書内で実施されいるか1つずつ確認して、されていれば箇条書きを消していくという作業を根気よく行います。
そうすることで漏れなく要件が反映されていることが担保され、利用者が望む機能を設計することができます。
誰にでも理解できる表現に工夫する
例として、特別に必要でなければ難しい専門用語はなるべく使わない方が良いです。そのくらい、誰でも理解できる設計書を目指してください。
どうしても使わなければならない場合は、別紙に用語集を定義しても良いくらいです。
また、設計書に記載する言葉の表現には気を付けましょう。
以下の内容はどれも大事なので、一つ一つ心当たりがないか自問してみてください。
- 同じ内容についてそれぞれを異なる表現にしない。
- 一般的でない言葉を設計書に記載する場合は、その言葉を冒頭で定義する。
- 文章表現は、口語や小説等の感情豊かな表現にならないこと。簡潔に。
- 冗長な表現は避けること。文章は短ければ短い方が良い。
- 語尾は揃えること。ですます調。である調など。
- 分かり易い表現になるのであれば、図表は多用するべき。
- 説明は大きな説明から細かな説明に流れるようにする。粒度を意識すること。
- 標題は、標題以降の内容の要約が簡潔に分かり易く書かれていること。
- 誤字脱字を徹底的には排除すること。
- 誤解を生む解釈とならないように、揺らぎのある表現は使用しないこと。
- 項番を採番する際も一定のルールを設けること。1、2…の次は(1)、(2)で、その次は1)、2）で、のように。
そういう意味だと、設計書はテンプレートを用意しておくのが良い方法だと思うが、上記の内容を100%防ぐことは難しいので、個々人が意識してレビューする必要があります。
一人が全ての設計書を書くのであればある程度は共通的なルールのもとに作成できるかもしれませんが、そういったシチュエーションはあまりないですよね。
レビューの際は紙に印刷する
これは僕の好みの問題ですが、ディスプレイ上でレビューを行うよりも、設計書を紙に印刷して確認し、指摘内容は直接紙に鉛筆で書き込む方がパフォーマンスが上がる気がします。
なぜか電子だと、見落としや気付きが少なくなってしまうんですよね（デュアルディスプレイでレビューしていても）。
なので少なくとも初回レビュー時は必ず紙に印刷して鉛筆片手にレビューを行っています。
ただし、レビューを補完してくれるその他の資料はディスプレイで参照しながら行っています。テーブル定義や要件定義資料など。
また、これまた大事なのが、設計者には必ず自己レビューを行うことを義務付けることは重要です。
レビュアーの作業を軽減する目的もありますが、設計者本人にレビュアーの視点を養わせる良い機会になります。
指摘の際はダメ出しだけではなくどうあるべきかまで伝える
フィードバックでダメ出しをし続ける人を見かけることがあるのですが、レビューは「ダメ出し」ではありません。
なので、ダメダメというだけでは、それこそ「ダメ」なのです。
指摘した後は必ず改善策を伝えましょう。
改善策が思い浮かばなければ、課題として検討してもらうのも良し、設計者だけで解決できそうでなければ、それを関係者で揉むための資料を作ってもらうのも良しです。
結局、前に進むためのアドバイスを送るのが役目だと思えばダメ出しに終始することはないです。
目的はあくまで良い設計書を作成することですから。
まとめ
今回は、「レビューを行う際に抑えるべき4つのポイント」をお伝えしました。
設計書にもデバッガがあれば良いなと思う今日この頃ではありますが、そんな便利なツールは無いです。
設計書は未来永劫残されていくものと思って、いつだれが読んでも恥ずかしくない内容にしたいですよね。
それは設計者をフォローするレビュアーがいてこそ実現するので、是非、ポイントを意識してレビューに励んでください。
システム開発にお役立ちの以下の記事もどうぞ
→質の高い資料を作成する方法を3つのポイントにまとめて紹介します。これは設計書を作成する際も同じことが言えます。
→システム開発は設計工程だけではなく、様々な工程を経て行われます。本記事では流れを具体的にお話しします。
