システムエンジニアが評価されていない場合の対策の実例

タイトルが気になったバーバードビジネスレビューをパラパラと見ていて最初は記事にある自主管理組織の事例に挙げられているザッポスなどの組織内での役割が平均7.4は自社サービス（B2C）とか自社内での活動がベースでSIerのようなプロジェクト専任がアサインのベースだと全面的には適用できない（部分的にはできる）と思っていたんだけれど、その先のページでCLOUを作るときに他の社員と一緒に行う、というのを読んでちょっと思い出したことを書こうと思う。

あるメンバがいて、どうもある偉い人の誰かから良い印象を持ってもらっていないという情報をぼかされて聞いたのですね。立場上、とても気になるわけで、あたりをつけて見たけれど、どうも今ひとつ当たらない。

仕事自体は期待どおりだったし、評価自体もそれなりだった（でも飛び抜けているわけではない）ので、半ば棚に上げていたのです。それほど支障が目に見えてあるわけでもないから。

ただ、評価の時期になるとその話が蒸し返されるので認識せざるを得ないけれど、なにせ例の人がわからないし、たとえ分かったとしてもどう手を打ってあげれば印象が上書きできるかがさっぱりわからない状態で。

あるタイミングでメンバにアサインされているプロジェクトの報告と見通しのような報告をアドホックにさせて組織として前向きなリクエストをさせようと思いつき、それ向けの資料を準備してもらい、報告とリスクエストのプレゼンをさせてみたんですね。

結論から言えば、その場に呼んだ幾人かの偉い人の中に探していた人が含まれていたようで、関係性から消去法で特定ができたのでした。

それはどちらかと言えばおまけの方で、良い印象を持たれていなかったメンバの印象がその報告で良い印象に上書きされたんですね。

ワタシの印象は以前と変わっていないくて、いつもどおりに話していたので（だから安心して聞いて入られたし、フォローもほとんどしなかった）ことが次の疑問になったのでした。

「さて、どうして以前は良い印象を持たれなかったのだろう」と。ただ、逆に過去のことを想像して労力を使うより、何が印象を上書きする要因になったのかな、と考えることにしたのですね。

思いついたのことは特別に難しいこととか、奇異なことでもなくて、対面で報告させたことが要因ではないかと。

そりゃそうですよね、どこかでよくない印象を得るにしても、それは直接的に感じたからでしょう。書面のようなレポートでは、そこまで強い印象は相当悪いレポートでなければ影響を与えられないでしょうし、そんなレポートは途中で修正することになるでしょうから。

このことから得られる解は、システムエンジニアであればこそ、それも会う機会が早々にないシステムエンジニアは機会をみるか、そういう場を設けられるように上司と画策してプレゼンをする、でしょう。

そこで、よくやりがちなことはシステムエンジニアの目線で自分のやっているプロジェクトの技術を延々と仔細までを書き連ねるような資料を作ることはNGで、話す相手に何をリクエストするかを明確にした資料を作るようにすることが観点として必要です。

例えば、プロジェクトが拡大する見通しがあって（確証は別にして）要員リクエストをしたい場合、どう見せればマネジメントを動かせるかを考えて資料構成することがポイントになります。別の言い方をすれば、マネジメントを動かして人を他から移してでもやることにビジネス的に価値（＝リターン）があることを単純に示そうということです。

システムエンジニアだからこういったマネジメントへの働きかけは必要ないと思っていたら、それは間違いです。なぜなら、システムエンジニアも役割が上になればなるほど、顧客のマネジメント層に対し、担当するプロジェクトの様々なレポートや説明の機会が増えるからです。そうした場では技術よりのテーマが多いでしょうが、企画や提案であれば、経営視点で物の見方が必要になるのは必須ですから避けて通れませんし。

ダイヤモンドハーバードビジネスレビュー 2016年 12 月号 [雑誌] (チームの力 多様なメンバーの強さを引き出す)