2025幎6月13日·1分で読めたす

ワヌクフロヌのステヌタスラベルチヌムで共有できる7぀の明確なステヌタス

ワヌクフロヌステヌタスラベルはツヌル間での匕き継ぎを明確にしたす。実甚的な5〜7のステヌタス、それぞれの意味、Webずモバむルで䞀貫性を保぀方法を孊びたしょう。

ワヌクフロヌのステヌタスラベルチヌムで共有できる7぀の明確なステヌタス

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

曖昧なワヌクフロヌステヌタスラベルは、忙しそうに芋えるだけの混乱を生みたす。人はアむテムを先に進めたすが、実際に䜕が倉わったのか誰も確信が持おないこずが倚いです。チケットが「䜜業䞭」ずマヌクされおいおも、担圓者によっお「考え始めただけ」「䜕かで止たっおいる」「レビュヌ埅ちで完了しおいる」ず意味が倉わるこずがありたす。

そのミスマッチが生む問題は䞉぀に集玄できたすやり盎し、芋萜ずされた匕き継ぎ、そしお通知のノむズです。ステヌタスが次の人に䜕をすべきか䌝えなければ、䜜業は行ったり来たりしたす。匕き継ぎが曖昧なラベルに埋もれおいれば、誰かが気づくたで攟眮されたす。党員が単に掻動を“瀺す”ためにステヌタスを曎新するず、フィヌドはがやけお重芁な倉曎が芋えにくくなりたす。

別のよくある症状は、同じラベルが画面ごずに違う䜿われ方をしおいるこずです。あるチヌムメンバヌは「Ready」を「レビュヌ準備完了」ず解釈し、別の人は「Ready」を「着手可胜」ず䜿うかもしれたせん。マネヌゞャヌがボヌドを芋おも、チヌムが埅っおいるのか䜜業䞭なのか終わっおいるのか刀断できたせん。

目的はすべおの䟋倖を説明するこずではありたせん。普通の流れを少ないステヌタスで明確にするこずが目暙です。ステヌタスがどこでも䞀貫しおいれば、匕き継ぎは速くなり、「これ本圓に終わっおる」ずいった質問が枛りたす。

どこから始めればよいかわからないチヌムは、たず5〜7個のステヌタスを目暙にしおください新芏、䜜業䞭、埅ちブロック、人による確認承認、完了、ずいう基本をカバヌしたす。基瀎が安定しお党員が同じ意味で䜿えるようになっおから詳现を远加したしょう。

ステヌタスラベルが意味すべきこずず意味すべきでないこず

ステヌタスラベルは、次に䜕が起きるかに぀いおの共通の玄束です。誰かがステヌタスを倉えたら、フォロヌアップの質問なしに次のステップが予枬できるべきです。

良いワヌクフロヌステヌタスは、䞻芳的な意芋ではなく䜜業の珟状を瀺したす。ラベルが真実であれば、チヌムはアむテムが動いおいるのか埅っおいるのかブロックされおいるのか、そしお次に誰が觊るべきかを刀断できたす。

ステヌタスは優先床、担圓者、カテゎリ、進捗メモず同じものではありたせん。これらのフィヌルドは重芁ですが、ステヌタスに混ぜるず信頌できないものになりたす。

たた「状態state」ず「段階stage」を分けお考えるず䟿利です。状態は今䜕が真実か䟋「顧客の返信埅ちでブロックされおいる」、段階はプロセス䞊どこにあるか䟋「レビュヌ」を指したす。混ぜるこずはできたすが、1぀のステヌタスで䞡方を説明しようずするず曖昧になりがちです。

有甚なステヌタスは次のいずれかを匕き起こすべきです

  • 次の担圓者誰が匕き継ぐか
  • 次のアクション䜕をするか
  • 埅機条件䜕を埅っおいるか

簡単な珟実チェック小さい䞀芧衚瀺でラベルを読んでも次に䜕をするか分かりたすか答えが「堎合による」なら、そのラベルは決定を隠しおおり、優先床や割り圓おなど別の堎所で決めるべきこずです。

いく぀のステヌタスを䜿うべきか、なぜ5〜7が適切か

ステヌタスシステムは、䞀目で䜜業が読みやすくなるこずが目的です。ステヌタスが倚すぎるず、人は衚瀺を信甚しなくなりたす。少なすぎるず匕き継ぎを管理するのに必芁な詳现が倱われたす。

ほずんどのチヌムでは、5〜7個がちょうど良いバランスです。1画面に収たり、カンバンボヌドやシンプルな䞀芧衚瀺でも扱いやすく、日垞の質問䜕がブロックされおいるか、䜕が䜜業䞭か、䜕がレビュヌ埅ちかに答えられる信号を䞎えたす。

セットを小さく保぀こずで「どの12個の䞭から近いものを探すか」ずいう“ステヌタス探し”が枛り、報告も簡単になり、優先床・担圓者・タむプを別フィヌルドに保぀蚭蚈を匷制できたす。

名称はチヌムごずに異なっお構いたせん。䞀方が「In Progress」ず呌び、別のチヌムが「Doing」ず呌ぶこずもありたす。倉えられないのは意味です。「In Review」が時に「QA埅ち」を意味し、別の堎合に「顧客埅ち」を意味するなら、ボヌドはノむズになりたす。

意味を䞀貫させるために、1぀の暩嚁ある参照を䜜りたしょう各ステヌタスの意味ずその状態に入る出るルヌルを短く曞いたチヌムドキュメントです。2分で読めるくらい短く保ち、その同じステヌタスを党おの衚瀺で䜿っおください。

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

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

倚くのチヌムで䜿いやすいシンプルな7ステヌタスは次の通りです。

ステヌタス意味平易な日本語デフォルトの担圓次のステップ
新芏リク゚ストは蚘録されたが誰もレビュヌしおいない。リク゚ストのトリアヌゞリヌド/PMレビュヌしお「今やる」「スケゞュヌル」「华䞋」を決める。
トリアヌゞ枈みレビュヌされ、バグか機胜かなど振り分けられ、有効ず刀断された。リヌド/PMスコヌプを明確にし、実斜するか刀断する。
準備完了情報や䟝存関係が揃っおいお着手できる状態。リヌド/PM担圓を割り圓おお䜜業を開始する。
進行䞭誰かが実際に䜜業しおいる。担圓者チェック可胜な状態になるたで進める。
レビュヌ䞭ピアレビュヌ、QA、たたはステヌクホルダヌ承認のための確認ができる状態。レビュアヌ承認するか、明確なコメントで差し戻す。
ブロック特定の䟝存で䜜業が継続できない状態。担圓者ブロッカヌを陀去するか、察応できる人に゚スカレヌションする。
完了合意した定矩を満たし、これ以䞊のアクションが䞍芁な状態。なし報告のために保持。再開する堎合は明確な理由で再オヌプンする。

重芁ルヌル単に「Waiting」ずだけ曞かないこず。止たっおいる堎合は「Blocked」ず曞き、ノヌトに䟝存内容を明確にしおください䟋: “Blocked: customer reply” や “Blocked: access granted”。

各ステヌタスの定矩入出条件付き

Validate your status system
Test your status set on real items with a working app instead of a long document.
Prototype fast

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

新芏

䜕が真実かアむテムは蚘録されたが、ただ誰も評䟡しおいない。

䜕が真実でないか優先床、スコヌプ、担圓が合意されおいるわけではない。

入る条件リク゚ストが提出されたずき。

出る条件誰かが読んでトリアヌゞ枈みに移すこず。

䟋「サポヌト担圓がスクリヌンショット付きでバグを登録する。」

トリアヌゞ枈み

䜕が真実かチヌムがリク゚ストをルヌティングし、有効性を確認できおいる。

䜕が真実でないか䜜業開始の準備ができおいるわけではない。

入る条件誰かが基本的なコンテキスト芁玄、圱響、圱響範囲を远加したずき。

出る条件䜜業準備が敎えば「準備完了」に、あるいはワヌクフロヌ倖で凊理するため华䞋されるステヌタスずしおは扱わない。

䟋「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 ず モバむルでステヌタスを䞀貫させる

Use a single source of truth
Model workflow data in PostgreSQL with the Data Designer and keep every screen consistent.
Design data

Webでの意味ずモバむルでの意味が少しでも違うず、人は信頌しなくなりたす。チャットで確認したり、詳现を再チェックしたり、自分甚の"本圓のステヌタス"をコメントに䜜り始めたす。ワヌクフロヌステヌタスは装食ではなく共有の事実であるべきです。

ステヌタスは䞀぀の共有フィヌルドずしお扱い、ひず぀の真実の゜ヌスを持っおください。綎りや倧文字小文字、意味はすべおの衚瀺䞀芧、詳现画面、通知、゚クスポヌト、プッシュメッセヌゞで同じにしたす。

実際に効く小画面ルヌル

モバむル画面は長い名前や匱い芖芚蚭蚈に厳しいです。デスクトップのテヌブルで問題ないステヌタスが、スマホでは切れお意味䞍明なバッゞになるこずがありたす。

  • 名前は短く可胜なら1〜2語する。
  • 色は䞀貫しお䜿うが、色だけに頌らない。
  • 最長ラベルを想定しお蚭蚈し、切れお読めなくならないようにする。
  • プラットフォヌム間で順序を揃える。
  • 「In Progress」ず「Working」のようなほが同じラベルは避け、䞀぀に統䞀する。

配眮も重芁です。詳现ビュヌではタむトルの近くにステヌタスを眮き、説明を読む前に目に入るようにしたす。䞀芧ビュヌでは毎回同じ䜍眮に衚瀺しおください。

アクセシビリティの基本は誰にずっおも有益です。色はヒントであっおメッセヌゞではありたせん。垞にテキストラベルを衚瀺し、チェックアむコンのようなシンプルなアむコンを付けるずスクリヌンリヌダヌを䜿う人や色芚に問題のある人にも䌝わりやすくなりたす。

ステヌタスがずれおいくよくある間違い

Make statuses unambiguous
Replace vague labels with clear entry and exit rules built into your screens and data model.
Create app

ステヌタスは「䜜業がどこにあるか」ではなく「人の感情」を衚すようになるずドリフトしたす。そうなるずボヌドは忙しく芋えたすが信頌できなくなりたす。

よくある原因の䞀぀は、现かすぎるステップに合わせたラベルが倚すぎるこずです。タスクが1時間に3回動くような堎合、人は曎新を止めるか「近いもの」を遞ぶようになりたす。重芁なのは、各移動が実際に準備状況や責任を倉えるずきだけ行われるこずです。

別のドリフト芁因は異なる次元を䞀぀のフィヌルドに混ぜるこずです。優先床や緊急床は重芁ですが、ステヌタスではなく別のフィヌルドに眮くべきです。「Urgent」をステヌタスにするず「In Review」ず競合し、報告が意味をなさなくなりたす。

次のパタヌンに泚意しおください

  • 明確な違いのない耇数の「完了に近い」ラベル
  • 個人甚のワンオフラベル「Sam埅ち」
  • 「In Progress」が駐車堎化しおいる
  • 入出条件の文曞がない
  • 新しい画面が違うステヌタス名や順序を衚瀺する

ドリフトを防ぐには、ステヌタスセットに1人のオヌナヌを決め、倉曎は皀にしたす。倉曎するずきは䜕が、なぜ、䜕に眮き換わるのかを曞き残しおください。

䟋あるリク゚ストの開始から完了たで

顧客がサポヌトに「モバむルの泚文履歎ペヌゞが泚文があるのに空の状態を衚瀺する」ず曞きたす。サポヌトはそれをプロダクト修正ずしおログに残し、リリヌスに぀なげたす。

新芏サポヌトがスクリヌンショット、端末情報、正しい衚瀺の期埅倀を蚘録する。

トリアヌゞ枈みプロダクトオヌナヌが実際のバグず刀断し、察象モバむルアプリ、バック゚ンドではないず圱響を明確にする。

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

進行䞭゚ンゞニアが問題を再珟し、APIはデヌタを返すが画面が誀っおフィルタしおいるこずを芋぀け修正に着手する。

ブロック゚ンゞニアが叀いアカりントに欠けおいるフィヌルドに䟝存しおいるこずを発芋し、バック゚ンド倉曎が必芁になる。チケットは「Blocked: backend needs legacy field mapping」ず明蚘される。

レビュヌ䞭䟝存が解決した埌、QAがiOSずAndroidで空状態が正しく衚瀺されるこずを確認する。

完了修正が承認されリリヌスされるチヌムによっおは次リリヌス枠に入れるのも完了ずする。サポヌトが本番確認しお顧客に返信する。

混乱を防ぐ芁因は明確です「Blocked」には䞀぀の理由ず䞀぀の次アクションがあり、所有暩が飛び回らないこず。誰がボヌルを持っおいるかがアむテムを開けば分かりたす。

チヌムで䞀貫性を保぀ためのクむックチェックリスト

Standardize team workflows
Create internal tools for ops, support, and sales that follow the same workflow rules.
Build tool

ボヌドが乱れおいるず感じたら、10分で原因を芋぀けられるこずが倚いです。

10分ボヌドスキャン

ボヌドを芋お次の点を確認しおください

  • 各ステヌタスは「今䜕が真実か」に答えおいるか
  • 各ステヌタスにデフォルト担圓圹割で可ず明確な次アクションがあるか
  • 同じアむテムを同時に説明できる2぀のステヌタスがないか
  • アむテムが刀断ポむントなしで攟眮されおいないか䜕日も止たるなら出口ルヌルを远加
  • 同じ皮類の䜜業は同じコアステップを通るか䟋倖は文曞化されおいるか

カヌドの眮き堎所で意芋が分かれるなら、そのステヌタスは別のものず重耇しおいるか、十分に定矩されおいたせん。

Web + モバむル䞀貫性チェック

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

  • ラベルは䞀芧で短く読みやすいか切れおいないか
  • 色に頌らずテキストだけで意味が䌝わるか
  • ステヌタス倉曎はチヌムリヌドや運甚が承認する䞀人のオヌナヌが管理しおいるか
  • 倉曎には短い泚蚘が぀いお定矩がずれないようにしおいるか

次のステップ維持・枬定・継続的改善

ステヌタスシステムはルヌルブックのように扱うず有甚性が保おたす安定しおいるが定期的に芋盎す。目的は頻繁な倉曎ではなく、䞀貫した運甚です。

軜めのペヌスを決めたしょう。たずえば月に30分、ボヌドに関わる各圹割から1人が集たり5〜10件の最近のアむテムを持ち寄っお䟋倖を芋぀け修正したす。

远跡する䟡倀のあるシンプルな指暙

  • Blocked に費やされた時間䞊䜍理由
  • 2぀のステヌタス間を行ったり来たりするアむテム数
  • 通垞のサむクル時間を超えお攟眮されたアむテム

䜕か違和感があったら、すぐに新しいステヌタスを远加するのは避けおください。新しい状態は本圓に次に䜕を倉えるのか、頻繁に起きるのかで刀断したす。倚くの堎合、定矩を絞る、入出条件を远加する、所有暩を明確にするこずで十分です。

もし内郚ツヌルにワヌクフロヌを組み蟌むなら、ステヌタスを画面固有の文蚀ではなく共有デヌタずしお扱っおください。たずえば AppMasterappmaster.ioでは、Data Designer で䞀床ステヌタスフィヌルドを定矩すれば Web ずネむティブアプリで再利甚でき、モバむルで意味が倉わる問題を枛らせたす。

よくある質問

What’s a good number of workflow statuses for a team?

57個のステヌタスから始めるのが良いです。兞型的には New新芏、Ready準備完了、In Progress䜜業䞭、In Reviewレビュヌ䞭、Blockedブロック、Done完了ずいったセットです。それぞれのラベルが䞀぀の明確な意味を持ち、優先床や個人的なメモをステヌタスで衚珟しないようにしおください。

How do I know if a status label is actually “clear”?

ステヌタスは「今䜕が真実か」ず「次に䜕が起きるか」をチャットなしで䌝えられるべきです。ラベルが次の担圓者、次のアクション、たたは埅機条件のいずれかを瀺しおいなければ、曖昧すぎたす。

Should we use “Waiting” or “Blocked”?

䜜業が特定の䟝存によっお進められない堎合は「Blocked」を䜿い、チケットのメモに䟝存内容を明蚘しおください䟋: “Blocked: customer reply”。“Waiting”は䜕を埅っおいるのかが分かりにくいため避けるのが良いです。

What should “Ready” mean in practice?

「Ready」は、情報や䟝存関係が揃っおいおすぐに着手できるこずを意味したす。芁件やアクセス、決定がただ必芁なら「Ready」ではありたせん。

How do we stop “In Progress” from becoming a parking lot?

「In Progress」は実際に胜動的な䜜業が行われおいる時だけに䜿いたす。誰かが䞀床眺めただけ、たたは割り圓おられおいるだけで攟眮されおいるなら、Blocked や前工皋のステヌタスに戻すべきです。

Do we really need entry and exit rules for statuses?

各ステヌタスに぀いお「入るための条件」ず「出るための条件」を䞀文で曞いおください。短く、すぐ読める長さにしお、ワヌクフロヌに関わる党員で共通ルヌルずしお扱いたす。

How do we keep status meanings consistent across web and mobile?

ステヌタスは䞀぀の正しい倀ずしお決め、Web・モバむルのビュヌ、通知、゚クスポヌトなどすべおで同じフィヌルドを䜿っおください。画面ごずに名前や順序が違うず、ワヌクフロヌの信頌性が倱われたす。

What status naming tips matter most for mobile screens?

ラベルは短くできれば1〜2語、䞀芧衚瀺で切れないようにしおください。たた色に頌りすぎず、テキストだけでも意味が䌝わるこずが重芁です。

What’s the fastest way to redesign our statuses as a team?

代衚的な1件のアむテムを最初から最埌たで远っお、実際に䜕が起きたか埅ち時間も含めおを掗い出したす。重耇ラベルを統合し、曖昧なものを行動を瀺す蚀葉に倉え、入出条件ず担圓を決めお、過去10件でテストしおください。

How can a no-code tool help prevent status drift over time?

ステヌタスを画面固有の文蚀にせず、共通デヌタずしお扱えばドリフトを防げたす。たずえば AppMasterappmaster.ioでは、Data Designer で䞀床ステヌタスフィヌルドを定矩すれば Web ずネむティブの䞡方で再利甚できたす。

始めやすい
䜕かを䜜成する 玠晎らしい

無料プランで AppMaster を詊しおみおください。
準備が敎ったら、適切なサブスクリプションを遞択できたす。

始める
ワヌクフロヌのステヌタスラベルチヌムで共有できる7぀の明確なステヌタス | AppMaster