文書ドリブン開発 詳細設計文書編：システム開発プロジェクトの現場から（26）（2/2 ページ）
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
管理者視点でのレビュー
レビュー者が詳細設計文書をレビューする視点はほかにどういうところにあるのでしょうか。プログラマとしての視点だけのレビューであれば、プログラミングスキルのある人間であればよく、必ずしも上長によるレビューというのは必要ないような気がします。しかしレビュー者は実はもう1つ別の視点を持っています。
もう1つの視点とは、そのプロジェクトの特性・状況・重視するものを個別に考えてレビューする視点です。こういったプロジェクト固有の特性というのはプログラマでは気付けないものであることが多く、若干高いレベルから物事を見渡す視点の備わった立場にいないと分からないものです。
そもそもレビューとは「そのプロジェクトで起こってほしくないことを事前に取り除く」という目的があります。つまり、プロジェクトやチームの管理者としての懸案事項を設計成果物レベルに落としたものがレビューする視点となります。先のプログラマとしての視点が局所的に丁寧に見ていくレビューだとすると、管理者としての視点は全般的に「起こってほしくないこと」が起きる可能性の高い部分はないかをチェックするのです。
図2はプロジェクトやチームの管理者の視点から成果物のレビューをする際のレビュー者としての視点への変化を表した図です。レビュー者は管理者としての視点を持ちつつ成果物のレビューを実施しています。それぞれのプロジェクトや機能で重視すべき個所というのは異なってきますので、レビューでの力の入れどころと力の抜きどころをコントロールして効率的なレビューをします。
実はこれは裏を返せば詳細設計文書の作成において最も注力するべき点ともいい換えることができます。最も重点的にレビューされる個所なのですから、当然最も神経を使って設計をするべき個所であるということになります。自分の所属するプロジェクトでは、管理者の視点としてどういった部分を重視しているのかをレビュー者や詳細設計成果物のお手本を作った人に聞いてみるのが一番よいでしょう。
冒頭に書いた「レビュー者としての特殊スキル」というのは実は管理者としての視点のことであり、まだそれが満足でない設計者の成果物をレビューする場合に感覚的に設計の不備に気付くことができるのだろうというのがわたしなりの考えです。
レビュー者が考えるべきこと
少し話が変わりますが、詳細設計文書のレビュー者向けの話を少ししたいと思います。詳細設計の工程は「見る人」が複数いる場合もあれば「見られる」人も複数います。そのためプロジェクト全体で詳細設計文書の品質を均一化するためには、詳細設計ガイドラインというものを用意することを強く推奨します（図3）。
まず詳細設計工程の計画の段階で詳細設計文書として何を作るかを定義します。次に詳細設計ガイドラインにて「レベル感」「レビュー視点（作成の注意点）」「作成手順」を明確にします。これらがそろったうえで詳細設計の工程を本格的に開始し、レビューにて詳細設計文書の品質の維持をします。詳細設計文書の具体的な記述レベルというのはやはりお手本となるものがある方が理解しやすいものです。レビュー者はレビュー時間が潤沢にあるものではありませんので、自分のレビュー視点を明確にしておけばセルフレビューの段階である程度の不備がつぶれます。作成要員もいっせいにそろわずに徐々に増えていく場合がありますので、ガイドラインの作成により都度の説明の手間を省きます。
また「レビューする人によって言っていることが違う」などという悲しい指摘をされる前に、まずレビューする側自身がしっかりと筋の通った方針というのを打ち出しておくことが詳細設計の工程では重要なことだと考えます。わたしもかつてレビュー時に「前と言っていることが違う！」という苦情を受けたことがあります。そのときは基準となるレビューの視点が明確ではなかったために自分自身のレビュー視点が定まっていなかったのだと思っています。そのような苦情を受けないためにも、レビュー者はレビュー者なりの準備というものを万全にしておきたいものです。
「見られる」という意識を持とう
詳細設計文書とは、誰かが何かの目的（視点）があって見るための文書です。この誰かというのはもしかしたら未来の自分かもしれません。今回はレビュー者という立場から説明をしてきたのには意味があります。詳細設計文書は「いつ」「誰が」「どういう視点で」「何を」見るのかということを意識するだけでグンといいものになります。「見られる」という心構えをするだけで、丁寧に、慎重に文書作りをするようになります。そしてどのような視点でレビューされるのかについては前述したようなものが主になりますので、その視点を念頭に置いて詳細設計文書を作成すれば自然と品質の高いものを作成することができるようになります。
次回はテスト成果物について触れてみたいと思います。
筆者紹介
アクセンチュア・テクノロジー・ソリューションズ マネジャー
宮本和洋（みやもとかずひろ）
メインフレームからWebシステムまで数々のシステム開発を経験し、実装可能なプログラム言語は10を超えるシステム開発のエキスパート。「システム開発者だって楽をしたい！」をモットーにし、楽をするための苦労なら買って出るというやや矛盾したポリシーを持つ。風呂場やトイレでいいアイデアが浮かぶことが多いので、狭い空間が大好き。特技は同時に2台のPCでまったく別のプログラミングができること。
- 文書ドリブン開発 テスト文書編
- 文書ドリブン開発 詳細設計文書編
- 文書ドリブン開発 DB設計文書編
- 基本設計文書の質を下げる「4つの心理バイアス」
- 本当は楽しいドキュメント作成
- 新人（3年目）、プロジェクトで「忍耐」を学ぶ
- 新人、集合研修で「伝説」を作る
- 新人（3年目）、先輩デビューで「最悪の振る舞い」
- 新人、アーキテクチャチームで「運命の出会い」
- 1人チームで悩む新人。「この作業って意味あるの？」
- 現場デビューのお供はビジュアル多用の報告書
- 大規模プロジェクトでは「同じ言葉を、同じ意味で」
- 「バッファ込み」の工数がスケジュール遅延の原因
- 運用って、あまりいいイメージはなかったけれど
- 最強チームで挑んだ、「40時間でデータ移行」の壁
- 障害対応とチューニングの危うい関係
- オフショアなんて、怖くない
- 3プロジェクト同時にリード！ どう乗り切る？
- この案件、ぜひ新しいテクノロジでやりましょう！
- 初めてのトラブル対応。これで直ると思ったのに！
- 「できるか！」な設計書に、どう立ち向かう？
- 専門用語で「カッコよく」話すのは簡単だけど
- メンバーとの仕様打ち合わせは海を越えて
- 定まらない要件、ユーザーからのむちゃな要求
- 未経験のデータベース構築に挑戦
- セットアップ全国行脚で九州弁に大苦戦
- 試行錯誤で分かったスパゲッティコード撃退法
Copyright © ITmedia, Inc. All Rights Reserved.