なぜpitboardを開発したのか

pitboard(ピットボード)は、プロダクトを継続的に改善する、小さな開発チーム向けのタスク管理ツールです。

開発のきっかけは、私自身がエンジニア組織のマネージャーとして働く中で感じた悩みでした。世の中にはBacklogやTrello、Asanaなど優れたツールがたくさんあるのに、なぜ新しく開発したのか。その理由をお話しします。

計画が頻繁に変わるチーム

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

マネージャーとしての悩み。それは「計画が変わるたびに、タスク管理ツールの更新が辛い」ことでした。

継続的改善フェーズでは、調査の差し込み、緊急不具合、要件変更で、計画は日常的に揺れます。チームは「期日厳守」よりも柔軟な対応を重視しているので、実装後のBiz確認で要望が変わることも多い。そのたびに計画と実態がずれていきますが、変更に柔軟に対処することでプロダクトの価値を高めています。

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

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

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

型	前提・シーン	変更の扱い
プロジェクト型	新規開発・受託。依存関係が多い計画	なるべく計画を正として調整
継続的改善型	運用中の追加・改修。短サイクル前提	計画を上書きしながら前に進む

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

計画が変わると、日付の再調整が生じます。日付を固定しなければ影響は小さいのですが、それでもタスクの消化にどのくらい要するかは計画段階で定義したい。理由はシンプルです。

さらに、パーキンソンの法則を避けるために、タスクごとにバッファを設けないポリシーで運用しています。

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

— ウィキペディア「パーキンソンの法則」

しかしながら日付で管理すると、変更時の影響がシビアになる副作用が生じます。

変更には柔軟でありたいが、タスクのボリュームは定義したい。 このジレンマが悩みの核でした。

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

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

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

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

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

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

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

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

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

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