Cpkツールは、最初から気持ちよく使えなかった
Cpkの計算・学習ツールを作ったとき、最初の依頼はかなり具体的に書いていました。
「Cpkツールのページ、いまひとつ気持ちよくない。スクロールしないと使えない。スクロールなしで、ある程度全体が見えて使えるようにしたい。」
最初のプロトタイプを操作したときのフィードバック
ページを開いたらすぐにツールと結果が見えること。PCでは入力と結果を2列にすること。グラフを表示すること。文字の大きさやサンプルデータも指定していました。
それでも、実際にできた画面を触ったときの感想は、「いまひとつ気持ちよくない」でした。
「ページを開いたら結果が見える」と文章で指定することと、自分が気持ちよく使えることは、同じではありませんでした。
画面を見ないうちは「見やすくしたい」「使いやすくしたい」としか言えなかった感覚が、動くものを触ると具体的になります。文字はこの大きさでよいか。条件、グラフ、計算結果を一つの画面で見られるか。結果を確認するたびにスクロールしなくてよいか。いま見ている数値とグラフの関係がすぐに分かるか。
AIでプロトタイプを作る価値は、最初のコードが速くできることだけではありません。実物を見ることで、自分の要望を自分で見つけられることにあります。
画面を見るまで、分からなかったこと
これまでは、業務を改善したい利用者が、コードを書ける人へ要望を伝えていました。
| 言葉だけで伝えると | プロトタイプを間に置くと |
|---|---|
| 使いやすくしてほしい | 結果を見るたびにスクロールしない配置へ変える |
| 見やすくしてほしい | 条件、グラフ、結果を一画面で確認できるようにする |
| 流れが分かりにくい | 操作順と画面上のStep表示を一致させる |
| 説明を分かりやすくしてほしい | 条件を動かすと結果の意味が分かる体験へ変える |
利用者の頭の中には「こんなものが欲しい」というイメージがあります。しかし、それを言葉だけで漏れなく伝えるのは難しい。開発者は質問を重ね、利用場面や困りごとを一つずつ聞き、画面や機能へ変換していきます。
このやりとりは、今後も必要です。ただ、AIによって会話の始め方は変わると思っています。
利用者は、「こんなものを作りたい」とAIへ相談し、完全ではなくても、ある程度動くものを作れるようになりました。コードを書けなくても、入力欄と結果画面があり、ボタンを押すと何かが変わるところまで形にできることがあります。
開発者側も同じです。長い要件定義書を説明してから反応を待つのではなく、まず粗いプロトタイプを見せられます。
「こんなのできるんですけど、あなたのイメージに合っていますか？」という会話を、言葉だけではなく、実際に触れるものを間に置いて始められます。
Cpkツールは、計算機から学習ツールへ変わった
Cpkツールは、見た目を整えただけではありません。プロトタイプを触ったことで、ツールの目的まで変わりました。
「サンプルデータの標準偏差や平均を自由に動かして、結果がどう変わるかインタラクティブに見られたら、学習のためにもいいと思う。」
計算機から学習ツールへ方向が変わったときのアイデア
最初は、ブラウザでCp・Cpkを計算し、工程能力を確認できるツールを考えていました。しかし、実務で計算するだけなら、JMPなどの専用ツールを使うこともあります。
画面を見ながら考えているうちに、平均や標準偏差をスライダーで動かし、結果の変化を見られるようにしたいというアイデアが出ました。
平均を規格の中心からずらしたら、Cpkはどう変わるのか。ばらつきを大きくしたら、ヒストグラムと数値はどう変わるのか。それを動かしながら見られれば、数式を読むだけでは分かりにくいCpとCpkの違いを体感できます。
こうして、単なる計算機だった試作品が、工程能力を動かしながら学ぶツールへ変わっていきました。
これは、最初の仕様をAIが正確に実装しただけでは起きなかった変化です。まず動くものがあり、自分で触り、「自分なら本当にこれを使うか」と考えたから、本当に欲しかった機能が見えてきました。
DOEツールでは、触るたびに次の疑問が出た
DOE（実験計画法）の学習ツールでも、同じことが起きました。
「今の説明を、聞かなくても画面上で分かるようにしてほしい。ただ説明を並べるだけではなく、動かしたら自然と理解できるようにしたい。」
DOEツールの説明方法を見直したときのフィードバック
作り始めた理由は、かなり個人的なものでした。以前に学んだ内容を忘れていたので、自分がもう一度理解するためのツールが欲しかったのです。
最初のプロトタイプには、実験順序や時間による変化への注意が文章で書かれていました。しかし、説明を読んだだけでは、実務で何が起きるのかがよく分かりませんでした。
「時間ドリフトとは何か」と質問したあと、文章を追加してもらうだけでは足りないと感じました。説明を並べるのではなく、操作したら自然と理解できるようにしたいと考えました。
そこから、反復データを実務に近い表で見せる、ANOVAの結果まで順番に触れる、F値だけでなくp値を見る、SS、MS、dfという略語の意味も画面内で理解できるようにする、といった要望が増えていきました。
画面の流れにも問題がありました。「Step 3」と書いてあるのにStep 1と2が見えない。「基礎」「実務に近づける」というタブ名では、何が違うのか分かりにくい。これらも、実際の画面を見るまで気づかなかったことです。
さらに、2因子2水準の基本だけでなく、完全実施要因計画と直交表の違いまで学べる発展編が加わりました。
最初から、ここまで詳細な要件を考えていたわけではありません。試作品を触るたびに、自分が分かっていないところが見つかり、それが次の要件になりました。
要件定義が不要になったのではない
AIでプロトタイプを作れるようになっても、要件定義やヒアリングが不要になるわけではありません。
むしろCpkとDOEの制作では、試作品ができたあとに要件が増えています。最初の依頼が間違っていたというより、触って初めて答えられる問いがあったからです。
この画面を毎日使いたいか。どの情報を同時に見たいか。どの言葉で迷うか。計算できるだけでよいのか、それとも判断の仕方まで学びたいのか。
AIは、こうした問いへの答えを自動で決めてくれません。ただ、問いを早く表面へ出すための試作品は作ってくれます。
要件定義が消えたのではなく、要件を見つける方法が変わった。私はそう感じています。
今回確認した制作履歴では、CpkとDOEのどちらも、同じ日に複数回の試作と修正を行っていました。ただし、ヒアリング時間や開発期間が何割短くなるかは測っていません。効果は、題材、利用者、データ、組織のルールによって変わります。
AIで作ったプロトタイプを、そのまま本番にしない
プロトタイプが速く作れることと、本番で安全に使えることは別です。
英国政府のサービス設計ガイドでは、プロトタイプをアイデアの探索、共有、検証に使う一方、試作コードは本番に必要なセキュリティや性能の基準を満たすとは限らず、そのまま本番コードへ流用しないよう案内しています。
本番で使うなら、機能が動くかだけでなく、使いやすさ、安定性、セキュリティ、性能、端末ごとの表示、アクセシビリティなどを確認する必要があります。
特に製造業では、設備情報、品質データ、顧客情報、社内の機密情報を、公開AIサービスや未確認の試作品へ安易に入力しないことが重要です。
プロトタイプは、正しさを証明する完成品ではありません。「この方向でよいか」「何が足りないか」を早く見つけるためのものです。
- ダミーデータや公開情報を使い、機密情報を試作品へ入れない
- 生成されたコード、依存関係、入力処理を人が確認する
- 本番では認証、権限、セキュリティ、性能、アクセシビリティを確認する
- 実際の利用者が操作し、画面、言葉、操作順の問題を確かめる
- 試作品をそのまま本番コードへ流用せず、運用条件を含めて設計し直す
最後は、「私が使うか」で決める
CpkもDOEも、誰かに頼まれて作ったものではありません。自分が欲しかったから作りました。
「一つ一つ順番に触っていくと、DOEを理解できるようなツール。かなり良いツール。私、使う。」
DOEツールを何度も直したあとに、自分で書いていた言葉
だから、AIへうまく説明しようとは、あまり考えていませんでした。「気持ちよくない」「スクロールが面倒」「この言葉の意味が分からない」。画面を触って感じたことを、そのまま返しました。
DOEでは、SS、MS、dfの意味を自分が十分に理解できていないことも、作りながら分かりました。分かったふりをして説明を増やすより、私が触って自然に理解できる画面にしてほしいと頼みました。その方が、ツールは良くなりました。
要件定義が消えたわけではありません。私の場合は、AIで試作品を作って触ることで、最初には言葉にできなかった要件が後から見えてきました。
AIに上手な指示を出すことより、自分が本当に使いたいかを何度も確かめる。自分で使わないものを、もっともらしく完成させても仕方がありません。