これまで問題解決のフレームワークとして、リーンやシックスシグマ、そしてDFSS、時にはSAFe（Scaled Agile Framework、別のブログへ移行）について書いてきました。これからは新たにバリュー・メソドロジー（Value Methodology: VM）についても書けそうです。
バリュー・メソドロジー（VM）とは
僕にとってはバリュー・メソドロジー（VM）はまったく新しい問題解決のフレームワークなのですが、VM自体はとても古く、その起源は第二次世界大戦中のアメリカ（General Electric: GE）まで遡ります。今ではVMは世界中に広がり、多くの企業に使われています。
VMは価値分析（Value Analysis: VA）と価値工学（Value Engineering: VE）の二つから構成されます。価値分析（VA）は主に既存のアプリケーション（製品やプロセス、プロジェクト等）に応用され、一方の価値工学（VE）は新規のアプリケーションに応用されます。これはリーンシックスシグマが既存のプロセスや製品、そしてDFSS（Design for Six Sigma）が新規のプロセスや製品に応用されることと良く似ています。
価値分析も価値工学も内容的にはほとんど違いが無いので、厳密に言葉を区別する必要性はあまり無いかもしれません。実際には価値工学（バリュー・エンジニアリング）がよく用いられているようです。ここでは下記の価値管理（Value Management）と区別するために、VMの事をVA/VEとして記します。
価値管理（Value Management）
どんな問題を解決する時も「顧客にとっての価値を高める」ということを常に考えます。問題の種類によって選択する最適な問題解決のフレームワークは違いますが、どんなフレームワークも「顧客にとっての価値を高める」ということは同じです。そのため色々な問題解決のフレームワークを使っていたとしても、それらはすべて価値管理（Value Management）の下にまとめることができます。
実際にリーンシックスシグマやDFSS、VA/VEを採用する企業は、下図のような組織体制を取るところもあるようです。
なぜVA/VEが必要なのか
企業内に無駄なプロセスや設計、品質の悪い製造プロセスや製品などがあると、企業はリーンシックスシグマやDFSSを導入します。そして多くのリーンシックスシグマやDFSSのプロジェクトを立ち上げて、企業内の無駄を削減し、品質を高めていきます（つまり顧客価値の向上）。
しかし多くの場合、それらのプロジェクトは容易に解決できる問題（つまり簡単で費用が安く、しかも効果の高いプロジェクト）から始めます。つまりLow-Hanging Fruits、木の下の方にぶる下がっている果物からもぎ取っていきます。
リーンシックスシグマやDFSSを導入してからしばらくすると、残っているプロジェクトは難しいものばかりになります。つまり果物は木の高い所にしかなく、低い所には見つからなくなってしまうのです。
そうすると、高い木によじ登るリスク（またはコスト）を冒してまでもその小さな果物をもぎ取る必要があるのかどうか、その判断がとても難しくなります。多くの場合、プロジェクトの効果よりもプロジェクトのコスト（費用や時間）の方が高くなってしまうため、プロジェクトが実施されないことが多くなってきます。
（参考: 2001年までに、GEは8万人の社員にシックスシグマのトレーニングを授け、50万件のシックスシグマのプロジェクトを完了しました。それにより年間利益は66%も上昇しました。しかしその後、木の下にある果物をすべてもぎ取ってしまってからは、GEは長い間停滞し続けています。）
僕が所属する企業も似たような状態で、すでに木の下の方にぶる下がる果物はもぎ取ってしまい、残るは高い所の果物だけとなってしまいました。
そこで木の高い所の果物をもぎ取るために注目したのが、新しい問題解決のフレームワークVA/VEでした。VA/VEを使って、これまでとは違う視点から問題を解決し、顧客価値を高めようと思ったのです。
VA/VEの導入準備
まずはVA/VEの理解を深めるために、SAVE（Society of American Value Engineering）が主催するトレーニングを受けました。そしてさらに勉強してVMA（Value Methodology Associate）の認定試験に合格し、その資格を得ました。
その後社内でVA/VEの啓蒙活動と根回しを行い、VA/VEの協力者（スポンサー）を募りました。なぜならVA/VEが本当に効果のある問題解決のフレームワークなのかどうかを知りたかったからです。その甲斐あって、やっと最初のバリュー・ワークショップの実施に漕ぎ着けることができました。
バリュー・ワークショップのステップ
バリュー・ワークショップはその前段階と後段階を含め、様々なステップから構成されています。
準備段階（Preworkshop）
まずワークショップの本番を開催する前に、その準備を行いました。各部門の管理職を集めてワークショップに参加するメンバーを決めたり、ワークショップの目標（ここではコスト削減）を決めたり、また対象とする製品やコンポーネントを絞り込んだりしました。またワークショップの参加者には事前にVA/VEを説明し、その理解を深めてもらいました。
- チームメンバーを決定する
- バリュー手法（VA/VE）の説明する
- コスト削減策アイデアのブレインストーミングを行う
- ゴールと目標の決定する
- データを予備収集する
バリュー・ワークショップ段階（Value Workshop）
実際のバリュー・ワークショップでは以下のことを行いました。
- 情報フェーズ（それぞれのチームメンバーが事前に与えられた課題を調査し、その結果をチームメンバーに報告する）
- ファンクション分析フェーズ（VA/VEのツール類を使って、コスト削減対象を決定する）
- コンセプト創造フェーズ（様々なコスト削減アイデアを創造する）
- コンセプト探究フェーズ（多くのアイデアから最適なアイデアを選択する）
- 設計フェーズ（選んだアイデアを使って、新しい設計コンセプトを固める）
- プレゼンテーション・フェーズ（新しい設計コンセプトを報告する）
バリュー・ワークショップの中心的な活動であるファンクション分析フェーズについての詳細は後述します。
実施段階（Postworkshop）
新しい設計コンセプトを実施する段階です。
- バリュー・ワークショップのドキュメント化（新しい設計コンセプトを実施できるように資料をまとめる）
- 代替案の導入・実装（新しい設計コンセプトを導入・実施する）
- 代替案の管理（新しい設計コンセプトが定着するように管理する）
- 代替案の検証（新しい設計コンセプトが目標を達したかどうかを検証する）
ちなみに、このブログを書いている今は、まだ代替案の導入や実装段階に至ってはいません。
ファンクション分析フェーズ
ファンクション分析フェーズはバリュー・ワークショップの中で最も面白いフェーズです。色々なツールを使って顧客価値を決めるファンクション（機能）とリソース（コストや時間など）を洗い出していきます。
まずランダム・ファンクション分析を行って、コスト削減対象の製品（実際はコンポーネント）のファンクション（機能）をすべて洗い出しました。単純なコンポーネントでもたくさんの機能を持っていることに、チームメンバーは驚いていました。
次にコンポーネントのコストと洗い出した機能との対応表（ランダム・リソース・マトリックス）を作りました。どの機能がどれくらいのコストを使っているのか、つまり価値（= 機能 / コスト）について検討しました。検討の際は現在の価値とあるべき価値を比べて、期待できるコスト削減額も計算しました。その結果、顧客にとっての価値を下げずに7%のコスト削減が期待できることが分かりました。
コスト削減のための新しい設計コンセプト（アイデア）を創造する前準備として、ファンクション分析システム・テクニック（FAST: Function Analysis System Technique）ダイアグラムを作りました。FASTダイアグラムを使うことでチームメンバーの対象コンポーネントの理解が深まっただけではなく、アイデア創造の対象機能を絞り込むことができました。
FASTダイアグラムを使ってチームメンバーがコスト削減の対象の機能を理解した後、ブレインストーミングを行って、新しい設計コンセプトをいくつも考え出しました。
そしてその中から最も効果的なコンセプト（解決策）をいくつか選び出して合成し、新しい設計コンセプトを創り出しました。
バリュー・ワークショップの別の効果
7人のメンバーによるバリュー・ワークショップは、結局1日半で終わりました。1日半で問題を分析し、機能を洗い出し、コストを検討し、価値を高める新しい設計コンセプトを創ったのです。
このバリュー・ワークショップはリーンシックスシグマ（DMAIC）の測定段階（Measure Phase）と分析段階（Analyze Phase）に当たります。これまでの経験からリーンシックスシグマの測定段階と分析段階は60日以上掛かると言えるので、それに比べてバリュー・ワークショップは速さは圧倒的でした。
なぜ設計期間中のコスト削減が難しいのか
バリュー・ワークショップが初めから何事もなくスムーズに行ったわけではありません。実際は、既存製品（コンポーネント）のコスト削減を目標にしたときに、その製品を設計したエンジニア達から非常に強い抵抗を受けました。
設計エンジニア達の言い分は「すでに目標コストと要求仕様を満たした最適な設計だ。設計のどこに問題があるのだ！」というものでした。つまりコスト削減のための設計変更は彼らのエンジニアとしての誇りを傷つけるものだったのです。
コスト削減の必要性に迫られた理由は、市場での競争が原因でした。確かにエンジニア達は与えられた目標コストと要求仕様を満たしましたが、その数年にも及ぶ長い設計期間中に、市場も競合他社製品も変わってしまい、製品がリリースされた頃には、その製品の価格競争力が無くなってしまったのです。
どうしてそのようなことが起ってしまったのかを、バリュー・ワークショップを終えた後にチームで議論してみました。議論をまとめたものが以下の図です。
いくつかの問題はVA/VEを上手く使うことで解決できるのではないかと思いました。例えば長い設計期間中に定期的にバリュー・ワークショップを開催することで、目標コストの見直しを行ったり、無条件に増えていく要求仕様をVA/VEを使って顧客価値の視点からから制限したり、VA/VEを使って短時間のうちにコスト削減案を考えたりするというものです。
まとめ
VA/VEに懐疑的だった人達も、今回のVA/VEの小さな成功事例を見てから少し考えが変わったようです。これからはもっと多くのスポンサーを見つけては、VA/VEの応用が増えていくのではないかと思います。