19
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

学生エンジニア、10年目

19
Last updated at Posted at 2025-12-14

watnowアドベントカレンダー14日目担当のhoshiです。

watnowというのは立命館大学のアプリ開発サークルで、形式を変えながら10年以上続いています。また、私に関しても2016年に入学してから10年目となる今日まで経営学部の学生としてこの団体に所属しています。

10年という月日は、本来なら小学校を卒業して高校生になるほどの期間です。この間、私はスタートアップの現場や個人開発を通じて、技術トレンドの激流に揉まれ続けてきました。

この記事では、レンタルサーバーでjQueryを書いていた入学時から、LLMとフルマネージドサービスに全振りする現在までの変化を振り返りつつ、私たちがこれからどこに価値を見出すべきなのか、ひとつの考えを共有できればと思います。(一部に生成AIの文章を含みます)

1. 10年間の観測 — 「実装」の価値はどう変化したか

まず、個人的な体験をベースに、この10年で開発の景色がどう変わったかを整理してみます。

2016-2018:牧歌的な「実装」の時代

私がエンジニアとしてのキャリアをスタートさせたのはこの頃です。当時は、AWSに買収される前のCloud9が入口でした。
クラウドIDEという技術は当時進んだものでしたが、まだまだ環境構築で躓いてしまうという世相を反映したものでもあると思います。

  • 技術スタック: Ruby on Rails, jQuery, Bootstrap
  • インフラ: Heroku, AWS EC2, オンプレミス

この時代は、「Webサービスを作って公開できる」こと自体に大きな価値がありました。黒い画面でコマンドを叩き、サーバーを構築し、DBを繋ぐ。その一連の作業ができる学生は希少で、CRUD(読み書き)ができるアプリを作るだけで、周囲からは魔法使いのように扱われたものです。実装力そのものが、そのまま市場価値になる時代でした。

2019-2021:UXと効率化の過渡期

スマホネイティブ世代が中心となり、よりリッチな体験が求められるようになりました。私もこの頃、jQueryからモダンなフロントエンド開発へと軸足を移しました。

  • 技術スタック: React, Vue, TypeScript, Flutter
  • インフラ: Firebase, Netlify, Vercel

SPA(Single Page Application)が当たり前になり、モバイルアプリ開発もReact NativeやFlutterといったクロスプラットフォーム技術が台頭しました。まだReactの状態管理が貧弱でReduxやRecoilなんかを使っていました。FlutterのProviderはRiverpodとして現役ですね。「いかに効率よく、複雑なUIを管理するか」に腐心しました。同時に、mBaaSやPaaSの進化により、インフラ構築の難易度は劇的に下がり始めました。

2024-2025:AIによる実装のコモディティ化

そして現在です。Next.jsなどのフレームワークは成熟し、バックエンドはSupabaseなどのBaaSで完結することも増えました。何より、生成AIの存在は言うまでもありません。

  • 技術スタック: Next.js, Supabase, AI (LLM)

今や、自然言語で指示を出せば、数分でそこそこ動くアプリケーションの骨格が出来上がります。かつて私が数日かけてドキュメントを読み込み、エラーと格闘しながら習得した知識は、AIが一瞬で出力してくれます。「コードが書ける」「アプリが作れる」というスキルの市場価値は、限りなくゼロに近づきつつあると感じています。

歴史の話

実は僕が経験したこの潮流は、まさに昨今のITの流れでした。それまでブログやLPといった静的サイトが中心だったネットがスマートフォンの登場により進化し、ajaxやモバイルアプリによるリッチな表現を伴って劇的なユーザーの増加を経ることになりました。ここで起きたコンテンツの爆発は機械学習のための大量のデータを供給しました。並行して、ゲーム向けだったGPUがマイニングで目をつけられ需要が高まります。(2019年ぐらいにぼくも0.3BTCぐらい買いました。そのまま持ってれば今頃7~8倍でしたがFXで下手に売ってしまった。)
"Attention Is All You Need"という論文が発表されたのは2017年でしたが、大量のデータをGPUで並列学習して飛躍的に精度をあげるというLLMの実用化は、こうした背景で達成されました。我々の作るもの、消費するものが発展した果てに、初めて生成AIは実現しました。
Web2.0の歴史の証人になれたのはうれしいですね。

2. 学生エンジニアが直面する「正解のない問い」

実装の価値が暴落した今、私たちエンジニアには何が残るのでしょうか。少し昔の話を思い出して考えてみます。

学生スタートアップという環境は、基本的に孤独です。経験豊富なシニアエンジニアもいなければ、整備された研修制度もありません。そこにあるのは、常に不足しているリソースと、高い理想、プレッシャーだけです。

そんな環境で私が10年間やり続けてきた仕事は、「綺麗なコードを書くこと」ではありませんでした。実際に必要とされたのは、正解のない問いに対して、自分なりの答えを出し続けることでした。

  • この機能に、学習コストの高い新しい状態管理ライブラリを導入すべきか?
  • AWSの請求額を抑えるために、RDBをやめてNoSQLにするべきか?
  • 今はバグが出るリスクを承知で、スピード優先でリリースすべきか?

誰も「それでいいよ」とは言ってくれません。論理的思考と、断片的な情報をかき集めて、自信を持って震える手でデプロイを実行する。その結果に対する責任を自分で負う。

振り返れば、私がこの10年で養い、発揮したスキルは、プログラミング能力そのものではなく、この「不確実性の中で意思決定をする力」だったように思います。

3. なぜAIの「意思決定」は不十分化か

「意思決定もAIに任せる」というは当然の発想です。人間vs人工知能については色々な人が色々なことを言っているのでこの場で深堀りはしませんが、短く触れておきます。

  • AIには「問い」が作れない
    AIは「正しく問えば、正しく答える」ことはできます。しかし、私たちの現場にあるのは「正しい問い」ではありません。「なんとなく使いにくい」「急に遅くなった気がする」といった、解像度の低いノイズです。
    このノイズの中から、「データベースのインデックスが効いていないのではないか?」と仮説を立て、実装可能なレベルまで「問い」を精製するプロセス。これこそがエンジニアリングであり、AIには手が届かない領域です。

  • AIは「平均への回帰」を目指す
    現在のAI(大規模言語モデル)は、学習データに基づいて、確率的に最も「ありそうな」答えを出力します。これはつまり、世の中の平均的な正解(ベストプラクティス)に収束しようとする性質があるということです。
    しかし、実際の開発現場、特にスタートアップは常に例外の塊です。「予算はゼロだが、来週までにこの機能が必要」「技術的には非推奨だが、現在のユーザー層の特性上こうせざるを得ない」といった、平均から外れた制約条件だらけです。平均的な正解が、私たちの現場の正解とは限らないのです。

  • 人間には人間の正解を
    AIに入力できるコンテキスト(情報量)には限りがあります。しかし、私たち人間の頭の中には、言語化できない膨大なコンテキストが存在しています。
    チームメンバーの性格や現在のモチベーション、過去のプロジェクトでの失敗からくる「嫌な予感」、言葉にはならないユーザーの熱量や空気感。
    人間は、過去から現在に至るまでの経験や感情の変化といった情報を、現状のAIとは比べ物にならないほど蓄積しています。その「言語化できない文脈」を含めて、論理を超えた「納得解」を導き出せるのは、現時点ではまだ人間だけです。

なにより、正しい決定だったかどうかを決めるのは人間の社会です。論理や統計、学習が示した正解は、正解であっても社会にとって本物ではありません。

ただこれらは「現状は」というもので、いつかは本当に区別がつかないか、人工的な知能の方が秀でるようになるでしょう。しかし私たちが働く数十年ぐらいはまだ不十分なはずです。

4. これからのエンジニアの「あるべき姿」

技術の進化は止まりません。私たち学生エンジニアも、そのあり方をアップデートする必要があります。

「How(どう作るか)」はAIに譲り、「Why(なぜ選ぶか)」を握る

コードを書くという作業自体は、AIという優秀なパートナーに任せていくべきでしょう。シンタックスを覚えることの重要性は薄れました。

しかし、「なぜそのアーキテクチャを選ぶのか」「なぜその機能を『作らない』と判断するのか」という決定権だけは、手放すことができません。AIが出してきたコードが、自分たちのプロジェクトの文脈において本当に正しいのかを判断し、その結果に責任を持つ。それがエンジニアの本来の仕事です。

フレーバーテキスト

僕は内燃機関が大好きです。材料、機械、熱、化学、流体といった科学分野を複合した文明の結晶です。燃料を噴射するキャブレター、理想の混合比を作るバルブ、それらのタイミングを合わせるクランクシャフト、毎分数千の回転を生み出し、耐え抜くピストンやコンロッド、タイミングベルトを介した冷却、オイル供給、時にスーパーチャージャーと呼ばれるターボ、オルタネーターという名のただのモーターなどの駆動。これらの複雑で微妙な仕組みを安定して稼働させる奇跡のシステムがエンジンです。幅広く奥深い知識を、だれでも使えて人命まで預かる重要な道具に仕立て上げたのが工学、エンジニアリングです。(だからただの変圧器とアクチュエータに置き換えられるのはいささか残念です)
そこまでして何がやりたいのか。できるんだからやってみる。それが人の役に立つからうれしい、おもしろい、それこそがエンジニアではないでしょうか。そのおもしろさには長期的で揺るがない価値があります。たかだか数百年のテキストを学んで真似をするプログラムとはまだ数万年のリードがあります。おもしろさという期待値が高く説明不能な軸が私たちの強みです。

孤独な意思決定から逃げない

AIや組織のガイドラインに正解を求めたくなる瞬間は誰にでもあります。その方が楽だし、安心なので。けれども、誰も正解を知らない中で、自分で答えを決めるという経験こそが、エンジニアとしての足腰を強くします。
考えてください。あなたは選ぶ能力を期待され、実際に発揮することができます。名前だけのコーダーやLLMとはそこが違います。考えることができます。

おわりに

これからエンジニアを目指す方、あるいは今まさに学生エンジニアとして活動している方へ。

プログラミングという魔法は解けました。でもそれは、私たちが「コードを書く作業員」から解放され、向き合うべき「課題解決の本質」に集中できるようになったことを意味します。

Githubの草の数や、使えるフレームワークの数ではなく、「現実世界にどのような変化を起こす選択をしたか」。これからは、その一点で勝負していきましょう。

大学10年生のエンジニアより、自戒を込めて。

19
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?