自分自身がユーザーになる強みを、自ら手放した
個人でタスク管理ツールを開発している。以前僕が在籍してたチームでは、エンジニアのタスクを、このツールを実際に使って管理していた。
今回記事を書くにあたり、チームの課題解決にツールが役立ったシーンを振り返ってみた。思い返すと、僕自身がマネージャーとしてチームに参画していたからこそ、課題を把握できていた。
でも僕はその後、チームを抜けた。今はもう、ユーザーではなくなってしまった（ちなみに、ツールは今でもチームで使われてる。ありがたい。）
この記事では、自分自身がプロダクトのユーザーであったからこそ得られたものと、それを手放したことについて考える。
チームに存在した課題と対策
前回の記事で、AIコーディングでエンジニアの実装が高速になった結果、タスク管理に歪みが生じたことを書いた。
2026-09-27AIで動作検証を引き取ろうとして、目的を置いてきたAIで手が空いて、セールスの動作検証を引き取ろうとした。同じ作業に見えても、確かめていたものは違った。職種が混ざるチームでは、そこに気づきにくい。
yamataka.blog
当時マネージャーだった僕は、この歪み解消のために2つの施策をした。1つの施策は「失敗」したことを前回書いたが、もう1つの施策は効果を発揮した。
そのチームでは、エンジニアによるテストに加えて、その要件の依頼主であるセールスやディレクターも動作検証をしている。この検証が滞留していた。
タスクの担当（実装）はエンジニア、検証は他のメンバー。この「担当の境目」があったため、動作検証はタスク管理に内包されていなかった。
当時は僕を含め、エンジニアと検証担当はチャットでコミュニケーションをしていた。しかし、チャットは情報が流れてしまい、検証担当への催促や確認漏れが1つの課題だった。動作検証において「今誰が、何を依頼されてて、何が指摘されたか」を、仕組みで管理したいと考えた。
そこで、僕はチームのタスク管理に手を加えることにした。ツールは僕が開発していたので、それまでもチームの状況に合わせて機能を追加してきた。今回も、以下のような機能をツールに加えた。
- 検証作業をタスク化するのではなく、実装タスクのTODOとして定義する
- タスクの担当とは別のメンバーをTODOにアサイン可能にする
- タスク管理の主な利用者はエンジニアだが、TODOにはエンジニア以外もアサイン可能にする
この施策は、見える化しただけで、検証の作業そのものが軽くなったわけではない。それでも、漏れや催促を減らせたことで、検証の滞留に効果があった。
理想的なプロダクト開発
タスク管理の仕組みに手を入れることで、チームの課題を改善できた。でも、僕にとってこの経験は、それとは別のことで大きなものになった。それは 「プロダクトに機能を追加する理想的な形」 だったから。
一般的なプロダクト開発では、ユーザーインタビューが大切とよく言われる。そりゃ、それができればしたい。でも、僕には難しい。
以前、作曲系のSNSを個人開発していたことがある。その当時は、自分で作曲をしていなかったので、ユーザーになりそうな人にインタビューをしたいと考えた。そこで実際に楽器屋に行って、作曲してそうな人に声をかけようと試みた。でも無理だった。効果的なヒアリングはできる気がしないし、そもそも見ず知らずの人にインタビューするなんて僕にはできなかった。
それ以来、個人開発は「自分が実際に使うツール」をテーマにしてる。自分をユーザーにすることで、どんな機能が必要で、どんなUXが便利かを、具体的にイメージしやすくなる。自分自身になら、いくらでも深いインタビューができる。それに一番のユーザーだから、真に迫る回答もできる。
今回の改善は、まさにその効果だった。自分自身のチームの課題を認識して、解決のための仕組みを考え、プロダクトに機能を加える。その結果、チームの仕事が改善される。これが、プロダクト開発の理想だと感じた理由だ。
一番のユーザーであることを手放した
2026年6月に、当時在籍してたチームを離れた。詳しくは以下の記事に書いた。
2026-08-05準委任で8年やって、次は登る山も自分で決めていきたい同じ現場に長く留まるほど、社員になるべきか、このまま続けるべきか、迷いは消えない。8年準委任を続けた末に見えた、その迷いの正体について。yamataka.blog
準委任契約を終了し、個人事業に時間を割きたい。その思いでチームを離れたのだが、その結果、僕は今このツールを自分自身で使っていない。「自分自身がユーザーであること」を個人開発のルールにしていたが、自分からそれを手放したことになる。
このツールはチームで使って初めて効果を発揮する。個人的なタスク管理であれば、TrelloやTodoistなど、他のツールが適してる。僕はチームを抜けてしまったので、今このツールを使っても、真のユーザーにはなれない。
実はチームを離れる時、このことも薄々意識していた。自分自身がユーザーとなった機能改善ができなくなる。それでも当時は「個人事業に時間を割きたい」との思いを優先した。
それは、プロダクトの機能にある程度の自信を持てたことが大きい。実際にタスクが600件を超えて登録されても運用が回っていたことで、ツールがチームに馴染んでいる実感があった。今はこれ以上の機能追加よりも、情報発信やマーケティングに時間を割いていきたい。プロダクトを知ってもらうこと。これが現状の優先事項だと考えた。
失ったものと、失っていなかったもの
前半で「僕にはユーザーインタビューは難しい」と書いたが、それは楽器屋で見ず知らずの人に声をかけることができなかったから。現状は、ユーザーが実際に使ってくれているし、ありがたいことに、改善のリクエストも届く。僕がチームを抜けた後も、そのチームで使われていて、改善点が挙がることが嬉しい。
先日は「親子関係のタスクを作りたい」との依頼があった。具体的に話を聞くと、「動作検証でタスクの要件が変更になったとき、新しくタスクを切りたいが、そのまま切ると元のタスクと関連づけられない」とのことだった。そこで、親子関係の機能を作り込むのではなく、元のタスクから派生した形でタスクを作成できる機能を設けた。その後、この機能をリリースしてみて、追加で気づくことがあればフィードバックをもらうようにしている。
システム開発でよくあることだが、要望の奥にある課題は、掘り下げると見えてくる。これは、自身がユーザーとして、自分へ問いかけていたときも同じだった。問いかける相手は変わった。でも、課題を見つける手段は、失っていなかった。
僕は、プロダクトの一番のユーザーではなくなった。正直、そのことに漠然とした不安も感じている。実際、自分自身で課題に気づくこと、効果を確かめることはできなくなった。いつかまた、自分でチームを持ち、このツールの一番のユーザーに戻れたらと思う。
開発してるタスク管理ツールはこちら
pitboardプレイングマネージャーのためのカンバン型タスクボードpitboard.dev