Feedback Loop

プログラミングをしていると、難しい場面にあたることがある。意図せぬ不具合、原因不明の挙動、ドキュメント通りに実装しているのになぜか動かない、など。プログラミングというと新しい機能を作り上げていくイメージがあるが、実はこういう調査系の時間がとても多い。3時間くらい問題を調査してコードの修正は1行だけ、というのも珍しくない。

問題を調査するのに大事なのが原因の切り分けで、これはセンスが問われる。経験が浅いとよくやってしまうのがいきなり問題を修正しようとコードを書き始めることで、これは良い手ではない。全体像が見えない状態での修正は根本原因の解決にならなかったり、別の箇所で同様の不具合が発生しているのに気づかなかったり、新たな別の不具合を生んでしまったりする。まずは全体を見渡して仮説を立て、ツリー構造の上から順にそれを確認していく。ある値を変更して不具合が再現するのを確認したり、ログを追加して不具合が起きたときに期待通りの出力があるのを確認したり、少しずつ問題を絞り込んでいくのが良い。

こういう問題特定のアプローチはプログラミングの外の世界でも役立つと思っていて、なにかトラブルがあったときにいきなり解決に当たらず、まずはその問題を網羅的に考えるようにしている。人間関係の揉め事であればAさんとBさん両方に話を聞く、他のメンバーで同じように感じている人はいないか聞く。サービスの新機能が使われていない場合は慌てて機能を継ぎ足すのではなく、なぜ使われないのかを関係者で議論し、そこで出た仮説をデータ分析で裏付ける。結局同じ対応に着地することも多いが、こうした議論を経るのと経ないのとではその後がまるで違う。長い目でみると地に足のついた議論ができるチームになる。

最近は仕事で採用面接をする機会も多い。問題特定を特定する思考法はとても大事だと思うが、曖昧なスキルなため履歴書には書かれない。どういう仕事をしていますか？と聞いて答えられるようなものでもない。強いていうなら論理的思考と近いが、それだとMECEとか三段論法とかが出てきてちょっとニュアンスが違ってくる。ただ、履歴書には書けないが、直接話せばすぐにわかる。こちらの質問を解釈する力や聞かれたことに順序立てて答える力。そういうところに自然と染み出しているように感じる。　

「いまだ成らず 羽生善治の譜」を読んだ。

棋士界の動向をまったく知らない自分でも羽生さんは知っており、子供の頃からなんとなく好きだった。数年前に読んだ「大局観」には千手先を読むことから直感的に次の一手がみえるようになった思考の変化について触れられていて、経験を積んでいくといずれロジックを飛ばして最良手に辿り着くことがあるのは面白い感覚だと思った。羽生さんの何千分のイチのスケールだがこの感覚は自分の仕事でも感じるときがあり、Webサービスの仕様を検討する際にロジックをあまり考えずともすぐ決められるときがある。そしてそう判断できる理由を考えていくとこれまでの意思決定であったり、経験してきたことが礎になっていることが分かり、大局観だなぁと本を思い返したりしている。

本書はそんな羽生さんについて書かれた一冊。羽生さんといえば最強というイメージがあったが最近は勝率も落ち負けているらしく、A級から落ちてB級になったりもしているらしい。かつての最強がまた挑戦者へ。AIが登場し研究の方法がまるで変わったりもする。それでも羽生さんは心を曲げず、好奇心をもって探究していく。

本の構成で面白いのが、ドキュメンタリーなのに羽生さん本人には一言も話を聞いていないこと。本人ではなく周りのプロ棋士の生涯を描き、そこに羽生さんが登場していくことで外堀から羽生善治像が描かれていく。羽生さんの背中をみながら苦しんだり、タイトル戦で挑むも自分のペースを崩して負けたり、はじめての一勝を手にしたり。存在感というか、羽生さんが強く純粋であるゆえに誰もそこを無視して通り過ぎることはできず、向き合い続けさせられる。こういう構造のドキュメンタリーは初めて読んだがめちゃ面白く、2日くらいで一気に読み進めた（どの章もパンチラインだらけ）。

印象に残っているところを二つ。かつてのプロ棋士は特定の政治家と仲良くなったりするのが当然だったが、羽生さんはそういったものに関せずより良い一手を追求し、それが将棋のゲームとしての面白さを世間に伝え、将棋が広まっていったこと。伝統や精神性ではなく合理的に考えるのはゲームの参加者を増やすことにもつながる。会社のよくわからない捻れた構造は末端メンバーの思考停止につながることが多いと感じていたが、その理由が言語化された気がした。

もう一つは、勝ち続けているときでも違う戦法を取り入れる、負けても微笑みながら感想戦に挑むなど、好奇心と探究を忘れないこと。誰かとの勝負だと思うと負けは良くないことだが、より良い一手を追求する道だと思うと勝ちも負けもその材料になる。最近「習慣化を意識すると自分との勝負になるので、人との比較から卒業できる」みたいな一文をなにかで読んだが、それと重なる部分があるように感じた。

最後に、羽生さんが藤井くんとのタイトル戦前に語った一言。

「一局の将棋は後悔だらけですが、後悔の多い人生こそ充実している。甲乙付けがたい局面、難しい状況にたくさん出会っているということですから。」

こう言える・思える人間でありたいものです。

「ラブ トランジット2」を観た。恋愛リアリティーショー番組で、男女各5人が1ヵ月くらいホカンスして関係を深め、最終日に告白して両思いなら恋人を作って帰るというもの。最大の特徴はXという要素で、これは元カレ元カノを意味する。つまり参加者のなかに昔付き合っていたパートナーがいるが、それが誰なのかは周りに気づかれないように行動する。Xの新しい恋にモヤったり、Xとの復縁を願ったり、新しい恋愛というよりはXとの過去の恋に区切りをつけるために参加したり、このシステムのおかげで他とは一味違ったつくりになっている。

バチェラー・バチェロレッテは真実の愛を見つけるというコンセプトで、1人を15人くらいが取りあい、一番良いと思える人を最後選ぶ仕組み。徐々に人数が絞られていく要素は見ていておもしろいが、最後まで残った一人と付き合っても番組が終わってから別れる・婚約解消する・別の女性と浮気するなど、短い期間でいきなり恋愛のボルテージをあげる難しさに世間が気づいてきている気がする。その点ラブ トランジットは元恋人という関係性を持ち込んでいるので、短い期間でも深い付き合いになる場合がある。実際ラブトラのシーズン1では結婚するペアも出るなど、恋愛番組の方向づけとしてはかなりうまくいっている印象。

さて、ラブトラのシーズン2。内容は面白かった。Xが誰なのか予想しながら観る謎解き要素や、綺麗な街や自然の映像、そしてなにより編集のうまさで何度も唸らされた。普通は10人(5カップル)もいると視点が散らばってしまうが、ラブトラのスタッフは時系列をうまくいじりながら1カップルずつフォーカスしていく。この技術が他の恋リア番組に比べて頭ひとつ抜けていて、驚いては数秒戻って再確認、を何度もした。ただしこれは諸刃の剣でもあって、編集過多になると視聴者の思想を操れてしまう（番組が見せたいように出演者の印象を決定できる）。また、どの関係性にフォーカスするかで番組の進行がまるで変わるので、そこのセンスが問われる。実際シーズン2でよく抜かれていたカップルがいたが、無用に長く扱われすぎだとX（旧Twitterのほう。ややこしい）で多くコメントされていた。誰を主役にするか、誰を悪者にするか決められてしまう難しさを表している。

シーズン1との違いでいうと、MC陣のコメントがVTRにオンタイムで被せられるようになっていた。シーズン1のときはVTRをある程度見て、一区切りついたあとにスタジオ映像に切り替わってそこまでの感想を話していた。シーズン2ではVTRをみながら副音声的にコメントするようになっていて、それができるようMCも麒麟の川島さんや指原さんというコメントの瞬発力の高い人選になっていた。個人的にこれはかなりネガティブで、映像をみながらコメントしたりツッコんだりするのは視聴者がやる仕事だと思う。面白くはあるが、MCがコメントするとそれで完結してしまい視聴者が参加できる余白が少なくなっているように感じた。Xが誰かを予想したり整理しながら観るのが結構難しいのでそれを解決するためのアップデートかなと推測したが、できればシーズン3では副音声のON/OFFを選べるなど改善を期待。ちなみに今回のシーズン2で一番笑ったのはスンギの「アニョハセヨったら飲み干せよ」とまさとの足ギターです。

プログラミングをしていると、よくわからないけど何故か動く、みたいなことがある。目当ての実装をググればそれなりに情報が得られる時代。実装の中身を理解していなくてもコピペだけでそこそこのものは作れてしまう。

ただ自分の肌感だと、理解が曖昧なとこは立ち止まってその場で調べたほうが結局早い。その場を適当に凌いで前に進んだ先で原因不明のバグにつきあたり、よく調べてみると曖昧にしていた部分が影響してたりすることがとても多い。理解を正確にするために誰かのブログではなく公式ドキュメントをよく読み、簡単なデモアプリを作っていろいろ試す。こうしておくとシステム全体への理解度があがり、何か想定外のことがあってもすぐにアタリをつけて修正できるため、結局早い。長いスパンで考えると同じような実装をするタイミングが必ず来るため、そのときにちゃんとした理解をもっていると爆速で実装できて、結局早い。

プログラミング以外の仕事でも近しいことが言える。チームで働いているとき、判断を求められて意思決定するときがある。その場凌ぎで曖昧な判断をすることもできるが、よく考えて誰にでも説明できる自分なりのロジックを作ったうえで判断するほうが結局早い。まったく同じ判断は二度ないものの意思決定の内容は抽象化すれば似てることが多く、ロジックを一度作っておくと次からの判断を爆速にできるようになる。例えばプロダクト開発でよく求められる判断として、利益をあげるような機能とユーザーの利便性をあげる機能のどちらを優先するか、というものがある。正解はなくバランスが求められる判断だが、自分は小さいチームのうちはユーザーの利便性をあげる機能を優先していくのが良いと思っている。ユーザーの抱えている課題を解決して、それに対してもらっている対価が利益だと整理しているので、まずは課題をたくさん解決するのが良い。ただし決め打ちではなく、チームの資産状況とかユーザーの数とか開発にかかる工数とか、多くの変数を考慮して細かくチューニングは必要。自分なりのロジックにその時の状況をトッピングしていくのがイメージに近い。

GoogleやAIに聞けばすぐに答えが得られる時代だからこそ、逆に時間をかけて理解することが違いになるかもしれない。目先でつくっている機能の提供が1週間遅れても実は別に大した影響はないので、落ち着いて理解を深めながら前に進むようにしたい。

フィリピンから帰ってきてから読書欲が高い状態が続いている。旅行中に読んだ本に面白いものが多く、もっとこういう本が読みたいという気持ちでいろいろ読み漁っている。

知人が作っているBookBankというアプリで読書記録をつけているが、このアプリでは月ごとの読書数を振り返る機能がある。ここ数年を振り返ってみると月ごとにかなりバラつきがあり、よく読むときは月10冊を超えるのに対し、月に1冊も読まないときもある。その理由を考えてみると、個人開発に没頭している時期に読書から離れていることがわかる。Webサービスやアプリを作っている間はそれに夢中で、本を読みたいという気持ちが沸かなくなる。

この「何かに興味を抱くとそればかりやってしまう」のは自分のスタイルで、思い返せば子供のときからそうだった。学校から家に帰ってきて漫画を読みはじめたら夕食までずっと漫画を読んでたし、勉強をはじめたら夕食まで机に向かって問題を解いていた。書籍の方の「君たちはどう生きるか」でコペル君が同じことをやり続けるのが人間の習性だと気づくシーンがある。ここを読んだときはわかる！と思ったのをよく覚えている。習慣術みたいな文脈で、朝起きたらまずやることで必要なものを机の上に置いてから寝ましょう、みたいなテクニックがよく語られる。毎朝日記を書くならノートを置く、体温を測るなら体温計を置くみたいな。朝起きて最初にやったことが流れを生むという説だが、これも理に適っているいると思う。逆に距離をおきたいものは収納の中に隠して腰を重くすれば離れられる。

習慣の観点でいうと読書したりしなかったり、自分の習慣はあまり安定していない。そういうプロと話す機会があるとしたら1日15分でも良いから毎日読みましょう、とか言われそうだ。でも個人開発に没頭している時期はすべての時間を注ぎ込みたくなったりする。本を読むことはすでに生活に溶け込んでいるとは思うので、ベストプラクティスみたいなものに捉われすぎず自分なりに読書を楽しめれば良いかなと思っています。