プロジェクトのマネジメントとは

去年わかった大きな成果のひとつに、プロジェクトのマネージメントとはどういうことか、というものがある。

プロジェクトをマネージメントする、ということはどういうことなのか。

それは、プロジェクトメンバーのやる気を引き出す、ということに他ならない。

ソースコードの管理はどうする、バグ管理システムはどうする、メーリングリストはどうする、コーディング規約はどうする、などというようなことはとてもとても些細なこと。

プロジェクトマネージャは、いかにしてメンバーのやる気を引き出すか、ということを、何よりも重視して実行しなければならない。

極論を言えば、プロジェクトマネージャはメンバーのやる気をうまく引き出し、ゴールに向けてプロジェクトが順調に進んでいることを確認すれば、後は就業時間中にずっと新聞を読んでいたってずっと 2ch をしていたってかまわない。プロジェクトが順調な間は、プロジェクトマネージャの仕事は多くはない。

どうやってメンバーのやる気を引き出すか、というのはメンバーそれぞれで異なるだろう。就業後一緒に飲みに行き、その場で進捗報告や問題点、モチベーションを確認する、というのはよく行われる方法だ。この方法でうまくいっているプロジェクトは、メンバーがマネージャを好きなので、プロジェクトがうまく回る。

プロジェクト開始時に誰に何をアサインすれば最もモチベーションが上がるか、ということを把握しているのはできるマネージャの資質のひとつ。ずっと Web 系をやってきた人間でも、だから Web 系をやりたいのもいれば、だから Web 系以外をやりたいのもいる。ここで彼らにアサインするタスクを逆にしてしまったら誰も幸せになれない。

最大限の権限を与える、というのも良い方法だ。細かいところはもちろんプログラマが決めるわけだが、可能な限り上流で決定する権利を与えることで、責任感が生まれる。やる気＋責任感という組み合わせは、自発的に彼らを動かす最も良い心理状態だ。

では、よくないケースはどういうものだろうか。

マネージャがメンバーに過干渉するのは避けるべきだ。この場合、マネージャはメンバーを技術的または性格的に信用できていないケースが多く、だから心配で（もちろんメンバーの心配ではなくプロジェクトの心配だ）つい過干渉してしまう。プログラマにとって忌みする出来事のひとつに割り込みの発生があるが、マネージャが割り込んでいては話にならない。

予定外の作業を急にメンバーにさせると、目に見えてやる気が低下する。今、彼の脳内は現在のタスクをどうするかということでいっぱいだ。作業項目が脳内の構文木にコンパイルされている状態で、その構文木を破棄して、こちらをパースからしてください、とお願いしているわけだ。避けられない突発的な作業は致し方ないにしても、マネージャは上記を十分認識し、見返りを出すぐらいはすべきである*1。

お客さんばかりを見て、メンバーにはケツしか向けていないマネージャは論外だ。もちろんお客さんあってのプロジェクトだし、お客さんと話すのがマネージャの仕事でもあるわけだが、お客さんの言うことばかり聞いて、メンバーにばかり無理強いするのはマネージャとしては下の下。マネージャの仕事はお客さんと話をすることだが、折衝ができないマネージャはマネージャではなく単なるスピーカーだ。

僕はこういうプロジェクトマネージメントをしている、という決まりはないんだけど、プロジェクトのマネージメントの仕方はそのプロジェクトを構成するメンバーによって決まってくるので、プロジェクトというのは生身の人間が複数人参加して成り立っている「生もの」である、ということと、いかにメンバーのやる気を引き出すか、ということを一生懸命考える、ということを忘れなければ、プロジェクトは成功するだろう、と考える。

*1:ひどいマネージャだと、割り込みを発生させておきながら、スケジュールは変わらずとか