プロダクトづくりでマネジメントするのは、「ステージ」か、「ステート」か
「ステージ」という言葉を比較的よく耳にする。「XXXステージを定義し、ステージの終わりにゲートを設けて、内容を審査する。ステージゲートでクオリティを担保しよう」みたいな話。
いにしえのソフトウェア開発でよくあった状況であるし、近年は事業開発の文脈でも、ステージゲート法が用いられることが多い。先に述べておくと、何も見ていないより、ステージゲートがあったほうが余程良い。ただし、"ステージ" という言葉に込められている暗黙的な傾向には注意したほうがよい。ステージは、「計画指向」を招きやすい。
"ステージ" で何を見て、何を担保したいのだろうか。あらかじめ組み立てられてた標準タスク群（要件定義、設計、テスト… もしくは、事業計画、事業準備、マーケティング…）を、まずもって抜け漏れなく実施できているか。そして、実施結果を適切に評価しているか。例えば、品質の高い、低いをどのように判断しているか、的を射るテストを行えているか、など、やるべきことをやっているか、に焦点があたる。測るモノサシは、標準規程などになる。
一方で、新規性の高いプロダクトづくり、事業開発を行うにあたっては、やるべきことをやっているか、だけでは評価ができない。標準とされるタスクを実行していれば、それで良し、とはならない。見るべき対象はあくまで、「結果」のほうになる。ユーザーに価値を感じてもらえるのか、顧客はサービスを購入するのか。望むべき「結果」が得られているか、または、それが期待できる「状態」（ステート）が得られているか。ここが焦点になる。
"ステージ" と "ステート"、似たような言葉だが、見えるべき焦点が異なる。ゆえに、マネジメントの観点も変わる。
紛らわしい概念になるが、この見分けがついていないと、プロダクトづくりにも関わらず、厳格なステージゲート運用を始めてしまいかねない。要件定義を綿密にやったところで、価値の検証にはならない…ということにも気付けない。そんなことある？ と思う方もいるかもしれないが、これも「これまでの仕事」観、その最適化によって、現実に起きている。
"ステージ" 指向か、"ステート" 指向か、本質を捉え損なっているかどうかは、「準備」フェーズを定義しているかどうかで判断できる。ステージの考え方だと、準備も重要な段階となり、審査の対象になる。ステートのほうでは、準備は（もちろん行うが）ゲート運用上の焦点にはならない。準備のゲートこそ、行うべきタスクがなされているか、のみ、見ることになる（実行のための「段取り」なのだから）。準備ゲートがあると、どういう認知のもとに組み立てられているかが分かる。
このステージとステートの考え方は、いにしえの書籍「適応型ソフトウェア開発」でジムハイスミスから教わった。いまだに、ジムハイスミス先生の教えは味わい深く、自分の身に刻まれている感覚がある。
タスクをどれだけこなしたかではなく、状態を見よう。状態の検査適応を行うために、アジャイルなプロダクトづくりをはじめよう。
この記事が気に入ったらサポートをしてみませんか？