得たい結果を得られるスキル

実は、エンジニアの仕事はどのようなロールであってもこうあって欲しいと導き出した『得たい結果』を実現する活動の機会は多いと思うのである。

例えば、今の担当のプロジェクトはステークホルダも多く、役職も偉い人が混ざっているのであれこれと口を出してくるが、プロジェクトをキャリーするのは自分であって、全体進行について(どう進めていくのかとか)口を出してくるが、結局、全体進行のプランを考え、どう持って行こうかを定めるのも自分である。

全体進行の方向性以外でも各回のagendaについてもどうするのか口を出してくるケースは自分が先にagendaを提示していないときで、この事象からも決まっていればまずは何をすればいいのか想定できるようで口を出してこない(個別の議題での議論は別)。

全体進行、言い換えればマスタープランレベルガントチャート、各回のagendaは会議ごとの議題(そのままである)は、プロジェクトの目的(=存在理由)から自分で『得たい結果』を導き出してイメージ化したものである。各回の最終には『得たい結果』のパーツを集め、全体進行を進めながら積み重ねていく。

エンジニアも同じで、何をシステムとしてコードを書けばいいのか、どう動けばいいプログラムを書けばいいのかを段階的な表現、実現したい思いを日本語へ、日本語からコードへ変えていく手続きを経る過程で自分と同じように『得たい結果』に近づけていく。

これらのことから、エンジニアには『得たい結果』を手に入れるスキルを持つことは仕事ができると評価されるために必要になる。

この『得たい結果』のスキルは自分の意思を伝えるということである。意思を伝え、『得たい結果』を手にれる。マネージャに『カンファレンスに行きたいので費用を出して欲しい』『業務量とリソースが不一致しており(要員を追加して欲しいが無理そうだから)納期を遅らせることに同意して欲しい』『顧客への報告は実績ではなく見通しにして欲しい』など実現したい、得たい結果を手に入れるための意思を伝えるのであれば、何が何でもそれを実現しなければならない。

意思表示をして実現しなくてもいいなら伝えるだけ無駄である。その点で言えば、わざわざマネージャや顧客の前まで来て言いかけ、相手のレスポンスがネガティブだったとしてすぐに撤回してしまうのはいい振る舞いでは無い。言いたいことは最後まで話してくれ、と逆にストレスを残すだけである。

得たい結果を手に入れるためには、話の組み立てが必要である。カンファレンスの費用を出して欲しいなら、組織内の手続きを調べた上で、費用に対する効果を整理し、組織の中で活かすことまで引っ括めて話す必要がある。組織の台所事情がものすごく悪くても話をしておくことは必要だ。結果的にビジネスに活かせるとか、エンジニアが先を考えているとか、どのようなことに関心を持っているとか知ってもらわなければマネージャに認識されないからである。

同じように、プロジェクトでの全体進行をイメージ化するのはステークホルダに先を見せてどう振る舞えばいいか合わせさせるためである。agendaを先に見せるのは各回の結論から全体進行の位置付けを知らせるためである。

こうしたことからエンジニアには要件を実現する技術力は必要なのはもちろんであり欠かすことはできないのであるが、得たい結果を得られるスキルはそれを上回るのである。それができないのであれば、得たい結果を得られるスキルを発揮する前に動くソフトウェアを見せてそれでいいかを尋ねるしかない。ただこのやり方も、一緒にチームで活動する他のエンジニアに得たい結果を共有しなければならないので、得たい結果を伝えるスキルからは逃れられない。