生みの苦しみ

ITmediaの記事から、一週間人力コーディングを禁止して生成AIのコード生成で開発してみた顛末の記事。規模的には、エンジニア3人だし、一週間という期間もそんなに長いわけではないので、結果的に成果半減は分かるとして、しかしそこから得られた「経験値」「経験知」は成功だったという話。

この記事を読んで思いだしたのが、1990年代に入りバブルが弾けたこともあって開発費が大きく削減される状態になり、それまでほぼ100%社内開発・製造だった製品を、OEM/ODMや外注化することでコストを下げて、でも品質や機能・性能・デザインは落とさずに、以前と同等以上の製品開発・製造が必須となった時の事を思いだします。「生成AI=委託先ODM/OEM」と思えば、この記事に書かれているような生成AIを初めて使って苦労する部分(経験値の無い部分は生成できない、経験値のあるところは信用できる)や、何度か学習させる(開発サイクルを回す)事で、製品の品質や製造の歩留まりが向上していくというのは、当時苦労したところでもあります。生成AIにコマンドプロンプトを投げて目的のコード生成を実行するように、OEM/ODMに対してこちらからの詳細仕様を投げて、製品(サンプル)を受け取るというのは似ている気がします。当然一回で期待通りのものが出てくるわけも無く、何度も問題点や違いを指摘して収束させる作業が必要でした。運が良ければ、その経験値が次の製品に引き継がれて、二回、三回と製品を回していくうちに、相手側の技術力や品質も上がるんだけれど、そうやって実力を付けたエンジニアは、どんどん待遇の良い他社(=ライバル会社)へ移籍したりするからある意味始末が悪い。

ただ、生成AIは学習した効果・内容は保存されて参照されるから、ある意味学習させるやり甲斐みたいなものはあると思います。OEM/ODMの場合は、相手も人間だから、だんだんと慣れてくると「手を抜く(=コストダウン)」事を考えてきて、同じ性能の安い部品に勝手に切り替えるなんて日常茶飯事で、担当エンジニアをベテランから若手に変えて、こちらを教育係のつもりで再教育させたり(再教育しないと製品品質に関わるので、こちらとしても仕方なくやるんですが...)、こちらの開発で得た技術や仕組みなんかを、しれっと別の他社向け製品に取り入れていたり、まぁいろいろありました。そう言うドロドロしたところは生成AIにはまだ無いと思うけれど、例えば最初からそういう技術収集目的を隠して、でも高性能で低コストの生成AIが公開されたら、みんな喜んで利用してでも裏でどんどん別の「学習」をしている事に気がつかないかも。今の生成AIだって、どういう状態か利用者は分からないわけですからね。少し前に中国発のDeepSeekが話題(問題?)になったけれど、実際はどうなんだろうか。

その1990年代にOEM/ODMに走った企業で失敗した企業の多くは、自社の開発リソースをOEM/ODMに全振りしたところだと思います。幸いにも弊社は、コアな部分は自社開発・製造を維持して、技術的優位性は担保した上でOEM/ODMを有効活用する様なプロセスを何年か掛けて構築したので、結構相手には嫌がられていた記憶があります(笑)。今回の生成AIだけのコード生成にしても、それを利用するエンジニア側に相手以上のスキルや知識が無いとそのまま受け入れて失敗するわけで、成果物を鵜呑みにせずに、どこを注意すれば良いのかとか何を確認すれば問題が防げるとか、そういう部分が重要。そう言う意味では、これまではコーディングするというレベルの視点から、それらを俯瞰して全体を掌握しつつ細部も認識して評価出来る、俯瞰できるような一つ上のレベルの視点が必要なわけで、それがこれからの時代に要求されるスキルであることは確実。便利な物が生まれれば楽になる部分はあるけれど、それよりもより高度な要求に応えられる実力が要求されていく時代になることも覚悟しないと。