システム開発プロジェクトで「管理」というと日常的にはスケジュール管理、タスク管理を指します。２つをまとめて進捗管理ということもあります。具体的には次のような作業です。
- 新規発生したタスクに担当者と納期を割り当てる。
- 実績を把握する。
- 予定と実績にズレが生じた場合は、しかるべき対処をする。
突き詰めてしまうとこれだけなのですが、ちゃんと出来ているマネージャは稀です。これを深堀すると色々あるのですが、今日は2.について軽く話したいと思います。
私が見てきた現場では管理者（以後マネージャと呼びます）が作ったWBSにプログラマが日々進捗を入力する形を取っていることが多かったようです。
WBSはEXCELで作られていることが多かったのですが、ここ５年くらいになってようやくWEBアプリ（といってもRedmineですけれど）が定着しつつある感じです。ただEXCELが絶滅したわけではなく、何かにつけてEXCELで台帳や報告書を作らせたがる人もいます。
さてプログラマがこうした進捗入力をきちっとやるケースは意外と稀です。面倒くさいから、やらなくても特に文句を言われないことが多いから、マルチタスクで作業していると進捗入力のような事務作業が頭から抜け落ちるから、など理由は色々です。
ではそのようなプログラマは性質が悪いのかと言うと、私はあながちそうでもないのではないかと考えています。
まず、そもそも論で言うと”進捗確認”という作業は誰の作業でしょうか。言うまでもなくマネージャの仕事です。断じてプログラマの作業ではありません。マネージャの負荷軽減のためにプログラマに作業を一部委託しているだけです。
そしてWBSまたはスケジュール表というアウトプットに対して責任を持つのは誰でしょうか。それもマネージャです。プログラマではありません。
であればマネージャはプログラマの負荷にならないようにマネージメント環境を整え、手順を明確にし、また報告された事項に対して即座にレスポンスを返すことが求められます。今の時代、そういったことは非常に簡単にできるはずなのです。
しかし不思議なことにそう考える（プログラマ側でも）人は非常に稀なようです。プログラマはマネージャより下という意識があるのでしょう。
なお私が現在所属しているプロジェクトでは、カテゴリごとに台帳が分かれていて、それらがどこにあるのか一目ではわかりにくくなっています。また最初にマネージャがやったのは台帳を用意することだけで、その元となるタスクはプログラマが作り、なぜか予定もプログラマが入力しています。
しかもマネージャは台帳を常にチェックしているわけではなく、気が向いたときに見て、抜けがあったら指摘するだけです。
ここまででも相当にダメなのですが、さらに恐ろしいことがあります。
このマネージャは台帳とは別に報告書を週次で作らせ、それを週１回の定例会（２時間以上）で１つずつ確認します。この間定例会に出ている全メンバーが拘束されます。
さらにこれとは別にタスクの棚卸しを任意のタイミングでやっているようで、そのときにタスクの状況をまた確認するのです。
プログラマにとっては物理的な時間が大きく削がれるだけではなく、同じことを何度も聞かれることによる精神的な苦痛と、意味がない作業（日々の進捗入力）をさせられているという徒労感により士気の低下をもたらします。
そしてそれらは最も重要な成果物であるプログラム資源の品質低下を引き起こすことになるのですが、マネージャはそのようなことを全く考えていないようです。