自分が楽になるツールと、みんなが楽になるツールは、作り始めた時点で別物になる

面倒だと感じた作業は同じです。「これ、毎月やるのは無駄だな」と思ったところまでは違いがない。手を動かし始めるまでは、二人とも同じ場所に立っていました。

分かれたのは最初の一歩です。自分の分だけ片付けばいいのか、他の人の分も片付いてほしいのか。それだけの違いなのですが、所要時間で言えば前者は数時間、後者は数週間かかりました。

その差は、機能の多さから来たのではありません。ほとんどが、自分だけなら考えなくてよかったことを考える時間でした。

具体的に何が増えたのかを並べます。どれも作る前に想像できたはずのことばかりですが、実際には全部、作ったあとで出会いました。機能を足す時間より、この5つに費やした時間のほうが長かったと思います。

1. 前提の検証が最初に来る

自分のデータを自分のプログラムが書き換えられるのは、当たり前です。他人のデータを書き換えられるかどうかは、当たり前ではありません。組織の設定次第では、そもそも拒否されます。

しかもこれは、機能の出来とは無関係に企画ごと成立しなくなる種類の前提です。私はいったん「たぶん触れないだろう」と判断して該当の操作を塞ぎ、あとから実際に試したら通ったので開け直しました。この行ったり来たりは、自分専用なら丸ごと発生しません。

2. 自分のデータには存在しない値が出てくる

自分の使い方だけを見て判定のルールを決めていたら、他の人が入れていた別の形式の値を「まだ入力されていない」と誤認して、上から二重に書き込んでしまうバグが出ました。
自分専用のまま使い続けていたら、一生出会わなかったはずのバグです。エンジニアなら最初に疑うところなのかもしれませんが、私はまったく思い

自分専用のまま使い続けていたら、一生出会わなかったはずのバグです。エンジニアなら最初に疑うところなのかもしれませんが、私はまったく思いつきませんでした。テストデータを丁寧に用意するより、他人の実データを一度通してみるほうが早い、というのがこのときの実感です。

3. 配る版と、さわる版を分ける必要がある

社内に配ったURLは固定されているので、直したあとに公開版を更新する操作が要ります。そして自分がいじり倒す検証用と分けておかないと、直している最中の壊れた状態がそのまま全員に見えてしまう。

機能ではなく運用の手間ですが、これは自分専用なら一切ありません。壊れていても困るのは自分だけだからです。

4. 自分の権限では終わらない作業が最後に残る

ツールが正しく動いても、受け取る側のシステムに設定が入っていないと結果が反映されない、ということがありました。そしてその設定は、私の権限では触れない場所にあります。

最後に残ったのは、コードではなく「誰かにお願いする」という段取りでした。社内ツールが最後の一歩で止まるのは、だいたいこの種類の理由だと思います。

5. 間違いも全員に伝わる

共有されているデータを書き換える以上、一人の操作は他の人の画面にも反映されます。便利であると同時に、間違えたときも全員に伝わるということです。

自分専用なら、間違えてもやり直せば済みました。他人が見ている以上、やり直しの前に「すみません」が挟まります

理由は単純で、削れる面倒が一人分で終わらないからです。仮に10人が毎月30分使っている作業なら、消えるのは月5時間になります。自分だけが楽になるのとは桁が違います。

もうひとつは、自分専用にすると、自分が使い続けている間しか価値が残らないことです。誰かが同じ面倒に困ったときに「あの作業ならあれを使って」と言えると、説明する手間まで一緒に消えます。

ただ、自分専用が劣っているとは思いません。試したい発想があるときに、他人の使い勝手を先に考えるのはむしろ邪魔になります。自分専用でしばらく回してみて、使い続けられたものだけ全員用に作り直す、という順番のほうが無駄が少ない場面は多いはずです。私自身、そうやって捨てたものもあります。

次に同じことをやるなら、手を動かす前にこれだけは決めます。どれも技術的な検討ではなく、対象を決めるための問いです。ここが曖昧なまま作り始めると、あとから設計ごとやり直すことになります。

対象を決める

・誰が使うのか。自分だけか、チームか、全社か
・その人たちの何分が、月に何回返るのか
・使う人は、その作業を面倒だと思っているか

3つ目は見落としやすいところです。自分がうんざりしている作業を、他の人は特に気にせず済ませていることがあります。その場合はいくら便利にしても使われません。何度作っても、この2つは後回しにしがちです。今回も計算したのは作り終えたあとでした。

作り始める前に確かめる

・他人のデータを、自分のプログラムから書き換えられるのか
・自分の使い方にしか出てこない値や、逆に自分だけが使っていない値はないか
・動かすのに必要な権限を、そもそも自分が持っているか

この3つは、通らなければ企画ごと成立しない種類の確認です。機能を1つ作るより先に、いちばん危ないところを一度だけ試してみるほうが安全です。私はここを後回しにしたせいで、作った機能をいったん塞いで、また開け直すという遠回りをしました。

配る前に決める

・使う人が今日すでに開いている画面の中で、完結するか
・直している最中の状態が、全員に見えない置き方になっているか
・使い方をどこに置くか。聞かれるたびに口で答えるのか
・自分が触れなくなったとき、誰が直すのか

1つ目は効き目が大きいところで、新しい画面を覚えてもらう前提にした時点で、使われない可能性が跳ね上がります。私の場合はたまたま予定表がそれでしたが、意識して選んだわけではありませんでした。

最後の1つには、正直まだ答えを出せていません。属人化した便利は、時間が経つと負債になります。今のところ、直せるのは私だけです。

以前なら人に頼むしかなかったものが、いまは自分で作れます。作れる人が増えれば、作れること自体で差がつく時間は短くなっていきます。同じものを二人が別々に作ってしまう状況は、今回まさに社内で起きたことでした。

差が出るのは、どこに向けて作るかを決めるところなのだと思います。自分の面倒を消すだけなら、たいてい今日のうちに終わる。他人の面倒まで消しに行くと数週間かかって、途中で何度か嫌になります。

それでも後者を選ぶかどうかは、削ろうとしている時間が誰の時間なのか次第です。何本作ってきても、私はこれを毎回あとから考えています。次はさすがに先に決めます。