連載
» 2007年01月31日 12時00分 公開

ソフトウェア開発をちゃんと考える(10):価値工学とソフトウェア開発

「価値」の重要性はリーン生産方式でも同じだし、アジャイル・プロセス全体にとってもとても重要なものだ。

[山田正樹,メタボリックス]

 前回「制約理論を読みほどく」は制約理論+アジャイルという枠組みを読んだ。ここでは「価値」というものが大きな役割を担っていることがお分かりいただけたかと思う。

 「価値」の重要性はリーン生産方式でも同じだし、アジャイル・プロセス全体にとってもとても重要なものだ。試しにXPでもScrumでも適応型ソフトウェア開発でも、アジャイル・プロセスの教科書を開いてご覧なさい。そこには必ず「価値」というキーワードが見られるはずだ。つまり何にしろ、良くしよう、頑張ろうと思うのならば「何のために」良くするのか、頑張るのかが問われるのである。

 制約理論で何を制約と考えるか、リーン生産方式で何をムダと考えるかは何を価値と見るかによって変わってくるはずだ。例えばリーン生産方式で、段取り替えのムダを許してもバッチ・サイズを小さくしようとするのは、その方がより大きなムダを取り除けると考えたからだ。しかし、段取り替えのムダと大きなバッチ・サイズというムダとの比較は、より大きな視点からの価値観があって初めて可能になる。先を見据えた価値観がなければ、取りあえず目先のムダをむしろ増やすことになる段取り替えに挑戦しようとはしないだろう <注>。


<注> トヨタは20年以上かけて段取り替えにかかる時間を2〜3時間から3分にまで短縮したという(「トヨタ生産方式」大野 耐一、ダイヤモンド社、71ページ)。恐るべきビジョンと粘りである。


 ところが……、価値を考えるのは難しい。制約理論では価値を取りあえず「継続して利益を上げ続けること」と見なす。企業の場合には大方この価値観は当てはまるだろう。しかし、自分のプロジェクトの「価値」は何かと問われて即座に答えられるだろうか? 価値を簡単に測る、計算する方法はないものだろうか?

 生産工学の分野では「価値工学」というものが知られている。日本バリューエンジニアリング協会による価値工学の定義は次のようになっている。

 「価値工学とは、最低のライフサイクルコストで、必要な機能を確実に達成するため、製品とかサービスの機能分析に注ぐ、組織的努力である」(「実践 価値工学―顧客満足度を高める技術」手島直明、日科技連出版社、1993、23ページ)

 そして価値は次の式で与えられる。

価値(V) = 得られる効用(F) / 支払う犠牲(C)

 得られる効用を上げるか、支払う犠牲を減らすことによって価値を高めることができる。効用とは何か、犠牲とは何か、効用を上げ、犠牲を減らすためにはどうすればいいかを考えるのが価値工学というわけだ。

 効用としては品質、機能、タイミングなどがある。犠牲はコスト、消費エネルギー、時間、作業などである。もっともいままでのモノ作り(製品)のための価値工学では効用は主に機能であり、犠牲とはコストであった。ソフトウェアをモノと見れば、機能を増やし、開発コストを下げればソフトウェアの価値は上がることになる。しかし、単純にそれを追求するとどういうことになるか。ソフトウェアには使われもしない機能が増えていき、目先の開発コストを下げるために2次請け、3次請け、オフショア開発が乱用される。開発者は疲弊し、ユーザー側も管理作業ばかりが増えていく。

 一方、ソフトウェアをサービスと見れば、モノとは異なる価値のとらえ方が必要になる(実はいまやモノだってサービスとして見ることが要求されているのだが)。前掲書では、全10章/331ページのうち、1章/20ページだけがサービスにおける価値工学に充てられている。その中でサービスとは「モノと行為を関連付けるシステム」であるとして、次のようなマトリックスを掲げている(各行はモノを、各列は行為を表している)。

  移動する 貸与する 代行する
例:タクシー 例:人材派遣 例:教師
例:宅急便 例:リース 例:小売り
金/権利 例:金融 例:クレジット 例:保険
情報 例:IP 例:図書館 例:インターネット検索

 そして、前掲書によればサービスに価値工学を適用するためのプロセスは次のようになる。

(1)対象分野を明確化する

 組織のポリシー、経営目標を確認する。自分のサービス領域を先のマトリックスに位置付ける(もしかしたらこのマトリックスでは不足かもしれないし、これとは異なる切り口もあるかもしれない)。「サービスの流れ」を分析する。価値工学適用のためのチームを作り、計画を立てる。

(2)達成すべき機能/品質を定義する

 基本機能をトップダウン(演繹的)に定義する。問題点、要求、制約などを整理する。それらを盛り込んで達成すべき機能を定義する。トップダウンな機能定義とは、目的から考えて、その目的を達成するために必要な機能を順に割り出していく方法である。定義した機能を樹木図(機能系統図)にまとめてモレ・ヌケをチェックする。

(3)機能/品質の評価基準とその重み付けを決める

 サービスの評価項目(書中では評価因子と呼んでいる)の例として以下のような項目が挙げられている。

  • 基本機能
  • 過剰性
  • 信頼性
  • 快適性
  • 嗜好性
  • 融通性
  • 対応性
  • 簡便性
  • 迅速性
  • 優越性

 これはあくまで例でしかないが、通常ソフトウェアの品質属性として挙げられるISO/IEC 9126などとはかなり異なることが分かるだろう。

 このそれぞれに対して、何を重視するかに応じて寄与率と呼ぶ重み付けを行う。

(4)機能/品質の達成度を随時評価する

 機能/品質とその評価尺度ごとに、現状値、目標値を算出する。これに対して次の式で表される値を貢献値と呼ぶ(後で使う)。

ALT

 貢献値とは、目標値を達成すればどれだけ価値の向上につながるか、という値である。

(5)コストを把握する

 顧客がサービスへの対価として払ってもよいと考えるコストを把握する。コストには直接支払われるコスト(例えばパッケージ価格、開発費用)と間接的に支払うべきコスト(例えば教育費用、移行/運用費用)がある。コストと前項の機能/品質達成度との相関関係を調べる。

(6)価値を把握し、評価する

 サービス価値は、

ALT

で算出される。ただしここでは分母にコストを取っているが、実は「支払う犠牲」はそれ以外にもあるはずだ。例えば、支払う犠牲として時間が非常に重要な要因ならば(われわれの世界ではそういう場合も少なくない)、サービス価値は次のようにも表されるだろう(前掲書ではこの式は現れないが)。

ALT

サービス価値の向上を時系列に従ってプロットし、現在のサービス価値がその延長線より上にあればよし、下ならば目標値を再設定したり、機能を見直したり、コストを下げる努力が必要になる。そのために次のステップを行う。

(7)アイデアを発想する

 いわゆる創造的思考、発想法などと呼ばれているものである。モノ作りの現場だとTRIZ(トゥリーズと呼ぶ。例えば「TRIZ入門」 V. R. Fey/E. I. Rivin/畑村洋太郎、日刊工業新聞社、1997)や創造設計原理(「創造学のすすめ」畑村洋太郎、講談社、2003)などが知られているが、世界中にはそれ以外にもたぶん無数にある。モノ作りの現場で重視されている「発想」や「創造」は、ソフトウェアの世界では意外と軽視されているのではないだろうか。

(8)具体案を作成し、提案、実施する

 考え出されたアイデアを組み合わせて改善案とし、計画を立て、実施する。

ALT

 以上が価値工学において考えられている「サービス価値を高める」ためのプロセス(サイクル)である。これがソフトウェアの世界にどこまで適用可能だろうか? これを「サービス」価値工学と呼ぶにはまだまだ「機能」や「コスト」がハバを利かせ過ぎているような気もするが、ソフトウェアをサービスと考えたいのならば、価値をこのようにとらえてみることも一度は必要かもしれないと同時に、サービスとしてのソフトウェアの価値計算論を考えていかなければならないだろう。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ