Feedback Loop

プログラミングで少し難しいことをしている時、いきなり完成物を作ろうとすると逆に遅い。これは何かに躓いた時にそれを直視せず、ゴールの方だけ見てもがきながら進もうとしてしまうため。簡単なタスクならそれでも走り切れるが、難易度が高いものでは躓きが次の躓きを呼びこのやり方では挫折してしまう。遠回りに見えてもひとつずつ理解した方が結局早い。

趣味で将棋をやっているが、将棋ウォーズで4月中に2級にあがることを目標にしている。目標がある方が学習にゲーム性があって良いかと思ったが、一局一局を大事に振り返らずにすぐ次の対局を始めてしまい積み上がらない。これでは同じミスを繰り返してしまう。目標をめがけて真っしぐらに進むよりも、丁寧に一歩ずつ進んだ方が結局早い。

プログラミングも将棋も誰かに成果を求められてるわけではない。急ぐ必要は早いのになぜ短期で成果を出そうとしてしまうのか？「早くリリースしたい」「早く上達したい」、その早さを求める自分の心はどこから来ているのかと考えると他人との比較が根底にあるかもしれない。同じ物事を自分の方が早くできた、というのは子供の頃から褒められることだった。そのロジックは無意識に刷り込まれている。いまリリースしないと機を逃すかも、という焦りも他人より上手くサービスを届けれる自分でいたいという比較級。比較は幸せから遠い位置にある行動だし、機を逃す如何もタイミングよりサービスの品質に問題があって失敗する方が遥かに多い。

人の期待に応えようとすればするほど、自分の力を示そうとすればするほど成果を焦り逆にゴールが遅くなる。本当は自分のペースで一歩ずつ進めばそれでいい。目標を真面目に捉えすぎず、もっと遊びの要素がある方が上手くいくのかもしれない。

村上春樹は朝4時に起きてそこから4-5時間ぶっ続けで小説を書くという。朝にいろいろ出来ると気持ち良いというのは知っているので試してみたがまるで続かない。朝は起きれるがその後ダラダラ過ごしてしまう。家だと誘惑が多いのがよくないのかとカフェに行ってみたりもしたがカフェでゆっくりしてしまう。体のスイッチをなかなかオンにできない。

集中のスイッチを入れるにはとにかく始めること。やる気が出るのを待つのではなく、小さなことで良いから着手する。手を動かす、頭を働かせるうちに少しずつ没頭していく。これまではこうやって集中モードに入ってきた。今やプログラミングはAIと一緒にやる時代である。人間がやるのはAIへの指示で、一度指示したら実装されるまでのちょっとした待ち時間がある。この待ち時間が没頭状態を解いてしまう。調べ物をしたり、次にやるタスクを考えたり、ひどい時は将棋をしている。マルチタスクは没頭の対義語であり、目の前に集中できなければリズムに乗ることも難しい。AIの登場による新しい悩みである。良い解決策を考えなければいけない。

良いリズムを作るためにどうすべきか考えてみる。まずは、集中して作業する時間を1日2時間で良いとしてみる。いきなり村上春樹の領域を目指すのは無理がある。1日4-5時間やらないと、と思うと朝にグダってしまったときに悲しくなる。目標を立てて自分を奮い立たせられるなら良いが、残念な気持ちになる機会が増えるくらいなら目標は低いほうがよい。次に1週間または1日のテーマを決める。今日はデザイン、今週は利用規約を作るなどと宣言して脳をそのモードにする。Webサービス作りは終盤になるとあれもこれもやりたい状態に陥る。どのカテゴリも重要ではあるので、テーマを定めて切り替えながらひとつずつ戦っていく。

最後にAIエージェントの待ち時間だが、これはチャットを毎回挟むのではなくまとめて複数の仕事を依頼する形で試してみたい。今は1つずつチャットに打つので3分に1回レスが返ってくるのが、10個まとめて依頼すれば確認は30分に1回で済むようになる。依頼するタスクを小分けにしたり、事前の準備は必要となるがマルチタスクを強いられるよりはかなり良い。考えてみればジュニアのメンバーに依頼するときもタスクは小分けにする。「分からないことがあったら聞いてね」とすると自分の仕事に割り込みで質問が飛んでくるようになる。そんな時は話しかけるのではなくチャットに質問を書いておいてもらったり、自分で探せるようにドキュメントを整理して渡したりと人間の場合はする。事前情報がなければ良い仕事をするのが難しいのは人とAIも同じようだ（今のところは）。

Web系の会社で働いていると、正社員ではなくフリーランスとして仕事をしている人にも多く出会う。彼ら・彼女らは専門の知識を提供する代わりに対価をもらう。正社員との待遇の違いは企業によって違うが、基本的には正社員は会社が「育てる」意識が強い。良い経験を積ませてエースとなる人材をつくる。そのために目標や評価の制度もある。フリーランスは成長よりも即戦力が求められる。仕事の価値を高める方法は自分で考える必要がある。

フリーランスは自分で取引先を見つけなければならない。話を聞いてみると昔の職場や、知り合い経由で仕事を紹介してもらうケースが多いらしい。良い仕事をすれば別のタイミングでも声がかかる。とてもシンプルだ。

落とし穴として、自分の年齢があがっていったとき、同世代が仕事をコントロールする立場から少しずつ離れていくというのがある。知り合いから仕事をもらえる機会がそもそも減る。自分なりの専門性を分かりやすく提示したり、世代を超えていろんなタイプの人と知り合っておくなどが必要になる。

自分はというと、あまり人脈を築くのに熱心なタイプではない。そうなれない。人と話すのは好きだがそこから仕事に繋げるみたいな発想にはまったくならず、ただその場を楽しく話せればそれで満足してしまう。

Webサービスを考えて作るのが好きで、それが仕事になればうれしい。これなら人からの依頼がなくとも自分で無限に仕事を生み出せる。その代わり仕事の不安定性がめちゃ高い。誰から仕事をもらうのではなく、自分で作り出すのはそれなりにエネルギーが必要になる。

4月中に将棋ウォーズ2級にあがることを目標に毎日少しずつ勉強している。羽生さんの本を読んでいると興味深い一節があった。

将棋は、一手だけよい手を指したからといって、それで急に状況がよくなるわけではありません。「自然な手」「平凡な手」を続けていくことによって展望が開けてくるのです。

素人の発想では「神の一手」がどこかに存在し、それを追い求める競技なのかと思っていたが違うらしい。もっと普通で、自然な一手の積み重ねがやがて有利な局面を作る。そういえば藤井聡太さんのすごいところはミスをしないことだと何かで読んだことがある。これまでの常識では途中で必ずミスがあり、それを見逃さず突いて戦うものだった。それがAIをパートナーに練習し続けてきた藤井さんはミスをしない。一度優勢を作られてしまうとそのままやることは地味押し切られて負けてしまう、ということらしい。一つ一つのアクションは地味で良い。それを続けることで局面が開けてくるというのは面白い。

Webサービスも似ているかもしれない。トリッキーな手法が注目を浴びたりするが、それは表面で起きていることであり、人気サービスはどれも地盤がしっかりしている。表示速度や使い勝手、不具合の少なさなど基本的な要素が積み上げられており、その上でトレンドに乗ったりフックとなる機能を作ったりしているように思う。気持ちとしては一発逆転の一手を狙いたくなるが、実は着実にひとつずつ作るのが近道だったりもする。毎日で良い、平凡な一手で良い。

いまは将棋を勉強しているから将棋とWebサービス開発が似ているなと感じるが、少し前に麻雀を勉強していたときは麻雀とビジネスの似ているところが気になっていた（運と実力の按配、他のプレイヤーが多く不確実性が高い）。要は何をしていても関連づけるのが好きなだけ。難しい言葉でいえば抽象化、平たく言えば上手いこと言うのが楽しいだけ。こうやって好き勝手考えるのは面白い。新しいことを学ぶのは過去の知識を整理することでもある。

「最高か最速しか生き残れない」は学生時代にインターン先の社長に教えてもらった言葉。当時はキャッチーな言葉くらいに思っていたが少しずつ意味がわかってきた。競争のある社会でやっていくには何かで頭ひとつ抜ける必要がある。質かスピードか、中途半端に迷いながらやっていては平凡なままで淘汰されてしまう。

都知事選で注目を集めた安野さんの新刊「はじめる力」を読んだ。エンジニアであり起業家でありSF作家、そして都知事選への出馬。新しいことを始めるのに特別な力は必要なく、仕組みや考え方を身につければ誰でも最初の一歩を踏み出せる。本の中では著者の経歴を振り返りつつ、その時々で何を考えて行動していたのかを紹介している。特に面白かったのはやはり都知事選まわりで、突貫のチームで混乱を減らすために安野さんは最初にある宣言をする。「とにかくスピード第一でいく。そのためにはリスクを取る。アウトプットが100点じゃないリスク。後から方針転換するかもしれないリスク。そして合意形成はせず、安野さんのトップダウンで決める」こんな感じの内容。

スピード重視で行くというのは誰でも言える。難しいのはその結果何を諦めるのかを明示することにある。納得いかない状態でリリースすることがある。整備された状態じゃないので方針が変わって作っていたものが無駄になる可能性がある。それを最初に伝えるのはチームの認識合わせとしてとても大事なことに思う。そして合意形成。長期的なプロジェクトであればメンバーの納得感や、各人が近い目線で先を見据えられているかは重要になる。しかし選挙は1ヵ月ほどの短期決戦。そうであれば意思決定者を決めてそこに委ねてしまう方が早い。プロジェクトの性質に合わせてエンジンのかけ方を選び、それを明文化して共有するのは現代のチーム開発の本質に近い。

最高か最速か？スピード勝負するのか、後出しにはなるけど品質で勝負するのか。もちろん理想は両取りだが実際リソースには限りがある。少ないリソースをどこに集中させるのか。特にサービス開発の初期のフェーズにおいては、競争力を左右する要素になりやすい。