TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

Value Metricsの4つの効果〜匠Method Value Metricsとゴール記述モデルによるモデルの検証その1

TRACERYプロダクトマネージャーの haru です。

2024年11月28日(木)に開催された勉強会「匠Method User Group Meetup#9〜実践事例の共有/Value Metrics」では、匠Method*1の匠Method Value Metrics(以下、Value Metrics)*2やゴール記述モデル*3をテーマにしたパネルディスカッションが行われました。その時の様子をお伝えします。

匠Method Value Metricsとゴール記述モデルによるモデルの検証

  • パネラー
    • 萩本 順三(はぎもと じゅんぞう) 氏:以下、萩本
      • 匠Method開発者、(株)匠Business Place代表取締役会長
    • 安樂 啓之(あんらく ひろゆき) 氏:以下、安樂
      • インフォテック(株)。匠Method Value Metricsの策定に携わった
    • 高崎 健太郎(たかさき けんたろう) 氏:以下、高崎
      • 匠Method User Groupリーダー幹事、(株)アクティアCOO
    • 高橋 大翼(たかはし だいすけ) 氏:以下、高橋
      • 匠Method User Group幹事、(株)アクティア
  • モデレータ
    • haru:以下、haru
      • 匠Method User Groupリーダー幹事、本記事の執筆者

haru:第1部の安樂さんのお話*4は、匠Methodについての奥深い内容だと思い、話を伺っていました。一通りの匠Methodのコアのモデル*5をつくるだけではなく、Value Metricsやゴール記述モデルを活用し、コアのモデルを洗練化し続けていることが素晴らしいと思いました。本日のパネルディスカッションでは引き続き、Value Metricsとゴール記述モデルをテーマに取り上げたいと考えています。まず、匠MethodのValue Metricsを実施することで得られる効果について、パネリストの皆さんに伺いたいと思います。

効果その1〜価値が見える化され、視野が広がる

高崎:匠MethodのValue Metricsを実施する際は、メンバーが集まり、「この価値概念が実現した場合、どの程度のインパクトがあると思うか」をあらわすポイント*6をメンバーそれぞれが提示します。それが出揃ったあとで「なぜそのポイントを付けたのか」を議論し、認識を擦り合わせます。このプロセスを繰り返すことで、価値の評価に対する認識のズレを解消し、モデルが徐々にブラッシュアップされていきます。また、自分では価値があると思っていたものが、他の人には違った視点で捉えられることもあり、近視眼的になりがちな視野を、他の人のポイントの理由を聞くことで広げられるという、大きな効果があると感じました。

高橋:価値が見える化され、定量化される点が良いところだと思います。それにより、言葉だけで議論するよりも、モデル要素の理由が明確になると感じます。

匠Method Value Metricsの価値の評価(価値測定)

効果その2〜価値を評価する過程で、価値が膨らむ

萩本:Value Metricsを作ろうという話が持ち上がったとき、「価値を測るなんてありえない」というところからのスタートでした。しかし議論を重ねる中で、Value Metricsのプロセスを通じて価値デザインモデル*7や価値分析モデル*8がさらに洗練される可能性を感じるようになったんですね。ポイントを付けた理由について「私はこういう価値があると思います」と価値のストーリーを話したり、価値の評価を価値概念*9として書いていくことで、単に価値を測るだけでなく、価値そのものを膨らませる特性があることに気付き、その点に面白さを感じました。

効果その3〜価値の評価と活動の評価を比較することで、活動が真に価値を生むものかを検証できる

萩本:Value Metricsでは、価値の評価だけではなく、活動*10の評価もあります。

匠Method Value Metricsの活動の評価
価値の評価に対して、活動の評価が低い場合には違和感が生じます。 ビジョン、コンセプト、目的までの連なりを価値概念の記述でみたときに、価値のポイントよりも活動のポイントが低い場合、それは要求が十分に抽出されていない可能性があります。中途半端な業務要求をあげてしまったのではないかということです。 一方で、活動は測定可能であるが、価値は測れないという考え方もあります。しかし、活動の評価だけをやってしまうと稚拙な価値となるリスクが高まり、結果として活動の質も低下してしまいます。そのため、価値の評価と活動の評価の両方に取り組んだほうが良いというところです。
価値の評価と活動の評価の比較

論理思考で導いた結論を感性で叩く

萩本: 論理思考は間違いを犯すことがあります。論理的には正しいけれど、それは本当に大事なことなのかということを疑う必要があります。 そのため私は「論理的に導いた結論、目的と手段の連鎖を、感性*11で叩いてください」と伝えています。これまでの経験を基に吟味し、検証することが重要です。 これらのValue Metricsの研究は「面白そうだ」と感じて始めましたが、実際にはかなり大変なものでした(笑)。

論理思考で作った要求分析ツリーを感性で検証する

効果その4〜価値の評価によって早期段階でモデルの品質が安定する

安樂:卵が産まれるまで*12、だいぶ時間がかかりました(笑)。私はValue Metricsをやってみて、モデル、特に要求分析ツリーの安定性が高まるということを実感しました。Value Metricsでは、価値の評価を行うときにビジョン-コンセプト-目的の連なりに対して、その価値が実現すると、何がよいのかという「価値概念」を書きます。実現した時に世の中どうなるか、結果どうなるかということを考えます。価値概念を書くことは業務要求、IT要求、活動を実現させたらどうなるかということとイコールになります。モデルはつくるときに、最初の方で楽してると後でツケが回ります。要求分析ツリー*13がそれっぽいからといってあまり考えずに次々と進めていくと、要求分析ツリーが蜘蛛の巣のようになってしまうことがあります。価値の評価で頭を使うと、モデリングのシフトレフト*14のような効果が生まれて、洗練されたモデルになります。目的より後ろのモデルの品質が安定したものになり、要求分析ツリーが蜘蛛の巣のようになったり*15、無用に要求が広がってしまうリスクが下がります。

価値が十分に洗練されていないことによる悪影響

次回は、合意形成をテーマに話が展開します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:価値をデザインすることをコンセプトとしたモデリングを主体としたビジネス企画手法。公式URL:匠Method。当記事の筆者は2024年12月現在で12年間実践で活用している。

*2:匠Methodでモデリングした価値を数値で測るための手法。資料:匠Method Value Metricsとは(説明シート)匠Method Value Metrics概説匠Method Value Metricsの概要を参照のこと

*3:匠Methodで作成するモデルのうちのひとつ。要求をどのような計画で実現していくのかをモデル化する。

*4:匠Methodによる社内ビジネス立ち上げ事例報告(+α版) - Speaker Deck

*5:ステークホルダーモデル、価値デザインモデル、価値分析モデル、要求分析ツリー

*6:ポイントは、1、2、3、5、8、13、21、34、55、89までを使用する(フィボナッチ数)。アジャイル開発のポイントによる見積もりでも、この数が使われることがある。

*7:匠Methodのコアのモデルの一つ。「意」のモデルと言われ、プロジェクトで実現したい意志をモデル化する。

*8:匠Methodのコアのモデルの一つ。「情」のモデルと言われ、ステークホルダーにとっての価値をモデル化する。

*9:ビジョン、コンセプト、目的の連なりに対し、価値を獲得した際のゴールイメージを具体的に説明したもの

*10:この「活動」は、要求分析ツリー上の「IT要求」と「活動」の両方を指す。

*11:ここでは、感情や直感、価値観、想像力などのこと。

*12:匠Method Value Metricsの業務利用ができるまで

*13:匠Methodのコアのモデルの一つ。「知」のモデルと言われ、プロジェクトで実現したい戦略的な要求、業務的な要求、ITの要求、活動の要求をツリーで表現する。

*14:システム開発プロセスにおいて、テストや品質管理などの工程を従来よりも早い段階(開発スケジュールの左側)に移行させる考え方。これにより、不具合の早期発見や修正が可能となり、開発コストの削減や品質向上が期待される。

*15:ロジカルシンキングでいうMECE(Mutually Exclusive and Collectively Exhaustive、漏れなく、ダブりなく)の逆の状態になると、要求分析ツリーは蜘蛛の巣の状態になる。