自走できるエンジニアとは

ソフトウェアエンジニアリング界隈の言葉はとても曖昧な言葉に満ち溢れています。「自走」という言葉もそうです。でも、そういう曖昧な言葉の方が使い勝手が良いため、たとえば、ツイッターランドにはそういう曖昧な言葉がバズりまくったり、日々流れてきたりします。そうじゃなくても、「うちの職場のエンジニアには自走力が求められるんだよね」とか「転職するためには自走できる力が大切だ」みたいな言い方、度々聞いたり、むしろ話したりしていませんか？

この記事では「自走できるエンジニア」について自分なりの考えをまとめてみたいと思います。もちろんこれはあまたある解釈の中でも、僕が解釈したものに過ぎません。そういう意味ではさらに「自走」という単語を持ち出して世に混乱を投げつけるだけかもしれません。僕のただのポジショントークかもしれません。

それでよければ、「自分は自走できているのだろうか？」「自分は、うまく部下や同僚を自走させられる・してもらえるのか？」という悩みを抱えている人に、ちょっとした指針になるかもしれません。それがこの記事です。

なお、完全初心者に向けた記事ではありません。

自走とは？

「自分で走る」のが自走です。色々なところで登場するであろう単語です。その割にはこの言葉が指してる意味合いは、人によって全く違います。「技術力」「人間力」「コニュニケーション能力」などといった意味の薄い言葉程度には、人それぞれの基準が違いすぎて、明確な定義もなく、曖昧極まりない言葉の一つです。DDDやユビキタス言語、変数名・関数名のネーミングルールなどが度々バズったり、本にもたくさん書かれているような、言葉を取り扱うプロフェッショナルであるはずのソフトウェアエンジニアリングに携わる人々なのにこのような、曖昧な言葉がたびたび蔓延します。

まぁ、今回は言葉の曖昧さについて考えるための記事ではないので、この記事では「自走」という能力があるものとみなした上でまとめていきます。

自走について定義できるか？

上司から見たとき、その上司がマイクロマネージメントを好む人でないという前提のもと、あるメンバーがマイクロマネージメントしないと、結果を出せない人であれば、少なくともその職場においては「自走できない人」という扱いになるでしょう。

言い換えましょう。「上司や同僚の手のかかる人」が自走できない人といえるはずです。

ただし、ここで注意すべきなのですが、たまたま組織・人間や課題にあってないだけで、本当に自走力が無い人なのかは、これだけでは確定しません。

たとえば、「新人歓迎」「未経験者関係」と謳いつつ、実際には投げっぱなしジャーマンで何も教えず「自走しろ」という矛盾した組織であれば、自走できる・自走するための素質がある人でも、容易に自走できない人になりえるでしょう。

つまり、「何を求められるか？」「何を条件として提示されているか？」「実際にどういう扱いをしたのか？」によっても変わってくるのです。

昨今「IT人材不足」が叫ばれるため、人手が足りていない職場・案件も多いことでしょう。エンジニア採用はそれなりに難しいです。即戦力を期待して採用を行っているケースも少なくはないでしょう。ベンチャーのようにいつも資金繰りとの戦いになっているような会社が悠長に人を育てるわけがありません。大会社でも、ケースによっては人を育てるためのリソースを捻出できない事例もあるかもしれません。

教育を十分に行える現場だとしても、教育カリキュラムを組んだり、メンターが教育したりした上で、育ってくれない人、いつまでも戦力になってくれない人であれば、それはその組織が求める人材ではありません。（もちろんおわかりの通り、その場合でも教育カリキュラムやメンターの教え方が悪いという可能性もあることは注意しなければいけません）

1. 「我々の現場に対して、必要以上に手のかかからない戦力がほしい」という大人の事情を、短く圧縮して生まれた言葉
2. 「我々の教育に対して、教育時間で成長して、戦力になってくれる人がほしい」という大人の事情を、短く圧縮して生まれた言葉

おそらく「自走」という言葉は、この2つのうち、どちらかに該当するのではないでしょうか？
これらをさらに統合すると「こちらの用意するオンボーディングや教育の手間以上に手間のかからない人材がほしい」という大人の事情があることが大前提です。
もちろん、組織によってはオンボーディングや教育に対して、短い期間で改善していってるケース（まさにアジャイルですね）もあるでしょう。

ここまでは大人の事情をもとに自走について定義できるか？を見てきましたが、次はなぜ「自走」という概念が必要になるのか？を説明します。

自走という概念が必要になる理由

自走という概念が必要になるのは、自走してくれない人は、その組織にとっては持て余すことになってしまうからです。これもその人に必ずしも責任があるわけではありません。受け入れる側の組織の問題であることもあります。

ただ、あまりにも受け身すぎる人は、ほぼ多くの組織では持て余すか、安い賃金で労働してくれる人と見なされるかもしれません。

• 誰がどうやってもマイクロマネージメントしなければ、結果を出せない人
• 当人に意欲や前提能力がなさすぎて、単純な仕事しか任せられない人
• そもそも仕事する気もない人

などでしょうか？大企業の片隅にはそういった人も多くいるかもしれませんが、あいにく僕はそういった職場に縁がないため、よく知らないです。

まぁ、まとめると「言われたことができない人」です。

ただし、そもそも「言った内容がまずかった」のケースも、普通に有り得るので注意しましょう。ここでは議論を簡単にするため、言ったことは適切だったとした上で、言ったことができない人としておきます。

こういった人たちは「自走できない人」とみなすことについては、たいていの人が同意していただけるのではないでしょうか？もちろん、こういった人たちも別の業界に行けば輝くこともあるかもしれないないかもしれません。

ではもう一段上げて同意の取れる「自走できない人」について定義できるでしょうか？

言われたことしかしない・できない人についてはどうでしょうか？

これはおそらく、色々なところで論争が生じるタイプの考え方です。

たとえば「言われたことが、マイクロマネージメントなしでできるのあれば、自走できてるのでは？」「そもそも言われたこと以上を求めるのは良くないのでは？」「実際の現場というのは万能の支配者がいるわけではなく、人と人の営みなのだから、言われた通りのことだけやるのでは困る。現実問題としてチームの目指しているものに対して自分なりに考えて行動してほしい」「経営者目線で考えてほしい」などなど。

個人的には「経営者目線を持て」みたいなのは、「なら、経営者 + 現場技術者の給料くれよ？」って話にしかならないと思っていますというのは余談なのでおいておきましょう。まぁ「プロジェクトで動く金額は意識してほしい」くらいはわからなくもないです。

「経営者目線を持て」みたいな無茶振り以外に挙げたものはどれもそれなりに考慮できるものであるつもりです。

ひとまず言われたことが、マイクロマネージメントなしで、きっちりこなせる人は、僕は自走できてるとみなしてもいいかもしれないと思っています。ただし「どれくらい言わなければいけないのか？どれくらいの手間をかけなければいけないのか？」がキーになると思っています。

結局の所、「自走」という概念ありきで天地創造されたわけではありません。

プロジェクト・プロダクト・現場、そういった「現実」があって、その現実においてソフトウェアエンジニアリングという業務は「何かしらの問題を解決すること」です（ゲーム制作ならゲーマーの飢えを満たして金を儲けるという問題とみなせるはず）。とりあえず、そういった「ゴールが存在」しています。メンバーはそのゴールを目指すために働いています。

少し長くなりましたが、ゴールを目指すために、メンバーがいるときに、自分がやるよりも、マネージメントの手間がかかるのであれば、それはプロジェクトとしてはマイナスになります。教育効果がある場合は長期的に見た上ででプラスにも転じるでしょう。

走る方向はゴールであり、タスクはあくまでゴールに向かうための、断片化された手段にすぎません。もちろんその手段を積み重ねてゴールに到達するわけです。

ここまで書いて、おわかりかもしれません。自走という概念が必要な理由は、

• 走る方向性、ゴールが存在しているから
• ゴールに向かうための人員が、貢献度としてマイナスになっていると困る

という「現実」からくる要請となります。ここでいう（ゴールに向かうための）貢献度はマネージメントコストを上回る成果として、ゴールに近づけること、その度合いとしておきましょう。

即戦力がほしい現場であれば、オンボーディングを済ませた時点で貢献度がプラスになってほしいですし、教育を前提にしている現場であれば、オンボーディングや最初の教育時点ではマイナスであったとしても、いつかはプラスになってほしいです。ここに相違はないはずです。

自分で走る

さて自走という概念がプロジェクトのゴールに到達するという現実から来た要望であるということは解説しました。

では自分で走る、ということについてもう少し掘り下げてみましょうか。

たとえば、自走できる人が、もしゴールとは違う方向に走った場合、それは自走できていると言えるでしょうか？言えないはずです。ゴールに向かうためのベクトルとのズレが生じるため、ゴールとの距離が縮まらない・遠くなる、などと言った可能性があります。

もちろん、本来ゴールであるべき場所に到達するために必要なこと、セキュリティ要件が大切なのに、メンバーの認識がズレていたなど、見かけ上のゴールがそもそも違っていた場合などであれば、それは正しい行いであるため、これは自走できていると言えます。

つまり、ゴールに対して走っていくという走る方向についても、自走には大切だということです。間違った方向に全力疾走する人はプロジェクトの足を引っ張っていることになります。

また、自力で走ること自体が大切な条件でしょうか？僕はそう思いません。自分の走った距離自体が少なくてもチームのメンバーが走る距離を伸ばすことができるなら、それは良い貢献であるはずです。

自力に固執して成果を出せない・あるいは成果が減っている人は、自走してるかもしれませんが、プロジェクト全体として見たときにマイナスである可能性があります。スループット効率とフロー効率の話もあります。

自走というと「自力で解決できる人」みたいなイメージがあるかもしれませんが、そんなことはないはずです。人に質問をすることも自走には大切なプロセスであるはずです。もちろん質問をした上で、他の人が質問を繰り返さなくても住むようにドキュメント化したりノウハウ化したりシステム化すればなお良いでしょう。

よほどの少数精鋭チームでなければ、自力で走ることにはさほど意味がありません。仮に個人のスループットが高くても全体として進まなければ意味がないからです。

まとめると、

• ゴールの方向を間違わないことが自走には必要（度合いはあるし、偽りのゴールもあるかもしれないが）
• 必ずしも合意できるシーンばかりではないが、自力に固執しすぎないことも、自走には大切

なのでは？と思っています。

結論

ここまであれこれ自走について書いてきましたが、あくまで僕の解釈です。

結局の所、「自走」という言葉が曖昧である以上、絶対に必須となる工程があります。

それは「双方の期待値を調整すること」です。「自走してほしい」というなら、言う側は、どれくらいどのように走ってほしいのか？という期待を提示する必要があり、言われる側は、どのように走りたいのか？という期待を提示する必要があり、どのように走った結果どう評価されるのか？という期待値のすり合わせが必須なのです。

曖昧な言葉は、世の中にあふれてしまっています。そして世の中のトラブルの多くは、期待値のすれ違いです。双方納得できる期待値調整ができることを望みます。