イシュー機能の設計 - チームでプロダクトを育てたい

スプレッドシートとタスク管理ツールの間で

継続的改善フェーズに入ったプロダクトを運用していると、毎日のように新しい要望や改善案が生まれてきます。

営業メンバーが顧客訪問から戻ってくると、「こんな機能があったらいいって言われた」「この部分が使いにくいらしい」といったフィードバックを共有してくれます。一方でエンジニアチームは、タスク管理ツールで今週、今月のタスクを粛々と進めています。

当初、チームでは顧客からのフィードバックをスプレッドシートで管理していました。営業メンバーはスプレッドシートに要望を記入し、定期的なミーティングでエンジニアと検討。実装が決まったものだけをタスク管理ツールに転記する、という流れです。

しかし、この方法には大きな問題がありました。要望を出した営業メンバーからすると、自分が記入した要望がその後どうなったのか分からない。実装されたのか、検討中なのか、見送られたのか。エンジニア側も、スプレッドシートとタスク管理ツールを行き来しながら、転記作業に時間を取られていました。

もっと「チーム全体で一つの場所を見ている」という感覚があったほうがよいと感じました。

チーム全員が同じ場所に集まるために

やりたいことはシンプルでした。営業もカスタマーサポートも、そしてエンジニアも、全員が同じツールを使って情報を共有する。顧客の声がダイレクトに開発の現場に届き、その進捗や判断も透明化される。

でも現実には、多くのBizメンバーは「タスク管理ツールはエンジニアのもの」という意識を持っていました。「まだ実装するか決まっていないのに登録していいのかな」「単なる質問なのにタスクにしたら迷惑かも」「優先度が低い要望は邪魔になるかも」そんな遠慮が、情報共有の壁になっていたのです。

そこで生まれたのが「イシュー」という概念でした。実施が決まっていなくても気軽に登録できる場所。タスクにするほどでもない質問や相談も含めて、何でも受け止められる窓口。これなら営業メンバーも遠慮なく顧客の声を記録できますし、エンジニアも「今すぐやるタスク」と「これから判断する項目」を明確に区別できます。

シンプルさとの葛藤

正直に言うと、イシュー機能を追加することには葛藤がありました。

pitboardは「シンプルで分かりやすいタスク管理ツール」を目指して開発してきました。機能を増やすことは、その理念に反するのではないか。ユーザーを混乱させ、学習コストを上げてしまうのではないか。

実際、すべてのチームにイシュー管理が必要なわけではありません。エンジニアだけの小さなチームなら、タスク管理だけで十分かもしれません。明確な要件定義があるプロジェクトなら、イシューという曖昧な状態は不要でしょう。

そこでpitboardでは、スペースごとにイシュー管理を使うかどうかを選択できるようにしました。最初はタスク管理だけでスタートし、チームが成長してBizメンバーが加わったタイミングでイシュー管理を有効にする。そんな段階的な導入も可能です。

操作の簡潔さへのこだわり

機能を追加する以上、操作が複雑になってはいけない。ここは大切にしたいポイントでした。

イシューの完了方法は、内容に応じて3つのパターンがあります:

タスク化する: 実施が決まったらワンクリックでタスク化。その瞬間から担当者をアサインでき、通常のタスクと同じように進捗管理ができます
回答して完了: 質問や相談の場合は、コメントで回答してアーカイブ。軽微な問い合わせもこれで完結します
見送る: 検討の結果、実施しない場合はアーカイブ。判断の記録は残ります

カードの見た目で一目でイシューとタスクを判別できるようにしました。イシューには担当者をアサインできないという制約も、実は分かりやすさにつながっています。「アサインできない=まだ誰のものでもない、チーム全体で検討すべきもの」という明確なメッセージになるからです。

アーカイブしたイシューは削除されず履歴として残るため、「なぜ実装しなかったか」「どう回答したか」という記録が将来の参考になります。

継続的改善の本質

継続的改善フェーズの本質は、すべてを実装することではありません。限られたリソースで価値を生み出すために、何を選び、何を選ばないかを適切に判断することです。

だからこそ、すべての声を可視化することに価値があります。実装しない要望も、検討中のアイデアも、すべてがチームの財産です。それらを一元管理し、全員が「今何を検討していて、何を優先しているか」を共有できる環境が、継続的改善の土台となります。

小さなチームだからこそ、全員参加型の改善サイクルを回せる。営業が持ち帰った顧客の声が、その日のうちにイシューとして登録され、エンジニアの目に触れ、議論が始まる。このスピード感と一体感こそが、目指していたものでした。

イシュー機能は、単なる要望管理の仕組みではありません。チーム全員が同じ方向を向いて、一緒に製品を育てていくための共通言語です。