生存戦略：プロ作業員とチームメンバー

はじめに

今回は、IT業界における生存戦略をプロジェクトのヒエラルキーから雑に考察します。

まずは、考察にあたってプロジェクトに参画する人員のヒエラルキーを図示します。

ヒエラルキーというとピラミッド状に▲で書かれることが多いですが、実情を鑑みるとそのようには書けなそうでした。¹
リーダーやPMのフォントサイズを小さくして、Opacity (不透明度) を下げて見えにくくしているのは、リアルさの追求（？）です。²
サブリーダーもいたりいなかったり、リーダー候補として抜擢されるも勝手に期待された動き方が何か分からず結局はメンバーとしての動きをしました、というケースもありそうなので微妙な表現にしてみました。

IT生存戦略

生存戦略は生存率を上げるための戦略です。
シンプルにヒエラルキーの上にいけば行くほど生存率は上がるのですが、フォントサイズが小さくなったり不透明度が下がって霞んで見えたりと最上位まで上がると微妙なこともありそうで、管理側になりたくない若者も増えていそうです。

一方で、IT新規開発案件の縮小傾向（小型案件の増加傾向）を見ていると、「作業員」階級の仕事が減っていくことが予測されます。

とした場合、目先の生存戦略としては、「作業員」階級を抜けて「チームメンバー」階級に上がっておくことが大事に思えます。

作業員階級・チームメンバー階級？

このエントリでは、作業員階級、チームメンバー階級を以下の様に定義します。³

階級	定義
作業員	指示された作業をやる人。作業をする人。
チームメンバー	プロジェクトのゴールに向けて、一緒に納品物をつくる人。仕事をする人。

作業員は具体的な指示を受けて、それをアウトプットする作業を行う人です。
チームメンバーはプロジェクトのゴールを把握し、リーダーやPMの抽象的なふわっとした指示を受け取って具体化して自分の作業に落とし込んでアウトプットをする人です。

作業員もチームメンバーもエスパーではないので、リーダーの指示をすべて「リーダーが思った通り」理解できることはないです。

人の仕組みとして、『正しく理解できていなかったとしても、気づいていなければ』質問することはできません。
ですので、作業者が思い込みで作業をして「リーダーの期待値と異なる」アウトプットが出たとしても、「なんで質問しないの？」と怒るのはよろしくないと思います。

ただ、分からなかったことがあった時に「プロジェクトのゴールを把握して推察」するのか、「プロジェクトのゴールを把握しないで自分の価値観で推察」するのかで、「リーダーが思った通り」 のアウトプットを出せる確率は大きく変わってきます。

「プロジェクトのゴールを把握」するのかに、チームメンバーと作業員の壁がありそうです。

SESやフリーランスで時給いくらのプロジェクトを渡り歩いていると「プロジェクトのゴールを把握する」というのは基本的に不要です。そのため、本人が意識して「プロジェクトのゴールを把握して仕事をしよう」と思わない限りは、5年経験しようが10年経験しようが作業員からチームメンバーになれることはなく、作業員レベルだけが上がった、プロジェクトとしては難しいプロ作業員になっていくと考えられます。

プロ作業員

一般的に、指示の具体度が上がれば上がる程、作業者のスキルは低くてよくなりその作業を実施できる人も多くなると考えらます。

また、プログラミングスキルやドキュメンテーションスキル単体と、プロジェクトのゴールは基本的には一致せず、「プロジェクトに必要なスキルのみ」が要求されます。

図に示すと以下の様になるでしょうか。

Java の案件では Java や Spring のスキル、Next.js の案件であれば Typescript や React のスキルといった具合に、プロジェクトによって必要なスキルが異なるため、スキルは継続的に習得する必要があります。

スキルを継続的に習得しコーディングスキルが上がってきて、気働きよく、よりキレイで障害が起きにくいコードを書けるようになることはとても大事ですが、「プロジェクトのゴール」との関係性が分かりにくく、技術負債の問題がたびたび議論（炎上？）されているように思えます。

また、一見キレイなコードでもプロジェクトのゴールの認識を合わせずに書かれたコードは、それはそれで分かりにくいという難しさもあります。

生存戦略の観点では、身につけたスキルを『プロジェクトのために活用できているのか？』を意識することが、案件が獲得できる（＝生存できる）確率を上げることに繋がるのではないかと感じています。

おわりに

生存戦略における、作業員ポジションについて考察しました。
人の考えることは曖昧で分かりにくいですが、プロジェクトのゴールは人の考えることよりはまだ明確かと思います。
そこから逆算をすれば、指示を出している人が何を望んでいるかを考えやすいのかもしれません。

たまたま参画したプロジェクトでも、チームの一員と思って参画し、一緒にプロジェクトの成功を喜べるところを目指せるとよりよいエンジニアライフを送れるかもしれませんし、ブラックなエンジニアライフを送ることになるかもしれません。

おまけ

• kaku3 - Qiita記事一覧
  ポエム多め。PM、メンター、未経験エンジニアや新卒向け記事など。

• エンジニアのためのお仕事問題集
  2030年にIT人材が最大79万人不足するとのことで、学習用の資料をgitで無料公開してます(不定期更新)。

よろしければどうぞ。

1. わたし調べ。 ↩

2. 何がリアルかは各自の想像にお任せいたします。 ↩

3. 「非正規雇用」、「フリーランス」や「SES従事者」等の雇用や業務形態、「自社プロ」や「それ以外」といったプロジェクトには無関係の定義。 ↩