メディア

エンジニアにとっての本当の「顧客」は誰？！：開発チームを作ろう（3）（2/2 ページ）

» 2006年12月22日 12時00分公開

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

プロジェクト内での「出世」

最初は協力会社の一実装者

　さて、ここで、Fさんの事例に的を当てて見ましょう。ある金融の基幹プロジェクトを例に取ります。

　Fさんは30代。必要な経験を持ち、一番無理が利く年齢です。当初多くのプロジェクトにあるように、Javaのプロジェクトの「火消し増員」の1人として呼ばれました。立場はベンダの協力会社の一員としてです。期待されていたスキルは、Javaの実装力ならびにUMLによるシーケンス図の記述です。いわゆる実装部隊の増員の一員でした。

　しかし、私が常に思うのは、「JavaのプロジェクトだからJavaの技術者を増員する」というのは、非常に危険な考え方です。

　その前提にあるのは、プロジェクトのサイクルは正しく回り、要件は設計に落とされ、それが実装に回され、その実装の結果がフィードバックされる……。そのプロジェクトサイクルが正しく回っている中でさらに、要件がきちんと管理されている。そのサイクルによって「転がって」いくべき方向がはっきりとしているときには実装者を増員することは、プロジェクトの速度を速めるでしょう。

　しかし、逆にその「転がっていない」、あるいは「どこに転がっているか分からない」状況での実装者の増員は、「空回りの速さ」を上げるだけだったり、あるいは別の方向に進む速度を上げるだけになります。

　そして、私が見る多くの「火事の現場」にはおよそ、実装者の頭数以前の問題が多く存在しています。

　しかし、このFさんも今回はまずは実装者として呼ばれていました。Fさんは早い段階でプロジェクトの問題点が実装者の頭数ではないことに気付きました。途中から参加した協力会社のメンバーがプロジェクトに参加して早々「プロジェクトの取り回し」がおかしい、といっても説得力もないですし、そもそも聞いてももらえないでしょう。

　大体「実装者」である、彼が出ることのできる打ち合わせは、自分のチーム内会議のみです。顧客とは話す機会もなく、プロジェクト自体をどうこういえる立場では無論ありません。

作業を自分で探す／集める／実行する

　こういった場合に、多くの経験豊かなSEの取る手法は「プロジェクト内での出世」です。Fさんはこの方法を有効に活用しました。

　最初は、実装をするうえで、設計や設計の要件の落とし込みにおかしな部分があることを徐々に……それも1カ月もかけて少しずつ指摘していきます。焦って、これがダメ・あれがダメと指摘してはいけません。現在のプロジェクトのステアリングコミッターたちの反発を招かず「役に立つアドバイスをするメンバー」となっていくことが重要です。

　また、要件の管理などに問題がある場合もいきなり「管理」を提案したり行うのではなく、まず要件を持っている人の「細かい作業」をしてあげるようにします。プロジェクト内での地位を上げるコツの1つは、プロジェクトを観察し、問題点を割り出し、その問題点のためになすべき仕事を自主的に探していくことです。

　そして、少しずつ現在の担当者の仕事をもらっていくことです。そのためには「面倒な細かい作業」などを受け取ってサポートしていくうちにだんだんと「把握しているのはFさん」となることが重要です。

　そうやっていくうちに、要件・バグ・リソースなどの管理作業がいつの間にかFさんに集まっていきました。よく、企業の事務組織などで「実権」が現場の作業担当者にある場合が笑い話のようにいわれますが、プロジェクトの中でも同じことが起こります。

　指示決断をプロジェクトマネージャがするわけですが、地道にExcelなどで管理して、調整をしている担当者の「提案」の下に決断を行っているのです。

図3 キーパーソンとなったFさん

　さて、いつの間にか、チームリーダーはFさんに問題点や、状況を報告します。Fさんは協力会社ですから、本来決定権はありません。しかし、その状況を正しく理解して正しく調整できる唯一の人物になってしまっています。本来その役割を担う人は把握をしていないので、どうしてもFさんに聞いて、Fさんの回答に基づいて決断を行います。

プロジェクトキーパーソン

プロジェクトキーパーソンになったFさん

　事実上のプロジェクトマネージャがFさんに移った瞬間です。こういった人をプロジェクトのキーパーソンと呼びます。着実に一歩ずつプロジェクト内での地位を上げていきます。ただし、ここで重大な注意点があります。最初から最後まで、Fさんの「人月単価」は協力会社の実装者のままです。

　つまり、彼は純粋にプロジェクトの遂行を願い「活躍」をしています。結果、その端々に出る「プロジェクトの利益を最優先するフンイキ」があらゆる関係者に素直に彼の意見を聞かせる理由になっていったのでしょう。最終的には、請けているベンダの立場として、顧客折衝部門との打ち合わせを任されるまでになりました。

　しかし、大抵この瞬間にはキーパーソンは残念ながら「顧客の評価」の調整に苦慮することになります。顧客の希望とベンダの希望。チームメンバーの利益は究極的には別の方向を向いています。極論をいえば、顧客は機能がより充実すればうれしくて、ベンダは、それが予算に収まることを希望します。

利益のデッドロック

　具体的な問題は連休前に起こりました。連休のリリースに向けて、チームメンバーにタスクを依頼して追い込みを一丸となって行います。彼の口癖は「いま頑張れば連休があるぞ」です。

　そして、チームは見事に、連休前にそのタスクを完了させたのです。しかし、顧客のシステム部門は「連休前にタスクが終わったのであれば、連休を投資すればさらに機能が積める」と考えました。

　ここで、エンドユーザーという顧客を優先すれば、受けて、チームメンバーに謝るという選択肢があります。ところが利益が相反するのが、ベンダはその分の作業費をSEに払わなくてはなりません。

　ここで、Fさんは奇妙なデッドロックに入りました。エンドユーザーのいうとおりにすれば、チームのモチベーションとベンダの利益を損ないます。ベンダの利益を優先すれば、顧客の不満は高まります。そもそも、システム開発は土日返上でデスマーチで……という顧客文化にも問題がありますが。

　Fさんはここで、「エンドユーザー」の要求を飲まない方向にするためにある程度強行に出ることにしました。ベンダという顧客とチームメンバーの利益を優先したのです。

Fさん、デッドロックの状況に追い込まれる

　このときすでに、ベンダは、完全にFさん任せになっていたので、Fさんが討論の「矢面」に立つことになってしまいました。最終的に交渉は成功しましたが、エンドユーザーは、ほかのベンダが連休返上で対応しているのを見て彼の意見を疎ましく思ってしまいました。

　ちょうど、顧客、ベンダ、協力会社にまたがって大問題となっていたプロジェクト自体は、全体としては落ち着き、無事に着陸し運用し始めました。そのときに「初期開発メンバーを大幅に減らす」際に、残念ながら「1協力会社にもかかわらずFさんは顧客の要望に強く反発した」という問題でプロジェクトを去らねばならなくなってしまいました。

図4 システム開発を巡る利害関係者

　「顧客の評価」の難しさが浮き上がるプロジェクトになりました。もちろん「ベンダにとってコストを抑えた」という意味での顧客満足度は高まりました。しかし、機能の改善を了承しなかったという顧客満足度は下がってしまったのです。

　皆さんもぜひ一度「自分の顧客」が何者で、その顧客がどういう立場であるかを再認識してみてください。ただ、私はプロジェクトを軟着陸させるために奔走する「火消し」を個人的には非常に頼もしく思います。しかし、同時にその奔走が「誰の利益になっているか？」を次の段階として考えてみてください。

　徹夜で頑張った作業票を提出されるベンダのプロジェクトマネージャは予算超過で社内での立場が厳しくなっているかもしれません。やはり、お互いにビジネスで行っている以上「お客さまの笑顔がすべて」とはいい切れない世界なのです。

Webアンケート実施中！！

◆ ITプロジェクトの運営・遂行の上で非常に需要だと思われる要素は？

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

前のページへ 1|2 　　　　　　