納品段階、まだまだ問題・修正はでてきます。

納品段階

現場での最終確認

さていよいよ納品段階です。

現場での最終確認を行ないます。

パソコンソフトであれば、パソコンの設定インストール作業も必要ですね、マイコンプログラムであれば、ここが正念場、エンドユーザーとの間にいくつかの会社が入っていれば、全ての会社を回って接続テストが繰り返されることになります。

完成状態のアプリケーションの最終確認のはずなのですが、私の経験上この場においても仕様変更が発生することがあります。担当者の状況にもよるのですが、初めて真剣にアプリケーションの動作を確認ってこともあるのです。なので、多少の仕様変更は覚悟の上で臨んでください。

そして、時間が許す限り現場で修正しその場で承認して頂きましょう。一度持ち帰って修正となると二度手間になりますし、その場で確認してもらえれば思い違いも減ると思います。

とにかくこの段階の目的は担当者レベルでの承認を頂くことです。

取扱説明書の作成を行ないます。

パソコンソフトの場合、仕様書のユーザーインタフェースに関する部分が、そのまま取扱説明書となる場合が多いので、最終仕様での仕様書のまとめということになるかもしれません。

取扱説明書というのは、いくらでも詳細に書くことができますし、簡略化することもできます。この事は最初の打ち合わせの段階で決めておきましょう。

また費用削減のためにいらないっということあります。

この項目は担当者によって全て行なっていただける場合と、自らが担当者の変わりに行なう場合があります。

パソコンソフトの場合、ここがちょっと大変なところです。特に事務系ソフトの場合、複数の方が使用することになるので、説明や質問に答えるだけでも一苦労です。

ここでひとつ明らかになることがあります、いかに担当者がエンドユーザー（実際にアプリケーションを使用する人達）と緊密に打ち合わせをし、それをまとめていたかということです。

もし、エンドユーザーとの打ち合わせもせず、業務内容を完全に理解せず、私に発注していた場合、ここが修羅場となります。また、システムの置き換えともなりますと、「以前のソフトはもっと使いやすかった」、「あれ！あの機能はなくなったの」などなど、収集がつかなってきます。

システムの成功、失敗はプログラマである私の責任でもあるのですが、この担当者という立場の人の能力が大きく作用するのです。とにかく、この段階でも仕様変更は、発生するものと覚悟しておいてください。

仕様変更に伴うプログラム修正も終り、インストール作業も終了。

後は、成果物の納品です。何を提出するのかは、初期段階の打ち合わせで決め、仕様書にもちゃんと記載しておきましょう。

提出物としては。

っとこんな物です、仕様書、取扱説明書、プログラムドキュメントはまとめて一冊の場合もありますし、いらないということもあります。

ここで一番問題となるのは、ソースです、私の場合はソースは必ず提出します。

ソースは誰のものかというのは契約段階（私のような個人では行いませんが）で決まる事です。他社様の話でよく耳にすることですが、ソースは渡さないということも多いようです。

つまりソースは作成者のノウハウでありそれは公開できないということなのです、要するに使いまわしをするということとソースを渡してしてしまうと他の会社に乗り換えられてしまう危険があるということみたいです。

私の場合は契約もできませんし、大したノウハウも持っていないので、ソースもドキュメントも全て提出しておきます。それと会社組織ではなく個人なので、私がいつ病気で倒れるか交通事故に会うかもしれません、なので保険としとの意味もあるのです。

こんな話もあります、アプリケーションの修正依頼がきました。

なので、とりあえずソースをメールで送ってもらえますかっと尋ねると「ソースってなんですか」っという返事。担当者はソースの意味さえ知らされておらず、もちろんソースは提出されていない、そしてそのアプリケーションを開発した会社は倒産したとか、もうどうすることもできませんよね。