みんな僕にやめろと言った。
残酷ではなく、本当に、慎重に—時間を無駄にしていると思う人に向けるような懸念を込めて。「君はもうファウンダーなんだ、Gautam。コードは委譲しろ。」Seahawk Media の共同創業者が2018年頃、私たちが同時に100以上のアクティブなクライアントプロジェクトを抱えていた時期に似たようなことを言った。その論理は筋が通っていた。ファウンダーはシステム、採用、パイプラインについて考えるべきで、プルリクエストではない。Seahawk Media said something similar around 2018 when we crossed a hundred active client projects simultaneously. The logic was sound: founders should think about systems, hiring, pipeline. Not pull requests.
僕はそのアドバイスを無視した。そして今、それで良かったと思っている。
---
コーディングをやめかけた時——でもやめなかった
2019年の初め、あるクライアントから今でも笑ってしまうようなブリーフをもらった。中規模なeコマースブランド、名前は挙げないが、WooCommerceの完全な再構築、カスタム商品コンフィギュレーター、全部やってほしいということだった。締め切りはタイト。チームの開発者に割り当てた。これはまさに自分が一歩引くべき仕事だと自信を持っていた。
3週間目に、その開発者が辞めました。個人的な事情で、それは完全に理解できます。しかし、半完成のコンフィグレーター、プレッシャーをかけるクライアント、その開発者だけが完全に理解していたコードベースが残されました。
日曜日の朝7時にVS Codeを開き、昼まで閉じなかった。やり遂げた。ヒーローだからじゃなく、単にコードパターン、WooCommerceのフックアーキテクチャ、カスタムポストタイプが商品バリエーションを供給している時のwoocommerce_before_add_to_cart_buttonの動作を実際に覚えていたからだ。忘れていなかった。ただ自分は前に進んだと自分に言い聞かせていただけだ。woocommerce_before_add_to_cart_button behaves when you've got a custom post type feeding product variations. I hadn't forgotten. I'd just been pretending I had moved on.
あのプロジェクトが、自分のロールに対する考え方を完全に変えました。
---
「コードを書くファウンダー」が本当に意味することは
これは私が全機能を構築しているという意味ではない。していない。Seahawkには特定の分野—アニメーション、複雑なReactの状態管理、大規模なデータベース最適化—で私より優れた開発者がいる。これは謙虚な発言ではなく、本当のことだ。
だがファウンダーとしてコードを書くというのは、仕事の感覚を決して失わないということだ。プロジェクトを管理することと理解することには違いがある。開発者が「2週間かかります」と言った時、私は正しい質問ができる。「2週間なのはAPI認証が本当に複雑だからなのか、それともWordPressプラグインに既に存在する何かを再構築しているからなのか」と。feel of the work. There's a difference between managing a project and understanding one. When a developer tells me "this will take two weeks," I can ask the right question, "is that two weeks because the API authentication is genuinely complex, or because we're rebuilding something that already exists in a WordPress plugin?"
その質問は10,000フィート上空からはできません。絶対にできません。
見積もりの問題
ソフトウェア見積もりというのはこういうものだ。開発者がクライアントに話すのと同じくらい、自分たち自身に言い聞かせる物語なんだ。シニア開発者が WordPress REST API エンドポイントのカスタム実装に 4 日かかると見積もったのに、実際に腰を据えて一緒にスコープを詰めたら 6 時間で完了したのを見たことがある。怠けてたわけじゃない。単にそのエンドポイントが本当は何をする必要があるのか、誰も掘り下げてなかったんだ。WordPress REST API endpoint that took six hours once I sat down with them and scoped it properly. Not because they were lazy. Because neither of us had dug into what the endpoint actually needed to do.
コードを定期的に書いていると、見積もりのウソを見破る嗅覚が磨かれる。劇的に。
---
それが僕をより良い社内クライアントにしてくれる
エージェンシーを運営する上で誰も教えてくれないことがある。開発者は君の社内クライアントなんだ。外部クライアントに対して売り込むのと同じように、良い判断を彼らに売り込まなきゃいけない。そして君がその言語を話すのをやめたら、その力を失うんだ。
デザインハンドオフには Figma を使う。Git を使う（具体的には GitHub で、2021 年に Bitbucket から全部移行した）。Linear で実際のチケットを書くときは、開発者がキックオフ通話なしで作業を始められるくらいの詳細さで。その最後の部分だけで、プロジェクト当たり 40 分くらい節約できてる。うちは案件数が多いから。Figma for design handoffs. I use Git (specifically GitHub, we moved everything there from Bitbucket in 2021). I write actual tickets in Linear with enough specificity that a developer can start work without a kickoff call. That last one alone has saved us probably 40 minutes per project, and we run a lot of projects.
「全体像」に振り切ってたら、こんなことできない。開発者がチケットで何を必要としてるのか知っといた方がいい。反対側に座ってた経験がなけりゃ、そんなことわかりっこないんだ。
ボスが予期しないコードレビュー
時々PRコメントを落とす。マイクロマネジメントをするためではなく、そう明示する。だが「このフィルターは毎ページロードで実行されている。結果をキャッシュできないか」というようなコメントは重要なことを示唆している。つまり、重要なレベルで気をつけているということだ。
開発者はそれを尊重する。びっくりする人もいる。そして正直なところ、それに不満を感じる者たちもいるが、それも私にとって有用な情報を教えてくれる。annoyed by it, that tells me something useful too.
2024年に実際に使っているツール
2024年に実際に使っているツール
私のスタックはテックファウンダーにしては恥ずかしいほど地味だ。VS Codeにいくつかのエクステンションをつけたもの（Prettier、GitLens、PHP Intelephense）。LocalWPで実行しているローカル開発環境。2020年にMAMPから乗り換えて、それ以来戻ることはない。Git関連はすべてターミナルを使う。GUIを完全には信頼できなかったからだ。LocalWP, I switched from MAMP in 2020 and never looked back. Terminal for everything Git-related because I never fully trusted any GUI.
クライアントプロジェクトに取り組むときは、今でもWordPressに頼ります。Webflow、Shopify、カスタムLaravelで構築したことがありますが、WordPressが最も速く対応できます。速度が重要なのです。8時間集中して作業するのではなく、断続的に対応するときは特にそうです。
先週火曜日、Coolors.coを使ってクライアントのランディングページのちょっとした修正用にブランドカラーパレットを作った。全部で4分かかった。デザイナーに説明して、待って、レビューするなら1時間かかっていた。これが創業者がコーディングするときの小さなアドバンテージだ。
エディタから手を引く創業者のほとんどは、浸透作用でテクニカルなままでいられると自分を納得させる。スタンドアップとSlackのスレッドから吸収できると思う。できない。
やめたときに実際に失うもの
エディタから手を引く創業者のほとんどは、浸透作用でテクニカルなままでいられると自分を納得させる。スタンドアップとSlackのスレッドから吸収できると思う。できない。
実際に起こることはこれだ：
- 語彙がズレていく。「API」「webhook」「cache invalidation」といった言葉を、自分のスタックの具体的な文脈での意味を知らないまま使い始めるんです。
- プロトタイピング能力を失う。2時間のコーディングセッションは、3回のステークホルダー会議では答えられない製品の疑問に対して答えを出すことができる。
- ちょっとした決定を開発者の予定に依存するようになる。かつては20分で済んでいたことが、今はスケジュール調整が必要になる。
- 開発者はそれに気づく。全員が口に出すわけではないが、明らかに数年間その仕事に触れていない創業者とどう関わるかについて、微妙な変化が生じる。
尊敬する人たちがこれを経験するのを見てきました。本当に技術的なエージェンシーを構築した優秀な人たちが、徐々に自分の専門知識から身を引いていった。5年目には経営を完全に担当していて、その点では優秀でしたが、何か言葉にできない何かを失っていました。
---
反論（そしてなぜ私はそれに同意しないのか）
ファウンダーがコーディングすることに対する最も強い反論は機会費用です。ポール・グレアムはこれについて様々な形で書いています。スケールしないことをファウンダーはやるべき、でも焦点こそが初期段階の事業の唯一の利点だという考えです。Paul Graham has written about this in various forms, the idea that founders should do things that don't scale, but also that focus is the only real advantage an early-stage operation has.
その通り。本当にそうだ。
しかし、この論理は、VCが出資するスタートアップのプロダクトファウンダーには当てはまりますが、エージェンシーファウンダーとフリーランサーにはより緩く適用されると思います。文脈が異なるからです。私たちにはコーディングから目をそらす必要があるほどのランウェイの問題がありません。品質と信頼の問題があり、コーディングはその解決策の一部なのです。
Seahawk が複雑な WordPress マイグレーションをエンタープライズクライアントに提案するとき、共同創業者がデータベーステーブル構造と wp-config 定数について詳しく議論できるという事実は小さなことではない。それが会議室の雰囲気を変える。
コーディング時間を保護する方法。問題にならないように
コーディング時間を保護する方法。問題にならないように
これを理解するのに何年もかかりました。本当に。以前は何か壊れたときか開発者が詰まったときだけ反応的にコードを書いていました。それは最悪です。コードの中にいますが、ストレスを感じていて、フロー状態に入りません。
今は、こうしている。
- 月曜と木曜の午前に90分間ブロックする。その日は午前9時30分前に会議なし。交渉の余地なし。2022年からカレンダーに入っている。 No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
- 常に「ファウンダープロジェクト」を走らせておいてください。小さいもの、個人用ツール、クライアント向けのマイクロフィーチャー、内部オートメーション。今のところはLinearからプロジェクトステータスを取得して、週間ダイジェストをフォーマットするPythonスクリプトです。180行、特に凝ったものではありません。 Something small, a personal tool, a client micro-feature, an internal automation. Right now it's a Python script that pulls our project status from Linear and formats a weekly digest. 180 lines, nothing fancy.
- 少なくとも週に1つのPRをレビューする。読むだけでいい。diffに留まること。 Even if it's just to read. Stay in the diff.
- 四半期に1回、何かをスクラッチから再構築する。ランディングページ、プラグイン、小さい連携。何でもいい。ポイントは基礎を鋭い状態に保つこと。 A landing page, a plugin, a small integration. Whatever. The point is staying sharp on fundamentals.
総時間は週4〜5時間。それだけ。スプリントを走らせろと言ってるわけじゃない。
---
よくある質問
コーディングはCEOまたは共同創業者として経営能力を損なわせるのか？
実際のリーダーシップの責任を圧迫しない限り問題ありません。問題はコーディングではなく、コーディングをより難しいファウンダーの仕事から目を背けるための手段として使うことです。難しい会話、採用決定、商業的思考といった。チャーンしているクライアントと話すべきときにエディタを開いているなら、それは問題です。木曜日の朝4時間は、リーダーシップの怠慢ではありません。avoidance strategy for the harder founder work: difficult conversations, hiring decisions, commercial thinking. If you're opening the editor when you should be talking to a churning client, that's a problem. But 4 hours a week on a Thursday morning isn't leadership negligence.
チームがコーディングしているのを見て、自分たちを信頼していないのではないかと思ったらどうしよう？
直接的に説明することだ。私はチームに明確に言った。「コードを書くときは、君たちが間違っているとか遅いとかいう合図ではない。実際に私たちが構築しているものに足を地につけておくためだ」と。その会話は90秒で済むし、ほとんどの場合1回だけで十分だ。
より大きなチームを運営する創業者にとってはこれは現実的か？
50人の時点で15人の時点より難しいのが正直なところです。でも原則はスケールしますし、実践は変わります。ある規模に達すると、「コーディング」はアーキテクチャの決定をレビューすること、四半期ごとに一度の探索的なスパイク、あるいはLighthouseパフォーマンスレポートの中身を深く理解することかもしれません。自分で修正を書くのではなく。要点は、技術的な能力が完全に萎縮するのを許さないことです。Lighthouse performance report rather than writing the fix yourself. The point is: don't let technical fluency atrophy entirely.
創業者はいつコードから本当に身を引くべきか？
コーディングが他の誰かの成長を阻害しているとき。開発者があなたのPRレビューをマージするために待っていて、あなたが一貫してボトルネックなら、それがシグナルです。クリティカルパスから身を引いてください。まだコードは書けますが、メインブランチの午前2時ではなく。critical path. You can still write code, just not on the main branch at 2am.
---
コーディングは私を誠実に保ってくれた。それが私が知る最もシンプルな表現方法だ。差分を読むことができ、機能を見積もることができ、小さなものを自分で本番環境にデプロイできるなら、自分のビジネスがより明確に見えてくる。何が実際に難しいのか、何が単に説明が悪いだけなのかが分かる。その明確さは、週4時間かかることの価値をはるかに上回っている。
相変わらずエディタを開いている。体が動く限り、おそらくこれからも続けるだろう。