概要
今回は3月に拙著「すりあわせの技術」をダイヤモンド社から出版した[1]ので、価値星座の考え方と関連付けながら紹介することにしよう。
ところで、次に紹介するような「すりあわせの技術」がなぜ必要になるかといえば、世界が変化するからだ。世界が変化することで、これまでの仕組みに隙間ができる。この隙間を埋めるためには、既成概念の見直しも含めた新しい仕組みの創造が必要だ。この新しいイノベーションによって、世界がさらにまた変化することになる。このような世界についての絶え間のない変化に対応するためには、すりあわせが絶えず求められることになるだろう。
すりあわせの技術
広辞苑で「すりあわせ」を引くと次の2つの意味が紹介されている。
①「高精度な平面を作るための手仕上げ作業のこと」で、表面を摺合わせ定盤で摺り合わせ、きさげで削って仕上げることを指すもの」
②「それぞれの意見や案を出し合い調整してゆくこと」
私が考えるすりあわせは、この2つの意味を組み合わせたものだ。
オープン・イノベーションでは、外部で開発された要素技術を活用して新しい製品やサービスを創造するために、それぞれが持つ強みを出し合い、境界面に隙間がないように相互に補完しながら調整していくことが求められる。このとき、それぞれが自分のことだけ考えていたら共通の課題を解決できないから、それぞれの境界を越える努力が必要になる。それがイノベーションの源泉になるはずだ。
既存の技術やサービスを組み合わせるだけでなく、要素としてこれらの部品が持つ特徴を生かしながら、それらを適切に結合するために分解して隙間をきれいに埋めるところに新しい意味を込めたつもりだ。
すりあわせの技術を再掲すると表1に示す9つの考え方になる。
技術 | 説明 |
---|---|
価値指向 |
業務が生む価値を考えてそれに見合うコストで開発 |
顧客指向 |
業務環境と顧客を明確にして開発 |
活用指向 |
顧客による活用を前提にして開発 |
オープン・イノベーション |
あるものを組み合わせて使用 |
つながり指向 |
隙間の確認に基づき業務・ ITの境界を繋ぐ連携要件を発見 |
分解と再結合 |
オープンイノベーションのために要素に分解して再結合 |
構造化・相対化・統合化 |
業務要件を構成要素に分解し、相互比較することで業務目標に応じて統合化 |
情報共有 |
プロジェクト中に発生した課題と解決策をプロジェクト間で共有 |
進化指向 |
開発後の活用状況に基づいて業務目標を評価し変革を継続 |
(1)価値指向
業務が生む価値をまず考えた上で、それに見合うコストでサービスを開発する必要がある。
従来のようなコストベースの開発ではなく、価値ベースの開発への転換が求められる。
(2)顧客指向
業務環境と顧客を明確にしてサービスを開発する必要がある。
従来は開発者の視点からサービスを開発することが多かった。これがサービス開始間際になってから要求変更が多発したり、サービス開始後の仕様変更になったりする原因ではなかったか?顧客視点でサービスを開発することによって、これらの問題を解決することが求められている。
(3)活用指向
顧客によるサービスの活用を前提にして開発する必要がある。これも顧客指向と同じように、従来はサービス開発がまずあって、その後でサービスの運用をどうするかを直線的に考えてきた。このため、要求とテストの回で紹介してきたように開発者が考えるようなサービスの機能を運用担当者が考えないことがあり、そのために運用トラブルになったりすることが多発するのである。
したがって開発者がサービスの活用を自分達だけで考えるのではなく、実際にサービスを活用する現場とともにサービスの活用のあり方を明確にすることが求められている。
(4)オープン・イノベーション
前述したけれども、オープン・イノベーションではすべて自前で開発するのではなく、あるものを組み合わせて使用することで新しい製品を創造する。連載でも紹介したが、最近はずいぶん日本でもオープン・イノベーションの概念が理解されるようになってきた。筆者が参加するある省の委員会でも、盛んにオープン・イノベーションの必要性が指摘されていた。Chesbrough教授のオープン・イノベーションの本[2]では「技術そのものに価値はない。ビジネスモデルが顧客価値を生む」と述べられているので、私の講演でも良く使っているが、これがなかなか理解されないことがある。「技術そのものにも価値があるはずだ。けしからん」と怒られたことが何回かある。この概念を提唱したChesbrough教授は、サービスサイエンスについての研究課題をまとめている文献[3]の最後で「価値を協働して創出するためのvalue co-creation理論」が必要であると指摘している。
いずれにしろ、すべてを所有することはできなくなった。これからはどう所有するかではなく、何をどのように利用するかを考えたサービスが求められている。
(5)繋がり指向
隙間としての問題を確認することによって、業務とITの境界を繋ぐあたらしい連携要件を発見することができる。だれかが隙間を指摘すると
「あー、それはできないんですよね。わたしも気づいているんですが、自分の問題ではないですから。」
としてそのままに放置されていることがある。実は、それを繋ぐのがすりあわせだ。
古い友人と最近再会してちょっと飲んだときのことである。私が、
「日本では専門家というと、自分の専門という穴を縦に深く掘るだけで穴の外を見ようとしない人が多いよね」と言うと、
「いやいや、最近は穴の上からじっと穴の中で穴を掘る人をただ覘いて見ているだけの人が増えてきたんだよ」
と教えてくれた。それならまだ穴を掘るだけでもましではあると妙に感心したが、覘いているだけでは隙間も見えないことだろう。
隙間を認識するだけではなく、繋がりを実践するところから新しいサービスを生み出すことが求められている。
(6)分解と再結合
オープン・イノベーションを実現するためには部品を組み合わせるだけではなく、要素に分解して適切に再結合する必要がある。最初から組合せが分かっていることはほとんどない。
個としての要素を、全体へどのように再結合すべきかをデザインするためのアーキテクチャが求められている。
(7)構造化・相対化・統合化
業務要件を構成要素に分解し、相互比較することで業務目標に応じて統合化する必要がある。これは分解と再結合を実践するための考え方である。
そのためには、主観ではなく客観的な判断が求められている。そのためにはサービス対象を構造化し相対化することで、客観的に比較することによって統合していくことが求められるのは当然ではないのか?
最近ある新聞を読んでいたら、ある時代の日本の報道内容は、事実に基づかない一方的な主観と判断で埋め尽くされていたそうである。これに対して欧米の報道は、事実を客観的に述べていくことが結果として非常に説得力のある内容になっていたそうである。科学的報道と呼ぶべきだ。主観的サービス開発ではなく、科学的サービス開発が求められている。
(8)情報共有
プロジェクト中に発生した課題と解決策を、プロジェクト間でナレッジとして共有することでプロジェクトを次々に成功させている組織がある。JAXAだ。プロジェクト・マネージャ(PM)にはプロジェクトが完了すると、3ヶ月をかけて問題とその解決策をまとめることが義務付けられているそうである。
従来は、経験を積んでノウハウを習得した優秀なPMがいるかどうかでプロジェクトの成否が決まっていた。これからはPMのナレッジを人材として所有するのではなく、個々のプロジェクトで発生した事実を記録し共有することが求められている。
(9)進化指向
サービス開始後のサービス活用状況を監視し分析した結果に基づいて業務目標を評価することにより、サービス導入によるビジネスの変革を継続する必要がある。
これまではサービスが開始されれば「お疲れ様でした。さようなら」といってプロジェクトも終わりだった。しかし本来は、サービスを何のために導入するかといえばビジネスの変革のためであり、変革されたかどうかを評価しなければプロジェクトは終わらないはずである。新しいプロジェクトの始まりへ、どのように切り替えていくかがサービス開始の後に求められている。
ところで組織進化論[4]では、変異、選択、保持、闘争という4つのプロセスがあると指摘されている。組織ルーティンや組織能力が変化することが変異、特定の変異を選択することにより他の変異を排除することが選択、選択された変異によって保護、複製、再生産される行動が保持、そして競合する供給資源を獲得するための競争が闘争である。サービスを開始することは、そのサービスを選択することである。次いでサービスを保持することが始まる。そのためには経営資源をサービス保持に投じなくてはならないから、良いサービスしか生き残れないということになる。ところが日本ではなかなかこの選択ができない。一旦導入されてしまうと商品が排除できず、たくさんの商品を抱えて担当者が懸命に働いているのに利益がでないそうだ。日本企業は商品の範囲を広くするのが得意なのだろうか。米国のIT企業をみると実に商品の数が少ないことに気づく。集中することで業務の効率を上げて利益率を向上しているのである。規模の経済を追求するのが得意なのが欧米企業なのだろうか?
この9つの「すりあわせの技術」はそれぞれが有用な考え方ではあるが、図1のように循環させて組み合わせることでさらに効果を発揮できると思われる。この循環がサービス・イノベーションの進化につながると考えている。これもまた10番目の「すりあわせの技術」である。これを「すりあわせのサイクル」と呼ぼう。
価値星座
「すりあわせのサイクル」では、最初にどんな価値を提供できるかを考える価値指向の視点が大切だ。価値指向では、価値連鎖(Value Chain)と価値星座(Value Constellation)という2つの考え方がある[5]。
価値星座は、「価値連鎖」がアクタ間での価値の直線的な連鎖を対象とするのに対して、アクタ間の双方向的で動的な価値の相互作用を対象としている。公平性の点では価値星座の方が高いといえよう。アクタ間の相互作用を表現するゴール指向要求工学手法として、i*フレームワークや我々が提案しているアクタ関係表などがある。価値星座では特定の表記法が定められているわけではないので、これらのゴール指向要求工学手法を適用することができる。またGordijnらは、e3-valueという手法でアクタ間の価値の相互作用をモデル化している[6]。この手法についてはまた回を改めて解説したい。
サービス要求工学
すりあわせの技術をサービス要求工学に応用してみよう。たとえば次のような手順でサービス要求を具体化できるだろう。
【手順1】問題を抱えているアクタを識別する
【手順2】アクタ間の隙間を明らかにする
【手順3】この隙間を埋めるサービス仲介者を価値星座に基づいて抽出する
【手順4】サービス仲介者の代替案を比較する。この過程で必要があればアクタを分解する
【手順5】最適なサービス仲介者を用いてアクタを再結合する
【手順6】アクタとサービス仲介者によるサービス活用プロセスを評価する
ここでサービス仲介者を「すりあわせアクタ」と呼ぶことができる。すりあわせアクタによって問題を抱えていたアクタ間の隙間を埋めることが、それぞれのアクタに対して新しい価値の相互作用を生むはずである。
事例研究
株式会社ユンクス[7]をご存知だろうか?最近テレビでよく紹介されている。
軽トラ1台ごとに10軒の顧客を確保して、その地域にある150軒の顧客に対して1チームになるように軽トラの数を決めると15台になる。そこで1台の売上げを2万円とすると、チームごとに軽トラ市で300万円の売上げになる。また、エリアにある喫茶店やパチンコ店などへの納品を紹介する出前屋サービスも用意している。現在、大阪府の200エリアをカバーしているが、全国展開を目標にしているそうだ。200チームが同じ日に軽トラ市と出前屋を実施すると、その日1日だけで1億円の売上げになるとしている。顧客の数で考えると150軒×200=3万軒の御用聞き市場を創出したことになる。
この事例をサービス要求工学の手順で分析してみると次のようになる。
【手順1】
問題を抱えているアクタを識別する
ユンクスの社長の話では、大阪の家電メーカーに依頼されて九州地方に家電を運ぶのだが、大阪への帰り道で九州から運ぶものがないので、帰りのトラックの荷台は空になってしまう。そこで九州地方の農家で野菜を自分で購入して大阪で販売したところ、飛ぶようにに売れたのだそうだ。この話では、トラックと地方の農家という2つのアクタが問題を抱えていたことになる。
【手順2】
アクタ間の隙間を明らかにするために、表2に示すようなアクタ関係表を記述してみると、トラックと地方農家の間には都市部の市場と地方の生産者間に適切な物流ネットワークがないという隙間があることが分かる。
トラック |
地方農家 |
|
トラック |
商品を輸送した帰りに積む商品がない | 購入者がいないので配送できない |
地方農家 |
出荷先がないので配送をを依頼できない | 都市への販売手段がない |
【手順3】
この隙間を埋めるには、適切な物流ネットワークサービスがサービス仲介者として必要になることが分かる。また、サービス仲介者はトラックに農産物の配送を紹介し農家には顧客としての都市部の消費者を紹介することが価値になると思われる。
【手順4】
サービス仲介者の代替案を比較しよう。この過程で必要があればアクタを分解する。この事例では、トラックではなく軽トラックに限定している。また農家から直接仕入れるのではなく、農業法人から共同仕入れにしている。このように、トラックや農家という最初のアクタが軽トラックと農業法人に分解されている。このようにアクタを選択することで、農産物の安定供給や規模拡大による経済化を実現していることが分かる。
【手順5】
サービス仲介者を用いて、アクタを再結合してすりあわせた結果をアクタ関係表で示すと表3のようになる。地方農業法人と軽トラとの間の相互作用は、サービス仲介者が吸収しているのでなくなっている。この例では軽トラ、サービス仲介者、地方農業法人の間で双方向で価値が交換されているので価値星座の例になっていると思われる。
軽トラ |
サービス仲介者 |
地方農業保人 |
|
軽トラ |
販売機会の確保 欠品防止 在庫削減 |
特産品の仕入れ情報提供を依頼 |
|
サービス仲介者 |
納品情報 発注情報 |
規模拡大による経済化 安定供給 |
共同仕入れ 情報提供を依頼 |
地方農業保人 |
特産品を納品 特産品情報を提供 |
都市で地方の特産品を販売する |
【手順6】
アクタとサービス仲介者によるサービス活用プロセスを評価すると、現在もサービスが拡大しており、今後全国展開という次の目標が期待されている。
ここでは、サービス要求工学の手順を紹介するために軽トラ市を使っただけであり、軽トラ市を考案するためにサービス要求工学の手順を用いたのではないことを注意しておく。しかし前述したことから理解できるように、新しいサービスをすりあわせの考え方を利用することで、手順的に導くことができる可能性があることを示すことができたと考える。
まとめ
本稿では、3月に出版した拙著「次世代プロジェクトリーダーのためのすりあわせの技術」のエッセンスとそのサービス要求工学への応用事例を紹介した。今後の価値指向に基づくサービス要求工学で重要になると思われる「価値連鎖」の考え方についても触れた。ただし同書では、ここで述べたようなサービス要求工学について解説しているわけではない。未来の教育サービスが「すりあわせの技術」の考え方で、どのように開発されるのかについて、登場人物によるプロジェクトストーリーとして描いてみた。
■参考文献
- [1] 次世代プロジェクトリーダーのためのすりあわせの技術,ダイヤモンド社,2009
http://www.riss-net.jp/publication/books.html - [2] Chesbrough, H., Open Innovation- The New Imperative for Creating and Profiting from Technology, Harvard Business School Press, 2003
- [3] Chesbrough, H. and Spohrer, J., A research manifesto for service science. Communications of the ACM 49(7), 35?40, 2006.
- [4] ハワード・オルドリッチ,組織進化論,東洋経済新報社,2007
- [5] Bant Van Looy et.al.,“Service Management ? An Integrated Approach, second edition,”
(日本語訳)バート・ヴァン・ローイ他編,白井義男監修,サービス・マネジメント 統合的アプローチ,ピアソン・エデュケーション,2004 - [6] e3-value,http://www.e3value.com/e3family/e3value/
- [7] ユンクス,軽トラ市,http://keitora-ichi.com/truckichi.html
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要