あのときの“悔しさ”を忘れない。新ツール開発に挑んだ理由

――AIモダナイ解析ツールを開発するに至った背景には、加藤さんの前職でのご経験が大きく影響していると伺いました。

加藤：はい。前職は大手SIerの金融事業部に29年勤めていたのですが、30年ものの巨大なメインフレームシステムを担当したことがあるんです。

それを刷新するための計画を立てるという任務だったのですが、結局、断念してしまいました。

というのも、システムの仕様がまったくわからなかったんです。グローバルシステムで世界中のユーザーにヒアリングするわけにもいかず、仕様を知る有識者も日本にほとんどいない。

ブラックボックスを前に、どうやって仕様を解き明かせばいいのか、現実的な手法にたどり着くことができませんでした。あのときの苦い悔しさは、いまでも鮮明に覚えています。

「あのとき、このツールがあれば…」と、いまでも思いますね。

――その経験がいまにつながっているんですね。

加藤：それに加えて、日本のSI業界が抱える構造的な問題も何とかしたかった。前職時代、「現行仕様踏襲」という言葉はまさに鬼門でした。

お客様のいまのシステムと同じ動きをするものを新しくつくりましょう、というプロジェクトですね。何百億円という巨額の費用を投じても、結局システムができあがらないなんてこともザラにあって。

私はそういったプロジェクトの火消し役を任されることが多く、疲弊してしまう仲間をたくさん見てきました。100億円規模のプロジェクトともなると、その人数は大きくなる。

そんな働き方は絶対におかしい。このツールで現行仕様の可視化という難題に挑むことには、そうしたエンジニアの働き方を変えたいという思いも強く込められています。

不可能を可能にする“発明”。ソースコードを「変数単位」で解き明かすAI解析ツールの核心

――AIモダナイ解析ツールについて伺いたいのですが、SHIFTではすでに「AIドキュメントリバース」も展開しています。違いはどんな点でしょうか？

加藤：ドキュメント生成にフォーカスして開発されたのが、「AIドキュメントリバース」です。

どちらもソースコードを対象にするのは共通ですが、AIドキュメントリバースで解析するのは、あくまでプログラムの「内部仕様」。

一方で、モダナイゼーションにおいては、システムに何を入れたら何が出てくるのかという「外部仕様」についても把握する必要があります。

お客様からさまざまな要望をいただくなかでツールを拡張していた過程で、内部仕様の解析にまつわるある“発明”が偶然生まれたんです。

これは私ではなく、いっしょに開発しているエンジニアのおかげなのですが。

――発明、ですか？

加藤：ええ。彼が試行錯誤のなかで見つけ出したアイデアを共有してもらったとき、「これなら、あの外部仕様の解析ができるんじゃないか！？」とふたりで非常に盛り上がりました。

それが2024年の秋頃ですね。そこから本格的に始まったのが、いまの「AIモダナイゼーション解析」プロジェクトです。

エンジニアの彼はソースコードレベルのアーキテクトとして非常に優秀で、言語解析の論文を読み漁ったり、つねに新しい技術に挑戦したりと、探究心と開発力が本当にすごい。

彼がいなければ、このツールは絶対に生まれませんでした。

――その“発明”の核心について、もう少しくわしく教えていただけますか？

加藤：簡単にいうと、ソースコードを「データ項目単位」、つまり変数単位で解析するところがポイントです。

これまで世にあるツールは、テーブル単位での解析です。それだと概念的なつながりはわかりますが、詳細はわかりません。

メインフレームのシステムには帳票が何百種類もあって、「この帳票に出ている数字が、一体どう計算されたのかさっぱりわからない」というケースが山ほどあるんです。

テーブル単位の解析では、その謎は解けません。

しかし、私たちのツールは「画面で入力したこの項目が、この処理を経て、データベースのこの項目に入る」というデータの流れを、変数一つひとつのレベルで追跡できます。

ここまで徹底的にやるのは、おそらく他社にはない。

先ほどのエンジニアの卓越した専門性と情熱があってこそ実現できたものだと思います。

――ちなみに、ツール名に「AI」とありますが、AIはどの部分で活用されているのでしょうか。

加藤：膨大なソースコードを読み解き、変数単位で関連性を紐づけて構造化されたデータベースをつくりあげる。この作業は、頑張れば人手とプログラムでも組めるかもしれません。

ただ、その“頑張り”にかかる時間とコストが半端ではない。そこをLLMに任せることで、劇的に高速化しているんです。

――つまり、人手では事実上不可能だった、巨大すぎるシステムのソースコードの構造化を、AIの力で可能にした、というイメージでしょうか。

加藤：その通りです。ただ、AIに丸投げしているわけではありません。

「どういうデータベース構造をつくれば外部仕様が解き明かせるか」という設計思想、つまり“発明”の部分が我々の核であり、その特許もいままさに申請しようと動いています。

レガシー刷新に革命を。マイクロサービス化と「超高速ウォーターフォール」が拓く未来

――変数単位でデータの流れが可視化できると、具体的にどんないいことがあるのでしょうか。

加藤：まず、巨大でモノリシックなシステムを「マイクロサービス化」、つまり機能ごとに小さく分割できるようになります。

例えば100億円規模のプロジェクトは我々のような比較的小さな組織では一気に受注できませんが、このツールで解析して機能を切り出し、「まずはこの5億円の部分から刷新しましょう」と提案できれば、我々でもデリバリーできる。

――なるほど。巨大なブラックボックスを解体して、扱いやすいサイズに切り分けるわけですね。

加藤：はい。本音をいうと、当初の目的の一つがそこでした。これをフックにして自分たちで開発を主導できるSI案件を獲得したかった。

それが、事業成長だけでなく、エンジニアにとっての働きがいのある組織づくりという観点においても必要だと感じたからです。

――そのマイクロサービス化された部分を、今度はどうやって刷新していくのですか？

加藤：この解析ツールで出力した情報を使えば、理論上はAIを使って動くものを自動生成できるはずだと考えています。いまSHIFTではDevinを使った開発プロセスの構築を進めています。

将来的にはお客様からソースコードをお預かりして解析し、その2週間後にはリニューアルしたシステムのデモをお見せすることもできるようになるかもしれません。

お客様はきっと、びっくりされると思いますよ（笑）

――本来数ヶ月かかっても、というものが2週間で見れたら驚かれるでしょうね。ところでウォーターフォール開発は「つくったはいいが、使えないものが完成した」といった課題から、アジャイル開発が主流になったという流れがあるかと思います。その点はいかがでしょうか？

加藤：実は、私たちがやろうとしている開発手法は、完全なウォーターフォールなんです。ただ、ものすごくはやいだけ。

アジャイル開発は、スピーディーに改善を繰り返せる反面、担当者が変わったりするうちに全体像がわからなくなり、結局スパゲッティ化・ブラックボックス化してしまうリスクもあります。

実際にそういう現場を見てきました。

しかし、我々の手法なら、最初に仕様をがっちり固め、ドキュメントもすべて残しながら、アジャイル並みのスピードで開発できる。

ウォーターフォールの課題だった「スピードの遅さ」と、アジャイルの課題である「ブラックボックス化」の両方を克服できる、新しい開発の形だと考えています。

――この革新的な取り組みは、SHIFTだったからこそ実現できた、という側面はありますか？

加藤：採用の決裁権をもっていたこともあり、前述のエンジニアのようなすばらしい方を迎え入れることができたのは、本当に幸運なことでした。

一般的にはツール開発前にビジネスプランや投資回収計画を立てて、何度も決裁を仰いで…そんなやり方では、こんな突飛なアイデアは実現できません。

この開発においては、私たちに大きな裁量が与えられていて、自分たちの判断で進めることができたんです。

与えられた裁量と、卓越した才能をもつエンジニアとの出会い。この両方が揃ったのは、SHIFTならではだったと思います。

エンジニアが主役の世界へ。ツールに込めた、日本のITを変えるという“本音”

――お話を伺っていると、加藤さんの根底にはつねに「エンジニア」の存在があるように感じます。

加藤：そうですね。モダンな開発をやりたいと思って入社してきた若手が、古い言語の保守案件ばかりやっている状況にはしたくないんです。

リビルドであれば、我々が技術選定をして、最新技術を使った開発にみんなで携われる。

エンジニアが「つまらない仕事」ではなく、「モダンで楽しい仕事」をする環境をつくりたい。それが開発の最大の原動力です。

――冒頭にもありましたが、エンジニアの働き方そのものを変えていきたい、と。

加藤：はい。いまのIT業界は労働集約型で、品質も悪くなりがちです。

皮肉なことに、その品質の悪さが我々SHIFTのテスト事業の成り立ちにつながったわけですが、私はエンジニアがもっとスマートに、創造的な仕事に集中できるようにしたいんです。

このツールが、お客様にとってもITへの価値を考え直すきっかけになれば、これほどうれしいことはありません。

――本日はありがとうございました！

（※本記事の内容および取材対象者の所属は、取材当時のものです）