はじめに
筆者は、文系かつIT未経験で開発部門に配属された若手社員(二年目)です。
現在はとあるマイクロサービスの保守開発や運用、内部統制まで手広くやっています。
この記事では、そんな筆者が入社後に経験したこと(特に今のチームにアサインされてから)を振り返り、自分なりに考えた新卒エンジニアのための生存戦略を、主に以下の三つの要素にわけて紹介します。
- 断らない
- 声を上げる
- 小さな失敗をする
1. 断らない
いきなり怖いなと思われるかもしれません。
たしかに、どうあっても解決できない無理難題をそのまま飲み込む必要ありません。
しかし、一目見ただけで困難だと判断して仕事を断ることは、あなたの成長を妨げることになります。
詳しく説明していきましょう。
そもそも「断らない=できる」ではない
「これおねがいできる？」
「もちろんできるけど、やり方はわからない！」
(『30点で打席に立つ』より)
あなたが仕事を断らなかったとしても、それはその時点で仕事を完璧にこなせるという意思表示ではありません。
そして、たとえ現時点でやり方がわからないことでもとりあえずやってみることで、その後の成長につながることがあるのです。
・・・これだけでもちょっとだけハードル下がりましたかね？
やってみてわかったことは残す
また、例えば手順書(正解)のない、わからない作業を頼まれたときの反応として、本心として嫌だなと思うことは当然です。
しかしその状況はあなたがこう言うだけで解決するのです。
「この作業ってマニュアルないんですね、自分も初めてやるのでやった手順をまとめておきます！」
いやあなた自身からすれば、「俺が大変なことには変わりねーじゃん」と思われるかもしれません。
ですがこれこそがあなたの後ろにつづくはずだった、手順書がなくて嫌な思いをする人を減らすたった一つの方法です。
この時点で、あなたはもう与えられる側から与える側へと変身できるチャンスを得ているのです。
そしてこれができる人は自分の観測範囲ではみんな評価されています。
わからないことも言語化する
上記のように、わかったことやうまくいったことを文書化するのも非常に大事です。
しかしわからないことを改めて言語化することもまた、エンジニアとして生き抜くためには非常に重要です。
自分がわからない作業を改めて言語化することで、自分の中で整理することができます。
わからないことだらけの新卒エンジニアにとって自分が今何に悩んでいるのかというメタ認知はとても大切です。
またこのことに関連して、Working Out Loudという考え方があります。
コンセプトはリンク先で以下のように表現されています。
Working Out Loud（コラボレーションによる成果の達成）
= Observable Work（作業の可視化）+ Narrating Your Work（作業の共有）
作業が可視化され、共有されることがなぜ成果の達成につながるのでしょうか？
まず作業が可視化されると、あなたがどこに詰まってるのか明確になります。
そして先輩やマネージャーの目の届く範囲で共有されていると、先輩として、あなたに手を差し伸べやすくなるのです。
それだけではなく「この人は悩みを自分から言語化できる人だ」という印象を与えることができます。
この印象は先輩にとっても、あなたと仕事をするうえで非常に重要です。
というのもいちいち「この人はどこでつまづいているんだろう」と考えるコストが減り、あなたの悩みを解決するためのアプローチを即座にとることができるからです。
わからないことに技術的な伸びしろがある
筆者はそもそも大学時代までWindowsしか触ったことがありませんでした。
しかし、入社後アサインされたチームではLinuxを使って開発するProductもありました。
実際にはWSL2を使って開発を行うことになったんですが、そもそもCLIの操作方法がわからないという状態でした。
コマンドを打つとエラーが出て、そのエラーをググって解決するということを繰り返していました。
そんな中で、あることを知りました。
そうです、「WSL2ではWindowsのシステムフォルダを使わない方が身のためだ」ということです。
WSL2を使っている人なら誰もが知っていることかもしれませんが、私は知りませんでした。
熟練の開発者にとっては些細なことかもしれませんが、私にとっては開発を行う上で重要な知識でした。
そしてその開発を行うProjectのREADMEやWikiにもこの情報は言及されていなかったのです。
私はその事象について調べてまとめ、改めてREADMEにTipsとして追記しました。
これはわからないことを拒絶して、仕事を断っていては得られなかったはずの知識なのです。
評価の即効性が期待できる
筆者の尊敬する先輩の一人に、未経験からプログラミングを学び、中途採用でアサインされた方がいます。
その方は昨年入社し、現在はチームの中心メンバーとして活躍しています。
入社当初からチャレンジングな仕事にも前向きに取り組み、「断らない」姿勢を貫いています。
実際に、そのような姿を評価されて、入社後半年で昇格を果たしています。
(そのあたりのお話は昨年デブキャリに登壇された際の資料があるので、ぜひご覧ください)
2. 声を上げる
さきほど、わからないことを言語化することで自分の中で整理することができるという話をしました。
しかし、声を上げることの効用はそれだけではありません。
さらに踏み込んで、考えていきましょう。
予期せぬコラボレーション
先ほどは、チームの先輩やマネージャーとのかかわりの上で言語化することは大事だという話をしました。
ただそれだけではなく、自分の思考が可視化、共有されることで予期せぬコラボレーションに繋がるのです。
例えば弊社ではtimesという分報文化が盛んです。
(参考: なぜ WHI では times 文化がうまくまわっているのか？)
私のtimesでも以前こんなコラボレーションの一例がありました。
筆者:
PR上で、
レビュワー「これってなぜ○○じゃなく××にしてるんですか？××のほうがこういう理由でよいかと」
自分「自分はこういう意図で○○にしてたんですが、指摘されて見返すとおっしゃる通り、××のほうがいいですね」
こうなった場合、修正してpushするのはレビュワーからの返信を待った方がいい？？
他チームの先輩:
この会話だとボールがレビュアー側に戻ってないですね。
「～。でも修正後の確認が大変なので、このままでもいいですか？」とかなら待ちですね。
筆者:
確かに最後の返信の仕方(相手にボールを投げているか)によって変わるということですね
ありがとうございます！
もちろん自分の所属するチームの先輩やマネージャーがいるので、そちらに相談することもできます。
しかし、Working Out Loudでは時にチームの垣根を超えたコラボレーションが生まれることもあるのです。
(ちなみにtimesとWorking Out Loudについては『分報で各自の作業を可視化したら、メンバー間の協力が加速された話』が非常に参考になります。ぜひ興味がある方は一読してみてください)
違和感への対応
ある先輩社員に、勉強会で以下のようなことを言われました。
「我々が新入社員に期待することは、違和感を感じたら声を上げることです。なぜかというと新入社員の役割は組織内の多様性を高めることだからです。」
これはとても印象に残りました。
といっても当時はそこまで意味がわかっていませんでした。
漠然と「あ～、ただ与えられるだけの存在ではないんだな」と感じた程度でした。
ただ今なら少しは自分なりに理解できます。
というのも自分も二年目になり、後輩に対して同じ感情を持つようになったからです。
組織に属するということは、良くも悪くもそこに最適化しよう/させようという力が働きます。
そのため、組織内においては、ある程度の同質性が求められます。
しかし、同質性が高いということは、すなわち組織内での多様性が失われているということを表します。
このような状況では、組織内でのイノベーションが起こりにくくなるばかりか、組織外でのイノベーションに対しても柔軟な対応が取れなくなってしまいます。
また経験豊富な社員ばかりになるとイノベーションが起こりにくくなるだけではなく、日々の業務の属人化や、ナレッジの暗黙知化が起こりやすくなります。
そうならないためにも、違和感を感じたら声を上げることはとても大事なことなのです。
違和感を感じ声を上げることは、決して誰かの邪魔をしているわけではなく、それ自体が組織にとって価値ある行動なのです。
誰かの目につくことはキャリアにとっても大事
社内外で発信(=声を上げる)を行うことは、あなたのキャリアにとても大事です。
私はQiitaでも記事を書いていますし、社内でも積極的にtimesなどで発信を行っています。
これが直接的な影響を与えているかまでは断言できませんが、少なくとも私のキャリアにとってプラスになっていることは間違いありません。
つい最近も、社外のデブキャリというイベント(昨年先輩が出たやつ)に登壇する機会をいただきました。
特に社内で応募があったのではなく、もともとメインで登壇する予定だった方が、私にも登壇してみないかと声をかけてくれたのです。
これもおそらく、社内での発信がきっかけになっていると思います。
というのもそもそも目をつけてもらうには、その人の観測範囲内で最低限目立つ必要があるからです。
3. 小さな失敗をする
失敗はなるべく避けたいものです。
しかし、小さな失敗を経験した方が成長速度は速いです。
では小さな失敗をするコツを紹介していきたいと思います。
タスクの細分化
まず、タスクの粒度が大きいままだとそもそも自分が失敗していることに気づくまでの時間が長くなります。
当然、失敗が発覚した際にも、影響度が大きなものになりやすく、リカバリーも大変です。
そうならないために、まずタスクの細分化を行いましょう。
タスクの全体像やゴールから逆算し、各フェーズでどのような状態になっていれば受け入れ条件を満たしていると言えるかを考えることで、細分化しやすくなります。
ただし最初のうちは一日単位でどこまで進められるか見通しを立てるのは大変難しいです。
そしてこれは「慣れ」の部分も大きいと思います。
一刻も早く「慣れ」るためにも、一日や一週間といった区切りで振り返りの時間をもうけ、自分自身の見通しに問題がなかったかを分析しましょう。
失敗しやすい環境の整備
ローカル開発環境の構築が終わってない人は一旦この記事をストックでもしておいて、何よりもまず構築を開始しましょう。
なぜなら、あなたが書いたコードが期待通りの動作をするかどうかを即座に確認することができるようにしなければ、これまた失敗の発覚に時間がかかってしまうからです。
例えば、あなたが書いたコードの動きを確認するために、わざわざコードをリモートリポジトリにpushしてCI/CDを回して、社内環境で動作を確認するというのは、あまりにも非効率です。
そもそも開発者はコーディングよりもビルドとテストの待ち時間が長いという調査もあります。
これに加えて自分の書いたコードを確認するために、わざわざリモートリポジトリへのpushを行っていては、生産性を著しく下げることになります。
ということで失敗をするためには、まずは失敗しやすい環境を整備しましょうというお話でした。
(まぁAI開発とかしてる方はローカルではやらないのかもですね・・・)
・・・開発環境の構築しましたか？しましたね？
では次に進んでヨシ！
ChatGPTをはじめとした生成AIの活用
個人的に生成AIの一番の利点は、「質問するハードルを下げた」ということだと思います。
というのも、生成AIに対してどれだけ同じ質問を繰り返そうが、どれだけ初歩的な質問をしようが、AIは決して呆れたりしません。
すなわち、生成AIはこちらを評価してこないという最高の心理的安全性を提供してくれるのです。
ただし、生成AIの出力結果をそのまま信じてはいけません。
「生成AIはあくまでヒントを与えてくれるものであり、それを元に自分で考えることが大事です。」のような説教めいたことを言いたいわけではなく、生成AIは平気で間違った情報を出力してくるからです。
しかもその間違った情報は、もっともらしい言い回しで出力されることが多いです。
これをハルシネーションと言います。
そのことについて詳しくここで解説はしませんが、上記のような背景から初学者にとって生成AIは諸刃の剣です。
その諸刃の剣をうまく使いこなすためには、出力結果の裏どりをすることが必須となります。
だからこそまず、開発環境の構築は済ませておきましょう。
共有による責任の分散
とはいえいくら小さい失敗でも、個人だけで背負うのは荷が重いですよね？
なのでチームメンバーにも少しだけ共有してもらいましょう。
そのためにやることは・・・そうです。
「自身の作業を可視化し、共有すること」なのです。
声を上げる重要性について再三言及してきましたが、ここでも出てきます。
勿論いくら共有したからと言って、自分の責任がなくなるわけではありませんし、投げやりな態度で取り組むのはいただけません。
それはプロの仕事とは言えないでしょう。
しかしながら、そもそもあなたが行っている仕事はチームの仕事です。別に一人で抱え込む必要はありません。
また共有したうえで失敗すると、それが個人の能力不足だったのかチームの問題だったのか切り分けが行いやすいです。
失敗の原因がブラックボックス化されていると、改善の機会がありませんが、共有されたうえでの失敗は改善ポイントがわかりやすいです。
まとめ
いかがでしたでしょうか。
今回は、「新卒エンジニアのための生存戦略」ということで、筆者が入社後に経験したことを振り返り、以下のことをまとめました。
- 断らない
- 声を上げる
- 小さな失敗をする
ただしあくまでこれは筆者の経験に基づくものであり、一つの参考として捉えていただければと思います。
もしこれらが、あなたの成長にとっても、また所属する組織にとってもプラスになれば幸いです。
(反対にこの記事を読んで違和感を感じた場合は、ぜひそのことを発信してみてください！)