生成 AI 時代の新人さん向け「自分のコードに責任を持てる力」をつけるために
Back to Top
はじめに
#今どきの新人さんは、どのように技術について調べたり、学んだりしているでしょうか。Web 検索すれば、公式ドキュメント、数多くの技術ブログ（もちろん当サイト含む）などの記事がヒットしますし、X (Twitter) や YouTube にも有益な情報が溢れています。GitHub には多くの OSS が公開されており、簡単に試すことができます。Udemy や O'Reilly などのオンライン学習プラットフォームで効率よく学べるコースもたくさんあります。そしてなんといっても生成 AI。開発ツールにも AI が常駐してコードを書いてくれたり、エラー原因を教えてくれたりします。
今の若い人は情報リテラシーが高いため、これら情報源との付き合い方に長けており、効率よく知識を獲得しているという方も多いことでしょう。
しかし、次のようなことも起こりがちではないでしょうか？
- あまり頑張らなくても動くものができてしまうので、原理を理解する意欲が削がれる
- エラーが発生したとき、Web や AI からの情報で場当たり的に対応してしまい、根本原因を追及せずに終わってしまう
- いざ深く知りたいとなった時、どこからどう調べればいいのか迷う
言ってみれば「情報が溢れ AI がアシストしてくれる時代ならではの学びの難しさ」があるのではないでしょうか。
この記事では、そんな時代の新人さん向けに、技術を身につける上で意識するとよい（のではと筆者が思っている）ことやマインドセットについてお伝えできればと思います。
筆者が新人だった当時、企業ではインターネットもまだあまり普及しておらず、OS にインストールされたコマンドのマニュアル (man コマンドで読むやつ)、開発ツール付属の（印刷された）マニュアル、紙の書籍や雑誌などが主たる情報源でした。
付箋だらけの分厚いマニュアル片手にコードを書いたりエラーを調べたりしてました。コードレビューも印刷してペン入れしてたりしました（当時の PC の画面は非常に狭かったので視認性が低かったのです）。
いつの時代だよと思われるかもしれませんが、筆者自身も今の状況と比べると隔世の感があります。そもそも情報が限られていたため、その限られた情報を元に自分で考え、試すしかありませんでした。逆に言うとシステムを開発するための前提・知識が、現在よりも少なくて済む素朴な時代でもあったと思います。
「動けばヨシ」の限界
#新人に限らず「とにかくググって当てはまるコードスニペットを見つけて動けばヨシ」なタイプの人は一定数います。 技術ブログや Stack Overflow のコードスニペットをコピペして「動いたのでヨシ！」。でも、ちょっと仕様が変わったり、ライブラリのバージョンが違ったりするとすぐまたハマる。そのたびにまた調べて、なんとなく解決するのですが、根本的な理解がないから毎回同じようなことでつまずく。「なぜこうなるのか？」と一歩踏み込んで考える習慣があればと思います。
生成 AI を使っても動くまでの時間が短縮されるだけで、人間側に起こっていることは変わらない気がします。
生成 AI も最近は裏で Web 検索してくれますが、出始めの頃はモデル作成時点の情報を元にするため、生成されるコードが廃止された API を使っていたりして動かない、なんてことがよくありましたね。
まず公式ドキュメントを読もう
#かつて、「公式ドキュメントなんてあんまり役立たない」と思っていた時期がありました。実際、黎明期の OSS はドキュメントが更新されない・不親切・英語オンリーということも多く、検索で日本語情報を探す方が有益という時代が続いていました。
でも今は違います。大抵の OSS の公式ドキュメントはとても丁寧に書かれており、最も正確で信頼できる一次情報になっています。30分もあれば Quick Start でインストールや Hello World を済ませることができます。各言語へのローカライズも当たり前のようにされていますし、英語しかなくても Google 翻訳があります。
何か調べたいとき、「まず公式を見る」という習慣がつくと、理解の深さが変わってきます。バージョンの違いや設定の前提も明確に書いてあるので、検索よりも早く正確にたどり着けることも多いです。
公式には「仕様」「前提」「制限」がちゃんと書いてあります。たとえば、
- 「このオプションは v2.0 以降でしか使えない」
- 「この関数は Promise を返すので await や then で受ける必要がある」
など、ソフトウェア提供側の正確な情報を得ることができるのです。
公式ドキュメントという信頼できる一次情報を「読む力」を身につけることで次のような副次的効果もあります。
- 表面的なエラー対応だけで終わらせることなく、本質的な修正ができる
- 次からは同じことに躓かなくなる（再現力と予測力がつく）
- 新技術への対応力も高まる（ドキュメントを読み解ける人は吸収が早い）
OSS 普及以前、IBM / Microsoft / Sun Microsystems / Oracle などの企業のプロプラエタリなソフトウェア・開発ツールを使うのが一般的でした。
OSS を使って開発するのが一般化してきたのは、Linux や PostgreSQL などが商用の Unix OS や DBMS 並みの性能と信頼性を獲得してからでした。Apache HTTP Server や Java が業務で使われるようになって、徐々に業務で OSS の利用が増えてきました。それに伴い、OSS のドキュメントの重要性が認識され始めました。
現在の OSS は開発者のコミュニティを形成することが重要であり、チュートリアルや親切なドキュメントの提供などは、開発者体験の上で必須になっています。
エラーが出たらまずスタックトレースを読んでみよう
#エラーが出たとき、すぐに AI や検索に頼らず、まずはスタックトレースをじっくり読んでみることをお勧めします。一見とっつきにくいですが、問題解決のためのヒントが詰まってます。
「どのファイルの何行目で、どの関数から呼ばれて、何が原因で落ちたのか」これがちゃんと読めるようになると、エラー原因に自分でたどり着けるようになります。まずは、以下のような情報を読み取るように頑張ってみましょう。
- どの行で、どの関数で、どのモジュールが失敗してるか
- NullPointerException（いわゆるヌルポ）、型エラーなどの原因
例えば JavaScript (Node.js) でこんなエラーが出たとします。
TypeError: Cannot read property 'x' of undefined
at doSomething (/src/utils.js:25:13)
at main (/src/index.js:10:5)
この場合、どこで何が起きているかが明確に書かれています。
- 何が起きたか → undefined なオブジェクトのプロパティ
xを読もうとした - どこで起きたか → utils.js の25行目
- その関数はどこから呼ばれていたか → index.js の10行目から
この情報を読み解いて、自分のコードと照らし合わせるだけで、Web 検索 や AI に頼らなくてもも解決できることはたくさんあります。どこまでが自分のコードで、どこからが利用しているライブラリのエラーか、について識別できることも重要です。
Web 検索や AI への質問にしても、表面のエラーメッセージにだけ着目すると全く文脈の違うケースも多く出てきて解決に辿り着くのに時間がかかります。
最初はあまり分からなくても、だんだん慣れて読み方や発生原因も分かるようになっていきます。「エラーメッセージに重要情報が含まれているんだな」と思うところから始めましょう。
スタックトレースを読めるようになってくると、自分がコードを書くときも、障害解析しやすいエラーメッセージを書いたり、エラーが追いやすいコードを書くといったプラクティスに繋がっていきます。これは、保守しやすいコードを書く上でとても重要です。
課題を解決する基礎体力をつけよう
#プログラミングは課題を解決する手段であり、その過程も課題解決の連鎖です。まず開発環境を構築するという課題を解決しなければなりません。コードを書くのも、エラーを直すのも、「課題がある → どう解決するか」を考えることの繰り返しです[1]。
なので、コードを書く前に「なぜそうするのか」を考え、エラーが出たら「どこで何が起きてるのか」を突き止めるため一度立ち止まって考えてみる習慣をつけるとよいと思います。
課題を解決する力は、すぐに身につくものではありません。少しずつでいいので、「エラーメッセージを読む」「公式ドキュメントを読む」「まず自分で考える」という小さな習慣を続けてみてください。そして、自力で課題を解決できたという体験が積み重なれば、やがて、どんな環境でも、どんな技術でも「なんとかできそう」ていう自信につながると思います。その自信と経験は AI に頼っても頼らなくても大丈夫なエンジニアへの基礎となるでしょう。
AI もどんどん使おう。使う時に気をつけること
#この記事は AI を封印して全部自分で解決しようと主張しているのではありません。筆者自身、ChatGPT や GitHub Copilotを使っています。便利だし、手が早くなるのは確かです。
でも、「生成されたコードを吟味せずにそのまま使う」ことが常態化すると、成長のチャンスを逃してしまうリスクがあると思います。
AI の答えを参考にしつつ、
- 「なぜこうなるのか？」
- 「エラーの意味は？」
- 「公式ドキュメントにはどう書いてある？」
という視点を忘れないこと。この“考えながら使う習慣”があると、AI はむしろ学びを加速してくれるツールになります。実際、AI によって技術に触れて物を作り始めるまでのリードタイムが非常に短くなるため、新しい技術にも臆することなく挑戦できるようになっているのは素晴らしいことです。
おわりに
#ここまで読んで「そんなのもうとっくにやってるよ。」と思ったあなたは大丈夫です。このまま進んでいってください。
筆者が若い時、次のようなコンピュータ格言を読んで、なるほどと感心したことがあります。
コンパイラはコンパイルしてくれるし、リンカはリンクしてくれる。しかし、デバッガはデバッグしてくれない。
デバッガを使えばコードをステップ実行して、コードの振る舞いや変数の値などは観測できます。だけど、デバッグそのものは結局作った人間がやらなければならないということですね。これは生成 AI 時代の現在も変わりません。(あ、もしかして、若い人はリンカとか言われても存在を意識してなくてピンとこないかも。まあ、そこは気にしなくていいです。)
これは昨今の以下のような状況にも通じるものがあると思います。
生成AIはコードを生成してくれるし、エラーの原因も調べてくれる。しかし生成したコードの正しさは保証してくれない。
ソフトウェアエンジニアは、システムやサービスを利用してくれる人々のためにコードを書き、報酬を得る職業です。そのため、最終的には自分の書くコードに責任を持つ必要があります。では責任を持つとはどういうことか。それは自分の書いたコードがどのような作りで、どのように動くかを自分の言葉で説明でき、仕様変更や不具合があった場合に自分で修正できるということです[2]。
「責任ある AI」という言葉もありますが、あれは AI サービス提供側にも責任を求める話であって、エンジニアである我々が AI に責任転嫁する話ではありません。
今のところ、生成 AI がいかに発展していっても、コードの正しさを検証して保証する存在にはならないのではないかと思います。なので、我々人間がそれを行う必要があるのです。
まあ、エンジニアなんて AI があろうがなかろうが一生学び続ける職業なので、どんな時代が来ても自分の書くコードに責任を持てるように精進していきましょう。新人の皆さんの成長に期待しています。
