ひとり運用の道具立てを最小にする

TL;DR
- 道具を増やすほど、学習・更新・障害対応という見えないコストも増える。
- 「多機能を一つ」と「単機能を複数」は、保守の負担が大きく異なる。
- 連携の数は、壊れうる接続点の数でもある。
- 乗り換えやすさ(データの持ち出しやすさ)を基準に選ぶと、後で身軽でいられる。
ひとりで運用する道具立てを考えるとき、二つの方向がある。一つは、機能の多い道具を一つに集約する方向。もう一つは、単機能の道具を必要なだけ並べ、連携でつなぐ方向だ。どちらが優れているという話ではない。ただ、ひとりで保守する前提では、それぞれが背負うコストの形が違う。
多機能を一つに寄せる場合
多機能なツールに集約すると、覚える操作の入口が一つで済み、データも一か所にまとまる。連携の設定に悩まされることも少ない。一方で、その一つが止まれば全部が止まる。料金体系の変更や仕様の改定にも、丸ごと付き合うことになる。卵を一つの籠に入れる選択は、管理は楽だが、籠そのものへの依存が深くなる。
単機能を複数つなぐ場合
単機能の道具を組み合わせると、一つひとつは置き換えやすい。気に入らなければ、その部分だけ別の道具に差し替えられる。けれど、つなぎ目の数だけ壊れうる箇所が増える。連携サービスの仕様が変われば、自分の組んだ流れが静かに止まる。自動化が壊れた日のための備えで書いたとおり、接続点は便利さと同時にもろさを持ち込む。
つまり、集約は「一点への依存」を、分散は「接続点の数」を、それぞれコストとして抱える。どちらを選ぶにせよ、見えにくいコストがある点は共通している。新しい道具は、機能の対価として、学習と更新と障害対応の時間を静かに請求してくる。
選ぶ基準を「出口」に置く
私が道具を選ぶとき、最近いちばん重く見ているのは「やめやすさ」だ。導入のしやすさではなく、後でデータを持ち出して別の道具へ移れるかどうか。標準的な形式で書き出せるか、自分のデータを自分で取り戻せるか。出口が確保されていれば、たとえ依存しても、それは引き返せる依存になる。
ジェイソン・フリードとデイヴィッド・ハイネマイヤー・ハンソンは、必要以上の道具立てが「忙しさ」を生む構造を著作の中で繰り返し指摘している。道具が増えれば、道具の世話をする時間も増える。世話の時間は成果には見えにくいぶん、気づかぬうちに一日を侵食する。
足し算より引き算で見直す
道具立ては、放っておくと足し算の方向にしか動かない。新しい課題が出るたびに、新しい道具を一つ足す。けれど半年に一度、逆向きに棚卸ししてみると、もう使っていない道具や、機能が重複している道具が見つかる。自動化の前に、まず工程を削ると同じで、減らす視点を定期的に入れないと、道具立ては静かに肥大していく。
結局のところ、最小化とは「機能が少ない状態」ではなく、「自分が世話できる範囲に収まっている状態」だと思う。多機能を一つに寄せても、単機能を複数つないでも、自分の手に負える量を超えなければいい。ひとり運用で効いてくるのは、派手な機能よりも、止まったときに自分一人で立て直せるという安心のほうだ。入力まわりをどこまで削れるかは、入力の手数を減らす——定型文と展開で具体的に見ていきたい。
出典
- Jason Fried, David Heinemeier Hansson『It Doesn’t Have to Be Crazy at Work』(道具立てと忙しさの関係)
- 情報処理推進機構(IPA)データ移行・相互運用性に関する公表資料