開発の成果物を定義しておく

プログラムやアプリケーションを開発する場合の成果物は、プログラム本体だけがあれば良いということではありません。ただソフトウェアだけが納品されてもそれを用いる担当者が活用できなければ意味がなく、クライアント側で導入を推進している担当者に関しては、現場がしっかりとそのシステムを使いこなすことができてはじめて本来の目的が果たせることになります。つまりマニュアルや仕様書も加味しておかなければ、いざ納品されたものの使い方がわからないという事態に陥ってしまうことがあるという可能性もあります。

プログラムの機能やそれにかかるコストに意識が向いてしまうがために、そのような導入に関する問題をまったく度外視してしまっているケースは多々あります。特にノンサポート、つまり開発側は納品したら仕事が終わり、というケースではそのシステムを受け取った側がその後の社内に対するコーチングを考えなければいけなくなります。高いコストをかけて開発したものであるのに、誰も使うことができないというような事態に陥ってしまっては勿体ないことになってしまいます。

基本的にフルスクラッチ、つまり完全オリジナルで開発されたシステムに関してはそのマニュアルは黙っていれば成果物として納品されることはありません。仕様書や設計書など、専門的なドキュメントは本体と共に納品されることが多いですが、それは発注側の情報システム担当者がメンテンナンスするための拠り所になるものです。あらかじめ見積りの段階からスムーズに導入ができるようなマニュアルを成果物として定義しておかなければいけません。

さらに、開発費用のなかにそのマニュアルを入れ込むことも難しい問題になります。マニュアルを用意する工程とシステム開発の工程はまったく別であり、開発ベンダーによってはマニュアル制作を外注する場合もあります。ほとんどの場合でユーザーマニュアルのように体裁が整ったものは別費用と捉えておく必要があります。

パッケージ化されたシステムやWebベースで動作するシンプルなものであれば、このような成果物に関する注意を行う必要はないこともありますが、複数人のスタッフが関わることになる通販システムなどは、ひとつのシステムが複数の部署で用いられるケースもあるため、機能が雑多でひとりの担当者がすべてを把握することができないことも多いです。そのような際に手引書として提示できるものがあれば導入はかなりスムーズになります。