机の上に、小さなSIが現れた——ChatGPT Workで開発の値段が違って見えた
仕事の値段は、作業量だけで決まっているように見えるが、実際にはその仕事を誰と、どんな順番で、どこまで分けて進めるかによって、静かに形を変えている。
何人もの専門家が必要だと思っていた流れが、ある日ひとつの画面の中でつながって見えたとき、私は便利さより先に、これまで当然だった仕事の境界線が薄くなる感覚を覚えた。
速く作れることよりも気になったのは、その先で、私たちは誰に仕事を頼み、どこまで自分で確かめ、どの瞬間に専門家を呼ぶようになるのかということである。
画面の向こうに、何人かいる
システム開発の仕事は、コードを書くことだけではない。顧客の曖昧な言葉を聞く人がいて、それを要求として整理する人がいて、仕様へ落とし、設計し、プログラムを書き、正しく動くか確かめる人がいる。
私もシステムエンジニアとして、長いあいだその流れの中にいた。だから、生成AIがコードを書くこと自体には、もうそれほど大きな驚きは感じていない。
ところがChatGPT Workを使っているうちに、あるとき見え方が変わった。
業務コンサルタントがいる。SEがいる。プログラマーがいて、テスターがいて、その後ろにPMまでいる。もちろん本当に人間が並んでいるわけではないが、仕事の流れとして眺めると、そう考えたほうが自然だった。
AIを1人の優秀なアシスタントとして見るより、小さなSIチームとして見る。
そう考えた瞬間、ChatGPT Workで何を試せばいいのかが変わった。
一言の要求が、仕事になっていく
実験の題材は、あえて小さくした。
「工事実績CSVを、会社別・工種別に集計し、案件数と金額合計を出したい」
現場では、この程度の曖昧な言葉から仕事が始まることは珍しくない。しかし、その一言をそのままPythonへ渡せば、システムができるわけではない。
案件IDは必要なのか。空欄はどう扱うのか。金額欄に文字が入ったらどうするのか。同じ案件が二重登録されていたら、1件と数えるのか2件と数えるのか。
プログラムを書く前に、決めなければならないことがある。
そこで最初は正常なデータだけを扱うBaselineを作り、必要な列と集計条件を決めた。その仕様をもとにWorkにPythonを書かせ、同時にテスト用CSVと期待する集計結果も用意させた。
ここまでは、まだ「AIがコードを書いた」という話でしかない。
私が見たかったのは、その先だった。
PASSの文字で、手が止まった
生成されたPythonを、そのままChatGPT Workの中で実行する。出力された集計結果と、事前に決めておいた期待値を比較するテストまで走らせた。
結果はPASSだった。
画面を見ながら、私は少し手が止まった。
コードが書けたことではなく、仕事がひと回りしたことに驚いた。
要求を聞く。仕様へ落とす。テストデータを作る。コードを書く。実行する。そして、結果が正しいかを確かめる。
以前なら、その途中には何人かの人間がいて、いくつかのExcelや仕様書があり、メールがあり、打ち合わせがあった。工程ごとに担当者へ仕事が渡され、そのたびに文脈も少しずつ渡し直されていた。
それが、ひとつの画面と、ひとつの文脈の中でつながっている。
生成AIによってプログラミングが速くなるという話とは、少し違う。
開発工程そのものが、小さく折り畳まれ始めている。
私には、そう見えた。
AIに渡しても、判断は残しておく
ここまでできると、次は全部AIに任せたくなる。
要求を理解し、仕様を決め、コードを書き、テストまでできるのであれば、そのまま最後まで走らせればいい。技術的には、そんな方向へ進んでいくのだと思う。
けれど私は、BaselineのテストがPASSしたところで一度止めたい。
次へ進むのか。仕様を変更するのか。それとも、そもそも作るものを考え直すのか。そこだけは、人間が画面を見て決める。
AIから人間へ戻し、人間が判断し、再びAIへ渡す。
Human in the Loopという言葉にすると少し大げさに聞こえるが、昔のシステム開発でも普通にあったことである。工程の節目で、誰かが「これで行く」と決めていた。
むしろAIが多くの工程を引き受けるほど、その判断は重くなる。
次に扱うのは、きれいなCSVではない。
会社名がない。金額欄に文字が入っている。同じ案件が2度登録されている。マイナス金額がある。「設備」「設備工事」「設備工事業」が同じ列に並んでいる。
実際の仕事は、だいたいこちら側にある。
AIが気を利かせて勝手に補正すれば、一見すると便利である。しかし、何を異常とし、何を許容するかは、その会社が積み重ねてきた業務ルールそのものでもある。
除外するのか。補正するのか。処理を止めるのか。
そこまでAIに決めさせるつもりはない。
仕事は渡しても、判断までは渡さない。
これが、小さなAIチームを率いる側の仕事になる。
見積書の向こう側が、違って見える
15年間、雇われ社長をしていた頃、システム開発の見積書を何度も見た。
利用する側から金額だけを眺めれば、「この程度の機能に、なぜこれだけかかるのだろう」と感じることもある。しかし開発する側へ回れば、その理由はよく分かる。
話を聞く。要求を整理する。仕様書を書く。認識を合わせる。設計する。修正する。テストする。報告する。
コードの周りに、大量の仕事がある。
だから私は、SI会社の価格が高すぎるという話をしたいわけではない。むしろ、これまで人が担っていた工程の一部を、人間1人とAIのチームで回せるようになったとき、開発コストの作られ方そのものが変わるのではないかと思っている。
特に変化が大きいのは、小さなPoCである。
「この業務は自動化できそうだから、まず試作品を作ってみたい」
これまでは、この段階からSI会社へ相談し、要件を説明し、打ち合わせをして、見積もりを取り、発注することも多かった。
しかしChatGPT Workの中で、要求整理から仕様化、Python生成、実行、テストまで回せるなら、小さなPoCについては、最初から外部へ発注しないという選択肢が生まれる。
もちろん、製品版のシステムを作る話とは違う。
セキュリティ、運用、保守、性能、可用性、権限管理、既存システムとの連携まで考えれば、専門家が必要な仕事は残る。むしろ本番環境になればなるほど、その重要性は増していく。
ただし、専門家を呼ぶ場所が後ろへ動く。
「こんなものを作れませんか」と相談するところからではなく、「ここまで自分たちで試しました。ここから先を一緒に考えてください」という地点から始まる。
もしそうなれば、企業が払う開発費だけでなく、SI会社が価値を出す場所も変わっていく。
1人で作るより、1人で率いる
ソロプレーナーになってから、1人で仕事をする時間が増えた。
けれど最近は、不思議なことに、1人で仕事をしているという感覚が少し薄れている。生成AIを使えば1人で何でもできる、という意味ではない。
自分ですべてをやる必要がなくなってきたのである。
要求を整理する役割を渡す。仕様を書く役割を渡す。Pythonを書く役割を渡す。テストする役割を渡す。
そして私は、その途中で立ち止まる。
「そこは違う」「それで行こう」「ここはまだ決めない」
1人SIerになるのではない。
1人の人間が、小さなAIのSIチームを率いる。
こちらのほうが、今の感覚には近い。
AIによって軽くなる仕事は、これからさらに増えていくだろう。以前なら専門家に頼まなければ始められなかった仕事を、自分の机の上で試せる場面も増えていく。
それでも、最後に何を作るのかを決め、その結果を引き受ける仕事だけは、妙に軽くならない。
むしろAIが仕事をしてくれるほど、人間には判断だけが濃く残っていく。
私は、その重さまでAIへ渡したいわけではないのだと思う。
小さなPoCを自分の机の上で作れるようになったとき、最初に変わるのはプログラミングの方法ではない。
「誰に頼むか」ではなく、「どこまで自分たちで進んでから頼むか」。
