文書ドリブン開発 詳細設計文書編：システム開発プロジェクトの現場から（26）（1/2 ページ）

開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。

[宮本和洋，アクセンチュア・テクノロジー・ソリューションズ]

　システム開発プロジェクトで作成される文書にフォーカスしての連載の第4回です。今回は詳細設計文書について考えたいと思います。特に詳細設計文書のレビュー者の視点にスコープすることで、「指摘される個所が少ない」詳細設計文書の作成ができるようになることを目指します。なお、以下の記述はあくまで筆者の私見であることをあらかじめおことわりしておきます。

レビュー者としての特殊スキル

　先日同僚と詳細設計文書のレビューというテーマについて話をしました。彼は「レビューをした際に設計の怪しい部分とそうでない部分が感覚的に識別できる」といっていました。実はわたしも不思議なことに、詳細設計文書を斜め読みしただけで、設計のバグや実装上で問題になりそうな部分が感覚的につかみ取れることがよくあります。「どうしてだろうね？」ということで話題になりましたが、結局明確な理由というものは分かりませんでした。誰に教えられたのでもなく、詳細設計文書をざっと眺めたときに、瞬時に設計の怪しい個所が天啓のように見えてくるのです。ほかのSEにも同じ話をしたところ、やはり数人が同じような特技（？）を持っているようでした。

　わたし自身もこの特技がいつどうやって身に付いたものなのかはうまく説明できないのですが、どうやら自分なりにレビュー時の視点があることに気が付きました。わたしが詳細設計文書のレビューをする場合、まずわたしなりの設計の仮説を立て、それと実際に書かれている内容との整合性を検証するというスタンスでレビューに臨んでいます。また、プログラマとしての長い経験も積んできているため、詳細設計文書を読んだプログラマが誤解しやすい点に注意することもできます。それ以外にも、詳細設計者の持っていないようなシステムに関する業務的な知識や実装方式の良しあしの知識、関連する成果物に関する知識なども総動員してレビューに臨んでいます。

　レビュー作業とはレビュー者の知識や仮説とレビュー対象物との照らし合わせであると考えています。レビュー者（特に上長）は過去の失敗や経験を掘り起こし、プロジェクトの状況や規約との照らし合わせをしながらレビュー作業に臨んでいます。いつも「レビューで指摘される個所が多い」と落ち込んでいるあなたも、今回の記事を読んでいただき、少し高い視点から自分の成果物を見直せるようになってもらいたいと思います。

プログラマ視点でのレビュー

　詳細設計文書を作成するに当たって誰もが一度はぶつかる壁です。特に初めて詳細設計文書を作成する若手が一番悩む部分がここかと思います。しかし実はベテランのSEであっても悩むのです。「勘と経験」によってレベル感が作られていき、気付けばさまざまなレベル感の詳細設計文書が出来上がってしまうことが多々あります。そこで、レベル感に対する明確な考え方を示したいと思います。答えはわたしの連載で何度も示しているV-モデルにあります（図1）。

図1 V-モデル

　このV-モデルを見ると単体テストは詳細設計文書をインプットにして作成されることが分かると思います。もしあなたが単体テストの仕様書をプログラムコードから起こしているとしたらそれは間違いです。もしも誤りのあるプログラムコードからテスト仕様書を起こして単体テストを実行した場合、仮に動作結果が「書かれたとおりに動いた」としてもそれは「正しい結果」とはなりません。単体テスト仕様書とは本来は詳細設計文書をベースとして書かれるべきものなのです。

　テスト技法を大きく分けるとブラックボックステストとホワイトボックステストに分類できますが、このホワイトボックステストのテスト仕様書を書けるようなレベル感が詳細設計文書の目指すべきレベル感だと理解してください。記述レベルが細かすぎるような気がしますが、このレベルまで落ちていない詳細設計文書を渡されたプログラマの立場になってみてください。恐らく仕様が漠然としすぎていて「あの場合は？」「この場合は？」という疑問ばかりが生じる結果になると思います。

　レビュー者は自分自身がプログラマとしての視点で詳細設計文書をレビューします。そのため記述にあいまいな部分がないか、単体テスト仕様書が書けるレベルになっているかという視点でレビューをしているのです。