手法別開発ドキュメントの書き方第2回

顧客向けドキュメントだけでは、品質の高いソフトウェアは作れない

次はソフトウェアを作る工程です。他の製造業と異なり、ソフトウェアは毎回異なるものを作る「オーダーメイド」です。そのため、共通のマニュアルを作ることは難しく、プログラマに作り方を説明する方法は、毎回現場で試行錯誤されています。顧客向けドキュメントだけでプログラミングをしなければならないこともあります。

ソフトウェア開発には、数名から数十名のプログラマが携わります。全員を自社で揃えることは難しく、さまざまなところからの寄せ集め集団になることが少なくありません。スキルレベルや得意領域、経験年数がバラバラのプログラマが顧客向けドキュメントだけでプログラミングをすると、統一感の無いプログラムができあがり、動作させるだけで一苦労です（図2、上）。

運よく動くものができたとしても、機能追加やバグ修正の際に必ずといってよいほど問題が発生します。ソフトウェアには状況の変化に応じて変化していくことが求められますので、一度作って終りにはならず、何度も手が入ります。統一感の無いプログラムでは、そのような作業を行うことが想像以上に厳しく、ときには簡単な機能追加や修正が思わぬバグを引き起こすこともあります。

ソフトウェアの外部に対する振る舞いを説明したものである顧客向けドキュメントだけでは、ソフトウェアをどのように作ればよいかはわかりません。品質の高いソフトウェアは統一感のあるプログラムで構成され、機能追加や修正の際も最小限の作業で済むようになっています（図2、下）。品質の高いソフトウェアを実現するためには、プログラマに対してどのように作ればよいかを説明する開発ドキュメント（以下、プログラマ向けドキュメント）が重要な役目を果たします。

図2：プログラマ向けドキュメントの役割

「プログラマ」に対して「プログラムをどのように作れはよいか」を説明する

プログラマ向けドキュメントと聞くと、詳細なDFD（Data Flow Diagram）やシーケンス図などが思い浮かぶかもしれません。しかし、プログラムの内部構造をすべてドキュメント化するようなことは現実的ではありませんし、その必要もありません。ソフトウェアは共通の処理やいくつかの似たような機能で構成されることが多く、まとめられる部分があります。そのような部分の作り方はまとめてしまい、プログラマに対するプログラミングの手引書となるようなドキュメントを作成することが可能です。

また、似たような機能は作り方の「型」を決めてしまうことも効果的です。オープン系の開発では、オープンソースのフレームワークを使った開発が主流で、使わない開発の方が珍しいくらいです。フレームワークを使ったプログラミングには一定の型に従うことが求められるため、フレームワークをうまく使うことで、作り方の「型」を決めることができます。

しかし、単にフレームワークを使うだけでは不十分です。フレームワークはさまざまな状況を想定し、自由にプログラミングできる部分を残しています。また、適切に使うには想像以上に高いスキルが必要です。複数のプログラマが協調せずにフレームワークを使うと、まったく異なった使い方になることがよくあります。フレームワークを使う場合には、そのプロジェクトにおける使い方を決め、それを説明するドキュメントが必要になります。

プログラマに対してどのように作るのかを説明する開発ドキュメントは、RUP（Rational Unified Process）などのオブジェクト指向開発で「アーキテクチャ設計書」という名前で注目されるようになりました。しかし、実はメインフレームの開発の頃から「基盤設計書」などの名前で重要視されており、今よりもしっかり作成されていたようです。多くのプログラマが集まってプログラミングすることには、今も昔も変わりがありません。ますます短納期化するソフトウェア開発ですが、最低限のプログラマ向けドキュメントを作成することは大切なことです。