| « 2006年3月17日 | 2006年3月18日の投稿 |
2006年3月20日 » |
3月17日に行われた要求開発のパネルディスかションで、「ビジネス設計」（ユーザ側、発注側）と「システム設計」（ベンダー側、受注側）の間をどう埋めるか、という議論がおもしろかった。
日本総研の細川さんが、その２つの間に点線を引いていたのを、システム側からビジネス側に食い込む斜め線をひき、システム側からビジネス側に押し出すような三角形にし、このデルタ地帯を「黒い三角形」と呼んだ。
豆蔵の萩本さんは、「現にビジネスの設計においてITを抜きでは語れない」ことから、そもそも現在、この点線分割が出来ないことを主張した。動くものを見てみないと、話にならないことが多いのだ。これは、アジャイルの立場とも強く符合する。
ぼくが最もおもしろいと思ったのは、甲府市役所の土屋さんの意見。「システムの側からも、工夫してビジネスの要求を聞き出して欲しい」ということ。「射止めたい異性のためには、さまざまな工夫をしてコミュニケーションを取ろうとするであろう。この工夫を、ベンダー側にお願いしたい」という。自治体では設計・施工の分離から、法的にこの点線は必要になることがある。
また、マイクロソフトの安藤さんは、「とは言ってもユーザ側もそのITによって支えられるビジネスやサービスが事業のコアとなる部分であるなら、丸投げにせず、しっかり理解してビジネス設計すべきである」と。そして、NEC情報システムの猪狩さんも、「要求の把握には、すばやいフィードバックが不可欠である」と。
これらの意見を聞きながら、平鍋が思ったこと。
ITでは、設計・施工の分離、「ビジネス設計」と「システム設計」の分離は難しい。特に、それを文書で分割はできない。なぜなら、
ビジネス設計情報とシステム設計情報は sticky である（場所を移動しにくい）。すなわち、形式知化して他者に伝えようとすると、漏れてしまう情報の分量が多いのだ。
ビジネス⇒システムの例は、システムへの「思い」とか「こんなことで今困ってるんだ！」とかそういう熱を持った情報。システム⇒ビジネスの例は、こんな風に使えます、と実際に動くものを見せてはじめて伝わる発見的情報など。発見的情報は、フィードバックが不可欠だ。要求開発、システム開発のような悪構造問題（ill-structured problem）においては、問題の理解と解決は同時に起こる。
こういう暗黙知を伝えるには、点線を渡る際に、同じ人の頭の中で一貫した意図を持ち続けること、そして、徹底的に関与する人と「場を一つにして」話をすること。
つまり、点線を渡るには必殺仕事人よろしく、「要求開発人」として一貫してシステムに関わる人が不可欠であり、その人が意図をもって、場を形成し、話続け、フィードバックを得続けることではないか？そうでないと、
「紙になった仕様書」を壁越しに投げても、全く使えないシステムが出来てしまうことを防げない。
最後に、細川さんが「この黒い三角形が「黄金の三角形」になるように、要求開発を発展させていきましょう」と締めくくった。うまい！
| « 2006年3月17日 | 2006年3月18日の投稿 |
2006年3月20日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命