Feedback Loop

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

人に話しかけた言葉は同じ重さで返ってくる。これを言葉のエネルギー保存の法則と呼んでいる。例えば仕事でSlackに長文を書くと長文が返ってくる。優しい口調で書くと優しく返ってくるし、手厳しいコメントにはこちらも応戦してトゲトゲした文章を返してしまう。

エネルギーがちぐはぐだと違和感を感じる。例えばちょっとした質問を一行で書いたのに20行くらいの長文で返されると萎える。一生懸命考えた仕事の提案にSlackのリアクションの絵文字ひとつだけつけられて終わると肩透かしを喰らう。何かを人にするとき、同じ熱量でのアンサーを期待する。

熱量だけではなくフォーマットも保存される。固い文には固い文が、カジュアルにはカジュアルで応答される。最初にどういう話し方をするかで会話の進め方がある程度決まる。私は肩肘張らずに話せる方が好み。言い回しの丁寧さとかの余計な装飾は最低限にした方が、話題そのものに集中して話せる気がする。なのでできればフランクに話したい。ただフランクすぎると失礼になったり、くだけすぎて場にそぐわない雰囲気になるとそこに強い違和感が生まれてそもそも話を聞いてもらえない。気楽にいきたいが守るべき規範はある。言語化されていないラインを探りながら調整していく。

新卒の頃、1000人くらいが入室しているチャンネルでとあるベテラン社員がタメ口でメッセージを投稿していた。それは誰かの疑問に対して議論のコメントを投稿したものだったと記憶しているが、その光景に強烈な違和感を覚えた。自分なら1000人近い知らない人間がいるなかでそんなにフランクには発言できない。その人がなぜそう振る舞えるかというと、昔から会社にいて知り合いが多いことと、会社での立場的にも上のポジションにあることの影響が大きい。そう思うと勤続年数や権威があると下には強く当たって良いと示されてるようで嫌だった。敬語をちゃんと使おうという話ではない。日本語を第二言語として勉強した人が、敬語のない表現を書いていても気にならない。大事なのは敬語の完全さではなく、相手にリスペクトがあるかどうか。自分が正しいことを前提に置いて相手を嗜めるようなコミュニケーションは好きではない。人は間違えることを前提にしつつ、自分の今時点の意見を明確にしつつも相手の話をよく聞き、お互い理解を深めながら折り合いをつけられるようになっていきたい。

個人開発は平日の仕事終わりや週末の趣味の時間でやっている。短い時間で何かを作ろうとするとアウトプットを焦りがちだが、実際はすぐ完成させようとせず骨太に考えていく方が結局早い。

例えば日記アプリReliefで、iPadで手書きで日記を書ける機能を追加した。この手書きのデータを、他のiPhoneやiPadで見るときにどう表示するかを考える必要があった。日記を書くときは縦横の画面目一杯にキャンバスが表示され、そこに文字や図形を自由に書き込める。でも他のiPadでは画面のサイズやアスペクト比が違うし、iPhoneならもっと違う。どう表示するのがスマートか？結論としては、表示デバイスの画面サイズに合わせて手書きデータを拡大・縮小することに落ち着いた。

拡大・縮小するときに必要なのは倍率の計算で、キャンバスが縦長なのか横長なのか、縦方向に余白があるのか横にあるのか、少し数学的に考える必要がある。開発当初はソースコードの実装を変更しながら、色々値を入れ替えて試行錯誤していた。しかし2時間くらいかけても上手くつくれない。画面の拡縮のパターンを網羅できていなかったり、比率の計算式が間違えてたりしてよくわからなくなる。こういう時、あと少しでできそう！となってから意外に時間がかかる。色々試しているうちに今何が問題なのかわからなくなり袋小路に迷い込む。もう少しでできそうなのに上手くいかなくてイライラする。そうすると余裕がなくなるのでさらに時間がかかる。

こんな時はパソコンを閉じ、ノートとペンだけ持ってカフェに行く。パソコンがない環境で、紙にいろんなパターンを書き出したり、iPadとiPhoneの画面サイズを書いてみて比率を算出する数式をつくったりする。パソコンがないのですぐには試せない。だから紙の上で手を動かしていろいろシミュレーションするしかない。

そうしていると、めちゃめちゃ種類があると思っていた計算が、実は3パターンくらいに集約できることに気づく。計算式もシンプル。いろんな例外的なパターンを試してみても、その式でうまく表現できそうに思う。こうなると早く試してみたくなり、飲み物を飲み干して帰宅する。パソコンに向かい、ノートを見ながらロジックを実装する。ちゃんと期待どおりに動く。脳汁が出る。2時間以上手を動かして解決できなかった問題が、カフェでの20分で解ける。しかも行き当たりばったりではなくロジックも完全に理解した状態で。こういうことは経験的にもよくあり、狭くなりすぎた視野をいったんリセットする重要性を感じる。カフェに行くまでに軽く体を動かすのも良い切り替えになっているのかもしれない。心に余裕が戻れば、本質的な思考を取り戻せる。

何か良いサービスや機能を思いついたとき、早く試したくなる。世に出して反応を見たい。便利な機能を早く使ってもらいたくなる。でも実装がうまくいかなくて焦っている時は、一度立ち止まり違う視点で考えた方が結局うまくいく。マーク・ザッカーバーグの格言に「完璧を求めるよりまず終わらせよ」というのがある。完璧にこだわって何も出せないのは本末転倒ではあるが、理解しにいった方が結局早いこともあるというのは忘れないようにしたい。