全3291文字
PR
読み手が納得する開発ドキュメントを作るにはどうすればよいのか。本特集では日経SYSTEMSの過去記事を再編集。実用性の高い実践ノウハウを5日間で習得しよう。

 あなたが参加するプロジェクトでは、ドキュメントのレビューが形骸化していないだろうか。

 例えばこんな具合だ。レビュアーは、チームリーダーやサブリーダーといった作成者の上司だけ。どうレビューするかも含めて、1人ひとりの裁量に任される。するとレビュアーはこう考えがちだ。「下手にレビューを徹底すれば、修正作業に手間取って進捗遅れの責任を問われかねない」。自然とチェックは甘くなり、欠陥を見逃してしまう。

 レビューの重要性は、その意義を考えてみれば分かる。ドキュメントの情報漏れや間違いを、組織的にチェックして修正する。作成者1人ひとりでは気付きにくい、ドキュメント同士の整合性も検証する。また、「レビューは1人ひとりの仕事のやり方をチェックする場でもあり、人材育成の面で大きな役割を果たす」(大手SIerでERPの導入コンサルティングを手掛けるS氏)。

 レビューを形骸化させないために重要なのは、組織的なレビューの仕組みを確立することだ。そのために、品質保証部門やPMO(Project Management Office)のような専門チームによる支援を受けることが考えられる。しかし、そのような支援を受けられない現場にとって、組織的にレビューの仕組みを整えるのは容易ではないだろう。そこでここでは、現場で実践できる組織的なレビューの仕組み作りのポイントを3つ解説する。

現場で実践すべきレビューの3カ条
現場で実践すべきレビューの3カ条
レビューの専任組織がない現場でも実施すべきレビューのポイントを3つ挙げた
[画像のクリックで拡大表示]

ポイント 1
目的を基にチェックリスト作成

 レビューの仕組みを構築する上でまず行うべきは、チェック項目一覧の作成である。チェック項目のベースとなるのはドキュメントの目的だ。読み手はどんな人か、何にどう使うのかという観点で、ドキュメントを合格と判断する条件を洗い出す。

 レビューのチェック項目は、「基本的な考え方」「完了判定のレビューのポイント」「レビューの観点」「文章表現レビューのポイント」といった大項目ごとにリスト化しておく。そして例えば基本設計書のレビューの観点なら「プログラムロジックで実現してほしい業務機能要求を網羅して説明しているか?」といった具体的なチェック項目を洗い出して一覧にする。

 チェック項目の一覧表は時間をかけて作成しておきたい。その際「すべてのプロジェクトに共通する汎用的な基本チェック項目と、プロジェクトによって追加して利用するチェック項目を分けて定義しておくとよい」(プロジェクトの品質管理のスペシャリストである大手SIerのH氏)。そうしておくと、ほかのプロジェクトで流用しやすくなる。

 ドキュメントそのものをレビューするほか、どういう作業手順を踏んでドキュメントを作成したのか、というプロセスのレビューも必要である。実際には、あからじめ策定しておいた作業手順書を基に、レビュアーが作成者にヒアリングする。ヒアリングの内容は、1つひとつ手順を踏んだかどうか、作業の順番を守ったかどうか、などだ。

関係者全員の合意を得る

 ドキュメントとそのプロセスをレビューする2つのチェックリスト(ドキュメントのチェック項目一覧および作業手順書)を作成するうえで、必ず行うべきことがある。それは、プロジェクトのチーム内でチェックリストに関して合意を得ることだ。

 「そもそも作成者がチェックリストに納得していなければ、それに基づいたレビューの結果についても納得するわけがない。レビュアーについても同じで、チェックリストに納得していなければ、別の観点でレビューするようになる」(前出のH氏)。

 チェックリストの合意形成では、関係者全員で集まり、顔を突き合わせて納得するまで徹底的に議論する必要がある。合意なく議論を打ち切れば、レビューが形骸化する。特に注意が必要なのは、協力会社のメンバーとの合意形成である。一方的に押し付けるのは論外。時間をかけて説明したうえで、協力会社の意見を取り入れたい。