開発者からリーダーへの視点の切り替え：初めてのプロジェクトリーダー（1）

[岡島幸男，永和システムマネジメント]

　ソフトウェア開発チームを構成するメンバーは大きく2つの種類に分かれます。開発者とリーダーです。開発者にさまざまなスキルが必要なように、リーダーにもさまざまなスキルが必要です。多様なスキルの中で最も習得が難しいとされているのは、開発者と違う視点を持つことです。もし、（教科書どおりにやっているはずなのに）いまあなたがリーダーとしていま一つだと感じているのであれば、開発メンバーから、リーダーへの視点の切り替えが上手に行われていない可能性があります。

　この連載を通じて私がお手伝いしたいのは、視点の切り替えです。切り替えというよりは、「もう1つの視点を持つ」といった方が適切かもしれません。メンバーとして、開発者としてプロジェクトチームに貢献してきたあなたが、リーダーとしてチームに貢献するために追加すべき視点を持つにはどうすればよいか？ 次の3つの切り口で説明していきたいと思います。

3つの切り口：「価値」「原則」「実践」

　切り口は3つ、「価値」「原則」「実践」です。これらは、「価値」を最上段に置くピラミッド型に階層化され、上位のレイヤにいくほど、より普遍的、抽象的になります。もちろん、下位のレイヤはより上位のレイヤに基づきます。まず、価値とは、リーダーとして守るべき、大切にすべき心構えだと考えてください。次に原則とは、価値に基づいて信じるべき題目です。最後に実践とは、価値、原則に従って実行される具体的な行動です。

　連載初回に当たる今回は、まず、「価値」と「原則」を明らかにし、それ以降の回で、「実践」について具体的に説明していきたいと考えています。

想定するプロジェクト

　読者の皆さんに、より具体的なイメージを持っていただくために、以下のような仮想プロジェクトを想定します。以後の連載は、この仮想プロジェクト内部での出来事とし、プロジェクトリーダーを「あなた」と呼びます。

［規模］

　リーダー経験がないのに、それほど大きなチームのリーダーを任されることはないだろうということで、メンバー4名＋あなたの5名程度の小規模チームを想定します。メンバーのスキルとしては、ベテラン1名＋中堅2名＋新人1名とします。

［プロジェクトの種類］

　業種までは特定しませんが、Webアプリケーションソフトウェアの受託開発を想定します。システム構成や、開発に使用するアプリケーションサーバ製品などは、ある程度決まっていることとします。

［お客さまとの関係］

　リーダーが一番関心を払うべき人間として、1次請けの場合はエンドユーザーを、2次請け以降の場合は、発注元であるベンダーの担当者を想定します。

［プロジェクトマネージャ］

　プロジェクトマネージャも重要なリーダーですが、ここでは対象としません。必要とされるスキルが違うからです。むしろ、あなたが関心を払うべき対象として考えます。

価値

　それでは、まず「価値」について説明をしていきましょう。私は、リーダーが守るべき価値は3つあると考えています。それは、「チームプレイ」「顧客満足志向」「中庸であること」です。どれも当たり前に感じられるでしょうが、実に簡単にこれらの価値はないがしろにされてしまいます。それは、いずれもデスマーチプロジェクトからは消え去ってしまうことから実感できるでしょう。人間きつくなると、本能的に自分防御モードに入りますから、チームとしての価値は二の次になってしまうのです。だからこそ、リーダーとしてはこれらの価値を守る必要がありますし、逆にいえば、メンバーもこれらの価値を守れる状態を保てるよう、さまざまな手を尽くす必要があるのです。

チームプレイ

　リーダーは、まずチームの力を最大限に引き出すことに価値を見いだすべきです。というよりは、チームの力を引き出さない限り、達成できない仕事があるということを十分に認識する必要があります。特に優秀な開発者がリーダーを任された場合、意識の奥底には「最後には、自分がなんとかしよう（できる）」という思いがあるはずです。しかし、それではどうにもならない状況があり、その思い込みが、かえって油断を生み、最終的な状況を悪化させることもあります。常に、チームで勝負している感覚を忘れないようにしましょう。

顧客満足志向

　顧客満足、つまり顧客の「うれしさ」に敏感になりましょう。もちろん、「お客さまは神さまです」という意味では決してないので注意してください。そして（さらに重要なことには）、顧客が大してうれしくないことをして、無駄働きをしないという意味も含んでいます。

中庸であること

　極端な思考、志向、し好に偏らないことです。これは、日和見主義を意味することではありません。状況に応じて良いと思われることを大胆に取り入れる勇気や、状況に応じた良しあしを判断するロジカルさ、そして幅広い選択肢を持っていること、つまり引き出しの多さが必要となります。

原則

　次に原則です。何か意思決定をする場合に、まずは、これらの原則を切り口にして考えをまとめ、判断し、行動に移します。ただし、教条主義に陥らないようにしてください。プロジェクトの性質によっては、これらの原則を無理に適用することで、3つの価値（のどれか）が失われる場合があるかもしれません。

シンプルイズベスト

　何か選択に迷った場合は、よりシンプルで、より理解しやすい方を選びましょう。ソフトウェアは本質的に複雑であるうえに、複雑な方が、高等・高級に見えがちですが、それが顧客満足につながることはほとんどありません。シンプル化の対象は、アルゴリズム、設計、アーキテクチャ、プロセスなどさまざまですが、影響を受ける関係者が多い事項に関して特に効果的です。「シンプルでない」、具体例を挙げてみましょう。

• 特に要求されていないのに、EJBを使ったアーキテクチャになっている
• 先を見越し過ぎた設計をして、テストパターンが膨大になる
• デザインパターンを過剰に使った設計のため、新人の開発メンバーが理解できず、実装が進まない

管理というよりは演出

　チームメンバーの力を引き出すためには、管理というよりは、演出してあげる心持ちの方がうまくいきます。これは特に、経験豊富なメンバーが多いチームで有効です。ただし、新入社員など極めて経験が浅いメンバーの場合には、「管理されている」という安心感を演出することも大事ですし、チームにたるんだ雰囲気が出始めている場合は、あえて緊迫感を演出することも必要です。具体例を挙げてみましょう。

• メンバーに行動を指示する場合に、「してください。」と、命令するのではなく、「してみてはどうですか？」と、提案し、自発的な行動を促す
• プロジェクトと関係がない技術的な話題にも積極的に参加し、メンバーと議論する。関係がないと思っていても、意外とプロジェクトに役立つヒントが得られますし、メンバーの性格もつかめます
• 成果を上げたメンバーを褒める。「お客さんも喜ぶぞ」と、一緒に喜ぶ

チームは一期一会

　チームは、人間の相互作用の場であり、取り換え可能な部品の集合ではありません。プロジェクトの特性に応じた開発プロセスの定義や、メンバーに応じた役割分担、目標の設定が重要です。開発プロセスや役割はメンバーにあらかじめ説明し、途中で変える場合には、その都度正しく説明する必要があります。

目的、課題、アクション

　リーダーは、いわれたことだけやっているのでは務まりません。リーダーが混乱し、何をすべきか分からなくなってしまうと、チームはやがて混とん状態に陥ります。混とん状態のプロジェクトを前進させるためのキーワードは、目的、課題、アクションです。以下の切り口で自問自答することで、状況を整理します。会議の議事録も、この3つの軸に沿って書くと読みやすくなり、議事録としての効果が上がります。

• 何のためのプロジェクトで、どんな価値を生み出そうとしていたのか？（目的）
• そのためには、何が課題となっているのか？（課題）
• その課題を解決するために、あなたのチームがいまできることは？（アクション）

伝家の宝刀はひっそりと抜く

　技術者として、「おいしい」部分は、ほかのメンバーに譲らなくてはいけません。リーダーはプログラミングをしないということが前提ですが、万が一現場の手が足りなくなった場合は、比較的リスクの低い（時間さえあれば誰でもできそうな）個所を選び、ひっそりとやり遂げましょう。リスクの高い部分をリーダーが抱え込む英雄的行動は、ほとんどの場合事態を悪化させます。問題は、チームとプロセスの力で解決するのがベターです。「伝家の宝刀」を派手に抜いてしまった場合のリスクとして、以下のようなことが考えられます。

• リーダーが作業に没頭することで、視野が狭くなり、チーム全体の問題に対処する余裕が失われる
• （自分の力を否定されたと感じた）ベテランメンバーのモチベーションが下がってしまう
• 細かい部分ばかりが気になりだして、全体的な修正を命じた結果、バグを混入させ、結果的に納期に間に合わない

持ちつ持たれつ

　お客さまやメンバーとは持ちつ持たれつの関係であることを心得て、それをメンバーにも伝えましょう。それぞれの立場の責任を明確にしたうえで、関係者間の「関心チェーン」を上手につなぐことができればプロジェクトの目的達成に向けて、チームの一体感を強くすることができます。

---

　次回以降は、ここまで説明した、価値＋原則から導かれる実践を、プロジェクトのライフサイクルに合わせて説明していきたいと思います。まずは、プロジェクト計画とチームビルディングです。