エンジニアの生産性の差は10倍や100倍にもなると言う話は聞いたこことがあるかと思います、底辺と天才を比べた極端な話だと思いますよね？実はこれありふれた話です。超有名ベンチャーで難しい採用試験を潜り抜けて即戦力採用された人たちの中でも100倍の差があることもあります。それも瞬間風速的な話ではなく、年間の変更コード行数を計測してそうなります。10倍の差はもっとありふれた話です。

さてここまではプラス面だけの話ですが、マイナス面も考える必要があります。

あなたが無事現場に入ってわからないことを教えてもらう必要があるとします。面倒見のいい先輩がなんでも聞いて良いよと言ってくれたので、質問をして、3時間先輩の時間を使ってしまいました。先輩は100倍エンジニアだったとすると、その3時間であなたの二ヶ月分の作業量が消し飛んだ計算になります。あなたはそれに見合った成長をして恩返しできますか？

ちなみにそれくらい能力差があっても給与はあまりかわりません。良くて倍くらい。同じ給与ってこともまぁよくある話で、多重下請の現場では逆転してることも珍しくはありません。

底辺の生存戦略

そろそろ本題に近づいてきました。

ここまでの話を踏まえてどうするべきだと思いますか？

特別なことでも難しいことでもなく、いたってシンプルです。それは「足を引っ張らない」ことです。大抵の現場では初心者に毛が生えたような人にアウトプットを期待していません。ある程度の教育期間をとった後で普通の人の半分でもアウトプットを出してくれたら恩の字です。

あなたが天才でなければ、まずは自分でアウトプットを出すのは一旦諦めてください。先輩の時間を増やしましょう。例えば動作確認や他チームやステイクホルダーへの連絡、文書作成など、100倍エンジニアでも生産性が変わらない業務を肩代わりして先輩が開発にかけられる正味の時間を増やしましょう。これが現段階では正しいチームワークです。100倍エンジニアの時間を奪って質問するくらいなら、10倍の時間をかけて一人で調べた方が、10倍生産性が高くなります。聞くとしても調べた上での答え合わせと間違っていた時のヒントだけにしましょう。個人の学習効率をだけみてもそっちのほうが効率いいです。理解できない人には独学大全がオススメです。

ろくに動作確認をしていない可読性の低いコードをプルリクに出して、レビュワーになった100倍エンジニアが仕様確認したりローカルで動作確認したり、あまつさえバグを見つけてしまうなど、最悪です。

初心者だから間違えてもしょうがないというのは正論です。しかし、プロジェクトの時間とコストを考慮すれば逆の結論になります。あなたのアウトプットが数倍早くなろうが遅くなろうがプロジェクトには影響がないのです。学習時間とリスクを考慮してそういうふうにタスクを組んでいます。数倍時間をかけて慎重にやって良く、マイナスを生まない事を考えれば、初心者こそ絶対にバグを出してはいけないという結論になります。0は無理でもそういう気持ちでやりましょう。

ここまでは現場に入ってからの話でした。皆さんは現場に入る方法を知りたいと思いますが、もう少し辛抱してください。敵を知り己を知れば百戦危うからずの故事もあります。もう少し敵を知ってから戦術を立てましょう。

デスマーチ

デスマーチと呼ばれているものには2種類あります。一つは定義通りのデスマーチ　(https://ja.m.wikipedia.org/wiki/デスマーチ )。もう一つはデスマーチの要件を満たさないが、関係者の能力不足によってデスマーチの様相を呈しているもの。実は前者はとても希少で、世の中のきついプロジェクトというのはほとんど後者だと考えてください。

様々な点で両者は異なります。

真のデスマーチはほとんどの場合技術的な問題ではなく政治的な問題で発生します。そのため予算は潤沢ではないが常識的にはあり、技術は枯れてリスクが少なく確かな効果が確認されているものが採用されていることが多いです。工学的なアプローチで生産性を向上する仕組みなどが取り入れられていることもあります。管理プロセスも機能しておりコンプライアンス違反も少ない傾向があります。政治的な理由でプロジェクトが延長されている都合で、PMがプロジェクトを終わらせたいと思っていても、予算がある限り新しい要件が発生しつづけて終わらないという状況も発生しえます。こちらのタイプに参加するメリットとしては、よく管理運営されたプロジェクトを体験できる点、ドキュメントがしっかりしている点、低スキルの人が参加することを考慮して仕組み化されているのでキャッチアップにかかる時間が低いなどがあります。

なんちゃってデスマーチは技術力や要件定義能力、集団の合意形成能力などの不足によって起こります。PMやステイクホルダーは赤字を垂れ流すプロジェクトを早く終わらせたいと思っているので多少納期が伸びても必ず終わります。プロジェクトを終わらせるための提案であれば下からの意見でも柔軟に対応してくれることもあります。新しい技術と古い技術が混在していたり、新しい技術を採用しているのに使いこなしていないこともあります。CI/CDや自動テストが無い又は不十分な現場も多いです。こちらのメリットとしてはスタンダートが低いのでキャッチアップ戦力になれるまでの時間が短かったり、小さな労力で大きな生産性改善ができ職務経歴書に書ける良いエピソードが作りやすいといったことが挙げられます。

また両者には人の出入りが激しいという共通点があります。そのためドキュメントの有無にかかわらず新しい人が参加し、教育や環境構築を行いタスクを振って実務を行うという、一連の受入業務に現場の担当者が慣れています。またこれは両者それぞれのところで触れましたが、理由はそれぞれ違いますがキャッチアップして戦力になるまでの時間は小さいという共通点があります。

デスマーチでは残業が多いと思われていますが、新人は戦力として期待していないので残業する必要はないです。マネージャーからすると、無駄な残業代は払いたくないし事故って仕事を増やすリスクも嫌なので、1秒たりとも残業してほしくありません。早く帰ってリフレッシュするなり自習するなりしてプロジェクトのリスクを減らしてください。

そのため、デスマーチに入って残業というのは底辺層にとってはほとんどの場合杞憂です。テスト要員としてでも残業を頼まれたら戦力に数えられている事を喜んでも良いと思います。

翻って比較対照としてみなさんに人気のあるWeb系企業を考えてみましょう。GoogleやNetflixとまではいかなくても、ほとんどの会社ではそれらを模倣しています。共通点としてはだいたい自走・自律できることが求められます。辞める人は少ないので比較的受け入れ体制は整っていないケースが多いです。企業によってスキルレベルはピンキリですが、周りとのスキル差が大きくなるのでキャッチアップにかかる労力と時間は大きくなります。開発プロセスは整えられているため、あなたが工夫して改善できる余地は少ないです。

ここであなたが採用する立場になったと想像してください。「最新の技術スタックで言われた作業をやっていました。ついていくのがやっとで自分で工夫した点は特にないです。勉強はがんばりました」という人と、「技術スタックが古かったのですがXXを導入してXXをXX程改善できました」という人がいたとして、どちらが戦力になりそうでしょう？どちらを採用したいですか？

まとめ

ここまで書いたことを理解して謙虚に面接を受ければそう悪い結果にはならないと思います。

残業は大したリスクではありません。

現場の技術レベルが高い現場を望んでもメリットは無いので、少しでも自分が成果を出しやすい環境を探しましょう。

面接ではチームのアウトプットを高めるために最大限努力するという姿勢を見せましょう。

Permalink | 記事への反応(3) | 12:49

2020-11-17

■ベンチャー から 日本の大企業に転職して３年経った

とある日本の大企業に転職して３年経った。この３年、失望し続けることばかりでつらくなってきたので、ガス抜きにここに書こうと思う。

私は以前、とあるメガベンチャーに勤めていた。仕事はハードであったが、充実していた。結婚し子供が生まれ、育児しながら仕事をしていくのは少し難しかったため、業務時間が短く、保証も充実している日本的大企業に転職することにした。

大企業の仕事はお遊びだった。偉い人のお気持ちをまとめて、要件らしい何かを書き、それをベンダーに丸投げする。仕様書も、テストケースも、負荷試験も、自分たちでは何も理解していなかった。ベンダーからの成果物を、何も理解せず、検証もせずに受け入れていた。当然いくつかのプロジェクトは最後になって破綻し、すべての責任をベンダーに投げていた。

私は以前の会社で、すべてを実施していた。そのため、それらをそれなりにこなせる私は重宝された。私は入社して数ヶ月でプロジェクトリーダーになり、そのプロジェクトを成功させた。私が最初にいた企業では当たり前水準を満たさないようなものだったが、それでもこの企業では大きな成果だった。それ以降、数日おきに偉い人が自分の持っているプロジェクトについて意見を聞きに来るようになった。

私が彼らに話したのはシンプルな話だった。有名なマネジメントの本をよく読み、その知識を元にベンダーとよく話し、彼らの言葉をしっかりと理解し、無用な負荷を与えないように最も重要な課題にのみフォーカスできる環境を整える。本に書いてあることをちゃんと実践する。それだけだ。それだけのことが、驚くほど彼らには伝わらなかった。最初はプロジェクトの相談だけだったのが、計画書、仕様書、テストケース作成の仕事が回ってくるようになった。倍以上の年齢の人が仕事を渡してくるのだ。当時20代の私はうまく断ることができなかった。平日は深夜まで働き、休日も多くを仕事に費やして、なんとか回るような状態だった。

そして気がつけば、２つのプロジェクトのリーダーとなり、３つのプロジェクトのアドバイザーになっていた。だが当時20代の私は、肩書のない平社員のままだった。平社員の私が私よりも数段上の役職の人間に、彼らのプライドを最大限守りながら業務指示を出していた。

アドバイザーとしての仕事は、偉い人の非現実的な妄想を聞いて、それを現実的な着地点に収める計画書を作るといったものだ。偉い人は自分で依頼した仕事について、何も理解していない。そのため、ベンダーからの成果物も私が検品し、何も勉強していない足りない頭でも理解できるように解説して渡した。仕様書通りの成果物がベンダーから提供されたときも、偉い人間が癇癪を起こし、やり直しになることもあった。

この大企業は、若者たちの多くが優秀だった。みな学習意欲が旺盛で、プライベートでは様々なプログラミング言語やクラウドについて学習し、今の仕事に取り込むために知恵を振り絞っていた。若者達は多くを学んでいるため、上の人間の間違いによく気づき、それとなく指摘した。上の人間は知識では勝てないので、怒りの感情でそれに対処した。若者達は今の仕事で実績を作ったあと、AmazonやGoogleに転職していった。残されたのは、学習する習慣の無い、高学歴で、間違いを指摘するような精神性を持たない者達だけだった。