基本設計文書の質を下げる「4つの心理バイアス」：システム開発プロジェクトの現場から（24）（2/2 ページ）
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
基本設計文書の総合テスト用途
基本設計文書が総合テストのインプットとして使用される、具体的な例を紹介します。
総合テストでは、一連の業務の流れを連携させたテストを実施します。総合テストシナリオ作成の際、業務の流れや特徴を明確に把握するために、業務フロー図や業務機能一覧表を活用する場合が多いのではないかと思います。
業務フロー図とは、業務の流れと使用する機能を表した図です（図4上部）。主にPowerPointやVisioなどで作成します。業務機能一覧表とは、業務機能を手順に沿って時系列で並べ、他機能との関連などを示した表のことです（図4下部）。主にExcelで作成します。どちらも基本設計の成果物として作成されます。
業務フロー図と業務機能一覧表は、業務の流れと使用機能を把握するという点において、ほぼ同一の目的を持ちます。そのため、詳細設計文書作成用途だけを考えると、業務フロー図と業務機能一覧表のどちらか一方を作成すれば対応が可能なように思えます。
業務機能一覧表の方が記述すべき情報が多いので詳細設計に役立てやすく、個々の業務機能を実装するシステム開発者が機能に関する多くの情報を記述できることなどから、業務フロー図より業務機能一覧表が好まれるかもしれません。
機能の開発自体は、業務機能一覧表だけでも対応できるかもしれません。しかし、総合テストのテストシナリオを作成する場合はどうでしょう。業務機能一覧表だけからテストシナリオを作ることが果たして可能でしょうか。
例えば、図4の業務フロー図を見れば、テストすべきケースは
- 書類不備があるケース
- 書類不備がなく、出張費が1万円未満のケース
- 書類不備がなく、出張費が1万円以上のケース
とすぐに分かります。しかし業務機能一覧表を見ただけでは、テストすべきケースはすぐには思い浮かばないでしょう。
図4の例は非常に単純なものですが、業務機能が多岐にわたる場合、業務機能一覧表を見ただけではテストすべきケースを洗い出すことはできません。
もし、詳細設計や開発が実行しやすいからというだけの理由で業務フロー図を作成しなかった場合、上記のように総合テストのシナリオ作成が困難になります。
つまり、基本設計文書は総合テストのインプット資料になるため、目先の詳細設計や開発のことだけではなく、「総合テスト用途」まで意識して作成する必要があるということです。
基本設計文書作りの面白さと難しさ
上述したとおり、基本設計文書を作るには比較的高度な設計スキルが必要です。またずっと先の工程での用途も意識する必要があるため、システム開発をする中でも最も難易度が高く、最も面白い部分だと思います。
前回紹介した計画書作りは比較的孤独な作業ですが、基本設計文書はさまざまな分野のエキスパートのアドバイスを元に作成していくので、大いに刺激を受けることができます。
基本設計文書作成は、お客さまの要件とシステムをつなぐITエンジニアの、一番の腕の見せ所だと思っています。
私自身は基本設計工程に、アプリケーション構成を考えるポジションでかかわることが多いです。どのようなミドルウェアの使用が適しているか、開発効率を上げるためにどのようなアプリケーションフレームワークを作るべきか、どうすれば性能を確保できるかなど、さまざまな検討要素を盛り込んで設計しています。
基本設計は誰もがすぐにできるたぐいのものではなく、プログラマとしての長い下積み経験や、常日ごろの学習があってこそできる仕事だと思っています。
ただし、忘れてはならないのが、基本設計の成果や評価は、システム開発の後半に差し掛からないと見えてこないという点です。上手に設計できればいいですが、もし設計が誤っていた場合……、あえて説明しなくても分かりますね。
基本設計文書作りに技術スキルが必要なのはもちろんですが、開発工程以降の展開まで見通せるスキルも必要です。経験の浅いITエンジニアはこのスキルを十分取得していないことが多く、なかなか難しいところなのだろうと考えています。
繰り返しになりますが、基本設計文書は詳細設計工程にとどまらず、さらに後の工程でもインプットになることを認識する必要があります。
「負の心理バイアス」や「レビュアー不在の問題」から内容が不十分な基本設計文書を作成してしまうと、テスト工程でシステムに修復不可能な欠点が見つかることになりかねません。基本設計文書の品質の良しあしは、最終的にはテスト工程にて評価されるということを、ぜひ念頭に置いてほしいと思います。
次回は、詳細設計文書のうちデータベース設計文書の勘どころについてお話しします。
筆者紹介
アクセンチュア・テクノロジー・ソリューションズ マネジャー
宮本和洋（みやもとかずひろ）
メインフレームからWebシステムまで数々のシステム開発を経験し、実装可能なプログラム言語は10を超えるシステム開発のエキスパート。「システム開発者だって楽をしたい！」をモットーにし、楽をするための苦労なら買って出るというやや矛盾したポリシーを持つ。風呂場やトイレでいいアイデアが浮かぶことが多いので、狭い空間が大好き。特技は同時に2台のPCでまったく別のプログラミングができること。
- 文書ドリブン開発 テスト文書編
- 文書ドリブン開発 詳細設計文書編
- 文書ドリブン開発 DB設計文書編
- 基本設計文書の質を下げる「4つの心理バイアス」
- 本当は楽しいドキュメント作成
- 新人（3年目）、プロジェクトで「忍耐」を学ぶ
- 新人、集合研修で「伝説」を作る
- 新人（3年目）、先輩デビューで「最悪の振る舞い」
- 新人、アーキテクチャチームで「運命の出会い」
- 1人チームで悩む新人。「この作業って意味あるの？」
- 現場デビューのお供はビジュアル多用の報告書
- 大規模プロジェクトでは「同じ言葉を、同じ意味で」
- 「バッファ込み」の工数がスケジュール遅延の原因
- 運用って、あまりいいイメージはなかったけれど
- 最強チームで挑んだ、「40時間でデータ移行」の壁
- 障害対応とチューニングの危うい関係
- オフショアなんて、怖くない
- 3プロジェクト同時にリード！ どう乗り切る？
- この案件、ぜひ新しいテクノロジでやりましょう！
- 初めてのトラブル対応。これで直ると思ったのに！
- 「できるか！」な設計書に、どう立ち向かう？
- 専門用語で「カッコよく」話すのは簡単だけど
- メンバーとの仕様打ち合わせは海を越えて
- 定まらない要件、ユーザーからのむちゃな要求
- 未経験のデータベース構築に挑戦
- セットアップ全国行脚で九州弁に大苦戦
- 試行錯誤で分かったスパゲッティコード撃退法
Copyright © ITmedia, Inc. All Rights Reserved.