AIで動くものが作れても、実務は別ゲーだった¶
対象:これから長期インターンに挑戦したい人、IT系新入生
TL;DR(先に結論)¶
- AIで動くものが作れても、実務は別ゲー(10聞いて1も分からんは普通に起きる)
- 伸びたのは技術だけじゃなくて、責任感 / コミュニケーション / レビュー耐性
- 逆に 責任感 さえあれば他の要素は勝手に伸びまくる
- 最初はやっぱりしんどい。
- チーム開発がエンジニアとしての成長を加速させる
自己紹介¶
神戸電子専門学校のITエキスパート学科に通っている学生です(現在4年)。
開発アルバイトをしていました。
- 期間:2025/2 〜 2026/3
- 稼働:週3〜5(15:30〜18:30)長期休みは 9:30〜18:30で出勤
- 開始当時:AIを使って動くアプリは作れるけど、実装の中身は正直よく分かってない / Webの仕組みも全然
どうやって入ったか¶
きっかけは、学校に求人が来ていたことでした。
自分はデジタルワークス(学校の制作発表イベント)に出ていたので、その成果物を武器にコンタクトを取りました。
入った時のマインドとしては、実務入ったら自分のためになるだろ。学校の中では優秀なほうやし、実務でも活躍できるでしょ!
当時は生成AIが流行り出した頃で生成AIで綺麗なアプリを作れることで実力があると勘違いしていた学生でした。
選考フローはこんな感じです。
- 人事面談
- 技術面談
当時は分からなかったけど、面接でお世話になった社員の方とお話ししていて思った当時の採用のポイントは、 おそらく技術力というより 人間性 と 吸収する熱意 です。
学生は伸び代が前提なので、「伸びそう」「一緒に働きやすそう」がめちゃくちゃ見られてる?と感じました。
入って最初に食らった現実:10聞いて1も分からない¶
最初に衝撃だったのは、タスクの説明を受けた瞬間に、普通に脳がフリーズすることです。
「こういうタスクやってね」って言われて、頷くんですけど、心の中はこう。
え、今の単語なに? これ調べなきゃ… いや待って、そもそも何をゴールにしたらいい?
用語を調べても情報量が多すぎて、数分前に聞いた話が抜けていく。
「何言ってたっけ」と「全然知らなすぎる」が多すぎて落ち込みましたし、全然通用しませんでした。
AIで動くものが作れると、ちょっと「自分いけるかも」って思うじゃないですか。
でも実務は、理解して、共有して、責任を持って積み上げる世界でした。 ただ、AIを使ってなんちゃってアプリを作り上げれるだけではダメなんです。
それでも続けられた理由:メンタルの天秤¶
最初の頃はずっと天秤にかけてました。
- 迷惑かけても学びのために吸収してやり切る
- 迷惑かけすぎてるから辞める、自分って役に立たない…
迷惑かけても自分のために吸収しまくるんだ!という気持ちで前者が勝ち切りました。
(ここは運も良くて、人事の方や拠点の偉い方と話しやすく、信頼関係を作れたのが大きかったです)
出社しての流れ、そして質問¶
自分の出社した時のルーティンはだいたいこれでした。
- 連絡ツールを開く
- タスクチケットメンションを確認
- チケットがなければ、上長にメンション or 近くの社員に聞いてチケットをもらう
- チケットを読んで、分からない点があれば質問
- 作業 → 詰まったら質問or分報チャンネルで呟く → 作業
「分報チャンネル」についてはこちら
「1日で実装してレビューまで出す」みたいな日は少なめで、1週間かけて進めることも普通にあります。
分からないことまみれだから積極的に質問したいんですけど、何がわかっていないのか分からないので、質問できない状態になることが多かったですね。
そこで助かるのが、
時々、上司の方が今どんな感じ?っていうので進捗を報告するのですが、これがありがたかったんです。
というのも、自分の今理解していることを未熟ながらも吐き出すことで何がわかっていなさそうで、何の考慮が漏れているのかを勝手に汲み取って、適切にアドバイスがもらえるんですよね。
今思えば、上司の方が上手に汲み取ってくれるので、もっと積極的に「質問あるんですけど」って言って雑アウトプットをしとけば良かったのかなと後悔しています。
どんなことを中でこなしていたのか¶
- 機能開発
- 新機能の技術的調査
- バグ対応、調査
- CI/CD
- データ活用のための見える化
- などなど
やったことの例:
- ある画面をフロント〜バックまで一気通貫で実装(DBは既存のものを利用)
- 難しかったこと:主要機能だったので、なる早で実装しないといけなかった
- Renovateでライブラリ自動アップデートのCI/CD整備
- 難しかったこと:社内で採用例が少なく、手探り(ドキュメントを読んで自走)
- Metabase + DuckDBでジョブ時間などを集計して可視化
- 難しかったこと:要件の認識合わせ(データの加工フローとデータの可視化など)
レビュー:目的と背景まで教えてくれる¶
実務で一番ありがたかったのが、レビューです。
PRを出すと、ただ「ここ直して」で終わらず、
- こう書くと読みやすい
- こうすると可読性が上がる
- 結果として保守しやすくなって、理解コストが下がる
みたいに 目的と背景 までセットで説明してくれました。
例えば単純なロジックでも「三項演算子などで見通しをよくすると読みやすいよ」みたいなやつ。
これ、学生の制作だと「動いたらOK」になりがちなんですけど、実務は「未来の誰かが読む」が前提なので、視点が変わります。
リーダブルコード - O'Reilly Japanを読むのおすすめです
やらかし2選¶
実務に入ったら誰でもやらかしエピソードを持っているのではないでしょうか。私のやらかし2選について紹介します。
- テストデータの名前文字列を少し遊び心を入れたものにしてしまった。
- 詳しくはこちら
- 流石に「う◯こ」は入れてませんが、「じゅげむ」などを入れようとした記憶があります。
- PRを無言でマージしてしまった。
PRの無言マージについては 大事故ではなかったですが、「危ないよ」と理由込みで注意をもらいました。
そこからは以下のことを守っています。
- 危ない変更は Draft PR にしてマージできない状態にする
- 通常は承認2人をもらってからマージする
長期インターンを目指す学生へ:最初の一歩は“とにかく参加”でいい¶
伝えたいのはこれです。
「何が分からないかすら分からない」状態から始まるのが普通です。
だから、最初の一歩は綺麗じゃなくていい。 分からないからこそ長期インターンなどの実務の世界に飛び込んでみてほしいです!
そして長期インターンなどをする前に、 We部でも他のコミュニティでもいいので、とにかく一回、チーム開発での輪に入ってみてほしいです。 学校のカリキュラム内でのチーム制作はワンマンになることが多く、熱量ある人たちと一緒にやるのをお勧めします。
まとめ¶
- 実務は別ゲー(10聞いて1も分からんは普通にある)
- しんどいけど、責任感さえあれば全部成長できる
- 実務は経験してみないと分からない