- うまく運営されているシード段階のスタートアップでは、エンジニアがユーザーの課題を見つけ、実装・リリースまで自ら回すが、会社が大きくなるほどこのループは遅く分断された仕事へと変わる
- 10人未満のチームは、ユーザー接点、アイデア選定、同僚からのフィードバック、小さなコードベース、軽いデプロイのおかげで実装速度が速い
- 100人以上の組織では、ユーザー接点がPMに分離され、セキュリティレビュー・CI・PRレビュー・インフラ手順が積み重なり、作業速度が大きく低下する
- 変化の背景には、利害関係の低下、従業員数の増加に伴う O(N^2) のコミュニケーション、ユーザー数と規制の増加によって下がるリスク許容度がある
- 楽しさの消滅を完全に防ぐのは難しいが、大企業式のプロセスを性急にまねず、小さな独立チームとインセンティブを設計し、採用ペースを落とせば遅らせることはできる
小さなスタートアップで仕事が中毒的に感じられる理由
- うまく運営されているシード段階のスタートアップで、エンジニアの中核的な仕事は、ユーザーの課題を把握し、アイデアを作り、同僚と議論し、実装したうえでリリースと振り返りを繰り返すこと
- 10人未満のチームでは、このループの各段階が楽しいものになり得る
- 関心のあるユーザーに直接連絡し、ビールを飲みながら話せる
- 会社にとって価値があり、個人的にも興味深いアイデアを見つけたら、進行中の作業を止めてすぐに取り組める
- 同僚は同じ会社の成果に直接の利害関係があるため、良いアイデアを後押しし、悪いアイデアの問題点を説明する動機がある
- 同僚自身がそのアイデアのユーザーかもしれず、一緒に作業したがるかもしれないし、コードベースの大きな部分を知っているため有用な洞察を与えられる可能性が高い
速い実装と高い期待感
- 小さなチームでは実装速度が速い
- 好きなツールを選べ、セキュリティレビューがない
- コードベースが小さく全体構造を頭に入れられるため、大きなリファクタリングも比較的気軽に試せる
- 高速なホットリロードのおかげで、試行錯誤型のデバッグを素早く繰り返せる
- 変更のマージも軽く行われる
- CIに遅いテストがなく、安全な変更にはブロッキングなPRレビューが不要な場合がある
- 場合によっては
master に直接プッシュしたり、危険な変更は同僚に肩をたたいてレビューを頼んだりできる
- ユーザーが多くなければ、迅速なバックエンドやデータベース変更のためにダウンタイムを許容できる
- 小さなスタートアップでは、何でも可能だという期待感が強い
- 新機能が持ち分の価値を高めるかもしれず、その後も人々がその機能の上に積み上げ続けるかもしれない
- ユーザーが「このアイデアを出したのはあなたですか、私の人生を救ってくれました」と言う場面を期待することもできる
- チームメンバー全員が利害関係を共有しているため、互いの成功を応援する雰囲気が生まれる
会社が大きくなると同じループはどう変わるか
- 100人以上の組織では、ユーザーとの直接接点が減る
- ユーザーと話す仕事はPMの役割になり、エンジニアはユーザーインサイトの要約と優先順位リストを受け取る程度にとどまることがある
- 悪い場合、ユーザー理解が間違っていたり、マネージャーの自己中心的なビジョンに基づいた混乱したタスクリストを渡されたりし、各作業がなぜ重要なのかを説明できる人もいないことがある
- 個人がやりたいことをすぐに選びにくくなる
- 全員が各自やりたいことをすると、O(N^2) のコミュニケーション混乱が生じる
- マネージャーは組織の他の作業まで考慮して、個人の計画を設計する
- 自分のアイデアは、決められた仕事を終えた後にやるか、余暇にこっそり進めなければならないことがある
- 同僚とアイデアについて話すことはできるが、関心と余裕は減る
- 同僚が個人の成功から得る利益は小さく、昇進の競争相手になることもある
- それぞれ長いタスクリストを抱えており、進行中の仕事を置いて一緒に作業する自由がない
- そのコードに関する記憶や文脈も不足している可能性が高い
大規模組織で実装が遅くなる理由
- 100人以上の組織では、ツール選択はすでに決まっている
- より良い新ツールがあっても、一貫性を崩すコストのため導入する価値がないと判断されることがある
- 新しいツールを使うには、マネージャーに尋ね、セキュリティレビューチームにメールを送らなければならない
- 大きなコードベースは主にレガシーな理由で大きくなる
- 触るのが怖いコードが多く、もはや理解している人がいないコードも多い
- 徹底したテストが、システム全体を壊さないという唯一の確信の根拠になる
- 試行錯誤型のデバッグが必要だが、コンパイル時間が長く反復サイクルが遅くなる
- 小さなPRを1つマージするだけでも2週間かかることがある
- CI通過に20分待ち、テストが flaky なら再実行しなければならない
- レビューを待つ間にマージコンフリクトが積み上がる
- レビュアーには十分な文脈や動機がなく、重要な提案より些細な指摘しかできないことがある
- 要求された変更を反映して再度プッシュし、さらに20分待つ過程がPRごとに3回繰り返されることがある
- インフラ変更は、1,000万ユーザーのダウンタイムやデータ損失を避けるために14段階の手順になることがある
- 3カ月間静かに作業した後でリリースしても、報酬と承認は限定的かもしれない
- 金曜の会議でCEOに見せられるデモの機会を得るが、実際に集中している同僚は一部にとどまることがある
- マネージャーは、5カ月後の業績評価サイクルに役立つだろうと言うかもしれない
- 良い場合は20%の昇給と肩書きの変更を得られ、悪い場合は4カ月後の組織改編で新しいマネージャーが来て、プロジェクトが優先順位から外れたり廃止されたりすることがある
楽しさの死を遅らせる方法
- この変化は完全に止めるというより、遅らせる問題に近い
- 根本原因は利害関係の低下、O(N^2) のコミュニケーション、リスク許容度の低下である
- 利害関係の低下とコミュニケーション問題は、従業員数が増えるほど避けにくくなる
- リスク許容度の低下はユーザー数増加の結果であり、部分的には政府規制とも関係する
- スタートアップは大企業のプロセスをまねることで、企業化を不必要に早めてしまうことがある
- 大企業出身のマネージャーを採用すると、彼らが使っていたプレイブックも一緒に入ってくることがある
- 多くのスタートアップは大企業が使っているという理由でJiraを使うが、そうしたやり方は避けるべきだという立場である
- Y Combinatorは、大企業がスタートアップのように運営しようとすべきだという認識を広げたと見ることができる
- 大企業のプレイブックは大企業のためのものであり、スタートアップが大きくなる頃には、スケールの問題を扱うより良い解決策があるかもしれない
- スケールに伴う痛みを経験するときは、第一原理から解決するか、同じ規模でもより速く動くスタートアップから着想を得るほうがよい
- 会社を複数の独立したスタートアップのように構成する方法は、可能な範囲で試す価値がある
- Ripplingは、ある程度これを実現した例として挙げられる
- ただし、製品コンポーネントがあまりにも緊密に結合しており、ほとんどのコンポーネントが単独で売上を生み出せないため、通常は限界がある
- インセンティブ設計は、利害関係の低下を意味のある形で遅らせることができる
- しかし、大きな持ち分とその価値を変えられる力ほど強いインセンティブはまれである
- 最良の方法の1つは、採用を減らすことである
- 多くの会社は、マネージャーのインセンティブ不一致、急成長する他のスタートアップのように見せよという投資家からの圧力、人員1人当たりの真のコストを理解していないことが原因で、あまりに速く採用している
- ツール、特にAIが良くなるほど、小さなチームが支えられるユーザー数は増える
- 未来の創業者たちは、こうしたスケールの痛みをあまり心配しなくなり、仕事は誰にとってもより楽しいものになるかもしれない
1件のコメント
Hacker News の意見
10年前、Netflix がまだ小さかった頃のやり方は本当に良かった。成熟した人たちを採用することでプロセスをなくせたし、実際にあらゆるものを脱プロセス化しようとしていた
その結果、仕事は自然に回り、当時の Netflix では「大きな事件もなく自然に進むこと」がよく期待されていた。アクティブ-アクティブのリージョンも数か月で実現し、使いやすいデプロイツール Asgard も生まれ、自社 CDN を作って ISP と提携する計画も、12人ほどで6か月のうちに実現した
エンジニアの立場では、週1回のチームミーティングがあるだけで、マネージャーやディレクターたちがチーム間の文脈を合わせる会議をたくさんしてくれていたので、エンジニアは思う存分生産的に働けた。当時は自然なことだと思っていたが、後から見ると非常に高い基準だった
手取り足取り導かれなくても仕事を終えられる開発者も必要だが、マネージャーも同じく、手取り足取り統制するのではなく調整できなければならない
しかし、2人以上から主観的な入力を受けて反復改善しなければならないプロダクトなら、コミュニケーションと分散協業は重要で必要になる。だからといって必ず苦痛でなければならないわけではないが、上の Netflix モデルがどこにでも適用できるわけではなく、盲目的に複製すべきではない
私が働いたところではプロダクトがうまく定義されていなかったが、それは放置していたからではなく、新しくて形が曖昧で、何であるべきか誰にも分からなかったからだ。一方 Netflix は「映像を可能な限り効率よく画面へ届ける」という目標が明確で、純粋な技術課題の解決に近くなる
もちろん広告やバックオフィスのようなプロダクト開発は続くだろうが、プロダクトの中核ミッションがかなり堅固なので、人々を同じ方向にそろえるのにかける時間が少なくて済むのか気になる
こういう文章を見るたびに目を回したくなる。書いた人がかなりジュニアか、社員がなぜ自分の会社のために働くのかについて、どこか壊れた期待を持つ創業者タイプだと感じる
サンフランシスコのテック業界の奇妙な文化から来ている面が大きいが、その外側では人々は自分の職業をこのようには考えない。私が一緒に働いた最高の開発者たちは仕事に「酔って」いなかったし、自分が何をしているかを理解しているプロで、その知識に対して十分な報酬を受け、仕事の外でも友人や個人的な関心を持つ充実した人生を送っていた
こうした物語は、若く影響を受けやすいエンジニアに、給与が正当化する以上の人生を仕事に捧げさせようとするプロパガンダに近い。若いエンジニアなら、そうすべきではない。興奮と純真さを利用して私生活を完全に壊す上司も多いが、普通の雇用主と従業員の関係を期待する会社も多い
製品リリースまで賃金を先送りしようと提案されたとき、何年もかけて積み上げられた信頼戦術がついに換金され、ひどい給与が意図的だったのだと徐々に悟った。その仕事に対してまともな賃金を払うことはできたはずなのに、正当な報酬を求めると、返ってきたのは抵抗とパンくずのような約束、そして壁を作ることだけだった
後で未払い分を求めると「払う金がない」と言われたが、私が怒って辞めた後、私の2つ目のプロジェクトを一からやり直させるために別の人を雇った。私は最速の開発者ではなかったし、新しく雇われた人もかなり優秀だったようだが、私と別の開発者から見ると、私の仕事は十分にやれていた
「同僚3人が解雇されて、今は4人分の仕事をしているのに、過労だと言っても上司が聞かない」といった状況だ。プロであれば、解雇の前にすでに去っていたか、そうした状況が生じたら通常の勤務週の中で何をして何をしないのか境界線を引き、交渉していた可能性が高い
会社は何も考えずに解雇できるのに、自分の人生より会社を心配するよう洗脳された人が多すぎて、まったく理にかなっていない
その後スタートアップに移り、後悔していない。より多く働いているがずっと楽しく、永遠に続けられるわけではないだろうけれど、金銭的な報酬も良くなったので、以前の安定していて退屈な仕事のように65歳まで働く必要はなさそうだ
だからといって人生が充実していないという意味でも、搾取されているという意味でもない。むしろ、そうではないと言う人たちは、仕事から得られるものをあまり得られていないように見える。週40時間をそう使うのは少しもったいない
基本的にクールエイドを飲んでいて、自分が何を知らないのかも知らない状態だ
「火花」よりさらに一段進んで、完全な破壊を招く要因もある
これまで、エンジニアリングチームとプロダクトを衰退させたり崩壊させたりする大きな要因だと見てきた、不完全なリストは次のとおり。技術寄りすぎるリーダー、非技術系リーダー、問題のあるエンジニア、マイクロマネジメントである
スタートアップが成長すると、スーパースター級エンジニアが VP Engineering、アーキテクト、CTO といったリーダー職へ移るが、リーダータイプでなければチームはビジョンのない動物園になりがちで、逆にエンジニアリング経験がほとんどない非技術系リーダーも同じように危険である
浅い面接で問題のあるエンジニアが入ってきて、解雇も緩ければ、チームの 5〜10% がそういうタイプなだけでも進捗を妨げ、責任を避け、評判だけを積み上げ、ひどい成果物を押し通して士気を大きく損なう。良いエンジニアリングチームと文化を保つのは、鉛筆を芯の先で立てるように難しく見える
初心者の創業者は、ネガティブなフィードバックを与えたり、IC のままでいるべきだった技術寄りすぎるマネージャーを降格させたり、合わない社員を退職させたりすることに、あまりにもためらいがちな場合が多い
ある地域のスタートアップは、C レベル役員の UI デザイナーの友人をプロダクト VP に据えたが、その人は仕事をまったくこなせなかったにもかかわらず、「成長する機会を与える」として 2 年間留め続けた。VP 配下の全員が彼の無能さを知っており、どう回避するかを話していた
結局、プロダクトのイニシアチブは始まりさえせず、会社は完全にサービスベースの業務へピボットせざるを得なかった。社内の人々がすでに見限っている無資格なリーダーを維持し続けるスタートアップには残らないほうがよい
同じ会社は、縮小時にプロダクト VP と、ほとんど仕事をしていない彼の帝国を整理する絶好の機会があったが、C レベルとの人脈のために避け、代わりにエンジニアを切った。報酬の高いエンジニアから削り始めた結果、コアエンジニアを失い、適切な人を知ってさえいれば無能でも許されるというシグナルを出してしまい、その後数か月でさらに多くの中核人材が去った
採用ミスは誰にでもあるが、そのミスにどう対応するかが会社の運命を決める
「IC には耐えられる最大限の自律性を与えるべきだ」といった経験則は言えるが、すべてのルールには例外がある。圧縮された知恵は文脈を失って誤解されたり、経験の浅い人がカーゴカルトのように真似したりしやすい
個人の性格や組織構造の微妙な違いから生じた小さな力学が、全員が善意で最善を尽くしていたにもかかわらず、巨大な機能不全と生産性の損失につながるのを見てきた。上から命令し、中央計画するやり方では、良いエンジニアリングはできない
プロダクトと事業を最後まで理解する人が、現場のエンジニアを含めて十分にいなければ、小さな意思決定が大きな全体像に合うように下され、正しい懸念がリーダー層へ上がっていくことはない。プロダクト、デザイン、法務、財務、サポート、セキュリティ、運用の短期・長期コストを合わせて天秤にかける必要がある
これは、専門家が意見を述べ、適切な妥協点を見つけられるだけの高い信頼と安全性があって初めて可能であり、自我や性格の衝突が簡単に妨げになるため、リーダーシップの成熟度が必要になる。鉛筆を芯の先で立てるという比喩はかなり的を射ている
その人がアプリを見て回り、文脈のない意思決定をすべて技術的負債と呼び始める。何度か見たことがあり、新しい VP Engineering に対して、当初の問題や意思決定、スケジュールの場にいなかったのに悪い判断だったと言うのは無知に見える、と伝えたことがある
幸い、その後別途呼ばれて感謝され、さらに多くの背景を聞かれた。全体の話を聞いた後は、私たちが正しい選択をしたことに同意してくれた。しかし逆の方向に進んだケースも見ており、そのときは本当に大変だった
すべてのチームをスプレッドシートに入れ、画一的な指標で管理を自動化しようとしただけで、直属の部下を管理し成長させることには集中していなかった
逆に、技術的にはやや弱いリーダーが来て、周囲のエンジニアたちが多少の男性優越主義を交えながら目を回すのを見たこともあるが、実際には悪い採用を退場させ、スター人材を採用し、全員の優先順位をそろえて生産的にした。リーダーシップは技術的卓越性とはまったく別の仕事であり、本来は昇進ではなく昇給やボーナスで報いるべき能力が、あまりにも頻繁に昇進で報われている
リーダーシップ経験がありながら実務能力もあり、十分な時間が与えられれば新しい技術スタックや財務上の動きの細部まで理解できる人は、長期的なリーダーシップ貢献によって現場のスーパースターたちから尊敬され得る
同意しない。小さな会社を立ち上げたことがあり、FAANGや大手銀行を含む巨大企業でも働いたことがあるが、そうした没入感のある環境はどこでも作れる。
重要なのは、ダイナミックなリーダーが、人々がなぜその場にいるのかを正確に理解しているチームを作り、各自に得意な仕事を任せ、苦手なことは得意な人が助けるようにすることだ。そのうえで、チームの使命が企業の使命や世界における目的に対してどんな価値を持つのかを明確にし、生産とインパクトを妨げる障壁を粘り強く取り除かなければならない。
N²コミュニケーションのような主張は還元的で不正確だ。どのチームも組織内のすべてのチームに依存しているわけではなく、通常、領域は小さく、隣接チームも有限だ。コアチームは例外だが、うまく機能しているコアチームはN²のオーバーヘッドではなく、チームが集まってくる焦点のように振る舞うN構造になる。
Nが大きくなることはあるので、効果的な選別、自動化、セルフサービス、自己文書化された一貫性のあるプラットフォーム、そして教えることが本当に好きなチームメンバーが重要になる。こうしたチームを作るのはマネジメント面でとてつもなく大変で疲れ果てたが、本来マネジメントとはとてつもなく大変であるべき仕事だ。次の仕事では後期スタートアップのdistinguished engineerに戻り、しばらく原点に戻るつもりだ。
ただし、そうした没入感のある環境はどこでも作れるし、人々がなぜその場にいるのかを理解しているチームを作るダイナミックなリーダーが重要だという点は正しい。それでも、規模や悪いインセンティブとは関係があると思う。FAANGでも、ある部門はスタートアップのようで、別の部門は魂を吸い取られるような退屈さだという話を聞いたことがある。
挙げられた反例はN²の複雑性が存在しない例ではなく、その複雑性を適切に管理した例だ。
すべてのチームが他のすべてのチームに依存しているわけではないと言うなら、むしろ記事に同意していることになる。だとすれば、どの部分が間違っているのかわからない。
大規模組織で得られるという規模の効率は、実際には効率ではないように感じる。採用、人事、品質保証、ユーザー調査のような専門人材を置く、といった類の効率のことだ。
より「効率的な」組織構造を作るよりも、最も小さく効果的に機能していたチームを繰り返し複製する形で組織を成長させるほうがよいのかもしれない。ただし、そうした「ミニ会社」同士が効率的にコミュニケーションする方法は、また別の問題だ。
会社の価値が大きくなり、リスク許容度の低い株主やマネージャーが入ってくると、リスク管理と回避に多くの資金を使わなければならない。以前の会社では、競合がユーザーの要求を解決しようとして露骨に法律を破っていたが、小さくて収益もなかったためか、何事もなく済んでいたようだった。
また個人的な経験では、ほとんどの従業員は創業者ほどエネルギーを投じないが、それは完全に理解できる。創業者対従業員の比率が小さくなるほど、自分が一人でできることを安定して期限どおりに終えるために、3人を雇うようになる。
初期採用者は創業者に近く、会社が成功したときに得るものも大きいので創業者により近いが、213人目の従業員は週40時間の労働を売っており、実質的に固定給が得られるもののすべてだ。複数の独立したスタートアップから成る大企業というロマンチックなアイデアはよいが、実際に機能しているのを見たことはなく、うまく想像することもできない。
拡大する最善の方法は、チームに求める特性を強化するプロセスを作り、チームがそれぞれ異なる個人の集合だと理解しているマネージャーを採用することだと思う。マネージャーは、自分の人員を、デリバリーを最適化し離職を減らす形で自由に管理できるべきだ。
チーム間ではコミュニケーションと成果物の品質基準が非常に高くなければならず、組織文化は、採用された各個人への尊重と、各自が効果的に働けるチームに配置されるようにする執拗な集中の上に築かれるべきだ。
労働の果実がますます高いところにぶら下がるようになる。スタートアップ初期は問題空間が豊富で、個人が生み出せるインパクトが異常に大きく、その成果を分け合う人数も最も少ない。
会社が大きくなると、この3つの要素がすべて圧迫される。問題空間は希少になり、大きなインパクトへの評価はますます階層の上のほうに持っていかれ、インパクトを共有する人数は増え、評価は短くぼやけたものになる。
しかし結局、単一の巨大組織になった。Valveのフラットな組織構造も同様だ。十分に大きくなれば、何であれ最終的には塊になる。
成長管理の技術は、かなりの部分、人々に足かせをはめるのではなく解放する方法を見つけることにある。
「ほとんどのスタートアップは大企業のプロセスをまねて、不必要に企業化の速度を上げている。たいてい大企業出身のマネージャーを連れてきて、彼らが自分のプレイブックを持ち込む」という一文は痛いほど正確だ。
このサイクルを何度か経験した。一番好きで、最後に成功したスタートアップは、4年目の2007年に巨大なグローバル企業に買収され、私はさらに2年残った。
製品リリース後は、カスタマーサポートと営業支援の必要性から、明らかにスピードが落ちた。優秀だったVP EngineeringがCTOになり、中間管理職のバカをVPとして採用したことで、良い時代は終わった。新しいVPは優秀なエンジニアではなく「チームプレイヤー」を採用し、能力より忠誠心に報い、おかしなことが起きた。
私にとって楽しいスタートアップらしい時間は、1年にたった1週間、クリスマスから新年の間だけに縮んだ。その週は誰もいなかったので、自分が重要だと思うことをずっと自由に進められ、きらびやかな新機能のアルファ版を作って、組織に後から追随させることができた。
候補者の中には、サメのような人たちが驚くほど多い。彼らは現れて、あなたが新任だと察知し、あなたが聞きたいことをすべて言い、あらゆる問題を解決すると言う。前職の会社それぞれで、あなたにまさに必要なその仕事をやってきたと主張し、お世辞を言い、あなたのような人と働く機会を待っていたと言う。
これまで面接した中で最も口のうまいIC候補の、5倍強力で見抜きにくいバージョンだと思えばいい。彼らは信じがたいカリスマを持っているが、難しい仕事をする気はあまりなく、会社に食い込んだ後に搾り取ろうとする。
自分の報酬、友人を雇うための人員枠、友人たちの報酬、外部委託先の友人たちへの利益率の高い契約を引き出し、場合によってはリベートすらあるかもしれない。多くの活動を作り出すため、実際には大したことをしていないと人々が気づくまでに何年もかかることがある。その過程で、有能な社員はくだらなさに疲れたり、無能さを指摘したという理由で追いやられたりして、去っていくこともある。
Safi BahcallのLoonshotsは、この現象をかなりうまく説明している。150人前後でインセンティブの「相転移」が起き、多くの組織にとって致命的になり得る。
コツは、スタートアップがこの人数をどう超えるかにある。正直、多くのソフトウェア企業には150人を超える人員は必要ないのかもしれない。
ダンバー数は、安定した社会的関係を維持できる人数に関する認知的限界として提案された概念だ。ここでいう関係とは、各人が誰で、互いにどうつながっているかを知っている関係を指す。
https://en.wikipedia.org/wiki/Dunbar%27s_number
世界は数千年前にすでにこの限界を超えて拡大しており、会社もそれ以上に拡大できる。
採用を減らせという助言の価値は、いくら強調してもしすぎることはない。別の言い方をすれば、問題を解決する他の方法がないときだけ採用し、その場合でも慎重であるべきだ。
この原則のために、スケジュールがかなり長くなることは受け入れなければならない。過剰採用の中長期的コストは、リリース遅延のコストよりはるかに悪い。残念ながら、スタートアップの資金調達環境と成長期待は、しばしば逆の行動を促す。
ただし、シリコンバレーのスタートアップの採用状況がここまで悪化しているとは、かなり過小評価していた。多くの人がFAANGでのバーンアウトから回復したり、面接準備をしたりする間に、履歴書に書くための居場所としてスタートアップを利用している。
こうした構造では、会社を作れる数少ない人を逃すリスクがあるため、採用マネージャーは過度に楽観的に傾きがちだ。結局、合わない人は積極的に退場させる必要がある。
この記事には気に入った部分もあり、同意しない部分もあった。
最も同意したのは「早すぎる採用をするな」という部分だ。採用が遅すぎて失敗したり苦しんだりしたスタートアップや会社はあまり思い浮かばないが、採用が早すぎたことで生じた問題は、個人的な経験も含めて非常に多く思い浮かぶ。
一方で「Jiraを使うな」という部分には目をむいた。太陽が東から昇るのと同じくらい、エンジニアがJiraをこき下ろすのは大好きな趣味だ。スタートアップのタイプによっては、Jiraはその仕事にとても良いツールになり得る。
会社がサポートしなければならないワークフローが多い場合、追跡がうまくいかず、イシューのオーナーシップが明確でないと、取りこぼしが増えて大きな時間の浪費につながる。もちろん、不要なステータスを山ほど作ってJiraを過度に複雑にしても時間を浪費しやすいが、最近のJiraは小規模チームがすばやく生産的に使いやすくなっていると思う。
Jiraが始めるのに最高のツールだという意味ではないし、前回のスタートアップはTrelloで始めてうまくいった。だが運用フェーズに入り、新機能開発と並行して多くの運用上のイシューを管理し優先順位づけしなければならなくなると、全員の足並みをそろえ、情報を共有するためにJiraのようなツールが必要になる可能性は高い。