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

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

すごい技術者はすごいマネージャ？

技術の分からないダメマネージャよりはうまくやる？

　Gさんは30歳代前半の実装技術者として、まさしく経験豊富で優秀な人物です。フレームワークからアーキテクチャ、インフラからアプリケーション、要件からテスト・運用……。システムのすべてを経験し、それなりの造詣を持っています。会社でもエースの技術者として扱われてきました。そして、いままでの立ち位置は、いわゆる「技術頭」でした。何人か部下というより後輩を抱え、チームメンバーをプロジェクトごとに面倒を見てきました。いわゆるリーダークラスといえるでしょう。

　そんな彼に、いままでの部下を連れて、次のプロジェクトではマネージャになるよう指示があったのです。彼にも、いままで散々多くの技術の分からないダメマネージャを見てきて、自分ならうまくやれるという自負もありました。彼は快諾し、次のプロジェクトを待っていました。顧客との打ち合わせでも、要件を直接聞きながらその技術を自身で説明し、実装を判断してゆく姿は顧客からも頼もしく思われていました。「技術に相談しないと……」と、よくある持ち帰りにするということもなく、スムーズに話が進んでいきます。顧客の興味をそそるような新しい技術も織り交ぜながら説明していく姿に、顧客も安心してプロジェクトを任せました。

　今回のプロジェクトはWebのECシステムです。フレームワークにはStrutsを使用し、細かい入力支援などをAjaxで実装……、いずれも彼とそのチームが実績も自信もあるアーキテクチャです。メンバーは4人。気心が知れていて、しかも技術的なスキルも十分です。リーダーとメンバー同士は、信頼関係もできていました。

技術が分かる人がみると見積もりは安くなる？

　しかし、当初から若干の不安要素はありました。そもそも本プロジェクトがすんなり受注できた背景の1つに、見積もりを低く抑えることができたということがありました。受注のために営業的に費用を抑えたというより、当初の見積もりから競合他社より比較的抑え目でした。

　工数を見積もったのはGさん自身です。GさんはFP法を用いて基本的な算出を行ったのですが、出来上がった見積もりには納得ができません。どうも「高く」感じてしまいます。

　自分が作るイメージでこの機能は何人日、この機能は……という具合に、工数を再割り振りしていきます。彼の頭の中には、要件から設計実装がスムーズに再現されます。彼は経験から、見積もりは1つずつの機能に対して、全体的な画面フローから、画面数まで似たような事例を基に想像で描くことができます。

　その1つ1つに自分であれば画面に何日、DBに何日……細かい見積もりが立てられていきます。営業も、画面ごとに大まかな設計まで含んで正確に見積もられた資料とGさんの自信のほどに納得して話を進めたのです。

見積もりアンチパターン

パターン1

　ところがここには、非常に大きな「見積もりアンチパターン」が含まれていました。第1のポイントが、「彼がやったなら」という「見積もりアンチパターン」です。彼は自分の能力に自信はありますが、「他人など足元にも及ばない」と（自分のことを）思っているわけではありません。むしろ、口癖は「チームメンバーがなぜこの工数でできないかが分からない」です。

　それも嫌味でいっているわけではありません。真剣に疑問に思っています。ところがこの場合、Gさんは、非常に重要なポイントを見落としています。実装能力うんぬん以前に、一番要件と設計を理解しているのが「自身だ」という事実です。

　つまり、彼が実装する分には他人に伝えるための資料の作成や、説明の時間。中間成果物のレビューといった要素がごっそりと省略できます。そのため、彼の能力以上に彼が実装する場合には非常に少ない工数になってしまいます。そのために、頭の中で「自分なら」とシミュレートした工数が現実のコストと一致するのは非常に難しいことになってしまったのです。

見積もりアンチパターン その1

パターン2

　第2のポイントが、このときに数十に上る機能1つ1つが「最も効率よく作られたら」という前提で見積もりを積み上げてしまっていたのです。つまり、彼の見積もりには顧客の目的＝要件を最小限で実装するというフィルター（前提）が掛けられていました。

　よく「技術者」が設計をする際に陥る「見積もりアンチパターン」の1つに、この最も「効率的な機能設計」があります。何年もシステムにかかわっていると、顧客の要望がSEには一見「無駄にしか思えない」ことは実はよくあります。

　しかし、深く相手の要望を掘り下げて、顧客の業界の「プロ」の目から見るとそれは「必須」の要件だったりします。

見積もりアンチパターン その2

　「彼という優秀な技術者が最善のプランで作成した場合」の見積もりは非常に安く、また非常に精緻です。その精緻さゆえに、一見顧客と営業を納得させる妥当性もありました。

　まず、彼が最初にマネージャとなり、同時に全体の見積もりを依頼された際に最初に起こした間違いです。

プロジェクトスタート

　そして、彼をマネージャにプロジェクトが開始されました。Gさんの見積もりとWBSに沿って。Gさんは責任感が強く「頑張り屋」です。それにしても、なぜか、2カ月目にはほとんど終電の状況になります。そこでおよそ、前倒しになっているのであれば良いのですが、オンスケジュールを維持するのが精いっぱいです。

　メンバーもGさんとの付き合いも長いメンバーです。だんだんと同じように忙しくなっていきます。理由は、もとより「彼の思いに基づき」作られた「最善のプラン」です。

　仕様の打ち合わせをする中で、Gさんが当初「無駄」だと思った機能が次々と追加されていきます。細かいところで、チェックボックスを足したり。選択時に色を変えたり……。

　Gさんも、良かれと思って、このWBSと見積もりを作りました。技術者であった彼には常に「顧客のためにあれ」という気持ちがあったのが事実です。いや、そのこと自体は素晴らしいことです。もっと低い見積もりで、良いシステムを提供できる……、その思いから見積もりやWBSが作成されています。

　メンバーにも苦労を掛けようと思っていたわけではありません。「妥当」と彼なりには思っていました。繰り返し述べますが、メンバーのスキルは長い付き合いによる信頼関係に加えて、同じような事例の経験、アーキテクチャなどのスキルから、モチベーション・チームワークまで問題はまったくありません。