システム開発を外注したとき、当然やってくれると思った業務を外注先がやってくれないことがあります。

たとえば、仕様書を作ってくれないとか、ソースコードが提供されないとか、使い方のマニュアルを作ってくれないとか、さまざまな問題があります。

この問題は決して外注先の問題だけではありません。

発注元も「こういうものを用意して欲しい」を契約の段階で明らかにすることが大事です。

なぜなら、そういった作業一つ一つは手間のかかる、つまりコストが発生することなのです。

契約して仕事を開始してから「こういうものを作ってくれ」と言われたら、少々のことは受け入れるにしても、ある程度の量を超えコスト的にも見合わない仕事量になるなら、「それは契約にありませんので、対応できかねます」と断られることもあります。

開発に入ってからもめないように、「やってもらう作業は契約時に決めておく」ことはとても大事なことになります。

契約書で成果物を定義しよう!

外注先に仕事を依頼する場合、どんな仕事をしてもらうのか話し合いますが、仕事の内容とか納期だけでなく、どのような成果物を期待するかしっかりと合わせるようにしましょう。

成果物にはいろいろなものがありますが、たとえばホームページの開発をしてもらうのであれば、

* デザイン書
* 設定一覧(サーチコンソールやアナリティクス、サーバーの契約やその他の設定)
* 概要設計書
* ホームページの修正手順書

といったものが考えられます。

あくまでも例であって、ホームページを作る場合に、これを成果物としてもらえば十分ということではありません。

ではなぜこういうものが必要なのでしょうか?

成果物は何のためにもらうのか?

外注先からは完成したものがもらえれば、その他の成果物なんてなくてもいいよと考えるかもしれません。

しかし、仕様書や設定一覧、あるいは手順書のようなものは、そのシステムがどう作られているのか、そして自分たちが使うためにはどうすればいいのか、ということを知るためには欠かせない情報です。

発注したものが完成し納品されたあと、それを誰が使うのか、どんな作業をするのか、その頻度はどのくらいなのか、といったことに依存しますが、できる限り発注先に依存せず発注元で対応できるようにしておくおとは何かと大事なことです。

自分たちで少しでも対応できれば、毎月契約するお金が不要になったり、都度外注に頼むようなコストを省くことができます。

また、その後機能を追加したり使いやすいように改修したい場合に、前の設計情報が残っていれば別の業者に頼むこともできます。

設計情報がないと新たに仕事を受ける業者にとって、調査から始めないといけないので設計に時間がかかる(=お金がかかる)という問題があるのです。

そういうこともあり、後々のためにもしっかりと仕様書や設計書を作ってもらうことは非常に大事です。

成果物の決め方

成果物の決め方は、システム開発のような場合はある程度基本になるようなものはあります。

・要件定義書
・仕様書
・設計書
・テスト項目
・テスト結果
・運用設計書
・運用手順書

といったものが代表的な例になります。

ある程度大がかりなものは設計のプロセスごとに成果物を決めて、その成果物をレビューして成果物として問題ないことを検証していきます。

ただ、小さな開発の場合や大きなコストをかけられない場合、細かく文書を決めれば決めるほどコストが上がることになりかねません。

また、そこまで細かい設計書をもらっても、中身を見ることもなく使われないのであれば、それこそ無駄なものになりかねません。

ですので、必要なものを選んでいくことも必要なスキルです。

成果物が出ているかをしっかり検証する

成果物は単に最後に納品されればいいというものではなく、必要なタイミングで作られているかということも大事なことです。

文書って最後にとってつけたように作るものではないのです。

まとめるという意味では最後に作ることも多いのですが、文書を作るための準備というのは日々必要になりますし、それができているかということを見る目も必要です。

最終の成果物を品質良く得るためにも、最後だけでなく最初からしっかりと見ておくことを忘れないようにしましょう。