―― Document Cross FinderとHuman-in-the-making
本記事は、AIとの個人開発を通じて得た気づきを記録するシリーズの第3弾です。
過去の記事
第1弾：コードを読めない私が、AIとの「協働」にたどり着くまで
第2弾：コードを書けない私は、何を「ものづくり」と呼べばいいのか
今回は、仕事で必要に迫られて作った Document Cross Finder というソフトの話です。
複数のドキュメントを横断して検索し、見たいところをすぐ表示する。それだけ聞けば、よくある便利ツールの話かもしれません。
実際、私も最初はそのつもりで作っていました。
1．必要に迫られて作ることになった
■ 作った資料は、読んでほしい
仕事では、説明書や手順書など、いろいろなドキュメントを作ります。
必要だから作るのですが、これが思ったほど読まれません。
社内やお客さんから、いろいろ質問されるのですが、「それ、資料に書いてあるんだけどなぁ」と思うことがあります。自分が時間をかけて作ったものなら、なおさらです。正直、ちょっとむかつきます。
とはいえ、使う側の事情も分かるのです。
資料がどこにあるか分からない。
見つけても、何ページに書いてあるか分からない。
いちいち開いて探すのは面倒くさい。
資料があることと、使われることは、どうも別の話らしい。
そんなことを、以前から感じていました。
■ 「まとめられないか」と言われた
あるとき上司から、「いろいろ技術資料や説明書があるけど、まとめられないか」という相談がありました。
よく聞いてみると、要するに、
「使いたいときに探すのが面倒」
「いちいちPDFを開くのが面倒」
「AI使って、うまくできないか」
ということらしい。
なんとも……な要求です。
せっかく作った資料なんだから読んでくれよ、と言いたくもなります。でも、上司の言っていることも分かる。私自身、資料を探すのが面倒だと思ったことは何度もあります。
これまで私のやってきた開発は、自分の中に「こういうものを作りたい！」があって始めることが多かったのですが、今回は違います。
特に作りたかったソフトでもありません。
正直、少し億劫です。
でも、仕事です。作ることにしました。
2．とりあえず、作ってみた
■ 仕様は、まずこれくらいでいい
対象は、およそ15個のPDF。ページ数もそれぞれ違います。
要望を整理すれば、「必要な情報を、すぐ探せて、すぐ見られるようにする」ということです。
ならば、基本動作は単純です。
- 一つのフォルダにPDFを入れておく。
- 複数のPDFをまとめて文字検索する。
- ヒットした文字を含むPDFファイルを候補として表示する。
- ヒットした文字を含むページを、その場で見られるようにする。
まずは、これくらいでいいだろう。
第1弾・第2弾の記事で書いたAI／OVER SOUL駆動開発の考え方を、ここで生かします。
最初にすべてを仕様として決め切るのではなく、ひとまず形にして、触りながら考える。
AIに作ってもらい、実際に動かしてみる。
違うと思えば直す。
欲しい機能があれば足す。
■ 人が使うものだから、見た目も大事
ただし、今回は上司に見せ、使ってもらうソフトです。
機能だけ動けばいい、というは少し味気ない。見た目は大事です。
そこでAIには、
「ちょっとおしゃれな、センスいい感じで。
色使いにも気を使って」
と頼みました。
我ながら、ずいぶん曖昧な要求です。
それでも形になったものを見ながら、ボタンの大きさを変え、文言を直し、表示の仕方を調整していきました。
■ どうせなら、自分も使いやすいように
人が使うためのソフトではあるのですが、どうせ作るなら、自分にも使いやすいようにしたい。
そこで、頼まれてもいない機能をこっそり盛り込みます。
例えば、文字サイズを「小・中・大」から選べるようにしました。上司の老眼対策です。
これは自分でも、なかなかいいアイデアだったと思っています。「文字が小さくて見えない」とか言うに決まってますから。
言われたらやらなきゃいけなくなるし、結局同じ手間なら先に仕込んでおいて「あなたのために機能作りました」って言えば、機嫌良くなりますからね。
さらに、PDFだけでなく、WordやExcelも検索できるようにしました。どうせなら、フォルダに入っているドキュメントをまとめて探せた方が便利です。
そんなふうに、作ったものを触っては直し、また触っては機能を足していきました。
出来上がったものを使ってみると、思っていたより便利です。PDFを一つずつ開いてページを探すよりも、欲しい情報へすっとたどり着ける感じがする。
「あれ、意外といい出来じゃん」
複数のドキュメントを横断して探せるので、
Document Cross Finder
と名付けました。
ここまでは、単に、必要なソフトを一つ作ったという話です。
3．他人用に作ったソフトを、自分でも使ってみた
■ 「あ、これが使えるじゃん」
その後、仕事で客先からトラブルの連絡がありました。
過去に似たようなトラブルはなかっただろうか。
私はこれまで、トラブル内容や対応方法、結果などを、1件につき一つのWordファイルに記録していました。そこそこの数があります。
ファイル名には、それらしいキーワードを入れてあります。でも、詳しい内容は開いてみないと分かりません。
一つ開く。違う。次を開く。これも違う。
そんなことを繰り返していると、だんだん面倒になってきます。過去には、途中で探すのをやめたこともありました。
ところが今回は、ふと思いました。
「あ、Document Cross Finderが使えるじゃん」
Wordファイルもまとめて検索できるようにしたのですから、過去の記録を横断して探せます。
実際に使ってみました。
残念ながら、探していたトラブルの過去記録はありませんでした。
でも、それとは別に、少し気になったことがありました。
■ 使える、というより、使いたくなる
自分で作ったソフトだから、多少ひいき目はあるかもしれません。
それでも、検索して、候補が出て、そこから内容を確認できる。この一連の操作は、使っていて気持ちがいい。
使いやすいものは、単に「使える」のではなく、「使いたくなる」。
私は今回、過去の記録を探すために、このソフトを使おうと思いました。
でも、そこで引っかかったのです。
なぜ私は、今回は探そうと思ったんだろう？
以前から、過去の記録があることは知っていました。調べれば何か見つかるかもしれないことも、分かっていました。
それでも、面倒で探すのをやめたことがある。
今回は、自分から使おうと思った。
機能があるから使った。もちろん、それはそうです。
でも、使いやすくしておいたから、使おうと思えたのではないだろうか。
4．あれ？ 変わったのは資料じゃない
■ ソフトを使うって、何を使うことだ？
ここで、また、少し考えました。
私はDocument Cross Finderを使おうと思った。
でも、何のために？
過去のトラブル対応記録を調べるためです。
ということは、ソフトを使おうと思ったのは、資料を使おうと思った、ということでもあるわけです。
……あれ？
■ 資料は、何も変わっていない
過去のWordファイルは、前からそこにありました。
ファイルの数も、中身も、このソフトを作ったことで変わったわけではありません。情報は一文字も増えてない。
なのに、今回は「調べてみよう」と思った。
じゃあ、何が変わったんだろう。
以前は、ファイル名から当たりをつけて、一つずつ開いていました。
今は、一つの画面からまとめて検索して、見たいところへ行けます。
変わったのは、資料そのものではなく、資料へ入っていくための入口だった。
資料単体には、「私が探しやすいようにしてくれる」という機能はありません。そこに情報が書かれているだけです。
でも、その資料へ入りやすい入口を作れば、使ってみようと思える。
使いたくなるソフトを作ったら、その先にある資料まで使いたくなった。
そんなことが起きていたのではないか。
■ UIって、そんな役割もあったのか
私はこれまで、UIを、ソフトを見やすくしたり、操作しやすくしたりするためのものとして捉えていたのだと思います。
もちろん、それも大事です。だから今回も、見栄えやボタンの大きさに気を使いました。
でも、今回のことを考えると、少し違う役割も見えてきます。
バラバラに存在するPDFやWordファイルを、一つの画面から横断して探せるようにした。
すると、資料の中身は変わらないのに、使われ方が変わった。
もしかすると、UIには、コンテンツを表示するだけでなく、コンテンツ同士をつなぎ、利用する価値を変える役割もあるのではないか。
一つずつ独立して置かれていた資料が、横断して探せる一つの情報のまとまりになる。
そのとき増えているのは、資料の情報量ではありません。資料へアクセスできることの価値なのかもしれません。
そうか、UIって、結構大事なものだったんだな。
いまさら何を言っているんだ、と思われるかもしれません。
でも、私はこのとき、初めてそんなふうに考えたのです。
5．ソフトを作っていたのに、思想が生まれた
■ そもそも、私は何をしていたんだっけ？
UIについて考えていたら、今度は別のことに気づきました。
ちょっと待てよ。
私は、何をしていたんだっけ？
上司に頼まれて、資料を探しやすくするソフトを作った。それだけのはずです。
最初から「UIがコンテンツの価値を変えるはずだ」なんて考えを持っていたわけではありません。
それなのに、自分で作ったソフトを使っていたら、いつの間にかそんなことを考えていた。
しかも、誰かに教わったわけではない。
自分で作ったソフトを触っていたら、そこから知らなかった見方を教えられた。
■ 今までと、順番が逆じゃないか
これまで私がAIと作ってきたものは、どちらかというと、自分の中に「こうしたい」という思想や理想が先にありました。
それをAIとのやりとりで、現物として具現化していく。
思想・理想 → ソフトウェア
もちろん、出来上がった現物から、新しい発見をすることもありました。
でも、今回の出発点は違います。
必要に迫られてソフトを作り、使っていたら、「あれ？」と思った。そこから考え始め、自分の中になかった見方にたどり着いた。
ソフトウェア → 気づき・発見 → 思想
今までと、順番が逆じゃないか！
私はこれまでずっと、自分の思想をソフトウェアとして具現化しようとしていました。
ところが今回は、ソフトウェアを作っていたら、そこから思想が生まれてきたのです。
■ 当たり前かもしれない。でも、私は知らなかった
ここまで読んで、「UIが使いやすさや価値に影響するなんて、当たり前じゃないか」と思う人もいるでしょう。その通りです。
しかし、この記事で私は、UIについて新しい理論を発見したと主張したいわけではありません。
私が面白いと思ったのは、何を知ったかだけではなく、どうやってそれを知ったかです。
私はソフトウェアに機能を与えたつもりでした。
ところが、そのソフトウェアを使っているうちに、今度はソフトウェアの方から、私が知らなかった世界の見方を教えられた。
あなたには当たり前かもしれない。でも、私は知らなかった。そして私は、作ることでそれを知った。
今までとは逆の経路で起きた、この体験そのものが、私には面白かったのです。
6．これって、Human-in-the-makingじゃないか
■ あれ？ これって前回書いたことだ
ここまで考えて、ふと思いました。
これって、Human-in-the-makingじゃないか。
前回の記事では、AIがコードを書くようになっても、人間をものづくりの現場から外してはいけないのではないか、という話を書きました。
人間がコードを書かなくても、AIが作ったものを見る。触る。試す。「違う」と思う。「これ何だ？」と思う。そこから、また作るものが変わっていく。
人間が、ものが生まれる現場に居続ける。
今回のDocument Cross Finderでも、私はそれをやっていました。
AIに作ってもらい、自分で触り、使いにくいところを直す。使っていて欲しくなった機能を足す。そして、できたものを実際の仕事でも使ってみる。
その中で、「あれ？」と思った。
そこから考えを進めたら、自分の知らなかった見方にたどり着いた。
■ 「完成」だけを見ていたら
もし私が、最初に要求を伝え、AIが実装したものを仕様通りできたか確認し、「できた。完成」として終わっていたら、どうだったでしょうか。
上司の要求は満たしている。仕事としては、それで済んだかもしれません。
でも、自分で使わなければ、「使いたくなる」という感覚には気づかなかったかもしれない。
なぜ今回は資料を探そうと思ったのか、という疑問も生まれなかったかもしれない。
UIの役割について考えることも、なかったかもしれません。
ものづくりから人間が離れると、失われるかもしれないのは、楽しさだけではない。
違和感を拾うこと。
偶然に気づくこと。
そこから考え、抽象化すること。
そして、自分の世界の見方を更新すること。
そんな学びの機会まで、失われる可能性があるのではないか。
■ 人を、学習と発見のループに残す
前回、私はHuman-in-the-makingを、人間がものづくりの現場に居続けるための考え方として捉えました。
今回は、その意味が一つ深まりました。
現物を作って触ることは、ものづくりの熱量を保つだけではない。そこから、作る前には知らなかったことを学べる場合がある。
自分の考えをソフトウェアにする。
そのソフトウェアを使って、自分の考えがまた変わる。
この往復は、逆向きにも働くのです。
だから、Human-in-the-makingは、人間を学習と発見のループに残すための考え方でもあるのだと思います。
最初は、上司に言われて仕方なく作り始めた、小さなソフトでした。
それが、思いがけず、自分の知らなかったことを教えてくれた。
Human-in-the-makingによって、私はソフトを作っただけではなく、そのソフトから学ぶことができた。
今回は、そんな体験の話でした。