毎日使わない業務ツールは売らない — AI業務管理秘書たすきばを自分のプロジェクト管理に使い倒す理由
たすきばは “私自身が最初のユーザ”
たすきばを作るとき、私はずっと一つのことを意識してきました。
「私自身が最初のユーザ」という前提を、最後まで崩さない。
リリース直後から、私の本業のプロジェクト管理は 全部たすきばで実施する つもりです。今日は L 章の第 2 回として、 たすきばが戦略の中心に置いている Dogfooding の話を書きます。
Dogfooding とは
英語の “Dogfooding” は、 「自社のドッグフードを自分で食べる」 の比喩です。ソフトウェア業界では「自社製品を自分のチームで実利用する」ことを指します。
代表例：
- Microsoft の社内開発者が Office を使う
- Slack の社内コミュニケーションは Slack
- GitHub のチームは GitHub で開発
——自分で使うことで、ユーザ視点が自然に獲得できる、というのが Dogfooding の核です。
なぜ Dogfooding が重要か
Dogfooding なし で開発すると：
- 「こうあるべき」という想像で機能を作る
- 実際の使い勝手が分からない
- バグや UX 問題に気づかない
- 「作って終わり」になる
Dogfooding あり の開発：
- 自分が使うので、不便な部分が 即座に痛い
- バグはすぐ気づく
- UX 改善が日常的に進む
- 「作り続ける」モチベーションが続く
Dogfooding は、 サービス品質の “最低保証” になります。これは K-4 で書いた「自分が使わないものを売るのは不誠実」 と、表裏一体の発想です。
たすきば Dogfooding 計画
私は本業で複数の案件に関わっています。リリース後、これらの案件管理を すべてたすきばで実施 する想定です。
想定する利用シーン
| シーン | 使い方 |
|---|---|
| 新規案件の立ち上げ | プロジェクト作成 → 提案エンジンで過去案件のナレッジ参照 |
| WBS 管理 | タスク階層管理 / ガントチャートで進捗確認 |
| リスク / 課題管理 | 顕在化したリスクを起票 → 解消時にナレッジとして横展開 |
| 振り返り | スプリント毎に KPT を記録 → 過去の振り返り教訓を意味検索で参照 |
| ナレッジ蓄積 | 個別の技術判断・業務判断をナレッジに残す → 次案件で引き出す |
ユーザ視点で気づくこと
Dogfooding を始めると、開発時には気づかなかった問題に、必ず遭遇します。
予想される気づきとして：
- 「この画面、毎日見る場所なのに、ちょっと重い」 → パフォーマンス改善
- 「この操作、よく使うのに、ステップが多い」 → UX 簡素化
- 「提案結果、意外と精度が低い」 → 提案エンジン調整
- 「このフィルタが欲しい」 → 機能追加
これらは、Dogfooding しない限り、永遠に気づきません。
“6/15 ± 1 週 AI 補助なし 1 機能実装チャレンジ”
ちょっと変わった計画として、 6 月 15 日 ± 1 週で、AI 補助なしで 1 機能を実装するチャレンジ を予定しています。
これは：
- 普段は Claude Code 補助で開発している
- それを 意図的に止め、自分の手だけで実装する
- AI 駆動の “罠” や “慣れ” に気づくため
たとえば、
- ある小さな新機能を選ぶ
- Claude Code を一切使わずに、IDE で手書き
- ドキュメント / KDD / ADR も自分で書く
- かかった時間を記録
——このチャレンジで、自分の AI 依存度を測ります。依存度が高すぎたら、人間駆動への移行が難しくなります。 心理的安全性の “再現する” 段階 で書いた「型に落として再現する」と、根は同じです。 自分の手で再現できないものは、本当に理解できていない のです。
実プロジェクトで使うことで、リスクが見える
私自身がたすきばを使う中で見える Risk:
- 自分のプロジェクト情報をたすきばに入れる → 個人情報 / 機密情報の扱いリスク
- 提案エンジンの精度が悪い → 業務効率を下げるリスク
- バグでデータが消える → 業務継続リスク
これらのリスクに 私自身が直面する ことで、対策を真剣に考えられます。
「他人事のリスク」と「自分事のリスク」では、対策の真剣さが圧倒的に違います。
Dogfooding から得たフィードバックの処理フロー
Dogfooding で気づいた問題は、以下のフローで処理します。
- GitHub Issue として記録（「自分のユースケース」を明示）
- 優先度をつける（P0〜P3）
- Phase 2 ロードマップに反映
- 改修を実装
- 再度 Dogfooding で検証
このサイクルを回すことで、たすきばが 「自分が毎日使えるサービス」 に近づいていきます。
Dogfooding は競合優位の源泉
Dogfooding なしの SaaS と、ありの SaaS では、長期的な競争力が違います。
- Dogfooding なし: 「作って売る」だけで終わる
- Dogfooding あり: 「毎日改善される」サービス
たすきばは、 「毎日改善される」 サービスを目指します。そのために、Dogfooding を戦略の中心に置きます。
“Dogfooding が機能しないケース” の自覚
Dogfooding にも、限界があります。
- 自分のユースケースが、他ユーザのユースケースを代表しない
- 一人で全業界の慣習をカバーできない
- 「自分が使うから良い」だけで、他ユーザに合うとは限らない
そのため、
- Dogfooding は 必要条件、十分条件ではない
- ユーザフィードバックも必ず取る
- 多様なユースケースを意識する
Dogfooding + ユーザフィードバック の 両輪 が必要、と思っています。
“失敗 Dogfooding” の予測シナリオ
将来 Dogfooding で失敗する可能性があるシナリオ：
| 失敗 | 解決 |
|---|---|
| 私のユースケースが偏りすぎる（PM/PL レイヤだが、エンジニア個人のユースケースは弱い） | メンバー加入時に、その人のユースケースも Dogfooding |
| 個人情報を入れる心理的ハードル（自分の案件情報をたすきばに全部入れるのは怖い） | 自分が信頼できないなら他ユーザにも勧められない → セキュリティ強化のモチベ |
| 本業の負荷で使い続けられない | 入力を簡素化 → 「3 秒で記録できる」UI を目指す |
これらは、 Dogfooding を通じて事前に気づける問題です。
まとめ
| Dogfooding の役割 | 効果 |
|---|---|
| ユーザ視点の自然な獲得 | 想像に頼らない |
| バグ / UX 問題の即時発見 | 高速な改善サイクル |
| 自分事としてのリスク認識 | 真剣な対策 |
| 競合優位の源泉 | 毎日改善されるサービス |
たすきばは、 Dogfooding を戦略の中心に置き、 毎日改善されるサービス を目指します。
次回は L 章の最終回、連載の中盤の締めくくり。 「10 年後の金のなる木」 というシナリオを書きます。たすきばが、私の人生において何を果たしてほしいのか、という話です。
関連記事
- v1 リリース後のロードマップ — Phase 2 / Phase 3 の構想 — 連載第 15 回・ロードマップ
- 2 年で収益化判定、だめでもサービスは続ける — たすきばが持つ 2 つのシナリオ — 「自分のために続ける」発想の源
- 心理的安全性は「知っている」だけでは届かない — 「再現する」と「Dogfooding」の親和性
たすきば について
たすきば Knowledge Relay は、私自身が毎日使うサービスとして開発・運営されています。 プロダクトページ からお試しください。
