すごい技術者はすごいマネージャになれるか？：開発チームを作ろう（4）（3/3 ページ）

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

なぜかきつくなっていくWBS

　さらに「顧客のためにあれ」という思いは「顧客のお願い」もなるべくのむ方向でコストを圧迫します。顧客の要望をなるべく取り込んであげたいという思いから、「ちょっと僕が徹夜をすれば済む」「Aさんにお願いして後で代休で」という発想で顧客の要望をのみ続けていきます。

　彼も実装をしながら、いままでのプロジェクトで「これ以上要求を追加・改変されたら対応しきれない」といってきた身でした。しかし、自身が実際に顧客の前に立ち、「あなたにこのシステムを任せた」という言葉を顧客の口から聞かされることで、彼は「このシステムの顧客の喜びが最大プライオリティだ」という思いにのまれてしまいます。

　前述の開発側の視点から見た「もっとも効率よく作ったら」という見積もりです。顧客の要望を深く掘り下げるうちに機能は追加され、さらに、其の機能追加の結果「他の機能も同じように修正しなければいけない」という形で、どんどん、作業は膨らんでいきます。

　Gさんの行動基準は「とにかく良いアプリケーションを提供する。顧客のためを願う」です。その結果、顧客の不満や指示の発生時に「どうやってのみ込むか」を基準に行動してしまいます。ある修正が要求されると、自身や実装者の中でやはり「最善の工数」で見積もってしまいます。

　実際にはそのままの工数で終わらずに、よりメンバーへの負担も高まります。繰り返しになりますが、メンバーのスキルはむしろ「高い」状況です。

モチベーションもスキルも高いのに……

　さて、メンバーもかなり厳しい状況での作業が多くなります。それでも、技術的に尊敬できるリーダーであり、自身が一番多く問題を解決しているリーダーには皆、文句をいうでもなく手伝ってゆきます。

　このとき彼は本来の役目のマネージャではなくリーダーから抜け切れていないことが分かります。マネージャはQCDのバランスを常に計算し続けなければなりません。その任務はアプリケーションの完成とチームの維持ではなく、プロジェクト全体の成功……、顧客は無論チーム、自身の開発組織……、すべてのステークホルダーに対するメリットにほかなりません。

　例えば、QCDのバランスを大きく崩すような要求に対しては、「落としどころ」を探るのが任務となります。「こうすればできるかも」から発想を始めてはいけません。「なぜこの要求が発生したのか」から始めるのがマネージャの発想になります。

　その発想は、実装で解決しない方法……、業務の対応や、ほかの機能での代用。そもそものビジネスプランの再検討。などさまざまな「落としどころ」を生み出すもとになります。

　仮に実装で対処する場合でも全体のスケジュールへのインパクト。増大した機能の長期的な視点でのコストなど、幅広く検討せねばなりません。

　しかし、彼のプロジェクトは、メンバーの疲労が目立ち、利益も出しにくい構造になっています。顧客は、徹夜をしながらコストを積まずに機能を充実させていくGさんを彼の上司を捕まえては褒めていきます。

　ますます、彼は心血を注いでプロジェクトに対応していきます。メンバーも彼を慕い、全力を尽くします。チームの結束も固く決して状況の厳しさほどにメンバーはストレスを感じていませんでした。

PJは完遂、お客も満足。しかし……

　問題はGさんにとって意外なところから発生しました。顧客もメンバーも満足です。しかし、唯一満たされないステークホルダーがあります。

　多くの経営者は、「エンジニア」と「ビジネスマン」の距離の遠さに悩んでいます。特にマネジメント層になると、後者の要素は非常に強いものになります。それは、いわゆる「営業部」と「技術部」の対立という意味ではありません。プロジェクトのマネジメントを行う者には所属する部署うんぬん以前に「ビジネス」の感覚が必要だという事実です。

　最終的には無事納品にこぎつけました。少なくとも顧客は大満足です。「苦労した」という事実も、顧客の感謝ともにメンバーの思い出に変わります。

　しかし、工数が増え、皆が残業などでカバーしたぶんにより、「最善の見積もり」に付け加えられた、営業的なバッファも使い果たしてしまいました。結果、開発組織つまり「会社」はこのチームを「儲からない部署」として再編を始めてしまったのです。

　ここで疑問は、「顧客はそれだけ満足し、チームも満足しているなら、いずれかあるいは両方から援護されるのでは？」ということでしょう。

　ITプロジェクトは多くの場合、顧客にとって「お買い物」の1つに過ぎません。「よいお買い物」ができたことについて、顧客の信頼や評価は上がりますが、逆にいえば、それ以上ではありません。長い目で取引先を育てるという視点で支援をしてくれるケースはまれなのです。

　そうすると、特にビジネスとしてはその開発自体、利益が出なければ「商い」は成立しないことになります。Gさんの技量は評価し、報いたいとは思います。しかし、顧客の満足度は少なくとも前のプロジェクトの低コスト、高機能なソフトウェアの提供で達成されてしまっています。行われる追加発注も、いままでの「低コスト」を前提に進められます。

　顧客の担当者もチームメンバーも彼と彼のチームを評価しますが結局のところ、部署として企業として「手仕舞い」を迫られることになります。

マネージャに求められるものは3つある……

　今回のケースでは結局彼は、自身もチームメンバーも守ることはできませんでした。部署は再編され、チームは解散させられてしまいました。「メンバーのスキルが非常に高いにもかかわらず」です。

Webアンケート実施中！！

◆ 見積もりパターン・アンチパターン

「開発チームを作ろう」バックナンバー

• スキルシートと単金だけで開発チームは作れない
• 良い顧客が良いITプロジェクトを作る
• すごい技術者はすごいマネージャになれるか？
• エンジニアにとっての本当の「顧客」は誰？！
• エンジニアのやる気は報酬だけじゃ維持できない
• スキルシートでいったい何が分かるのか