エンジニアにとっての本当の「顧客」は誰?!開発チームを作ろう(3)(1/2 ページ)

システム開発における「人」(=開発担当者)に視点を当て、普遍性を持ったプロジェクト運営プロセスを探り出す連載の第3回です

» 2006年12月22日 12時00分 公開
[佐藤大輔,オープントーン]

 前回「エンジニアのやる気は報酬だけじゃ維持できない、前々回「スキルシートでいったい何が分かるのか」は、プロジェクト内でうまく活躍できなかった担当者を例に取り、その原因を探りました。今回はプロジェクトでは活躍し、貢献したものの、プロジェクトを去らねばならなかった例を見てみましょう。その中から、これまでと同様、「プロジェクトと人」をうまく結び付ける要因を探ります。

 まずは、前回のWeb投票「プロジェクトへのモチベーションが一番高まるのは以下のうちどれを獲得したときといえますか?」の結果を確認してみます。

  1. 金銭的報酬 107人 35.2% 107人 35.2%
  2. 顧客からの評価 73人 24.01% 73人 24.01%
  3. チームメンバーからの評価 21人 6.91% 21人 6.91%
  4. 技術的冒険、技術的スキルアップ 49人 16.12% 49人 16.12%
  5. 平和なプロジェクト 54人 17.76% 54人 17.76%

開発者のモチベーションは金銭的報酬で高まるか?

 第1位は「1. 金銭的報酬」です。ちなみに弊社もよく人材募集を行いますが、その人材募集のコンサルティングをお願いしている企業からもやはり、「SEの最も高い興味項目はダントツに報酬です」というのは聞かされていました。また、現在の報酬に対する「不満」の部分も大変多く出ているように思います。しかし、この報酬については前回大分掘り下げてしまったので、今回は1位となった「金銭的報酬」については、あえて外して述べていきたいと思います。

 第3位は「5. 平和なプロジェクト」です。実際、プロジェクトがデスマーチ状態に陥ると、参加しているプロジェクトメンバーは大きな精神的・身体的な負担を継続的に感じることになります。そのため、仕事と生活・健康をてんびんに掛けて、あるいは身の回りの順調なプロジェクトの様子を見ては「この仕事がこのまま続けられるか?」という悩みを持ち始めることもあるでしょう。

 第4位は「4. 技術的冒険、技術的スキルアップ」ですが、第3位の「5. 平和なプロジェクト」と僅差だったのは意外でした。

 @ITという比較的ITスキルの高い方が見ている媒体ということもあり、個人的には「5. 平和なプロジェクト」よりもこちらの方が上位になることを予想していました。多くの方が、プログラム実装力だけでなく、さまざまな技術のスキルアップの重要性を認識しています。しかし、そもそもスキルアップを重要と考える背景には、それが報酬や顧客満足度につながっていくことを前提と考えている方が多いようです。そのため、「スキルアップの票」は報酬(1位)、顧客の満足度(2位)の一部となったようです。

 第5位は「3. チームメンバーからの評価」です。チームを強化し、一体感を高めて、より良いものを楽しく作る。そのためにはメンバーが互いに評価をしていることも重要です。

 また、顧客が見えない環境での開発に従事されている方にとっては、プロジェクトマネージャなどの「チームメンバー」が結果として顧客同然だったりします。なので、後述の「顧客って何だっけ?」でも検討しますが、「チームメンバー=顧客」の場合もあることを忘れてはいけません。そういった場合にはこの評価を求めるケースが多くなるとは思いますが、やはり報酬(1位)、顧客の評価(2位)を優先する方が多いようです。

ALT 図1 開発者のモチベーションは金銭的報酬で高まるか?

 さて、最後に第2位「2. 顧客からの評価」です。今回はこの「顧客の評価」について検討してみます。

顧客って何だっけ?

顧客というアクターの分析

 まず、この「顧客からの評価」について今回は分解して考えてみましょう。「顧客」という言葉は非常にあいまいです。プロジェクトにかかわる多数のステークホルダーによってその対象は真逆だったりするからです。

 金融機関を例に考えてみましょう。まずその金融事業を行う事業主体の企業の顧客。例えるならば預金者。つまり、本当のエンドユーザーです。

 それに対して次に現れるのが、エンドユーザーとやりとりを行う、顧客折衝部門(例えば窓口従業者)です。そしてその後ろには事業主体企業のシステム部門。

 プロジェクトにおいて、我々開発者からすると「エンドユーザー」といわれるのはこの事業主体企業のシステム部門を指す場合がほとんどです。しかし、アプリケーションにとっての「エンドユーザー」は前述の、「金融機関のお客」だったりするのが非常に難しい部分です。

 大抵「ユーザー」と一言でくくられてしまうシステムのアクターはざっと数えただけでもこれだけに細分化されてしまいます。

顧客分析

 そして金融基幹プロジェクトともなるとステアリングを行う企業としてのプロジェクトの「総元締め」のベンダがいます。さらには、あまりにも規模が大きいプロジェクトの場合はその「元締め」さえ、複数になり、それぞれに階層化していくでしょう。

 なぜ、こんな分析を行うかというと、「顧客の評価」を皆さんが「大切だ」と認識しているわけですが、「顧客」という言葉をどこに置いているかで相当得るべきものが違うからです。

顧客によって分かれる「利益」

 もちろん、プロジェクトのステークホルダー全員の満足度を得るのがプロジェクトの本来あるべき「顧客の満足」です。しかしながら、その「立場」によって優先する「顧客の利益」は変化します。あなたがもし、ベンダの中の一作業者であれば、作業工数と納期の満足により「元締め」のコストとリスクを低減させることは最高の「顧客の利益」です。

 ところが、あなたがその「元締めベンダ」の立場で会ったなら、「顧客」とは「事業主体そのもの」になります。例えばその「システム部門」を満足させることが、「顧客の評価」を得ることになるでしょう。

 なぜ、このように立場によって「顧客」というものを分けて考えねばならないかといえば、しばしば双方の利益が対立するからです。例えば典型的な双方の利益が相反するシーンとしては、機能の充実を求める「事業主体のシステム部門」の担当者と、コストによりその「機能の充実」を飲めないベンダ側の利益です。

ALT 図2 それぞれの希望はなかなか相いれない

 あなたがその「ベンダ」の下でプロジェクトを遂行する立場だったとしましょう。機能追加を承諾して顧客満足度を上げることもできます。しかし、その分作業者に負荷が掛かり、その負荷がベンダに請求されるとき、それはべンダの不利益となってしまいます。このときに双方の利益は不幸なことに完全に相反してしまいます。

 つまり、皆さんに「顧客からの評価」と質問しておきながら非常に意地悪な内容ですが、「顧客」というのは一くくりにできません。おそらく、多くの意味を複雑に絡み合わせたまま、皆さんは、「顧客の評価」と呼んでいると思います。

 ベンダから「すてきな下請け」としての評価も重要ですが、上記のステークホルダーをすべて満たす人が本当のSEと呼べるのではないでしょうか?

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ