ドッグフーディングの始め方

ドッグフーディングは、始め方を決めずに号令だけかけると続きません。数日で元の手段に戻り、「やってみたが特に成果はなかった」という記憶だけが残ります。逆に、対象と退路と記録を先に決めておけば、小さなチームでも成立します。

本記事では、自社プロダクトを業務の本番として使い始めるための手順を、順を追って整理します。ドッグフーディングの定義についてはドッグフーディングとは何をすることかをご覧ください。

手順1: 対象業務を一つに絞る

最初に決めるのは、どの業務をプロダクトに載せるかです。次の三つを満たす業務から選びます。

• 自社に実在する業務であること（検証のために新しく作った業務は、実際の負荷がかからないため意味がありません）
• 止まっても復旧できること（基幹の会計や決済など、止められない業務は最初の対象には向きません）
• 週に複数回は発生すること（頻度が低いと、期間内に十分な回数を使えません）

同時に、対象外にする範囲も書き出します。「顧客への請求はまだ載せない」「外部に出す資料はまだ従来どおり」というように、線を引いておくと、後から「これも入れるべきか」で迷わずに済みます。

手順2: 止まったときの復旧手順を決める

本番業務に載せる以上、止まる可能性を前提にします。開始前に次を決めます。

• 業務が止まったと判断する基準（何時間止まったら、何件滞留したら）
• そのときの代替手段（手作業での処理、旧ツールの一時的な再開）
• 再開を判断する人
• データの退避先と、後から取り込む手順

この手順を用意することが、次のステップで退路を断つための条件になります。逃げ道を用意しないまま業務を載せると、トラブル時に現場の判断で勝手に戻され、検証そのものが崩れます。

手順3: 旧ツールへの書き込みを止める

ここが最も効果が大きく、最も先延ばしにされやすい手順です。新旧の併用を許すと、人は不便を感じた瞬間に慣れた方へ戻ります。戻れる限り、不便は課題として記録されません。

具体的には、次のようにします。

1. 旧ツール（表計算ファイル、旧システム、紙の帳票）を参照専用にする日を決める
2. その日以降、新規の書き込みは新しいプロダクトにのみ行うと宣言する
3. 例外を認める場合は、誰がどの条件で認めるかを決めておく
4. 担当者による手作業の代行を止め、詰まった箇所は課題として記録に回す

手作業の代行を止める点は見落とされがちです。親切な担当者が裏で処理を肩代わりすると、表からは問題が見えなくなり、その人がいなくなった時点で破綻します。

手順4: 記録の経路を一つに決める

不満を記録する場所が複数あると、記録されません。チャットの雑談、口頭、課題管理ツールに分散すると、集計も優先順位付けもできなくなります。

決めるのは次の三点です。

• 場所を一つにする（課題管理ツールでも、専用のチャットチャンネルでも構いません）
• 書く項目を最小にする（何をしようとして、何が起きて、どう回避したか。一行ずつで足ります）
• その場で書ける状態にする（後でまとめて書く運用は、ほぼ実行されません）

記録の項目を増やすと書かれなくなります。頻度や深刻度の分類は、記録する人ではなく、集める側が後から行います。集めた記録を仕様に変える方法は社内の不満を仕様に変える手順で扱います。

手順5: 言い出しにくさを解消する

社内検証で最大の障害は、技術の問題ではなく、指摘のしにくさです。作った同僚が目の前にいる状態で「これは使えない」と言うのは、多くの人にとって気が重いことです。

対処は、指摘を個人の勇気に頼らない形にすることです。

もう一つ有効なのが、開発チームの側が率先して自分たちの作ったものの不便を記録することです。作り手が最初に「ここは使いにくい」と書けば、他の人も書きやすくなります。役割分担や体制づくりについては少人数開発チームの体制設計も参考になります。

手順6: 検証期間と判断日を宣言する

終わりを決めずに始めると、いつまでも「検証中」のまま続き、判断が先送りになります。開始前に次を決め、関係者に伝えます。

• 検証期間（業務の周期を最低1回は含む長さ。月次処理があるなら月をまたぎます）
• 判断日（その日に、続ける・作り直す・やめるのどれかを決める）
• 判断の基準（何が満たされていれば続けるのか）

判断の基準は開始前に合意しておきます。終わってから基準を決めると、出た結果に合わせて基準が動き、検証の意味がなくなります。何を見るかについてはドッグフーディングの効果を測るで整理しています。

手順7: 判断日に結論を出す

判断日には、記録と数字を並べて結論を出します。出す結論は三つのいずれかです。

• 続ける：対象業務を広げるか、次の課題に取り組む
• 作り直す：設計の前提が間違っていた箇所を特定し、やり直す範囲を決める
• やめる：このプロダクトを自社で使う必然性がないと判断し、外部の協力者による検証に切り替える

やめるという結論も正当な成果です。自社が典型的な利用者でない場合、無理に続けても判断を誤らせるだけです。その境界はドッグフーディングの限界と誤判断を参照してください。

始める前に決めることが結果を決める

ドッグフーディングの成否は、始めてからの努力より、始める前に決めた事柄で決まります。対象業務を一つに絞り、復旧手順を用意した上で旧ツールへの書き込みを止め、記録の経路を一つにし、言い出しにくさを仕組みで解消し、期間と判断日と基準を先に宣言する。この順序を守れば、少人数のチームでも検証として成立します。

自社プロダクトの検証設計や、Webシステム開発・開発チーム体制構築・内製化支援についてご相談がありましたら、お問い合わせからお気軽にご連絡ください。