両側から見てきた
システムエンジニアを40年やってきました。金融、保険、官公庁の基幹システム。名前を出せば誰でも知っているものもありますが、契約の関係で社名は書きません。
任される工程は現場ごとに違い、実装だけ、テストだけという時期もあったので、作る側と決める側の両方を経験しています。
上流工程のエンジニアは、一からコードを書く仕事ではありません。何を作るのかを決めて、それを別にいるプログラマに伝えて、上がってきたものを見る。これが仕事です。大きなシステムは分業でできているので、一人が受け持つのはその一部で、最初から最後まで通して見られることはあまりありません。
この仕事で身につくのは、書く技術とは別の二つです。ひとつは、曖昧なまま渡さないこと。決めきらずに投げれば、必ず違うものが返ってきます。もうひとつは、上がってきたものを疑うこと。手を抜かれた箇所、とくにテストが足りていない箇所は、独特のかたちで残ります。
この二つは、レガシーな世界の技能だと思われています。AIとは縁遠いと。
相手が人からAIに変わっても
実は逆でした。
何を作るのかを決めて、伝えて、上がってきたものを見る。相手が人からAIに変わっても、やることは変わりませんでした。
上流工程の仕事は、もともと特定の言語に縛られていません。だから道具が変わっても、覚え直す部分がそれほど多くない。この身軽さが、いま効いています。
一度あきらめて、また始めた
ずっと持ち越してきたものがあります。相場の値動きを、統計で予測できるかどうかを確かめるプログラムです。
きっかけは、友人からの相談でした。2000年の少し前です。システムエンジニアをやっていると話したら、こんなものはできないのか、と聞かれました。株価の並びを見て移動平均を出し、そのあと値がどう動いたかを確かめる。その程度の簡単なツールです。
作り始めたら、面白くなって止まらなくなりました。扱うデータはどんどん増えます。最初はExcelの行をそのままデータベース代わりにしていましたが、行数の上限にすぐぶつかりました。Accessに移し、それでも足りなくなって、最後はSQL Serverまで行きました。
処理はVBAで書いていました。当時すでにJavaもありましたが、一から覚えるより、手元で動かせるもので押し切る方を選びました。VBAはとにかく遅い。それでも時間さえかければ分析はできるはずだと考えて、一回まわすのに二週間かかる処理を流していました。
ある夏の日、冷房を切って会社に出ました。夜中に帰ってくると、パソコンから音がしていました。少し触ったら、煙が出て、そのまま壊れました。
そこで止めました。パソコンは遅く、熱に弱い。仕事の方も手一杯で、片手間で続けられるものではありませんでした。
それから何年も経って、Pythonが目に入りました。これなら書ける。ノートパソコンでも熱で壊れるようなことはない。データベースもSQL ServerやMySQLを使えば、あの頃とは比べものになりません。もう一度やれるのではないかと思いました。
試しに、あの二週間かかっていた処理を組み直してみました。二十分で終わりました。
統計学も、あらためて勉強し直しました。驚いたのは、あの頃に何も知らないまま「こうやってみよう」と決めていた手順に、ちゃんとした名前がついていたことです。自己流でたどり着いた場所に、すでに舗装された道が通っていました。
Pythonを覚え、データベースを調べ直し、人工知能も勉強しました。まだ生成AIが出る前です。ライブラリを読み、ニューラルネットワークの初歩を追いかけていました。
そこにChatGPT 3.5が出てきました。これはすごい、と思いました。出てすぐ、Pythonのコードを書かせる形に切り替えました。やっているうちに、相場の予測以外にもできることがあると分かってきて、そちらも調べ始めました。それが今の仕事になっています。
作る前に、外を調べる
いまの仕事でいちばん違うと感じるのは、調査です。これは昔と今の違いではありません。大規模な基幹システムの開発と、いま私が作っているようなシステムの違いです。大規模開発の現場は、今も同じやり方で動いています。
大きなシステムの中では、調査という作業はあまりありません。要件が決まったあとに調べるのは、膨大なプログラムと仕様書の中です。量は多いのですが、答えは必ずその中にあります。閉じた世界です。
いま私が作っているものは違います。何を作るかを決める前に、外を調べなければなりません。ひとつは、そのシステムが本当に必要とされているのか、というところ。もうひとつは、部品の方です。使えるデバイスがあるのか、そのデバイスにAPIはあるのか、どのソフトウェアと組み合わせられるのか。
いまのシステム作りは、その多くがすでにある部品を繋ぐ仕事になっています。裏を返せば、設計するのは繋ぎ目です。だとすると、部品を知らなければ繋ぎようがありません。適切な部品を選べるかどうかで、出来上がるものが決まります。
AIに聞けば何でも分かる、と言われます。半分は本当です。ただ、返ってくるのは聞いたことへの答えでしかありません。自分が本当に欲しいものを言葉にできているか。抜けなく聞けているか。ここが甘いと、もっともらしい答えで満足して終わります。私はいま、この調べ方そのものを型にする作業をしています。
要件を聞いたら、まず調べます。調査で思ったとおりのところにたどり着けていれば、そのあとはほとんど終わったようなものです。
動くものと、任せられるもの
AIを使えば誰でも書けるのではないか。そう思われるのは当然だと思います。そのとおりです。今は誰でも、動くものが作れます。ここを否定するつもりはありません。
ただ、動くものと、任せられるものは違います。
AIが書いたコードは、たいてい動きます。問題は、動いているように見えることの方です。例外のときに何が起きるか書かれていない。仕様の抜けを、抜けたまま実装している。テストがあっても、通ることが分かっている道しか通っていない。こういうものは、動いている間は誰にも分かりません。
私が40年やっていたのは、まさにそこを見る仕事でした。人が書いたものを受け取って、どこが危ないかを探す。相手がAIに変わっても、探す場所は変わりません。
渡す前の話もあります。曖昧なまま指示を出せば、違うものが返ってきます。これはAIも人も同じです。何を作るのかを決めきってから渡す。それだけで、やり直しが減ります。早く出せるのは、速く書いているからではありません。戻りが少ないからです。
AIを使えることは、もう強みではありません。前提です。差が出るのは、その前と後ろです。作らせる前に、使える部品を調べて選べるか。何を作るのかを決めきってから渡せるか。そして出てきたものを、動いているからよしとせずに、危ないところを探せるか。この三つだと思っています。