【メルマガ】生成AIでシステム開発は本当に早くなる？(2025年04月08日)

システム開発における生成AIの活用。

そもそもシステムと親和性が高く、ITスキルが高い業界ということもあってか、
活用が広がっていると感じています。

そんな中、ぶっとんだ発想も出てきています。

イーロン・マスク率いるDOGEが6000万行ものCOBOLコードを含む社会保障局のシステムをコード生成AIでわずか数カ月の内に移行させようとしており危険性が指摘されている >>>

今回は、現時点におけるシステム開発と生成AIについて考えてみましょう。

生成AIの活用

最初はプログラミングコードの出力を中心に利用が始まりましたが、
いまや、システム開発プロジェクトの各工程に
活用の幅が広がっています。

弊社もコーディングを中心にシステム開発に活用しており、
そのスピードには驚いております。

その他の工程でどこまで活用できるのかは
適用できる機会がまだないため品質は不明ですが、
少しずつ活用できるようになっていくことでしょう。

COBOLシステムの刷新に生成AIを活用？

上記記事によると、6000万行以上のCOBOLコードをJavaなどに刷新するお話のようです。
通常は10年かかると見られる移行を数ヶ月で、と。

本当に実施するのかどうかも不明ですが、
感触としては「無理ゲー」です。

何が一番無理かというと、数ヶ月で、という部分ですね。

そう感じる理由は多すぎるので当メルマガでは割愛しますが、
もっとも大きいポイントは下記です。

とにかく、時間が不足しています。

テストや移行にかける時間が足りません。

10000歩ゆずって、一瞬でJavaのコードが生成できたとしましょう。
しかし、それが正しく動作するかは、テストが必要です。

テストを実施するためのコードも自動で生成できる？
できますが、そのテスト結果が、本当に使用する時の正しい結果と合っているかはコードでは判断できません。

例えば、Aという値が入ってきたら、Bと出力するコードがあります。
これがその通りに動いたよね、という確認はテストコードでできますが、
そもそも、Bと出力することが業務として間違えていたら、業務としてはバグですよね。
(設計バグですが、コードだけ見ていても設計バグは分かりません。)

また、既存のデータを新システムに移行する必要もありますし、
利用者の業務訓練といった時間も必要です。

そもそもコーディングに使う時間は、システム開発工程の一部でしかありません。

もう一つの問題、それは業務特性

アメリカの社会保障局のシステムがどこまでの品質が必要かは分かりません。
(普通に考えると、ミスは許されないシステムですが)

たとえば、給付金の支払額の桁がズレていたらどうなるでしょうか。

トライアンドエラーで修正すればよい業務システムではないでしょう。

SNSのような
「なんとなく動いていれば、処理結果が多少おかしくても誰も死なない」
みたいな特性のシステムであれば
トライアンドエラーは開発スピードやコストを考えても有効ですが、
社会保障システムはそうではないでしょう。

システムは、業務を行う上での一つの道具です。
その道具の特性に応じて、
どのように作るべきなのか、を考えていく必要があるでしょう。