なぜpitboardを開発したのか

私の本業は、自社プロダクトの開発・運営チームでエンジニアのマネジメントを担っています。プロダクトは既にローンチ済みで、日々の仕事は機能追加や改修が中心――いわゆる継続的改善フェーズです。

マネージャーとして悩みがありました。それは「計画が変わるたびに、タスク管理ツールの更新が辛い」ことです。継続的改善フェーズでは、調査の差し込み、緊急不具合、要件変更といった理由で、計画は日常的に揺れます。

更に私たちは「期日厳守」よりも柔軟な対応を重視します。実装後のBiz確認で要望が変わることも多く、そのたびに計画と実態がずれていきますが、変更に柔軟に対処することでプロダクトの価値を高めています。

しかし、ガントチャートのように日付で厳密に管理するスタイルは、変更時の更新コストが大きいです。「複数のバーをドラッグして一括変更」といった便利な機能もありますが、私にとっては 変更作業そのものが苦痛 でした。

導入したタスク管理ツールは現場に馴染まず、計画変更のたびに更新が滞り、やがて計画と実態が乖離します。メンバーも使わなくなり、最終的に運用をやめました。

いま思えば原因は明確で、継続的改善の現場にプロジェクト型の前提を持ち込んだミスマッチです。

一般的なツールはプロジェクト型寄り、特にガントチャートは低頻度の変更に強い。一方で頻繁な変更が起きる現場では更新コストが膨らみます。この違いは、マネジメントにとって小さくありません。

計画が変わると、日付の再調整が生じます。逆に言えば、日付を定義しなければ影響は小さいのですが、それでも私は、タスクごとに日付を持たせたいと考えています。理由はシンプルです。

• 担当者が完了日を意識して動ける
• Biz／営業とスケジュール感を共有できる
• 計画と実績の差を見える化できる

さらに私は、タスクごとにバッファを設けないポリシーがあります（パーキンソンの法則）

仕事の量は、完成のために与えられた時間を全て満たすまで膨張する。

しかしながら結果として、変更時の影響がシビアになる副作用が生じます。

——変更には柔軟でありたいが、日付も定義したい。このジレンマが悩みの核でした。

突き詰めると、私が本当に欲しかったのは期日の厳守ではなく、タスクのサイズ感（想定工数）の共有でした。

「このタスクは何日くらいか」を合意でき、ボリューム × 優先順位が表現できれば、日付を細かく固定しなくても運用できます。

そう考えて実現できそうなツールを探しましたが、意外にもタスクをボリュームで管理する発想を中心に据えたツールは見当たりませんでした。

いくつも試した末に、自分のマネジメント哲学を形にし、チームで試したいという想いが湧いてきました。pitboard開発のきっかけは、新製品開発ではなく、現場の運営を良くするための道具として始まっています。

ただ、実運用に耐えるまでには開発に時間がかかりました。自身のチームで使う以上、品質が低ければメンバーに迷惑をかけてしまいます。私のわがままでチームの運用を乱したくはなかったため、時間をかけてじっくり開発を進めました。

2025年6月、エンジニア4名で実際に利用してみました。 粗い不具合や不足を潰してから、Bizを含む8名体制へ拡大しました。最初は不安もありましたが、いまは自然に馴染んでいます。

効果はシンプルです。「計画変更の辛さ」が大きく減りました。

• 日付の再配分はほぼ不要（ボリューム×優先で回す）
• 割り込み時はカードの移動で完結
• 定例会ではボードを見ながら進捗を共有

もともとは私の"わがまま"から始まった開発ですが、協力してくれたメンバーのおかげで、一緒に使いこなすツールに育っています。

競合が多い領域での個人開発に迷いはありました。それでも、継続的改善の現場では、日付固定ではなく「ボリューム×優先」で運用する発想が効く——その手応えを、私のチームで確認できました。

もし同じようにDevOpsフェーズで日々の変更に追われるプレイングマネージャの方がいたら、ぜひ一度試してみてください。デモ版をご用意しています。気軽に触って、相性を確かめていただければ嬉しいです。