スキルシートと単金だけで開発チームは作れない：開発チームを作ろう（6）（2/3 ページ）

[佐藤大輔，オープントーン]

ファクター1：生産性（Case1、2）

　Case1のEさんの場合は純粋に生産性に問題があります。ただし、Eさんが他のプロジェクトでの生産性まで悪かったのかは分かりません。はっきりいえることは、今回のプロジェクトで与えられたロールに対する生産性が悪かったといえることだけです。

この回のお題では、スキルシートだけで技術者の質を測る難しさを書いています。つまり、スキルシートがいかに多くの項目で埋められていても、その生産性はどこにも記載されないということです。Case2のNさんの場合もそうです。スキルシート上のミスマッチはなく、技術的にも特段問題があったわけではありません。しかし、ほかの人と比較して「生産性は悪い」ということになってしまいます。結果として、彼の「成果物」という観点で見たときには「非常に生産性が悪い」ということになってしまいます。

　うまくいかなかった2つのケースを挙げていますが、やはりマネージャとしての視点からもメンバーとしての視点からも、「生産性が悪い」というのは致命的な事態になります。

　プロジェクトマネージャは、往々にしてこういう生産性が悪い人に対して「ロールを変える」「周囲がサポート」（教えるなど）、「切る」（交代を含む）というカードを選択することができます。

　ただし、しばしばそこには「制約」も発生します。典型的なのは、「生産性の良いAさんと生産性の悪いBさんはセットなので」とか、会社が「教育を前提に入れているので」というケースです。その場合には、「周囲がサポート」という選択肢しか残されていない場合もあるのです。

　この「周囲がサポート」という一番容易な選択肢こそ一番のくせものです。マネージャがこの選択肢を取る場合、あるいは上司に当たる者がその選択肢を望む場合、すでに無事完遂するのが、大変なプロジェクトになってしまっているのです。　

　すでに、5人で1人を支える時点で、マネージャとしてメンバーに120％の作業を乗せてしまったことになるのです。例えば、プロジェクトの見積もり時点のバッファが20％だとすると、何もしない前から「ギリギリうまくいくかどうか」というプロジェクトになってしまっています。ですので、この選択肢はもっとも安易で、かつもっとも危険な選択肢であることを覚えておきましょう。

　つまり、「生産性が悪いメンバーがいる」ということは、非常に大きなリスクであり、プロジェクトと人のアンチパターンの典型だといえます。特に、スキルミスマッチの生産性の低さに関していえば、なかなか短期間での改善を行うことは困難な場合が多いようです。

　基本は今までの経験や、社内での教育によってスキルそのものを高めておくことです。普段から意識して新しい技術や手法を試していることなどによって、高い生産性が生まれてくるからです。

　しばしば努力によって「乗り切る」ケースもあります。例えば、スキルミスマッチが起きた際（例：初めての技術に当たった）に、業務をむしろ早く切り上げて書店に行き、知人や社内に聞き回り、情報収集をして非常に短期間で身に付ける「センスのある技術者」もいます。そうなれる人が多いとはいいませんが、少なくともそういった努力を払うことでスキルミスマッチという自体を乗り切るケースもあります。

　もう1つこの生産性パターンの「派生パターン」として、「価格が見合わない」パターンがあります。これもCase1、2の中にも含まれていますが、顧客の支払う「SE単価」に生産性・成果が見合っていないというパターンです。このパターンの最大要因は「業界の構造」があります。すなわち、しばしば「階層構造」で受注するために階層の「中間手数料」が膨らんでしまい、実際に本人が受け取る「評価としての金額」を大きく上回っていることがあります。その結果、「顧客の期待する金額への見合い」は、本人あるいはその会社が実際に受け取っている金額とは大きく懸け離れてしまうケースがあります。顧客は「こんなに払っているのに」、SEは「これしか貰っていないのに」というミスマッチです。これも「生産性が悪い」という形で発現することがあります。

ファクター2：必要性（Case2、3）

　生産性が低くて不要になるCase1の場合を除いて、生産性とは無関係にその人が必要にあるいは不要になるケースがあります。Case2のNさんとCase3のFさんはそういう意味では真逆の結果になりました。Fさんは不具合管理のような細かい仕事を1つ1つこなすことで技術力や生産性とは全く別の次元で、プロジェクトのキーマンになっていきました。

　逆に、Nさんは技術力や生産性とは別の次元で、「顧客の無理な要望には答えない＝顧客から見ると仕事をしない」ようにとらえられてしまい、結果として、彼の分担機能はどんどん減っていき、最後にはほとんど担当機能もなくなり、「不要である」と見なされてしまいました。

　ここで1つ注意しておかねばならないのは、プロジェクト内での「必要性」というこのファクターは生産性や技術力とは必ずしも関係がないことです。単純にそのメンバーが「プロジェクトに必要であったか否か」です。逆にいえば、メンバーとして必ずしも技術力や生産性だけが必要なのではなく、プロジェクトに貢献をし、評価を得られれば「必要な人」になれることになります。相対的に技術力があっても生産性がよくても「プロジェクトに必要」でなければ生き残ることができなくなってしまいます。

ファクター3：調整力（Case3、4）

　Case3のFさんと4のGさんは、いずれも自分のステークホルダーの一部を満たせなかったがゆえにプロジェクトを続けられなかった事例です。FさんもGさんも実は「エンドユーザー」の評価は二重丸（◎）です。つまり、顧客に貢献していいアプリケーションを作成し、システムを稼働させました。しかし、2人とも多岐にわたるステークホルダーの一部の評価を満たすことに失敗しました。

　一般に顧客という言葉でくくられるステークホルダーは、技術者から見るとたくさんいます。まず身近にいるマネージャ。マネージャから評価されなければいけないという意味では「顧客」です。

　会社組織、自身の所属する会社組織があります。さらには、マネージャと同じようにチームメンバーも自分を評価します。そしてベンダ。場合にもよりますが、取りまとめのベンダがいるような仕事では必然的に「元請けの評価」も重要な要素です。

　そして、いわゆるエンドユーザー。事業主体者ですね。

　そのほかに、システムの利用者がいます。ECシステムの場合なら購買者がそれに当たります。ITプロジェクトに参画・あるいは運営する際には自分が注意しなければならないステークホルダーを見極めなければなりません。

　顧客に喜ばれても、チームや利用者から非常に強い不満を受けるようではうまくいきません。

　Fさんは元請けベンダの満足度を非常に高めましたが、事業主体者の満足度を下げてしまいました。Gさんは事業主体者の満足度を高めましたが、自身の会社組織の満足度を下げてしまいました。

利害の調整はとても大変

ファクター4：技術力（Case1、4、5）

　「技術者」というくらいで、技術力は非常に重要な要素です。しかし、ITプロジェクトを完遂させるということと、技術は必ずしもイコールではありません。業務的ビジネス的な事柄になれば、なおさらです。

　Case1のEさんは残念ながら技術力が不足していました。このことは単純にEさんの生産性を押し下げ、彼がプロジェクトにいられなくなる要因となりました。

　Case4のGさんの場合は技術力はあったので顧客の信頼、メンバーの信頼の獲得には非常に効果を発揮しました。しかし、見積もりが作業時間・コスト共に「自分基準」であったため、コミュニケーションロスを見落として非常に厳しいWBSになってしまいました。結果として、彼もまた自身の会社組織の利益を確保できず、退場せざるを得なくなっています。

　顧客に技術力がある場合もあります。

　実装作業をするのはベンダですが、顧客に技術力があるとITガバナンスを維持できます。ITプロジェクトに限らず、物事において「ジャッジ」できることは非常に重要なことです。顧客層に技術力があると、ベンダやチーム、メンバーの提案を「ジャッジ」することができます。あるいは「プロジェクトに対する貢献度」を見極めることができます。

　開発組織において、どこが筋肉でどこが脂肪なのか。それを判定するにも技術力なりで見ると容易に判定ができるようになります。出された見積もりの妥当性の判定や、障害時のベンダの説明を聞き、正しく問題を把握できます。要は「仕切る」ことができるようになります。

　ベンダより優れた技術力が必要なわけでもありません。ただ、「いいようにされない」程度の技術力を持ち合わせていることは非常に良い効果を生みます。

ファクター5：責任感（Case2、4、5）

　「プロ」「仕事」そのいずれにも責任感を連想させるものです。しかし、その質や量は人によってもプロジェクトによってもさまざまです。

　例えば、Case2のNさんは上流工程のメンバーの遅れに対して自身は開発メンバーであるためにフォローを拒否しました。それ自体は間違ったことではありませんが、彼を「人より責任感が強い」というメンバーはいませんでした。

　おそらく責任感が強い人であれば、自分で「ここまでは私の責任」と線を引くのではなく「自分の（かかわった）プロジェクトを成功させる」という視点で行動したでしょう。つまり、上流工程のスケジュールが遅れていれば上流工程を手伝ったり、あるいは、（スケジュールの遅れを）取り戻すために他人の責任分担範囲のフォローという意味で頑張ったかもしれません。

　彼は問題ある行動をしたわけではありませんが、自身の責任はここまでと定めてしまいました。その「範囲」について、ほかの開発メンバーやマネージャが納得しているとは言えませんでした。

　逆にCase5のHさんは、もともと一実装部隊員だったにもかかわらず、フレームワーク部分にまで自分から首を突っ込んでいます。幸い、そういう行為を正しくジャッジできる顧客であったため、彼はそれを高く評価され良い結果を残せました。

　Case4のFさんは非常に責任感も強く、そのため親身・真剣に顧客の要望を聞き、取り入れていきます。しかし、その取り入れた結果が「調整力」の不足によって、チームへの負担と自社の利益の喪失という不幸な結果へとはまっていきます。