エンジニアとして労働集約的な働き方と小さく早く小回りの利く働き方のどちらを選ぶのが良いのか

メンバのエンジニアに失敗を恐るなと言ってもあまりその言葉に効果は生まれないでしょう。なぜなら、失敗して良いと言っているのが期末の評価者でもあり、評価をされるメンバからその時になって失敗したことを持ち出される可能性を捨てきれないからです。

 

反対に、チャレンジしようと言っても、今度は何をして良いか戸惑うメンバもいます。言われたこと、指示されたことは忠実に実行しますが、自分で課題を見つけたり、変化しようとすることを思いもしないメンバもエンジニアの中には多くいるのです。実際、こうしたメンバが大部分を占めているのでコマンド&オペレーションが有効に働くのです。

 

なんかちょっともどかしい状態ですね。今の時代は、労働集約的に働くより個々の能力を最良の状態で発揮してもらう方へシフトしていますので。

 

感覚的には、労働集約的な働き方の部分の一部がビジネススピードの変化に対応するためにビジネスサイズを小さくして早く小回りが利くような布陣を組むようになった、ということがいえるでしょう。

 

そこで求められるエンジニア像はどういったものであるか、従来の労働集約的に働くことを続けられるのかは、エンジニアとして一時的にも判断をしておいた方が良いでしょう。

 

仮に小さなビジネスサイズで早く、小回りの利くチームで働く場合は、ロールが曖昧で、多くのロールを兼務することを予めあると理解しておくことがひとつのポイントです。何せ、人がいませんから、誰かがやってくれることはないので気づいたメンバが相互にやっておくくらいの感覚を持っていないとそのボールは役割の間に落ちたままです。

 

このような小さなビジネスサイズで早く、小回りの利くチームで働く場合は、労働集約型の働き方とは少し違う価値観を持っておくと仕事の上でスタックすることが減るのではないかと思います。例えば、品質よりタイムボックスの中で可能な品質を確保するために最良を尽くす、ような考え、行動規範が必要になります。もちろん、品質を蔑ろにすることはなく、仕事で要求されるレベルは確保するのですけれど。

 

では、労働集約型の比較的大きなビジネスサイズを選ぶ場合は何もしなくて良いのかといえば、それほど世の中は甘くないのです。何せ、そうしたビジネスサイズは数量的に限られるので。限られた中で選ばれ続けるということもひとつの生存戦略が必要となります。

 

選ばれるということは相手に認知されなければならず、サブコン側にいる場合は、ご指名される程度の知名度がないと数多のエンジニアの1リソースでしかありませんから、需要により振り回され続けるだけです。意識的にロールをあげられる、どこにいっても必ずキーファクターになる技術を身につけることが武器になるでしょう。

 

どちらを選ぶにしても、一度、いや、数年は選ばない方の働き方を経験しておくことはエンジニアとしての懐の深さ、引き出しを増やすためにエンジニア人生のどこかで役に立つでしょう。

 

実際、大規模な労働集約型の働き方から小規模のプレイングマネージャとしてロールを転換した際に経験したことはアジャイル的な働き方をプラクティスとして習得していたため、後から読んだそれ系の書籍に書いてあることは実績を裏付けられるために同意するものとそうでもないというものと自分を判断基準として判別できたので。