プロジェクト・リーダーの心得

（3）ヒトを動かす

最後に「人を動かす」について解説します。プロジェクト・リーダーは、メンバーに動いてもらわなければならない立場です。プロジェクトの規模にもよりますが、どれだけ小規模であったとしても、必ず数名のメンバーと一緒に仕事をすることになります。

まず、リーダーが知っておくべきことは、「人は理屈では動かない」という事実です。

「人を思い通りに動かす」といった内容の書籍も多数出版されていますが、これらを読み込んだところで、人は動かせません。そもそも、自分自身ですら24時間完ぺきに動かすことは困難なはずです。

例えば、「メールの返事はすぐに返したほうがよい」と分かっていても、トラブル対応などのような気が進まない内容のメールには、なかなか返信することができないのが現実です。「頭では分かっているけど、どうしても後回しにしてしまう」という経験は、誰にでもあるはずです。

自分でさえ動かせない程度の理屈で、ほかのメンバーを動かせるはずがありません。メンバーを動かすためには、「共感」を得る必要があるのです。

また、リーダーが犯ちがちな、大きな間違いがあります。それは、リーダーは「言う人」、メンバーは「やる人」と思い込んでしまうことです。

もちろん、リーダーがすべての仕事を1人で行うことは不可能です。プロジェクトチーム内で、それぞれ役割分担を行う必要があります。

しかし、ユーザーとの交渉や、プロジェクトに望む姿勢に関しては、リーダー自身が先頭に立って取り組む必要があります。「たとえメンバーがやらなくても、自分だけでもやる」というくらい強い気持ちが必要なのです。

リーダーである以上、プログラミングなどの実作業は、プログラマに任せることになります。しかし、丸投げするのではなく、「いざとなったら自分でプログラムを書く」という気持ちで臨むことが大切です。プログラミングを行わないとはいえ、少なくともプログラミングのレビューには携わるべきでしょう。プログラムが分からなければ、猛勉強する必要があります。

経験上、プログラムが書けないリーダーは、プログラマと会話を行うことができないため、丸投げせざるを得ない状況となります。この結果、問題発生時に責任のすべてをメンバーに押しつけることになり、メンバーを肉体的にも精神的にも疲弊させることになります。

「リーダーが、常に先頭に立って、メンバーを引っ張る」ことで、メンバーは「この人に付いていこう、この人のために力になろう」と「共感」を得ることができます。このように書くと大げさですが、難しいことを実践する必要はありません。「リーダーは必ずメンバーよりも早く出社し、メンバーよりも遅く帰る」を徹底するだけでも十分です。つまり、プロジェクト・メンバーの中で、プロジェクトを成功させるために一番努力を重ねればよいのです。

例えば、朝。プロジェクト・メンバーよりも早く出社し、その日のタスクをメンバーにメールします。そして、夜。プロジェクト・メンバーが全員帰った後に、その日に発生した課題と問題点をメンバー内に連絡します。このサイクルを重ねることで、リーダーのプロジェクトに対する姿勢を伝えることができます。「リーダーがこんなにがんばっているのだから、自分もがんばろう」と自発的に動いてくれるようになれば、プロジェクトは円滑に進むでしょう。

また、リーダーは、自分の人格や人間性に関して、メンバーから信頼を得ることが大切です。

システム開発はトラブルがつきものです。品質問題、セキュリティ問題、パフォーマンス問題など、「困難な状況」に直面する機会が多いことでしょう。こうした中、後ろから「私は先に帰るけど、君たちは明日までに、発生しているバグを修正してくれ」と言われても、リーダーとしての責任感が欠如している、と失望されることでしょう。

本来、このようなケースでは、リーダーが率先して問題の原因解析を行い、リーダー自身で原因を見つけることが大切です。人任せでは何も進みません。あくまでもリーダー自身が動くことが、何よりも大切なのです。

「人を動かす」という事例は、歴史からも学ぶことができます。戦時中の日本では、「指揮官先頭」という言葉がありました。映画『硫黄島からの手紙』で渡辺謙氏が演じている栗林忠道中将は、まさに「指揮官先頭」を体現していました。指揮部隊の最後の伝令では、「予ハ常ニ諸子ノ先頭ニアリ」と命じています。日本軍が圧倒的に不利な状況下であったにも関わらず、部隊の士気は非常に高かったと言われています。

近年、成果主義を掲げる会社も増え、より厳格に数字を達成することが求められるようになりました。この結果、リーダーがメンバーに対して無理強いする悪例も増えるようになりました。

リーダーという立場を使えば、強制的に人を動かすことも、短期的には可能でしょう。例えば、外注先との関係が考えられます。仕事を受注している立場では、依頼主であるリーダーに対して強い態度はとれないものだからです。リーダーによっては、「この問題が解決するまで、貴社へ検収することはできません」という強硬姿勢に立って外注会社を動かすこともあるでしょう。

また、お金を使って人を使う、ということも考えられます。「あと100万円支払うので、この仕様変更に、明日までに対応してください」というようなケースです。システム開発では、お金と時間と人手が必要ですが、お金だけ積まれても時間がなければモノを作ることはできません。また、リーダー自身が経営者でない限り、プロジェクトに対して無尽蔵にお金を投入することも難しいでしょう。

上記の2パターンのような、メンバー泣かせの人の動かし方は、長続きしません。必ず破綻します。メンバーからの共感と信頼が得られないからです。1次開発に成功したとしても、2次開発、3次開発、と進み、その後に続く保守のどこかで、必ずメンバーから「あのリーダーの元では動けない」と見限られてしまいます。

おわりに

今回は、プロジェクト・リーダーとして大切な3つの心得について解説しました。本記事を参考に、リーダーの方々の役に立つことができたら幸いです。