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

» 2009年07月10日 00時00分公開

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

管理者視点でのレビュー

　レビュー者が詳細設計文書をレビューする視点はほかにどういうところにあるのでしょうか。プログラマとしての視点だけのレビューであれば、プログラミングスキルのある人間であればよく、必ずしも上長によるレビューというのは必要ないような気がします。しかしレビュー者は実はもう1つ別の視点を持っています。

　もう1つの視点とは、そのプロジェクトの特性・状況・重視するものを個別に考えてレビューする視点です。こういったプロジェクト固有の特性というのはプログラマでは気付けないものであることが多く、若干高いレベルから物事を見渡す視点の備わった立場にいないと分からないものです。

　そもそもレビューとは「そのプロジェクトで起こってほしくないことを事前に取り除く」という目的があります。つまり、プロジェクトやチームの管理者としての懸案事項を設計成果物レベルに落としたものがレビューする視点となります。先のプログラマとしての視点が局所的に丁寧に見ていくレビューだとすると、管理者としての視点は全般的に「起こってほしくないこと」が起きる可能性の高い部分はないかをチェックするのです。

図2 管理者の視点とレビュー者の視点

　図2はプロジェクトやチームの管理者の視点から成果物のレビューをする際のレビュー者としての視点への変化を表した図です。レビュー者は管理者としての視点を持ちつつ成果物のレビューを実施しています。それぞれのプロジェクトや機能で重視すべき個所というのは異なってきますので、レビューでの力の入れどころと力の抜きどころをコントロールして効率的なレビューをします。

　実はこれは裏を返せば詳細設計文書の作成において最も注力するべき点ともいい換えることができます。最も重点的にレビューされる個所なのですから、当然最も神経を使って設計をするべき個所であるということになります。自分の所属するプロジェクトでは、管理者の視点としてどういった部分を重視しているのかをレビュー者や詳細設計成果物のお手本を作った人に聞いてみるのが一番よいでしょう。

　冒頭に書いた「レビュー者としての特殊スキル」というのは実は管理者としての視点のことであり、まだそれが満足でない設計者の成果物をレビューする場合に感覚的に設計の不備に気付くことができるのだろうというのがわたしなりの考えです。

レビュー者が考えるべきこと

　少し話が変わりますが、詳細設計文書のレビュー者向けの話を少ししたいと思います。詳細設計の工程は「見る人」が複数いる場合もあれば「見られる」人も複数います。そのためプロジェクト全体で詳細設計文書の品質を均一化するためには、詳細設計ガイドラインというものを用意することを強く推奨します（図3）。

図3 お手本作りの流れ

　まず詳細設計工程の計画の段階で詳細設計文書として何を作るかを定義します。次に詳細設計ガイドラインにて「レベル感」「レビュー視点（作成の注意点）」「作成手順」を明確にします。これらがそろったうえで詳細設計の工程を本格的に開始し、レビューにて詳細設計文書の品質の維持をします。詳細設計文書の具体的な記述レベルというのはやはりお手本となるものがある方が理解しやすいものです。レビュー者はレビュー時間が潤沢にあるものではありませんので、自分のレビュー視点を明確にしておけばセルフレビューの段階である程度の不備がつぶれます。作成要員もいっせいにそろわずに徐々に増えていく場合がありますので、ガイドラインの作成により都度の説明の手間を省きます。

　また「レビューする人によって言っていることが違う」などという悲しい指摘をされる前に、まずレビューする側自身がしっかりと筋の通った方針というのを打ち出しておくことが詳細設計の工程では重要なことだと考えます。わたしもかつてレビュー時に「前と言っていることが違う！」という苦情を受けたことがあります。そのときは基準となるレビューの視点が明確ではなかったために自分自身のレビュー視点が定まっていなかったのだと思っています。そのような苦情を受けないためにも、レビュー者はレビュー者なりの準備というものを万全にしておきたいものです。

「見られる」という意識を持とう

　詳細設計文書とは、誰かが何かの目的（視点）があって見るための文書です。この誰かというのはもしかしたら未来の自分かもしれません。今回はレビュー者という立場から説明をしてきたのには意味があります。詳細設計文書は「いつ」「誰が」「どういう視点で」「何を」見るのかということを意識するだけでグンといいものになります。「見られる」という心構えをするだけで、丁寧に、慎重に文書作りをするようになります。そしてどのような視点でレビューされるのかについては前述したようなものが主になりますので、その視点を念頭に置いて詳細設計文書を作成すれば自然と品質の高いものを作成することができるようになります。

　次回はテスト成果物について触れてみたいと思います。

筆者紹介

アクセンチュア・テクノロジー・ソリューションズ　マネジャー

宮本和洋（みやもとかずひろ）

メインフレームからWebシステムまで数々のシステム開発を経験し、実装可能なプログラム言語は10を超えるシステム開発のエキスパート。「システム開発者だって楽をしたい！」をモットーにし、楽をするための苦労なら買って出るというやや矛盾したポリシーを持つ。風呂場やトイレでいいアイデアが浮かぶことが多いので、狭い空間が大好き。特技は同時に2台のPCでまったく別のプログラミングができること。

「次回」へ

「システム開発プロジェクトの現場から」バックナンバー