Googleの14年の経験から導き出された21の教訓をスタートアップの視点で解説。ユーザー中心の考え方から長期キャリア戦略まで、今すぐ活かせる実践的な知恵が満載です。
Google14年の経験から学ぶ21の教訓：スタートアップエンジニアが成功する実践ガイド
核心のポイント
- ユーザーの問題から始める：最高のエンジニアは技術ではなく、ユーザーの困りごとに執着する
- 正論より協力関係を優先：議論に勝っても、チームの協力がなければプロジェクトは進まない
- まず作る、後で直す：完璧を目指して何も作らないより、雑でもいいから作ってフィードバックを得る
- 読みやすさが最高の品質：トリッキーなコードより、誰もが理解できるコードが真のプロの仕事
- 複利思考でキャリアを積む：一発逆転より毎日の積み重ねが、長期的な成功を生む
はじめに：Google14年の経験が教えてくれる本当の大事なこと
GoogleでChrome開発に長年携わり、現在Google Cloud AIのディレクターを務めるAddy Osmani氏が、14年間の経験から学んだ教訓をまとめたブログ『21 Lessons From 14 Years at Google』が注目を集めています。
この記事は単なる技術的なノウハウではなく、エンジニアとして無理せず長く続けていくための、実践的な知恵 が詰まっています。スタートアップを立ち上げた創業者や、急速に成長するチームの中で働く開発者にとって、特に参考になる内容が満載です。
Osmani氏はO'Reillyなど多数の技術書を執筆し、長年にわたりWeb開発コミュニティに貢献してきたエンジニア。その想いは記事の中に明確に表れています。
これらを共有するのは、同じように経験を分けてくれたエンジニアたちから、私自身が計り知れないほどの恩恵を受けてきたからです。
スタートアップの世界では、速度と効率が重視されます。しかし、この21の教訓を読むと、短期的な成功よりも、「どうすれば自分たちのチームが長く、継続的に価値を生み出し続けられるか」 という視点が、実は最も重要であることに気づきます。
この記事では、これらの教訓をスタートアップの創業者目線で整理し直し、今すぐに活かせる実践的な解釈を加えていきます。
1. ユーザー中心の思考：技術ではなく「困りごと」から始める
なぜスタートアップは失敗するのか
The best engineers are obsessed with solving user problems. （最高のエンジニアはユーザーの問題を解決することに執着する）
スタートアップの起業家がついてしまう大きな落とし穴があります。それは、新しい技術やトレンドに惹かれて、実際のユーザーの問題を見落としてしまう ことです。
「AIを使った何か」「ブロックチェーンを組み込んだサービス」「最新フレームワークで開発した」——こうした技術的な輝きに目がいってしまい、本当のユーザーニーズを置き去りにしていないでしょうか。
ユーザーの声をどこで聞くか
Osmani氏の教訓は明確です。新しい技術を覚えると使いたくなる気持ちはわかります。でも本当に価値を生むのは、「この技術どこで使おう？」ではなく 「ユーザーは何に困ってる？」から考えられる人 です。
スタートアップの創業者なら、毎日がユーザーインタビューの機会に溢れています。
- サポートに来る質問やクレームは何か
- ユーザーの行動を観察すると、何を求めているか
- 使わない機能と使われまくる機能の違いは何か
こうした地道な観察が、実は最高の「技術選定の指針」になります。問題を本当に理解しているエンジニアは、洗練された解決策が誰もが予想していたよりもシンプルであることに気づくのです。
スタートアップが今日からできること
創業初期段階なら、毎週ユーザー3〜5人に話を聞く習慣をつけましょう。そこで出てくる「イライラ」「手間」「やりたいけどできない」が、あなたのプロダクトの本当の価値提案になります。
技術は後からついてきます。ユーザーの問題が明確なら、それを解く技術選定は自然と決まります。
2. チームの協力を優先：正論より「一緒に答えに辿り着く」ことを重視する
議論に勝つことの落とし穴
You can win every technical argument and lose the project. （技術的な議論にすべて勝っても、プロジェクトに負けることがある）
スタートアップの初期チームは、通常、天才的なエンジニアやプロダクト思考の強い創業者で構成されていることが多いです。その結果、毎日のように「どの技術を選ぶか」「どう実装するか」について議論が交わされます。
ここで注意が必要です。議論に勝つことと、プロジェクトを成功させることは別問題です。
あなたの提案が技術的に完全に正しかったとしても、チーム全体が心の底から同意していなければ、実装のプロセスで軋轢が生じます。「あの人が強引に決めた」という印象は、その後のコラボレーションに影響します。
「強い意見を、弱く持つ」の力
Osmani氏が提唱する「強い意見を、弱く持つ」というフレーズは、一見矛盾しているように聞こえますが、スタートアップの現場では最高の指針です。
これは確信がないからではなく、不確実な状況での決定を自分のアイデンティティにすべきではない ということです。
実装開始後に新しい情報が出てくれば、方針を変えることもあります。その時に「でも私がこう言ったじゃん」と固執するのではなく、「新しい情報が出たから変更しよう。みんなで一緒に最適解を見つけよう」という柔軟性こそが、高速で反復するスタートアップには不可欠です。
スタートアップが今日からできること
チーム内で技術判断をするときは、以下のプロセスを試してみてください。
- 提案者が「今の理解と判断」を説明 する（自分の意見として主張するのではなく）
- 反対意見や懸念を聞く（「なぜ反対か」に耳を傾ける）
- 一緒に最適解を考える（勝ち負けではなく、チーム全体の目標に向かう）
- 決定後は全員が支持する（その後、個人的な不満は持ち込まない）
このプロセスを回すことで、チームは高速に意思決定でき、実装時の協力度も高くなります。
3. 速く進むなら「作ってから直す」：完璧を待つな、雑でいいから動かそう
完璧な設計の罠
You can edit a bad page, but you can't edit a blank one. （悪いページは編集できるが、白紙は編集できない）
スタートアップの創業者にとって、時間は最も貴重な資源です。それなのに、技術的に「完璧な設計」を求めて、何ヶ月も実装前の議論に時間を費やしてしまうチームは少なくありません。
「このアーキテクチャなら将来の拡張性も大丈夫」「このAPI設計なら後から機能追加しやすい」——こうした理想的な設計を目指すことは大事ですが、それで6ヶ月実装が遅れるなら、話は別です。
実際のユーザーに使ってもらわなければ、その設計が本当に必要かどうかは、誰もわかりません。
フィードバックの価値は頭の中の議論の100倍
Osmani氏が強調するのは、「まず作る→直す→良くする」の順番 です。
実際のユーザーが使ってくれた時の反応は、社内会議で何時間議論するよりも、はるかに多くの学びをもたらします。
- 「想定通りに使わない」というユーザーの行動
- 「ここが使いにくい」という指摘
- 「実は自分たちが過度に複雑にしていた」という気づき
こうしたフィードバックは、初期段階のプロトタイプで得られます。
スタートアップが今日からできること
「MVP（Minimum Viable Product）」というワードはよく聞くと思いますが、これを本当に実践できているスタートアップは意外に少ないです。
次のチェックリストで確認してみてください：
- ユーザーが本当に欲しい機能は、全体の何パーセント実装されているか
- 実装されていない機能の80%は、本当に必須か
- もし30%の機能だけで市場に出せたら、いつリリースできるか
不要な完璧さを手放すことで、スタートアップは数ヶ月単位で成長を加速できます。
4. コードの品質：「賢さ」より「読みやすさ」が勝つ理由
2時間後の自分は「他人」である
Your code is a strategy memo to strangers who will maintain it at 2am during an outage. （あなたのコードは、障害中の午前2時にそれを保守する見知らぬ人への戦略メモだ）
スタートアップのエンジニアは、スピード重視で複雑でトリッキーなコードを書いてしまうことがあります。「こんなやり方で実装した！」と自分たちは理解していても、そのコードが問題を起こすのは大抵、本人がいない時間帯です。
午前2時に本番環境でバグが発生した。ログを見ると、あのコードが原因らしい。でも当番は新しく入ったエンジニア。そのコードを読んでも、何をしようとしているのかが全く理解できない。
こうした状況は、スタートアップ以上に頻繁に起こります。急速に成長するチームでは、新しいメンバーが頻繁に入ってくるからです。
「読みやすさ」はビジネスリスクの低減
トリッキーなコードは賢く見えるかもしれません。でも、それを深夜の障害対応で読むのは、あるいは3ヶ月後に新しく入ったエンジニアが読むのは、相当な苦行です。
その人が一瞬で理解できるコードこそプロの仕事。
スタートアップにおいて、障害対応の時間は直接的なビジネス損失につながります。回復が1時間遅れれば、その間に失う顧客や売上は計り知れません。
明快なコードなら、新しいメンバーがもっと早く貢献できます。バグの原因も素早く特定できます。これは単なるコード美学ではなく、スタートアップの生死を分ける実務的な判断です。
スタートアップが今日からできること
- コードレビューのポイント を「賢さ」から「読みやすさ」に変える
- 複雑な処理に直面したら、まずコメントで意図を書く
- 変数名や関数名 には、その役割が一瞬でわかる名前をつける
- 後から変更しやすいコード設計 を重視する
特にスタートアップは、メンバーの入れ替わりが多いです。その時に「前の人のコードが読めない」という事態は、避けなければなりません。
5. 新技術導入は「借金」：本当に必要な場所だけに絞る戦略
新技術の隠れたコスト
The "best tool for the job" is often the "least-worst tool across many jobs." （「最適なツール」は、しばしば「多くの仕事で最も悪くないツール」である）
スタートアップのエンジニアはつい、最新技術に惹かれてしまいます。Rust、Golang、Kubernetes、GraphQL——確かに素晴らしい技術ばかりです。
でも、最新技術を導入するたびに、見えないコストを背負っています。
- 学習コスト：チーム全体が新しい技術を学ぶ時間
- 採用難：その技術の経験者を新しく採用する時の困難さ
- トラブル時の情報不足：問題が起こった時、Stack Overflowに答えがない
これらのコストは「借金」です。その技術が本当に必要な場面では充分な価値を生みますが、単に「試してみたい」という理由なら、返済できない負債になります。
「枯れた技術」の価値を再評価する
Osmani氏の教訓は、スタートアップにとって特に重要です：
イノベーションするな、ではない。「独自に報酬を得ている場所でだけイノベーションせよ」ということ。それ以外は退屈でいい。退屈には既知の失敗モードがあるから。
言い換えれば、スタートアップが競争優位性を持つコア技術には、最新の技術を使う価値がある。でも、「見た目を表示する」「ユーザー認証をする」など、誰もが解く同じ問題には、わざわざ新しい技術を選ぶ必要はありません。
既知の技術なら、トラブルも既知です。ネット上に情報も豊富です。新しいメンバーが加わったときも、学習が早い。
スタートアップが今日からできること
技術選定の判断基準を、以下に変えてみてください：
- 「これは、私たちのビジネスの競争優位性を生むか？」 ：YESなら新技術を試す価値がある
- 「既存の技術では、ほぼ同じ結果が得られないか？」 ：得られるなら、枯れた技術を使う
- 「この技術を導入することで、採用や保守にかかるコストは増えるか？」 ：大きく増えるなら、本当に必要か再検討
スタートアップは限られたリソースで戦っています。技術的な好奇心より、ビジネス的な必要性を軸に判断することが、長期的な成功につながります。
6. 価値を「見える化」：良い仕事も伝わらなければ存在しないのと同じ
目立たない仕事の罠
If no one can articulate your impact when you're not in the room, your impact is effectively optional. （あなたがいない場で誰もあなたの成果を説明できないなら、その成果は実質オプションだ）
スタートアップのエンジニアには、「良いコードを書けば評価される」という幻想を持っている人が多くいます。ですが、現実はそうではありません。
あなたが会議に出ていない時に、マネージャーが「このエンジニアはどんな貢献をしているか」と聞かれて、誰も説明できなければ、その貢献は実質的に「存在しない」のと同じです。
昇進も、新しいプロジェクトへのアサインも、給与交渉も——こうしたキャリアの分岐点では、「あなたがいない場で誰かがあなたの価値を説明できるか」が決定的に重要です。
自分の価値を「伝える」ことはプロフェッショナリズムの一部
ここで大事な区別が必要です。これは「自慢する」ことではありません。価値の連鎖を、自分を含めた全員に「読める」ようにしておく ことです。
例えば：
- バグ修正をしたなら、「どんなバグだったか」「なぜ発生していたか」「どう修正したか」をドキュメントに残す
- パフォーマンス改善をしたなら、「改善前後の数値」を可視化する
- 新しい仕組みを作ったなら、「なぜこれが必要だったのか」を説明する
こうした「価値の可視化」があれば、あなたがいない場でも、チームは「このエンジニアは〇〇のような価値を生み出している」と説明できます。
スタートアップが今日からできること
毎週の振り返りで、以下の習慣をつけてみてください：
- This Week's Impact ：今週やったことの中で、ビジネスに直接つながったものは何か
- Documentation ：それを簡潔にドキュメント化したか
- Share ：チームに伝えたか（Slack、メール、全体会議など何でもいい）
これを3ヶ月続けると、あなたは「可視化されたプロフェッショナル」になります。キャリアの停滞感も、自然と解消されるでしょう。
7. 最高のコードは「書かなかったコード」：削減の哲学
なぜコード削減が最優先なのか
Before you build, exhaust the question: "What would happen if we just… didn't?" （作る前に「もしやらなかったら？」を徹底的に考えろ）
スタートアップのエンジニアはついつい、「機能を足す」ことで価値を生み出そうとします。でも、実際には、書かなかったコードこそが、最高のコード です。
なぜなら、書いたコードは全部：
- 将来のバグ対応の候補になる
- 新しいメンバーが学ぶべき「複雑さ」になる
- メンテナンスのコストが永遠についてまわる
つまり、機能を増やすたびに「技術的負債」が蓄積するのです。
「本当に必要な機能」を見分ける訓練
問題は、エンジニアがコードを書けないことじゃない。Osmani氏が指摘するのは：
問題は、エンジニアがコードを書けないことじゃない。書くのが上手すぎて、書くべきかどうかを問うのを忘れること。
スタートアップで急速に成長するプロダクトほど、このリスクは高いです。「あったら便利だろう」「あれば競争優位性が生まれるかも」——こうした推測で、不要な機能をどんどん足してしまうのです。
作る前に、以下の質問を徹底的に考えてください：
- ユーザーは本当にこれを求めているか（想像ではなく、実データや直接の声で）
- この機能がなければ、問題は生じるか（消えて困る機能か、あったら嬉しい機能か）
- この機能を保守するコストは見合うか（3年後も保守し続けるか）
スタートアップが今日からできること
プロダクト開発の優先順位をつけるときに、「追加」だけでなく「削除」も検討してください。
- 使われていない機能 はないか
- やっていることが重複していないか
- 本来の問題を解くのに、本当に全部必要か
スタートアップは、限られたリソースで戦っています。機能数を増やすことより、「本当に必要な機能を、完璧に磨く」 という戦略が、長期的には最強です。
8. スケール時代の互換性問題：バグにもユーザーがつく現実
プロダクト成長時の見えない落とし穴
At scale, even your bugs have users. （規模が大きくなると、バグにさえユーザーがつく）
スタートアップが成長し、ユーザー数が10万人、100万人に増えると、新しい問題が生じます。
初期のバグやAPIの設計上の「いびつさ」に対して、多くのユーザーが依存するようになるのです。例えば：
- 「エラーメッセージが特定の文字列で始まる」という仕様に依存している連携サービス
- 「APIのレスポンスが遅い時がある」という癖を計算に入れている外部ツール
- 「この入力方式だけ動く」という裏技を使い続けているヘビーユーザー
これらはテクニカルには「バグ」や「設計ミス」ですが、ユーザーは既にそれを前提に仕事をしています。急に修正すると、大混乱が生じます。
互換性維持こそが本当のプロダクト開発
Osmani氏が強調するのは、このような互換性維持こそが、実は「本当のプロダクト開発」だということです。
互換性作業を「メンテナンス」、新機能を「本当の仕事」として扱うことはできない。互換性はプロダクトだ。
多くのスタートアップ企業は、成長段階で「古いAPIは廃止して、新しいAPIに移行させよう」と考えます。でも実際には、その移行のコストをユーザーに押し付けることになり、顧客満足度が低下します。
賢いスタートアップは、以下の戦略を取ります：
- 古いAPI/機能は、新しいものと並行して動かし続ける
- 段階的に移行を促す（急な廃止ではなく、6ヶ月、1年単位の計画）
- 互換性維持のコストを、プロダクト開発の「正当な仕事」として評価する
スタートアップが今日からできること
プロダクト設計の初期段階で、以下の原則を定めておくことをお勧めします：
- 破壊的変更のルール：どの程度の警告期間を設けるか
- 後方互換性の確保：古いバージョンを何年間サポートするか
- マイグレーションパス：ユーザーが新しいバージョンに移行するための仕組み
こうした戦略があれば、プロダクトの成長とともに、ユーザー信頼も同時に高まります。
9. 遅さの本当の原因：チームのズレはコミュニケーション問題
プロジェクト遅延の真犯人
Most slowness is actually alignment failure. （ほとんどの遅さは、実際にはアラインメントの失敗だ）
スタートアップでよくあるシナリオです。プロジェクトが予定より遅れている。マネージャーは「人が足りない」「能力不足」と考える。だから、もっとエンジニアを雇おうとする。
でも実際には、それでは問題は解決しません。本当の原因は、方向性や優先順位がチーム内で揃っていない ことの方が圧倒的に多いです。
例えば：
- エンジニアAが思う「優先実装順序」と、エンジニアBが思う順序が違う
- フロントエンドとバックエンドで、APIの設計仕様の理解が異なっている
- 「これは今度のバージョンで実装」と考えていたのに、別の誰かは「次のバージョン」と考えていた
こうした「小さなズレ」が、実装進行中に「あ、ちょっと作り直す必要があります」と発展し、累積して大きな遅延になるのです。
シニアエンジニアの本当の仕事
Osmani氏が指摘するのは、経験豊富なエンジニアの役割についてです：
シニアエンジニアは「コードをより速く書く」より、方向性・インターフェース・優先順位を明確にすることに多くの時間を費やす。そこに実際のボトルネックがあるから。
つまり、スタートアップの成長段階で必要なのは、「より多くの開発者」ではなく、「方向性を明確に説明できるリーダー」 です。
スタートアップが今日からできること
次回のスプリント計画や進捗確認の時に、以下を試してみてください：
- 全員が同じゴールを言葉にできるか：各人に「今月のゴールは？」と聞いて、答えが揃うか
- 優先順位に異論がないか：「なぜこの順序か」を聞いて、全員が納得しているか
- インターフェース設計が確定しているか：API、UI、データ形式などが、全員の認識で一致しているか
こうした「見えない部分」を整理するために、週に2〜3時間使うことで、実装フェーズは2倍以上速くなる可能性があります。
10. 変えられないことに執着しない：戦略的なフォーカスの力
エネルギーを奪う「変えられない問題」
Energy spent on what you can't change is energy stolen from what you can. （変えられないことに使うエネルギーは、変えられることから奪われている）
スタートアップの創業者は、毎日のように「変えられないこと」に直面します。
- 資金調達が思うようにいかない
- 優秀な人材が退職してしまった
- 市場環境が想定と違う方向に変わった
- 大手競合が類似サービスをリリースした
こうした状況は、創業者のメンタルを削ります。そして、エネルギーをすべてそこに使ってしまうと、「変えられることの質が低下する」 という悪循環に陥ります。
「変えられること」の領域を明確にする
Osmani氏の教訓は、シンプルですが強力です。組織再編が起こるかはコントロールできない。仕事の質、どう対応するか、何を学ぶかはコントロールできる。
言い換えれば、戦略的なフォーカスとは「諦める力」ではなく、「自分たちが影響を与えられる領域に全力を尽くす」 という決断です。
スタートアップにおいて、変えられることは：
- プロダクトの品質
- ユーザーサポート
- チーム内の心理安全性
- 毎日の学習と改善
- 正直なコミュニケーション
これらに集中することで、変えられない外部環境の影響を最小限にできます。
スタートアップが今日からできること
毎週の経営会議で、以下を意識的に分けてみてください：
「変えられないリスク」：認識するが、過度に対応しない
「変えられること」：ここに最大のリソースを投下する
スタートアップが生き残るのは、外部環境に適応することより、「自分たちが最高の価値を提供するために何をするか」に集中した企業 です。
11. 抽象化の落とし穴：複雑さを「後回しにする」コストを理解する
便利さの裏に隠れた負債
Abstractions don't remove complexity. They move it to the day you're on call. （抽象化は複雑さを除去しない。オンコールの日に移動させるだけだ）
スタートアップがあるレベルに達すると、エンジニアはより「抽象的な」フレームワークやライブラリを使い始めます。Next.js、Django、Rails、AWS——確かに開発は速くなります。
でも、その内部で何が起きているかは、見えなくなります。
実装している時は便利です。でも、午前3時に本番環境でエラーが起きた時、その抽象化の下で何が起きているかを理解していなければ、対応できません。
「低レベル」理解の継続的な学習
Osmani氏が強調するのは、スタックが高くなっても：
シニアエンジニアはスタックが高くなっても「低レベル」のことを学び続ける。ノスタルジアからではなく、抽象化が失敗し午前3時にシステムと一人になる瞬間への敬意から。
これは、Pythonを使うなら「CPythonの内部」を学ぶ、JavaScriptなら「ブラウザのレンダリングエンジン」を学ぶ、という意味ではありません。
むしろ、自分たちが使うツール・フレームワーク・ライブラリについて、「内部でどう動いているのか」という理解を持ち続ける ことです。
スタートアップが今日からできること
チーム内での学習文化として、以下を導入してみてください：
- 月に1回の「チーム学習会」：使っているフレームワークの内部構造について、深掘りする
- 障害後のポストモーテム：「なぜこれが起きたか」を、単に「バグです」で終わらせず、根本原因まで掘り下げる
- 新入エンジニアへの教育：「こう使う」だけでなく、「内部ではこう動く」という説明も含める
こうした投資は、初期段階では時間がかかるように見えます。でも、長期的には、チームの対応力と信頼性が圧倒的に高まります。
12. 教えることで自分の理解が深まる：アウトプットの価値
なぜ教えることが最高の学習か
Teaching is debugging your own mental models. （教えることは、自分のメンタルモデルをデバッグすること）
スタートアップのエンジニアは忙しいので、「学習」が後回しになりがちです。でも、実は、自分の理解を深めるなら、人に説明するのが最速 です。
なぜなら、説明しようとすると、自分が曖昧に理解していた部分が、必ず見つかるからです。
例えば：
- テストを書く理由をジュニアに説明しようとしたら、実は自分もテストの意義を完全には理解していなかった
- APIの設計思想を解説しようとしたら、「なぜこの構造なのか」を言葉にできなかった
- 新入エンジニアに技術選択の理由を聞かれて、答えられなかった
こうした「つまずき」が、実は自分の理解が浅い証拠です。
アウトプットは最高のインプット
Osmani氏が強調するのは、単純ですが強力な原則です：
ブログ、ドキュメント、何でもいいから説明してみよう。つまずく場所が、理解が浅い場所。
スタートアップにとって、これは特に重要です。チーム内のノウハウが暗黙知化すると、新入メンバーがキャッチアップできず、組織全体の成長が止まります。
逆に、メンバーが「学んだことを説明する習慣」を持つ組織は、個人の学習が組織全体の資産に自動的に変わります。
スタートアップが今日からできること
チーム内での「説明文化」を作ってみてください：
- 週に1回、15分の「Tech Talk」：チームメンバーが最近学んだことを説明する
- ドキュメント作成を評価する：実装と同じくらい、説明文の作成を価値評価する
- ブログやQiitaなどへの執筆：チーム外に発信することで、自分たちのレベルを高める
この習慣があれば、チームの技術レベルは加速度的に高まります。そして何より、新しいメンバーのオンボーディング時間が大幅に短縮 されます。
結論：スタートアップが「長く続ける」ための21の教訓
Googleで14年の経験を積んだAddy Osmani氏の21の教訓は、結局のところ、1つの大きなテーマに集約されます。
「どうすれば自分たちのチームが無理せず、継続的に価値を生み出し続けられるか」
スタートアップの創業初期は、速度と効率がすべてのように見えます。でも、本当の成功は、「短期的な成長」と「長期的な持続性」の両立 にあります。
この記事で紹介した21の教訓を、あなたのスタートアップの現場に落とし込んでください。すべてを今すぐ実行する必要はありません。共感した3つか4つから、始めることをお勧めします。
今週から試すなら、以下の3つから選んでください：
- ユーザーの困りごとから始める：毎週ユーザー3人に話を聞く習慣
- 完璧より迅速：MVP思考：今月の30%機能リリースで何ができるか考える
- 読みやすいコード文化：コードレビューで「理解しやすさ」を最優先にする
スタートアップとして急速に成長することは素晴らしいです。でも、その過程で、自分たちのチーム、プロダクト、そして「なぜこのビジネスを始めたのか」という初心を失わないこと。
Osmani氏の教訓は、そのバランスを取るための、実践的で信頼できるガイドになるでしょう。
あなたのスタートアップが、長く、持続的に価値を生み出すチームになることを願っています。
Original source: 「Googleでの14年間で学んだ21の教訓」を 個人的な解釈でまとめてみた - Qiita
powered by osmu.app