速いプロジェクトのつくりかた
October 2, 2023
Last edited time
Nov 7, 2023 03:57 AM
序章: 時間というものの考え方
工数 - 手間と時間
タスク法や工数の見積もり
プロジェクトを進行する上で重要な要素となるのが、各タスクにかかる工数の見積もりだ。これは一見単純な作業に見えるかもしれないが、実際は深い洞察と経験が必要となる領域だ。間違った見積もりはプロジェクト進行に混乱を招くだけでなく、ステークホルダーとの信頼関係を崩す可能性もある。そのような事態を避けるため、以下にタスクと工数見積もりの方法について説明する。
パーキンソンの法則: 余剰は使い果たされる
見積もりを行う際に頭に入れておきたいのがパーキンソンの法則だ。「仕事は与えられたすべての時間を全うしてしまう」という法則であり、つまりどれだけ時間があっても、その時間を全うするまで仕事は終わらないという事だ。この法則を踏まえて、見積もりを行うときは適切なバッファを設け、リスク管理を行うことが重要だ。
例えば、会議で披露する企画書の締め切りまで1ヶ月も時間があったのに着手するのが大幅に遅れてしまったり、事前調査に時間をかけすぎたりなど、結局は期限ギリギリになってしまった経験はないだろうか。または、年収がアップしたら貯金しようと考えていたのについつい買い物をしてしまって貯金が増えないということもありがちである。
このように「人は時間やお金に余裕があっても、それらをすべて使い果たすように行動を拡大させてしまう」というのがパーキンソンの法則です。
つまり、バッファをもって工数を高く見積もることは一般的に、工数を肥大化する。この法則は、バッファの正しい使われ方 - つまり当初予見しなかった事象に対処するために使われる - と同時に発生しているから、切り出して観察することができない。このように、時間は現実の現象としてはひとつながりでしか表現できないから、不再現性があり、比較可能なものとならないといえるだろう。
時間的距離
プロジェクトに求められる観点
プロジェクトは普通、ビジネスとしてロードマップを実現するものである。ロードマップには、内容と時間軸が記述されている。
だから、プロジェクトにアサインされた者の責務は、以下の2つである。
- 求められていることを実現すること
- それを、ある時点で完了させること
とはいっても、プロジェクトには不確実性がどうしても存在する。むしろ、不確実性や不足があるからプロジェクトはつくられるのである。
そのために、我々は不確実性に抗うための手札を組み合わせ、ときには賭けをしながらプロジェクトをコントロールしていくことが必要である。
我々は1日24時間の元手を運用している
私たちは寝ている時も起きている時も、一定の時間を得てそれを消費している。
それは1日に24時間という時間的な制約の中で働いているということを意味する。
活動時間帯や個々の作業時間を最適化するためには、まずこの「1日24時間」を有効に活用する方法を見つける必要がある。一部の人は早朝に凝縮した作業時間を確保し、他の人は深夜まで働くことを選ぶ。その選択は、個々のライフスタイルや作業スタイル、そして仕事の目的に基づいている。
これは、24時間働けといっているわけではなく、いくつかの認識を提示する。
時間ははじまりに支給される資源であり、チームが効果的に稼働してなくても時間は同じスピードで過ぎ去っていく。時間の価値は、残り時間に応じて変化していく。
つまり、いつどれくらい時間を使うべきか、は成り行きにまかせて使い方を決めるよりマシな方法があるということである。
個々の人々が最適な作業シフトを見つけることで、チームとしてのプロダクト開発の効率が向上し、開発速度も向上する。より少ない時間でより良質なアウトプットを生み出すことで、時間的距離を短縮することができる。
1週間の経過と修正
たとえば週に一度の打ち合わせの間には、7日間という時間が経過する。この期間、個々のメンバーは各自のタスクを進行させ、進捗状況をチームに報告する。ここで、最初の計画から外れている部分や予定よりも進んでいる部分など、プロジェクトの進行における時間的なズレを早期に発見し、修正することが重要である。
週次の打ち合わせでは、各メンバーのタスク進行状況と時間の経過を確認し、課題を明確にする。そして、次の週に何を達成するべきか、どのように時間を配分するべきかを明記することで、プロジェクトの全体進行を効率的に管理することができる。
この周期的なリズムは、チームに調整メカニズムをもたらすだろう。調整により、時間的な制約をうまく管理し、プロジェクトの進行を円滑にすることが可能となる。しかし、その一方で、各メンバーの自由な時間管理と高いアウトプットを保証するバランスを維持することが求められる。これは、プロジェクト管理者の重要な役割の一つある。
タイミングの重要性とクリティカルパス
プロジェクト開発においては、共有の意識と円滑な連携が求められる。その上で特に重要な要素として位置づけられるのが「タイミング」である。タイミングは一見取捨選択できる要素ではないが、意外と盲点になりがちで、ここを意識することでちょっとした開発の効率化が図れまるだろう。
開発者がちょうど動けるタイミングで仕様の提供や調整を行うことで、スムーズに作業に移行できる。これはボトルネックの解消や無駄な待ち時間の削減につながり、プロジェクト全体のスピードを上げることができる。
このような最適な連携を実現するための手法として「クリティカルパス」という考え方がある。
この考えの前提には、作業者やタイミングの異なる複数の工程が関連しあって大きなものがつくられているという理解がある。クリティカルパスとは、プロジェクトの各タスクを開始できる最早の時間と、完成させることができる最遅の時間を計算し、全体のスケジュールに影響を与える重要な作業を特定する手法。
上記の表から見てもわかるように、作業Bと作業Dがクリティカルパスに該当します。これらが遅延するとプロジェクト全体が遅延する可能性があるため、この情報を共有し、優先度を明確にする事が大切である。
これをつかうというよりも、タイミングの最適化が重要な要素であるということである。
リカバリする
問題の発見と認知
プロダクト開発において、最初の一歩は課題の発見とその認識である。ここではプロダクトの課題ではなく、開発プロセスやチーム内のコミュニケーションなどの課題を指す。これらの課題を明確にすることで、適切な解決策を見つけ出し、プロダクトの質を向上させることが可能となる。
課題とはそもそもなにか
課題と問題は違いがある。問題は通常、明確な解決策を見つけることが可能な困難な状況を指し（なぜなら、解決容易な問題は即座に消滅するからだ）、課題はより抽象的な、または根本的な改善点や向上が必要な領域を指す。抽象的ということはつまり、視点によって設定単位が異なるわけだから、課題は観察されるものではなく設定されるものである。
例えば、コードのバグは問題であり、コードの品質やメンテナンス性の低さは課題である。
つまり、起きている現象と、それをどう認識するかはまた別である。現象は客観的に理解することができるが、それを課題とするかは非常に裁量的な問題なのである。
ボトルネックはシフトする
問題を解決すると、その先のプロセスで新たな問題が顕在化する。
たとえば、要件定義がスムーズにいかない、という問題が解消されたらおそらく次の関心はデザインがスムーズに確定しない、という問題に目が向けられるだろう。
ボトルネック転移は、ある課題が解決された結果、別の課題が明らかになる現象を指す。これはプロダクト開発においてよく見られる現象であり、常に新しい課題に対処しながらプロダクトを改善し続けることの重要性を示している。ボトルネック転移の理解は、開発チームが現在及び将来の課題を効果的に管理し、プロダクトの成功に向けて動き続けるために重要である。
このように、課題は捉え方・見え方によって変わると言える。
どうすれば速くなるだろうか
ここからが具体的にプロジェクトを速くするアプローチ
このドキュメントが提示するアプローチは以下の6つである。
- 戻らなくする
- リードタイムを短くする
- 効率を上げる
- 並列で進める
- 仕事を減らす
- プロジェクトを小さくする・なくす
1 | 戻らなくする
なぜ戻るのか
手戻りは普通、予測に含まれていないし当たり前のようにおきる。
ある程度コントロールできるはずだったのに、起きる。技術的な手戻りに対しては、開発者は身長に取り組むプロセスがあるが、プロジェクトマネジメントでは、手戻りはなるべく防ぐか、その影響を最小化するか、リスクを取っていくかということになる。
次のようなパターンがある。
- 決まったと思ったら決まっていなかった
- 決めたつもりが、その要件が満たされていなかった（考慮漏れ）
- 後から新しい要件が追加されてきた。
- 技術的にだめだった。
一方で、なんでもかんでも全て固める必要はない。多少の考慮漏れや手戻りは、結局そのインパクトが小さければ対処すればいいだけだからだ。だから、決めるということにどれほど執着するかはそのインパクトの見積もりによって勘案する。
さて、技術的な手戻り以外のパターンで、手戻りをなるべく防ぎたいときにとるアプローチを述べる。
誰がどう決めるか決める
まず、戻るパターンを抽象化すると、次のようなことである。
- What: 何を決めるか
- How: どう決めるか
- Who: 誰が意見をいい、誰がフィードバックするか
早く決めるべきことを特定する
プロジェクトにおける意思決定の中でも特に優先すべきなのは、プロジェクトの進行や成果に大きな影響を与えるものだ。例えば、技術選択、リリース日の設定、リソースの割り当てなどがそれに該当する。
これら重要な事項は初期段階で決定されるべきで、遅い決定はリスクを引き起こす可能性がある。
要求と要件、あるいは目的/must/betterなどをすべて宣言する
プロジェクト開発の初期段階では、全ての要求と要件を明瞭に定義し、それらを優先順位付けすることが重要である。ここで、強調したいのは「宣言」である。要求と要件はプロジェクトの“must”（必須）と“better”（より良い）を定義し、それらがプロジェクトの目標と要件にどのように連携するかを明示する。
文書主義で確実に仕事を進める
最後に、全ての決定と合意事項は文書化すること。文書主義を導入することで、誤解や不確定性を最小限に抑え、全ての関係者が何が決定され、なぜそれが決定されたかを理解するための共有基盤を提供する。
意味のある決め方をする
結論からはじまる問いかけは、結論 vs 結論の議論を生む。
「問題ないかご確認ください」「OK」という、全面承認をもとめるコミュニケーションにはあまり資産価値がない。問題を見落としてたら結局戻るからだし、その決定の内訳がブラックボックスになるからである。
だから、「論点Aについての方針の選択肢BCDはどれですか？どのWhyを採用しますか？」と具体的な問いを立てること。
論点Bがでても、論点Aの議論はストックできるし、Whyが選択されていれば別の論点Bがでても判断基準が採用できるわけである。
手戻るコストを最小化しておく
ここまでに述べたアプローチを突き詰めると、コミュニケーション頻度を高めるとか、じっくり検討するといったアクションになるだろう。
2 | リードタイムを短くする
リードタイムとは
リードタイム（Lead Time）とは、製品やサービスが顧客によって要求されてから、その製品やサービスが顧客に届けられるまでの時間を指す。例えば、ソフトウェア開発の文脈では、特定のフィーチャーまたはバグフィックスの要求がされてから、それが実装され、テストされ、最終的にリリースされるまでの時間をリードタイムとして考える。
リードタイムが長くなることは、後続のタスクの着手タイミングが後ろ倒しになるということである。
リードタイムの原因
リードタイムが長い場合、その根深い原因は多岐に渡る可能性がある。以下は、一般的な原因のいくつかである。
- 複雑な手続きと承認フロー: 多くのステップが組み込まれていると、全体のプロセスが遅くなる
- リソースの不足: 人員が足りなかったり、必要な機材やソフトウェアが不足していると、作業は遅れがちである
- プライオリティの不明確性: 何が最も重要なのかが明確でないと、人々は効率的に作業を進めることができない
- コミュニケーションの不足: チーム内や他の部署とのコミュニケーションが不足していると、誤解や作業の重複、必要な情報が伝わらない等、多くの問題が起きる
- 技術的負債: 過去の短期的な決定や適当な設計が、今後の開発速度を阻害する。
リードタイムの実態
ところで、リードタイムは冒頭の時間的距離そのものである。
リードタイムの実態は多くの場合、
- 作業待ち時間: メンバーAによる作業 → メンバーBによる作業時間
- コミュニケーション間隔: 情報の発生から伝達までの時間
プロジェクト内における改善可能な類型はたいてい、コミュニケーション間隔である。
なぜなら、作業はみなアサインされたらしっかり取り組むが、コミュニケーション間隔は人為的にかつ容易に伸びるからである。遅いプロジェクトと速いプロジェクトではここに差がついていることが多い。
仕様がもっと固まったら伝えようとか、来週のミーティングで展開しようとか、そういうことは人為的判断に基づくのである。これは考え方を変えればいくらでも早めることができる。
そもそも、他人がいつどの粒度でどの情報がちょうどいいかなんてものは、正確に見積もることはできない。であるなら、結局有用そうな情報は速く多くだす、というスタンスが最善である。
タスクのプライオリティを決定する
リードタイムを短くするための一つのアプローチは、タスクのプライオリティを適切に決定することだ。開発チームが何に集中すべきかをはっきりさせることで、リソースを最大限に活用し、結果的に開発時間を短縮することが可能になる。
プライオリティを設定するための基準としては以下のようなものが考えられる。
- ビジネス価値: そのタスクが実現した場合にビジネスにどれほどの価値をもたらすか。
- 利用者の価値: 実際のユーザーに対してそのタスクがどれほどの価値を提供できるか。
- リスク軽減: そのタスクを早めに実行することで、将来的なリスクをどれほど減らすことができるか。
このようにして各タスクのプライオリティを見える化することで、開発チーム全体での認識を揃え、タスクの取り組み順序が明確になる。これにより無駄な作業を減らすことができ、リードタイムを短くすることが期待できる。
また、これらのプライオリティ設定はMoscow MethodやRICEなどのフレームワークを参考にすると良いだろう。これらのフレームワークは効率的なプロダクト開発に役立つため、一読する価値はある。
早く手放す
ボールを持ち続けていても、それがクオリティ向上に直結するとは限らない。これは「オッズ・レシオの法則」に基づいている。この法則は、確率や期待値を扱う統計学からきており、ある事象の発生率の比率を表す。具体的には、必要な決定や情報の提供を遅らせることで、プロジェクトの成功確率が下がるということを示している。
つまり、次の打ち合わせまで情報を持っていると、それだけでプロジェクトの進行が遅れる可能性がある。そのため、情報はすぐに周囲に伝えるべきだ。他のメンバーも早期に情報を得ることで、より早く思考し、対応準備を整えることが可能となる。
ㅤ | 情報を早く出す | 情報を遅く出す |
プロジェクトの進行 | スムーズ | 遅れる |
クオリティ | 上がる可能性 | 上がらない |
メンバーへの影響 | 早期に対応 | 対応遅れる |
この表からも分かる通り、情報を早く出す方が、全体としてのプロジェクトの進行やメンバーへの影響が少なく、最終的なクオリティも保てる可能性が出てくる。なるべく早く手放すことで、リスクを軽減しつつ効率的にプロジェクトを運営できる。
情報を他者に出すことで他者の認識の負担が増えることを気にするべきではない。それをどう処理するかはその他者が決めればいいからである。もし、他者が必要な優先度で対応してくれない場合は急かせばよい。
タイミングがうまく噛み合うようにする
タイミングのコントロールとその具体的な対策
プロジェクトの成功に向けて重要な要素のひとつに、各作業のタイミングが上手く噛み合うということがある。これは特に、複数のメンバーが関わり、また作業内容が連鎖的に進行するプロジェクトにおいて、そのスピードや効率を大いに左右する。
なぜなら、例えば開発者が稼働可能である状態なのにデザインが未完成であるために待機状態になってしまうと、プロジェクト全体の進行が滞ってしまうからだ。こういった状況が望ましくないのは明らかで、その策略を考えることが求められる。
ここでは、それぞれの行動パターンとその手法について具体的に解説しよう。
せかす
例えば、デザイン等の前提となる業務が遅延している場合、その部分的な進捗を早めるために積極的に働きかけを行う。これは、催促の形態を含むことが多い。ただし、過度なプレッシャーは逆効果となる場合もあるため、相手を尊重しつつ、きちんと期限等を明示した形でコミュニケーションをとることが求められる。
部分的に着手可能な要素を選択する
全体のデザインが完了していなくても、その一部だけでも先に渡せる場合は、部分的に開発を進められる要素があるか確認しよう。これにより、プロジェクト全体の動きが滞ることなく、少しずつでも前進を続けることが可能となる。
着手順を組み替える
進行順序が固定されていないタスクについては、その順序を組み替えて待機時間を削減する。ただし、この方法はタスク間の依存性が少ない場合や、予め各タスクの進行予定を柔軟に組み替えられる状況下でのみ効果的となる。
タスク間の依存関係をなくす
可能ならば、プロジェクト内のタスク間に存在する依存関係を取り除く。例えば、別のチームが進行している作業と並行して、自チームの作業を進めるなどの工夫が考えられる。
上記のように、タイミングの調整は非常にダイナミックな要素であるため、逐次評価と調整を行なっていく事が求められる。これがプロジェクトマネージメントの根幹とも言える部分であることを理解し、有効な手法を選んでいこう。
言語的コストを下げる
言語的コストを下げる
言語的コストを下げるためのことについて考えてみる。バラバラな用語や表記を混在させることは、開発者に混乱や疑問を持たせ、作業の効率を阻害する。
プロジェクトメンバーは、大抵の場合正しい情報を正しく認識すれば適切に対処できるが、多くの場合に、「正しい情報を正しく認識する」プロセスに時間がかかっている。
つまり、理解のコストを各メンバーが負担している。この対処には、深く検証するタイミングがあったり、コミュニケーションのリードタイムとしてプロジェクトスピードに影響する。
ユビキタス言語を明確にする・いろいろな表記を混在させない
表記法が一定であれば、開発者が情報を迅速に理解するための時間も短縮される。ガイドラインやツールを使って統一表記法を推進すると良い。
ユビキタス言語とは、開発者間で共有される専門用語のことだ。この専門用語を明確にすることで、のみならず、コードの品質や保守性も向上する。
例えば、「顧客」を指すときは「customer」、「クライアント」を指すときは「client」という具体的なユビキタス言語も設定すると、誤解や混乱を避けることができる。
どうせ聞かれることは言語化する
開発者が聞きたいと思っていることや疑問点を予測し、それらを言語化しておくことは、不要なコミュニケーションのコストを減らすのに役立つ。
例えば、API設計書に「なぜこのフィールドはNULLを許容しないのか？」といった設計背後の理由を記載すると良い。
なるべく開発用語を用いること
開発者が理解しやすく、また、開発者が機能やバグについて考えやすくするためには、開発者が馴染みのある専門用語を用いることが重要だ。具体的なコード名や関数名を用いるなどの工夫をすると良い。
以上が、言語的コストを下げるための方策だ。
関係者を減らして意思決定やコミュニケーションコストを減らす
プロジェクトの進行速度と関係者
一見、関係者を増やせば増やすほど、多くの意見や視点が得られ、良いプロダクトが生まれやすいと思うかもしれない。しかし、実際は課題が存在する。それは意思決定のスピードが遅くなるという問題だ。当たり前だが、2人で議論する内容が3人になると自動的に速くなるか・質が高まるというとそうではない。
これは、多くの関係者がプロジェクトに関与していると、各人の意見を調整し合わせるまでの時間が長くなるためだ。この時間がプロジェクト進行全体に影響を及ぼし、結果的に開発速度を遅くしてしまう。
また、関係者が多いと、プロジェクトに関わるコミュニケーションの量も増える。これは、情報の伝達や誤解の解消に必要な時間が増え、プロジェクト進行の効率を阻害する可能性がある。
ピザチーム: 関係者の最適な数とは
では、適切な関係者の数とは何か、という問いに対する答えは一概にはない。しかし、可能な限り「必要最小限の人数」を心がけるべきだ。これは、アジャイル開発の原則でもあり、ビジネスの世界でも広く受け入れられている。
一般的に推奨される人数は「ピザチーム」で、これは一枚のピザでメンバー全員を満たせる人数、つまり5～7人程度とされている。必要な人数を見極めることで、コミュニケーションコストを最小限に抑えつつ、高速な意思決定を促進することが可能になる。
私たちは、プロジェクト関係者の最適なバランスを見つけ、開発スピードを加速させるための策を見つけることに焦点を当てるべきだ。
3 | 効率を上げる
メンバーのタスクにかかる時間を短くする
マルチタスクは出荷期間を遅延させる
シングルタスク化は、ひとつのタスクに集中し、それが完了するまで他の作業を行わないということだ。この方法は複数のタスクを頭の中で切り替える時間を削減し、全体の作業効率を向上させる。
例えば、あるデザイナーがデザインタスクとコーディングタスクを同時に進行させているとする。2つのタスクを頭の中で切り替える際に使う時間（コンテキストスイッチング）がそれぞれのタスクの完了までの時間を長くしてしまう。更に、それぞれのタスクが必要とするスキルや知識が異なるため、頭の中を切り替えるのも時間とエネルギーを必要とする。
シングルタスク化によって、同じ時間でも一つのタスクに集中する時間が長くなり、質の高いアウトプットが期待できる。そのため、タスクごとの時間を短くするためには、一つのタスクに全力を注ぐこと、つまりシングルタスク化が有効だといえる。
ただし、マルチタスクは必然的に発生する
マルチタスクは生産性をさげるといっても、クリティカルパスを実現するような動き（つまり、複数のメンバーが異なるタイミングで仕事を仕上げ、その連続を複数メンバーで実現している状態での最適パス）をするということは、自動的にマルチタスクの環境が発生するだろう。
マルチタスクにはもう一つ根深い問題がある。
それは、複数の性質のタスクを優先度付けする作業がプロジェクトマネージャーではなく作業者になりがちであることである。この状況は複数部門にまたがって仕事が発生して同一の作業者が対処しているときである。そして、複数部門をまたいだときには、往々にしてクロスオーバーした優先度付がおろそかになるだろう。
そうすると、いつの間にか全体最適としてイマイチな優先度付で作業がおこなわれるという悲劇が起きる。
タスクのサイズと効率に関する原則
効率的フロンティアとは
効率的フロンティアとは、一般に、特定のリソースを最大限に効率よく利用するための理想的な組み合わせを示す理論的な概念である。これは、例えば投資ポートフォリオのリスクとリターンの組み合わせなど、リスクと効率といった相反する目標を達成するための理想的なバランスを見つけるのに使用される。
要は、タスクのサイズとリスク管理は関連していて、最適点が存在するということ。
プロダクト開発の効率的フロンティア
プロダクト開発も投資と同じく、効率とリスクのトレードオフの最適解を探す必要がある。ここでいう効率とは、生産性や開発速度などの発展要素を指す。一方、リスクは開発失敗の可能性や予想外のトラブルなどの負の要素を意味する。
おおまかに言えば、小さなタスクは高リスクではあるが、その分回収期間は短い。ただし、コミュニケーションコストの投資効率は低いと言える。
一方、大きなタスクは効率的だが、その分リスクは大きくなる。
タスクサイズ | リスク | 効率 |
大 | 高 | 高 |
中 | 中 | 中 |
小 | 低 | 低 |
この最適解を見つけることで、プロジェクト全体の効率を最適化し、リスクを最小限に抑えることが可能になる。
プロセスを型化する
プロセス型化の重要性とその理由
プロダクト開発におけるプロセス型化の重要性は、その効率化やスムーズな実行を可能にする点にある。プロセスを型化することはつまり、プロジェクトの具体的な進行手順を明確にし、類似の業務を再現可能な形とすることだ。これは以下のようなメリットを生み出す。
一つ目は、「何をどう行うべきか」を各々が都度判断したり、コミュニケーションを取ったりする手間を減らすことができる。操作手順や業務フローが明確で統一されていれば、それぞれのメンバーが個々に解釈や判断をする必要がなく、一貫性を保ちつつ迅速に業務を進めることができる。
二つ目は、「予定通りに進行すること」への信頼感を高めることができる。明確な手順やルールが存在することにより、メンバー間での信頼関係が強化される可能性がある。業務遂行が予定通りに進むくやり取りが減ることで、より集中して各自の業務に打ち込むことが可能となり、全体の生産性を向上させる。
プロセスの型化は、特に同じような停滞や問題が2回以上繰り返された場合には重要だ。これにより問題の再発を防止し、業務のスムーズな進行を維持できる。
そのためには、まず具体的なプロセスを洗い出し、その中で発生する問題点を見つけ出すことが大切だ。そしてその問題点を解消するための新たなプロセスを設計し、それをチーム全体で共有する。これにより、チーム全体が一貫したルールのもとで働くことができ、結果的にプロジェクト全体の品質と効率を改善することが出来るというわけだ。
しかし、全てを型化すれば良い、というわけではない。型化には手間と時間がかかり、型には柔軟性が欠けるというデメリットもある。そのため、重要なのは型化の対象を適切に選び、型化の利点とデメリットを天秤にかけて判断することだ。必要なところには型を適用し、柔軟に対応するべき箇所は型化せずに自由度を保つ、というバランスが求められる。
議論する事項を減らす
議論を絞り込むためのポイント
プロジェクトを効率良く進めるためには、ステーキホルダー全員が適宜に議論できるようにすることが重要だ。議論するべき事項と、後で良い事項を分けることで、無駄な議論を減らし、必要な議論だけに集中できる。
プロジェクトを進める上で重要な3つのポイントを以下に示す。
- プロジェクト計画の段階で重要な事項をクリアにする
最初に全体の目標と戦略を設定し、明確にすることが最も重要だ。プロダクトの目標、計画、スケジュールそしてリソースは、議論の根底をなす要素だ。これらを明らかにすることで、何に焦点を置くべきか、何が後回しになっていいのかが明確になる。
項目 | 説明 |
プロダクトの目標 | プロダクトが解決すべき問題は何か、達成すべきゴールは何かを定義する |
計画 | 具体的な実行計画。目標達成のための道筋を立てる |
スケジュール | プロジェクトの期限や、各タスクの期限を決める |
リソース | 利用可能な人員や予算を明確にする |
- ステーキホルダー間の意思疎通と調整
プロジェクトステーキホルダー全員が同じ情報を共有し、理解し合えるようにすることも重要だ。プロジェクトステーキホルダー間で意見や理解が食い違っていないか確認し、調整することが必要だ。
- 議論の優先順位付け
すべての議論が同じ重みを持つわけではない。プロジェクトの進行に大きな影響を与える議論と、それ以外の議論を区別することが重要だ。重要な議論に時間とリソースをしっかりと割くべきだ。
これらを踏まえた上で、議論の段階では最も重要な要素から取り組み、「絶対に確定すべき事項」、「すぐには決定しなくても良い事項」といったカテゴリに事項を分けていく。これにより、必要な議論を行いつつ余計な議論を控えることができる。
効果的な発散と収束プロセス
企画をたててとおすのに難儀しているのであれば、あらゆるアイデアが発散と収束というプロセスを経ることを認識するとよい。そして、発散・収束どちらもメリハリをつけるべきである不確実なプロジェクトを効果的に推進することができるだろう。
アイデアの発散
プロダクト開発ではまず、広範で多岐にわたるアイデアを生み出す発散フェーズが重要だ。ここでは、なるべく制限をつけずに自由にアイデアを出すことが求められる。具体的な手法としてはブレインストーミングやマインドマップの作成があげられる。
ブレインストーミングでは、参加者全員から自由にアイデアを募る。このとき、「NOを言わない」「量を重視する」「遠慮しない」「アイデアは組み合わせる」の4つのルールがある。
マインドマップでは、1つの中心テーマから関連するアイデアを枝分かれさせていく。これによりテーマに対する深い洞察や意外な連想を引き出すことができる。
基準の設定と収束
発散で広げた視野をもとに、収束フェーズでは偏りなく厳選することが重要だ。毎回の議論が新しいアイデアを出すだけで終わる場合、プロジェクトは進行しない。
収束には適切な基準を設定することが必要だ。基準とは、アイデアを評価・選択するための明確な目安やルールのことを指す。例えばプロダクト開発の場合、基準には「ユーザーニーズ」や「開発コスト」、「時間」などが含まれることが多い。
収束プロセスで注意すべきは早とちりしないこと。十分な時間をかけてアイデアを検討し、複数の視点から評価することで、より適切なアイデアを選択することができる。たとえばPMは積極的にステークホルダーの意見を取り入れて多角的に評価すべきだ。
効果的な発散と収束プロセスを行うことで、幅広い視野から最適なアイデアを導き出し、プロダクト開発を円滑に進めることができる。
必要な合意をつみあげる
無限の可能性を棄却しつづけるプロセス
前述したように、アイデアは発散と収束のサイクルを経て特定される。このプロセスを組織内でどう進めるかが問題だ。
PMは要件を整理し、デザイナーはデザインを作成し、開発者は仕様を設計する。この具体化のフェーズには、目的の合理性の確認、整合性の確保、未知情報の調査など、多層的なプロセスが含まれる。そして、組織全体での認識を固めるために、その説明と合意形成が必要だ。
このプロセスは非常に個別性が高く、自由度も高い。物事を決定する過程は、無数の可能性を何らかの基準で絞り込む作業と言える。これは、不確実性を排除するか、強固な論理で積極的に選択するかのどちらかだ。
基本的には、消去法的なアプローチが多い。何かを積極的に選ぶと、その選択に説明責任を持つ必要があるからだ。
例えば、麺類を選ぶ場合、ラーメンを即決できるならいいが、それ以外の選択肢についても理由を明確にしなければならない。組織では、ただ「ラーメンがいい」と言うだけではなく、その選択が他の選択よりも優れている理由を示さなければならない。
考えるときのプロセス
何かを設計するときに、以下を明確にするとよいだろう。
- ベター要件は何か？
- マスト要件は何か？
- グレーゾーン（最終的にどうなるかわからないこと）は何か？
これらは、作業するときの指針になるようで、作業着手時にはそもそも不確定要素であることが多い。デザインが手戻りするということは上記のどれかの認識が違ったということである。やっかいなのが、人は具体案をみるまでこれを検証することができないことである。たとえば、上記全てを机上の議論で詰めるということはなかなか
合意する対象は結果ではなく理由である
しばしば、起案者や設計者は最終的なゴールが仕様やデザインである以上、やはり結果に合意をとっていくことに関心が向く。そうすると何かをまとめた後に、「XXXXでよろしいでしょうか？」型のコミュニケーションになっていく。
それが通る蓋然性が高いのであればそれで構わないが、さまざまな可能性がある場面ではリスキーなコミュニケーションになる。
そもそも、その案件について最も質の高い判断ができるのは、「一義的には」時間と情報をかけて詰めた担当者である。決裁者の機能は俯瞰的な観点を提示したり、抽象的な方針を示すことである。
具体的なUIこうするに合意をとるのではなく、その背後の論理や、抽象的な方針について合意をとっていく。そして、具体的なUIや仕様はその順当な帰結として存在する。
4 | 並列ですすめる
ファストトラッキング: 各メンバーが並行してすすられるようにする
従来のプロジェクト開発においては、ひとつのフェーズが完了するまで待って、次のフェーズに進むという逐次的な進行方法が主流だった。しかし、この方法は各メンバーの待ち時間が長くなり、非効率的である可能性が高い。
そこで、各メンバーが並行して作業を進められる「並行進行」（ファストトラッキング）を提唱する。これは「決まったところから」それぞれのメンバーが自分のタスクに着手する方法である。
たとえば、PMが仕様を決めている間にも、デザイナーやエンジニアが自分たちのタスクに取り掛かることができる。そのため、全体の開発速度が上がる。
しかし、並行進行を成功させるためには以下の点に注意が必要だ。
- 重要な項目を先に決める: すべてを明確にする必要はないが、基本的な方向性や最重要項目は初期段階で決めておくと良い。後から大きく方針を変更すると、既に取り組んでいるタスクへの影響が大きい。
- あいまいな仕様を許容する: すべての仕様を完全に定めてから作業を開始すると、作業の開始が遅れてしまう。ある程度のあいまいさを許容し、作業の進行とともに仕様を詰めていくことで、スピードを保つことができる。
- ヌケモレを早期に検知する: 各メンバーが並行して作業を進めると、全体としてのズレやミス（ヌケモレ）が起こりやすい。早期にこれらを見つけ出すために、定期的に連絡・確認を行うことが重要。
これらに注意を払いつつ、並行進行を活用することで、プロジェクトの遂行スピードを上げることが可能である。ただし、開発者の数を増やすだけではなく、質の高い開発を行うためのスキルアップも同時に行うことが重要だと言える（これをクラッシングという）。
また、並行進行を実現するには、初期の段階でプロジェクトのスコープをしっかりと決定し、チーム全体で共有することが求められる。このとき、プロジェクトの目標やKPI、期限など、具体的な目標を設定するとチーム全体の動きがスムーズになる。
リスクある状態で先行してある程度済ませておく
リスク分析の重要性
開発始まる前に、可能なリスク要素を洗い出す事は重要だ。それが、プロジェクト先行を有効に使うための一つの手段だ。まだ、決まってなくても先に動き始める事で、リスク要素を洗い出しやすくもなる。このリスク要素の洗い出しは、リスク分析と呼ばれ、プロジェクトの成功を向上させる効力がある。
リスク分析を行うことで、プロジェクトで起こりうる問題を事前に特定し、それらに対処するための対策を立てることが可能だ。この結果、開発工数が無駄になる可能性を減らし、プロジェクトの進行をスムーズにすることができる。
リスク分析を行う際の一般的な手順は以下の通り：
- プロジェクトで起こりうるリスクをリストアップ
- リスクの発生確率と影響度を評価
- リスクに対する対策を考える
- 対策の実施とリスクの再評価を定期的に行う
例えば：
リスク要素 | 発生確率 | 影響度 | 対策 |
成果物の品質が目標を満たさない | 高 | 高 | 品質管理の強化、開発手法の見直しなど |
スケジュール遅延 | 中 | 高 | タスクの進行状況を逐次監視、余裕を持ったスケジューリングなど |
人員不足 | 低 | 高 | リソースプランニングの最適化、外注の導入など |
開発におけるリスク要素はたくさんあり、それぞれに対する対策も様々だ。しかし、早期にそれらを洗い出し、それに対する対策を立てることがプロジェクトの成功を助ける。また、リスク分析は一度で終わりではなく、プロジェクトの進行状況を見ながら更新続けることが重要だ。
知見のある人物が対処する - 最適配置
プロジェクトの進行に当たっては、速度と品質の両面を見定めた上で、最適な人員配置を考える必要がある。チーム内で特定の知識や経験が豊富なメンバーがいる場合、その人物が対処することで進行速度と成果品の品質の両面で上手く行くことが期待できる。
ただし、この観点から考えると自分の仕事を1人でやりきるという考え方はあまり推奨できない。これは、他のメンバーとの連携や知識の共有を阻害し、場合によっては全体の進行を遅くさせる恐れがあるからだ。一人のメンバーが一部分だけを担当し、その領域の知見を深めることで、全体の作業効率を上げるというアプローチが求められる。
もちろん、経験者に一任することで属人化するリスクも存在する。そのため、毎回同じメンバーに同じ仕事を任せるのではなく、適宜メンバーの役割を回すなどして新たな視点やアイデアを導入することも大切だ。
また、知見がない場面での対応については、疑問を持った時点で経験者に助けを求めることが重要だ。これが怠慢となり、作業の遅延や誤解を招く結果となる事案が存在する。知見のある人物からの直接的なアドバイスや助言は、スキルアップの機会であり、仕事の質を高めるために利用すべきリソースである。
状況が不透明のとき
プロジェクトの実行のなかで、しばしば開発者が実際に調査してみなければならない時がある。
たとえば、他社のAPIがある要件を満たしているかなどである。
れは実際にグレーゾーンで、プロジェクトの成否に影響する。
「不確実な点があって、プロジェクトが遅くなってしまった」は調査の工数以外は段取りの問題である。
調査への問いを明確にすること
調査は何のためにするかというと、意思決定を確定したり、仮説を棄却するためにおこなうのであって、完璧に把握するために行うわけでは無い。であるから、調査タスクには明確に結論を導くための目的設計が前提必要である。
意思決定を確定するためには、何を知ることができればよいか、何ならリスクをとれるかを明確にすること。
シナリオをたてて準備しておく
しばしばあるのは、調査結果がでてから考えるというパターンである。
これでは遅い。
調査する前あるいはその間に、調査の結果のシナリオに応じてどうするか予め全パターン仕込んでおくことである。仕様やデザインが複数に分岐するならばぜんぶつくっておけばよい。調査結果がでたら自動的に次のステップに進むことができる。調査するということは、その事情はやはりクリティカルな事柄であるわけだから、そのぐらいは先にやっておくべきである。
早く着手する
不確実性や重要性が高いほど、なるべく早く着手する。
究極的にはプロジェクト開始前に処理することが望ましい。アイデアが浮かんでから着手してもする人がいるが、そうであればアイデアを出すのが遅い。
とにかく情報を手に入れる
社外の詳しい人にヒアリングするというオプションになる。
メンバーが自律的に対処する領域とPMがもつべき領域
PMが持つべき領域
プロジェクトマネージャーが持つべき領域とは、プロジェクト全体のビジョンと戦略を理解し、それを実現するための全体の進行を管理・推進するところである。プロジェクトの全体像を理解しているからこそ、メンバーが自律的に行動するためのフレームワークを提供し、各メンバーの役割を最大限に活かすためのサポートを提供できる。
プロジェクトマネージャーが担当すべき領域は具体的には次のようなものがある。
- ビジョン・戦略の明示: チームメンバー全員がプロジェクトのゴールを理解し、それぞれがどのように貢献すれば良いのか把握するためには、プロジェクトのビジョンと戦略を明示することが重要となる。
- 進捗管理と調整: プロジェクト全体の進捗を見える化し、各メンバーのタスクと期限を整合性を持って管理する。また、依存関係のあるタスクの補助や調整役も果たす。
- リソース管理: プロジェクトに必要な人的、物的、時間的リソースを適切に配分し、管理する。これには、必要なスキルを持ったメンバーの選定や教育、必要な資材・ツールの準備、スケジューリングなどが含まれる。
- リスク管理: プロジェクト内外のリスク要因を識別し、それらの対策を計画し、必要に応じて対策を実行する。
- コミュニケーション: チーム内外とのコミュニケーションを円滑に行い、情報の非対称性を減らし、誤解なくプロジェクトを進めるための橋渡し役となる。
メンバーが自律的に対処すべき領域
一方、メンバーが自律的に対処すべき領域とは、各自が担当するタスクに関連する具体的な作業や技術的な課題、コミュニケーションなど、自身のスキルと経験を活かして自主的に対処する分野である。メンバーが自律的に対処すべき領域の具体例としては以下があげられる。
- タスクの遂行: 自身が担当するタスクを計画し、実行する。また、達成のために必要なリソースを自分で調達する。
- 問題解決: 自身が担当するタスクに関する問題や課題が発生した際には、情報を収集・分析し、適切な解決策を自身で考え、実行する。
- 学習とスキルアップ: 自身が担当する業務に必要なスキルや知識を自己啓発する。新しい技術の習得や新たな知識の取得、既存スキルの深化などが含まれる。
- コミュニケーション: 自身の責任範囲内で必要なコミュニケーションを自主的に行い、情報の非対称性を減らす。具体的には、自身のタスクの進捗状況を報告したり、他のメンバーと連携を取るなどが含まれる。
このように、プロジェクトマネージャーとチームメンバーがそれぞれの領域で自律的に動くことでチームとしての生産性を最大化し、プロジェクトの成功に繋がるわけである。
速度を高めるための行動・規範を醸成する
スプリントとリスクへの対応
デジタルプロダクトの開発チームでは、「スプリント」という単位で作業を進めることが多い。スプリントは一定の期間を設け、その期間内でどの程度のタスクを完遂するかを固定する手法だ。スプリント期間中のタスクは、可能な限り変更せずに推進することで生産性を保つ。
リスクについても同様に、チーム全体で共有する必要がある。リスクとは、開発中に予想外の事態が起きたときの対応方法や、その可能性が現実になったときの影響度を指す。リスクを明確に言語化し、早期に対策を立てておくことで、突然の問題が発生したときも慌てずに対処することができる。
項目 | 内容 |
スプリント | 一定期間(例:2週間)でタスクを固定し、作業を進める。 |
リスク管理 | 予想外の事態への対応策を立て、早期対応を図る。 |
上記のように、チーム全体で行動・規範を醸成させることで一貫した開発を行い、開発速度を一層高めることができる。各メンバが自身の仕事を進める際の基準となるため、スプリントの進行や、リスクへの対応についてはチーム全体で良く話し合い、共有しておくことが重要になる。
5 | 仕事を減らす
タスクの整理
プロジェクト管理において、最も重要なことの一つがタスクの整理だ。これが適切になされないと、必要以上の仕事が生じ、時間やリソースの無駄となる可能性が高い。また、何を優先すべきか明確でなければ、チーム全体の生産性が下がる。したがって、タスクの整理は極めて重要である。
アイゼンハワーのマトリクス
タスクの整理方法の一つとして有名なのは、アイゼンハワー大統領が提唱した「アイゼンハワーのマトリクス」だ。これはタスクを「重要度」と「緊急度」の二つの軸で分類する方法で、以下の4つのカテゴリーに分ける。
ㅤ | 緊急 | 非緊急 |
重要 | 直ちに行う | スケジュールを立てて行う |
非重要 | 他人に委ねる | できるだけやらない |
仕事量の減少
上記のマトリクスでは、「できるだけやらない」とされている仕事もある。これは、仕事を減らすための重要な手段である。無駄な仕事、すなわち重要でもないし緊急でもない仕事は、やらないことによって時間を節約できる。これを積極的に行うことで、必要な仕事に専念し、結果的に生産性を上げることができる。
類似の事例を真似る
類似事例リサーチの方法
新製品を作成するとき、デジタルプロダクトのPMにとって類似の事例を調べ、それを参考にすることは非常に重要だ。これにより時間とリソースを節約し、プロジェクトの進行をスピードアップすることができる。
まずは、製品やサービスが解決しようとする具体的な課題を洗い出すところから始めよう。その課題を解決している他の製品やサービスを見つけられれば、そこから学びを得ることができる。学びを得るための一つの手法がベンチマーキングだ。これは、他の製品やサービスがどのように成功を収めているのか、その手法と戦略を調査し理解する作業だ。
次に、リサーチの対象となる製品やサービスのリストを作る。ここでリストアップする項目は、性質、特徴、ユーザーの声、利点、欠点、競合他社との比較など多岐に渡る。ここでの目的は、製品やサービスが顧客にどのような価値を提供しているのかを探求することだ。
次に、リストから最も有用と考えられる情報を見つけ、それを自社の製品開発に適応させる。これには、具体的な改善策の提案、新たな機能の追加、または既存の機能の改良などが含まれる。
以上の過程を通じて、類似の事例を真似ることで、思考や設計の時間を短縮し、プロジェクトを迅速に進行させることができる。
既存資産を使い回す
既存資産を使い回すことは、開発スピードを上げるために重要な方法だ。この手法は、すでに開発済みのコンポーネント、ライブラリ、またはサービスを再利用することで、新しいプロダクト開発に役立つ。
例えば、以前に開発したユーザー認証システムは新しいシステムに再利用可能であれば、開発者は認証機能を一から作る手間を省くことができる。これは開発スピードを上げ、コストを削減し、新しいプロダクトに集中することができる。
既存資産を再利用することにより、既存コードの品質を保つ機会もある。そのため、コードの見直しとリファクタリングは既存資産を再利用する上では重要な作業だ。
ただし、一部のケースでは既存資産をそのまま利用するのではなく、一部を改良して再利用することもある。 全く新しい設定で既存の製品を再利用する場合、古いコードを取り除いて新しいコードを追加することが求められるかもしれない。
すべての資産が全てのプロジェクトに適しているわけではないため、既存の資産を再利用する際には慎重な検討が必要だ。このためには、開始前に十分な調査と予測が必要だろう。
また、再利用可能な資産をつくること自体が価値あるゴールだ。それが今回のプロジェクトのメイン目標を十分に達成しない場合でも、その資産は他のプロジェクトで活用される可能性があるためだ。
これら全てを考慮に入れると、既存資産の再利用性について考えることはプロジェクトの成功を左右する重要な要素の一つだと言えるだろう。
SaaSや既存ライブラリで済ます
SaaSや既存ライブラリの活用
チームが開発するプロダクトの機能の一部が、既存のSoftware as a Service（SaaS）やライブラリで提供されている場合、それらを活用することによって高品質のサービスを迅速に提供することが可能になる。
メリット
- 時間とリソースを節約: 開発者がゼロからコードを書くことなく、必要とする機能を直接取り入れることができる。これは、プロダクト開発のサイクルを大幅に短縮し、他の重要な機能にフォーカスする時間を増やす結果となる。
- 品質と安定性: SaaSや既存のライブラリは一般的に長期間にわたり実戦でテストされているため、自社開発のものよりも品質と安定性が高いと言える。
- アップデートとパッチ: 適用したライブラリやSaaSは定期的にアップデートされ、新機能の追加やセキュリティパッチが提供される。これにより、自社でのメンテナンスコストを下げることができる。
デメリット
しかし、このアプローチにはいくつかの注意点もある。 1. 隠されたコスト: 初期費用は比較的少ないかもしれないが、長期的なライセンス費用や維持費がかかる可能性がある。
- 依存性: 外部のSaaSやライブラリの開発と維持が停止した場合、自分たちのプロダクトに影響を及ぼす可能性がある。
以上を考慮に入れ、必要に応じて自社開発と既存のSaaSやライブラリを組み合わせることで、プロダクト開発は最適化され、結果として市場への早期浸透を実現できる。
フレームワークで考える
プロダクト開発のフレームワーク
プロダクト開発においては、多くの課題が存在する。なぜなら、クリエイティヴなプロセスだからだ。プロジェクトの進行は複雑で、速さや効率性を確保するためには戦略的な枠組み、つまりフレームワークが必要である。
フレームワークには、開発プロセスをより効果的に管理するための方法論やツールが含まれている。その中には、要件定義、設計、実装、テストといった一般的なステップだけでなく、スクラムやアジャイルといった特定の開発手法もある。
以下に一つの例を示す。
「リーンスタートアップ」は、スタートアップ企業の成功を目指すためのフレームワークである。エリック・リースによって提唱され、急速に試作可能な最小の製品を作り、顧客の反応を見て学び、仮説を検証しながら製品を改善していくというアプローチを推奨している。
フレームワークを理解し、適切に適用することで、プロダクト開発の課題を整理し、速さと効率性を確保することが可能なのだ。フレームワークは、直感的なものから理論的なものまで、プロダクトのライフサイクル全体をカバーするものだからだ。
6 | プロジェクトを小さくする・なくす
プロダクトを小さくする：最小実行可能領域
最初に意識しなければいけない考え方として、プロダクトを小さくする方法が挙げられる。これは、プロダクトの全体像を見ずに、具体的で各々の能力を最大限に活用できる「最小実行可能領域」を考えるアプローチである。
たとえば、大規模なソフトウェアを開発する場合、一から作り上げるのは莫大な時間と労力を要する。しかし、最小実行可能領域を優先して開発し、それを後から拡張していくことで、早く結果を出しながら次のステップへ進むことが可能だ。
これには、プロジェクトの目的や要件を最小限に絞り込むスキルが必要だ。そのため、開発初期には情報収集や意見交換などを通じて具体的な要件を明確化し、各メンバーの能力を最大限に活用できるタスクの切り分けを行う。この結果、各メンバーは自分の役割と責任を明確に理解することができ、効果的にタスクを進行させることが可能となる。
なお、最小実行可能領域とは、「その領域以上には拡張できない」という意味ではなく、プロジェクト全体が一度に把握できる最小単位を意味する。これにより、プロジェクト進行の見通しを立てやすくし、また何が求められているのかを明確化する。したがって、開発が進むにつれて最小実行可能領域は大きくなり、プロジェクトの規模が拡大する。このように動的に変化するプロジェクトのなかで、最小実行可能領域を常に見直し、適切な形でプロジェクトを進行させることが求められる。
プロジェクトをなくす：クロスファンクショナルチーム
一方、プロジェクトをなくすアイデアも存在する。これは、各チームが独立して動くのではなく、複数の機能や専門性を持つメンバーが集まった「クロスファンクショナルチーム」を作り、全員が一つの目標に向かって動くという考え方だ。
このケースでは、チームが目標を達成するために共有するプロジェクトが存在しなくても、それぞれが自分の役割を理解し、自律的に行動することで目標達成を目指す。このような状況では、各メンバーは自分のスキルを発揮しながら、他のメンバーと協力してタスクを遂行する。
クロスファンクショナルチームを構成する際には、各メンバーの専門性や経験、役割を的確に把握し、それらをバランス良く配置することが求められる。また、チーム全体の視点で見たときに、プロジェクトを進行させていく力量が必要となる。
このようにプロジェクトを小さくする・なくすという視点は、大規模なプロジェクトをより効率的に、かつ効果的に進行させていくための一つの方法論である。中心となるのは、「最適な規模感」を見つけ、全体として連携を取りながら目標達成を図るという思考である。
時間がかかりそうだったら見切る
プロジェクト初期段階の判断力が重要
開発の初期段階では、まだ自分たちが開発しようとしているプロダクトの可能性や規模を十分に理解していない場合が多い。この段階での判断が困難な状況でも、早めに見切りをつけることの重要性を理解しておくべきだ。
“時間がかかりそう”との判断基準
“時間がかかりそうなプロジェクト”とは具体的にどのようなものなのか、その基準を明確にすることが第一歩となる。例えば、以下のような状況が該当する可能性がある。
- 技術的に難易度が高く、スキルが足りない
- 開発リソースが限られており、他に重要なプロジェクトがある
- ゴールや要件が曖昧で、進行方向が定まらない
- マーケットフィットが見つからない
これらの状況がある場合、ポジティブな結果を得るには長期間かかる可能性がある。これらを早期に見抜き、計画の修正や移行を選択することで、貴重な時間とリソースを適切に活用することができる。
プロジェクトの評価指標の設定
そもそも、“時間がかかる”とどの程度を指すのか明確な基準がなければ、いつまで経っても見切りをつけられない。そのためには、プロジェクトごとのKPI（Key Performance Indicator）を明確に設定しなければならない。これにより、様々なプロジェクトを客観的に評価し、必要な場合に早期に見切ることが可能となる。
例えば、開発速度、品質、予算、ユーザ評価など、プロジェクトの状況を示す様々な指標が考えられる。以下に各指標の一例を示す。
指標 | 評価基準 |
開発速度 | 進行度、遅延度合い、完了予想日 |
品質 | バグの数、ユーザの満足度 |
予算 | 予算消費率、コスト削減の可否 |
ユーザ評価 | アクティブユーザ数、レビュー数と内容 |
以上のように、具体的な評価指標と基準を設けることで、プロジェクトの進行状況を明確に把握し、早期に見切りをつける判断を下すことが可能となる。
最後に
あくまでこれらの「見切りをつける」という判断は、プロジェクトの成功に向けて必要な一環だと考えるべきだ。新しいプロジェクトに挑戦する勇気は重要だが、それと同時に開発のリスクを適切に管理し、時には見切りをつける冷静さも必要となる。その結果、組織全体の開発効率が向上し、より多くの成功を追求できるようになるだろう。
期待値を下げてプロジェクトサイズを小さくする
プロジェクトのスコープを小さくする
プロジェクトの期待値を下げることは、その成功への道のりを容易にするための重要な手段である。これは特にデジタルプロダクトに関して当てはまる。プロジェクトの期待値が高すぎると、予定を達成するのに長時間を要し、結果として多大なコストがかかる可能性がある。それを避けるためにも、最初からプロジェクトのサイズを小さく、短期間で達成できるタスクに絞ることがよい。これにより、早期のリリースとフィードバックの収集が可能となり、プロジェクト全体をスムーズに進行させることができる。
その一つの手段として、最小限の実行可能なプロダクト(MVP)の開発が挙げられる。MVPは、プロジェクトの基本的な目的を達成するために最低限必要な機能だけを持つプロダクトである。これにより、無駄な労力を投げ打つことなく、早期にプロダクトを市場に投入し、ユーザーからのフィードバックを得ることができる。
メリット | デメリット |
コスト削減 | 機能が不足する可能性 |
リリース早期化 | ユーザーの要求を満たせないかも |
フィードバック収集 | ユーザー離れの危険性 |
しかし、期待値を下げることは安易にすべきではない。ユーザーニーズを満たせないなど、逆効果となる可能性もある。プロジェクトリーダーとしては、期待値の縮小がデメリットを生むリスクとどれだけバランスが取れるかを評価する必要がある。そのために、「どの機能が最低限必要か？」をリSEARCH TEAMと共に議論することから始めることをおすすめする。この透明な議論がチーム全体の理解と共有につながる。
この達成可能なスコープにより、各メンバーが自身のタスクを明確に把握でき、リスクも小さく抑えることができる。
Author
Yasuhiro Yokota
1991-, Designer
大学卒業後、行政機関で情報政策部門で勤務。株式会社ワークスアプリケーションズを経た後、フリーランスでグラフィック・デジタル双方のデザイン及びディレクションを通し、様々なプロジェクトに携わる。株式会社TERASSに創業期からシリーズBまで参画した後、2022年9月にマイベスト入社。グロービス経営大学院卒業。
Drafts
Yasuhiro Yokota Today
This website is a private and sloppy collection of writings and personal information by Yasuhiro Yokota, a designer in Tokyo.
All data is based on the Notion Database and several APIs.
Built with Chakra UI, NextJS & Vercel.