次ページ  目次

開発&コンサルティング

第20回 新しいVE(価値工学)の考え方

今回はVEの専門家に読んでもらいたいと思います。と申しましても、VEを全く知らない人にもわかるように書きます。VE技術は非常に優れた改善・改革・開発技術で、活用の仕方次第では驚くほどの効果を発揮します。しかし、この技術を身につけるのは非常に大変です。それは、この技術を習得するのが難しいからではなく、VEそのものに多くの問題点があるからです。これらの問題点が、VE本来の考え方を生かせない原因になっているのです。これらの問題点については第7回で既に書いてありますが、今回はその問題点を解決して、私なりの新しいVEの考え方を提案してみようと思います。

その前に、ひと言言いたいことがあります。6月25日の日経の夕刊のコラム『十字路』にVEのことが書いてありました。私はこれはまずいと思いました。誤解されやすいからです。VEの初歩的なテキストを読んでいれば、こんな書き方はしなかっただろうと思います。この記事には次のように書かれていました。

「VEとは、建設業で一定の価値(機能と品質)を、より低いコストで実現するための様々な手法を総称して言うが、・・・・・・。」

これを見ると、まるでVEは建設業だけで使われる手法だと思われてしまいます。また、これはVEを定義していますが、定義はかってに行うものではありません。日経新聞がかってに定義してしまうと経済界に多大な悪影響を及ぼすことになります。

(社)日本バリュー・エンジニアリング協会では、「VEとは、最低の総コストで、必要な機能を確実に達成するために、組織的に、製品、又はサービスの機能の研究を行う方法である」と定義しております。VEはもちろん、建設業だけで使われる手法ではありません。

そもそも、この技術は、当初、アメリカのGE(ジェネラル・エレクトリック)社のローレンス・ D・マイルズ氏が購買品のコストダウン手法を開発し、それをVA(価値分析)と名付けたものです。その後、アメリカ国防省で採用し、企画、開発、設計、製造の各段階におけるコストダウンや新製品開発の技術として発展し、VE(価値工学)として多くの民間企業に普及したものです。

そして、現在では世界中のあらゆる業界の企業や官庁などで活用されているのです。また対象は製品、サービスだけでなく現場作業、業務(デスクワーク)、組織にも応用されております。現在では業務改革とか組織改革にはなくてはならない技術となっています。なぜなら、「目的と機能(働き、役割)を研究する方法」ですから、どんな対象にでも活用できるのです。たとえば、その部品は何のために存在し、どのような役割を果たすべきかとか、その仕事は何のために存在し、どのような働きをすべきか、などVE技術は何にでも活用出来るのです。

さて話を元に戻しまして、新しいVEの考え方についてですが、まず、VEの主な問題点を整理しておきましょう。

  1. 価値概念が一般的なものとは異なるので理解しにくい。 VEでは、使用価値と貴重(美的)価値を対象とするが、価値=機能/コスト(価格)である、としている。
  2. 機能研究が重要であるにもかかわらず、機能の定義が曖昧である。 VEでは、機能とは、(1)働き(役割)である、(2)目的と働きである、(3)目的と働きとその達成度である、と3つの言い方がある。しかも、達成度は機能を制約する条件であるとしている。
  3. 「同じ機能を果たす方法はたくさんある」というVE本来の考え方を生かしていない。 VEの目的は機能研究を徹底的に行った上で、不要機能、過剰機能、重複機能などを発見し、これらを削減するとともに、必要機能をより安く、より正しく、より速く、より楽に、より安全に、より確実に達成出来る方法を発見、または発想し、より良いものにすることにある。しかしながら、この方法が明確になっていない。しかも、アイデア発想の方法がない。既存のブレーンストーミング法などを紹介しているに過ぎない。
  4. 機能表現(機能の命名)にこだわり、本来の目的を忘れてしまっている。 本来、機能表現を行う目的は、アイデア発想をしやすくするためである。ところが、日本語の文法にこだわり、表現が限定されてしまうため、アイデア発想があまりできない状況になっている。

以上がVEの主な問題点です。さてこれから、以上の問題点を解決することにします。第7回で書いたものと一部重複しますがご容赦ください。まず1番目ですが、この式は、価値は機能に比例し、コスト(または価格)に反比例するというものです。たとえば、機能が一定として、ある商品の価格が半分になるとその商品価値は2倍になる、というのです。しかし、これが一般には理解出来ないのです。価格が変わっても商品価値は変わらないと考えるのが普通です。当たり前でしょう。商品価格と商品価値とは何の関係もないのですから。これは経済学の初歩的な教科書にも書いてあります。

実は、これは生産者の立場で考えると理解できます。つまり、コストが半分になると利益は2倍になる。だから価値が2倍になると考えたのです。これならお分かりでしょう。つまり、この価値概念は元々生産者の考え方だったのです。それが顧客指向が叫ばれるようになってコストを価格に置き換えて考えようとしたためおかしくなったのです。

しかも、実際にはコストが半分になっても利益は2倍にはなりません。ですから、いずれにしても、この式は間違っています。VEの専門書には、この式は考え方の式(思想式)で、計算式ではない、とか、価値ではなく価値指数であるとか、価値の程度を表すものだ、などと書かれていたりしますが、いずれにしてもごまかしです。

次に2番目ですが、(1)が正しいのです。目的と機能は別のものです。目的を果たすのが機能です。また、機能を下位から見れば目的になるのです。同様にその目的はさらにその上位の目的から見れば機能になるのです。見方によって同じものが目的になったり機能になったりするわけです。親子孫の関係と同じです。子供は親から見れば子供であっても、孫から見れば親なのです。一方、達成度というのは、機能がどの程度達成したかの度合いですから、機能とは別のものです。なぜなら、機能は抽象的なことばで表し、達成度は具体的な数値で表すからです。

3番目ですが、これが最も重要です。まず、機能が明確になったところで、不要機能か過剰機能か必要機能かなどをどうやって判断するのでしょう。判断基準があるのでしょうか。それはありません。それなのに判断しようとするから難しくなってしまうのです。では、本来は誰がどのように判断するのでしょうか。それは、消費者(ユーザー)が主観で判断するのです。当然です。その製品やサービスを利用する人が判断するのですから。製品やサービスであれば消費者、業務であればその業務のユーザーが判断するのです。ですから、消費者やユーザーに聞けば良いのです。

たとえば、消費者にこの機能は必要だと思いますか?と聞くのです。あるいは、この仕事はどんな役に立っているのですか、とユーザーに聞くのです。開発設計段階で設定した機能が、消費者(ユーザー)からみれば不要だったり過剰だったりするので、それを発見して削減するのです。設計者が消費者(ユーザー)の立場で考えてもわかるときがあります。この当たり前のことを多くの企業では行わないから、コストダウンの成果が上がらないのです。

最後に4番目ですが、ことばの文法には例外がつきものです。また、ことばは生き物です。文法にこだわれば余計おかしな表現になってしまうことがあります。ですから、文法を無視すれば良いのです。要は如何に簡潔にかつ的確に表現するかです。このためには、ことばのセンスが必要です。言うなれば作家、翻訳家、コピーライターなどのセンスが必要になってきます。ですから難しいのです。

ではどうするかですが、実は簡単なのです。辞書を活用すればよいのです。特に類語辞典などは非常に有効です。作家が頭でイメージしたことを的確なことばで表現しようとする時に使うのが類語辞典です。この辞典の使い方に慣れるとたちまち数百の類語が出てきますので、その中から最も的確なことばを選べば良いのです。

さて次に、必要機能を果たすより良い具体的な方法、つまり、仕様や方法をどうやって発見、または発想するかです。通常、数人でブレーンストーミングなどを行ってアイデア発想するわけですが、元々限られた知識と経験の人たちで画期的なアイデアを発想しようとしてもムリなのです。良いアイデアを出す方法は、すでに第3回で書きましたがもう一度書きます。これも簡単です。

まず、その機能を果たす方法についていろいろな人に聞くのです。たとえば「AとBを結合する」という機能の方法は、機械屋でしたら溶接とかボルトナットとか接着などと答えるでしょう。電気屋でしたらコードでつなぐとかスイッチを入れるとかと答えるでしょう。また、植木職人だったら接ぎ木とかでしょう。漁師だったら釣り糸で結ぶ、動物好きだったら交尾と答えるかもしれません。

つまり、同じ機能を果たす方法は世の中にたくさんあるのです。何百、何千、何万とあるのです。だから人に聞いても良いし、百科事典で調べても良いのです。インターネットで調べてもよいのです。それらを参考にアイデア発想すればきっと良いアイデアが浮かんでくると思います。限られた人たちでブレーンストーミング行ってもあまり良いアイデアは発想できません。

以上、私の新しいVEの考え方はいかがでしたか。簡単で効果的でしょう。大いに活用してください。より詳しく知りたい人は、『文科系のためのコスト削減・原価低減の考え方と技術』(電子書籍、アマゾンで販売)、又はコスト削減・原価低減をご覧ください。

Ⓒ 開発コンサルティング

次ページ  目次