Comments
Description
Transcript
K-SEA_20120720_Handout(PDF 2.2MB) - K
H A N D O U T 第 4 8回 SE A 関西プロセス分科会 2 0 1 2 年07月20日(金) 18:30∼21:00 @大阪市立大学文化交流センター 顧客価値共創のための超上流工程 田中 康 奈良先端科学技術 大 学 院 大 学 （ 特 任 准 教 授 ） , 東 京 工 業 大 学 （ 特 別 研 究 員 ） , 有 限 会 社 ケイ プ ラス ・ ソ リュ ー シ ョンズ 自己紹介 ソニー（1986∼2006） ! 情報デザイン • デザインセンター • ヒューマンインターフェス・ラボ ! ソフトウェア開発プロセス改善 • CMM正式リードアセッサー（非更新 笑） はじめに 何のグラフ？ !" #$$ !" #$$ %$$ %$$ *$$) *$$) !($) !($) !$$) !$$) %($) %($) %$$) %$$) ($) ($) $) $)+* $! % $! %+*$! %! %! * * ,+# ,+# -+" -+" %$+ %! %+ * %$+ %! %+ * , * %+ %+ $* ,+#$* ,+#$! -+"$* -+"$! %$+ $ %$+ $ $, $* $* $! $* $! $* $! ' $# 問題提起：「価値は誰が創るのか」 ソフトウェアエンジニアの 職能 とは？ ! User Interfaceの3接面 User-System系 output System User 社会 第1接面 第2接面 第3接面 Usability Utility Social Impact （ソフトウェア）エンジニアの責任範囲は？ 田中康 • [email protected] • http://kplus-solutions.com/ %& $# ' %& 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 人間中心設計の必然 「ソフトウェア開発を複雑にする要因は数多く存在する。しかし、この複雑さの核心にあるの は、問題ドメイン自体が本質的に複雑であるという事実だ。…（中略）…複雑さをコント ロールする秘訣は、優れたドメインモデルにある。」 マーチン・ファウラー ドメイン駆動設計（エリック・エバンス） 序文より → なぜ、「問題ドメイン自体が本質的に複雑」なのだろうか？ → 優れたドメインモデルとは？ システム設計とは ! 機械系 vs 中数系 機械系：構成される部品とその関係とを解 析的に記述することができる 中数系（一般システム）：解析的にも統計 個々は独立している 「大集団」 ： 的にも記述することが困難 非組織的で複雑 問題ドメイン自体が本質的に複雑なのは、 「人」というシステムを扱うため ! 層変換系の設計 ︵ 各 要 素 の 独 立 性 ︶ 統計的方法による記述 ラ ン ダ ム 度 の 違 い システム設計とは、「機械系」と「中数系 組織的で複雑 システム科学的方法 「機械」 ： のシステム」の異なる系同士をいかに結び 組織的で単純 解析的方法による記述 つけるか、すなわち 層変換系 を設計する 相互に関係する こと。 「人」 ： 少ない 因子数 （複雑さ） 多い 異なる系同士の関係を設計するために • 中数系のシステムである人を設計可能な系とするために、 対象機器との関係の上で モデル化することが必要 • システムの設計には、人のモデル化が必要；人間中心設計（Human Centered Design） • 選択されたアプローチではなくシステム設計の必然のアプローチ 中数系のシステム 機械系 対象機器との関係の上で 人とその活動をモデル化 （層変換） モデル化 機械系 2 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 要件開発とは • 要件は、経営視点と顧客視点、そして技術視点のAndを見つける作業 • Andにのみ解が存在する Andを見つけるためのアプローチ 経営 ‣ 顧客志向 • まず、顧客志向で見る • 次に、顧客とどのような関係を結びたいかを考える ‣ 提供者志向 • まず、提供者志向で考える • その上で、顧客にどのような関係を結ばせたいかと考える 顧客 代表的な提供者志向の例は？ 要件開発 Engineering Processの拡張 CMM：要件管理（REQM）からCMMI：要件開発（RD）へ （そして、「超上流」へ？） The Engineering Process Areas Requirements REQM Product and product component requirements RD Alternative solutions Product components Product TS PI Ver Val Customer Requirements Product components, work products, verification and validation reports Customer needs Requirements Development-Context (Develop Customer Requirements) Develop Customer Requirements Transform Needs into Customer Requirements Collect Stakeholder Needs CL2 Elicit Needs Customer Requirements Needsは何処からくるのか？ 3 技術 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 要件開発の特徴 • 解析的方法による解の算出および検証ができない • やめかたが難しい 要件開発の本質とは 正しい「問い」を立てるプロセスを通して、対象に対する理解を深めること（科学的アプローチ） 仮説検証（学習）とコミュニケーションのプロセス 共創と人間中心設計のための要件開発モデル：逆Vモデル 組織を語るときに最も一般的な方法は、組織の構造を述べることである しかし、顧客に約束した価値を提供する手段はプロセスにある 組織や役職・人・システムは目に見えるがプロセスは見えない、名前が付けられていない場合も多い 3階層の抽象度を持つ超上流工程のプロセスモデル • システム系を構成するものは、組織や人、そしてITシステムといった目に見える「モノ」のレベル • 企業が顧客に対して価値を創出するのは、モノのレベルを横断して機能する「コト」としてのプロセス • モノのレベルである人やシステムの上をコトとしての業務プロセスが流れることによって、顧客に対する価値 （「カチ」）を生み出す 4 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 業務プロセスのモデル化 「組織の階層構造が、もっぱらある時刻の断面から責任の所在と報告関係をとらえようとするのに対して、プロセス の構造は、いかにして組織が価値を提供するかという動的な視点に立つ」1 業務プロセス設計は、顧客視点から要求された品質目標に対して、どのように業務を進めたら経営ゴールを満足し、 さらに経営リスクを低減できるかを設計することである。そして、業務プロセスを設計するためには、目に見えない プロセスを外在化、すなわちモデル化する必要がある。 プロセス を描いてみよう：レストラン「注文を取る」 1 Davenport T.H. (1993). Process Innovation, Reengineering Work through Information Technology. Boston, MA: Harvard Business School Press 5 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 プロセスのモデル化 なぜ、クイズになるのか 伝えるときは「つつむ、しばる... 」となるのはなぜか プロセスのモデル化視点 ! タスク視点 工場の生産ラインを記述する例を考える。 たいていの場合、目が行くのはラインを構成する機械である。 生産ラインが「Aをする機械」、「Bをする機械」、「Cをする機械」... によって構成されていると認識した場合、 生産ラインを A→B→C... の機械の並びとして描くことが自然であると感じる。 ! 成果物（Entity）視点 成果物視点は、ライン上でどのような中間成果物を作り、それらを管理して最終製品に仕上げるかという視点。 最終成果物を一気に作れない場合、適切な段階が定義される。 どのような段階に分けるかは、作ろうとする製品の制約、品質管理上の確認ポイント、そして製造リスクの管理の視 点から決まる。 ラインを構成する機械は、設計したプロセスを実現するために開発される。 6 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 タスク観点の易しさと難しさ 記述の3視点 • 構文的記述 • 構造的記述 • 目的的（機能的）記述 ! 理解 目的的に構造を理解 ! コミュニケーション 運動としての発話 活動の本質としての「変化」 人間社会の営みの根幹は活動の調整。 活動は常に変化する。 固定化された活動は、人間性を阻害し生産性を引き下げる。 変化、すなわち活動の調整こそが、人間の柔軟性の現れ。 タスク視点でプロセスを描くためには、 活動をいかに固定化するか という視点がとられる（ 活動の調整的視座が 欠けてしまう）。 人の活動を正確に描こうとすると、すべての場合が描けているのかという問題にあたってしまう。 活動の本質は 変化すること であり、すべての活動をそのまま（タスクの視点で）描くことは困難。 7 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 PRePモデル Products Relationship Processモデル ソフトウェア開発プロセス改善のためのプロセスモデル化手法として開発 システム開発のための業務プロセスモデル化手法として適用 Entity-base Process Model（成果物観点による構造モデル） PRePモデルの簡単な説明 ! 3段階の抽象度レベル ! Entityの定義 • 意味のあるチャンク • 振る舞いを持つ • 他の成果物の入力となる • 共有され管理されている ! Entity間の関係 （右図 →） ! 基本的な記述構成 ! 適用上の課題 モデル化視点の難しさ • 目的的にプロセスをとらえる • 適切な言葉で表現する • 利用者の視点からシステムを見る 8 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 演習解説 業務プロセスのモデル化とシステム改善の要件検討の事例として、レストランのプロセスを考えてみる。レストラ ンには、いくつかの業務プロセスがある。その中には「レストランの客が料理を注文する」というプロセスが存 在するであろう。ここでは、注文プロセスを例にとって逆VモデルとPRePによる業務プロセスのモデル化を考え てみる。 【モノ】レベル（As-is） まずは、現行のシステム分析として「モノ」のレベルを分析する。モノレベルの分析では、まずはじめに、プロ セスを構成している実在物とその仕様を洗い出す。例えば、「レストランの客が料理を注文する」というプロセス では、次のようなモノが存在するであろう。 • アクター • 客（レストランの客） • 接客担当 • システム • メニュー（紙に印刷されたもの） • オーダー伝票（接客担当が注文を控えて厨房に渡すための用紙） 実際のコンピュータシステムでは、それぞれのシステムの現在の仕様の分析を行う。上記の場合、「メニュー」と いうシステムの仕様は その利用者から見て どうなっているのかを調べる。例えば、「メニューシステムは、食事 と飲み物とが別のメニューとなっており、A4見開きの厚紙の内面に写真付きでメニューが印刷されている」とい う具合である（実際のコンピュータシステムでは、外部仕様の洗い出しが行われる）。 【コト】レベル（As-is） マイルストーン成果物とサブプロセスの特定 次に、モノレベルで分析した実在物によって作り出されている 現状のプロセスを分析する。まずはじめに、Entityにあてはま るものを洗い出し、それらの関係を描く。 • Entityの定義 • 意味のあるチャンク • 振る舞いを持つ実体 • 他の成果物の入力となる • 共有され管理されている 注文プロセスを考えてみると、まず、Entityにあてはまるマイル ストーン成果物として「注文」というEntityが考えられる（個々のEntityには、その振る舞いを記述するための属 性が定義されるが、ここでは簡略化したモデルで話を進める）。「注文」Entityは次に続くサブプロセス（例え ば「調理する」）への入力となるであろう2。 Entity「注文」は、 客からのオーダーを管理可能な対象とすることによって、客からのオーダー3を厨房に確実に 送るという下記のビジネス遂行目的と業務リスク管理を行っているのである。 • 客のオーダーを確実に受け取り、厨房へ伝えることができる（顧客のオーダーを接客段階で確実に受け、厨房は注 文に従って調理業務を進めることに注力できる） 2 実際には、プロセス全体のEntityが先に洗い出されたあと、サブプロセスの定義が行われる 3 「注文」と区別するために顧客からの注文を「オーダー」と呼ぶことにする 9 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 • 接客担当が、顧客からのオーダーと店のメニューとを比較することによって、メニューに無いオーダーを厨房に送 らないようにする そして、サブプロセス「注文を取る」は、そこからのマイルストーン成果物である「注文」によって、その目的で ある「客からのオーダーを厨房に確実に送る」を確実にしている。上記の考察から、現状のプロセスには、「注 文を取る」というサブプロセスが存在し、そこからは、「注文」というマイルストーン成果物が出力されている であろうということが分析される。 サブプロセスの完成 サブプロセスを完成させるために、「注文」成果物に必要とな るEntityを洗い出す。「注文」には、客からの「オーダー」が必 要である。ところで、客からのオーダーの実体は何であろう か。客がオーダーを紙に書いて接客担当に渡す場合はオーダー が書かれた紙がEntityとなるが、多くの場合、オーダーは客か ら口頭で伝えられる。このような場合のEntityは、「（オーダー を伝える）客」となる。 客がオーダーをするためには、店が用意している「メニュー」 がその入力となる（「メニュー」は「オーダー」の入力）。接 客担当は、客からのオーダーとの確認をとりながら「注文」を 取る。接客担当がオーダーを聞き取れなかったり聞き間違いを したりしたときは、書き取った「注文」が修正される。さらに 一方で、接客担当は、客のオーダーがメニューに載っているものであるかを確認しなければならない（さらに は、 商品の品切れ等の情報を頭の中に入れておく必要もある）。つまり、「注文」は、客のオーダーと店の「メ ニュー」と同期関係となる。 現行システムの配置 上記で設計した注文プロセスに、現行のシステムを配置してみ る。 印刷されたメニュー、オーダー伝票（注文を書き取る用 紙）などがそれぞれのEntityに配置される。この段階で、As-is のプロセスモデルが描けたことになる。 10 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 【カチ】レベル できあがったAs-isプロセスをもとに、現行プロセスの改善課題を抽出し顧客視点で改善すべき事項、顧客に提供 すべき価値を検討する。実際の検討では、作成したAs-isプロセスをもとに作成したストーリーボドなどを利用 し、業務プロセス改善を行う企業側の利害関係者を中心としたワークショップが実施されたり、As-isプロセスを 参照しながら専門家によるフィールドリサーチが行われたりする。一方で、PRePモデルによって作成したAs-isプ ロセスからも、プロセスの構造からいくつかの改善課題を読み取ることができる。 リスクポイントの考察 サブプロセスが完成した段階で、プロセスの構造からいくつか のリスクを読み取ることができる。代表的なものとして、同期 関係リスクがある。Entity間の同期関係は、両者の内容の擦り 合わせを行わなければならないという点でリスクのポイントと なる可能性がある。注文プロセスでは、例えば、品切れのメ ニューを受けてしまったり、ランチ終了時間にランチを受けて しまったりという「メニュー」と「注文」との同期リスクがあ る。また、接客担当が客のオーダーを間違って聞き取ってしま うことも考えられ客のオーダーと「注文」の同期リスクがあ る。さらに、客からのオーダーはそもそも実体がなく、口頭で 受けるため、実体としての確実性が弱いというリスクが存在す る。 ところで、プロセス上のリスクを低減するための主な方法には、プロセスを改善することと、担当者のスキルで カバーする方法がある。どちらを取るかは、経営的な判断が必要となる。例えば、従業員コストを下げるのであ れば（すなわち、スキルの低い従業員でプロセスを駆動するには）、プロセスを改善することになるであろう。 一方で、スキルの高い従業員による品質の高い接客をビジネス戦略とするならば、プロセスは変えずに、逆に、 注文を受ける際の顧客とのコミュニケーション（同期関係プロセス）を重視するかもしれない。 顧客価値の検討 レストラン業務を顧客視点から考えた場合の価値にはどのようなことがあるであろうか。プロセスの構造的問題 の分析、そしてフィールドリサーチやワークショップなどを通じて、例えば、下記のような改善項目が出される と考えられる。なお、いずれも主語は「顧客」である。 • 確実に注文をしたい（接客担当が客のオーダーを聞き間違える、もしくは品切れメニューを受けてしまう） • 接客担当をいちいち呼ばずに速やかに注文をしたい（接客担当を呼んでもなかなか気づいてもらえない） • すべてのメニューを写真付きで確認したい（現在のメニューでは、主な料理の写真しかない） 上記の顧客視点からの価値に対して、ビジネス視点からどのように対応するか（もしくは、しないか）が検討さ れる4。上記までのフェーズは現行システムとプロセスのリバース・エンジニアリングであった、次に、検討した 顧客価値を実現するためのTo-beプロセスとシステムの検討（設計）を行う。 4 例としてあげた顧客価値は、主に、一般価格層のレストランで見られる顧客ニーズである。高級レストランでは、求められる顧客価値は全く違ったものとなるであろう。 11 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 To-beの検討 逆Vモデルにおいて、To-beプロセス設計とシステム要件の定義は、多くの場合、行きつ戻りつしながら進められ ることになる。下記に、プロセスの改善とシステム要件の検討例をいくつか示す。 To-be検討例1 カチレベルで検討したいくつかの顧客価値として「確実に注文 をしたい」を実現することにする（残り２つは、ビジネス的視 点での検討から対応しないことにする）。一般的に、2つ以上の Entityの内容の擦り合わせが必要となる同期関係にはリスクが 伴う。注文を取るためのAs-isプロセスでも2箇所に同期関係が 存在した。 「確実に注文をしたい」を実現する場合、「メニュー」を、現 在の店舗の在庫状況も反映した最新の「現在のメニュー」とす るとよいであろう。さらに、その「現在のメニュー」を接客担 当に確実に伝えることができれば、同期関係（接客担当が現状 メニューをいちいち把握しなければならない状態）のリスクを 低減することができるであろう。 そこで、確実に注文をすることを達成するためのプロセスとシステムへの要件として下記を考える。 • 「メニュー」を「現在のメニュー」とする • 注文を取る際に、接客担当が「現在のメニュー」を常に参照できるようにする • 接客担当が注文を受ける際にメニューにあるオーダーを確実に受けることができるようにする その結果、注文を書き取る用紙の代わりに、例えば、電子注文システムのようなシステムを考案することになる であろう5。接客担当は店のメニューや、商品の品切れ等の情報を頭の中に入れておく必要が無くなる。また、確 実に、調理プロセスへ注文を送ることができる（ただし、「オーダー」との同期関係リスクは幾分低減される が、それでも完全に無くなる訳ではない）。 To-be検討例2 例1で実現しなかった顧客価値も含め、すべての顧客価値を実現するプロセスとシステムを考えてみよう。 • 確実に注文をしたい • 接客担当をいちいち呼ばずに速やかに注文をしたい • すべてのメニューを写真付きで確認したい As-isプロセスを見ると、 接客担当と客とのコミュニケーション 、そして 接客担当とメニューとの擦り合わ せ にリスクが潜在していることがわかった。つまり、接客担当が同期関係リスクの発生ポイントとなっているこ とがわかる。 そこで、解決策として、接客担当を無くしてはどうかと考えてみる。すると、「注文を取る」サブプロセスからの 出力がそのまま客からの「注文」となるプロセス。つまり、客が店の「現在のメニュー」を入力として、「注 文」というEntityを出力するサブプロセスが考えられる（これまでは、客からのスツ力は、 口頭 という弱い実体 であった）。この場合、客によって生成される「オーダー」がサブプロセスでのマイルストーン成果物となり、そ の入力が「現在のメニュー」となる。その結果、システム要件としては、下記のような定義となるであろう。 • 客が、店の「現在のメニュー」を入力として、「注文」できるサブプロセス 5 これは、「電子注文システム」というものを我々が知っているからこのように表現できるのであって、それが考案される前は「例１で設計したプロセス要件を満足するシステ ム」として表現されていたであろう。 12 第48回 SEA関西プロセス分科会 顧客価値共創のための超上流工程 顧客のテーブルに配置されたタッチパネル式の注文システム は、上記の要件を満足しているものであると思われる。その結 果、接客担当が不要になり、注文ミスも無くなる。 ただし、これは一つの解であり正解というわけではない。確実 に注文ができるという意味では第2接面の品質は満足している。 また、接客担当を呼ばずに手早く注文できるという意味では第1 接面の課題もクリアしているように見える。しかし一方で、客 自身が注文システムを操作をしなければならないため、顧客に よっては、第1接面に関する新たな問題が発生することが十分考 えられる。また、本業務プロセスとシステムを導入することに よって接客担当が不要になることは、第３接面、すなわち社会 的な新たな問題が立ち現れる可能性がある。 お問い合わせ 田中 康（TANAKA Yasushi） 有限会社ケイプラス・ソリューションズ 代表（[email protected]） 奈良先端科学技術大学院大学 情報科学研究科 特任准教授（[email protected]） 東京工業大学 情報理工学研究科 計算工学専攻 特別研究員／非常勤講師（[email protected]） 13