リーダーシップは天性ではない：初めてのプロジェクトリーダー（7）

　連載最終回は、いままでのおさらいに加えて、これまで言及できなかったテーマについて書くことにします。

連載内容のおさらい

　まずは連載内容のまとめとして、それぞれの連載内容の要約と、「どのような人が、どのようなときに読むと効果的か」を説明します。もちろん連載内容は、初回から順次読むと効果的なように組み立ててありますが、それぞれの回を単独で読んでも、なんらかの気付きがあるはずです。

第1回 開発者からリーダーへの視点の切り替え

　連載初回は、プロジェクトリーダーが持つべき価値観と、従うべき原則論について説明しました。メンバーとリーダーでは全く違う視点を持つ必要があり、これらの切り替えが最も難しい課題となります。いままで何回かリーダーの経験があるけど、どうもチームがうまく機能していないと感じるリーダーは、まずは初回から読み進めてください。

第2回 なにはともあれ、まずはチームビルディング

　リーダーにとって、チームビルディングは最も重要な活動の1つです。第2回は、プロジェクトチーム計画書作成を通じて、チームビルディングの一例について説明しました。メンバーの性格に応じた役割分担や、期待感を伝えることが重要なポイントです。いまからチーム作りをする、あるいはチーム体制を見直したいという人にお勧めします。

第3回 朝会を15分で終わらせるには理由がある

　最も反響があった回で、個人的には最も実践的であったかなと自負している回です。タイトルでは、「朝会」が目立っていますが、内容的には進捗（しんちょく）会など、「硬めの」会議について多く言及しています。特に議事録に対する心構えと、書くべき内容について注目してください。この会は、別にプロジェクトリーダーでないメンバーにも役に立ちます。

第4回 開発中、リーダーは何をしている？

　特に小さなプロジェクトのリーダーをしていると、常に「兼任」は避けられません。また、「まだまだ現役」的な考え方を持ってプログラミングに取り組むリーダーも多いでしょう。第4回は、進捗の「見える化」を中心にしながら、このような兼任リーダーについての話題も扱いました。

第5回 リーダーとしての問題解決能力を磨く

　プロジェクトリーダーをしている限り、そのプロジェクトで発生する問題からは逃れられません。この回では、プロジェクトで発生するであろう、さまざまな問題に対する対応について、基本的な考え方と、具体的なケーススタディを交えて説明しました。問題解決能力は、なにもリーダーだけに必要なスキルではありません。普段はプログラミングを主に行っているメンバーでも、プログラムの（不可解な）バグに対応するためには、同様の考え方とスキルを使って問題解決に当たる必要があるでしょう。

第6回 「ふりかえり」でプロジェクトを改善する

　「ふりかえり」とは、プロジェクトの活動を通じて継続的な改善を行うためのアプローチです。この回は、そのアプローチの一手法である、「KPT法」について説明をしました。KPTは、習得が簡単で定着率が高く、次の課題・アクションが見えやすいという特徴があります。KPTは仕事だけでなく、いろいろな場面に応用が可能です。「プロジェクト」や「リーダー」にこだわらず読んでみてください。

書き残したこと

　連載のスタイルであった、「価値・原則・実践」という枠組みからはちょっと外れますが、最後に、これまでの連載では書き切れなかったことを、バラバラと書き連ねさせてもらいます。

リーダーの修行方法

　実践的項目の1つとして、リーダー修行の方法について書きます。それは、「リーダーになったつもりシミュレーション」です。

　これは、あなたがサブリーダーなど、リーダーと同席する機会が多い場合に有効です。ただし、リーダーが、あなたの尊敬できるリーダーであることが条件です。

　やり方は簡単で、お客さまとの打ち合わせなど、何かリーダーが判断を迫られる場面に同席した場合に、（心の中で）自分だったらどう判断し、どう発言するだろう？ ということをシミュレーションしてみます。

　そして機会があればリーダーに「なぜあのような判断をしたのですか？」と聞いてみるとよいでしょう。もちろん、リーダーの判断が常に正解で、ベストである保証はないのですが、優秀なリーダーであれば、一貫した価値観と原則に従って理屈を説明してくれるはずです。

　この方法は、実際にあなたが判断をするわけではないので、プロジェクト実施面でのリスクがありません。どんどんやってみるといいでしょう。

リーダーシップは天性か？

　＠IT自分戦略研究所の「リーダーシップは生まれつきの才能ではない」でも触れられていますが、筆者もリーダーシップは、天性が100％を決めているものではないと考えています。

　天性だとすると、性格によってある程度決まってしまう、ということになります。確かに、リーダー向きの性格はありでしょう。前向きで、辛抱強く、人と話すのが好きで……など、が一般的にいわれることでしょう。

　しかし、あなたの周りを見渡してもらえば分かるように、すべての（優秀な）リーダーがこのような人ではないでしょう。心配性で、飽きっぽく、独りを好み……、このような人でも、プロジェクトリーダーの役割をまっとうしていることが少なくありませんし、前向きな性格であれば、すべてのプロジェクトが成功するわけでもないでしょう。

　どのようなリーダーにせよ、プロジェクトを上手にコントロールできず、結果的に失敗することはあります。そして、この挫折を味わったときに「俺にはできっこなかった。やはりリーダーシップは天性だよ」と、常にあきらめてしまう人は、性格に関係なくリーダー失格です。

　そうではなく、「スキルと経験が足りなかった」と考え、いままでの自分の経験・スキルによるやり方（正）と、失敗したプロジェクト状況（反）との間に生じる矛盾と葛藤を課題としてとらえ、次の機会には、この課題を克服した新しい自分のやり方（合）として統合していけるかどうかを検討する。

　優秀なリーダーは、このように弁証法的な思考プロセスで成長していける人だと筆者は考えています。

図1 弁証法的な思考プロセス

リスクとチャレンジ

　デマルコが「熊とワルツを」で言及しているように、リスクが全くないプロジェクトをやる意義はありません。

　しかし、例えば会社や部署の性格上、常に同じようなプロジェクトを延々と任されるケースもあるでしょう。そのような場合に、「リスクがないのでやりません」とは、なかなかいえるものではないし、いうべきではないでしょう。

　せっかくプロジェクトリーダーという立場を任されたなら、自分の責任の範囲内で新たなチャレンジをリスクとして取り込むべきです。お客さまの要望として、「前と寸分たがわず同じ方式でやってほしい」と要求されない限り、必ずチャレンジするチャンスはあります。例えばプログラム言語を変更するなどといった、技術面での大きな変更は難しくても、「無駄な会議、ドキュメントを減らす」「見える化を推進する」などといった管理面での取り組みは可能でしょう。まったくリスク（＝やりがい）がないのであれば、リーダーの権限でそれらを作ってしまえばよいのです。

　今回で連載を終了します。筆者は別にそれほど経験があるわけでなく、まだ修行中の身でありながら、7回にもわたってさまざまなことを書いてきました。今回の連載を通じて、自分にとって大きなプラスになったのは、自分の無意識のやり方が、記事という形で「見える化」されたことにより、自分なりの課題が見えてきたことです。微力ではあっても、「初めてのプロジェクトリーダー」のお役に立てたのなら幸いです。