変幻する実行可能知識 22セル, 制約, 価値, アジャイル III前回は制約理論+アジャイルという枠組みを読んだ. ここでは「価値」というものが大きな役割を担っていることがお分かりいただけたかと思う. 「価値」の重要性はリーン生産方式でも同じだし, アジャイル･プロセス全体にとってもとても重要なものだ. 試しにXPでもScrumでも適応型ソフトウェア開発でも, アジャイル･プロセスの教科書を開いてご覧なさい. そこには必ず「価値」というキーワードが見られるはずだ. つまり何にしろ, 良くしよう, がんばろうと思うのならば「何のために」良くするのか, がんばるのかが問われるのである. 制約理論で何を制約と考えるか, リーン生産方式で何をムダと考えるかは何を価値と見るかによって変わってくるはずだ. 例えばリーン生産方式で, 段取り替えのムダを許してもバッチ･サイズを小さくしようとするのは, その方がより大きなムダを取り除けると考えたからだ. しかし段取り替えのムダと大きなバッチ･サイズというムダとの比較は, より大きな視点からの価値観があって始めて可能になる. 先を見据えた価値観がなければ, とりあえず目先のムダをむしろ増やすことになる段取り替えに挑戦しようとはしないだろう (注1).
ところが ...... 価値を考えるのは難しい. 制約理論では価値をとりあえず「継続して利益を上げ続けること」とみなす. 企業の場合にはおおかたこの価値観は当てはまるだろう. しかし自分のプロジェクトの「価値」は何かと問われて即座に答えられるだろうか? 価値を簡単に計る, 計算する方法はないものだろうか? 生産工学の分野では「価値工学」というものが知られている. 日本バリューエンジニアリング協会による価値工学の定義は次のようになっている.
そして価値は次の式で与えられる. 価値 (V) = 得られる効用 (F) / 支払う犠牲 (C) 得られる効用を上げるか, 支払う犠牲を減らすことによって価値を高めることができる. 効用とは何か, 犠牲とは何か, 効用を上げ, 犠牲を減らすためにはどうすればいいかを考えるのが価値工学というわけだ. しかしどうも価値工学もいまいちな感じ, つまり我々が重要だと思う価値の側面をよく表し切れていない感じがする. それはなぜだろうか. 価値工学では, 価値は独立した製品やサービスに付与されるものであった. 何かモノを作り, 計算をすると「価値XXXを持つ製品」というものが存在することになる. 価値工学のおかしさはどうもその辺りにあるのではないか. あるモノそれ自身に価値が貼り付いているというのはおかしかないか. 価値はモノの側ではなく, モノを使う側にあるはずであり, もっというと価値はモノとモノの間にあるように思えないか. ここでは価値工学におけるものとは異なる定義, もう少し自分たちの (実行可能知識としての) 直観に近いと思われる価値の定義を考えてみよう. 「価値とは, それを使って別の価値を生み出す可能性である」 再帰的になっている. 何かお金にも似ている. まぁ, お金は価値を抽象化したものだから当然なのかもしれない. ただし一般的に価値はお金のように蓄えることができないし, ひと一人ひとりによって価値観, 価値の尺度は異なる. でも価値は「流れる」. 例えばAさんという旅行代理店を経営している人がいたとする. 今までの形態の旅行代理店ではだめだ, 何とかしようということで素晴らしいアイデアを思いついた. もちろんアイデアだけではビジネスはできないので, 設備や人やお金などと一緒に, アイデアを具体化した「動くソフトウェア」も必要になる. ITというやつですな. ここで我々ソフトウェアを作る人間の立ち位置はどこだろう.  箱にくっついている風船みたいなのは, それぞれの「価値」と思ってほしい. この図には「Aさんのアイデア」というモノを「動くソフトウェア」というモノに「変換」するのが「ソフトウェア開発」というコトだ, ということが描かれている. このようにあらゆる仕事を「あるモノ (の状態) を別のモノ (の状態) に変換するコト」と捉える考え方は「もの・こと分析」(「もの・こと分析で成功するシンプルな仕事の構想法」中村善太郎, 日刊工業新聞社, 2003) から借りてきた. この本ではおもに金物 (ハードウェア) が扱われている. ソフトウェアやサービスについても少しページが割かれているが, ちょっともの足りない. もの・こと分析では「ムダを省くこと」ではなく, 「要 (かなめ) のもの・ことを掴んで, できるだけシンプルにする」ことを重視する. これは我々にとっても本質的な点のはずだ. さて, 開発の価値 v1, Aさんのアイデアの価値 v2, 動くソフトウェアの価値 v3はいくらになるだろう. v1が我々が頂くおまんまに相当することになる. もっとも単純に考えれば, v1 = v3 - v2 となる. とすると, 次にv3とv2はいくらになるだろう. まずv3を考えるにはこのソフトウェアの立ち位置を考えなければならない.  この図でBさんはAさんの旅行代理店の顧客だ. 今まで出張の1週間前には日程を決めなければならなかったのが, このシステムを使うことによって, 日程は1日前に決めればよく, 経費も10%下げることができた. とすると, v3 = v5 - v4ということになる. v1 = v3 - v2 = v5 - v4 - v2 もちろんBさんの出張も仕事だから, 何かから何かへの変換に違いない. v4とv5はその変換の価値によって決まるはずだ.  v5 = v9 - v8, v4 = v7 - v6. v1 = v5 - v4 - v2 = v9 - v8 - (v7 - v6) - v2 v2も同じ. 以下いつまでも続く. 下にも続くし, 上にもあるだろう. Bさんの仕事もいつかは回り回って, 我々の開発に価値を与えてくれるかもしれない. もちろんこの図は世の中というものを極端に単純化している. それでもこんなにややこしいのである. だから, この考え方だけでは我々がいくらお金を頂戴するのがちょうどいいのかは, 永遠に決まりそうにない(注2). どこかでえいやっと決めるしかないのだ, 残念ながら.
とはいえ, 今までの議論からいくつか分かることもある. ひとつは, ここには価値の流れ (というよりも実際には価値の網の目というべきか) があるということだ.  何を価値とするかはそれを受け取るひと (ここではAさんやBさんなど) によって異なるのだけれど, どんな価値にしろ, 価値の流れがなければ, 仕事 (我々にとっては開発業務) というものは意味がないのである. もう一つは, この中からひとつの変換過程だけを取り出して見たとき,
だ. なぜならそれが価値の流れを決定するから. この流れの中に「詰まり」があると, その流れはやがて干上がってしまうか, 溢れてしまう. あるいはやがて, その詰まりをよけて新しい流れができるかもしれない. ここまでは「価値の流れ」というものを見てきた. しかし, 実はここに流れているのは価値だけではない. 価値の流れに沿って (方向は逆の場合もあるし, 別の経路をたどる場合もあるかもしれない) さまざまな流れがある. だからこそ価値も流れる. そういう意味では, 価値の流れは単純な川 (stream) というよりは, 電流や血流に近いのかもしれない. まずたいていの商業的な開発の場合には「お金」, あるいはそれに相当する何らかの報酬が価値の流れとは逆方向に流れているだろう. この二つの流れはバランスしていなければならない. しかしそれだけではダメで, 価値の流れには次のようなものが流れているはずだ.
 制約は価値の流れと同じ方向に流れる場合もあれば, 逆方向に流れることもある. 制約の多くは技術的なものであったり, 政治/制度/ポリシ的なものであったりする. 制約の流れは目に見えない, 伏流である場合が多いことが問題を困難にする. 価値の流れをよくするためには, それに伴うこれらの流れもよくすること, 透明度を上げることが重要になるだろう. |