ソフトウェアの「真の2割の価値」を可視化して見つけ出す方法
前回に続いて『スクラム 仕事が４倍速くなる“世界標準”のチーム戦術』を読んで、この概念・考え方はプ譜で表現できそうと感じたものをこのnoteに書いておきます。
今回は、同書に書かれていた「ソフトウェアの価値の8割は2割の機能に含まれる法則」をプ譜で表現してみます。
同書には以下のような記述があります。
ソフトウェア開発の世界には、それまでの研究から生まれた法則がある。
「あるソフトウェアの価値の八割は二割の機能に含まれる」というものだ。
お金を出してものを買う際、その価値の大部分、言い換えれば買う人がその製品に求める価値なり機能なりの大部分は、その製品全体の五分の一に収まってしまうということになる。
スクラム以前の製品開発のやり方では、この大事な二割が何なのかは完成した製品を市場に出すまでわからない。あとの八割に費やした労力は無駄になる。製品をインクリメンタル (段階的)に開発しリリースしていくスクラムでは、すぐに利益につながる部分を最初に形にすれば、早い段階でプロジェクトのリスクを減らせる。
競合相手よりも五倍の速さで五倍の価値がある商品を市場に出せたら? まさに勝利への方程式だ。
こりゃいいものです。その2割を見つけるための方法を教えてください。
「要求事項は1,100項目に上りました。書類の厚さは10センチ近くになりました」 ジェフ・ ジョンソンは振り返る。
（中略）
そんなわけで文書の山ができたあと、二人は全体に目を通し、それぞれの要求事項に優先順位をつけていった。絶対にはずせないくらい重要で、意外と手こずるものは何か。よく、どれも全部重要だと答えが返ってくることがある。だが追求すべきなのは、プロジェクトに最大の価値をもたらすものは何か、だった。それを最初にやるのだ。ソフトウェア開発の世界には、それまでの研究から生まれた法則がある。あるソフトウェアの価値の八割は二割の機能に含まれる、というものだ。
（中略）
価値を基準にして優先順位をつけると、この二割の機能を先に形にすることになる。その段階までくると、あとの八割はそれほど必要ではなかったり、最初に重要と思えた部分が実際はそう でもなかったりといったことに気づく場合も多い。
ここで疑問を持ちます。
最大の価値をもたらすものかどうかは、どう判断すればいいんだろう？
大量の情報、それら情報個々の関係性など、どう全体に目を通せばいいんだろう？
この記事では、同書のP224とP248に書かれていた建物管理のオートメーションシステムと戦車開発を題材にした「最大の価値をもたらす判断方法」をミックスして、その方法をプ譜で行いやすくする方法について説明します。
プ譜を用いて「真の２割の価値」方法は以下の手順で行います。
製品のビジョンに取り入れる可能性のある項目を網羅したリストをつくる
その項目が、製品を使用しているときのどんな状態＝中間目的を実現しているのかを定義する
状態と項目を1セット（ひとまとまり）にする
勝利条件を決める
最初にどの状態から始めるかを決める（最大の価値を付加でき、かつリスクが最小の項目から着手する）
最初に着手する状態を実現する施策の順番を決める
以下、一つずつ詳細を見ていきましょう。
1.製品のビジョンに取り入れる可能性のある項目を網羅したリストをつくる
プ譜では最初にプロジェクトに関わる全員でプ譜を書きます。その施策欄に書いた「欲しい機能」や「必要な機能」がバックログになります。
施策を1つ1つの付箋やカードに書き出してもかまいません。
2.その項目が、製品を使用しているときのどんな状態＝中間目的を実現しているのかを定義する
ここからは、同書のP248で題材にしていた戦車開発を用いていきます。
時速一二〇キロは欲しい、一分間に一〇発の砲撃ができて、定員は四人、
空調完備等々、必要な特徴 を全部書き出す。
戦車の各要素についての要望を、「中間目的」に書いていきます。本来は文字で書くのですが、ここではわかりやすくなるように写真を入れていきます。上から順に定員は4人、1分間に10発の砲撃ができて、高精度の照準を合わせられている状態です。
中間目的の表現は、ストーリーの一シーンをイメージする。項目＝機能によって“なっている”状態にします。このとき、この状態の「完了の定義」も決めておきます。
3.状態と項目を1セット（ひとまとまり）にする
施策と中間目的の間を矢印線でつなぎます。施策と中間目的の関係は、「項目（～する）＝機能」によって、ある要素がこのような状態に“なっている”」と考えます。「する→なる関係」と覚えてもらえばわかりやすいです。
4.勝利条件を決める
勝利条件とはプロジェクトの成功の定義です。同書でいうところの「最大の価値（最も重要な価値）」を言葉で表現します。
この作業はバックログを書くより前、プロジェクトに取り組む一番最初に行った方がいいのではないかと思います。
5.最初にどの状態から始めるかを決める
最大の価値を付加でき、かつリスクが最小の項目から着手します。
ビジネス上の効果が大きい、顧客にとっての最重要、もっとも利益につながるもので、かつ一番簡単に実現できる状態を選びます。
6.最初に着手する状態を実現する施策の順番を決める
もっとも早く、簡単にできる施策は何か？
所与の条件（リソース、スキル、時間、お金）に適した施策は何か？という視点から実行する施策の順番を決めます。
施策を実行する（機能を開発する）のに必要なリソースがなければ、その施策は実行できないません。ムリに実行したとしても時間がかかったり、バグが出たりしてその修正にさらに時間がかかったりしてしまいます。
このように計画を立ててから実際につくり始め、段階的なリリースをすばやく顧客に提供していくことで、顧客が何を重要と考えるか、何に価値を見出して対価を払ってくれるかが把握できるようになります。
もし（３）の質問の答えがOKなら施策6を実行するコストを削減できます。
また、（４）の質問の答えがNoなら中間目的3を実行するコストを削減できます。当初求めていた品質よりも下げられて、コストを削減できる可能性もあります。
このように進めることのメリットを同書では下記のように書いています。
最初の予測がずれていても、修正すればいい。損失があるとしても最初の数スプリントにかける時間と労力だけですむ。
莫大な予算をかけて複雑な設備を作り上げた結果、製品は気に入ってもらえてもかかったコストに見合うほどの売り上げにならなかったときの損失と比べれば、はるかに小さい。
でも、もし「真の２割の価値」が計画に含まれていなかったら？プロジェクトを進めるなかで見つけた別の点に価値があるとわかったら？
こんなときはどうすればいいでしょうか？
どうしても変更しなければならないとなると、追加費用が発生してしまいますが、そこで同書が提案するのが「変更は追加費用なし」の方針です。
再び本書の内容を見てみましょう。
開発側はリストを見て、エンジンを作るのが一〇〇ポイント、砲弾の装填をす る部分は五〇ポイント、座席部分は五ポイント、と見積もっていく。
こうしてすべての機能に仕量に応じたポイントをつける。
このケースでは契約上、顧客はプロダクトオーナーと密に連携 をとってプロジェクトを進めることにしておき、スプリントごとに仕事の優先順位を変えられる。 バックログの項目をどう変えてもいい。新たな機能を追加しても構わない。
その場合はサイズが 同程度の機能を削って対応する。レーザー誘導式のシステムを追加したい? 五〇ポイント相当の仕事だな。ではそれを追加する分、同じ五〇ポイントの作業で、バックログの下位にある優先 順位の低いものを削ろう、という対応ができる。
変更したいものとサイズが 同程度の中間目的を削って変更します。
ただし、ポイントだけ見て、全体の辻褄が合わなくならないように注意する必要があります。
戦車に限らずその他の製品でも、例にあげたように「中間目的が3つしかない」ということはありません。実際はもっと数が多くなりますが、この記事では見やすくするため３つにしました。
プ譜を用いたこの方法が、真の2割の価値の発見に役立てばうれしいです。
未知なる目標に向かっていくプロジェクトを、興して、進めて、振り返っていく力を、子どもと大人に養うべく活動しています。プ譜を使ったワークショップ情報やプロジェクトについてのよもやま話を書いていきます。よろしくお願いします。