動いていたものを、なぜ止めたのか
毎月出ていく費用を、月に一度まとめて確認している。
新しく試したい機能やサービスの予算をどこから出すかを考えていたときも、同じように一つずつ見ていた。
当時、アプリの規模は大きくなかったので、出ていく額も全部足して大きくはない。一つずつ見ていくと、常時動かしているサーバーが一台あって、動いている。止まったこともないし、エラーも出ていない。
けれど引っかかった。
動いていることは、請求書を見れば確認できる。動かしている理由のほうは、確認していなかった。
作った理由は、消えても知らされない
もともとサーバーを実装したのは、外部サービスとの連携のため。
認証情報を保持したり、認証のやり取りをする目的で作った。当時は他の方法が思いつかなかったのと、実際に機能のために必要だったから作った。
それから、作るものの方向性が変わって、連携の機能を外した。検証の段階だったので、Webのほうにも機能は持たせず、内容を伝える一枚のページだけにしていた。
この段階で、アプリのバックエンドにサーバーを使う理由は、ほとんど消えた。ただ、そのままサーバーを使っていた。
理由がなくなったことは知らされない。請求はき続けるし、動作も正常のまま。必要ではなくなったことを、何かが教えてくれるわけではない。
サーバーの残っていた用途も、改めて確認すると重要ではなかった。アプリからデータを読み書きしていただけで、認証の仕組みは既に別のサービスに移してあった。
払っていたのは、金額だけではなかった
払い続けても困らないので、特に気にしていなかった。金額が小さいと、見直しの対象から外れやすい。ただ、同じ額を他に使えるという見方をすると、無駄なコストはかけ続けたくなかった。
実際、金額以上のコストもあった。アプリの機能を変えるたびに、場合によってはサーバーの実装も変える必要がある。変えずに済むことのほうが多かったけれど、その都度確認することにはなる。何を作るかを試している段階だと、この確認と修正が手間になっていた。
請求書に載るのは7ドルだけで、確認に使った時間は載らない。手間のほうも、機能変更の片手間と考えれば大きくはない。ただ、二つを合わせて見ると判断が変わった。
残す理由もあった
サーバーには汎用性があるから、将来また要るかもしれない。そこが気になっていた。
ただ、当時作っていたものは、使う人がいるかどうかをまだ確かめている段階だった。何が使われるか決まっていない状況で、ただの可能性に対して毎月コストが発生する。だから決め手にしなかった。
データを端末の中に持たせる形も考えた。ただ、iOSはUIの一つとして選んだだけで、他のプラットフォームでもよかった。端末の中に保存していると、別のプラットフォームに広げたり移行するときに、データの移行が要る。これも選ばなかった。
実際のところ、いま同じ用途が出てきたとしても、常時動かすサーバーを持たずに済む形がある。データを預けているサービスの側にも、Webのページを置いているサービスの側にも、呼ばれたときだけ動く仕組みを用意できる。使っていない時間まで動かし続ける必要がない。作った当時と選択肢や状況が変わっているのも大きかった。
以前、どこまで作り込むかという設計の判断について書いた（「ちゃんと作らない」という設計判断）のは、簡素に作ること自体が問題ではなく、いつまで簡素なまま使うかを決めずに時間が経つことがコストになる、という話。今回のサーバーは、必要な最小限の作りにはなっていたけれど、いつまで・どういう条件で使うのかを決めていなかった点は同じだった。
一度に消さない
一度に消さずに、データの移行とアプリの切り替えだけ先に試した。サーバーとデータベースはそのまま残しておいて、サービスだけ止めた。
移した先は、データを預けるサービス。間にサーバーを置くのをやめて、アプリから直接読み書きする形にした。データを移して、アプリの向き先を変えるだけだったので、移行自体も手間ではなかった。
コードや設定は残してあるので、戻そうと思えばすぐ戻せる状態にしてある。
難しいから続いていたわけではなく、必要かどうか・難しいかどうかを確かめていなかっただけだった。
止めたあとに残るもの（移したあとのデータや、使っていないアカウント）は、それ自体にコストや手間があるかどうかで、消す時期を決めればいいと思っている。
浮いた分は、もともと予算を探していた、新しく試したい機能のほうに回せた。
時間がかかったのは、思い出すこと
移行しようと思ったときに、サーバーを使っていた理由を思い出すことのほうが、時間がかかった。自分で決めて、自分で作って、自分で払っていたにもかかわらず。
当時、実装した理由は明確にしていた。ただ、判断の記録として残していなかったので、変更履歴やコードを確認する必要があった。
理由がなくなっていたことに数ヶ月気づかなかったのが、一番意外だった。
規模の話としてはかなり小さい。月7ドル、使っているのは自分だけ、判断するのも一人。稟議も承認も要らない。作った人がいなくなることもないし、請求も自分で確認している。状況としては、気づきやすいほうだと思う。
関わる人が増えて、作った人が別の部署に移ったり、その費用が部門の予算にまとまって、明細を誰も個別に見なくなる。そんな環境だと、もっと気づきづらくなるように思う。規模が小さいから残っていたというより、気づきやすい条件が揃っていても残っていた。
思い返すと、作る側に人と予算がある環境だと、まず自分たちで作る、という場面をよく見てきた。作らない形が検討されないままなこともある。体制があると、自前で作らない選択をする理由のほうが弱く見えるからかもしれない。それ自体が悪いとは思わないけど、なぜ作るのかが言葉になっていないと、あとで止める判断ができなくなると思う。
決めたことを、記録するということ
止める判断自体は、確認して決めるまで数日。手間だったのは、なぜ作ったのかを思い出すほうで、それは記録がなかったせい。だから、今回の判断は記録として残しておく。
以前に引き継ぎの話を書いたとき（「開発した人がいなくなったらシステムはどうなる？」）にも同じことに触れていた。あのときは他の人に引き継ぐ場面を考えていたけれど、引き継ぐ相手が数ヶ月後の自分でも、あまり変わらなかった。
状況：個人で作っているアプリ。外部サービス連携のために置いたサーバーを、月7ドルで常時動かしていた。実際に使っていたのは自分のアプリだけ
論点：この支出と手間を続けるか。続ける・残しておく理由があるか
選択肢：そのまま続ける／別のサーバーに移す／サーバーをなくして、データを預けているサービスに直接つなぐ／残したまま縮小して、常時動かすのをやめる
決め手：作った理由が既になくなっていた。いまの用途にサーバーが必要ではなかった。金額そのものより、機能を変えるたびに確認する手間のほうが重かった
決め手にしなかったもの：将来また必要になるかもしれない、という汎用性
その後：段階的に停止。移行自体は軽かった。2〜3ヶ月経っても、戻す必要は出ていない。運用していたときのコードや設定は残しているので戻せる
「決め手にしなかったもの」を書いているのは、あとで見返したときに役立つから。何を選んだかだけだと、状況が変わったときに、退けた案をもう一度見に行く手がかりがない。採用しなかった理由が残っていれば、その理由がまだ成り立つかを確かめるところから始められる。今回でいえば、次にサーバーが要りそうになったとき、汎用性を退けた前提が変わったのかどうかから確かめられる。
止めてみて思ったのは、何かを始めるときには判断が要るけれど、続けるときには要らない、ということ。何もしなければそのまま続く。止めるときには、また判断と理由が要る。
この差があるせいで、いま続いているものの中には、意図的に続けているものと、止める判断をまだしていないだけのものが混ざる。どちらも同じように動いているだけだと、見分けがつかない。なぜ動いているのかを説明できないままだと、気づかないまま払い続けるか、理由を掘り起こすところからやり直すことになる。
いま動いているものを、続けるか、作り直すか、やめるか決められないとき：https://yoshiakihayashida.com/consulting/
