ワークフローのステータスラベル：チームで共有できる7つの明確なステータス

なぜ曖昧なステータスが作業を遅くするのか

曖昧なワークフローステータスラベルは、忙しそうに見えるだけの混乱を生みます。人はアイテムを先に進めますが、実際に何が変わったのか誰も確信が持てないことが多いです。チケットが「作業中」とマークされていても、担当者によって「考え始めただけ」「何かで止まっている」「レビュー待ちで完了している」と意味が変わることがあります。

そのミスマッチが生む問題は三つに集約できます：やり直し、見落とされた引き継ぎ、そして通知のノイズです。ステータスが次の人に何をすべきか伝えなければ、作業は行ったり来たりします。引き継ぎが曖昧なラベルに埋もれていれば、誰かが気づくまで放置されます。全員が単に活動を“示す”ためにステータスを更新すると、フィードはぼやけて重要な変更が見えにくくなります。

別のよくある症状は、同じラベルが画面ごとに違う使われ方をしていることです。あるチームメンバーは「Ready」を「レビュー準備完了」と解釈し、別の人は「Ready」を「着手可能」と使うかもしれません。マネージャーがボードを見ても、チームが待っているのか作業中なのか終わっているのか判断できません。

目的はすべての例外を説明することではありません。普通の流れを少ないステータスで明確にすることが目標です。ステータスがどこでも一貫していれば、引き継ぎは速くなり、「これ本当に終わってる？」といった質問が減ります。

どこから始めればよいかわからないチームは、まず5〜7個のステータスを目標にしてください：新規、作業中、待ち／ブロック、人による確認／承認、完了、という基本をカバーします。基礎が安定して全員が同じ意味で使えるようになってから詳細を追加しましょう。

ステータスラベルが意味すべきこと（と意味すべきでないこと）

ステータスラベルは、次に何が起きるかについての共通の約束です。誰かがステータスを変えたら、フォローアップの質問なしに次のステップが予測できるべきです。

良いワークフローステータスは、主観的な意見ではなく作業の現状を示します。ラベルが真実であれば、チームはアイテムが動いているのか待っているのかブロックされているのか、そして次に誰が触るべきかを判断できます。

ステータスは優先度、担当者、カテゴリ、進捗メモと同じものではありません。これらのフィールドは重要ですが、ステータスに混ぜると信頼できないものになります。

また「状態（state）」と「段階（stage）」を分けて考えると便利です。状態は今何が真実か（例：「顧客の返信待ちでブロックされている」）、段階はプロセス上どこにあるか（例：「レビュー」）を指します。混ぜることはできますが、1つのステータスで両方を説明しようとすると曖昧になりがちです。

有用なステータスは次のいずれかを引き起こすべきです：

• 次の担当者（誰が引き継ぐか）
• 次のアクション（何をするか）
• 待機条件（何を待っているか）

簡単な現実チェック：小さい一覧表示でラベルを読んでも次に何をするか分かりますか？答えが「場合による」なら、そのラベルは決定を隠しており、優先度や割り当てなど別の場所で決めるべきことです。

いくつのステータスを使うべきか、なぜ5〜7が適切か

ステータスシステムは、一目で作業が読みやすくなることが目的です。ステータスが多すぎると、人は表示を信用しなくなります。少なすぎると引き継ぎを管理するのに必要な詳細が失われます。

ほとんどのチームでは、5〜7個がちょうど良いバランスです。1画面に収まり、カンバンボードやシンプルな一覧表示でも扱いやすく、日常の質問（何がブロックされているか、何が作業中か、何がレビュー待ちか）に答えられる信号を与えます。

セットを小さく保つことで「どの12個の中から近いものを探すか」という“ステータス探し”が減り、報告も簡単になり、優先度・担当者・タイプを別フィールドに保つ設計を強制できます。

名称はチームごとに異なって構いません。一方が「In Progress」と呼び、別のチームが「Doing」と呼ぶこともあります。変えられないのは意味です。「In Review」が時に「QA待ち」を意味し、別の場合に「顧客待ち」を意味するなら、ボードはノイズになります。

意味を一貫させるために、1つの権威ある参照を作りましょう：各ステータスの意味とその状態に入る／出るルールを短く書いたチームドキュメントです。2分で読めるくらい短く保ち、その同じステータスを全ての表示で使ってください。

すぐに使えるシンプルな7ステータスセット

明確なワークフローステータスを長く保ちたいなら、まずは「今誰が担当か」「次に何が起きるか」「完了がどう見えるか」に答える小さなセットから始めます。

多くのチームで使いやすいシンプルな7ステータスは次の通りです。

重要ルール：単に「Waiting」とだけ書かないこと。止まっている場合は「Blocked」と書き、ノートに依存内容を明確にしてください（例: “Blocked: customer reply” や “Blocked: access granted”）。

各ステータスの定義（入出条件付き）

明確なワークフローステータスは各ラベルが「今何が真実か」を答えるときに最も有効です。

新規

何が真実か：アイテムは記録されたが、まだ誰も評価していない。

何が真実でないか：優先度、スコープ、担当が合意されているわけではない。

入る条件：リクエストが提出されたとき。

出る条件：誰かが読んでトリアージ済みに移すこと。

例：「サポート担当がスクリーンショット付きでバグを登録する。」

トリアージ済み

何が真実か：チームがリクエストをルーティングし、有効性を確認できている。

何が真実でないか：作業開始の準備ができているわけではない。

入る条件：誰かが基本的なコンテキスト（要約、影響、影響範囲）を追加したとき。

出る条件：作業準備が整えば「準備完了」に、あるいはワークフロー外で処理するため却下される（ステータスとしては扱わない）。

例：「PMが実際のバグとしてマークし、再現手順を記載する。」

準備完了

何が真実か：必要な情報や依存が揃っていて着手できる。

何が真実でないか：作業が開始されているわけではない。

入る条件：受け入れ基準が明確で、依存関係が整っている。

出る条件：誰かが着手して最初の意味ある変更を行う（進行中）。

例：「フォームのフィールドとバリデーションルールが合意された。」

進行中

何が真実か：能動的な作業が行われている。

何が真実でないか：キューで待っている状態ではない。

入る条件：誰かが取り掛かり作業を始めたとき。

出る条件：チェック可能な状態になったらレビュー中へ、依存にぶつかったらブロックへ。

例：「開発者が新しいステータスドロップダウンを実装してロジックを保存する。」

レビュー中

何が真実か：ピアレビュー、QA、ステークホルダー承認などで確認されている。

何が真実でないか：新機能がまだ追加されている状態ではない。

入る条件：実装者が検証のために提出したとき。

出る条件：チームの合意した定義を満たして承認されれば完了へ、フィードバックがあれば進行中へ戻る。

例：「QAがWebとモバイル両方で動作を確認する。」

ブロック

何が真実か：特定の、名前の付いた依存により作業を継続できない。

何が真実でないか：単に優先度が低いわけではない。

入る条件：担当者が自分で解決できない依存に直面したとき。

出る条件：依存が除去され作業が再開される（通常は進行中）。

例：「Blocked: production logs へのアクセス待ち。」

完了

何が真実か：合意した受け入れ基準を満たし、出荷済みまたは出荷準備が整っている。

何が真実でないか：まだレビューやテスト、フォローアップが必要な状態ではない。

入る条件：レビューが通り、リリース手順が完了したとき（チーム定義による）。

出る条件：なし。再オープンは新しい理由を添えて別サイクルとして開始する。

例：「修正が本番反映され、バグが再現しなくなった。」

ステップバイステップ：60分でステータスシステムを作る

1回の集中したミーティングで混乱したステータスは改善できます。目的は完璧なモデルではなく、実際の動きに合ったラベルセットと繰り返し使えるルールを共有することです。

60分のワークセッション（結果は1つ）

作業に関わる各役割から1人ずつ（リクエスター、実行者、レビュアー、承認者）を集め、現在のボードや一覧を画面共有します。

まず、理想ではなく実際のワークフローをマッピングします。典型的なアイテムを1つ選び、実際に何が起きたか（待ち時間も含む）を追跡します。ステップは動詞で書き出します（「下書き」「レビュー」「承認」など）。稀にしか起きないステップは枝分かれとしてメモします。

次に重複を取り除き、不明確なラベルをリネームします。同じ意味のラベル（「In Progress」対「Doing」）は統合します。「Pending」のような曖昧なものは「Blocked: customer reply」のように行動できる文言に変えます。1文で説明できないラベルは使えません。

その後、入出条件を各ステータスに書きます。各ステータスについて「入るには何が必要か」「出るには何が必要か」を短く書いてください。例：「レビュー中は作業者が提出したときに入る。レビューで承認されフィードバックが解決されれば完了に出る。」

次に各引き継ぎの担当を決めます。各ステータスにデフォルトの担当（役割で可）を設定すると、アイテムが停滞しにくくなります。例：レビュー中のアイテムは実行者ではなくレビュアーが所有します。

最後に過去10件でテストして調整します。過去数週間の完了またはアクティブなアイテムを10件取り出し、それぞれについて各時点でどのステータスになるかを割り当てます。しばしば議論になるならラベルが重複しています。配置できないアイテムがあればステータスが不足しているか、二つの概念を混ぜています。

ミーティング後は定義を1ヶ所に公開し、表示されるすべての場所でラベルを一致させてください。

Web と モバイルでステータスを一貫させる

Webでの意味とモバイルでの意味が少しでも違うと、人は信頼しなくなります。チャットで確認したり、詳細を再チェックしたり、自分用の"本当のステータス"をコメントに作り始めます。ワークフローステータスは装飾ではなく共有の事実であるべきです。

ステータスは一つの共有フィールドとして扱い、ひとつの真実のソースを持ってください。綴りや大文字小文字、意味はすべての表示（一覧、詳細画面、通知、エクスポート、プッシュメッセージ）で同じにします。

実際に効く小画面ルール

モバイル画面は長い名前や弱い視覚設計に厳しいです。デスクトップのテーブルで問題ないステータスが、スマホでは切れて意味不明なバッジになることがあります。

• 名前は短く（可能なら1〜2語）する。
• 色は一貫して使うが、色だけに頼らない。
• 最長ラベルを想定して設計し、切れて読めなくならないようにする。
• プラットフォーム間で順序を揃える。
• 「In Progress」と「Working」のようなほぼ同じラベルは避け、一つに統一する。

配置も重要です。詳細ビューではタイトルの近くにステータスを置き、説明を読む前に目に入るようにします。一覧ビューでは毎回同じ位置に表示してください。

アクセシビリティの基本は誰にとっても有益です。色はヒントであってメッセージではありません。常にテキストラベルを表示し、チェックアイコンのようなシンプルなアイコンを付けるとスクリーンリーダーを使う人や色覚に問題のある人にも伝わりやすくなります。

ステータスがずれていくよくある間違い

ステータスは「作業がどこにあるか」ではなく「人の感情」を表すようになるとドリフトします。そうなるとボードは忙しく見えますが信頼できなくなります。

よくある原因の一つは、細かすぎるステップに合わせたラベルが多すぎることです。タスクが1時間に3回動くような場合、人は更新を止めるか「近いもの」を選ぶようになります。重要なのは、各移動が実際に準備状況や責任を変えるときだけ行われることです。

別のドリフト要因は異なる次元を一つのフィールドに混ぜることです。優先度や緊急度は重要ですが、ステータスではなく別のフィールドに置くべきです。「Urgent」をステータスにすると「In Review」と競合し、報告が意味をなさなくなります。

次のパターンに注意してください：

• 明確な違いのない複数の「完了に近い」ラベル
• 個人用のワンオフラベル（「Sam待ち」）
• 「In Progress」が駐車場化している
• 入出条件の文書がない
• 新しい画面が違うステータス名や順序を表示する

ドリフトを防ぐには、ステータスセットに1人のオーナーを決め、変更は稀にします。変更するときは何が、なぜ、何に置き換わるのかを書き残してください。

例：あるリクエストの開始から完了まで

顧客がサポートに「モバイルの注文履歴ページが注文があるのに空の状態を表示する」と書きます。サポートはそれをプロダクト修正としてログに残し、リリースにつなげます。

新規：サポートがスクリーンショット、端末情報、正しい表示の期待値を記録する。

トリアージ済み：プロダクトオーナーが実際のバグと判断し、対象（モバイルアプリ、バックエンドではない）と影響を明確にする。

準備完了：再現手順が確認され、受け入れ基準が明確になっている。

進行中：エンジニアが問題を再現し、APIはデータを返すが画面が誤ってフィルタしていることを見つけ修正に着手する。

ブロック：エンジニアが古いアカウントに欠けているフィールドに依存していることを発見し、バックエンド変更が必要になる。チケットは「Blocked: backend needs legacy field mapping」と明記される。

レビュー中：依存が解決した後、QAがiOSとAndroidで空状態が正しく表示されることを確認する。

完了：修正が承認されリリースされる（チームによっては次リリース枠に入れるのも完了とする）。サポートが本番確認して顧客に返信する。

混乱を防ぐ要因は明確です：「Blocked」には一つの理由と一つの次アクションがあり、所有権が飛び回らないこと。誰がボールを持っているかがアイテムを開けば分かります。

チームで一貫性を保つためのクイックチェックリスト

ボードが乱れていると感じたら、10分で原因を見つけられることが多いです。

10分ボードスキャン

ボードを見て次の点を確認してください：

• 各ステータスは「今何が真実か」に答えているか
• 各ステータスにデフォルト担当（役割で可）と明確な次アクションがあるか
• 同じアイテムを同時に説明できる2つのステータスがないか
• アイテムが判断ポイントなしで放置されていないか（何日も止まるなら出口ルールを追加）
• 同じ種類の作業は同じコアステップを通るか（例外は文書化されているか）

カードの置き場所で意見が分かれるなら、そのステータスは別のものと重複しているか、十分に定義されていません。

Web + モバイル一貫性チェック

同じワークフローをスマホで開き、ラベルが小さなスペースでも機能するか確認します。

• ラベルは一覧で短く読みやすいか（切れていないか）
• 色に頼らずテキストだけで意味が伝わるか
• ステータス変更はチームリードや運用が承認する一人のオーナーが管理しているか
• 変更には短い注記がついて定義がずれないようにしているか

次のステップ：維持・測定・継続的改善

ステータスシステムはルールブックのように扱うと有用性が保てます：安定しているが定期的に見直す。目的は頻繁な変更ではなく、一貫した運用です。

軽めのペースを決めましょう。たとえば月に30分、ボードに関わる各役割から1人が集まり5〜10件の最近のアイテムを持ち寄って例外を見つけ修正します。

追跡する価値のあるシンプルな指標：

• Blocked に費やされた時間（上位理由）
• 2つのステータス間を行ったり来たりするアイテム数
• 通常のサイクル時間を超えて放置されたアイテム

何か違和感があったら、すぐに新しいステータスを追加するのは避けてください。新しい状態は本当に次に何を変えるのか、頻繁に起きるのかで判断します。多くの場合、定義を絞る、入出条件を追加する、所有権を明確にすることで十分です。

もし内部ツールにワークフローを組み込むなら、ステータスを画面固有の文言ではなく共有データとして扱ってください。たとえば AppMaster（appmaster.io）では、Data Designer で一度ステータスフィールドを定義すれば Web とネイティブアプリで再利用でき、モバイルで意味が変わる問題を減らせます。