2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

システム開発計画は破綻する、という前提でのやわらかな計画づくり

Last updated at Posted at 2025-07-31

こんにちは。@koheitokumasu と申します。資源・廃棄物の収集・運搬・排出作業の効率化SaaS「WOOMS」のプロジェクトマネージャーを務めております。
本記事は、社内勉強会で共有した内容をもとに、「アジャイルな見積りと計画づくり」(Mike Cohn著)を参考にしながら整理したメモです。

WOOMSは、基本となるプロダクトがすでに比較的安定的に稼働しております。その中で基本プロダクトに足りない部分で、かつ顧客の細かい要求に対応していくような新プロダクトや機能追加を計画する必要があります。全体としては、大枠のロードマップを作成しつつ、足元では小さく計画し、素早くリリースできる、そして現場と市場からのフィードバックをもとに軌道修正していくことで、遥かに価値あるプロダクト開発につながると感じています。

その背景を踏まえ、今回の勉強会では次の3つの結論に至りました。

結論: 計画に対してはこう向き合う

  1. ほどほどの時間をかけて頻繁に見直す
  2. 計画づくりには、個人ではなくチームで取り組む
  3. 不確実性を受け入れて、計画に取り込んでおく

「どういうこと?」と思われた方は、以下をご一読いただければ幸いです。

良い計画を考えるために、まず「悪い計画」とは何かを考える

計画の善し悪しを考えるうえで、まずは逆説的に「これは機能しない」と言える特徴を考えてみました。

悪い計画とは?

  • 作った瞬間から誰にも見られない
  • 現実とのズレが放置される
  • 目的や価値が共有されていない
  • 精緻だが仮定だらけ
  • 優先順位が不明確
  • 見積りが根拠不明または一律
  • レビューや更新の仕組みがない
  • 計画=管理のための資料になっている

これらに共通するのは、「計画がコミュニケーションの軸になっていないこと」です。
計画が日々の判断材料になっていない、行動を変えない、誰も参照しない——。それは「計画が存在していない」のとほぼ同じです。

悪い計画が生まれやすいチーム文化・マネジメント体制とは

こうした「使われない計画」が生まれる背景には、チームの文化やマネジメントの構造があります。

たとえば、完璧な予測を求める文化では、現実の変化に合わせて計画を更新することが「失敗」と捉えられ、誰も変更したがらなくなります。
また、管理資料としての計画が優先されると、現場にとって意味のある粒度や構造ではなくなり、使われないまま放置されます。

現場の裁量が小さい場合も同様です。誰も更新できない計画は、現実から遠ざかるばかりです。
その結果、「とりあえず出すけど誰も見ない計画」や、「マネジメントのための報告用資料」になっていきます。

study-20250731-01.png

良い計画とは何か

その対極にあるのが、以下のような性質を持つ「よい計画」です。

  • 実際にチームで日常的に使われている
  • 現実の変化に応じて更新されている
  • 優先順位と目的が共有されている
  • 不確実性を前提に設計されている
  • 誰が関与していて、どう見積もったかが可視化されている

つまり、「正しさ」よりも「使われ方」が重要です。
計画とは未来を予測するものではなく、チームの判断と行動を支える道具であるべきです。

study-20250731-03.png

なぜ良い計画を立てるのは難しいのか

それは、「不確実性」が常に存在するからです。
プロジェクト初期には情報が少なく、関係者や仕様も流動的です。その中で精緻な計画を立てようとすると、たいていは外れます。

このとき大切なのは、不確実性を排除するのではなく、前提として計画に組み込むことです。

たとえば、"不確実性コーン"という考え方では、計画初期は見積もりに幅を持たせ、進むにつれて精度を上げていくというスタンスを取ります。
このような考え方に基づき、計画を「固定するもの」ではなく「前提を共有し、修正し続ける仕組み」として扱うことが肝要です。

実際にどう進めればよいか:計画づくりを支える3つの態度

ここで冒頭の3点に戻ります。

study-20250731-02.png

1. ほどほどの時間をかけて、頻繁に見直す

「ほどほど」が何よりも重要。「ほどほど」が何よりも重要。重要なことなので。多くの計画の失敗は、時間をかけすぎてしまうことか、時間をかけなさすぎることからスタートします。完璧な見通しは不要です。それよりも、今わかっていることをベースに仮説としての計画を立て、ズレたら直す。その“身軽さ”こそが武器になります。

計画を見直すサイクルは、チームやプロジェクトによっても変わります。一般的なアジャイルでは一つのスプリントを開発サイクルとして回しているかと思います。WOOMSチームでは1ヶ月を1つのイテレーションとして開発を行っているため、少なくとも1ヶ月単位での計画の見直しが必要になっています。実際には1つのイテレーションの中でも週次や日次で確認する機会を設けることで細かい調整を可能にしています。

2. 計画づくりには、個人ではなくチームで取り組む

個人の作る計画のなんたる脆弱なことか。スモールプロジェクトであっても、一人で全てを行う仕事ではに限りは、全ての部分について一人のスーパーマンが焦点を当て続けることは困難です。もちろん、そういったスーパーマンが存在しないとはいいません。しかし、通常はスーパーマンはいないし、いたとしても計画づくりですり減らすべきではないのです。

リーダーが一人で決めるのではなく、計画づくりそのものをチームの会話として共有することで、納得と実行力が生まれます。会話を組み込むことで、チームとしてのコミットメントを引き出すことも可能となります。

3. 不確実性を受け入れ、計画の中に組み込む

「ズレること」を前提に、「どこまでが確かで、どこからが仮定か」を言語化しながら計画する。それだけで、計画が壊れるのではなく“更新される”ものに変わります

WOOMSチームでは、「ズレること」を前提とした計画づくりを実践しています。新機能の企画段階では、「この機能はユーザーにとって本当に価値があるのか?」という仮説からスタートし、まずは必要最低限のMVP(Minimum Viable Product)としてプロトタイプやデモを作ります。その際、「ここまでが実現可能な範囲で、ここから先はユーザーの反応次第で調整する」というように、確実な部分と仮説の部分を明確に言語化しています。

そして、仮説を検証するために、営業チームやオンボーディングチームなど、実際に顧客のニーズを掴んでいるチームと確認を行い、場合によっては顧客に実際に当てながら検証を行います。これにより、計画が途中で頓挫するのではなく、市場や現場の生の声を取り込みながら、より良いプロダクトへと“更新”され続けています。不確実な未来を完璧に予測しようとするのではなく、不確実性を受け入れ、それを計画の軌道修正の機会と捉えることで、私たちは常に進化し続けるプロダクト開発を目指しています。

study-20250731-04.png

study-20250731-05.png

※画像は勉強会で使用した資料より抜粋

おわりに: WOOMSではエンジニアを募集中です

ここまで読んでいただきありがとうございます。
このブログでご紹介した「計画づくりの考え方」は、WOOMSというプロダクトチームが大切にしている開発の姿勢そのものです。

私たちWOOMSは、廃棄物処理という社会インフラ領域に向き合うSaaSプロジェクトです。単なる“ごみの管理”にとどまらず、地域社会の課題解決と、循環型社会(サーキュラーエコノミー)実現の一歩を支えるデジタルソリューションを提供しています。

現在、このプロジェクトではエンジニアを募集しています。以下のような価値観や環境に魅力を感じていただける方は、ぜひ一緒に働きましょう。

プロジェクトの立ち上げ期だからこそ、コードを書くことも、意思決定することも、すべてが次の社会を形づくる“手触りある仕事”になります。

もし、未来の当たり前を一緒につくる仲間として興味を持っていただけたら、ぜひご連絡ください。

👉 WOOMS 採用情報

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?