開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
前回「本当は楽しいドキュメント作成」に引き続き、システム開発プロジェクトで作成される文書にフォーカスします。
今回は基本設計文書について考えたいと思います。なお、以下の内容は筆者の私見であることをあらかじめお断りしておきます。
基本設計工程では、文書作りに対して、その完成度を下げるための「負の心理バイアス」がかかると考えています。文書作りの際、文書の量と質を下げようとする意識が働くのではないかということです。
基本設計文書の完成度を下げる「負の心理バイアス」にはさまざまなものがあります。わたしは、下記の4つが代表的なものだと考えています。
基本設計文書は、システム開発の中で最も軽視されやすい文書ではないでしょうか。
要件定義文書は仕様に対するユーザとの認識齟齬(そご)を避けるため、詳細設計文書にはシステムの品質を保つため、しっかり作成する必要があるのは周知の事実です。しかしながら基本設計文書は、直接何に影響するかの確認が難しいため、軽視される傾向にあるのではないでしょうか。わたしは、この基本設計文書の軽視が「負の心理バイアス」を生み出す原因の1つではないかと考えています。
そのほかの基本設計文書の問題点として、「レビュアーの不在」を挙げることができます。画面や帳票の基本設計であれば、お客さまが詳細にレビューするでしょう。しかし比較的高度な設計スキルを要する、ほかのシステムにも関連するような部分の基本設計は、レビューなしにそのまま詳細設計の工程に流れてしまうことが多いのではないでしょうか。
これら「負の心理バイアス」と「レビュアー不在の問題」が、基本設計文書の品質を下げてしまう大きな要素であると考えています。まず、この点についてよく注意しておく必要があります。
そもそも、基本設計文書は何のために必要なのでしょうか。ここでいう必要性は、成果物としてではなく、システム開発作業を進めていくうえでの必要性のことです。
すぐに思いつくのは、詳細設計文書のインプットとしての必要性でしょう。これを含め、基本設計文書には次の4つの用途からの必要性があると考えています。
これらが、いずれも非常に重要な用途であることは明らかです。
詳細設計文書作成用途については、誰もが理解しているところだと思います。意外に見落としやすいのは、総合テスト用途ではないでしょうか。総合テスト用途を意識して基本設計文書が作成されることは少ないと感じます。
ここで、V-モデルというものを紹介します。V-モデルとは、要件定義から受入テストまでの各工程の関係を表した図のことであり、
基本設計の工程で作られた文書の正当性検証を、結合テストや総合テストの工程で行う
ということを示しています。
基本設計文書が詳細設計工程のインプットとしての意味を持つことは当然認識しなくてはなりません。それにとどまらず、さらに後の工程である結合テスト・総合テストのインプットであるということも、非常に重要なポイントとして認識する必要があります。
Copyright © ITmedia, Inc. All Rights Reserved.