エンジニアのソフトスキル (3) 推進力
（この記事は「エンジニアに求められるソフトスキル」のPart 3です）
物事をゴールに向かわせるための力です。頑張ってもゴールに向かわなければ報われないです。マネジメントのスキルもここに含まれたりしますが、肩書にマネージャーと書いてある人以外にも必要なはずです。
タスクを分解する力
大きいタスクは、複数の小さいタスクに分解して取り掛かろうというシンプルな話です。抽象度の高いことも、分解すると具体的に検討可能になります。実現手段、完了条件、工数見積など。
大きいタスクを大きいまま取り掛かると、ずっと「1個のDoing」となってしまい、進捗も分かりません。分解すると「ここまではDone」が見えます。
言うのは簡単ですが、実行は簡単ではありません。対象領域に関するハードスキルも必要となりますし、物事を論理的に整理する力も必要です。これができる人は、自分よりスキルが低い人にも成果を挙げさせることができます。これは立派なマネジメントです。
このスキルについては、以下の記事が話題になりました。
優先順位を判断する力
タスクに優先順位をつけて、順にやる。これも言うのは簡単なスキルです。
優先順位を判断するためにできることは、色々考えられます。関係者とコミュニケーションして、与えられたタスクの目的を理解すれば、良い判断材料になりそうです。全体を俯瞰し、各工程の所要時間や依存関係を考えることもヒントになるでしょう。総じて、ゴールから逆算する思考によってうまく判断できることは多いです。
時間は有限なので、やらなくていいことをやらない力も重要です。人間ってついつい、「今やらなくていいのに今の自分にできそうなタスク」や「そこまで深入りする必要がないタスク」に誘惑されて着手し、働いた気になっちゃうものです。また、いきすぎた完璧主義も考えものです。「2割の時間で、80点の成果をまず出そう」とか言いますよね。
最後に、私の前職で会ったマネージャーの言葉を紹介します。特に2行目に注目です。
いま決められることはすぐ決める。
いま先送りできることはすぐ先送りする。
WIPの数を制限する力
一度に存在するWIP（Work In Progress: やりかけの作業）の数を制限する力です。有名な「アジャイルサムライ」にも同じことが書かれています。あれもこれもWIPになると、大抵ろくなことがないです。頭の切り替えコストがかさみますし、定期的な進捗報告もダラダラと情報が小出しになりがちです。そうこうしてるうちにプルリクもコンフリクトします。
エンジニアあるあるなのが、何かしてる最中に別の何かに遭遇して、それを調べだして、以下繰り返しというやつです。別の何かに遭遇したら、スタックに積まずにキューに突っ込みましょう。
ファシリテーション
チームの意思決定が円滑に進むように、段取りを整えたり合意形成にもっていくスキルです。主に会議の場で登場するスキルですが、会議に限らないかもしれません。コミュニケーションの力とも関わってくるでしょう。
事前準備をし、ゴールをメンバーと共有し、メンバーの関与を促し、決定にもっていきます。事前準備は大切です。その場のアドリブでどうにかしようと思っている人は、大抵どうにかできずにグダります。
当日は、発散させる力と収束させる力の両方が必要です。発散が弱い場では、メンバーに質問して言葉を引き出したりします。どこかで収束に切り替えるために、残り時間に気を配る必要があります。最後には決定事項を言語化できていなければいけません。
また、みんなが同じ理解度になれているかどうかも気を配りながら進めます。ついて行けてなさそうな人を察知しましょう。そして、理解度を揃えるちょっとしたことを挟みます。「今の案って、言い換えるとこういうこと？」とか、参考URLを貼るとか。
ポジションを取る力
今度は会議に参加したりするメンバーとしてのスキルです。ポジションを取るとは、意見や立場をはっきり表明するという意味です。
いつもどっちつかずの無難なことしか言えない人、断言できない人、リスクをとれない人は、結局は信頼を得られない人、決められない人になってしまうのです。
ポジションを取るには、最後には勇気や覚悟が必要になります。また、自信をもって自分の意見を決めるためには、案の良し悪しを自力で測るためのハードスキルも前提となってきます。
このスキルについては、以下の記事が話題になりました。
越境する力
必要とあらば、チームや部門などの組織の境界を越えて、適切な相手にコミュニケーションをとりにいったり、巻き込んだりする力です。色々な関係者による素早い協調や意思決定が必要な状況では、自分が境界を超えるフットワークも必要です。「この件は誰々さんを通して・・・」などと言っている間に、自分が直接赴く力です。
もちろん、度が過ぎると誰かに怒られるリスクはあります。周囲や過去ログを見て、こうした行動がありかなしかを判断することも大切です。また、相手が他の法人に所属する人などの場合、何らかのルール違反になるかもしれないので、そこの確認はとても重要です。そうした上でなら、リスクを恐れすぎずに思い切ることも必要です。
もう一つの注意点として、よその誰かと直接やり取りするとしても、お互いの関係者（上長など）がやり取りを見れるコミュニケーション手段を基本としましょう。例えばSlackならパブリックチャンネルで話すといったことです。そうしないと「その件はさすがにこちらを通してね」といった検出機能・ブレーキ機能が組織として働かなくなります。
この記事が気に入ったらサポートをしてみませんか？