yamataka yamataka

プロジェクトじゃないのに、プロジェクト管理ツールを使っていた

タスク管理 仕事の仕組み

タスク管理ツールを開発して2年、チームで実際に運用して1年以上が経つ。僕はなぜこんなに長い間、開発を継続しているか。

プロダクト開発系の記事には「なぜ開発したか？」をテーマにしたものが多い。でも正直に言うと、僕は開発当初にはそこまで大きな志は無かった。なんとなく、既存のツールが好きになれなかった、自分のやりたい形を実現したかった。既存の仕組みに違和感があったけど、それをうまく言語化できなかったり、言語化しても本質じゃなかったりもした。

しかし、さすがに2年以上続けていると、自分が何を実現したいのか、やっと言語化できてきたように思える。今回は「ツールで何を解決したいのか」これを整理していく。

「タスク管理」は「プロジェクト管理」なのか

タスク管理ツールを比較すると、そこには「プロジェクト管理」として紹介されてるツールが多く存在する。確かに、タスク管理とプロジェクト管理のツールは、似たような機能を提供してる。IT系の現場ではタスク管理ツール＝プロジェクト管理ツールとして捉えられてると思う。

ここに大きな問題があると思っている。それは、チームの性質が「プロジェクト」ではないのに、タスク管理としてプロジェクト管理ツールを導入してしまう点だ。

僕の在籍していたチームは、プロダクトを運用しながら継続的に改善している。普段の業務は「プロジェクト的な開発」もあるが、他にも軽微な改修だったり、差し込みの問い合わせ、障害対応といった作業も含まれる。

それに、チームはサービスの運営が終了するまで、開発が継続する。プロジェクトの特徴である「始まりと終わりが明確」になってない。

プロジェクトじゃないのに、プロジェクト管理ツールでタスク管理をする。なぜなら、有名なタスク管理ツールは「プロジェクト管理ツール」を名乗ってるから。ここに矛盾があった。

サービスを運用しながら改善するチームの特徴

僕が在籍していたチームは、受託開発でもゼロイチの開発でもない。自社のサービスはすでに稼働していて、お客様が利用している。一般的には「保守・運用フェーズ」になると思うが、プロダクトも積極的に改善している。同じ「ソフトウェア開発」の現場でも、プロジェクト型と比較すると、僕たちのチームには以下のような特徴があった。

差し込みタスク

すでにサービスは稼働して、実際にユーザーが利用している。そこには、問い合わせ調査や障害対応などの「差し込み」業務が必ず発生する。この「差し込み」は、チーム内で最重要であることが多い。仮に機能レベルでの障害が発生したら、着手中の作業を中断して対応する必要がある。

プロジェクト管理ツールを使って、ガントチャートで計画を立てると、差し込みの影響を受けて、リスケが頻発する。そのためにバッファを設けることの問題点は、以前の記事に書いた。

2026-09-09「そのタスク何日で終わる？」と、メンバーに聞かないメンバーに日数を聞くと、その数字は約束になり、バッファが入る。しかし積んだ分だけ、問題が起きなくてもタスクは遅くなる。だから、マネージャー自身でサイズを出す。yamataka.blog

計画の変更に価値がある

僕のチームには、専任のプロダクトマネージャー(PdM)はいなかった。大規模チームには当然な存在も、小中規模のチームだと、PdMが存在しないチームも珍しくないと思う。

PdMが存在しないことで生じる影響は、要件が定まっていない点にあると思う。セールスやディレクターがPdMの代わりも担う場合、開発する機能のイメージや設計が難しい。そうすると「実際に動くもの」をさわったときに、イメージが膨らんでいく。当初の要件で実装してから、動作確認を依頼すると「もっとこうしたい」「この機能を追加したい」といった声が上がる。

エンジニアからすると、手戻りのような感じがしなくもないが、プロダクトの価値を考えると、この磨き込みのフェーズが重要だった。理想とは言えないかもしれないが、これが小規模な継続改善チームの現実的な姿だ。

更に「期日」がそこまで重要でない点も大きい。自社サービスなので、ユーザーに事前の告知が不要なことが大半で、こちらのタイミングでリリースができる。だから、継続的に改善を進めるチームでは、期日を守ることよりも、変更に柔軟に対処することのほうが価値が高い。一方で受託開発などは、期日が重要な要素なので、変更には慎重になる。この違いが、プロジェクト管理とのミスマッチになってくる。

メンバーが多様

チームは、エンジニアだけでなく、セールスやオペレーターなど、複数の職種で組まれている。エンジニアだけだと4名程度の小規模だが、チーム全体となると10名くらいの規模になる。

ソフトウェアの開発主担当はエンジニアになるが、セールスが起案した要望や、オペレーターが利用する管理画面の開発などもある。その場合、セールスへの動作確認依頼だったり、オペレーターへの進捗共有などが生じるので、エンジニアだけで完結するタスクはあまりない。すなわち、タスク管理はエンジニアだけのものではなく、多様な職種のメンバーみんなで利用するツールになる。タスクの消化はエンジニアの役割であっても、その出所や出口はそれ以外のメンバーになる。

ここで「スクラム」を候補に検討したこともある。ただ、僕はスクラムを実践したことがない。書籍で学んだ程度だ。それでも、この多様なチームに当てはめると、引っかかることがあった。セールスやオペレーターとのコミュニケーションでは、タスクをポイントではなく日数で伝える。それに、僕たちのチームはスプリントで計画を守ることより、途中で変えられることのほうに価値を置いている。

そうすると、スクラムがメンバーに浸透していくイメージが、僕には湧かなかった。それが正直な思いだ。

継続的改善型チーム

以上3点が、僕のチームにおける既存のツールとのミスマッチが大きいと考えた要因だ。特にガントチャートを利用したプロジェクト管理ツールは、差し込みや変更への対応が難しかった。

ちなみに、僕のチームも「○○開発プロジェクト」のように、中長期的な開発は「プロジェクト」と呼ぶ。だから当初は僕も「プロジェクト管理」をしていると思っていた。しかし、ここに落とし穴があった。

興味深いのは、プロダクトを運営しながら改善を進めるチームは珍しくない。むしろ一般的な形だ。それなのに、多くの現場がプロジェクト管理を使っていて、僕自身もそうだった。仕事の見た目がプロジェクトだから、気づかない。

そして、冒頭で「開発した動機を言語化できなかった」と書いた。僕のチームは「プロジェクト型」では無かったが、それを「継続的改善型」と名付けると、チームの領域が明確になった。

まとめ

「継続的改善型チーム」（略して継続型チーム）の特徴をまとめておく。

  • 自社サービスを運営しながら、継続的に改善して育てている
  • エンジニアだけでなく、チームには多様な役職から構成される
  • 期日を守ることよりも、要件の変更に柔軟な対処が求められる

名前を付けたことで、そのミスマッチを明確にすることができた。継続型チームに適したタスク管理を実現したい。それこそが、2年以上経った今でも、開発を継続してる理由だと言える。

なお、マネージャー視点では、以前に「管理しないタスク管理」という話を書いた。

2026-08-27マネジメントが嫌い。だから、管理しないタスク管理を実現したい。タスク管理が嫌いなプレイングマネージャーが、2年におよぶタスク管理ツールの個人開発で悟った「任せる管理」についての思想。yamataka.blog

では、継続型チームに求められるタスク管理とは何だろう。これについては、また別の記事で述べていきたい。