免責事項的な
- 以下はあくまで個人的な理解のために翻訳したものです。Linear社は一切関係がありません
- 以下の翻訳の利用は利用者の責任によるとし、翻訳者は翻訳の正しさに責任を持ちません
- 私は特に英語が得意なわけでもないですし、誤訳が含まれている可能性があります。また、ところどころ意訳が含まれている一方、カタカナ語としてそのままにしているところもあります
- 誤訳、ご指摘大歓迎です。助かります！
目次
Introduction（はじめに）
プリンシプルとプラクティス
プリンシプル
クリエイターのために作ろう
ソフトウェアプロジェクト管理ツールは、そのエンドユーザー ――クリエイターのことだ―― を念頭において作られるべきである。クリエイター個々人を生産的にすることは、完璧なレポートを生成することよりも重要である。
意見を提案するソフトウェア
生産的なソフトウェアは、そのユーザーに対して意見を提案するようなものであるべきである。それが、プロダクトが真の意味であなたに大きな力をもたらす唯一の方法だ。そうではないユーザーに用途を委ねるような柔軟なソフトウェアは、結局ユーザーに自身向けのワークフローを定義させることになり、チームの規模が大きくなるにつれユーザー定義のワークフローは混沌を生み出すことになる。
ただ仕事を急ぐのではなく、モメンタムを作り出そう
我々はケーデンスとルーチンを仕事のなかに見つけるべきである。サイクルの中において、我々は優先度を決断し、責任者を割り振る。我々のゴールは、我々のチームに健全なモメンタムを維持することであって、仕事を終わらせるために急ぐことではない。
意味の大きいディレクションをしよう
我々の日々の業務はタスクに満ちているだろうが、我々の仕事の目的や長期間のゴールを理解し、それらをチームに忘れさせてはならない。1週間のスケジュールを立てる際にも、ロードマップやプロジェクトやマイルストーンを念頭に置くことが重要である。
明瞭さを目指そう
できるだけ新しい用語を発明するべきではない。混乱を生み、チームによって意味が変わってしまうかもしれないからだ。プロジェクトは常にプロジェクトと呼ばれるべきだ。
忙殺からの解放
我々は、ツールの単なる設計者や保守担当者に成り下がって、ユーザーに負担を強いてはいけない。我々はユーザーの忙しい仕事を捨て去れるようにするか、自動化するべきで、これによりユーザーはより重要な仕事にフォーカスできるようになる。
まずシンプルであることは強力である
異なるサイズのチームは異なるニーズがある。ツールは使い始めるのが簡単で、時間が経つにつれて強力になっていくものでなければならない。
決断し、動き続けよう
常にベストな答えなんてない。決断し、動き続けることこそが重要なことである。
プラクティス
月ごと、四半期ごと、年ごとに、あるいはそれぞれでロードマップを立てよう
野心的なゴールこそが、意味の大きいインパクトを生み出す唯一の方法である。会社は、高次の戦略決定をする際に、その目標にフォーカスすべきである。ロードマップの中に、常に出てくる予期しない仕事や状況に合わせた対応のための余白を取っておくことで、ロードマップは必要であれば変えることができるようになる。
日々の仕事とプロジェクトの大きなゴールをつなげよう
全てのプロジェクトと仕事は、そのゴールに直接関連づいているべきである。ロードマップのミーティングの際に、プロジェクトとその目標日をレビューし、サイクルを計画する際にプロジェクトから情報を引き出す。
N週間のサイクルで仕事をしよう
サイクルは健全なルーチンを作り出し、チームが次に起こることに対して必要なことにフォーカスできるようになる。2週間のサイクルがソフトウェア開発においては最も一般的である。他の優先事項を見失わないようにするには十分短いが、重要な機能を構築するには十分長い。サイクルは合理的と感じられるものでなければならない。多すぎるタスクを積んではいけないし、終わらなかったタスクは自動的に次のサイクルに移す。
バックログが管理可能な状態を維持しよう
全ての機能実装要望やフィードバックを保存しておく必要はない。重要なものは再浮上するだろうし、優先度の低いものは永遠に内容が固まらないだろう。きちんとフォーカスを絞ったバックログがあれば、各サイクルの計画が簡単に素早く立てられるようになるし、実際に仕事が完了することを確実にしてくれるだろう。
機能実装と品質向上を同時に管理しよう
全てのソフトウェアにはバグがあるし、その全てを直すことは不可能だ。サイクルの中にバグやその他の修正を含むべきだ。開発で使う道具に投資することを正しく行えば、チームの戦力増強になる。
プロジェクトとイシューのオーナーを定めよう
各プロジェクトには、その提供とプロジェクトの信条に責任を持つオーナーが指名されるべきである。イシューのゴールについても同様である。オーナー以外の人々は、一人の人間の責任の元にコラボレーションするべきである。
プロジェクトの仕様を書こう
簡潔さであろうとしよう。短い仕様の方がより読まれやすい。仕様の目的は、プロジェクトの "why", "what", "how" をチームの他のメンバーに簡潔に伝えることである。理想的としては、短い仕様ドキュメントによってチームはやらないことを決めることができるし、優先度が明確になり、間違ったものを作ってしまうことを避けられる。
ユーザーを理解しよう
プロダクトが普及すればするほど、より多くのフィードバックが得られる。それらがバグの報告でなければ、ユーザーからのフィードバックが溢れ返ることは良い兆候である。新たな機能を開発する際に、フィードバックを集め、図書館のようにそれを活用すべきである。フィードバックの傾向にも焦点を向けよう。たとえそれが不満であってもユーザーのフィードバックをユーザーのことを知る機会として活用し、ユーザーになぜその機能を欲しているか説明してもらうことができれば、（機能そのものではなく）彼らの本当の要望を見つけ出すことができる。単に機能を実装するだけではなく、それによってユーザーの問題を解決しよう。
イシューのスコープはできるだけ小さくする
巨大なタスク群を進めている場合、進捗を見える化することは困難であるし、それはモチベーションの低下を招く。仕事を小さく分解し，できるだけそれぞれを一つのイシューとして立てる。理想的には、毎週具体的ないくつかのタスクを完了させられるだろうし、完了したイシューに印をつけるのはとても気分がいいはずだ。
実際の仕事によって進捗を測ろう
何かが完了しているかどうかを知る最も明確な方法は、コードやデザインの差分を見ることである。タスクを小さいスコープにしておけば、差分は小さくなりレビューもしやすくなる。巨大なプルリクエストや、急激なデザインの変更は避けるべきである。
クロスファンクショナルなチームを運営しよう
自然なコラボレーションを生むために、プロジェクトにおいてデザイナーもエンジニアも協働すべきである。デザイナーはアイデアを探り、チームの考えを前に進めるためのスキルを持っている。エンジニアは実装についての検討を進めることができるし、実際に選択されたアイデアを実現することができる。最も偉大なクリエイターはその両方を持っている人物である。他のチームのための機能を実装しているときや、顧客とコミュニケーションをとって利用を促すときに、そういった人物は機能検討や開発とユーザーからのフィードバックのループを直接的に回すことができる。
Change Logs を書こう
振り返ってチームが成し遂げたことを称賛することは重要である。一貫性のある Change Logs はそれだけではなく、ユーザーに新機能を伝え、ユーザーがプロダクトから得られる価値や、チームがその価値向上へ貢献していることをも、ユーザーに伝えることができる。それはチームの各個人の仕事と、それらがどんな価値を作り上げているかを結びつける簡単な方法の一つでもある。Change Logs をどう書いているかについては こちら も参照されたし。