生成AIの登場によって、非エンジニアでも業務システムを作れるようになり、社内でもさまざまな開発が進んでいる。
これまでなら、アイデアがあってもエンジニアへの相談や開発工数の確保が必要だった。今は生成AIに指示すれば、データを登録・検索・一覧表示する画面を短時間で作ることができる。この変化によって、身近な業務課題を自分たちで解決しやすくなった。
一方で、「作れるようになったこと」と「作るべきであること」は分けて考える必要がある。
特に気をつけたいのが、「業務を改善・自動化すること」と「専用UIを新しく作ること」を同じものとして捉えてしまうことだ。
例えば、集計作業に時間がかかっている場合、本当に必要なのは「集計結果を表示する新しいシステム」だろうか。
データの取得や計算だけをプログラムで自動化し、結果は既存のスプレッドシートに出力すれば十分かもしれない。特定の条件を検知してSlackに通知するだけで、目的を達成できることもある。
そもそも、入力項目や業務フローを整理すれば、その作業自体をなくせる可能性もある。
画面は、ユーザーとシステムの接点であり、価値を届けるための手段である。しかし、画面を作ること自体が価値になるわけではない。解決したい課題によっては、画面を持たない自動処理や、既存ツールのUIを活用する方が、利用者にとって自然で効率的なこともある。
例えば、次のような状況では、専用UIを作り込まない方が合理的なことがある。
スプレッドシートであれば、自由にメモを書いたり、その場で列を増やしたりできる。業務の変化を探っている段階では、この柔軟性が役立つ。
一方、専用UIを作ると、入力方法や業務フローを標準化できる代わりに、想定していない使い方が難しくなる。
操作方法が変わることにより発生する学習コストや、変更のたびに仕様の検討やテスト・改修が必要になり、画面を持ち続けるコストも発生する。
反対に、次のような状況では、専用UIを作る価値が大きくなる。
この場合のUIは、単なる入力画面ではない。業務のルールを適切に伝え、次に行うべき操作を案内し、ミスを防ぎながら目的の達成を支援する役割を持つ。
生成AIによって、画面やプログラムを作るまでの時間は大きく短縮された。しかし、システムを安全に使い続けるためのコストまで、すべてなくなったわけではない。
問い合わせや要望への対応、データの整合性、権限管理、セキュリティ、バックアップ、障害対応、外部サービスの仕様変更など、システムは作ったあとも管理する必要がある。
生成AIを使えば、動くものは早く作れる。だからこそ、「ひとまず作ってみる」と「業務で継続的に使える状態にする」の間には差があることを意識したい。
生成AIを使った業務改善では、次の内容を考えることが重要だと思う。
生成AIによって開発のハードルが下がったことは、大きな可能性だと思う。ただし、その可能性を活かすために必要なのは、あらゆる業務をシステムに置き換えることではない。
プログラムによる自動化、既存ツールの活用、専用UIの開発を分けて捉え、課題に合った最小限の方法を選ぶ。
「作れるから作る」のではなく、「作ることで、本当に誰かの仕事が良くなるのか」を考える。生成AI時代のシステム開発では、実装する力と同じくらい、作らないものを判断する力が重要になっている。