});前回「エンジニアのやる気は報酬だけじゃ維持できない、前々回「スキルシートでいったい何が分かるのか」は、プロジェクト内でうまく活躍できなかった担当者を例に取り、その原因を探りました。今回はプロジェクトでは活躍し、貢献したものの、プロジェクトを去らねばならなかった例を見てみましょう。その中から、これまでと同様、「プロジェクトと人」をうまく結び付ける要因を探ります。前回のWeb投票「プロジェクトへのモチベーションが一番高まるのは以下のうちどれを獲得したときといえますか?」の結果を確認してみます。ちなみに弊社もよく人材募集を行いますが、その人材募集のコンサルティングをお願いしている企業からもやはり、「SEの最も高い興味項目はダントツに報酬です」というのは聞かされていました。現在の報酬に対する「不満」の部分も大変多く出ているように思います。この報酬については前回大分掘り下げてしまったので、今回は1位となった「金銭的報酬」については、あえて外して述べていきたいと思います。平和なプロジェクト」です。実際、プロジェクトがデスマーチ状態に陥ると、参加しているプロジェクトメンバーは大きな精神的・身体的な負担を継続的に感じることになります。そのため、仕事と生活・健康をてんびんに掛けて、あるいは身の回りの順調なプロジェクトの様子を見ては「この仕事がこのまま続けられるか?」という悩みを持ち始めることもあるでしょう。平和なプロジェクト」と僅差だったのは意外でした。平和なプロジェクト」よりもこちらの方が上位になることを予想していました。多くの方が、プログラム実装力だけでなく、さまざまな技術のスキルアップの重要性を認識しています。そもそもスキルアップを重要と考える背景には、それが報酬や顧客満足度につながっていくことを前提と考えている方が多いようです。そのため、「スキルアップの票」は報酬(1位)、顧客の満足度(2位)の一部となったようです。チームメンバーからの評価」です。チームを強化し、一体感を高めて、より良いものを楽しく作る。そのためにはメンバーが互いに評価をしていることも重要です。顧客が見えない環境での開発に従事されている方にとっては、プロジェクトマネージャなどの「チームメンバー」が結果として顧客同然だったりします。後述の「顧客って何だっけ?」でも検討しますが、「チームメンバー=顧客」の場合もあることを忘れてはいけません。いった場合にはこの評価を求めるケースが多くなるとは思いますが、やはり報酬(1位)、顧客の評価(2位)を優先する方が多いようです。顧客からの評価」です。今回はこの「顧客の評価」について検討してみます。顧客って何だっけ?顧客というアクターの分析まず、この「顧客からの評価」について今回は分解して考えてみましょう。「顧客」という言葉は非常にあいまいです。プロジェクトにかかわる多数のステークホルダーによってその対象は真逆だったりするからです。金融機関を例に考えてみましょう。その金融事業を行う事業主体の企業の顧客。本当のエンドユーザーです。それに対して次に現れるのが、エンドユーザーとやりとりを行う、顧客折衝部門(例えば窓口従業者)です。その後ろには事業主体企業のシステム部門。プロジェクトにおいて、我々開発者からすると「エンドユーザー」といわれるのはこの事業主体企業のシステム部門を指す場合がほとんどです。アプリケーションにとっての「エンドユーザー」は前述の、「金融機関のお客」だったりするのが非常に難しい部分です。「ユーザー」と一言でくくられてしまうシステムのアクターはざっと数えただけでもこれだけに細分化されてしまいます。顧客分析そして金融基幹プロジェクトともなるとステアリングを行う企業としてのプロジェクトの「総元締め」のベンダがいます。あまりにも規模が大きいプロジェクトの場合はその「元締め」さえ、複数になり、それぞれに階層化していくでしょう。こんな分析を行うかというと、「顧客の評価」を皆さんが「大切だ」と認識しているわけですが、「顧客」という言葉をどこに置いているかで相当得るべきものが違うからです。顧客によって分かれる「利益」もちろん、プロジェクトのステークホルダー全員の満足度を得るのがプロジェクトの本来あるべき「顧客の満足」です。その「立場」によって優先する「顧客の利益」は変化します。あなたがもし、ベンダの中の一作業者であれば、作業工数と納期の満足により「元締め」のコストとリスクを低減させることは最高の「顧客の利益」です。ところが、あなたがその「元締めベンダ」の立場で会ったなら、「顧客」とは「事業主体そのもの」になります。その「システム部門」を満足させることが、「顧客の評価」を得ることになるでしょう。このように立場によって「顧客」というものを分けて考えねばならないかといえば、しばしば双方の利益が対立するからです。典型的な双方の利益が相反するシーンとしては、機能の充実を求める「事業主体のシステム部門」の担当者と、コストによりその「機能の充実」を飲めないベンダ側の利益です。それぞれの希望はなかなか相いれないあなたがその「ベンダ」の下でプロジェクトを遂行する立場だったとしましょう。機能追加を承諾して顧客満足度を上げることもできます。その分作業者に負荷が掛かり、その負荷がベンダに請求されるとき、それはべンダの不利益となってしまいます。このときに双方の利益は不幸なことに完全に相反してしまいます。皆さんに「顧客からの評価」と質問しておきながら非常に意地悪な内容ですが、「顧客」というのは一くくりにできません。多くの意味を複雑に絡み合わせたまま、皆さんは、「顧客の評価」と呼んでいると思います。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。