プログラマの進捗管理は、感覚的に把握できることが必要

プロジェクトが成功するためにはプロジェクト管理が欠かせません。

リリース日から開発スケジュールを決め、仕様書作成・UTの完了・システムテストの完了・ユーザー評価の完了、などのように大きなプロセスの納期を決めただけでは実際にはその納期通りには終わりません。

自分一人ですべてプログラムを仕上げるのであれできるかもしれませんが、ほとんどのケースは一人ではありません。

規模が大きくなればなるほど、複数人で開発することになりますし、誰かが書いたプログラムと連携して動作するのが通常だからです。

自分のパーツを書き上げることはできるにしても、全体として動作しなければ意味がないわけです。

そのためには、それらのプログラムがどのように連携するのか仕様を決めなければなりませんし、仕様を決めて実装したら本当に期待通り動くのかをテストしていかないといけません。

そのように進めるためにも、誰々のプログラムはいつまでに作る、そして細部の連携のテストをしながら徐々に全体を通して動作確認していくことになるのです。

全体の動作確認をするためには、個人個人のやるべき時期が自ずと決まってくるのです。

その納期に向かって設計活動を進めていくのですが、それがうまくいっているかを管理しないと、気づいたら遅れているということになりかねないのです。

プロジェクトの成功に、「進捗管理」は欠かせない作業なのです。

進捗管理で悩ましいのがどの単位で進捗を確認していくかです。

どこまで細かく管理するか、ということです。

細かさには、仕様書を何ページ書いたとか、コードを何ライン書いたとか、そこまで報告する方法もありますが、

そのためには「全体で何ページになるのか」、コードなら「担当分は何ラインになるのか」という見込みが立っていないと、進捗の善し悪しが判断できません。

ところが実際にはそこまで正確に見積もれないという現状があります。

全体としてざっくり「何Kラインぐらい」という開発規模は見積もれても、進捗を測るために数値化できるほどに正しい見積もりを出すことは難しいのではないかと思うのです。

経験の浅い人であれば、見込みのライン数に対して進んでいる、遅れているという進捗管理は有効かもしれません。

それでも、仕様書だってプログラミングだって、考える日と書く日は分かれます。

調査や設計をしていて検討段階は進捗がないように見えても、決まったら一気に書き上げるスタイルの人もいるのです。

そう考えると、あまり細かな進捗管理より、進捗に課題があるのかないのかを把握することの方が大事なのです。

進捗管理の大事なところは、

・プロジェクトマネージャが進捗を把握し、
　遅れなど課題があれば、対策を打つこと

これに尽きます。

対策の最も初期の対応は、担当者本人が遅れているという自覚を持って、開発速度を速めることになります。

本人に問題意識が薄いとすれば、しっかりと納期を意識させることが大事ですし、

そのためにはより詳細な納期を設定することも必要です。

ある機能の実装に対して、UT（ユニットテスト）完了の納期が決まっていたとして、

それをするための設計書の作成やレビューの実施、環境構築、コードの作成とデバッグの開始時期など、より詳細なスケジュールを決めてそれが守れているかどうかで遅れを認識させるとということです。

もし、本人の問題ではないところで止まっているのであれば、止まっている問題自体が解決できるようにしていくことが必要です。

そのようにして、進捗を把握し遅れがある場合には初期の段階で解決していくようにするのです。