コストセンターから価値換算器へ:テクニカルサポートにおける反価値の転換

全文

1 はじめに

多くのプロダクト組織では、テクニカルサポートはコストセンターとして計上されます。その予算は可視化され、成果は解決したチケットの数で数えられ、通常問われるのはどうすればより安価にできるかということです。本稿は、この捉え方は不完全であり、そこで抜け落ちているのは、プロダクトにとって最も重要なサポートの部分であると論じます。

議論には、価値管理理論(Theory of Value Management、VMT)と Æilus 方法論の語彙を用います。価値、反価値、価値の流れ、価値システム、価値変換器、そして計画価値、実現価値、事後価値は、本シリーズの第1論文で定義されたとおりに用います。価値通貨 Æ の形式的な扱いは Bolshakov (2026) に示されており、ここでは繰り返しません。

主な出典は、Æilus の記事 "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025) です。この記事は、サポートを、クライアントから反価値を受け取り、それを価値に変換する価値変換器の連鎖として記述しており、その係数は各ラインで増大し、各段階で測定すべき2つの係数を提案しています。本稿は、このモデルを再述し、係数を運用可能なものにし、それらが誰の価値を測るのかを明示し、測定プロトコルを提案します。本稿には実地データは含まれません。実例中の数値はすべて説明用のものです。

本稿は、VMT の公理 A1(文脈性)、A2(複数の解釈)、A4(計画と実績の非対称性)、A5(反価値の独立性)、A6(消費時の実現)、A7(変換)、A12(価値の非保存)、A13(部分的通約可能性)、ならびに定理 T2(流れの反転)、T4(抵抗の蓄積)、T5(局所最適化)、T9(隠れた流れ)、T14(解釈されない価値は失われる)、T15(境界依存性)、T16(実現を伴わない解釈によるスケーリング)に依拠します。

2 サポートがコストセンターとして扱われる理由と、それが覆い隠すもの

2.1 コストという見方は境界の選択である

コストセンターという見方は、価値システムの境界を企業の財務の流れの周囲に引くことから生じます。その境界の内側では、サポートは給与とツールを消費し、収益の項目を生みません。A1 のもとでは価値は価値システムの内部にのみ存在し、T15 のもとでは、境界を変えると現実は変わらないまま結論が変わります。コストという見方は、ある一つの価値システムの正しい読み取りであり、サポートが行っていることの記述ではありません。

T2 は、一つの流れが異なるシステムで正反対の解釈を担いうると述べています。企業がコストとして計上するサポートのやり取りは、クライアントにとっては反価値の除去です。つまり、痛みを生まなくなった障害であり、作業を妨げなくなった疑問です。出典は、サポートが提供するクライアント価値を、インシデントの反価値の低減や時間の節約からリスクの低減や信頼まで、10種類挙げています。そのどれもコストレポートには現れません。

2.2 コストという見方が覆い隠すもの

• クライアント側の価値。 サポートはクライアントの価値ストリームを回復させます。それが行われなくなれば、クライアントの参加条件(A8)が危うくなり、T7 は、クライアントが離脱するか参加の形態を変えると予測します。
• 内部の価値。 出典は3つの内部の流れを挙げています。インシデント情報、競合他社が持つ機能の要望、そしてクライアントからの独自の提案です。T9 のもとでは、モデルに示されない流れによって支えられている構造は、誤ってモデル化されているか、境界が不適切に設定されています。サポートのコストモデルはまさにそのようなモデルです。
• 変換。 出典は、サポートが反価値を価値に変換し、その結果は、課題がより深いラインとプロダクトに到達した場合、元の反価値を桁違いに上回りうると主張しています。A12 はこれを許容します。一つの根本原因を修正すれば、報告者だけでなくすべてのクライアントの反価値が除去されるからです。

3 反価値ストリームの入口としてのサポート

あらゆるプロダクトは価値と反価値の両方をもたらします。A5 のもとでは、反価値は独立したカテゴリです。クライアントはプロダクトから実際の価値を受け取りながら、同じ週に、障害から実際の反価値を受け取ることがありえます。サポートは、その反価値の大部分が観測可能な流れとして企業に入ってくる場所です。本稿は、第一線での受付に関する出典の記述に沿って、それを4種類にまとめます。

• インシデント。 動いていたものが動かなくなった。
• 欠陥。 意図どおりに動いたことが一度もない。クライアントがそれに遭遇したときに反価値が顕在化する。
• 混乱。 プロダクトは動作しているが、クライアントはそこから価値を得られない。
• 裏切られた期待。 計画価値と実現価値が異なる。A4 はこれが通常のことだと述べており、サポートはその乖離が報告される場所である。

5つ目の入力は潜在価値、すなわち要望と提案です。出典はこれを別に扱い、その量は限られていないと述べています。これは同じチャネルを共有するため、2つの分母が混ざらないよう、測定では反価値と切り離しておく必要があります。

入口が重要なのは T4 のためです。抵抗は蓄積します。キューに残された反価値は、信頼の喪失へと積み重なり、T6 により、将来の価値を実現する能力の低下へとつながります。プロダクト開発におけるキューの力学はよく記述されています(Reinertsen, 2009)。VMT の読み方が付け加えるのは、サポートのキューで待っているものは、クライアントの価値システムの中で蓄積していく反価値だということです。

4 変換の連鎖

A7 のもとでは、変換とは、行為者が入ってくる価値を実現する、あるいはここでは入ってくる反価値を吸収し、新たな計画価値を生み出すことを意味します。出典は、各サポートラインをそのような変換器として扱い、それぞれに固有の価値変換器オーナー(VTO)を置きます。

4.1 第一線

出典は第一線に、反価値ストリームの構造化されたチケットへの受付、最初の接触での反価値の迅速な減衰、連続的な価値ストリームの維持、ルーティング、データ収集、クライアントの期待の管理、そして反価値の深さの評価を割り当てています。その役割はフィルター、ショックアブソーバー、アクセラレーターです。多くの場合、それはクライアントの元の状態を回復させるため、出典は第一線に最も低い係数を割り当てています。期待の管理は注目に値します。ステータスの更新は何も修正しませんが、不確実性という反価値を減らします。これは A5 の直接の例です。

4.2 第二線

第二線は複雑な反価値を引き受けます。難しいバグ、連携、パフォーマンスです。出典が示す重要な転換は、問題を抑え込むことからその根本原因を取り除くことへ、そして一人のクライアントからすべてのクライアントへという移行です。修正と更新された手順書がクライアント基盤全体に波及するからです。第二線はまた、第一線の対応能力を高めるナレッジベースを構築し、繰り返し発生するインシデントをバックログに送り込み、技術的負債のような隠れた反価値を減らします。

4.3 第三線

出典は第三線を、アーキテクチャ、コード、プロトコル、コアロジックに根ざした反価値に取り組む、戦略レベルの変換器と呼んでいます。その成果物は、機能とアーキテクチャの変更、そして新たな変換器、すなわち反価値を変換し続けるツール、スクリプト、モニタリング、自動チェックです。第三線はまた、複雑なケースで価値と反価値をどう測定するかを含め、下位のラインのルールも定めます。出典は、変更がクライアントに届くまで、その上積みを定量化することは難しいと指摘しており、これは運用面から見た A6 です。

4.4 プロダクトオーナー

出典は、プロダクトオーナーのチームを次の変換器であり、価値の統合者として位置づけています。このチームは、すべてのラインからのストリームに優先順位をつけ、戦略と整合させ、コスト、時間、リスクにおける反価値が最も低く、クライアントの価値が最も高い箇所を評価し、市場のニーズから潜在価値を加えます。その成果物は、既存の価値を拡大し、新たな価値を創出するデリバリー計画です。出典はこれを PDCA と結びつけています。Plan はサポートデータから、Do はデリバリーチームが、Check はインシデントと価値指標について、Act は戦略とプロダクトについて行います。更新されたプロダクトは再び価値をもたらし、サポートは次のストリームを捉え、ループが閉じます。

5 出典が提案する係数

5.1 ラインごとの名目係数

出典による閉ループのまとめは、第一線で捉えられた反価値は x1 から x1.5 の係数で価値に変換でき、第二線では x10、第三線では x100 になると述べています。クライアントの提案は、量が限られていないとされたまま第二線と第三線に渡り、プロダクトオーナーがクライアントに返す価値は、事実上無制限になりうると記述されています。そのパターンは、問題が大きいほどより上位のラインに到達し、ラインが上位であるほど係数が高い、というものです。出典はこれらを測定値ではなくオーダーとして示しています。本稿はこれらを仮説として扱います。

5.2 VAM と ACM

出典は、各段階で2つのパラメータを測定する必要があると結論づけています。

• Value Amplification Multiplier (VAM)、価値伝達係数:「どれだけの価値が受け取られ、クライアントに届けられたか」。
• Anti-Value Conversion Multiplier (ACM)、反価値から価値への変換係数:どれだけの反価値が受け取られ、そのうちどれだけがクライアントにとっての価値へ変換されたか。

原典はこれらを言葉で述べており、数式は示していない。ここで提案する最小限の比率としての読み方は、レビュー期間におけるステージ s(第1線、第2線、第3線、Product Owner)について次のとおりである。

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s はステージに入ってくる価値(提案、または部分的に変換された潜在価値)、V_delivered,s はそのステージのアウトプットに帰属する、実現されたクライアント価値、AV_received,s はステージに入ってくる反価値、V_converted,s はそこから生み出された、実現されたクライアント価値である。すべての項は Æ で表される。

原典の文言から、2つの読み方が導かれる。分子はクライアントにとっての価値であるため、計画、チケット、バックログ項目は、クライアントによって実現されて初めて数えられる(A6)。また、2つの係数は分母が異なる。一方は価値の増幅を追跡し、他方は反価値の変換を追跡する。チェーン全体の係数は ACM_chain = sum of V_converted,s / AV_received,1 であり、分母は受付時の反価値、実現された価値の各単位は1つのステージにのみ帰属させる。

6 誰の価値を測定するのか

A1 と A2 のもとでは、価値システムが明示されていない係数は無意味である。このチェーンは4つの価値システムに関わる。

本稿では測定を次のように定める。VAM と ACM の分子はクライアントの価値システムで測定する。実現された価値は受け手による解釈だからである。分母はクライアントとサポートの境界で測定する。すなわち、クライアントが経験し報告するとおりの反価値を、第1線が記録する。サポートおよびプロダクトの価値システムは係数を利用し、会社の価値システムはそれらをコストと比較して評価する。VSO は、部分的にしか通約できないこれらの読み取りを比較するための集約ポリシーを所有する(A13)。サポートが自らの価値システムから自己測定を行えば、報告されるのは労力と計画された価値になってしまう。原典の定義は外向きであり、このプロトコルはそれを外向きのままに保つ。

7 測定プロトコル

以下のプロトコルは、現場では未検証の提案であり、既存のチケット管理ツールやバックログツールと連携して機能するよう設計されている。

7.1 記録するデータ

• 受付時:クライアントとプロダクトの利用状況、入力の種類(インシデント、不具合、混乱、期待との食い違い、提案)、共通の尺度による Æ での反価値の見積もり(可能な場合はクライアントと確認)、影響を受けるドメイン。
• 各引き継ぎ時:受け取るステージとその理由、解決の種類(状態の復旧、このクライアントについての修正、根本原因の除去、新しい変換器の作成、バックログ項目の起票)、チケットからバックログ項目およびリリースへのリンク、提案された変更の計画価値(実現された価値とは区別して保持する)。
• 提供後:クライアントまたは合意された代理指標によって確認された、Æ での実現価値、到達したクライアント数、後日の振り返りによる再評価。

7.2 実現価値を検証するのは誰か

成果を主張する変換器が、自らの実現価値を検証することはない。クライアントが、明示的な確認、または事前に合意された代理指標(インシデントが再発しない、機能が使われている)を通じて、それを解釈する。各ラインの VTO は見積もりを提案し、ログの品質を所有する。Product VTO は、提供されたどの変更がどのサポートからの入力に遡れるかを確認する。VSO は帰属をめぐる紛争を裁定する。計画価値は記録されるが、A4 と T16 に従い、分子に入ることはない。解釈だけで価値の主張を拡大することは、構造的に不安定だからである。原典における第3線の x100 は、その変更がクライアントに届くまでは、そのような主張にあたる。

7.3 レビューの頻度

• チケットごと、クローズ時:受付時の見積もり、解決の種類、第1線の実現価値。
• ラインごと、短い定期サイクルで:完了した項目の ACM と VAM、キューに残る未解消の反価値の滞留期間(T4)、エスカレーションの理由。
• システムごと、より長いサイクルで:VSO と Product VTO が、提供された変更、振り返りによる再評価、反価値の総流入量、そして各ラインの係数が原典の予測する順序に従っているかどうかをレビューする。

実現には遅れが生じるため、係数はコーホート別、すなわち反価値が受け取られた期間ごとに報告すべきである。

7.4 落とし穴

Goodhart (1975) は、統計的な規則性は、統制に用いられるとたちまち崩れる傾向があると指摘した。VMT の用語では、これは T5、すなわち局所的な最適化は全体的な改善を保証しないということにあたる。

• チケット件数の操作。1つの問題を複数のチケットに分割するとスループットが水増しされる。VAM と ACM は件数ではなく Æ の比率であるが、それらと並べてチケット件数を目標に設定すべきではない。
• 受付の過小評価。反価値を過小に見積もると ACM が上がる。受付時の見積もりには、共通の尺度と、サンプリングによるクライアントの確認が必要である。
• 過剰なエスカレーション。上位のラインほど係数が高く出る場合、エスカレーションへの誘惑が生じる。それは、第3線が定めるエスカレーションルールに照らして判断されるべきである。
• 二重計上。同じ実現価値が複数のステージによって主張されうる。各単位は一度だけ割り当てる。
• 流入の隠蔽。最良の結果はサポートに届く反価値が減ることであるが、ACM にはそれが見えない。総流入量を係数と並べて報告し、その減少は成果として読み取らなければならない。
• シグナルの欠落。T14 によれば、解釈のない価値は失われる。ログには、提案やパターンのうち、いくつがプロダクトの意思決定に届いたかが示されるべきである。

8 サービスドメインとの関係

Æilus の方法論は、ドメインを、許容されるプラクティスと成果に要件を課す価値解釈のコンテキストとして定義している。ドメインは価値を生み出さず、許容されない反価値を防ぐ。サポートは、いくつかの典型的なドメインに関わる。

• Availability and Continuity.インシデントは、クライアントにとってこのコンテキストの侵害である。価値の流れを途切れなく維持するという第1線の責務は、その運用上の側面であり、ルーティングは重要度に関するドメインのポリシーに従うべきである。
• Security.方法論は、安全な参加に必要なコンテキストに違反するために、価値が拒絶されうることを指摘している。セキュリティを弱める回避策は、変換ではなく、新たな反価値として記録される。
• Architecture.原典は、第3線の決定について、アーキテクチャの整合性、スケーラビリティ、パフォーマンス、セキュリティを確認することを求めている。
• Knowledge Management と Continuous Improvement.第2線のナレッジベースと PDCA ループは、これらのドメインにおけるプラクティスである。

ここから2つの帰結が導かれる。ACM で数えられる実現価値は、関連するすべてのドメインで許容されるものでなければならない。そして ACM は、部分的にしか通約できないドメインにまたがって価値を集約する(A13)ため、方法論が VSO に割り当てる明示的な集約ポリシーが必要であり、ドメインのポリシーは Domain Owner が保持する。それがなければ、方法論が警告するとおり、最適化は局所的な選好や指標の操作へと堕してしまう。

9 例示的な実例

この例は仮想のものである。プロダクト、クライアント、数値は架空であり、意図的に切りのよい値にしてある。これらは調査結果ではなく、原典の係数を検証するものでもない。

あるプロダクトで、データインポート連携に繰り返し発生する障害がある。ある期間に、10のクライアントがそれを報告する。

• 受付。各クライアントの反価値は 10 Æ と見積もられ、したがって AV_received,1 = 100 Æ です。
• 第1ライン。既知の回避策と状況の更新により業務が回復し、クライアントは 120 Æ の実現価値を確認します。ACM_1 = 120 / 100 = 1.2 で、原典の公称範囲内に収まります。
• 第2ライン。設定に起因する根本原因が見つかり、修正されたデフォルト値とナレッジベース記事が、報告したクライアントとそれ以外のクライアントに届きます。確認された実現価値は 400 Æ です。ACM_2 = 400 / 100 = 4 で、公称の x10 を下回ります。プロトコルでは、これは修正すべき誤りではなく、検討すべき結果として扱われます。
• 第3ラインとプロダクト。インポートプロトコルが脆弱であると判明し、再設計と自動チェックが、計画価値 5,000 Æ としてロードマップに載ります。まだ何もリリースされていないため、このコーホートについては ACM_3 = 0 です。5,000 Æ は記録されますが、算入されません。
• 提案。2 件のクライアントが定期インポートを求めています。これは VAM トラックにおける潜在価値であり、ACM には入りません。

このレビュー時点では ACM_chain = (120 + 400 + 0) / 100 = 5.2 です。再設計が後にリリースされクライアントが価値を確認した場合、第3ラインのコーホートは遡及的に更新されます。リグレッションを引き起こした場合は、その反価値が第3ラインに対して記録されます。この例は、パイロットが観察すべき事項を示しています。最も深い段階での計画と実績の乖離(A4、A6)、実現の遅れ、そして公称係数からの乖離の可能性です。

10 限界

本稿にも原典にも、実地データはありません。係数 x1 から x1.5、x10、x100 は提案された桁の目安であり、記述されたメカニズム(1 つの修正が多数のクライアントに展開されること、新たな変換器が生み出されること)の上ではもっともらしいものの、測定はされていません。数式は、言葉による定義に対する本稿なりの解釈であり、他の解釈もあり得ます。Æ の見積りは解釈に依存します。これは A2 のもとでは価値の性質ですが、それでもチーム間の比較には較正された共通の尺度が必要であり、本稿はそれを提供していません。段階をまたぐ帰属は、規則なしに VSO へ割り当てられています。

このモデルを裏付ける、あるいは弱めることができるパイロットには、次のことを示す必要があります。

• 異なる人々が同じチケットに対して一貫した Æ の見積りを行うこと。
• 複数のレビューサイクルにわたるコーホート ACM が、絶対値にかかわらず、ライン別に予測された順序に従うこと。
• 実現価値が、申告したラインではなく、クライアントまたは合意された代理指標によって確認されていること。
• 係数の使用後に、第 7.4 節に挙げたゲーミングを伴わずに、反価値の総流入が減少したこと。
• サービス復旧時間などの従来の指標(Forsgren, Humble and Kim, 2018)を超える情報を、係数が付け加えること。

11 結論

サポートを単なるコストセンターとして扱うことは、境界の選択です。会社の財務システムではサポートはコストですが、クライアントのシステムでは反価値の除去であり、プロダクトのシステムでは、プロダクトがどこで失敗しているかについて最も直接的な情報です。原典のモデルは、レバレッジが第1ラインから第3ラインへ、さらに Product Owner チームへと大きくなり、クライアントへ戻る PDCA ループを閉じる変換器の連鎖を記述し、それを測定するために VAM と ACM を提案しています。本稿は、これらの係数に最小限の数式を与え、その分子をクライアントの価値システムに固定し、実現されドメインで許容される価値のみを算入し、記録、検証、レビュー、ゲーミングからの保護のためのプロトコルを提案しました。原典の桁の目安が成り立つかどうかは、パイロットだけが答えられる問いです。

参考文献

• Bolshakov, V. Technical Support Service - Anti-Value Conversion. aeilus.tech, 2025.
• Bolshakov, V. Domains and Policies. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Roles. Æilus methodology, aeilus.tech, 2026.
• 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.
• Forsgren, N., Humble, J. and Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.