背景

1/11に戸塚でオフラインで開催されたイベントに参加してきました。

要求開発と匠メソッドとの考え方の違い

要求開発は戦略からがスタートであり、
匠は価値から戦略を考える　という違いがある。

復習

知情意は哲学者カントが作ったもの。
プロジェクトの体験のデザインとして使える。
要求から業務のビジネスコンテキストフローへ変換。
ここから詳細化してRDRAのビジネスフローの図などを用いて表現する。

私は、要求から業務へ変換する際に
この時点でビジネスイベントストーミングの作成に入ることが多い。
そこでAsIsに縛られないToBeの業務モデリングを行いたいからである。

知情意思考について

意だけだと視野狭窄になりがちで、
知だけだと論理思考にばかり傾き、手段思考になりがち。
情だけでは魅力的アイデアは出てくるが、実現性が低い。

情の部分

情の思考は、ボトムアップに視野を広げてくれる。
これは下位の要求から価値デザインで書かれた上位要求を再検討する感じ。

この辺りは前回の匠イベントの復習になります。

また、情は使いやすさや見やすさなどのUI/UXのベースにもなり、
ユーザー視点で使いやすい情報を設計する上でも重要になってきます。

知の部分

情の考察だけでは、システム上でどのような品質が重要なのかの考察が十分ではありません。
そこで知の部分でどの品質特性が価値に結びつくのか？を考察します。

個人の仮説

個人的にはここで脅威の側面からの考察も必要です。
例えば、使いやすさばかりを求めて、トレードオフの品質になるセキュリティが抜けもれて安全性が思わぬ形で損なわれたりしかねません。

つまり、企画段階でリターンとリスクの両側面からの考察をしておくことで、
トレードオフ分析の土台を整えなくてはいけないのです。

それぞれの関係性

意は常に方向性を与える。
これが価値分析モデルで、プロジェクト目標に紐づく価値記述を結ぶことに相当する。
これを行わないと、常に流されてそこに自分としての当事者意識のない、
内発的動機を伴わない顧客に言われるがままのものを作ってしまいがち。

情は意の視野を広げてくれる。

感性思考と論理思考で強化し、それを知に落とし込む。
これが価値分析モデルと価値記述を結合し、要求分析ツリーに落とし込む流れの思想。

知はそれぞれにフィードバックを与える。
実際に具体化してやってみた際に、発見を与えてくれる。
この際にクリティカルシンキングを用いつつの検証をしないといけないと感じる。

理解を深めたいところ

活動のツリーとか、ドメインモデルへのマッピングのあたり
↑　ここはかなり技術的なところであるため、過去のアーカイブなどを見て復習したいところ。

匠で何ができるのか

モノ人ことがデザイン可能であり、
モノのプロダクトデザインなどに使える。

例えば、しろたんというあざらしの赤ちゃんのキャラが、
まさに匠を暗黙的に用いてプロダクトデザインをしているし、
周辺のイベントとかでコトのデザインも行っているように感じる。

コトは開発者体験品質、従業員体験品質などの土台にもなると感じる。
他には、社会デザインなどにも使える。

制度の設計にも使った方がいい

制度はどんな価値を実現したくてとか、どんなリスクを回避したくて
という国民という巨大なステークホルダーにとっての価値を実現する上での
ルールと言うように設計さてていないといけない。
これはガバナンスアーキテクチャにおいても非常に重要である。

ゴール記述

どんな業務要求、どんな戦略要求とトレーサビリティ取れている。
これによって無駄なドキュメントを予防できる。
ドキュメント過多を避けられやすい。
そのため、よりアジャイルプロセスを実現しやすい。

それによって誰がいつ何をなどを明確に定義可能であり、
これは運用フローのサポートプロバイダの定義にも使えそうと感じている。

モデリングの流れ

ここで出すのは組織図っぽいと感じているけども、全然違う。
自分たちやエンドユーザー含めて関わる人たち全て。

ちなみに未来の社員といったフィーチャーホルダーも定義してもいい。

PTAでも使える！　確かに！と感じました。

最初にステークホルダーモデル→価値デザイン→価値分析
が通常の流れだけど、全然意が思いつかないなら、
価値分析をデザインより先にやってもいい。

価値記述のルール

シチュエーション、手段、価値の言葉(安心して住めるので嬉しい)を全て価値記述に盛り込むのがルール。
シチュエーションなどは利用シーンのことであるため、ステークホルダーの置かれてるコンテキストの深い理解のために必要。
価値記述は一人当たり２、３個までで書いたらすぐ発表する。

次にプロジェクトの目的を定義する。
「そもそもどんな目的で集まりましたか？」と言うように。
この際に価値記述は一旦無視していい。
でないと価値記述に縛られた目的を出しかねないから。

重要な価値記述があった場合に、そこと結びつかないプロジェクト目的がない場合に、
先程の情から意の範囲を広げる！
逆に、目的にそぐわない価値記述もあるので、そこは削って考え直すなどが必要。

目的を定義してから価値記述ってしないのは、
自分たちの意としての視野がいかに狭いか？ということを実感するためにも必要。
視野狭窄にならないようにするため。
どちらにせよ、意と情の行き来が大事。

知のモデルである要求分析ツリーで検証して、おかしければ前提の価値分析、デザインモデルなどに戻る。

論理思考で感性思考を補う。
価値分析の目的が増えたりして、価値記述を新たに定義したら、
未発見であったステークホルダーの発見にもなったりする。
（これはアーキテクチャを考えるにあたって非常に重要）

スコープ調整にも活かせる。
これはプロジェクトの目的から逸脱しているとかの判定をできるから。
ゴール記述モデルでKPIを定義して、一旦終わり。
ここからプロジェクトを始動させる。

企画段階でのこれが価値かもというモノを見つけることが大事。
ただしその時点では仮説の範疇を越えないので、場合によってはMVPなどを開発必要。

個人的研究課題

品質エンジニアさんの鈴木さんのスライドの価値と品質の関係性
と匠の関係性はどこでつながるのか？
おそらく、バリューメトリクス部分ではないか？
品質メトリクスの指標を増減させた際に、バリューメトリクスがどの程度変動するのか？
を分析したらいいと思われる。

方針制約との関係性は研究課題。

質問リスト

イベント中にあった質問の内容とそれに対する回答をまとめます。

要求と価値との違いは？

端的にいうと視点が違う。
１つの概念に対して、要求の中に価値が入ってる。
要求されるってことはなんらかの価値があるとみなせる。

分けるとわかる！　要求という１つの概念から価値へ。
要求の中に価値が含まれている。
つまり、要求→価値　という依存関係です。
要求のなんでなのか？に価値が潜んでいる。
上位概念であるってことであり、価値←要求
目的だけでは足りず、目的の価値を考えることが重要。

目的と価値を分けていることで、目的に価値がないことを検証しやすくしている。
これは縦構造の関心の分離をまさにおこなっているといえる。

価値を浮き彫りにしたら、他の要求との比較検討をしてみるのがベター。
でないと、視野狭窄な要求に縛られてしまいがちになる。

要求開発手法の弱点として、戦略の裏に具体的などんな喜びを伴うのか？
などのイメージがない状態で開発が進んでしまう。

個人考察として、UAFは戦略スタートなので、
匠で要求を開発したのちにUAFに行くといいと改めて感じる。(実体験済み)

知情意は個人で行うかチームで行うか

個人考察としては、個人レベルのものからボトムアップに帰納法などを使って
チームの集合意思として定義する。
もちろんそこは感性で叩いて検証した上で、チームが納得したものを明確に定義する。

集合意思を定義するには、ステークホルダーの情を踏まえないと
自分たちの視野狭窄に陥るから、情を踏まえた上で定義。
というようにサイクルを回して洗練していく感じ。
知を踏まえないと、地に浮いた状態になってしまうので、論理的思考を用いて検証する。

ストーリーの検証

運用してみると、仮説のストーリーと実際のストーリーは異なることが多々ある。
価値記述が具体的でないこと以外に、何が要因として考えられるか？

軌道修正のためには？
体験しながらモデル修正していく。

あくまでも骨組みは匠で定義し、肉の部分をアジャイルで回して素早く検証する感じ。
素早く検証し、肉を組み替えていく感じ。
骨組みの軸が変わると、そもそもあっちこっちに発散してしまうからNG。
ここは下の本、ラディカルプロダクトシンキングと思想が同じである。

マインドを変える手法に感じるが、キードライブは？

キードライブとなる要素は何か？
匠のモデルを更新するたびにエンゲージメントを徐々に上げていくための
気づきの仕掛けを盛り込んでいる。

マインドチェンジするには、要求ではなく、価値駆動で行うのがベター。
要求だけでは、その先の未来に繋げにくい。

「〜〜で嬉しい」と言うワードを必ず価値記述に書くこともキー。

要求とユーザーストーリーとの関係性は？

価値記述をより具体化したものがユーザーストーリーという位置づけ？
ここは質問できなかったので、別の機会に質問します。

価値の検証の方法は具体的に何があるか

同じ席の方からバリューメトリクスに関連していく質問がありました。
内容は、「価値の検証可能性について。その価値が確かに満たされたかの検証は？
ここの価値が満たされてないから軌道修正しようとか。」
といったもの。

これに対しての回答は、
ゴール記述のKPIだと粒度が細かすぎるから、要求モデルの方にもマクロなKPIをバリューメトリクスとして定義するということ。

ここで新たに、個人的に疑問を感じたのは、
品質特性の１つである、機能適合性とバリューメトリクスの関係性。

機能適合性の内容的に、間違いなくバリューメトリクスと密な関係を示すと感じる。
ただし、バリューメトリクスの中には、機能的側面だけでなく、
品質の側面も含まれての内容と感じるため、正確にはイコールではないと思っている。

その他の思想

要求ツリーで財務指標いれないのは視野狭窄を防ぐためで、KGI、KPIの土台。
価値の数値化と活動の数値化両方。

なぜ感性が必要とされるのか？
真善美。感性思想哲学。
サイエンス(論理)とアート(意や情)のバランス！
アート駆動でそれをサイエンスで脇固める。

エッセンスを言葉で表すとキャッチコピー。
経営の文脈でいうとビジョンや戦略。
イノベーションのためには、マクロなストーリーが必須。
ロードマップはわりと論理よりなストーリー。