れは、一つの営業支援ツールが少しずつ賢くなっていく、いまも続いている記録です。
派手な話は、ほとんど出てきません。
天才も、閃きも、一夜にして世界が変わる瞬間もありません。
あるのは、うまくいかなかった一件を実際に開いて、「なぜだろう」と眺めるところから始まる、ずいぶん地味な時間の積み重ねだけです。
書いていて少し気恥ずかしいのは、出てくる間違いの多くが、笑ってしまうほど単純なことです。
けれど、その単純な間違いを一つずつ拾っていくうちに、成績は「200社に2社」から「5社に1社」まで動きました。
改良の回数は、300を超えています。
『リストル：フォームリーチツール改善奮闘記』によろしければ、お付き合いください😊
サードパーティモジュール依存の罠。例外処理を起点としたフェイルセーフの思想
■ 環境依存によるサイレントエラー。「あるはず」の外部コンポーネント欠落
昨日まで動いていたのに、今日は動きません。
こちらは、何も直していません。名簿も同じです。設定も変えていません。
記録には、短い1行だけが残っていました。
「起動できませんでした」
これでは、何も分かりません。
手元で同じことを試すと、ふつうに動きます。困っている環境でだけ、動きません。こういうときは、環境の違いを1つずつ潰していきます。
入っているものを見比べました。
中で使っている表示部品が、欠けていました。
このツールは、ページを開いて中身を読むために、画面を表示する部品を使っています。人間が見るための画面ではありません。中身を正しく読むために、いったん表示させる必要があるのです。その部品が、その環境にだけ、ありませんでした。
何かの拍子に、片付けられてしまったようでした。
本人に悪気はありません。整理のつもりだったのかもしれませんし、別のツールが消したのかもしれません。
いずれにせよ、無くなっていました。
あっ、と思いました。
こちらは「あるもの」として動き出していた。
■ 起動時の依存性検証（プレフライトチェック）とフォールバック（代替）処理の実装
このツールは、立ち上がるとき、自分の持ち物を確かめていませんでした。あって当たり前のものです。入れたときから、ずっとありました。
だから、確かめる必要を感じませんでした。
無いことが分かるのは、実際に使おうとした、そのときです。
しかも、そのときの記録は「起動できませんでした」の1行だけです。
何が無いのかも、書かれていません。これでは、困っている方は何もできません。
直したのは、3つです。
1つ目は、立ち上がるときに、持ち物を確かめること。
必要なものが揃っているかどうか、先に見る。
2つ目は、無かったときの記録です。
何が無いのかを、はっきり書くようにしました。
「表示のための部品が見つかりません」
1行違うだけで、次にやることが決まります。
3つ目は、無かったときの振る舞いです。
無ければ、そこで止まるしかない。最初は、そう思っていました。
調べてみると、そうでもありませんでした。
同じ役目を果たせる別の道が、いくつかあります。
少し遅くなりますが、動きはします。
そこで、こうしました。
いつもの道が使えなければ、別の道で立ち上がる。そして、その旨を記録に残す。
「いつもの部品が見つかりませんでした。別の方法で動いています」
遅くはなりますが、止まるよりはずっとましです。
ここで、笑ってしまう話がありました。
持ち物を確かめる仕組みを入れたあと、こちらの手元でも、確かめる部分が働き始めました。そして、「部品がありません」と言って、止まりました。
手元には、ちゃんとあります。調べてみると、確かめにいく場所が1か所しか書かれておらず、こちらの環境では、別の場所に置いてあっただけでした。持ち物があるかどうかを確かめる仕組みが、持ち物の置き場所を1つしか知らなかったわけです。
置き場所の候補を増やして、ようやく落ち着きました。
■ トラブルシューティングの工数削減。サードパーティ依存のリスクマネジメント
直したあとの効果は、地味なものです。
届く数は増えません。こなせる数も変わりません。
変わったのは、困ったときの分かりやすさだけです。
それでも、この直しは意味がありました。
「動きません」という連絡を受けてから、原因が分かるまでの時間が、大きく短くなったからです。
以前は、1日がかりでした。いまは、記録を1行見れば分かります。
ツールは、自分の欠けに自分で気づけるほうがいい。
人間の道具なら、見れば分かります。鋸が無ければ、鋸が無いと分かります。
こういうツールは、中が見えません。見えないものについては、自分から言ってもらうしかありません。
このあと、他の場所についても、同じ考え方を入れました。
立ち上がるときに、必要なものを1通り確かめる。足りないものがあれば、名前を挙げて言う。
立ち上がりが、ほんの少しだけ遅くなりました。
その遅さは、困ったときの1日と引き換えです。
悪くない取引だったと思っています。
この1件で、もう1つ考えたことがあります。
このツールは、他人の作ったものを、いくつも借りて動いています。
ページを表示する部品もそうですし、文字を扱う部品も、記録を残す部品もそうです。
どれも、自分で作ったものではありません。自分で作ったものなら、無くなることは、まずありません。借りているものは、そうではありません。
いつのまにか片付けられていたり、別のものに入れ替わっていたりします。こちらの都合とは関係なく、そうなります。
だから、借りているものについては、「あるはず」で動き出してはいけませんでした。この考え方を、他の場所にも入れていきました。
置き場所は、あるか。
書き込む先は、書き込める状態か。
外へ出ていく道は、通っているか。
立ち上がるときに、ひととおり確かめます。
どれも、たいていは大丈夫です。大丈夫な日が、9割9分でしょう。
残りの1分のために、毎回確かめます。
その1分の日に、「起動できませんでした」の1行だけで1日を潰すのは、もう懲りました。
■ 開発者視点からユーザー視点へのエラーログ改修。例外処理を引き受ける意味
ツールというのは、うまくいっているときの姿だけを考えて作りがちです。うまくいかない日のことを、同じくらい考えて作ったほうが、結局、長く使ってもらえます。
この一件のあと、記録の書き方も少し変えました。
これまでは、うまくいかなかったときに短い1行だけを残していました。
「起動できませんでした」この1行から分かることは、何もありません。
いまは、こう書くようにしています。
「表示のための部品が、次の場所に見つかりませんでした」
「別の方法で立ち上げます。少し時間がかかります」
2行です。
2行あれば、読んだ方が「ああ、そういうことか」と思えます。
思えなくても、その2行をそのまま伝えていただければ、こちらには、すぐ分かります。
困ったときの記録というのは、困った人が読むものです。
こちらが読むためだけに書いていると、困った人には、何も伝わりません。この当たり前のことに、ずいぶん長いあいだ気づきませんでした。
この回は、こちらの落ち度が分かりやすい回でした。
部品が欠けたのは、こちらのせいではありません。
欠けたときに何も言えなかったのは、こちらのせいです。
ツールが壊れること自体は、避けられません。
壊れたときに、何が壊れたのかを言えるかどうか。そこは、作る側で決められます。この違いは、思っていたより大きいものでした。
「動きません」
この一言から始まる調べものは、だいたい、1日仕事になります。
「表示のための部品が見つかりません」
この一言なら、5分です。
どちらの一言を出すかは、困ったときではなく、作るときに決まっています。作っているときは、うまくいく道ばかり見ています。
うまくいかない道は、書くことが多くて面倒です。しかも、通らないかもしれない道です。
その面倒を先に引き受けておくかどうかで、困った日の1日が決まります。
この件で、それをはっきり教わりました。
（つづく）
→ 営業リスト探しに、もう時間をかけない。
業種別に企業情報をまとめて収集できるリストルを、まずは3,000件まで無料でお試しください。👇
📊営業リスト収集ツール「リストル」
