訳者注

ここでいう「プロジェクト」は一般的な意味合いではなく、Linear における Project の単位をイメージして訳しています
- Linear ではいくつかの Issue（タスク）をまとめる単位として Project があり、その説明や設計資料とともに、開始日や終了日、必ずオーナーを定める形になっています
- Linear ではいくつかの Project を時系列こみで束ねるものとして Roadmap という機能があります
ここでいう「ロードマップ」は Linear 上の Roadmap を指すと捉えることもできますが、もう少し広い意味で捉えても良さそうに思っています

Direction（プロダクトやチームの方向づけ）

ロードマップはチームを方向づける

方向性を設定することは、プロダクトや会社を作り上げていく際に最も重要なことの一つである。明確な方向づけがあれば、全ての人が同じゴールに向かって働けるようになる。明確な方向づけは、個々人の日々の意思決定を助けるばかりか、チームがプロジェクトの優先順位を決めることができ、組織の全てのメンバーが共有された目的に向かって動機づけられることを助ける。方向づけなしには、協働することも、フォーカスすべきことを知ることも、意味のある進捗を出すことも難しくなる。

ロードマップは方向性を形作るための決定的なツールである。ロードマップを作るプロセスによって、ビジョンを明言し、ビジョンに向かってどう作り上げていくかを決めることが必須になる。集大成となるロードマップは、近い将来の実行の道筋を示すものである。それは、一部は具体的に見えているが、理想像としてはまだ手の届かないところにあるものであるべきだ。会社の誰もがロードマップを見ることができ、何に取り組むべきか、なぜそれが重要かを、素早く理解できなくてはならない。ロードマップをチラ見することで、進捗が明らかになり、注視すべきプロジェクトがどれかがわかるようになっていなければならない。

3人のスタートアップだったとしても、1000人の従業員を抱える企業だったとしても、ロードマップは、あなたや共に働く全ての人が、迅速に意思決定でき、より価値ある仕事にフォーカスできることを助ける。明確なロードマップは、たとえ個々人の仕事が独立に行うものだったとしても、チームの連携は保たれる。野心的なロードマップは、人々が最高の仕事をするために挑戦することを後押しする。目に見えるロードマップは、自分の仕事がなぜ重要なのか、その背景を示すことで個人のモチベーションを高め、信頼を築く透明性のある文化を創造する。それにより、コラボレーションが容易になり、思いがけずコラボレーションに拍車がかかることもある。

プランニングへの投資

ロードマップを計画するにはいくつかの方法がある。全員が参加したとしても効果的に議論できるほど小さい組織である場合を除き、ロードマップを計画するためにリーダー陣からなる小グループを選出するかもしれない。最初の打ち合わせの前に、会社の目標やプロダクトのどの部分を最も改善したいかを考える時間を設けることは有意義だ。プロダクトに対する直感を働かせるのだ。顧客のフィードバックや機能要望をレビューしよう。会社の指標、例えば契約数や有効顧客数や継続顧客数や収益などをレビューすることも重要だ。それにより、機能実装やアプリケーションのどの分野をより優先すべきかといった事柄の間にあるトレードオフを明確にできるからだ。

最初期のロードマップは小さなチームで作り上げていくだろうが、何らかの形でロードマップの計画に携われるなら、組織やチームにより参画していると感じやすくなり、よりオーナーシップを持ちやすくなるだろう。全ての人々にロードマップ作成に貢献するチャンスを与えよう。各チームに自身の関わるプロジェクトを提案してもらい、誰もがフィードバックやアイデアを提出する期間を設けることもできる。同様に、顧客とも会話しよう。特に顧客のニーズやプロジェクトのスコープが明確でないなら、検討中の機能を求めている顧客に働きかけて優先順位を決めよう。どんなロードマップの作り方をするにしても、そのプロセスのタイムボックスを決め、再現可能な構造を生み出しておくことが有効である。それにより時間が経てば経つほどロードマップが作りやすくなるのだ。

プロジェクトを充実したものにするには

あなたが取り組もうと決めたプロジェクトは、何らかの具体的な進捗を生み出すことが理想だ。新しい機能を作ったり、キャンペーンを開始したり、プロダクトの既存機能を改善したりするだろう。機能構築を完了させ、その進捗が意味のないものに思えるほどプロジェクトが細切れになるのを避ける。ツール作りやドキュメンテーションのような、何としても完了させねばならないプロジェクトもあるだろう。そしてそれらをロードマップに当てはめ、仕事の種類と強度のバランスを取るようにする。
より楽しく仕事をするために、チームは細かいイシューをまとめることもあるだろう。例えば、バグウィークと呼ぶプロジェクトを作ったとしたら、バックログにある優先度の高いバグの修正に集中することができるだろう。

インパクトによって優先付けしよう

より重要なプロジェクトに作業を集中させるために、より高い目標となるマイルストーンにしよう。基盤となるプロジェクトや、顧客の体験に最も大きな影響を与えるプロジェクトを優先しよう。顧客のためにプロダクトを改善しないプロジェクト、会社の目標達成に役立たないプロジェクト、仕事の質とスピードを上げないプロジェクトは優先順位を下げよう。

取り組むべきプロジェクトのリストができたら、チームメイトの許容量とプロジェクトの強度を調整しながら、必要に応じて順番を調整しよう。燃え尽き症候群にならないように、大きな機能をリリースした後は、小さなプロジェクトをいくつか担当してもらおう。プロジェクトのリーダーを交代させることで、トップパフォーマーが過負荷にならず、全員がプロジェクトマネジメントのスキルを身につける機会を得ることができる。チームとして、個人としても、一度に取り組むプロジェクトはできるだけ少なくしよう。新しいプロジェクトを始める前に、既存のプロジェクトはリリースしてしまおう。集中することでより質の高い仕事が生まれるし、継続的にリリースすることでそれが習慣化されていく。プロジェクトを順番に進めることで、新しい仕事が前のプロジェクトの上に積み重なり、変化が有機的に感じられるようになり、複合的な効果が期待できる。また、中途半端なプロジェクト10個でロードマップを終えるよりも、重要なプロジェクト3個をリリースしたほうがいい。

定期的にレビューしよう

ロードマップを見直し、プロジェクトの進捗を評価することをルーチン化しよう。毎週のチームミーティングにロードマップの見直しを盛り込むだけでなく、プロジェクトリーダーに直接確認してもいい。プロジェクトリーダーが、状況や完了予定日を報告するだけでなく、率直に共有し、助けを求めることを積極的に奨励する環境を作るべきだ。ロードマップ全体の進捗状況を確認したり、今後のプロジェクトの優先順位を見直したり、顧客からの新しい情報やフィードバックに基づいて変更を加えたりするために、時々定期的なレビュー以外で確認をすることも、会社のリーダーにとって有益だろう。優れた計画も、その通りに実行されていなければ意味がないし、定期的なレビューがなければ、どの程度うまくいっているのかわからない。

常に柔軟でいよう

ロードマップは無理なく充実したものでなければならない。バランスの取れたロードマップでは、バグや修正、バックログにあるイシューへの着手に費やせる作業時間が全体の3分の1まで確保されている。プロジェクトの見積もりには最善を尽くし、自分が考えているよりも時間がかかることを想定しよう。また、ロードマップに追加するプロジェクトは、少なすぎず多すぎず、野心的であるほうがいい。現実的なプロジェクト数より2、3個多い方が、リリースしようというチームの士気が高まる。プロジェクトが少なすぎると、スケジュールのスピードに合わせて仕事をするという罠にはまり、モメンタムが鈍化してしまう。

また、ロードマップを変更ができる活きの文書とみなすことも有効だ。状況は変化し、プロジェクトを移動させたり、追加したり、遅らせたりする必要が生じることもある。ただ、あまり頻繁にプロジェクトを変更したり、シャッフルしたりすると、当初の方向性から外れたり、モメンタムを失ってしまう危険性がある。

Linear ではどうやってロードマップを設定しているか

我々は四半期ごとにロードマップを作成している。各四半期には明確なテーマが設定されており、例えば2020年第4四半期は「コアユーザーの体験」であった。

事業的なニーズ、プロダクトとしてのゴール、顧客のフィードバックを踏まえて、我々はフォーカスを選択し、フォーカスされたゴールから逆算する形でプロジェクトを選択する。そして、我々はロードマップにはいくらかの余白を持たせるようにする。理想的なのは、ロードマップに必要な仕事は可能な仕事量の60～80％になるように設定し、バックログのイシューに取り組んだり、バグを修正したり、予期せぬニーズに対応したりする余地を残しておく。

我々は、ロードマップの作成に各四半期の初め2～3週間を費やす。厳密な手順が決まっているわけではないが、通常はその期間に数回の会議を重ねた上で最終化する。会議の合間には、SlackやZoomでフィードバックやアイデアについて議論する。四半期のプロジェクトが決まったら、時系列順に優先順位をつけ、最初のプロジェクトにプロジェクトオーナーをアサインする。明確なオーナーがいない場合は、プロジェクト開始日が近づくまではアサインしないままにしておく。誰の手が空くのか、過去のプロジェクトがいつ終了するかを予測するのは難しいからだ。

我々は全てのプロジェクトに必ずリードをアサインする。彼らは、プロジェクト仕様書の作成、プロジェクトチームでの会議の主導、Change Logs の作成に責任を持つ。個々のプロジェクトチームメンバーは、プロジェクト内で担当するイシューを作成し、リードはプロジェクトをリリースすることに責任を持っている。

我々の週1回の全社会議はロードマップのレビューから始まる。プロジェクトのリストを時系列順にひとつひとつ確認し、各プロジェクトオーナーがチームの状況を報告する。障害や問題が出てきた場合は、すぐに話し合うか、会議後すぐに解決しようとする。

四半期を通して、緊急な対応や臨機応変な対応が急遽必要になり、プロジェクトが長引いたり、スケジュールが繰り上がったり繰り下がったりすることはよくあることだ。これは予想の範疇で問題にはならない。我々は個々のプロジェクトに特定のリリース日を設定することを好まない。プロジェクト詳細のサイドバーでグラフを見ることで完了予定日は分かるし、Cycle や Change Logs を確認することでモメンタムを感じ取ることはできる。一方、締め切りが役に立ったり必要だったりすることもある。社外と連携する必要のある機能リリースや、期間を設定した方がスコープを狭められる場合などだ。例えば、コーポレートサイトの微調整のために、そのリリースを延期し続けることは簡単だが、サイトの見た目が少しだけ良くなることが顧客や会社の付加価値につながるわけではない。それよりもチームにはプロダクトの機能にフォーカスしてもらったほうがいい。とはいえ、最新リリースのために見た目を改善するのはとても楽しかったし、Big Sur のロゴには必要以上に時間を費やした。楽しい時間だった。

有用なゴールを設定しよう

スタートアップの動きは非常に速く、翌週はおろか翌日も何に取り組んでいるのかわからないのが普通だ。会社の中長期的な成功のために何が重要か忘れないために、ゴールは重要である。ゴールを何にすべきかを判断するのに、十分なユーザーや実績データがないと思うこともあるかもしれないが、それは普通のことで、そのような状況では、何らかの測定可能な方法で進捗がわかるゴールをさしあたり設定すればいい。

初期の頃は、ゼロからはじめていきなりゴールを達成するのは難しいかもしれない。ゴールに到達する道のりを考えるには、ゴールから逆算することだ。10ユーザー獲得するにはまず1ユーザー獲得しなければならないし、1ユーザー獲得するにはそもそもプロダクトがリリースされていなければならない。10ユーザー獲得のための、最初の意味のあるゴールはユーザーを10人見つけることであり、それからユーザー100人獲得、さらに1000ドルのMRR獲得にゴールが変わっていくかもしれない。成功するスタートアップは、多くの場合は小さなゴールから始め、ゴールの達成に必要なことを理解し、そしてスケールさせていく。そして、成長スピードに限界はないことを覚えておいてほしい。

エネイブラーとブロッカーの優先度付けをしよう

仕事の優先順位をうまくつけ、なぜ優先順位をつけたのか、つけなかったのかを明確に説明できるようになることが本当に重要だ。特にアーリーステージでは、リソースも時間も無限にあるわけではないから、それらをうまく活用することが必須だ。

まず、新機能を作るとして、それがエネイブラーを追加するものなのか、あるいはブロッカーを取り除くものなのか、考えるとよい。エネイブラーは、通常はプロダクトの価値を高めたり興味深いものにする新機能のことだ。ブロッカーは、ユーザーや顧客が製品を使うのを妨げるギャップや摩擦のことだ。機能を構築する前に、それが本当にプロダクトの使用を妨げているブロッカーを取り除くものなのか、それともユーザー体験においてあった方が良い程度のものなのか、理解するよう努めるべきである。企業の成長は、適切なエネイブラーにエネルギーと労力を投資し、クリティカルなブロッカーを取り除くことによってもたらされる。

次に、どれだけタイムリーに構築できるかどうかを考えることが重要だ。作るべきものは、常に使えるリソース以上にあるものだ。アーリーステージでは、いずれ構築する必要のある機能がたくさんある。今週、あるいは今月は、影響が大きいものを優先しよう。これは今やるべき重要なことなのか、それとも後でも良いことなのかを自問自答してほしい。そのプロジェクトやタスクが完了すれば、より高い目標となるゴールの達成につながるのか？　加えて、今それを構築することで複合的な効果があるのか、複雑さやコストがどのように増加するのか（例：顧客別対応の増加）を把握する必要がある。

例えば、我々は Linear のβ版をGoogleアカウントによるログインのみでローンチした。それがユーザー認証を構築する上で最も速い方法だったからだ。その後、それ以外の認証方法を開発する代わりに、他の機能に着手した。より多くのユーザーや大規模な顧客を獲得するために、最終的にはメールアドレスや他のログイン方法をサポートする必要があることは分かっていたが、β版のユーザーコミュニティを立ち上げ、運営するためには必要なかった。これにより、我々はより早く他の機能に着手できた。

プロジェクトのスコープを絞ろう

アーリーステージでは、プロジェクトのスコープを絞ることが特に重要だ。1～3人のチームなら1～3週間で完了できるようにプロジェクトを設計する。小規模な修正や追加であれば、数時間から1日程度で済むようにする。

プロジェクトを短くすれば、最も重要な機能を優先せざるを得なくなる。また、継続的にリリースする習慣を身につけることで、顧客との素早いフィードバックループが生まれる。少人数のチームであれば、より速く進めることができ、マネジメントやコミュニケーションのオーバーヘッドを減らすことができる。プロダクト構築の初期では、どのプロジェクトがインパクトのあるものになるかどうかを十分に予測できていないため、大規模なプロジェクトは避けた方がいい。プロジェクトのスコープを縮小する方法がない場合は、段階的に分割する。

例えば、 Linear を始めて最初の数ヶ月で、我々は Cycles と Projects の最初のバージョンをリリースした。この2つの機能のMVPバージョンは、設計と構築に2週間ほどかかった。最初の1週間で、我々自身とプライベートβのユーザーに向けた初期バージョンをリリースし、すぐにユーザーフィードバックを収集し、次の数週間で修正を開始した。それ以来、我々は Cycles と Projects に多くの改善を加え、今ではどちらもプロダクトの主要な機能となっている。

Linear Method 私家訳 / Direction

免責事項的な

目次

訳者注