NEW! スキル
生成AIが瞬時にコードを書き上げ、的確なドキュメントを生成する時代。エンジニアが積んできた「悩んで、調べて、書く」という鍛錬は、もはや無用に見えるかもしれない。
しかし、書籍『技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて』の著者であり、プログラマーとして20年近く活躍し続けてきた伊藤淳一さんは、同書の中で「自分の手で書く」ことへのこだわりを明かしている。
なぜあえて「自分の手」を動かす必要があるのか。AIに頼ることで、失われるものとは何か。AI時代におけるアウトプットの本質を、改めて問い直してみよう。
株式会社ソニックガーデン
伊藤淳一さん（@jnchito）
1977年生まれ、大阪府豊中市出身。SIer、外資系半導体メーカーの社内SEを経て、2012年ソニックガーデンに入社。保守性、拡張性の高いシンプルなコードを追求するプログラマーであり、プログラミングスクール「フィヨルドブートキャンプ」でメンターも務める。ブログやQiitaなどでプログラミング関連の記事を多数公開している。将来の夢はプログラマーをみんなの憧れの職業にすること。主な著書に『プロを目指す人のためのRuby入門』（技術評論社）、『技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて』（翔泳社）などがある
ーー伊藤さんは今も「技術記事は自分の手で書く」ことを大切にしているとか。生成AIを使うことがスタンダードとなりつつある中で、自ら書く姿勢を貫いている理由をお聞かせください。
私の個人的な考えとしては、「すでに記事を書くスキルが身に付いていて、自分なりのスタイルが確立されている人」であれば、生成AIを使っていいと思っています。これまでブログをたくさん書いてきて、自分で記事を書こうと思えばいくらでも書ける。その上で「執筆時間を短縮したいから生成AIを使う」と判断するなら、それはそれでアリです。
これはプログラミングでも同じことが言えます。私もコードを書く時は生成AIを使いますが、それは「いざとなれば自分で書けるけど、生成AIにやらせた方が早いから」です。なので、仮にシステム障害が起こってAIコーディングツールが使えなくなったとしても、「じゃあ自分でやるか」と仕事を進められます。
つまり技術記事にしろコーディングにしろ、自分ができる以上のことをAIにやらせるのは良くない。これが私の基本的な考え方です。
ーーそういった考え方をするようになったのはなぜでしょう？
アウトプットとは自分の名前とセットで世に出るもので、いわば名刺代わりになるからです。
技術記事も本来は「私はこれができる」「自分はこの技術について理解している」という証明になるもの。ですが、生成AIの力を借りて自分の実力以上のものをアウトプットしたら、それは誇大広告になってしまいます。
それに、生成AIが書いた記事には個性がないんですよね。文章が流暢すぎて、どことなく「ツルツル」している感じがする。最初から最後までスーッと読めるのですが、どこにも引っ掛かりがないから印象に残らないんです。一方、人間が書く文章には、その人ならではの個性やクセがにじみ出ます。その引っかかりこそが記事の面白さにつながるんです。
議事録やマニュアルのように、自分の名前が出ないドキュメントの作成であれば生成AIは効果的でしょう。でもせっかく名前を出して書くなら、一人一人の個性と結びつくものを書いた方が読者の記憶に残る記事になるはずです。
ーーですが、「書く」というプロセスには少なからず労力が伴いますよね。
そうですね。でも、「書くために調べる」ことにも意味があると思うんですよ。
よく知っているつもりの技術も、いざ文章で説明しようとすると「これってどういうことだっけ？」と疑問点にぶつかることがあります。そんな時は、自分で調べてから記事を書きますよね。
実は理解があやふやだった部分についてしっかりと調査し、技術を深掘りするプロセスを踏むことで、自分の知識も深まっていくんです。これは生成AIに調べさせた内容をコピペするだけでは得られないメリットですね。
ーーとはいえ、現在は記事の執筆からコーディングまで、あらゆる「書く作業」が生成AIに代替されつつあります。人間が「書く力」を身に付ける意義や価値も変わっていくのでは？
マシン語やアセンブラでプログラムを書くことがなくなったのと同じように、自然言語で指示を出すだけでコーディングが成り立つようになるだろう、という意見が巷で広まりつつありますし、おそらく同じようなことが記事の執筆に対しても言えるのでしょう。ですが、私自身はそうは思いません。
技術者として生きていく以上、文字通り「技術（＝スキル）」を身に付けておく必要がありますし、中でも「書く力」は、技術者として持っておくべきコアスキルです。
先ほどお話ししたように、自分がきちんと理解していないことは正確に言語化できません。つまり、コーディングを生成AIにやらせるとしても、その裏側にある仕組みや背景を理解し、アーキテクチャの構造をイメージできていないと、的確な指示が出せないんです。
それに、生成AIに指示を出すプロンプトだって文章です。プロンプトを書くスキルがないとまったく使えないものが生成されてしまい、あとで痛い目を見ることになりますよ。
ーー痛い目を見る、ですか。
スキルが身に付いていない人は、生成AIのアウトプットを見ても「良い・悪い」「使える・使えない」が判断できません。
自分でコードを書いてきた人なら、生成AIが書いたコードを見たときに、「これは違和感がある」「これは良からぬ結果を招くんじゃないか」といったセンサーが働きますよね。でもプログラミング経験が浅い人は、出力されたコードを見てもよく分からず、「AIが書いたのだから大丈夫だろう」と考えてそのまま取り込んでしまう。その結果、誤りが含まれていてミスやトラブルにつながってしまった……なんて場面が容易に想像できます。
つまり「自分でやろうと思えばできる」と言えるだけのスキルが前提になければ、生成AIを十分に使いこなすことはできないのです。
私自身、生成AIに自分のスキル以上のことを頼んで痛い目を見た経験はありますしね。
ーーどんな「痛い目」を見たのですか？
私は個人事業主としても活動しているので簿記関連の作業が必要になるのですが、処理の仕方がよく分からなくて。なので、ChatGPTに質問して返ってきた答えを、そのまま会計ソフトに入力したんです。
ところが出来上がった決算書を見ると、極端に大きいマイナスの数値が出てしまって、明らかに内容がおかしい。税理士に相談したところ、ChatGPTの回答がまったく異なっていたことが発覚しました。
つまり私の簿記レベルの低さが原因で、生成AIに正しく状況を説明できなかったことに加え、回答の良し悪しも判断できなかったわけです。これはまさに、新人エンジニアが生成AIを使ってプログラミングをしたときに失敗する流れと同じだなと痛感しました。
ーー冒頭の話にあったように、基本的な知識がある人が生成AIを使うからこそ、より高いパフォーマンスを出せるということですね。
こんなことを言うと「時代遅れだ」と笑われるかもしれませんが、私は日常の全てをAIに委ね、徹底的に効率化を突き詰めるようなスタイルをとるつもりはないんですよ。効率化の波に身を任せすぎると、膨大な情報に飲み込まれて思考がオーバーフローを起こしてしまう気がするんです。
それに、「これはやるべきか否か」「この判断は正しいか」という最後のジャッジには責任が伴うので、そこはまだAIに渡せない。だとすると、自分が受け止められるボリュームを見極めていくことも重要なんじゃないかなと思います。
ーー生成AIはアウトプットだけでなくインプットでも有用ですよね。特に最近の若手エンジニアは、学びの初期段階からAIを使いこなす「AIネイティブ世代」です。「人から学ぶこと」の意義も変わっていくのでしょうか？
AIでインプットできるからといって、若手エンジニアが人から学ばずに独り立ちできるかといえば、そんなことはありません。AIがカバーできるのは、あくまでエンジニアの仕事の一部ですから。
例えば、私が所属するソニックガーデンは受託開発を手掛けているので、お客さまとの会話が欠かせません。相手のビジネスや業務を理解した上で要件を定義したり、現在の負荷状況を踏まえてシステムのアーキテクチャを設計したり、コストを踏まえて運用方針を決定したり……考えるべきことが山ほどあります。
少なくとも現時点では、その全てをAIで完結させることはできないし、人間でなければできない仕事がたくさんある。だから若手エンジニアが成長するためには、仕事で欠かせないスキルや知識を持った先輩エンジニアから学ぶ必要がまだまだあるはずです。
ーーとはいえ、AIネイティブ世代にとって、人に教えを請うこと自体が心理的に高いハードルになっているようにも感じます。
質問先が人ではなく生成AIになったというのは、あくまでも一要素だと思いますよ。「相手の時間を奪ってしまうかも」「こんなことを聞いてバカだと思われたら嫌だ」といった理由で、若手エンジニアが先輩に質問しづらいと思う感情は昔からあったはずです。
加えてここ数年は働き方の多様化が進んで、人と人がリアルで接点を持つ機会が減っていることも影響しているかもしれません。ソニックガーデンもリモートワークが基本なので、当初は新人育成もリモートで行う想定でした。
ただ、結果的にリモートでは育成が難しいと感じ、「徒弟制度」という仕組みを導入したんです。ベテランエンジニアが「親方」、若手エンジニアが「弟子」となって、オフィスで一緒に仕事をしながら若手を育成しています。
ーーAIで学んだり、リモートワークで育成したりする場合とどういった違いが？
新人と対面で接していると、「今の話は理解できなかったみたいだな」「『分かりました』って言っているけど、本当に大丈夫かな」といった違和感に気付きやすくなるので、相手の理解度が把握できるんです。
そんな時は「ここは本当に分かった？」「こんな時はどうすればいいと思う？」ともう一歩踏み込んだ突っ込みを入れてみる。すると、相手がどこを理解できていないのかが明らかになり、より詳しく教えることができます。
新人としても、先輩から直接教わった方が良い意味で厳しく教えてもらえるはずです。生成AIはどんな内容でも、基本的には肯定的ですよね。でも、時としてそれは自分のためになりません。あやふやな部分は指摘してもらってこそ、理解は深まるものです。
ーー自分が本当に理解できているのか、それとも「分かったつもり」になっているだけなのかは、第三者に指摘してもらわないと自覚しづらいかもしれないですね。
生成AIは便利ですし、人間の代わりにやってくれることも増えましたが、そうは言っても本質的には「道具が一つ増えただけ」なんですよね。
以前は情報を調べるのにGoogleという道具を使っていたのが、今はAIという道具が加わった。これまでコードを書くのに自分の手を動かしていたのが、今はAIというツールが加わった。それは新しい要素ではあるけれど、あくまで道具でしかない。道具を使うのは人間だし、AIという道具ではできないこともまだまだあります。
だからAI時代であろうとも、人からしか学べないことは存在し続けるし、人から学ぶ価値は変わらない。私はそう思っています。
技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて
ITエンジニアの間では、自己成長やスキルアップのために「日々のアウトプットが重要」と言われます。本書は、代表的なアウトプットである「技術記事の執筆」に焦点を当て、「読まれる」「伝わる」技術記事を書くための考え方と実践法を体系的に解説します。
記事構成の組み立て方から、タイトル・見出しのテクニック、専門的な内容をわかりやすく伝える表現技術まで。QiitaやZenn、企業ブログはもちろん、ITエンジニアの日常のテキストコミュニケーションにも応用できる一冊です。
15年以上にわたりアウトプットの最前線を走り続けてきた著者が、長年の経験から培った執筆ノウハウを惜しみなく全公開します。
＞＞詳しくはこちら
取材・文／塚田有香 編集／秋元 祐香里（編集部）
タグ
