Feedback Loop

一年の計は元旦にありというが、自分の中では年よりも年度末の方が区切り感がある。3月に誕生日があって年を重ねるからかもしれない。年始に考えたときから変わらず、今年の抱負は「良い日を増やす」としている。

良い日とは何か？大きな前進じゃなくて良いので目指す方向に向かって着実に一歩を進めること。特別じゃない普通の日を大事に思えること。良い日を過ごせると気分がよくなり、また次の日も良いコンディションで臨めるようになる。そしてこのサイクルを繰り返すと集中状態が高まりゾーンに入る。昨年末に読んだ「ゾーンに入る」という本に書かれていた内容だが、今年はこれを意識していきたい。

自分なりの良い日の作り方を考えてみた。大きく二つあり、一つは家族や友人など大切な人に親切にすること。対象は大人数じゃなくてよく、ごく身近の数人を大切にできればそれで良い。もう一つは没頭する時間をもつこと。個人開発でも将棋でもなんでも良いが、いまこの瞬間に向き合えると大変心地よい。この二つを支える根底に健康がある。肉体的健康と精神的健康。散歩や水泳で運動の習慣を作りつつ、たまに友人となんでもない時間を過ごす。今年度はこんな感じでいきたい。

最近読んだ複数の本で、小説家の村上春樹の習慣について触れられていた。午前4時に起きて5-6時間続けて執筆。午前の間に仕事は終え、午後からは運動や読書、音楽を聴くなどして過ごすらしい。夜は21時就寝で、365日このリズムを繰り返す。

「学ぶは"まねぶ"」ということで、まずはそのまま真似してみた。朝7時に起きて13時頃までプログラミング、そして午後は運動や読書をして過ごす。朝起きがけの時間は頭がクリアで確かに創作活動に向いている。体力ゲージも回復してるし雑念がないので、目の前のことに集中できる。何も考えずにいると仕事開始後の最初の仕事はメールやビジネスチャットの確認になるが、頭がクリアな時間にするには勿体無い。先にクリエイティブなこと、それからコミュニケーションの仕事という順番が滑らかに進む。

予定通り午前にプログラミングを出来たとして、午後以降はもうプログラミングをしないというのが地味に難しい。やりかけの部分が気になったり、ちょっとだけ続きをやろうとして夜も作業してしまったり、手を止めて翌日に回すというのが中々出来ない。読書や買い物よりもプログラミングが面白いのでそうしてしまうが、これをやり始めると一日中作業していることになって疲れていく。5-6時間ほど集中して作業できれば十分で、追加で時間をとって一日でブーストするのではなく、毎日その5-6時間を着実に積み重ねることを意識する方が結果的には遠くまでいける。

最近読んでいる将棋の本に「普通の手を積みかねて有利な局面を作っていく」と書かれていた。一発で形成逆転できるムーンショットを実現するのは難しい。良いと思う方向に少しずつ、毎日の積み重ねで近づいていく。肉体や精神の健康に気を配りつつ、自分のリズムを作ることにしばらくの間は向き合いたい。

仕事のセオリーであったり世間一般の常識であったり、大人になるほど「こうすべき」が身についていく。先人が積み上げたノウハウ集なので従えばある程度はうまくいく。しかしと周囲と同じ行動をすることになるので成熟してくるとそこでは差がつかない。方法論ではなく、自分の見てきたものや考えてきたものの反映が差別化になる。

自分が「すべき」に捉われていると他人にもそれを求めるようになる。相手に勝手に自分の基準を押し付ける。相手としてはそんなもの知ったこっちゃないので、当然基準に沿わないことも多くなる。それを見てその人がダメだとか、仕事ができないとか判断を下していると世界はどんどん窮屈になっていく。

「すべき」ではなく「したい」を大事にする。自分はこうしたい、こう考える、というのを信じてみる。世の中の常識とは違っても、自分の内なる声に従う方が後悔が少なくて済む。人に依頼するときは自分の想いを伝えて、その上でどういうものが返ってくるかはその人次第。その出来は良し悪しというよりは自分とその人の相性なので、そういうものとして受け止める（認識がズレてるなどそれ以前の問題であれば修正する）。

組織やチームでいうと、「すべき」をルールでガチガチに固まるのではなく、「こういうチームでありたい」というビジョンを伝える。しつこいぐらい何度も伝える。目指す先だけど共有できてれば、あとは各人がそこを目指して自分なりの最高の道筋で進んでいける。楽しんで創意工夫するチームは強い。そういうマインドが育まれる組織でありたい。

最近は自分がどういう状態であれば幸せかをよく考える。年齢的なものもあるし、年収をずっと上げていくような生き方に息苦しさを感じるというのもある。「イノベーション・オブ・ライフ」には自分が大切なものに時間やお金を配分する重要性が書かれている。大切なものは人によって違う。まずは自分は何があれば満たされた気持ちになるのかを理解したい。

10年ほど前、近所に広島焼の美味しいお店があってよく通っていた。そこはカウンターだけの小さなお店だったが、たまたま隣に座っていた同世代くらいの方に話しかけられた。その人は絵本作家を目指しているらしく、良い絵本とはどういうものかを教えてもらった。彼曰く幸せの形は多様で表現が難しい。しかし不幸はある程度みんなイメージできる。なのでよく売れている絵本は不幸をあえてピックアップし、そこから解放されるような描き方をしているものが多いらしい。幸せを定義して目指すのは難しいので不幸をひとつずつ剥がしていく考え方。たまに思い出しては何かヒントをもらえているような気分になる。

普段生活していて、私たちは小さなストレスを細かく受け続けている。「仕事が本当に嫌いで出社したくない！」などの強いストレスは表面化するので対処されるが、細かいものはつい見過ごしてしまう。こういったものが少しずつ自分のエネルギーを削っていってしまう。自分は何が不安なのか？何を恐れているのか？落ち着いた場所で自問し、それを紙に書き出すと整理されて心に余白ができる。すぐに対応が難しいものでもモヤモヤの正体が分かればかなり気は楽になる。エネルギーは増やす必要はなくて私たちに元々ある。それを削っている要因に目を凝らすようにすれば、不幸から少しずつ離れていけるかもしれない。

昨今のWebサービスは作ることよりも使ってもらう方が難しい。技術の進化により作ること自体はかなり簡単になった。小慣れた機能や美しいデザインも作れる。難しいのはサービスを知ってもらい、そして使い続けてもらうことである。

「ビルドインパブリック」という手法がある。これはリリースしたサービスの開発状況や改善の様子をXやブログで公開していき、それによりサービスのユーザーを増やしていく方法。自分の使っているサービスの新機能が出来上がっていく様子を知れるのは何となく面白い。リリース時点では機能が足りてなくても、その後すぐに追加されそうであれば利用を続けてもらえる可能性もあがる。そんな事情もあり、特にXなどでコミュニティが形成されている開発者に向けたサービスなどではビルドインパブリックがよく用いられている。

認知してもらうには継続的な発信が必要だが、自分の開発しているものであればネタには困らない。そういう意味でビルドインパブリックはよくできた手法だが、個人的には落とし穴もあるように感じる。開発で難しいのは後方の互換性を保つことで、新しい機能をリリースする際に他のシステムや過去データが壊れないように気をつけるのは思った以上に難しい。公に発信するとなるとトピックが欲しいので次々とリリースすることに力学が働くが、突貫で作ってしまうと負債になり後半の開発にブレーキがかかりだす。では作り込んでから一気に出せば良いかというとそうでもない。市場のタイミングを逃すリスクがあったり、リリースしないとそもそも反応がないので誰も必要としていないものを作り込んでいる可能性がある。結局はバランスということになり、どこに重心を置くかは開発チームの性格によって違いが出る。

日本だと有名なのはInkdropというサービスを開発しているTakuyaさん。開発の様子や考えなどを発信しながらファンを増やされている。見た目上はブログを書くだけなので簡単に見えるが、その内容が芯を喰ったものであったり、その人なりの考えがあって読み応えがあったりでないとすぐに人は離れてしまう。そして何よりまず魅力的なプロダクトがあるというのが大前提。そもそも価値のないプロダクトでは周りをどれだけ豪華に飾っても真に響くことはない。それに良いプロダクトであればそれ自体に宣伝効果がある（クチコミで広がる）。まずはコアのプロダクトに集中、そして次に広める。どちらも大事だが、順番があることは忘れないようにしたい。