「価値」の重要性はリーン生産方式でも同じだし、アジャイル・プロセス全体にとってもとても重要なものだ。});前回「制約理論を読みほどく」は制約理論+アジャイルという枠組みを読んだ。ここでは「価値」というものが大きな役割を担っていることがお分かりいただけたかと思う。「価値」の重要性はリーン生産方式でも同じだし、アジャイル・プロセス全体にとってもとても重要なものだ。試しにXPでもScrumでも適応型ソフトウェア開発でも、アジャイル・プロセスの教科書を開いてご覧なさい。そこには必ず「価値」というキーワードが見られるはずだ。何にしろ、良くしよう、頑張ろうと思うのならば「何のために」良くするのか、頑張るのかが問われるのである。制約理論で何を制約と考えるか、リーン生産方式で何をムダと考えるかは何を価値と見るかによって変わってくるはずだ。生産方式で、段取り替えのムダを許してもバッチ・サイズを小さくしようとするのは、その方がより大きなムダを取り除けると考えたからだ。段取り替えのムダと大きなバッチ・サイズというムダとの比較は、より大きな視点からの価値観があって初めて可能になる。先を見据えた価値観がなければ、取りあえず目先のムダをむしろ増やすことになる段取り替えに挑戦しようとはしないだろう。耐一、ダイヤモンド社、71ページ)。恐るべきビジョンと粘りである。ところが......、価値を考えるのは難しい。制約理論では価値を取りあえず「継続して利益を上げ続けること」と見なす。企業の場合には大方この価値観は当てはまるだろう。価値を簡単に測る、計算する方法はないものだろうか?生産工学の分野では「価値工学」というものが知られている。日本バリューエンジニアリング協会による価値工学の定義は次のようになっている。1993、23ページ)そして価値は次の式で与えられる。支払う犠牲(C)得られる効用を上げるか、支払う犠牲を減らすことによって価値を高めることができる。効用とは何か、犠牲とは何か、効用を上げ、犠牲を減らすためにはどうすればいいかを考えるのが価値工学というわけだ。効用としては品質、機能、タイミングなどがある。犠牲はコスト、消費エネルギー、時間、作業などである。いままでのモノ作り(製品)のための価値工学では効用は主に機能であり、犠牲とはコストであった。ソフトウェアをモノと見れば、機能を増やし、開発コストを下げればソフトウェアの価値は上がることになる。単純にそれを追求するとどういうことになるか。ソフトウェアには使われもしない機能が増えていき、目先の開発コストを下げるために2次請け、3次請け、オフショア開発が乱用される。開発者は疲弊し、ユーザー側も管理作業ばかりが増えていく。ソフトウェアをサービスと見れば、モノとは異なる価値のとらえ方が必要になる(実はいまやモノだってサービスとして見ることが要求されているのだが)。前掲書では、全10章/331ページのうち、1章/20ページだけがサービスにおける価値工学に充てられている。その中でサービスとは「モノと行為を関連付けるシステム」であるとして、次のようなマトリックスを掲げている(各行はモノを、各列は行為を表している)。例:インターネット検索そして、前掲書によればサービスに価値工学を適用するためのプロセスは次のようになる。(1)対象分野を明確化する組織のポリシー、経営目標を確認する。自分のサービス領域を先のマトリックスに位置付ける(もしかしたらこのマトリックスでは不足かもしれないし、これとは異なる切り口もあるかもしれない)。「サービスの流れ」を分析する。価値工学適用のためのチームを作り、計画を立てる。それらを盛り込んで達成すべき機能を定義する。トップダウンな機能定義とは、目的から考えて、その目的を達成するために必要な機能を順に割り出していく方法である。定義した機能を樹木図(機能系統図)にまとめてモレ・ヌケをチェックする。9126などとはかなり異なることが分かるだろう。このそれぞれに対して、何を重視するかに応じて寄与率と呼ぶ重み付けを行う。(4)機能/品質の達成度を随時評価する機能/品質とその評価尺度ごとに、現状値、目標値を算出する。これに対して次の式で表される値を貢献値と呼ぶ(後で使う)。貢献値とは、目標値を達成すればどれだけ価値の向上につながるか、という値である。(5)コストを把握する顧客がサービスへの対価として払ってもよいと考えるコストを把握する。コストには直接支払われるコスト(例えばパッケージ価格、開発費用)と間接的に支払うべきコスト(例えば教育費用、移行/運用費用)がある。コストと前項の機能/品質達成度との相関関係を調べる。(6)価値を把握し、評価するサービス価値は、で算出される。ここでは分母にコストを取っているが、実は「支払う犠牲」はそれ以外にもあるはずだ。支払う犠牲として時間が非常に重要な要因ならば(われわれの世界ではそういう場合も少なくない)、サービス価値は次のようにも表されるだろう(前掲書ではこの式は現れないが)。サービス価値の向上を時系列に従ってプロットし、現在のサービス価値がその延長線より上にあればよし、下ならば目標値を再設定したり、機能を見直したり、コストを下げる努力が必要になる。そのために次のステップを行う。呼ばれているものである。モノ作りの現場だとTRIZ(トゥリーズと呼ぶ。2003)などが知られているが、世界中にはそれ以外にもたぶん無数にある。モノ作りの現場で重視されている「発想」や「創造」は、ソフトウェアの世界では意外と軽視されているのではないだろうか。(8)具体案を作成し、提案、実施する考え出されたアイデアを組み合わせて改善案とし、計画を立て、実施する。以上が価値工学において考えられている「サービス価値を高める」ためのプロセス(サイクル)である。これを「サービス」価値工学と呼ぶにはまだまだ「機能」や「コスト」がハバを利かせ過ぎているような気もするが、ソフトウェアをサービスと考えたいのならば、価値をこのようにとらえてみることも一度は必要かもしれないと同時に、サービスとしてのソフトウェアの価値計算論を考えていかなければならないだろう。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。