「書けないまま入って、通用するものなのか」
「実装から離れたら、戻れなくなる気がする」
そんな不安を抱えたまま応募を止めているあなたへ。
結論から言えば、
減るのは書く量で、増えるのは読んで決める量でした
書けるかどうかより、読んで判断を残せるかどうかが問われます。
この記事では、書く側と受け取る側で中身が入れ替わる場面を、実際に机へ届く成果物ごとに開いていきます。
結論 — 手が空くのではなく、読む対象が入れ替わる
社内側に移ると、まとまった実装は外に出ます。手元に残るのは、小さな改修と調査が中心になりました。
ただ、空いた時間に何も入らないわけではありません。入ってくるのは、他人が書いたものを読む時間です。
読む対象は、コードだけではありません。設計書、見積、テスト結果、障害の報告書。順番に届きます。
そして読んだ後には、受け入れるか差し戻すかを決めて名前を残します。読む量より、決めて名前が残る回数のほうが効いてきました。
ですからこの記事では、書ける書けないの線引きはしません。読んで決める場面が何回来るかを数える形で進めます。あなたの現場にも、同じ場面はすでに来ているはずです。
「できない」という一語では、何も測れていない
プログラミングができるかどうかを、一語で答えられた記憶がありません。言語も、規模も、目的も違うからです。
求人票の「開発経験」も同じで、何をどこまで指しているかは書かれていません。読み手の側で解釈が割れます。
この曖昧さは、公的な整理の側でも意識されています。能力は一語ではなく、層に分けて記述されています。
IPA が公表するi コンピテンシ ディクショナリでは、タスクディクショナリがタスク3階層と評価項目の計4階層、スキルディクショナリがスキル3階層と知識項目の計4階層で構成されると説明されています（2026年9月8日 取得）。
つまり、仕事の側も能力の側も、層に分けて初めて記述できる作りになっています。できる・できないの二択は、そもそも記述の単位として粗すぎます。
ですから不安を分解するときも、二択ではなく場面で割ったほうが答えが出ます。あなたの不安も、次のどれかに寄っているはずです。
- 手を動かす時間が減って、書く速さが落ちることへの不安
- 新しい言語や書き方から離れて、話題に付いていけなくなることへの不安
- 技術で貢献した実感が無くなり、何をした人か説明できなくなることへの不安
- 次に動くとき、経歴に書ける行が薄くなることへの不安
4つのうち、社内側で実際に強く出るのは1つ目と4つ目でした。次の章から、その中身を場面ごとに開いていきます。
書く側のレビューと、受け取る側のレビューは別物だった
受託や常駐で開発していたころ、レビューという語は「直すべき箇所を見つける場」を指していました。
指摘の数が多いほど、丁寧に見た証拠になります。指摘票が返ってきたら、直して再提出する流れです。
社内側に移って、同じ語が別の意味で使われていることに気づきました。受け取る側のレビューは、直す場ではなく受け入れるかを決める場でした。個人の経験に基づく記述であり、同じ結果を保証するものではありません。
指摘を書くと、相手は直します。直せば工数が増え、日付が動き、金額の話になります。
ですから指摘は、直すべきかどうかを判断した後にしか書けません。見つけた不備を全部書くと、進行のほうが止まります。
書く側にいたころ、指摘の少ないレビュアーは手を抜いていると思っていました。実際には、書かなかった指摘のほうを別の場所で処理していました。
同じ「レビュー」という言葉が、両側で別の作業を指していました。ここを取り違えたまま移ると、最初の半年は指摘の量で評価されようとして空回りします。
読んで決める仕事は、5つの場面に分かれる
読む場面を数えると、行き先はこの5つに落ち着きました。どれも書く技術より、読む観点のほうが効きます。あなたの経験がそのまま効く場面から並べます。
1. 見積の妥当性を、規模の感覚から読む
届いた見積に、根拠が細かく書かれていることはまれです。工数と期間だけが並びます。
妥当かどうかを判断する材料は、こちらの経験にしかありません。似た機能を自分で作ったときの感覚が、そのまま物差しになります。
ここで効くのが、書いてきた期間です。画面が何枚で、テーブルが何本で、といった規模の勘は、読むだけでは身につきませんでした。
ですから、書けない人には難しい仕事です。正確には、書いた経験を持っている人が読むと速い仕事でした。
逆に言えば、いま書けている経験は、移った後に物差しとして残ります。捨てるわけではありません。
2. 受け入れの合否を、仕様書ではなく画面で決める
納品物が届いたら、受け入れの判定をします。ここで見るのは、仕様書との一致だけではありません。
使う部署が明日から回せるかどうかを、画面を触って確かめます。仕様どおりでも回らない場合があるからです。
回らない理由は、たいてい仕様書に書かれていない前提にあります。締めの日の運用、例外の入力、紙との突き合わせ。
ですから受け入れの前に、使う部署の人と一緒に触る時間を取ります。ここを飛ばすと、稼働後に差し戻しが来ます。
判定は、合格か不合格かの二択ではありません。この機能は通し、この機能は次回、という線引きになります。
3. 障害の一次切り分けで、ログとコードを読む
止まったときに最初に立つのは社内側です。ベンダーへ渡す前に、事象と影響範囲を書き出す必要があります。
ここでログを読みます。読めないと、ベンダーへ渡す文が「動きません」だけになり、往復が増えます。
ソースを開くこともあります。書き換えるためではなく、どこまでが自分たちの責任かを見るためです。
この場面が、実装の経験を最も強く求められる瞬間でした。夜間や休日に一人で読むこともあります。
4. ベンダーの提案を、後で誰が保守するかで読む
提案書には、新しい構成や新しい製品が並びます。技術的に良いかどうかは、比較的すぐ判断できます。
判断が難しいのは、その構成を5年後に誰が面倒を見るかのほうです。作った会社が残っているとは限りません。
ですから読む観点は、性能や機能より先に、引き継げるかどうかになります。設定が独自の書き方で埋まっていないか、といった見方です。
この観点は、常駐している側では持ちようがありませんでした。契約の期間が終われば、こちらの手は離れるからです。
離れない側に回ると、時間の幅が変わります。読む対象は同じでも、見る先が数年先へ伸びました。
5. 社内に残った内製コードを、引き継げる形かで読む
どの会社にも、誰かが作った小さな仕組みが残っています。マクロ、バッチ、集計用のスクリプト。
作った人はたいてい辞めています。動いている限り誰も触りませんが、止まった日に全部こちらへ来ます。
ですから、止まる前に読んでおく必要があります。読んで、残すか置き換えるかを決める作業です。
置き換えると決めた場合、手を動かすのは自分になることもありました。小さい実装は、社内側でも手元に残ります。
まとまった開発は減りますが、書く機会がゼロになったことはありませんでした。減るのは量で、消えるのは連続した時間のほうです。
書けなくなるのではなく、書く場所が変わる
実装から離れることへの不安は、腕が落ちる心配として語られます。実際に落ちた部分と、落ちなかった部分がありました。
- 落ちた：まとまった機能を一人で組み上げる持久力。連続した時間が取れないので、練習量が減ります
- 落ちた：新しい書き方への追随。動いているものを更新しない判断が正しい場面が多く、触る機会が減ります
- 落ちなかった：規模を見積もる勘。読む対象が増えるので、むしろ精度が上がりました
- 落ちなかった：ログから当たりを付ける手順。障害の一次対応で毎回使います
落ちる側は、業務時間の外で補うことになります。落ちない側は、社内側の仕事そのものが練習になります。
この非対称は、移る前に分かっていれば手が打てます。移った後で気づくと、埋め合わせに使える時間が減っています。
どちらを自分の芯にしたいかで、移る判断は変わります。芯が前者にあるなら、内製の比率が高い職場を探す話になります。
常駐している側で技術が積み上がらない感覚があるなら、原因は別のところにあるかもしれません。割り当ての幅と決定への距離から止まる場所を探した記事を用意しています。移る前に、いまの現場の側を確かめておくと判断が楽になります。
読む力は、いまの現場で測れる
読んで決める力があるかどうかは、移る前に見当が付きます。あなたの現場にも、他人が書いたものは届いているはずです。
- 直近1か月で、他人の書いたコードを読んだ回数を数える。ゼロなら、まず読む機会を作るところから始まります
- 読んだ後に、直したか、指摘したか、そのまま通したかを分ける。通した判断が一度もないなら、決める側の経験が薄い状態です
- 自分が出した指摘のうち、相手の工数が増えるものが何割あったかを見る。割合が高いほど、受け取る側の作法とは離れています
- 読めなくて手が止まった箇所を書き出し、言語の問題か業務の問題かに分ける。業務側が多いなら、社内側では有利に働きます
ここで出るのは技術の優劣ではありません。決めた回数という、数えられる実績のほうです。
数が少なくても、いまの席で増やせます。読む機会は、たいてい隣の席に転がっています。
決める側に回ると、部署の位置そのものが効いてくる場面も出てきます。決裁が誰の手にあるかで通り方が変わる話は別の1本にまとめました。判断を通しにくいと感じたことがあるなら、そちらも開いてみてください。
窓口へ行く前に、公表されている対象を確かめる
読んだ回数と決めた回数が出たら、相手側の公表内容へ移ります。ここを先に読むと、面談で経歴の説明に時間を取られません。
確かめるのは対象の欄です。面談では動かせない条件なので、合わなければその時点で見送りになります。
社内SE転職ナビが対象に掲げるのは、自社の中で働きたいITエンジニア（社内SE・情報システム職）です（同社公式サイト。2026年8月17日 取得）。
もう一方のレバテックキャリアは、ITエンジニアとデザイナーを対象に挙げています（同社公式サイト。2026年8月17日 取得）。業界の側はIT・Webに絞られます。
引いたのは各社の公表内容だけで、当サイトの側で確認したものではありません。公式サイトに載っていない条件を、無いと決めつけることはできません。
当サイトの評価軸に基づく整理であり、客観的な優劣を示すものではありません。評価軸は広告掲載方針に記載しています。
2つの窓口は、実装を芯に残すかどうかで分かれる
筆者は本サービスの利用者ではありません。以下は各社の公表情報と、SE・社内SE としての実務経験からの整理です。
面談では、書けるかどうかの確認が先に来ます。読んで決めた回数を出せると、話が一段先へ進みます。
あなたが読む側へ寄せたいのか、書く側を芯に残したいのかで、見る窓口の順番も変わります。
読む側へ軸足を移すと決めた段階なら、社内SE転職ナビの掲げる範囲に入ります。
受け皿は社内SEと情報システム職に限られます。実装を芯に残す道を探している間は、条件のほうが先に立ちはだかります。
実装を芯に残したいなら、レバテックキャリアのほうが枝を並べやすくなります。置かれる前提は、エンジニアかデザイナーの側で積んだ経験です。直近で書いた記録が薄いと材料が足りません。
3つの項目は、どちらの枝でもそのまま使えます。違ってくるのは、返ってきた答えを読む時間として受け取るか、書く時間として受け取るかです。
まとめ — 問いを「書けるか」から「決められるか」へ入れ替える
社内側で減るのは、書く量でした。増えるのは、他人の成果物を読んで受け入れを決める回数です。
書いてきた経験は、読むときの物差しとして残ります。実装の年数は、移った後も使い道があります。
失われやすいのは、まとまった時間で組み上げる持久力のほうでした。ここを芯にしたいなら、内製の厚い職場を探す話になります。
問いを「書けるか」から「読んで決められるか」へ入れ替えると、確かめる材料が手元に出てきます。今月読んだ他人のコードの本数から数え始めると、面談で話せる形になります。