共通機能は基盤に、独自要件はAIに
矢野氏がまず挙げたのが、開発効率と品質の両立という意義である。認証・認可や権限管理、ワークフローといった、業種を問わず必要とされる共通機能は開発基盤に任せ、AIは付加価値を生み出す部分に使うべきだと述べた。AIは確率的に次の文字を選び出す仕組みであるため、同じ機能を毎回書かせると出力される実装が揺らぎ、品質が安定しないという。一方、個別の業界や案件固有のロジック・画面については、関係者の合意形成に使うプロトタイプも活用しながらAIでブラッシュアップしていくのが望ましいとした。
2つ目の意義は、開発基盤の枠組みがシステムの一貫性と保守性を担保するという点である。枠組みがない状態でAIに積み木のようにコードを積み上げさせると、一点ものとしては見た目の整った画面ができても、少し手を加えただけで画面の一部が動かなくなるといった不具合が生じかねない。認証・認可の処理も単体で完結するものではなく、リクエストを受けてからロジックを経て応答を返すまでの一連の流れに組み込まれている。矢野氏は、基盤が担う処理とAIが作り込む処理をうまく融合させ、基盤の枠組みの中をAIが高速に埋めていく形が望ましいと説明した。
3つ目の意義は費用対効果である。AI駆動開発であっても、本番運用に求められる品質を満たすには、設計・実装・テストという工程は省略できない。従量課金の下でこれらすべてをAIに担わせればコストは膨らむ。速く作れる一方でコストがかさむというトレードオフが生じるため、既存で活用できるものは活用し、活用できない部分だけをAIに作らせるほうが、コストと速度の両方を最適化できるというのが矢野氏の見解である。
製品選定は「家の購入」に似ている
開発基盤の意義を踏まえたうえで、矢野氏は続けて、数ある製品の中から自社に合ったものをどう選べばいいのかという論点に移った。ローコードツールやAI駆動開発をうたう製品は数多く存在し、一見しただけでは違いが分かりにくい。矢野氏は、そうした状況で製品の設計思想を知ることが選定の助けになると述べた。
製品選定は住宅の購入によく似ているという。建売住宅を買えば早く安く住めるが自由度は低く、土地から設計まで自分で決める注文住宅は自由度が高い分、時間とコストがかかる。矢野氏自身も中古物件を購入してフルリノベーションした経験を踏まえ、間取りは固定で内装だけ選べるセミオーダーのような選択肢もあると説明した。ソフトウェアの世界でこの対比に当たるのが、建売住宅のように標準機能の範囲内で要件を実現するFit to Standardと、注文住宅のように業務に合わせて作り込むMade to Orderである。そして、SaaSの活用からフルスクラッチまでの選択肢はカテゴリーとして分断されているのではなく、コストと自由度のグラデーションとして捉えるべきだとした。
市場にあるローコードツールや開発基盤をこのグラデーションの中で捉えると、製品ごとに設計思想が異なり、位置づけも様々である。矢野氏は代表的な製品を例に挙げながら、非エンジニアの現場部門が自ら業務改善アプリを作れることを重視したもの、ビジュアル開発で業務アプリを高速に構築することに強みを持つもの、営業支援・顧客管理を核にエコシステムで業務を広くカバーするもの、オープンソースでバックエンドを即座に立ち上げられるものなど、その設計思想の違いを紹介した。
そのうえで矢野氏が紹介したのが、電通総研が提供するiPLAssである。iPLAssはフルスクラッチと同等の自由度を保持しつつ、業種を問わず必要となる共通機能をノーコード・ローコードで実現するMade to Order寄りの設計思想を持つという。住宅で言えば、セミオーダー住宅のような形だ。向いているユースケースは大規模かつカスタマイズ重視の業務システムであり、この設計思想がエンタープライズの現場でどのように評価されているのか、矢野氏は3つの観点から説明を続けた。
