今日の種記事 いつもながらしんぺいさんは面白い種をくれる
nekogata.hatenablog.com
この記事で僕が引っかかったのは次の部分
「機能」は「できた」「できなかった」の二値なのだけれど、ユーザーストーリーは「めちゃめちゃ実現できた」「おおよそ実現できた」「少し実現できた」などのグラデーションがある、という見方はどうだろうか。
「機能」は「できた」「できなかった」の二値、ということは本当に真なのか？真だとすればそれは何によってか？ということを考えてみると、そこには『目標の到達度』の認識に混乱をもたらす『状態目標が隠された行動目標』という概念を言語化できた。
目標の到達度
目標は大きく行動目標と状態目標に分けられる。この違いは何をもって目標に到達したとするかによる。
- 行動目標: ある行動ができたときに到達する
- 状態目標: ある状態になったときに到達する
目標は到達することが目的である限り、つねに「到達したかどうか」を評価される。そしてその評価は少なくとも「到達した」「到達していない」の2値で評価可能である。この評価すらできないならば永遠に到達不可能なので、そのような目標は目標として存在しえない。
そして目標への到達度合いを、2値よりも小さな単位で段階的に評価したいという欲求から、到達度の定量的な計測が試みられる。
どのような目標であっても、その到達度が表すのは「目標までの距離が、スタート地点からと比べてどれほど短くなったか」であるはずだ。
さて、行動目標における到達度は、その工程の進行度合い（進捗度合い）であるはずだ。
その行動ができるまでに必要な工程のどれだけの割合を完了しているか、それは工程の個数ベースの割合もあれば、労力の負荷ベースの割合もありえる（登山と同じ）。
どのような基準にせよ、行動目標において段階的な到達度の評価には、工程の分解が必須である。
一方で、状態目標における到達度は、その状態をなんらかの指標で定量化した比較評価である。
したがって、状態目標において段階的な到達度の評価には、中間状態を評価できる指標を持つことが必須である。
行動目標ができた・できてないでしか評価されないのはなぜか
ある目標が真に行動目標なのであれば、上述のとおり工程の進行度で評価できるはずである。
逆にいえば、行動目標であるのに到達度が測れないときに考えられる要因は次の2つだけである。
- 工程がそれ以上分解されない場合
- 形式上は行動目標であるが、裏に暗黙的な状態目標がある場合
1. 工程がそれ以上分解されない場合
その行動が複数の工程に分解されていないなら、その行動目標の評価はできた・できてないの2値が限界であるのは当然である。
行動が複数の工程に分解されていない理由は、もはや分解できない最小の単位であるか、分解を怠っているかのどちらかであろう。
2. 形式上は行動目標であるが、裏に暗黙的な状態目標がある場合
形式上は行動目標であるが、裏に「その行動がなされた後に実現されるであろう状態」になることが暗黙的な状態目標としておかれている場合には、その行動目標の評価はできた・できてないの2値になってしまうことが考えられる。
なぜなら、その行動目標のための工程がどれだけ進んだとしても、「隠された状態目標」側の指標で評価すれば到達度が変わっていないことがありえる。
そのようにして最後まで中間状態が変化しないような工程を組んだ場合には、行動目標の到達と同時に状態目標が到達することになり、結果的に2値での評価となる。
つまり、本当は行動目標ではないために、行動目標としては到達度をあらわすはずの工程の進行度が、隠された状態目標としては無価値となるという現象が起きえる。
状態目標が隠された行動目標
そのような、『状態目標が隠された行動目標』は、いわば手段が目的化した目標であるとも捉えられる。
なぜなら、本当は状態を目標としているはずなのに、それを達成する手段のほうを形式上は目標としてしまっている。
このことによって、異なる手段を選ぶ余地を自ら閉ざしていることになる。
ただし、『状態目標が隠された行動目標』であったとしても、到達度を段階的に上げることはできる。
なぜなら、『状態目標が隠された行動目標』の到達度が2値になるのは、そのような工程を組んだことによる結果であるからだ。
状態目標が隠されていたとしても、工程の途中段階で中間状態が変わっていくのなら、到達度は行動目標としても状態目標としても段階的に評価できる。
2値になってしまうのは、工程の進行段階で状態に変化がなかったために、最後まで0から動かなかっただけである。
『状態目標が隠された行動目標』からみる機能開発とユーザーストーリー
ようやく冒頭の話題に戻ってきた。
まず、「ある機能を開発してリリースする」という機能開発は明らかに行動目標である。
そして いわゆるユーザーストーリーは「誰々をどのような状態にしたい」ということから明らかに状態目標である。
この整理と上述の『状態目標が隠された行動目標』から、冒頭の問いを解いてみよう。
「機能」は「できた」「できなかった」の二値なのだけれど、ユーザーストーリーは「めちゃめちゃ実現できた」「おおよそ実現できた」「少し実現できた」などのグラデーションがある、という見方はどうだろうか。
機能開発はリリースできたかどうかというのが基本の到達度評価であるが、上述のとおり行動目標であれば到達度は工程の進捗度によって段階的に評価できるはずだ。
ということは、機能開発をいくつもの工程に分解し、進行しているにもかかわらずその到達度を0とするなら、それは裏に隠された状態目標があるとしか考えられない。
そして多くの場合で、機能開発はそのリリースによる効果や価値を見込んでいるのであって、ほぼ間違いなく裏に状態目標がある。
つまり、機能開発という行動目標は間違いなく『状態目標が隠された行動目標』である。
このような場合、プロダクトマネージャーの心中ではユーザーストーリーという状態目標があるにもかかわらず、開発者は機能開発という行動目標を追跡するような認識のすれちがいが起こりうる。
それは状態目標として評価する人と、行動目標として評価する人は、物事を異なって評価しているためであり、「進捗しているのに評価されない」と「時間をかけているのに変化がない」が両立する。
また、『状態目標が隠された行動目標』は形式上は行動目標となっているため、工程を途中で見直すということは行動目標として到達度を下げる行為になり、負のインセンティブがある。
しかし状態目標としてはよりよい手段を選択しただけであるため、到達度に変化はない。この点でも物事の見方が大きく変わってしまう。
ところで、なぜ到達度を段階的に評価したいのかといえば、連続的な到達度の変化を追跡することで到達するまでの時間やコストの予測ができるからだ。
つまり、到達度の推移を分析することで見積もりの精度を高めようとしている。
コストやスケジュールなどのトレードオフを考え、計画を立てるにあたって必要とされているから到達度が2値では困るのだ。
そのことを踏まえると、『状態目標が隠された行動目標』というのは解消すべき問題であるといえる。
この問題を解消する方法は2つしかない。「真の行動目標にする」か「状態目標に置き直す」かのどちらかだ。
『状態目標が隠された行動目標』を本当に行動目標にするということは、工程の進捗度を到達度として評価することだ。
まだリリースされていないが、確実に工程は進んでいる。そのことを評価基準とすることを選ぶなら、真に行動目標となる。
しかし多くのプロダクト開発、サービス開発では、結局ユーザーにどれだけ影響があったのか？ビジネス上の効果があったのか？ということを問わずにいられないだろう。
したがって、この方法は現実的には選択できない。
残された方法は、『状態目標が隠された行動目標』を明確に状態目標であると置き直すのである。
状態目標であることが明らかになることで、工程がどれだけ進捗していてもそれだけでは価値がないことが明確になる。
そうすると、段階的に状態が変わるような工程を組まなければならないことが目標を共有する人々の間で共通の認識になる。
世にいうアジャイルな開発というのは、そのような認識を共有していることが前提となっているのではないだろうか。
到達度を上げるためには状態を変えなければならないので、リリースをなるべく早く行おうという力学が働く。
リリースを早く行うためには、小さな単位でリリースしようとする。
小さくリリースするたびに中間状態を評価し、工程が最適ではないなら組み直す。
行動目標を追いかける立場としては「手戻り」としてリリースが遠のくため避けたい判断だが、状態目標を追いかける立場では最適な判断になる。
スコープ調整とは到達度のコミットメントを変更すること
このように考えれば、手段の「スコープ調整」を自然なものとして可能にするための条件は、前提となる目標が状態目標であることだと言えるのではないだろうか。
行動目標にとって手段とは工程であり、達成度そのものである。その上で「やることを変える」は工程を破壊する行為になってしまい負のインセンティブがはたらく。
冒頭のしんぺいさんの記事でも触れられている次の記事に書かれたことは、僕が言いたいことを別の視点から言っている。
mactkg.hateblo.jp
でもスクラムのスプリントゴールっていうのは多分そういうことなんだと思う。今のところこういう仕立てがいいと思うんですよね、とPBIを使ってPBLに表現されているけど、達成したいことはスプリントゴールに書いてあることである。スプリントゴールに書いてあることが達成できるんだったらこういう方法でもいいじゃん。という「スコープ調整」を毎日していくことがスクラムとかでやっていきたいことなんだろうなと思う。
スコープ調整とは何か、それは本来見込んでいた「このスプリントではここまでいける」という到達度のコミットメントを変更することだ。
したがって、行動目標であっても状態目標であっても、到達度が段階的なのであれば調整できる。当たり前だが、到達度が2値の目標について、到達度のコミットメントは調整できない。
たとえばスプリントゴールが「○○をリリースする」という行動目標だとすれば、それが間に合わないということはイコール到達できないことになる。その上で行われるスコープ調整とはリスケジュール以外にない。なぜなら「○○をリリースする」のが目標なのだから。ところが機能のリリースは『状態目標が隠された行動目標』なのであって、どれだけギリギリまで進捗していても状態目標としての到達度は0である。このようなスプリントで何が検査できて、何が学習できるだろうか。
達成したいことはスプリントゴールに書いてあること
つまり、この「達成したいこと」は段階的に到達度を評価可能な目標として書かれていなければならない。そしてそれは多くの場合、状態目標を書くべきなのである。
状態目標の到達度をコミットメントとするのなら、そのコミットメントさえ果たせるのなら手段をいかようにも変更可能になる。そして、そのコミットメントを果たすのが難しいとなったときに到達度を調整することができる。
コミットメントを維持した手段の可変性と、コミットメントのレベルの可変性（トレードオフスライダーに加えられるということ）、この2つを確保することが多くの場合で求められてるのであろう。
そして『状態目標が隠された行動目標』の二重性をそのままにすることが、それらを強く阻害しているのではないだろうか。
