納品時に気をつける事

年度末というと、納品のごたごた。

いくら厳しくてもきちっと検収してもらわないと後でえらいことになります。せっぱ詰まって、バグや未実装部分の残件は4月以降に必ず対応するから今年度中に支払いをお願いしますなんて交渉したとします。お客さんも今年度の予算は今年度中にしか使えないし、うちの会社もグループ企業の一員で金もって夜逃げなんてことはありえないそれなりに信用のある会社なので、まあシステムの出来具合次第でしぶしぶOKしてもらえることもあります。

ところが、4月に入ると当初の残件以外に仕様変更や仕様追加の嵐。もう支払いは済ませているんだから責任もって対応してくれと、延々と搾られることになります。当然プロジェクトの収支は真っ赤っか。
とはいえ、その辺の程度にはお客さんの心情が影響します。仕事について強い不満を持っている場合は情け容赦のないことになります。逆に結果はどうあれ良くやってくれたと思われている場合は、多少加減してくれたり残件の対応分を追加発注してくれたりします。

納品時に気をつけなければならない事はお客さんを満足させることでしょうか。まあ当たり前のことですが、納期までに仕様通りのシステムを納品しても、それまでのすったもんだでお客さんの心情が最悪なら重箱の隅を突かれることになります。信用できない人間が作ったシステムもまた信用できないということです。

お客さんの満足度を高める為に何をすべきかというと、いろいろありますが大事なことは説明責任を果たすということですね。プロジェクトの見える化といってもいいです。

• スケジュールや問題点について早くからお客さんに説明する。
  • 簡潔に要点をまとめた文書を提出することが重要。長々とした報告書を出しても読んでくれません。
• 自分達以外の遅れの原因、つまり不測の事態やお客さんの都合によるロスをうまく説明する。
  • 問題が起きた時点で議事録に残しておくことが重要。納期間際で口頭で説明しても言い訳と受け取られます。
• 開発後半から残件がどれだけあって、どのくらいで対応できるか見通しを示す。
  • 最悪なのは90%出来てますとあいまいな報告をして、毎週90%のまま進まないことです。これはタスクを細分化してWBSを作成していないことが多いですね。同時に未熟な担当者と（忙しくて）細部まで把握できないリーダーという組み合わせが多いです。
  • 残タスク数を元にバーンダウンチャートを書くのも良いです。
  • 各工程のレビューの記録をしっかり残しておくと上流工程で問題点の検出が不十分なので、コーディングからテストにかけての折り返しで不具合が多発しそうだとか見通しが立てられます。

うーん、納品が近くなってやばい！と感じた時に出来ることはほとんどなく、プロジェクトの初期から心がけなければならない事がほとんどですね。「納品は一日にして成らず」ということでしょうか。