みんな僕にやめろと言った。
残酷ではなく——本気で、忠告めいて、時間を無駄にしていると思う人に対して向ける心配のような口ぶりで。「君はもうファウンダーなんだ、ガウタム。コードは誰かに任せろ」2018年頃、Seahawk Mediaの共同創業者も同じようなことを言った。同時に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週間かかります」と言ったとき、正しい質問ができます——「API認証が本当に複雑だから2週間なのか、それともWordPressプラグインに既に存在する何かを再構築しているから2週間なのか」と。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にいくつかのExtensionを入れているだけ（Prettier、GitLens、PHP Intelephense）。LocalWPで動かしているローカル開発環境だ。2020年にMampから切り替えて、以降ずっとこれだ。Gitに関連することはすべてTerminalを使う。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」「キャッシュ無効化」—— スタックの特定の文脈で何を意味しているのか知らないまま、これらの言葉を使い始める。
- プロトタイピング能力を失う。2時間のコーディングセッションは、3回のステークホルダー会議では答えられない製品の疑問に対して答えを出すことができる。
- ちょっとした決定を開発者の予定に依存するようになる。かつては20分で済んでいたことが、今はスケジュール調整が必要になる。
- 開発者はそれに気づく。全員が口に出すわけではないが、明らかに数年間その仕事に触れていない創業者とどう関わるかについて、微妙な変化が生じる。
私は尊敬する人たちにこれが起きるのを見てきた。本当に技術的な実力を持つエージェンシーを構築した良い人たちが、徐々に自分たちの専門知識から身を引いていく。5年目には彼らはビジネス全体を経営していて、それは得意だった。でも、自分たちが何を失ったのか正確には言い表せないものを失っていた。
---
反論（そしてなぜ私はそれに同意しないのか）
創業者がコーディングをしない場合の最も強い主張は機会費用だ。Paul Grahamはこれについてさまざまな形で書いている。つまり、創業者はスケールしないことをやるべきだという考え、そして焦点が初期段階の事業の唯一の真の利点だという考えだ。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.
- 常に「ファウンダーズプロジェクト」を走らせておく。何か小さいもの。個人用ツール、クライアントのマイクロ機能、社内自動化。今やってるのはPythonスクリプトで、Linearからプロジェクトのステータスを引っ張ってきて、週刊ダイジェストにまとめるやつだ。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回だけで十分だ。
より大きなチームを運営する創業者にとってはこれは現実的か？
正直なところ、15人のときより50人のときのほうがはるかに難しい。だがその原理は拡張可能だ。実践は変わっても原理は変わらない。ある程度の規模になれば、「コーディング」はアーキテクチャの決定のレビュー、四半期に1度の探索的なスパイク、または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.
---
コーディングは僕を正直に保たせた。これが一番シンプルな説明だ。diffをまだ読めて、機能を見積もることができて、小さなものを自分で出荷できるなら、自分のビジネスがより明確に見える。何が実際に難しいのか、何が単に説明が下手なだけなのかが分かる。この明確さは週4時間の時間に勝る価値がある。
相変わらずエディタを開いている。体が動く限り、おそらくこれからも続けるだろう。