学生と実務は何が違うか

この教科書の残りは、すべて技術の話です。 しかし最初につまずくのは、たいてい技術ではありません。

学生としてプログラムを書くことと、仕事としてプログラムを書くことは、 前提が違います。そして厄介なことに、その前提は誰も説明してくれません。 周りの人にとっては当たり前すぎて、説明が必要だと思われていないからです。

この章は、その当たり前を先に言葉にしておくためのものです。

1. コードを書く時間は、仕事の一部でしかない

最も大きなギャップです。

学生:  課題が出る → 考える → 書く → 動いた → 提出
実務:  ？？？ → ？？？ → 少し書く → ？？？ → ？？？

実際の1日は、こういう形になります。

「今日は1行も書いていない」という日が、普通にあります。 そして、それは何もしていない日ではありません。

2. ゼロから作らない。既存の改修が大半

学生:  空のディレクトリから始める。全部自分で書く。全体を把握している
実務:  何十万行もあるコードベースの、ごく一部を触る

最初の仕事は、たいてい既存機能の修正や小さな追加です。 新規サービスをゼロから作る機会は、何年かに一度あるかどうかです。

だから、読む技術のほうが先に必要になります（既存コードを読む）。

そして重要なこととして、

□ 触る範囲の周辺だけ理解して着手する
□ 分からない部分は「今は分からなくてよい」と決める
□ 必要になったらその都度読む

3. 模範解答が存在しない

学生:  課題には正解がある。教科書に載っている。先生は答えを知っている
実務:  誰も答えを知らない。そもそも問題自体が曖昧

これは想像以上に大きな転換です。

「使いやすくしてほしい」        ← 何をどうすれば「使いやすい」のか
「パフォーマンスを改善して」    ← どこが、どれくらい遅いのか
「いい感じにやっといて」        ← ？

曖昧なまま来るのが普通で、それを具体的にするところから仕事が始まります。 これは相手が不親切なのではなく、依頼する側も分かっていないのです。

だから、こう聞き返します。

「今、具体的にどの操作で困っていますか」
「何秒くらいになれば OK ですか」
「これができたら成功、と言えることは何ですか」

□ なぜこのテーブルにこのカラムがあるのか
□ なぜこの処理だけ例外的なのか
□ この「顧客」という言葉が何を指すのか（ドメインとは何か）

4. 「動いた」は終わりではない

学生:  動いた → 提出 → 終わり
実務:  動いた → ここからが半分

実務での「終わった」は、こうです。

□ テストを書いた
□ 他人が読める形になっている
□ レビューを受けて、指摘に対応した
□ マージされた
□ 本番にデプロイされた
□ 本番で正しく動いていることを確認した
□ 問題が起きた時に気づける状態になっている

そして、その後も運用が続きます。 作って終わりの成果物はありません。

「これ、終わりました」と言った後に「本番で確認した？」と聞かれるのは、 新人が最初に必ず通る道です（開発の流れ）。

5. 評価のされ方が、根本的に違う

ここが最も誤解されています。

学生:  点数。一人で解けたか。速く正確に解けたか
実務:  信頼。この人に任せて大丈夫か

具体的には、次のようなことで評価が決まります。

30分調べて分からないことを、3時間かけて自力で解く
   → 2時間30分を無駄にした、と評価される

6. 黙っているのが、最も評価を下げる

学生:  進捗を報告する義務は無い。提出日に出せばいい
実務:  進捗が見えないこと自体が問題

新人が「詰まっている」と言えず、3日間黙って作業していた—— これは実務で最も多い失敗パターンです。

周りから見ると、こうなっています。

（何をしているか分からない）
（順調なのか、詰まっているのか分からない）
（間に合うのか分からない）
→ 声をかけるべきか判断できない
→ 締め切り直前に「できていません」と知る

あなたが悪いのではなく、情報が無いことが問題です。

□ 1日1回、今やっていること・詰まっていることを書く
□ 見積もりからずれたら、その時点で言う
□ 「順調です」だけでなく、何がどこまで進んだかを書く

完璧にしてから見せる → 方向性が違ったら、全部やり直し
早めに見せる        → 5分の会話で方向修正できる

7. 時間とお金の感覚

学生:  自分の時間は自分のもの。徹夜も自由
実務:  あなたの1時間には、会社が払っている値段がある

これは厳しく聞こえるかもしれませんが、逆の意味もあります。

□ 「1時間悩む」より「5分聞く」ほうが、会社にとって安い  ← だから聞いていい
□ 会議に5人が1時間出る = 5時間分のコスト               ← だから短く済ませる
□ 手作業を30分×毎日 = 年間100時間以上                   ← だから自動化する価値がある

「聞くのは申し訳ない」という遠慮は、経済的には逆効果です。

待ち時間が存在する

学生:  自分が手を動かせば、常に前に進む
実務:  レビュー待ち、CI 待ち、承認待ち、他チームの対応待ち

自分では進められない時間が存在します。 これは最初とても戸惑います。

□ 待っている間に進められる別のタスクを持っておく
□ 何を待っているかを見えるようにする（開発の流れ）
□ 待ちが長引いたら催促する（遠慮しない。忘れられているだけのことが多い）

まとまった時間は取れない

学生:  半日集中して一気に書く
実務:  会議、質問、レビュー依頼、障害で中断される

中断される前提で作業を区切る必要があります。 「今どこまでやったか」をメモしておくだけで、復帰の速度が変わります。

8. 失敗の重さが違う

学生:  バグ = 自分の点数が下がる
実務:  バグ = 顧客が困る、売上が減る、信用が落ちる

だからこそ、隠さないことが最重要になります（エンジニアとしての立ち振る舞い・ルールを守る — 情報を扱う者の日常）。

□ ミスは必ず起きる。責められるのはミス自体ではなく、隠すこと
□ 気づいた時点で、すぐ言う。数時間の遅れが被害を桁で変える
□ 「自分で直してから報告しよう」が最も危険

□ 本番のデータは、練習で触らない
□ 「たぶん大丈夫」で実行しない
□ 権限を求められるまま受け取らない（ルールを守る — 情報を扱う者の日常）

9. レビューは、人格への評価ではない

学生:  評価される経験 = 成績。指摘 = 減点
実務:  レビューの指摘 = そのコードを良くするための情報

最初は、指摘が全部「ダメ出し」に見えます。それは正常な反応です。

しかし実際には、

□ 指摘が多い = よく読まれている（放置されるより圧倒的に良い）
□ 指摘は「コード」に対するもので、「あなた」に対するものではない
□ ベテランのコードにも同じくらい指摘は付く

そして、納得できなければ議論して構いません。 「言われた通りに直す」だけの人より、「なぜですか」と聞く人のほうが伸びます。

10. 勉強は終わらない

学生:  試験が終われば、その範囲は終わり
実務:  常に知らないことが出てくる。しかも調べると新しい未知が増える

最初の数ヶ月は、「調べれば調べるほど、知らないことが増える」 状態になります。 これは正常です。むしろ、それが起きていないなら学べていません。

□ 全部を理解しようとしない
□ 「今日はこれが分かった」を1つ拾う
□ 分からないものリストを作り、後で回収する

学生の常識と、実務の常識

まとめると、こうなります。

最初の1ヶ月で意識すること

□ 分からないことは30分で聞く（何を試したかを添えて）
□ 1日1回、進捗と詰まりを書く
□ 完璧にしてから見せない。途中で見せる
□ 用語が分からなければその場で聞く（ドメインとは何かの用語集を自分で作る）
□ ミスに気づいたら、その場で言う
□ 「終わりました」の前に、DoD を確認する
□ 書いていない日に罪悪感を持たない
□ 全部を理解しようとしない

逆に、学生のほうが強いこと

ギャップばかり書きましたが、あなたの側にしかない強みもあります。

「何も知らないこと」は、一時的に価値があります。 その期間にしか出せない指摘があるので、遠慮せずに出してください。

まとめ

• コードを書く時間は仕事の一部。読む・調べる・聞く・書く・待つが大半。 「1行も書いていない日」に罪悪感を持たない
• ゼロから作らない。既存の改修が大半で、全体は理解できない
• 模範解答は存在しない。曖昧な依頼を具体化するところから仕事が始まる
• 「動いた」は終わりではない。レビュー・デプロイ・本番確認・運用まで
• 評価されるのは点数ではなく信頼。 一人で抱えることは評価されない。早く言うことが評価される
• 黙っているのが最も評価を下げる。7割で見せる
• あなたの1時間には値段がある。だからこそ「5分聞く」のが正しい
• 失敗は隠さない。責められるのはミスではなく、隠すこと
• レビューはコードへの指摘であって、人格への評価ではない
• 勉強は終わらない。そして土台が無いとマニュアルも読めない
• 何も知らないことには、一時的な価値がある。今しか出せない疑問を出す

参考資料

章末問題

次の章では、この違いを踏まえて日々どう行動するかを扱います。