気づけば、手元には自分で作った業務ツールが何個も増えていました。
Teamsのリンクとメモをその場で保存するツール。仕事で使う樹木の図鑑。指導記録をつける専用ツール。技術情報を332件まとめて検索できるデータベース。
どれも、最初は「これ、いちいち手作業でやるの面倒だな」という小さな不満から始まりました。
私はプログラマーではありません。
それでも、これだけの数のツールを実際に仕事で使える形にできています。
今日は、その”やり方”を再現できる形に整理してみようと思います。
プログラミングを覚えなきゃ、って思ってた時期が私にもありました
でも実際にやってみて分かったのは、覚える必要があったのは「コード」ではなく
「頼み方」だったということです。
自分専用のツールは、コードを書く力ではなく
「小さく作って、会話で育てる」
というやり方さえ知っていれば、誰でも形にできます。
ここからは、実際にやっている5つのポイントをお話しします。
① 「1枚のファイルで完結させる」を最初のルールにする
最初に決めたルールがひとつだけあります。
それは、ツールを、1つのHTMLファイルだけで完結させることです。
サーバーを借りたり、インストール作業をしたりする必要はありません。
ファイルをダブルクリックすれば、ブラウザでそのまま開いて動きます。
これは職場のパソコンで使うツールを作るときに、特に効いてきました。
情報システム側の許可待ちも、環境構築の手間もいらない。
フォルダごとコピーして渡せば、相手のパソコンでもすぐ同じように動きます。
“ツール作り＝大掛かりな開発”というイメージが、この時点でだいぶ崩れました。
② 完璧を目指さず、まず「動くもの」から会話で育てる
最初から完成形を狙わないことも、大事なポイントです。
たとえば林業のフィールドガイドは、最初17種類だった中身を、
後から「もっと充実させて」と頼んで26種類まで増やしました。
画像がなければ「画像も集めてほしい」、材木としての特徴が抜けていれば、
「材の特徴も入れて」。
気づいたところから、その都度直していくやり方です。
メモのツールも同じでした。
最初は保存先を毎回選び直す必要があって面倒だったのですが、
「前回のファイルを覚えておいて、次はワンクリックで再開できるようにして」と頼んだら、
その通りに直って修正できました。
実際に使ってみて初めて「あ、ここが引っかかるな」と気づくことは多いです。
完成を待たずに使い始めて、引っかかったところから直していく。
この順番の方が、結果的に早く「本当に使えるもの」にたどり着けます。
③ 「外部に送信しない」を、最初から条件にしておく
仕事で使うツールには、外に出せない情報が関わることもあります。
なので私は、ツールを頼むときに必ず、
「外部通信なし」
「データは自分のパソコンの中だけに保存」
という条件を最初に伝えるようにしています。
一度、音声入力の機能を使っていたことがあったのですが、
それが外部のサービスにデータを送る仕組みだと分かって、
あとから撤去してもらったこともありました。
“便利そうな機能ほど、裏側でどこにデータが流れているか確認する”
ということを、この経験から学びました。
最初にルールとして伝えておけば、後から仕組みごと作り直す手間も減ります。
実物の資料に語らせる
図鑑やガイドの類は、説明文だけだと今ひとつ実感が湧きません。
林業ツールに樹木の写真を足したときは、著作権的に問題のない実在の写真素材
（Wikimedia Commonsという場所にある、誰でも使える写真）を、
種類ごとに探して当てはめていきました。
一枚一枚、本当に実在するファイルかどうかを確認しながら進めるので、
多少手間はかかります。
それでも、写真が入った瞬間にツールの説得力がまったく違うものになりました。
④ 「使い方」も、ツールと一緒に作ってしまう
ツールができても、周りの人が迷わず使えなければ意味がありません。
指導支援ツールを作ったときは、ツール本体だけでなく「使い方スライド」も
あわせて作ってもらいました。
印刷して配れる形で、口頭で説明するときの原稿としても使えるようにしています。
「タブが6つもあって難しそう」と身構えられてしまう前に、
「まずはここだけ使えば大丈夫」と伝えられる資料を用意しておく。
これも、ツール作りの一部だと思うようになりました。
まとめ
「1枚のファイルで完結」
「完璧を待たず会話で育てる」
「外部に送信しない」
「実物の資料に語らせる」
「使い方も一緒に作る」
この5つさえ押さえておけば、思いついたその日のうちに、最初の一歩は形にできます。
もし「これ、ツールにできたら楽なのに」と思うことが日々の中にあったら、この五つさえ押さえて、小さく試してみてください！
コメント