社内にエンジニアが自分しかいないと、何が伸びて何が止まるのか
一人目のエンジニア、一人の社内SE、一人で担当している受託案件。相談相手がいない環境では、触る範囲は広がるのに判定の基準だけが作られません。伸びるものと止まるものを分け、一人のまま埋める方法と、選考での読まれ方を整理しました。
目次
社内でコードを書いているのが自分だけ、という環境は思ったより多いです。一人目のエンジニアとして入った、社内SEが自分だけ、受託で案件ごとに一人で担当している——形は違っても、起きることは似ています。
この環境は、評価が真っ二つに割れます。「一人で全部やったから成長が早い」と言われることもあれば、選考で「基準が独特ですね」と見られることもあります。両方本当で、伸びる部分と止まる部分がはっきり分かれているからです。
一人の環境では、幅が伸びて判定が止まる
同じ年数を複数人のチームで過ごした場合と比べると、差はきれいに出ます。
最後まで自分で持っていく力
- 要件から運用まで一通り触る
- 詰まったときに自分で抜ける経験
- 技術選定を自分で決める
- 誰も助けてくれない前提の見積もり
自分の判断に値が返らない
- 書いたコードが読めるかどうか
- 選んだ構成が妥当かどうか
- 自分の速度が速いのか遅いのか
- 他のやり方が存在することに気づく機会
左側は、チーム開発では手に入りにくいものです。ここは素直に強みになります。問題は右側で、どれも自分では判定できない種類のものだという点です。
止まるものは、具体的に3つ
書いたコードが他人に読めるかどうか
一人なので、読む人がいません。自分が読める書き方は、自分には必ず読めます。だから半年前のコードが読めなかったとしても「忘れていたから」で説明がついてしまい、書き方の問題だと気づけません。レビューがない環境で何が抜けるかはコードレビューを受けたことがないまま年数が経つとに分けて書きました。
構成の選択肢が、最初に選んだものに固定される
一人で決めると、比較対象が自分の過去の判断だけになります。最初に調べて選んだ構成が、そのまま3年後も標準になりやすい。悪い構成という話ではなく、他の案を知らないまま最適だと思っている状態になります。これは選考の「他にどの案を検討しましたか」でそのまま出ます。
自分の速度が分からない
一人だと、1つの機能にかかる時間が妥当なのか判断できません。3日かかったものが、他の環境なら半日かもしれない。この感覚がないと、見積もりが社内でしか通用しない形になります。転職後にいちばん戸惑うのがここです。
一人のまま埋められるもの、埋められないもの
全部は埋まりませんが、半分は自分で置けます。
| 止まるもの | 一人で置ける代わり | 効き方 |
|---|---|---|
| 読めるかどうか | 2週間おいてから自分のコードを読む | ある程度効く |
| 他の案を知らない | 同じ機能をOSSがどう実装しているか読む | かなり効く |
| 速度が分からない | 公開されている技術記事の実装時間と比べる | 弱い |
| 判断が妥当か | 外の人に1回見てもらう | これしかない |
| 標準が分からない | 使っているライブラリの公式の書き方に寄せる | 効く |
2番目は負荷が低くて効きます。自分が作ったものと同じ機能を、使っているライブラリのリポジトリや類似のOSSがどう書いているかを読むだけです。選択肢が複数あることと、自分が選ばなかった案の理由が同時に分かります。
4番目だけは、一人では置けません。ここが一人の環境の構造的な穴です。
選考では、プラスとマイナスが同時に出る
一人の経験は、選考で両方向に読まれます。先に知っておくと対策できます。
プラスに読まれるのは、範囲の広さです。要件から運用まで触っているので、任せられる幅が広いと判断されます。30代以降は特にここを見られます（「30代でプログラミングスクール」は未経験と経験者で答えが正反対になるに年齢と範囲の関係を書きました）。
マイナスに読まれるのは次の2つです。
- チームで開発した経験がない（レビュー、分担、合意形成の経験が読めない）
- 判断の基準が社内に閉じている（他の案を知らないまま決めてきたのではと疑われる）
1つ目は事実なので、覆せません。代わりに、2つ目を潰しておけば印象はかなり変わります。「この構成を選んだとき、他にA案とB案を調べて、こういう理由で外した」が1つでも言えると、閉じていないことが示せます。
いまの環境で確かめること
一人の環境が自分にとって得か損かは、次の5つで判断できます。
確かめる5つ
- 01自分のコードに、誰かの指摘が返ってくる機会が年に1回でもあるか
- 02使っている技術が、社外の求人票に載っている技術と重なっているか
- 03この1年で、新しく作ったものがあるか（保守だけなら判断の機会が増えない）
- 04技術選定をするとき、2案以上を比べて決めているか
- 05社内でしか通じない仕組みに詳しくなっていないか
1が「ない」で、5が「なっている」なら、年数が増えるほど外に出しにくくなります。社内固有の知識が評価されない構造はエンジニアの年収が上がらない理由に書きました。
正直なところ：一人の経験はかなり強い
穴ばかり書きましたが、一人で回してきた経験は市場では評価されます。要件を決めて、作って、運用して、壊れたら直す。この一通りを自分の判断でやった人は、複数人のチームで分担していた人より範囲が広いことが多いです。
足りないのは経験の量ではなく、自分の判断に外からの値が返ってきていないことだけです。ここだけを埋めれば、一人の環境は不利になりません。埋め方は何でも構いません。外のエンジニアに見てもらう、OSSに出す、勉強会で話す。1つ入れれば変わります。
独学と同じ構造の問題なので、エンジニアの独学に限界が来るのは、知識が足りないところではないも合わせて読むと、止まっている場所の特定がしやすいと思います。
まとめ
| 一人の環境の見え方 | 実際 |
|---|---|
| 全部やるから成長が早い | 範囲は伸びる。判定は止まる |
| 一人でできるなら実力がある | 動かせる力はある。妥当性は不明 |
| 相談相手がいないのが弱点 | 弱点は相談ではなく判定が返らないこと |
| チーム経験がないと不利 | 他案を検討した跡があれば印象は変わる |
社内に自分しかいない環境でやることは、相談相手を探すことではなく、自分の判断に外からの値を一度でも返してもらうことです。範囲の広さはすでに持っているので、そこに判定が1つ加わると、選考でも社内でも読まれ方が変わります。
JISOUは実務経験者向けのオンラインスクールで、受講生は自分のアイデアでサービスを作り、提出したコードに現役エンジニアのレビューが入ります。ハッカソンはオフラインで開催していて、一日チームで開発すると、一人では出てこなかった差が一気に見えます。社内に相談相手がいない状態が続いているなら、一度外の基準に当ててみてください。