開発が遅れる原因

受託開発で開発の遅延が発生するのは、私の実感している感じとしては、3割くらいあるような気がしていますが、その原因は様々です。プログラマーの腕が悪いこともありますし、そもそも無理なスケジュールであった場合ももちろん遅延します。これまた私の実感としてですが、原因の半分以上は仕様に関する問題だと感じています。

プログラマーの立場として最も困るのが仕様が決まらないことです。そもそも作ることができませんので。仕様変更も困ります。プログラムは基本的に決定した仕様を元に構成を考え、作りながら動作確認していきますので、仕様が途中で変わると構成に歪みが生じたり、すでに確認し終えた部分に影響が出たりします。プログラムの品質を下げる原因の一つが仕様変更です。もちろんベテランになればなるほど仕様変更を想定して作業を進めているものですが、それでも影響は大きいものです。

仕様関連以外では、要求がどんどん膨らむことです。要求とは、例えばこういうドキュメントも作って欲しいとか、こういうテストもやって欲しい、など、作業が増えるようなものです。多くの場合品質や性能にほとんど貢献しないような作業を要求されるため、プログラマーは非常に嫌な気分になるものです。これらの要求は、IT業界の多段下請け構造が作り出すことが多く、上に報告するために資料のボリュームやテスト項目数が必要ということが原因になります。そのようなあまり意味のない要求に対応していると、肝心の動作の流れを見るような確認の時間が取れなくなり、結局資料の体裁ばかり整って、動きはいまいち、というシステムができあがってしまい、その先の結合・総合テスト工程でひどい状態に陥ります。

これらの問題はプログラマー側に責任が無いわけではありません。依頼側からの要求に対して、それはどのくらいの作業ボリュームで、行程にどう影響するかなどを伝え、交渉しなければなりません。何とかなるだろうと安請け負いすると、頼んだ側としては頼んだ瞬間は良いのですが、結局後で苦労することになります。問題を先送りせず、何ごとも早めにきちんと解決しながら進めることがとても大切なのです。

信頼できる仕事を続けられるかどうかが、お客さんとの関係維持のポイントです。なんでも言うことを聞くのがお客さんにとっての利益になるのではなく、議論しながら確実に進めることがポイントです。依頼する側としても、反論が無いというのは、本当に考えているのか？と、不安になるものです。先延ばしはなにひとつ良いことがありません。

2つ前に書いた、昔からの仲間の方から言われたことですが、「小俣さんに仕事を依頼すると、メール爆弾が飛んできたのを思い出す。」と。仕様書を読みながらプログラミングし、気になることを片っ端からメールで問い合わせたところ、一日で何十通ものメールが流れていた、ということなのです。今思えばもう少しまとめてから問い合わせても良かったと思いますが、返答する側も一気に大量に受け取るより、こまめに対応する方が楽だろうと思って、都度送っていました。メールの量から見てしっかり進んでいるな、と実感できて安心だったと言われたものです。お互いにとって一番大事なのは成功することです。コミュニケーションで手を抜いて上手く行くことなど滅多にありません。