はじめに
前回のプロダクトノート では、最初の目玉機能である「複数プロジェクトの横断管理」を紹介しました。今回はその第2弾、テーマは 「WBS連動タスク管理」 です。
個人的にこれは、革命を起こすと考えています。 やっていることはごく普通のことなのですが、今までこれを体現したツールがほぼなかったと思います。（もちろんないことはないのですが、使いやすく理想の粒度で使えるものは私は出会っていません） なぜそう感じているのか、これから書いていきます。
なお、この機能はまだ作り込みの真っ最中です（特にUI/UX周り）。それでも、設計思想と大枠の使い勝手はもうリリース済みなので、本機能で得られる大きなメリットについて記載いたします。
WBSを「最後まで使い切れた」チームを、見たことがありますか？
プロジェクトの計画を立てるとき、多くのチームがWBS（Work Breakdown Structure）を作ります。たいていはスプレッドシートで、大機能・中機能・小機能と分解し、見積工数を振り、担当者と期日を入れ、進捗率の列を用意する。
ここまでは、ほとんどのチームができます。問題はその先です。
WBSをプロジェクトの最後まで、きちんとメンテし続けられたPMまたはチームに、私はほとんど出会ったことがありません。
理由はシンプルで、メンテのコストが高すぎるからです。
- 期日が変わるたびに、該当行の日付を直す
- タスクのステータスが動くたびに、WBS側のステータスも直す
- 進捗が進むたびに、進捗率の列を手で書き換える
- 計画が変わるたびに、行を足したり、組み替えたりする
これを、数十〜数百行のWBSに対して、プロジェクトが続く限り毎日やり続ける。最初の数週間は気合いで回せても、忙しくなった瞬間に後回しになり、一度ズレ始めると追いつけなくなって、やがて誰も開かなくなる。気づけばWBSは初期の遺物と化している ── これが、現場で一番よく起きていることだと思います。
つまりWBSの最大の課題は、作れないことではなく、「メンテし続けられないこと」。ここをクリアして、序盤から最後まで楽に使い切れるようになること。それだけで、PM業務は本当に変わります。
“二重管理” が、メンテコストを押し上げる
メンテがしんどい要因のひとつが、いわゆる 「二重管理」 です。
多くの現場では、WBS（スプシ）とは別に、タスク管理ツール（Backlog、Asana、Jira、Notion、自社ツール……）でタスクを動かしています。
- WBS（スプシ） … 計画と全体像を持っている
- タスク管理ツール … 日々の実作業を動かしている
この2つが別々のデータとして存在しているせいで、同じ情報を2回入力し、1つの変化を2回更新することになります。
タスク管理ツールでステータスを変え、それを見てWBSの進捗率も手で直す。
期日が変わればまた両方。
転記漏れ・更新漏れも必ず起きて、「WBS上は80%なのに実際はほぼ完了」のような不整合が生まれる。
WBSが最後まで使われなくなる、その背中を押している要素のひとつは、この二重管理が大きいと捉えています。
それでも、WBSを完走できたチームだけが手にできるもの
ここまで「WBSはしんどい」という話をしてきました。では、なぜそんなにしんどいものを、私たちはわざわざ完走させたいのか。
それは、最後まで使い切れたWBSが、PJ管理において桁違いに強力だからです。
WBSがちゃんとメンテされていると、当初の見積工数に対して実績を紐づけるだけで、予実管理 が自然にできるようになります。特別な集計機能なんていりません。WBSという仕組みそのものが、
- いま、どのくらい進んでいるのか（スケジュールに対する進捗率）
- どこで、どのくらい遅延が出ているのか
- 残りのバッファはあとどれくらいあるのか
- これからどのくらい巻かないといけないのか
を、手に取るように見せてくれます。
本来こうした 「PJの可視化と、成功に向けたコントロール」こそがWBSの最大のメリットであり、存在意義です。WBSは進捗管理表であると同時に、PJを操縦するための指針なのです。
devDash では、「進捗レポート」機能で過去の履歴データに基づいたい詳細な集計を行ったりもしていますが、これはあくまでPJに異常をきたした際に要因を分析するのがメインの目的であり、その手前に、WBS上でリアルタイムに予実が見えるという基礎があるべきだと考えています。
なのに、完走できるチームは限られてしまった
これだけのメリットがあるのに、現実はどうでしょう。
- 管理コストが高すぎてメンテが追いつかない
- 限られた予算で、管理に十分な工数を割けない
- 優秀な人材は不足し、プレイングマネージャーが増えて、PjMが管理に専念できない
こうした事情が重なって、WBSをきちんとメンテし切れるチームは、ごく一部に限られてしまいました。
その結果どうなるか。WBSという指針を手放したまま走ったプロジェクトが遅延・炎上したとき、開発チームは強制的に大きな負荷を強いられることになります。
可視化ができていないから「どこでどれだけ遅れ、なぜそうなったか」を客観的に示せない。
原因はチーム単独の問題ではないのに、説明する材料がない。あまりに肩身が狭い。
この状況を、ツールの力で変えたい。「優秀でメンテを頑張れるチーム」だけの特権だったWBSの恩恵を、普通のチームが当たり前に受け取れるようにしたい。それがこの機能の出発点です。
devDash のアプローチ：メンテコストを構造から消す
「メンテし続けられるWBS」をどう実現するか。devDash の答えはシンプルです。
WBSの行と、実際のタスクを 1:1 で直結させる。
devDash のWBSは、スプシと同じように、大機能・中機能・小機能…と階層でタスクを分解していきます。
※階層の段数も呼び名は、プロジェクトごとに自由にカスタム設定できる作りにしています。
このような形で、WBSに並んだ各タスク行が、devDash 内の実タスクそのものと紐づいています。
これで、メンテコストを押し上げていた要因が次々と消えます。以下で説明していきます。
転記がゼロになる ― 二重管理がそもそも発生しない
WBS上でタスク紐づけを行った瞬間、それは devDash のタスクとして実体化します。
WBSを書く＝タスクを登録する、がほぼ同時に行える。
「タスクをWBSに書き写す」作業も、その逆もありません。最初から1つだからです。二重管理という問題が、構造的に存在しなくなります。
更新が一度で済む
WBS上で担当者を変えれば、連携タスクの担当者が変わる。
期日を変えれば、タスクの期日が変わる。
ステータスを変えれば、タスクのステータスが変わる。
WBSで触ったことが、そのままタスクになる。「WBSも直してタスクも直す」という二度手間が、原理的に消えます。
進捗率の手入力が、要らなくなる
WBSメンテで一番面倒な「進捗率を手で更新する」作業。devDash では、これがそもそも存在しません。
タスクの進捗を更新すると、それが自動でWBS側にも同期反映されます。
※β版である現時点ではステータスごとに進捗率を設定することで簡易的に進捗を算出しています。
また、タスクごとの進捗率が、 中機能 → 大機能 → プロジェクト全体へと自動でロールアップされるので、タスクを動かしていれば、WBSの進捗は勝手に正しくなります。ようするに自動集計がきくので、手動で何かを打ち込んだり集計したりする必要はありません。
つまり、WBSが形骸化しようがないのです。
そして、予実管理が “ただ見えている” 状態になる
ここが、前章で書いた「完走できたチームだけの果実」を、誰でも手にできるようにする部分です。
devDash のWBSは、各行で 見積(h) / 実績(h) / 残(h) を持ち、それらをカテゴリ単位・プロジェクト全体へと自動集計します。画面上部には、見積・実績・残工数・全体進捗率が常にサマリ表示される。
つまり、当初の見積に実績が紐づいた状態が、メンテの手間ゼロで維持される。特別な集計機能を呼び出さなくても、「どこが見積を超えているか」「残りどれだけか」「全体でどれくらい進んでいるか」が、WBSを開いた瞬間に見えている。予実管理が、わざわざやる作業ではなく、ただそこにある状態になります。
バッファを”溶かさず”管理する ── あと何時間残っているかが、常に見える
予実管理をやっていてよくハマるのが、機能別の見積だけを積み上げても、PJ全体の”余裕”が管理できないという問題です。
バッファは厄介で、各機能の見積にこっそり溶かし込んでしまうと、進行中に「これはバッファだ」と認識されないまま消えていきます。気づいたら余裕がゼロ、という事態の原因はだいたいこれです。バッファは、バッファとして独立させておく必要があります。
devDash では、機能工数の合計に対して、パーセンテージ（5%、10%…）でバッファを見積もれます。「バッファ 15%」と置けば、全機能の見積合計に対して15%分の余裕が、独立した枠としてはっきり確保される。管理コストなども同じ仕組みで、ラベルと％を付けて何枠でも積めます。
そして、ここが肝心なところです。確保したバッファに対して、各タスクの遅延・巻きが、そのまま”消費率”として反映されます。つまり、
いまバッファをどれだけ食いつぶしていて、あと何時間（何％）残っているか
が、WBSを開いた瞬間に一発で分かります。「なんとなく押してる気がする」ではなく、残りバッファという具体的な数字で、プロジェクトの余力を把握できる。
これは、多くのPMがずっと欲しかった機能なのではないかと思います。バッファは本来、「あるはずなのに、いつの間にか無くなっている」もの。それが常に残量として見えていれば、まだ攻めていいのか、もう締めにかかるべきかという判断が、勘ではなく数字でできるようになります。
機能の予実だけでなく、バッファの残量まで含めて見える ── ここまでできて初めて、WBSは「PJの本当の余力」を映す操縦席になります。
UI/UX のこだわり：「Webアプリ」ではなく「スプレッドシート」の操作感
メンテコストを下げるという意味で、もうひとつ絶対に外せないのが 操作の楽さ・速さ です。ここが、この機能で一番こだわっているポイントです。
スプシがWBS管理で根強く使われ続ける理由のひとつは、入力が速いから。セルをクリックしてダイアログを開く、なんてことはしません。
矢印キーで動いて、そのまま打って、Enterで確定して、次へ。キーボードから手を離さずに、思考のスピードでデータを入れていける。
多くのWebアプリ型ツールは、ここで負けます。「行を追加」ボタンを押し、モーダルが開き、フォームを埋め、保存ボタンを押す……。1タスクごとにこれをやっていたら、スプシには勝てません。そして、操作が遅いツールは、結局メンテされなくなります。
devDash のWBSは、この「スプシの操作感」をWebアプリ上で再現することを目指しています。
- 矢印キーでセル間を移動できる
- そのまま文字を打てば、セルの値が即・編集モードになる（クリックもダブルクリックも不要）
- Enter で編集 / 確定、ステータスや担当者のセルなら Enter でそのまま選択肢が開く
- ⌘ + Enter で行追加 ― カテゴリ行なら子を、タスク行なら次の兄弟を、カーソルを保ったまま追加
- ⌘ + C / ⌘ + V でセルのコピー＆ペースト
- Backspace / Delete で値をクリア
- 行はドラッグ＆ドロップで階層ごと並べ替え、列幅も自由にリサイズ（設定は記憶されます）
- 入力できる空行が最初から並んでいて、上から埋めていくだけでWBSが育つ
つまり、「スプシを触っている時の手の動き」がそのまま通じる。なのに、入れたデータはタスクと連動していて、予実も進捗も勝手に積み上がる。「スプシの速さ」と「ツールの連動性」の、いいとこ取りを狙っています。
このあたりはまさに今、細部を詰めている最中です。文章では伝わりきらない部分なので、ぜひ実際に触って確かめてほしいところです。
実際の使い方：計画から着地まで、1つの画面で
日常的にどう使うか、ざっくり流れを書くと：
- プロジェクト開始時：WBSをスプシ感覚でガッと作る。階層に分解し、見積・担当・期日を入れる。この時点で、タスクの登録もほぼ同時に完了している。
- 進捗確認・報告時：メンバーがタスクを進めると、進捗も実績もWBSに勝手に積み上がる。PjMはWBSを開くだけで、どこがどこまで進んでいるかが一目で分かるため何もしなくていい。
- 計画変更時：期日や担当が変わったら、WBS上でその場で直す。別ツールを更新する必要はない。
やっていること自体は、ありふれた「WBS管理」です。でも、転記しない・二度更新しない・進捗率を手で書かない・集計しない。メンテコストを押し上げていた要素が消えるからこそ、最後まで使い切れる。そして使い切れるからこそ、WBS本来のメリットを受け取れる。この当たり前の仕組みが大事だと思っています。
おわりに：WBSが続かないのは、チームのせいではない
「WBSを作っても、結局メンテされなくなる」というのは、PM界隈で語り尽くされた悩みだと思います。でもそれは、チームの怠慢ではありません。WBSとタスクが別々にあり、二重管理を前提に、すべてを手で更新し続けなければならない構造が、メンテ放棄を必然にしているだけです。
そして、その構造のせいでWBSを手放したチームが、いざ遅延・炎上したときに、可視化できていないがゆえに詰められる一方になる ── この理不尽を、ツールの力でなくしたい。
devDash のWBS連動タスク管理は、WBSとタスクを1つにして、転記・二重更新・進捗率の手入力・集計という”見えない作業”を構造から削る試みです。そして、スプシの操作感を保ったまま、それを実現する。狙いはただ一つ、普通のチームが、WBSを最後まで使い切れるようにすること。それができれば、予実管理もPJの可視化も、自然と後からついてきます。
「WBSはいつも途中でメンテされなくなる」「進捗率の列を手で更新するのが苦痛」「WBSのスプシとタスク管理ツールを行ったり来たりしている」「遅延しても客観的に説明する材料がなく、ただ責められる」── そんな心当たりがある方は、ぜひ一度触ってみてください。文章では伝わりきらない手触りがあると思います。