.png)
「いま、動くしかない」リプレイスを決めたタイミング
──最初のテーマは「『いま、動くしかない』決断のXデーをどう迎えたか」。皆さん、どういうときに判断して、どう説明して実行に移していったのでしょうか。
普川：モノタロウはもともとはフロントエンドもバックエンドも内製でバリバリ開発してきました。ですが、ビジネスの継続的な成長により、業務とシステムの複雑性が増加。モノリシックな基幹アプリケーションでは業務の変更要求に耐えられなくなりました。そこで2010年代中盤にパッケージシステムの導入を計画し実施しましたが、システムがあまりにも密結合で、依存関係もあり、導入が進まなかった。私がCTOになった時に、内製化しようという判断を行い、モノリシックなシステムから徐々にアプリケーションを切り出してモダナイゼーションを行っています。
樽石：そもそもリプレイスは決断して取り組んでも、完遂できないケースも多いです。
リプレイスは、ある程度の蓋然性があること、例えばリアーキテクトするならその専門家が入社するなど人材が揃っていれば、意思決定しやすいと思います。
イオンネクストも2019年設立の比較的新しい会社とはいえ、システムは突貫で作ったものが多いです。そのためリプレイスの必要性を感じていながらも、手をつけられずにいました。ですが今年2月に篠田が入社してリプレイスのメイン担当に就任。そしてもう一つ、リプレイスを決断できた背景にあったのは、生成AIの活用が進んできたこと。例えばシステムについてAIに聞くと、どんどんREADMEを作成してくれる。つまりシステムを丸裸にしてくれる。
長沢：当社の主力事業であるLIFULL HOME'Sは、不動産会社に物件を入稿してもらい、それをサイトのデータベースに登録、ユーザーが自分に合う物件を検索できるというシステムです。既存のデータベースのままだと、ビジネスのスピードが上がらないという状況に陥りました。そのようなリプレイスはビジネス要件が選考する部分が大きいですね。また、それ以外の面でも大規模なリファクタリングに関しては、ビジネス的な要件というよりは、開発生産性の改善、という側面が強いです。そのようなことができたのは、開発生産性を内部で計測していたことがポイントだったと思います。数値化したことで、非エンジニアからもリプレイスした方が良いのではという声が上がりました。
安井：今、私のチームではリフォーム店が使うシステムをリプレイスしているのですが、既存システムを運用しながら、機能ごとに新しいシステムに切り替えるという方法を採っています。ダブルでメンテナンスコストがかかっていますが、そういう方法が最良だと思いました。
リプレイスにおける生成AIの活用法
──2つ目のテーマ「技術負債のラビリンス 潜って初めて見えた真の敵」にいきましょう。技術負債のラビリンスは、AIの活用で大きく改善ができるとお考えでしょうか。
樽石：技術負債はいわば考古学のようなもの。ですが、AIを活用すると、人間では到底できないレベルのことまでサクサクやってくれる。これまでは技術負債を解消する作業はモチベーションが上がりませんでしたが、これからはAIの活用によって、真の敵を見つけ出すことも盛り上がり、あちこちの古いシステムがリプレイスされるのではと期待を感じています。
──とはいえ、生成AIを導入してリプレイスする事例はまだまだ少ないと思います。どんなところに適用できると思いますか。
普川：私たちが今、取り組んでいるものの一つは注文管理システムのリプレイス。VB（Visual Basic）で書かれていたため、エンジニアは誰もやりたがりませんでした。ですが、昨年、プロンプトでリプレイスするという課題に設定し直したところ、エンジニアが生き生きと取り組み始めた。そのときになるほどと思ったのは、無理矢理コードからコードに置き換えるプロンプトではなく、まずは設計書をつくるところから始めたこと。その際も「プログラムの構造はどうなっていますか」「インプットするデータはどうなっていますか」など、細かく分けたことで、そこそこの精度の設計書が出来ました。人間が一つずつ取り組むフェーズをプロンプトにわけて、「LangChain」などでつないでいく。そういうチャレンジをしたところ、工数を約3割削減できました。またこれができるならと、今までは触れたくなかったシステムのリプレイスへのモチベーションも高まったような気がします。
長沢：当社では今、OracleからPostgreSQLへの移行を行っています。そのSQLの書き換えに生成AIを活用するなどは、非常にわかりやすい例だと思います。
当社のサービスは20年以上続いており、ビジネス要件の追加などで、テーブルも継ぎ足されたものとなっています。それをキレイにするには、データの流れをゼロから考えて設計していく必要があります。ですが、それには時間がかかる。そこで今は一旦、データベースエンジンを変えるということをまずやる、と割り切って、取り組んでいるところです。移行のときにきれいな設計で作り直したくなる心理は非常にわかりますが、これが個人的に見えた真の敵でもあり、折り合いの付け所でもあるかなと思いました。
篠田：全体をキレイにするというのは、エンジニアなら一度は見る夢だと思います。ですが、それを一気にやろうとすると絶対失敗します。細かい問題が積み重なって、全体として大きな問題となっているので、隅から順に片付けていくのは得策だと思います。しかも今は生成AIで問題を調べることが容易にできます。生成AIの活用によって、リプレイス作業が楽しく出来るようになり、真の敵を倒すことも出来るのではと思います。
安井：リプレイスプロジェクトで、潜って初めて見えた真の敵とは見えない依存関係だと思います。ですが樽石さんが話しているようにAIで分析すると、見える化されるようになる。真の敵がAIによって可視化できるのは、大きなポイントだと思います。
樽石：よく暗黙知を形式知にしましょうと言われますが、暗黙知を有している本人は、他の人に伝えることにあまり興味がないから暗黙知のままなんです。ですが、AIで仕事をするようになると、暗黙知のままだとプロンプトにならないので、それが負債になる。つまりこれまで暗黙知で出てこなかったものが、プロンプト化することで、どんどん表に出てくる。そうすれば隠れていた地雷みたいなものが、目に見えるようになり、リプレイスもやりやすくなるのではと思います。
