免責事項的な
- 以下はあくまで個人的な理解のために翻訳したものです。Linear社は一切関係がありません
- 以下の翻訳の利用は利用者の責任によるとし、翻訳者は翻訳の正しさに責任を持ちません
- 私は特に英語が得意なわけでもないですし、誤訳が含まれている可能性があります。また、ところどころ意訳が含まれている一方、カタカナ語としてそのままにしているところもあります
- 誤訳、ご指摘大歓迎です。助かります！
目次
訳者注
- ここでいう「プロジェクト」は一般的な意味合いではなく、Linear における Project の単位をイメージして訳しています
- Linear ではいくつかの Issue（タスク）をまとめる単位として Project があり、その説明や設計資料とともに、開始日や終了日、必ずオーナーを定める形になっています
- Linear ではいくつかの Project を時系列こみで束ねるものとして Roadmap という機能があります
- ここでいう「ロードマップ」は Linear 上の Roadmap を指すと捉えることもできますが、もう少し広い意味で捉えても良さそうに思っています
- ここでいう「イシュー」は一般的な意味合いではなく、Linear における Issue の単位をイメージして訳しています
- 多くのプロジェクト管理ツールにおける「タスク」「課題」「ユーザーストーリー」などに相当するものです
- Linear の場合は Issue は任意の Sub Issue をぶら下げることができます。Sub Issue にさらに Sub Issue を作ることもできます
- Linear の場合は Issue または Sub Issue はプロジェクト管理の最小単位となり、github の Pull Request を紐づけることができます
Building（実際のプロダクト開発）
モメンタムを生み出そう
あなたとあなたのチーム全体は、素早い行動を取り、日々進捗を生むように常に努めなければならない。何かをしようと考えたり話したりするのではなく、やるかやらないかを決めるのだ。そして、明日やるのではなく今日、来週やるのではなく今週やるのだ。
何が最もやるべき重要なことなのかわからない週もあるだろうし、プロダクトの中でどのような決断を下すべきか迷う週もあるだろう。そのようなときに麻痺してはいけないーーー代わりに行動に移せる方法を探すのだ。自分の直感を信じて、理にかなっていると思えることをやってみよう。より多くのユーザーと話し、より多くのフィードバックを得ることで、明確にしていくことができるだろう。素早く動き、学習するように業務を設計できていれば、決定を修正したり巻き戻したりすることもできる。
先に行き過ぎたとか、悪い決断をしてしまったとかだけで、スタートアップが滅びることは殆どない。スタートアップが滅びるのは、動きが遅すぎたり、諦めてしまったときだ。
ユーザーストーリーではなくイシューを書こう
Linear ではユーザーストーリーは書かないし、プロダクト開発におけるアンチパターンだと考えている。我々は代わりに、タスクを平易な言葉で説明する短くシンプルなイシューを書く。
イシューを書く意味は、タスクを伝えることだ。担当者がそれを実行できるほど十分に明確である必要があり、また、知る必要のあるチームメイトがチームでどのような作業が行われているかを理解できるように、十分な文脈が記載されている必要がある。であるので、イシューを書くときのゴールは、これをできるだけ効果的に素早く行うことだ。
なぜユーザーストーリーは使われなくなったのか
ユーザーストーリーは20年以上前から、ソフトウェアチームが提供できる形で、顧客が何を求めているかをプロダクト要件に落とし込む方法として発展してきた。だが、今日に至るまでにソフトウェアの構築方法において多くの変化が訪れた。顧客は基本的なプロダクト要件を明確にできるほど技術に精通している。ショッピングカート、Todoリスト、通知メッセージといった一般的な機能の標準が開発されたので、それらがどのように機能すべきかを説明する必要はない。そして、最高のプロダクトチームやエンジニアリングチームは、ユーザーを深く理解し、プロダクトがどのように機能すべきかを熟知しているものだ。
ユーザーストーリーは、カーゴカルト的な儀式となっており、一見良さそうに見えるが、多くのリソースと時間を浪費する。ユーザーストーリーはタスクを遠回しに説明するものであり、なすべき仕事を不明瞭にしている。ユーザーストーリーは、書くのにも読むのにも時間がかかり、エンジニアをプロダクトレベルでユーザー体験を総合的に考える役割ではなく、要件に合わせてコーディングする機械的な役割に閉じ込めてしまう可能性がある。ユーザーストーリーが複雑で、スコープ決めが難しい理由の1つは、プロダクト全体レベルの詳細であるべきものを個々のタスクレベルに持ち込んでしまうからだ。そして、率直に言って、ユーザーストーリーは、我々が実際の会話でソフトウェアについて議論している内容と噛み合わない。
イシューのより良い書き方
何よりも、明確でシンプルで、タスクが平易な言葉で説明されているイシューを書くのがよい。自分のイシューを書く場合には、タスクレベルではなく、プロダクトや機能レベルでユーザー体験を議論する。ユーザーストーリーの作成に時間を費やすのではなく、構築する前にユーザーと話し、機能について考えることに時間を費やす。
具体的なタスクや問題を記述する
イシューには明確で決まった成果を伴うタスクを記述するべきである。それはコードの一部だったり、デザインだったり、ドキュメントだったり、取るべき行動そのものであったりする。もしそれがタスクでないなら、イシュートラッカーシステムに入れるべきではない。ドキュメントや会話で具体化すべきプロジェクトのアイデアだったり、より細かく具体的な仕事に分解する必要のある大きな機能などが、それにあたる。
ただ、このルールには例外もある。例えば、ある機能に取り組む前に、デザインや技術的なアプローチについて時間をかけて検討する場合、プレースホルダーのイシューを作成して後で分解したり（例：「デザインを検討する」）、成果物として定めることができる場合である（例：「プロジェクトの仕様を書く」）。
明確かつ直接的に書こう
イシューには短くシンプルなタイトルをつけることで、タスクが何であるかを直接的に表すことができる。殆どの人が、他のイシューを担当している中、一覧やカンバンでタイトルを目にすることになるため、タイトルは探しやすいものであるべきである。説明文は必須ではなく任意であり、関連する考えや文脈、より深い議論へのリンクを含めることができる。タスクを実行し、関連する情報をチームに伝えるために共有する必要がある分だけを書けばよい。
機能リクエストやバグレポートを共有するときは、ユーザーのフィードバックを要約するのではなく、直接引用する。多くの場合、顧客はあなたが要約するよりも、より真実に近い形で問題点を説明してくれるし、コピペしてしまった方が単純に早い。さらに詳しい情報が必要な場合は、顧客との会話にリンクを張れば簡単に情報が手に入る。
自分が担当するイシューを書く
チーム全員が自身が担当するイシューを自身で書くべきだ。その仕事のやり方を理解している人が、その仕事を説明するイシューを書く方が早いし簡単だ。また、チームがより良い仕事をするための準備にもなる。自分でイシューを書くと、問題を深いレベルで考えざるを得なくなる。そうすることで、より良いアプローチについて考える機会となり、近道となる解決法や欠けている部分を見つけやすくなる。このプラクティスはまた、仕事への取り組み方を完全に見直すことにもなる。タスクが完了したことをマークしたり、要求事項のリストをチェックしたりするのではなく、プロダクトやプロジェクトの成果物に焦点を当てるのだ。
バグレポートを提出するときなど、他の人のためにイシューを書く方が理にかなっている場合もある。そのようなイシューの書き方は少し異なるという注意点とともに、奨励すべきやり方である。こういったイシューを書くときは、質問形式で記述するか、起きている問題を記述する。担当者に解決策を考えさせ、イシューをタスクとして書き直してもらうのだ。
ユーザー体験の議論はプロダクト全体レベルで続ける
プロジェクトを仕様化し、ロードマップを作成する際には、顧客体験についてプロダクト全体レベルで議論しよう。このような話し合いには、デザイナー、エンジニア、顧客担当者など、チーム全員に参加してもらい、全員がユーザーニーズや制約やプロダクト要件を深く理解する必要がある。そして、プロジェクトチームに委譲し、彼らが成果を出すことを期待する。プロジェクトチームは直感的にユーザー体験を理解するので、タスクレベルで明確にする必要はない。
Linear ではどうやっているか
実装プランを決める前に、我々は機能やプロジェクトについて深く話し合う。プロジェクトオーナーが仕様を書き、正しいアプローチだと思えるまでフィードバックを集め、その後にコードを書き始める。機能を構築する前に、数週間かけて考え抜くことも珍しくないが、正しいプランが決まれば、そのまま実行モードに入る。プロジェクトオーナーは各プロジェクトメンバーに仕事を委譲し、それぞれ自分が担当するイシューを書き上げることから始まる。
プロジェクトにおけるデザインの進め方
Linear ではアプリ内のデザインタスクを管理し、デザイナーとエンジニアが密に連携して機能を構築する。そのプロセスは、一般的なプロジェクト管理手法とは相容れないように思えるかもしれない。プロジェクト開始時にデザインがどのようなものになるかを予測することは難しく、ましてやいつ提供可能になるか見積もることも困難である。バランスをとりながら効果的に協力し合うために、我々がプロジェクトのデザインに際してとっている手法をいくつか紹介する。
問題を検証しよう
どんなプロジェクトにおいても、最初のデザインタスクは問題を検証することだ。一画面を作りあげるなど、問題が明確でシンプルなこともある。一方、問題が不明確だったり不十分だったりして、実装前に調査が必要になることもある。これは、特に顧客やプロダクト以外のチームからの機能要求を取り上げた際によくある。ユーザーは、彼らの問題Yを解決するために特定の機能Xを構築するよう求めてくる。しかしながら、その機能Xは、ユーザー目線での問題の捉え方のみで定義され、その解決のためにユーザー目線でどのようにプロダクトの改修をできそうかという見え方によって、制限されたものになっていることが多い。表層的な問題の調査から根本的な原因を見つけ、それを解決することがデザインの挑戦である。デザイナーとして最も重要なステップは、問題が実際に存在し、解決すべき正しい問題であることを検証することだ。
Linear では、自分たちで製品を使って色々と試すことで、このデザインと調査の多くを行う。デザインチームは Help や Feedback 用のモーダルウィンドウや、公開Slackコミュニティを通じてユーザーから寄せられた機能要望を定期的にレビューしている。実装が予定されている機能であれば、Slack や Linear のイシュー上で、それらについて日常的に議論している。そして、問題を深く考えざるを得ないように、機能を開発する前にプロジェクトの詳細仕様を記述することに、我々は投資している。
探索段階でのやり方
問題が明確になったら、次はさまざまなデザインの可能性を探索することになる。我々は Linear に 「デザイン探索」というイシューを作成し、プロジェクトのプレースホルダー用のイシューとして管理していく。
この段階では、実現可能かどうか、デザインシステムに合うかどうか、そもそも良いアイデアなのか、などを判断せず、自由に解決策を探索することが重要である。悪いアイデアは、創造していくプロセスにおいて自然と生まれるものであり、思考を明確にする助けとなり、他のアイデアがより良いアイデアである理由さえ示してくれるものだ。問題によっては、調査に数時間から数日かかることもある。（他のプロダクトなどから）ベスト・プラクティスを学び、インスピレーションを得るための調査もあれば、Figma上でいろいろな実験をしてみる調査もある。小さな機能であば、異なるUIを何度か試す必要があるかもしれないが、大きい機能では良いと思えるものに辿り着くまで、方向性自体が複数に枝分かれすることもある。正しいものに辿り着けるのは、大抵は他者からのフィードバックを得た後になるが。
参考: Figma design demo: Linear release page with Karri Saarinen
（2020年12月の Linear の release page について）
フィードバックに導かれる
最初の探索の後、チームメイトを始めとする他の人たちからフィードバックや反応を得るべきだ。彼らの反応を観察しよう。彼らがデザインについて何か言っているなら、何を言っているかだけでなく、なぜそれを言っているかに注目しよう。まだ探索している間にフィードバックを得るべきで、ディテールや洗練度については気にする必要はない。もし否定的なフィードバックを得たとしても、必ずしも方向性が間違っている兆候とは限らず、なぜそういったフィードバックになったのか知ることに集中しよう。方向性としては正しかったが、既存のバージョンのデザインが完全におかしいせいだったか、フィードバック者の問題に対する理解に合わなかったせい、ということもある。デザインやストーリーにあるギャップを見つけて、それを埋めていこう。
デザインについてのフィードバックを得る際には、デザイン全体のレビューと、具体的な細部についての意見収集を交互に行う。一度に両方について良いフィードバックをもらうのは難しいことが多く、フィードバックしてほしい点がフォーカスされていないと、無用な脇道に逸れてしまいやすい。期待値を定め、どんなフィードバックを求めているのかを相手に伝えよう。
方向性を選択する
最終的にはデザインの方向性を決めなくてはならない。方向性をより具体化するために数時間から数日かかるかもしれないが、それまでに、その機能の構築に関わるエンジニアを含めて、少なくとも一通り社内のフィードバックを得ておきたいところだ。
この段階までに、どのようなデザインアセットが必要なのかよく理解しておくべきで、それにより具体的なデザインタスクをリストアップすることができるはずだ。たとえ細部が変わったとしても、機能の土台となる部分がそこにある。注力すべきデザインの部分を挙げていき、一つずつ片付けていくべきだ。タスクリストが片付いていくのは気分がいいし、全体のデザインに取り組んでいる最中だったとしても、手元の次のタスクに集中しやすくなり、空回りしてしまうことを避けられるだろう。
機能としての最終形や、それを構成するパーツはエンジニアから知らされるべきだ。エンジニアは技術的制約を指摘し、代替案を提案してくれる。これは、エンジニアが文脈を把握し、解決しようとしている問題についてより深い理解を得ることを助け、協働することが容易になる、一般的に良いプラクティスでもある。
デザインからエンジニアリングへの橋渡し
Linear ではデザインチームとエンジニアリングチームをどう繋いでいるのか、という質問をされることがよくある。 Linear では、プロジェクトのデザインから実装まで全体を通してデザイナーとエンジニアが協働しており、それはプロジェクトの仕様を書き始めた時から始まる。我々はプロジェクトチームとして仕事しており、ユーザーが触れる機能であれば必ずデザイナーがチームにいる。我々の Linear のワークスペースには独立する形でデザインチームが存在するが、我々のプロジェクトはデザインチームとエンジニアリングチームの間で共有される。そして、デザイナーもエンジニアもそれぞれ自分で担当するイシューを作成する。共同作業が必要なものについては、サブイシューによってデザインとエンジニアリングのタスクを分担している。
Linear ではどうやっているか: Karri のデザインプロセス
私自身、デザイナーとしてこのようなタスクシステムに悩んだことがある。何かをデザインするということは、しばしば全体的で、具体的なタスクに分解するのが難しい。デザインの一部分を変えたら、他の部分も変えたくなるかもしれない。また、最初のうちは未知の部分が多いので、先の計画を立てるのが難しく感じることもある。
会社全体として、私たちは機能を構築する際にプロジェクトを使って仕事を整理している。プロジェクト仕様書を作成した後、最初のデザインタスクはたいてい「デザインの探索」で、ある程度の時間（1日から1週間）を使って様々な方向性や選択肢を検討し、デザインすべき部分を把握していく。そして、フィードバックをもらうためにチームと共有する。Figma の画面や単なるスクリーンショットを Linear のコメントに貼り付けて、フィードバックが欲しい人にメンションすることが多い。Adrien は Loom の動画で共有するのが好きで、加えて Figma のリンクを貼り、変更点の概要やフィードバックが欲しい点を書いている。
デザインと方向性が見えてきたら、「X画面のデザイン」のような具体的なタスクを作る。何週間もかかるような巨大なタスクを抱えるよりも、やれそうで完了できそうな個別のタスクを抱えた方が、やる気が出るように感じる。デザインが完了したら、私はしばしば実装のサブイシューを作成し、チームのリーダーやエンジニアをアサインする。そうすることで、彼らがその機能を実装する際に、デザインタスクのデザイン的な決定と Figma のリンクを参照することができる。
ユーザーと共にプロダクトを作っていこう
アーリーステージのスタートアップに必要なことの多くは、顧客が何を求めているかを学ぶことだ。ユーザーや潜在的なユーザーからのフィードバックを求め、反復し、顧客や市場の要求に柔軟に対応する必要がある。
ビジョン vs フィードバック
とはいえ、ビジョンや直感を信じて作ることと、ユーザーが望むものを作ること、それらのバランスを取ることは創業者としての仕事でもある。ビジョンが強すぎるプロダクトはユーザーや市場のニーズを見逃しかねないし、ユーザーなどのフィードバックを受け入れすぎるプロダクトは明確な目的のないフランケンシュタイン的な創造物になってしまう。つまりは、ユーザーからのフィードバックをもとに、プロダクトのビジョンそのものについても磨き続ける必要がある。
機能開発ではなく問題解決をしよう
ユーザーは、プロダクトの目指す姿ではなく、現在目にしている状況やプロダクトから自身のニーズを述べることを理解しよう。ユーザーが追加すべき機能を求めてくることはよくあることだが、プロダクトの作り手としては、そういった場合は必ず彼らに質問を返すことが重要である。ユースケースは何か？ この機能やソリューションで解決しようとしている問題は何か？ その問題が解決されたら、プロダクトの体験はどう変わるのか？
ユーザーとの会話の軸を、機能要求から解決したい問題の説明に向けることで、何がペインであるのかという議論に変えることができる。そういった会話をすることで、その問題が解決すべき価値のあるものなのか、あったら嬉しい程度のものなのかが見えてくる。また、問題に対する複数の解決策を検討し、より広いビジョンに照らし合わせることで、本当に適切なものを選択することができる。
正しいユーザーのために開発しよう
元来ターゲット層ではないか、あるいは現時点ではそうではないが、多くのフィードバックを持っているユーザーに話を聞くこともあるだろう。もしアーリーステージのスタートアップ向けのものを作っていると考えているのなら、大企業の顧客の意見を聞くことは、あなたを間違った方向に向かわせる可能性が高く、その大企業が顧客になる見込みも薄いだろう。
フィードバックを取り入れ、プロダクトに磨きをかけるのはいいが、ユーザーからのフィードバックだけで何を作るかを決めてはいけない。ユーザーからのフィードバックに追従しすぎてしまう可能性がある。だからこそ、ユーザーと自分達のニーズのバランスを取るために、ゴールやロードマップを持つことが必要なのだ。
ローンチし続けよう
ローンチのタイミングは一度きりでなければならないという誤った考えがある。そうである必要はなく、多くの場合で多くのスタートアップが複数回ローンチしている。一度に大規模なローンチを行うよりも、普通はその方がうまくいく。大規模なローンチの問題点は、準備に時間がかかることと、リスクが高いことだ。ローンチがうまくいかず、すべての仕事が無駄になるリスクも高まる。何度もローンチすることで、時間をかけてストーリーとブランドを構築し、人々の関心を高めることができる。ローンチを重ねるごとに支持者が増え、それが将来のローンチに役立つのだ。
次に、最初の数ヶ月や数年間は、プロダクトが全てのユーザーにうまく当てはまるとは考えにくい。完璧なタイミングを待つよりも、早い段階でローンチし、ユーザーの獲得を進め、モメンタムを生み出す方が良い。
Change logs と同様に、ローンチし続けることは、自社の存在感や事業が進捗していることを市場に印象付けることにもなるのだ。
例えば、Linear を立ち上げたときは、プロダクトを作る前に会社設立を発表した。シードの資金調達を終え、プロダクトを進化させたとき、我々は発表をローンチした。プロダクトを全てのユーザーに開放し、価格設定を決めたときも、我々は発表をローンチした。シリーズAの調達を終え、さらにプロダクトを進化させたときも、我々は発表をローンチした。それぞれのローンチは、前のローンチよりも多くの人々に届き、より多くの顧客を生み出した。一度しかローンチしていなかったら、この状態になるまで1年半かかっただろうし、今の状態ほど多くのことを学べず、多くの顧客を得ることもできなかっただろう。
プロダクト作りを公開しよう
開発途中のものを見せるのは危険だと感じるかもしれないが、多くの場合、その方が役に立つ。危険などころか、競合他社はそのスピード感に落胆し、真似をせざるを得なくなるか、あえて真似を避けるようになるかもしれない。
プロダクト作りを公開する一つの方法は Change logs だ。ユーザー数が多くない段階から、Change logs をまとめるのは馬鹿げていると思われるかもしれないが、我々は役に立つと考えている。チームやチームメンバーにとって、Change logs は毎週何が起きているかを知らせ、コンスタントにリリースすることを促す。ユーザーにとっては、プロダクトが良くなっていっていることがわかる。投資家には、それは事業の進捗を示す。物事はなかなか進まないと感じるときも、すでにどれだけのことを達成したかを振り返ることができる。
Chagnge logs が役に立つ理由は他にもある。
参照: Startups Write Changelogs