価値システムスキーマによるソフトウェアデリバリーにおける価値の流れの測定

全文

1 はじめに

ソフトウェアチームは細かく計測されています。ベロシティ、スループット、リードタイム、デプロイ頻度、変更失敗率は自動的に収集されます。しかし、これらの数値は一つの問いを残したままです。チームはどのような価値を、誰に、そして損失というどのようなコストを払って届けたのか、という問いです。

本稿は、Æilus 方法論のモデリング表記である価値システムスキーマ(Value System Schema、VSS)を用いてこの問いに答える方法を提案します。VSS は aeilus.tech で公開されている VSS Editor に実装されています。本稿は連載「Æilus for Business」の第5論文です。本稿は、連載第1論文「Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners」(Bolshakov, ÆVRI, 2026)で定義された語彙を用い、その定義は繰り返しません。測定可能な通貨(Æ)としての価値の形式的な扱いは、「Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective」(Bolshakov, ÆVRI, 2026)に示されています。

本稿は、デリバリー組織が自らの価値システムのスキーマをどのように構築し、リリースに計画価値と実現価値をどのように結び付け、流れの抵抗(flow resistance)と漏出(leakage)をどのように特定し、共有される技術的ノードをどのように評価し、明確な役割とケイデンスでこのサイクルをどのように運用できるかを説明します。本稿は VMT の公理 A1、A2、A4、A5、A6、A7、A11、A13 と定理 T3、T4、T5、T6、T8、T9、T15、T16、T17 に依拠しています。実測データは含まれていません。第9節の具体例は合成されたものです。

2 デリバリー指標が測るものと測らないもの

デリバリー指標は作業の動きを記述します。ベロシティは完了した見積もり工数を数え、スループットは完了した項目数を数えます。Forsgren、Humble と Kim(Accelerate, 2018)が広めた4つの主要指標、すなわちデプロイ頻度、変更のリードタイム、サービス復旧時間、変更失敗率は、デリバリーパイプラインの速度と安定性を記述します。この研究はこれらの能力を組織のパフォーマンスと関連付けており、本稿はそれに異を唱えません。本稿の主張はより限定的です。これらの指標はパイプラインを記述するものであり、そこを通過する価値を記述するものではない、ということです。

ここから3つの隔たりが生じます。

• 工数は価値ではありません。ベロシティの高いスプリントが、誰にも使われない機能を届けることもあります。Product Value System デッキの言葉では、「機能は価値ではなく」、「指標は価値ではありません」。機能は価値についての仮定であり、指標はその解釈です。
• 速度は方向ではありません。短いリードタイムは、誤った仮説をより速く届けます。
• 安定性は反価値(anti-value)がないことではありません。低い変更失敗率は、遅延、混乱、ユーザー側での手戻り、あるいは設計どおりに動作した変更が引き起こした信頼の喪失については何も語りません。

価値管理理論(Value Management Theory、VMT)の観点では、この隔たりは構造的なものです。価値は定義された価値システムの内部にのみ存在し、そのアクターによって解釈されます(A1、A2)。価値は消費の瞬間に実現され(A6)、計画価値と実現価値は通常異なります(A4、T3)。パイプライン指標は消費の前、送り手側で収集されるため、せいぜい計画価値の引き渡しを記述するにとどまります。こうした指標が目標になると、Goodhart(1975)が述べた効果が現れます。チームは数値そのものを最適化するのです。VMT は同じリスクをシステムの言葉で述べています。局所的な最適化は全体的な改善を保証しません(T5)。

3 価値システムスキーマの表記

3.1 表記の要素

Æilus 方法論において、価値システムスキーマは最初の中核成果物です。これは価値システム、そのアクター、価値の流れ、変換器、主要な交換を形式的に記述したもので、システム境界を確立し、見えない外部依存を防ぐために用いられます。VSS は変換器レベルでもシステムレベルでも描くことができます。

2025年12月に aeilus.tech で公開された VSS Editor は、こうしたスキーマのためのブラウザベースのビジュアルエディタです。その表記には少数の要素があります。

• コンバーター。コンバーター(converter)は、スキーマにおける変換器の役割を指す Æilus の名称です。チーム、サービス、サブシステムなどの機能ブロックであり、価値要素を受け取り、それを変換し、新たな価値要素を生み出します。コンバーターは、価値が創出され、増幅され、あるいは破壊される場所です。
• 流れ。流れ(flow)は、コンバーター間、またはコンバーターと外部世界との間の有向の接続です。流れは Æ 単位での価値または反価値の量を運びます。流れには、外部からの流入(価値がシステムに入る)、外部への流出(価値がシステムから出る)、内部(コンバーター間の価値)があります。
• 入力と出力。外部からの流入と流出は、価値が入り、出ていく場所を示します。これらを合わせてシステム境界を定めます。
• 価値要素。要素の種類は、流れの中を具体的に何が移動するかを記述します。顧客価値、収益、コスト、リスク、技術的負債などです。保存されたスキーマでは、各要素に種別(価値または反価値)、符号、数量、単位(Æ)があります。
• 反価値。反価値は損失と負の効果を表します。遅延、手戻り、欠陥、官僚主義、リスク、燃え尽き、無駄な労力などです。スキーマでは、反価値は負の符号を持つ明示的な要素であり、価値の不在ではありません(A5)。

3.2 機械可読モデルとしてのスキーマ

エディタはスキーマを、ノード(コンバーター)、流れ、要素を持つ構造化 JSON として保存します。そのためスキーマはプロダクトとともにバージョン管理でき、後から流れごとの計画量と実現量を比較する分析で読み取ることができます。そのような分析は今後の課題として予告されており、本稿では前提としません。

3.3 スキーマではないもの

VSS Editor は、KPI ダッシュボードでも、BI ツールでも、シミュレーションエンジンでも、財務会計の代替でもないことが明示されています。それは計算よりも明確さを優先します。推奨されるモデリングの順序は次のとおりです。まず境界を定め、主要なコンバーターのみを追加し、名前の付いた流れでそれらを接続し(数値よりも名前、精度よりも方向)、その後に反価値を記入します。この最後の段階が、しばしば最も多くの洞察をもたらします。

4 誰の価値か:システムとその境界

誰の価値を測るのかを明示しない限り、価値の測定は意味を持ちません(A1、T1)。選ばれた境界は、現実が何も変わらなくても結論を変えてしまいます(T15)。そのため本稿では、あらゆる測定に先立って価値システムを確定します。

ここでモデル化する価値システムは、プロダクト組織内の単一のソフトウェアプロダクトのプロダクト価値システムです。Product Value System デッキに従うと、そのアクターはプロダクト機能、開発チーム、運用、本番環境のプロダクト、ユーザー、そしてユーザーから返される価値の受け手としての企業です。財務は外部からの支援的な流入(給与)です。

実現された解釈は2つを測定します。ユーザーまたはその観察可能な行動によって解釈されるユーザーにとっての価値と、返却の流れ(収益、継続利用、コストまたはリスクの低減)の受け手としての企業によって解釈される企業にとっての価値です。計画価値は、リリース前の送り手による解釈です。同じリリースがパートナーや規制当局にもたらす価値は、明示的に拡張しない限り境界の外にあります。

5 プロダクト仮説から実現価値へ:価値ループ

Product Value System デッキは、プロダクトの仕事を、価値仮説が作られ、実装され、検証され、維持されるループとして捉えています。スキーマの言葉では、このループには次のコンバーターと流れがあります。

1. プロダクト機能への投資。プロダクト機能は、リソースとユーザーのシグナルを、計画価値を帯びた仮説に変換します。
2. プロダクト機能から開発へ。仮説は計画価値を持つバックログ項目になります。デッキは2つの期待を述べています。仮説の計画価値は構築中に減少すべきではなく、届けられた価値は計画価値と大きく異なるべきではない、というものです。
3. 開発から運用へ。開発は工数を消費し、反価値(技術的負債、欠陥、遅延)とともに、動作する変更を生み出します。
4. 運用から本番環境へ。変更は稼働するソフトウェアになります。リリースのエラーやダウンタイムは反価値として現れます。
5. 本番環境からユーザーへ。価値は使用においてのみ実現されるため(A6)、ここが実現価値を観察できる最初の地点です。
6. ユーザーから企業へ。ユーザーは収益、継続利用、信頼を返します。著者の2022年1月のチャンネル投稿は、これを閉じた流れと呼んでいます。クライアントに届けられた価値は、しばしば貨幣だけではない、戻ってくる価値と釣り合うのです。

このループは変換の公理(A7)を具体的に示します。各コンバーターは受け取ったものを実現し、次のコンバーターのために新たな計画価値を生み出します。また、パイプライン指標がステップ3と4しかカバーしない理由も示します。価値が計画され、実現され、返されるステップ1、2、5、6は、パイプラインの外にあります。

このデッキは、社内向けおよび社外向けのプロダクトについて、観察可能な要素の種類も挙げている。価値要素には、時間の節約、運用ミスの減少、キャッシュフロー、リスクの低減、認知負荷の低下、予測可能性、新しい能力、信頼が含まれる。対応する反価値の要素には、失われた時間、手戻り、増大する運用コスト、技術的負債、予測不能性、手作業による回避策、信頼の喪失、顧客サービスの低下が含まれる。この類型は、デリバリーのための価値要素登録簿(Value Element Registry)の出発点となる。

6 リリースごとの計画価値と実現価値、抵抗と漏出

6.1 比較の単位としてのリリース

比較の単位はリリースであり、リリースが小さい場合はバックログ項目である。それぞれについて、この手法は Æ に次を記録する。

• 計画価値: 送り手の見積りであり、開発開始前に記録され、明示的かつ記録された決定を通じてのみ更新される。
• 実現価値と実現反価値: リリースが合意された観察期間にわたって使用された後の、受け手の解釈。
• 遡及的価値: 二次的な効果(サポート負荷、解約、技術的負債)が見えるようになった後の、事後の再評価。

デッキは段階的な導入を提案している。まずすべてのバックログ項目に計画価値を付け、次にリリース済みのすべての項目に実現価値と反価値を付け、最後に遡及的価値を付ける。計画価値がなければ測定すべきギャップは存在せず、実現価値がなければ計画は仮説のままである。

6.2 デリバリーにおける流れの抵抗

流れの抵抗(flow resistance)とは、計画価値と実現価値のギャップに、流れの中に現れる反価値を加えたものである。VMT はゼロでないギャップを正常なものとみなす(T3)が、抵抗は履歴的に蓄積し(T4)、将来の価値を実現する能力を低下させる(T6)と考える。デリバリーにおいて価値は、実装(スコープの削減、仮説の読み違い)、リリース(欠陥、ロールバック)、導入(ユーザーが変更を見つけられない、または使えない)、そして遅延によって失われる。遅延コストの概念(Reinertsen, 2009)に従い、遅延は別個の指標ではなく、遅れた流れに対する反価値としてモデル化される。

各流れがそれぞれの計画量と観測量を持っていれば、スキーマはどのコンバーターで損失が生じたかを示す。これが、Æilus の成果物セットにおける流れの抵抗登録簿と計画価値と実現価値のギャップレポートの目的である。

6.3 漏出

漏出(leakage)とは、システムに入る価値を、システムから出ていく実現価値が持続的に上回ることである(A11)。プロダクトの価値システムでは、二つの形がよく見られる。一つ目では、ユーザーは恩恵を受けるが、戻りの流れがそれを可能にする流入を賄えない。二つ目では、チームが仮説の構築中に投資を消費するが、その仮説は決して実現されない。どちらの場合もスループットは健全に見えうる。流入と流出が一つの境界上にあるため、スキーマは両方を示す。

7 共有ノード: すべての流れを横断した評価

ソフトウェアシステムのコンバーターの中には、ユーザーが名指しするような価値を何も生み出さないが、すべての価値の流れがそこを通過するものがある。著者の2025年9月のチャンネル投稿と関連する aeilus.tech の記事は、認可を例として挙げている。認可はそれ自体では価値を生まないが、それがなければあらゆるシナリオが止まる。API ゲートウェイや CI パイプラインも同種のものである。

そのようなノードを単独で評価すると、コストだけが見えて出力が見えず、コスト削減を招く。スキーマでは、それは同時に多くの流れ上に現れ、その効率は、支えているすべての流れの総価値を通じてのみ明らかになる。したがって、この手法は共有ノードに次を割り当てる。

• スキーマから読み取られる、そこを通過する流れの集合。
• それがそれらの各流れに加える反価値(レイテンシ、障害、ログインの失敗、統合の欠陥)。
• それが消費する価値(チームの労力、インフラ)。

その効率は、同じ記事のプロセス効率の定義に従い、すべての流れにわたる提供価値から反価値を引いたものを、消費価値と対比したものである。共有ノードの劣化は決して局所的なインシデントではなく、それが支えるすべての流れに加わる抵抗である。定理 T8 は持続可能性の観点からの論拠を加える。変換の役割が果たせなくなると安定性が失われ、その役割の冗長性は安定性を高める。

8 チームリーダーが得るもの

著者の2022年2月のチャンネル投稿は、このアプローチがチームとそのリーダーにもたらすものを挙げている。本稿の用語で言い直すと次のとおりである。

• フィードバックとしての提供価値。どの期間についても、チームはベロシティという間接的なシグナルの代わりに、受け手によって確認された、自らが提供した価値を Æ 上で見ることができる。
• プロセス方法論から独立した有効性の尺度。プラクティスが何であれ、尺度は消費価値あたりの実現価値であり、プラクティスはそれに対する効果によって選択または廃止される(P7)。
• ビジネスに対する透明性。技術的な作業は、それが支える流れを通じて説明可能になる。
• 価値に基づくバックログの優先順位。優先順位は、最も声の大きいステークホルダーからではなく、計画価値、その確度、遅延コストから導き出せる。
• 反価値としての遅延コストと本番環境のエラー。ビジネスは、変更が遅れたり欠陥があったりしたときに価値がどのように下がるかを示すことができ、チームは自らの作業の有用性がタイミングと本番品質にどのように依存するかを理解できる。
• 共有リソースのための論拠。管理者や DevOps エンジニアが共有されている場合、価値に基づく優先順位は、あるチームの作業が別のチームの作業を優先して延期された理由を、どちらの方向についても説明する。

これらの利点は、実現価値がその受け手によって検証される場合にのみ成り立つ。チームが自らの価値を見積り、確認するならば、尺度はまた別の自己申告のカウンターになり、T17 が適用される。すなわち、影響力のある情報源からの解釈で、実現によって確認されないものは、反価値を蓄積する。

9 合成プロダクトのスキーマの実例

このセクションは、例示のための合成プロダクトを説明するものである。これは事例研究ではなく、実在のいかなる組織も説明しておらず、測定された数値も含まない。

この合成プロダクトは、小規模なサービス事業者が顧客の予約を受け付けるサブスクリプション型のウェブアプリケーションである。その価値システムは、セクション 4 で定義した境界に従う。認可サービスと API ゲートウェイという二つの共有ノードが、ユーザー向けのすべての流れを支える。財務部門は、それを可能にする流入を提供する。会社は、戻りの流れとしてサブスクリプション収益とリテンションを受け取る。

スキーマは VSS Editor で四つの段階を経て構築される。すなわち、外部からの流入が一つ(投資と給与)とユーザーへの外部への流出を持つ境界、七つのコンバーター、それらが運ぶ価値要素にちなんで名付けられた流れ、そして反価値の要素である。数量は、最初の見積りセッションまで空のままとする。

ある仮想的なリリースを考えてみます。予約の無断欠席を減らすことを目的としたリマインダー機能です。開発の前に、プロダクトオーナーは要素ごとの計画価値(Vplan)を記録します(節約される時間、減少する予約漏れ、リテンションへの期待される効果)。合意された観察期間の後、プロダクト分析とビジネスユーザーのサンプルが実現価値(Vreal)をもたらし、チームは実現された反価値を記録します。リリースの遅れ、重複したリマインダーを送信した不具合、APIゲートウェイへの追加負荷などです。その差が、このリリースの流れの抵抗です。不具合とゲートウェイへの負荷は、他のシナリオにも使われる流れの上にもあるため、共有ノードにも割り当てられます。四半期後、価値レトロスペクティブ(Vretro)は、そもそもリテンションが変化したかどうかを記録します。実際のアプリケーションでは、数量は次に説明するセッションから得られます。

10 運用の方法

10.1 誰が見積もり、誰が検証するか

2025年の投稿にある Æilus のルールは簡潔です。プロセスの出力価値は、それを消費する者が評価しなければならず、別の誰かがその評価を確認すべきです。これをデリバリーに適用すると、次のような明確な役割分担になります。

• 計画価値は送り手が見積もります。仮説の場合、これはプロダクト変換器の価値変換器オーナー(VTO)として行動するプロダクトオーナーです。開発変換器の場合は、VTOとしてのチームリーダーです。
• 実現価値は受け手が解釈します。受け手とは、プロダクト分析やウェブ分析を通じて観察されるユーザー、および還流する流れについては会社です。資料(deck)は、直接の検証が確立されるまでの暫定措置として、プロダクト分析がユーザー側を代表することを提案しています。
• 解釈の検証は第二者が行います。システム全体の持続可能性を担う価値システムオーナー(VSO)、または重要な流れについてはフローオーナーです。
• 方法論の一貫性は Æilusマスター(資料では、プロジェクトマネージャーが担う Æilus チャンピオン)が支えます。Æilusマスターは、価値デリバリー、計画対実績、流れの抵抗に関するレポートを作成します。

10.2 ケイデンス

Æilus はカレンダーを定めていません。方法論が推奨するイベントに沿った、デリバリーチームのための最小限のケイデンスは次のとおりです。

• バックログリファインメントごと:要素登録簿を用いて、新しい項目に計画価値を割り当てます。
• 観察期間後のリリースごと:実現価値と反価値を記録して検証し、短い価値レトロスペクティブでそのギャップを議論します。
• 毎月または四半期ごと:共有ノードを含むスキーマ全体に対する流れの抵抗レビューと、以前にリリースされた項目のレトロスペクティブ価値の確認を行います。
• 四半期ごと、または構造変更時:境界、変換器、依存関係についての価値システムレビューを行い、スキーマファイルを更新してバージョン管理します。

10.3 規律

すべての成果物には、オーナー、更新ループ、意思決定の目的が必要です。そうでなければ、維持コストと誤った確信を通じて反価値を生み出します。この方法における意思決定の目的は、バックログの優先順位、共有リソースの配分、リリース時期、共有ノードへの投資です。計画価値の拡大が認められるのは、それを実現するチームの能力が確認されている場合に限られます(P9)。計画価値を実現価値よりも速く拡大することは、T16 が述べる失敗モードです。

11 限界と実証研究に必要なもの

本稿は概念的なものであり、測定データでは検証されていません。そのため、いくつかの限界があります。

• 見積もりの品質。Æ における価値は解釈であり、その信頼性は見積もる者とそのキャリブレーションに左右されます。
• 部分的な通約可能性。節約された時間、収益、信頼は、部分的にしか通約できません(A13)。これらを単一の通貨で表現するには価値集約ポリシーが必要ですが、本稿はそれを前提としつつも定義はしていません。
• 帰属。実現価値は多くの場合、複数のリリースと外部要因から生じます。スキーマは構造を示しますが、1つのリリースの寄与を切り分けることはできません。
• 隠れた流れ。スキーマがシステムの観察された安定や衰退を説明できない場合、潜在的な流れがあるか、境界が誤っています(T9)。スキーマは構造についての仮説であり、見直されなければなりません。
• 方法のコスト。意思決定を生まないセッションは、方法そのものを反価値に変えてしまいます。

実証研究には、最低でも次のものが必要です。レトロスペクティブ価値を記録できるだけの十分に長い期間この方法を適用する複数のデリバリーチーム。データ収集の前に合意された、安定した要素登録簿と集約ポリシー。チームではなく受け手による、実現価値の独立した検証。従来のデリバリー指標と実現価値との関係を検討できるようにするための、従来指標の並行収集。そして、スキーマがある場合とない場合に下された意思決定の比較です。このような研究だけが、価値に基づく優先順位付けが提供される価値を変えるかどうか、またどのような条件下でそうなるかを示すことができます。

12 結論

デリバリー指標は、作業がパイプラインをどのように流れるかを記述するものであり、それが受け手にとって何を変えたかを記述するものではありません。VMT のもとでは、価値は文脈的であり、使用においてのみ実現され、計画価値と実現価値は乖離するため、指標にはそれができません。VSS Editor に実装された価値システムスキーマにより、ソフトウェアチームは、仮説から実現価値、そして会社へと戻るプロダクトの価値ループを描くことができます。リリースごとに計画価値、実現価値、レトロスペクティブ価値を記録することで、このループは測定へと変わります。抵抗と漏出が可視化され、共有ノードはそれが担うすべての流れにわたって評価され、チームリーダーは提供された価値、価値に基づく優先順位、遅延とエラーのコストをフィードバックとして得ます。この方法が誠実であり続けるのは、システムの境界が明示され、受け手が実現価値を検証し、すべての成果物が意思決定に役立つ場合に限られます。実際に提供される価値が向上するかどうかは実証的な問いであり、本稿はそれを枠付けしますが、答えてはいません。

参考文献

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (ロシア語). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.