機能一覧表とI/O関連図

請負で仕事をするために必要な2つの作業

   システム開発の仕事では、仕様の追加や変更は日常茶飯事です。「これで仕様凍結！と宣言して、仕様変更を受け付けなければ良い」などとこちらの勝手を言う人もいますが、事はそう簡単にはいきません（安易な変更を抑制する効果はありますが…）。現実的にはその仕様のままじゃ動かなかったりするので、ある程度の追加・変更はあるものと覚悟しておく必要があります。

   社会においても「警察官や教師は、不正があってはならない」というタテマエにとらわれて対策を打たないことが問題視されています。「彼らも不正行為を犯す」という前提に立って対処方法を定めておくべきというのが現代の常識です。同じように、仕様変更も発生し得るという前提に立ち、それを吸収しながらプロジェクトを成功させるという柔軟な姿勢が重要なのです。

   常駐・派遣ベースでは、変更が生じてもリスク（コストやスケジュール）は基本的に相手側にあります。しかし、請負で仕事をする場合は、仕様変更による損失がもろにかぶさるので、十分な対処が必要です。

   対処のひとつは、口頭でなく文書レベルでやり取りするということです。具体的には、打ち合わせをしたら「打合議事録」をきちんと書く、タイムリーにレビューをして「レビュー報告書」を提出する、仕様変更は電話ではなく「仕様変更依頼書」で受け付けるなどです。これらは、PMBOKにおけるコミュニケーション管理に相当するもので、プロジェクト管理手法PYRAMIDではドキュメントテンプレートを用意して運用することを定めています。

   もうひとつ、その前段として必要なのがPMBOKにおけるスコープ管理です。つまりプロジェクトスタート時に開発範囲を明確にしておくことが大切です。スコープの表現には作業（タスク）と成果物の2つの切り口があります。

   ときどき未確定な部分があるという理由で、スコープをあいまいにしたままプロジェクトをスタートさせている例を見かけます。しかし、そんな場合でも"その他帳票10本"というように未確定ながらボリュームを抑えておくことが、請負で仕事をする際は肝心です。

機能一覧表

   第1回は、開発ドキュメント標準DUNGEONで規定されている開発ドキュメント体系を紹介しました。また、その中から「業務フロー」の標準テンプレート記入例をもとに、業務フロー記述のポイントについて解説しました。

   今回は、スコープを明確にするためのドキュメント「機能一覧表」を取り上げて説明しましょう。図1は、DUNGEON様式の「機能一覧表」の記入例です。システム開発対象となる機能を洗い出して、大分類（サブシステム）、中分類（機能分類）ごとに整理して一覧表にまとめています。

   ここでは、機能ごとに画面入力、画面照会、帳票出力、バッチ処理の4種類に区分けをしています。このほかにも帳票出力指示画面などがありますが、それらは"照会"に区分けすることで対応します。

   プロジェクトの最初の段階では、機能の洗い出しが完全にできません。しかし、ぐずぐずと「機能一覧表」の作成を延ばしていると、全体のボリューム把握が遅れプロジェクトに支障が生じます。機能一覧表は、不完全でも良いので必ずプロジェクトの初期段階で作成し、仕様が固まるのと並行して追記・修正していくようにしてください。