Feedback Loop

個人開発で道の駅アプリをつくっている。全国にある道の駅を訪問し、記録するとマップ上のピンの色が変わる。全国や自分のエリアのピンの色をすべて変えることを目的にドライブにでかける、スタンプラリーのような使い方ができるアプリ。

いま調べたら2018年にリリースしていたのでもう6年も運用している。自分が本格的に運用しているアプリのなかでは最も古く、リリースしてからも色々と機能追加を行った。収益的なところだとリリースは当初広告を入れてるのみだったが、途中からサブスクリプションモデルを導入。月額いくらか払うと機能をフルに使えたり、広告を非表示にできたりする。個人がひとつのアプリに月額を払うのはそれなりに覚悟が必要なことなので、何か機能を追加してサブスクの登録数が増えたら刺さるものが作れたと考えられる。

当初広告モデルを採用していたこともあり、無料でもかなり多くの機能が使える。サブスクに入るとプラスでいくつかの便利機能が開放される。例えば訪問履歴をグラフで振り返る、細かいオプション設定、ダークモードテーマの適用など。でも一番需要があったのはデータの自動バックアップで、昨年実装して有料ユーザーがグンと増えた。道の駅巡りをしている人にとって一番ショッキングなのはそれまで積み上げてきたデータが消えることで、その恐れから開放されることが価値があったといえる。

面白いこととして、この自動バックアップ機能に需要があることは以前から気づいていた。というかユーザーからよく要望の声が寄せられていた。しかしシステム的に実装が重そうだし、考慮ポイントが多すぎて不具合生みそうで怖いし、iOS/Android間のデータの定義が難しいしで後回しにしてしまっていた。自動ではなく手動のバックアップ機能は以前から提供していたというのも優先度があがらなかった理由のひとつ。記録データをCSVファイルの形で書き出したり読み込んだりできる。この機能を使えば機種変更時もデータ移行自体はできる。ただマニュアルが必要なくらいには手順が少し複雑だったので、自動バックアップは求められていた。振り返ってみると需要は明確なのだからすぐに作れば良いのだが、なぜかダークテーマや細かい機能開発を優先してしまった。その理由を考えてみると「短い時間で作れそうだから」「自分の興味ある技術だから」あたりが挙げられる。

個人開発は平日の夜や週末にやっている。そうなるとまとまった時間は確保しにくく、短いタイムスパンでできる改善を先にしてしまう傾向がある。それ自体は悪いことではないが、時間をかけて大いなる機能を作った方が良い場合もあることには自覚的でいたい。また、自分の好きなことをできるのが個人開発の醍醐味なので自分の興味関心の影響を大きく受ける。例えばダークモードの実装はどうするか、グラフはどう実装すると良いのかなど。実装してみてとても勉強になったが、これらは自分目線でユーザーが欲しているものではない。賑やかしとしては良いが、ユーザーが心から求めているものではないので刺さることはない。

自分が作りたい機能を10個作るより、ユーザーが本当に欲しい機能を時間をかけて1個作るほうが提供できる価値は大きい。自動バックアップ機能の反応をみて最近はそう思うようになり、大きい機能でも避けずに毎日コツコツ実装するようになった。そして細かい実装ステップにわけて作ってみると、途方もなく時間がかかると思っていた機能でも案外2週間くらいで作れたりする。これくらいなら個人開発の時間の使い方でも全然作れる。

ただ寄り道に意味がないわけではなく、自分がなんとなく作っていて面白く感じた機能もある。それは投げ銭機能で、YouTubeやライブ配信のようにアプリに投げ銭して応援できるという機能。実体としてはアイテム課金のアイテムが何も貰えないバージョンで、金額を3段階から選べて購入できる。これは意外にも定期的に買ってもらえていて、ちょっとした開発のモチベーションになっている。アップデート時にアプリ内にどこいう機能が追加されたかポップアップで表示しているが、そのポップアップの下部にも「応援する」ボタンを置いている。良いアップデートだと投げ銭の数が増えたりして、機能開発に対してダイレクトに反応を示してもらて面白い。要望や不具合報告はお問い合わせフォームから連絡してもらえるが、良い！という感情はわざわざ書いたりしない人が多いと思う。投げ銭はユーザーが欲しがる機能ではなくいわばこちらのエゴだが、ユーザーの喜びが可視化できたのは面白くて勉強になった。

趣味の他に、会社でもPodcastをしている。会社の雰囲気やどういう人がいるのかを知ってもらいたくて始めた番組で、毎回ひとつテーマを挙げてそれについて雑談するような構成。最近週一での定期更新を目指してみることになったが、定期的に続けるにはできるだけ運用を楽にしたいと考えた。

一番簡単にしたいと思ったのが録音の部分。これまでは参加者が各々のパソコンで録音し、それを後から編集ソフトで合体させていた。この手順は慣れた人には良いが、初めてPodcastを録音しようという人にはちょっと手間になる。自分の声が入らないようにイヤホンをつける必要があるし、収録した音声ファイルがパソコンのどこに保存されるかを探すのも地味に難しい。普段のオンライン会議のように普通に話せば収録できる、そんなツールはないかと思って調べるとRiverside.fmに行き着いた。

Riverside.fmはSpotifyが提供するサービスで（過去に買収したらしい）、Podcastの収録に特化している。ホストがスペースを立ち上げ、そこにゲストをメールやURLで招待する。レコーディング開始ボタンをポチッと押すだけで録音は開始され、参加者全員の音声が個別に録音される。まさに探していたツールのように思う。試しに20分ほど収録してみると、これが想像以上に便利だった。

まず、録音したファイルは参加者ごとに分けて録音される。波形が色違いで表示されていて、誰がよく話しているかが一目でわかる。さらに自動で発話が文字起こしがされ、話題が切り替わったタイミングを自動で検知してセクション分けし、そのセクションに相応しいタイトルをつけてくれる。ここまでで既にすごい。音声の編集で面倒なのが、一部分だけカットすること。内容が間違えているとか、勘違いを誘うセリフがあったとき、その部分はカットしたい。しかし音声は全体感を把握しにくいので、該当箇所を記憶を頼りに探して見つけ、何秒から何秒までをカットしたら良いかメモし、カットした後に問題ないか聞き直すステップが必要になる。これが地味に手間だが、Riverside.fmでは文字起こしされたテキストを削除すると該当する音声も連動して削除される。つまりテキストをざっと見て問題がありそうな箇所を削除していくだけで期待する音声ファイルが得られる。ちなみにテキストも発話者ごとに表示され、音の重なりもテキストのレイアウトによって表現される。同時に喋ってしまって聞き取りづらい箇所もすぐ特定できる。痒いところによく手が届いている。

先日編集していると、録音したファイルにかなりノイズが乗っていることに気づいた。後ろでずっとザザザという音が鳴っていて本編の会話が聞き取りづらい。調べてみるとMagic Audioという機能があり、これを使うと自動でいい感じにノイズ除去、さらに話者ごとのボリュームに差がある場合は自動調整してくれるらしい。こういった機能は従来のツールでもよくある機能ではあると思うが、Riverside.fmでは滑らかな体験として提供される。Podcast録音に特化したツールとして、そのために必要なことは何でも深掘ってやります、という意思が伝わってきてうれしくなった。

最近は動画つきのPodcastも増えてきて、Riverside.fmもデフォルトでは動画ありで収録される（オーディオのみに設定変更できる）。個人的には散歩や家事をしながらPodcastを聴く時間が好きなので、映像なしで楽しめるコンテンツのままではあって欲しいと思う。でも時代の流れには逆らえないので、数年後には普通に動画つきでPodcastを楽しんでいるかもしれない。

技術で何かの敷居が下がるのは素晴らしい。趣味の方のPodcastを始めたのも、元々はAnkerというスマホアプリで簡単に収録できるようになったことがきっかけだ。いろんなトピックを誰でも話せ、それを耳元で距離感近く聞けるPodcastは完全に自分の好みにハマっている。もっと流行っていろんな番組が増えて欲しいと願っております。

何かを試すとき、いきなり全体に適用するのではなく小さい単位でまずは動かしてみる。例えば誤りのあるデータを修正するスクリプトを書く場合、いきなり全件を対象にすると失敗したときの影響が大きすぎる。一人のユーザーとか一つの会社とか、限定された対象でまずは試す。それがうまくいくと分かって確認が取れてから全体に適用する。

昔宇宙兄弟という漫画が好きで、その中で限られた予算でとある装置を作るという話があった。他のチームは予算を目一杯作って作ろうとする中、物語の主人公の六太は予算の半分で作れる設計を探す。疑問をもったチームメンバーから聞かれると、予算を目一杯使うと失敗できなくなる。試行錯誤が大事だから二つ目を作れるように進めたい、と話す。どれだけ緻密に考えられたものでも実践投入すると気づかなかった綻びが見つかる。それをあらかじめ計画に織り込む。失敗してもゲームオーバーにならない座組を整えておく。

似たような話として、何か大きいものを作る時はいきなり作り出さないという話がある。事業であればいきなり全国展開するのではなく、特定の市区町村で小さく試す。システムであればいきなり仕組みを構築せず、まずは手探りでうまくいく部分を探す。スタートアップ向けのアドバイスで「スケールしないことをやれ」とよく言われる。例えばAIとチャットして美味しいレストランを探すサービスを企画し、作ることを考えてみる。AIのロジックがコアだと思って先に作ってしまいがちだが、実はその前にニーズを検証した方がよい。そのためにはシステムの裏側で人が待機して、ユーザーからの入力があったらその条件に合う店を食べログなどで検索して探し、AIのフリをして返事をすれば良い。これでユーザーが満足するか、感動する体験になるかは十分検証できる。それが確認できたらその時初めてAIのロジックに着手する。人間が対応するのはマンパワーが必要なのでユーザーが増えてくると回らなくなるが、数十人くらいならなんとかなる。スケールしないことをやることで、短い時間でサービスのヒット確率をあげる。AIのロジックを作るまでもなく、世の中に受け入れられるコンセプトかを確かめられる。

新しいサービスを作るときも、最初はユーザー数の拡大ではなく誰かに深く刺さる体験を探す。自分や友人、身近な困っている特定の誰かを助けるものを作る。それを磨いていってしっくりくるラインまで来たら拡大路線に入る。小さく試して、それから拡大する。このパターンは胸に刻んでおきたい。

久しぶりに朝から外に出る予定があり、早朝に起床するつもりだったが寝坊。待たせている人もいるのでめっちゃ焦るが新幹線の距離なのでどうしようもなく、そこから出せるだけのスピードで準備して出発。予定外の出来事が起きるとどうしても動揺してしまうが、焦ってバタバタするとさらに悪い結果をもたらすことが多い。こけて怪我するとか、逆方向の電車に乗ってしまうとか。ミス直後はできるだけニュートラルな心持ちで行動し、落ち着ける場所に来れたらゆっくり反省する。傷口を広げないための自分なりの行動指針だ。

こういう思考がどこに由来するかと考えてみると、エンジニアの事故対応の仕事が元になっている。事故とはシステムの障害や不具合のことで、特にサービスが使えなくなるなどユーザーに悪い影響を与えるものを事故とラベルづけするようなイメージ。ソフトウェアは複雑でバグをゼロにするのは難しく、事故ゼロを目指しつつも、事故が起きたときにスムーズに対応・復旧するスキルもまた必要になってくる。この事故対応をするなかでいろいろと学んだことがある。

まず、事故の原因の多くは単純なミスに起因する。ソースコードの書き間違いとか、仕様認識ミスとか、確認ミスとか。複雑で避け難いミスと比べ、単純なミスをすると自分の責任であることが明らかなので焦る。なんとか取り返そうと思う。影響ユーザー数が増える前に、誰かに気づかれる前に直したい、というモードに入る。ただここで焦って修正するとその修正が別の事故を引き起こす。ソフトウェアは複雑で、ある場所の修正がまったく別の箇所に影響する。焦って狭くなった視野では全体を見通せず、修正のはずの変更が傷口を広げていってしまう。

ベテランの先輩方をみると、事故などのアクシデントが起きたときほど落ち着いて行動する。内心はどうか分からないが笑みを浮かべている人もいる。どうしても焦ってしまう局面であることを理解し、そのうえで普段と同じ行動に努める。自分の視野が狭くなっていることを分かっていれば対応はできる。紙にパターンを書き出すとか、不具合の心当たりを人に話すとか、修正方針をレビューしてもらうとか。普段だったらしないような行動をしているな、と自分で感じたときは黄色信号。外からの視点を入れて平常心を取り戻す。自分のミスに人を巻き込むのは気が引けるが、被害が拡大するよりはマシなので人を頼って良い。自分のミスを素直に話せるか、緊急時に人に頼れるかはチームの雰囲気によるところも大きい。問題を引き起こした人が責任をとらされるチームだと自分のミスを隠したくなる。この辺りの雰囲気は普段のやり取りや以前の問題の扱われ方によって決まるので、オープンに話すのが良いという雰囲気を作っていきたいと思っている。

イージーミスをしてしまったとき、自分がこんなミスをするなんて...とショックを受け、なぜそれが起きたか分析したくなる。でも分析の前に、まずは事故の対応を優先した方が良い。ソフトウェア開発ではGitなどの仕組みによりひとつ前のバージョンに戻すことが簡単なので、まずシステムが動くことが確認されている状態まで戻し、ユーザーへの影響をなくしてから問題の分析にあたる。焦ってるとこの順番もよく間違えてしまう。

事故の対応が終わり、落ち着いたら問題の分析をする。なぜ事故が起きたのか？何があれば事前に食い止められたのか？いろんな角度から深掘りをする。連携のミス、作業者のスキル不足、確認の漏れなど根本的な原因が特定できる。今後同じような問題の発生を防ぐための仕組みを考えて構築する（再発防止策）。どんな事故であれ原因は単一ではなく、複数の要素に起因することが多い。すべての再発防止策を採用するのが正しいとも限らない。長期的にみるとフローが肥大化し、サービスの提供スピードは落ちていってしまう。ここはサービスの特性を見つつ、どれだけ時間がかかってもバグ0に近いものを選択するのか、それともイレギュラーなケースは許容して9割防げれば良いとするのか、判断が必要となる。

今回の寝坊を分析してみると、Xiaomi Smart Bandへの過信がある。Smart Bandではアラームの時間に腕時計が振動して起こしてくれるが、これが音でのアラームよりかなり起きやすい。アラームに気づかず寝過ごすことがなくなり、かなり気に入っている。海外旅行で出発が早朝になるときもこれで起きれた実績もある。そういう背景からアラームの設定をこれ単一にしてしまった。再発防止策として、今後早朝に起きる必要があるときはiPhoneのアラームと2台構えにしたいと思います（遅れてすみません）。

ものづくりはクリエイティブな作業なので、取り組むには余裕が必要。この余裕は分解すると時間的余裕と精神的余裕がある。時間的余裕は日々の忙しさで、たとえば仕事で残業続きだったり毎日がミーティングだらけだったり、土日のどちらも予定が詰まっていたりすると余裕がなくなる。サービス設計や良いユーザー体験を考えることは時間がかかる。ああでもないこうでもないと頭を捻る必要があるので、30分スキマ時間あるからここでこの判断をしよう、という類のものでは本来ない。ずっと考えてて、あるときスッと腹落ちするタイプのものだと思っている。なので時間がたっぷりあることは重要。幸い転職してからは残業ゼロ、ミーティングも週に2-3時間しかないので良い環境で仕事できている。

精神的余裕は気持ちの問題で、何か大きな懸念があると目の前に集中できなくなる。たとえば引っ越しを控えていてライフラインの手続きをやらないとと思ってたり、胃カメラをしたら変性している粘膜が見つかり病理検査の結果を数ヶ月待っていたり。気になること・心配事があると気が逸れてしまって集中できない。友人やパートナーと不穏な雰囲気になるとかもそう。心穏やかに過ごしたい。

森博嗣先生の著書「夢の叶え方を知っていますか？」を読んでから、幸せとは没頭する時間のことだと定義している。何かに没頭するには時間と精神の両方に余裕がないといけない。健康で、自由に使える時間があって、打ち込める何かがある。没頭する条件が揃ってるだけですでにかなり幸せなのかもしれない。

余裕がないときの対処法。ひとりで悩んでいても仕方ないんだよ、というのを自分が腹落ちできるまで深掘りする。何が気になってるのか、何が不安なのか、自分はどうしたいのか。行動できるものはすぐにしてしまえば良いし、検査待ちなど自分ではどうしようもないものは悩んでいても結果は変わらないと理解する。あとは部屋を掃除したりするのも意外と良い。机のまわりやキッチンなど、散らばっているものを整えると雑音が減って余白が出る。最近自転車の空気が減っていたので、近くの商業施設に行って空気を入れた。それだけのことで、自分で問題に対処できるという自信になりリズムが生まれる。前向きに考えると余裕を生み出す工夫をしやすくなる。