SEが生成AIと出会う時

いきなりタイトルの補足をするのも野暮だが、SEは「ソフトウェアエンジニア」ということである。「システムエンジニア」も含むが、「プログラマー」も含み、ソフトウェアを構築する仕事に関わる皆さんという意味である。生成AIあるいはLLMに出会ったのはもう数年前のことだ。もちろん衝撃的であり、もはや仕事の進め方が大きく変わってしまったことは、世間にもよく知られている。ソフトウェアをどのような手順で構築するのかについては、古い時代のウォーターフォール型や、その後台頭してきたアジャイル開発などがよく知られているとはいえ、今までは結構ハンドクラフトだった。分析から始めて、設計し、実装し、テストすることを繰り返す。天才的な閃きもごく稀に功を奏するが、通常は地味な作業の連続であり、仕事をする上では、どれくらいの時間で完成できるのかを予測することが大きな課題となる。そんな枠内にいる筆者の実態について、SEではない人に向けて紹介したい。

AIが当たり前となった現在からはるか昔、自分としては理想的な開発とはどういうものかを考えたことがある。自身でフレームワーク、つまりシステム構築の中心的な素材を作っていることもあり、そこを言語化したかった。そして思いついたのは、「やりたいことを言えば、そのシステムが出来上がる」というようなものだ。スタートレックなどのSFドラマの場面を想像してのことだ。『物質の濃度を変えたときにエンジンの効率がどうなるかをグラフに出してくれ』と言ったら、コンピューターがそういうグラフをサクッと出す。これが、1つの開発プロセスの理想なのかもしれない。もうお分かりの通り、今やそういうことができるようになったと言っても過言ではない。自身のフレームワークでも、「住所録を作ってくれ」という指示を出すだけで、住所録のアプリケーションが作れるようなプロンプトを用意する、といった対処をしている。つまり、単なる指示だけでは少々心許ないので、追加命令も与えるということである。AI時代にフィットするための開発は、別の側面にも展開する必要が出てきている。

しかしだ。はっきり言って、AIで盛り上がる現在、うまくいったという話と、うまくいかないというアンチ的な話の、結局のところどちらかしか出てこない。その渦中にいる私たちは、その間を行き来している。プログラムをAIが勝手に作ってくれるという話はよく出ているのだが、それがどんなものかを、小さな例、つまりその雰囲気がわかる程度に作ったコードを示して、AI時代のプログラミングがどんな様子かわかる実例を紹介しよう。以下はJavaScriptの例で、変数にデータを入れている。記述はないが、その後に表示されることを想定している。金額を「円」付きで表示するのだが、ある項目は「千円」単位にする必要がある。そこで、単位を文字列として与えようとしている（リスト1）。そして、「千円」までをタイプすると、2つの変数の値を自動的に1000で割るコードが入る（リスト2）、という具合だ。「/=」はちょっと難しいが、a = a / 1000は、a /= 1000と記述できる。つまり、キータイプした「千円」という文言から、その近辺で使っている値の計算が必要であると推測して、コードを作ってくれるのである。おっと、変数定義がconstだったら代入できないからletにしないといけないところも指摘してくれる。ちなみに、実際には一方は不要だったりして、この後に修正は必要なのだが、根幹となる「1000で割る」というコードは自動生成されたと言える。もちろん、このプログラムで「千円」は初出である。

注：
・const 再代入ができない読み取り専用の変数を宣言する
・let 再代入可能な変数を宣言する

という感じで、それなりのヒントがあれば勝手にプログラミングができる雰囲気はわかってもらえたと思う。ところが、勝手にやりすぎる場合もある。文字列の配列を定義する必要があったので、「const structures = ['M構造',」とまでは手打ちしたのだが、勝手に「const structures = ['M構造', 'L構造', 'S構造'];」と補完してしまった。ここで入力したかったのは、「['M構造', 'T構造', 'H構造']」なのだが、ちなみに火災保険関連の分類である。なんじゃコラと思ったら、M、L、Sとは洋服などのサイズではないか。「Mと来たらL、Sだろう」と勝手に決めてしまう、AIのやり過ぎ感を味わっていただけただろうか。

このようなAIを使い始めて、結局のところ何が変わったのだろうか？　それは「疲れ方が変わった」という言い方で言い切れると思われる。AI以前だと、少ない資料を必死に読んで情報を得て、試行錯誤を繰り返しながら、なんとか完成に持ち込むのが普通だった。そういう方法で、自身のスキルをアップデートしながら開発を進める。よって、時間がかかる作業をテンションを上げてやらないといけなく、体力的に疲れていた。しかし、今はやり方が変わった。私自身、学習して適用するということをしなくてもすみ、AIがそれをやってくれる。私は、当初の「問題の提示」と、それをどういうふうに解決したいかという「ゴールの提示」を行うだけでよい。それは体力仕事ではなくなったが、一方で、確認をきちんとやらないと、斜め上の方向にコードを変えてしまうこともある。つまり、体力仕事ではなく、確認仕事であり、さらに一般的な意味では管理仕事になったということだ。確認仕事はもちろんそれなりに疲れるが、体力仕事のようなヘトヘトになる感じとはちょっと違う。

昔ながらの体力仕事的なことも、場合によっては必要だ。まだ、すべてをAIによって解決できるわけではないし、できるとしても、思った結果が得られない時には、少ない情報からスタートしないといけないこともある。AIが勝手にプログラムを作るとなれば「プログラマー不要論」がまかり通るのだが、そろそろリタイアかというような年齢の筆者にとっては、体力仕事が減る分AIによってプログラマー寿命は伸びると感じている。「仕事を奪う」どころか、かえって仕事は増えるのではないかと強く感じるところだ。