６．事例(4)：IT 活用支援サービス (1) 背景 IT（Information Technology）の高度化により、ビジネスが効率的かつ迅速に展開できる ようになった反面、IT が経営に与えるリスクは日増しに増大している。システム障害が社会 生活に重大な影響を及ぼすようになり、既存システムの維持・運用費、市場の変化やサービ スの多様化への対応費が増大するなど、IT 投資の質の改善、向上が求められている[横浜他 2005]。 また、大規模システムの開発において、品質、コスト、納期を全うできたプロジェクトは、 全体のほぼ 4 分の 1 であり、コスト超過を招いた原因の大半は、追加の企画、設計、開発作 業が発生したことに起因するという（表 3-6-1）。 表 3-6-1. コスト超過を招いた原因 コストの超過を招いた原因（複数回答可）有効回答は329件 追加の企画作業が発生した 28.0 追加の設計作業が発生した 42.6 65.0 追加の開発作業が発生した 13.1 テストが長引いた ハードウェアの追加購入・高性能化 15.5 ソフトウェアの追加購入・高性能化 9.4 途中で全面的にやり直した 5.2 その他 4.9 （%） 0.0 10.0 20.0 30.0 40.0 50.0 60.0 70.0 日経コンピュータ 2003/11/17 情報化実態調査 その原因には、要求定義が明確にできないことが挙げられる。具体的には、①情報システ ム部門の弱体化に伴い、IT 知識の乏しいユーザー部門主導のシステム開発プロジェクトが増 え、要求を明確にできないケース、②ビジネスモデル自体が不透明な新規分野では、システ ム完成時には陳腐化し、作り直しを余儀なくされるケース、③また、大規模システムでは、 関連する業務、組織、利用者も多様化し、全体をバランスした最適化が難しく、要求仕様に 落とせないケースなど――が考えられる。要求を「開発」するための方法論を提起する、｢要 求開発アライアンス｣も発足している[山岸他 2006]。 一方、開発会社の側では、IT システムの受託開発は、一般の製品販売とは異なり、製品コ ンセプト（Needs）も曖昧で、具体的な機能仕様（Requirements）は決まっておらず、寸法 を記した設計書（Specification）もない状況下で、多岐に渡る新技術を消化できぬままに採 用し、膨大な人の作ったプログラムを組み合わせ、統合する、という IT 業界特有の一品料理、 一品生産の難しさがある。加えて、経営者の参画意識、プロジェクト管理、意識ギャップ、 調達、品質などの課題を抱え[情報処理推進機構 2006]、要求仕様通りに作ったが顧客に受け 113 入れられず、作り直しが生じる、あるいは「動かないコンピュータ1」となるケースは、枚挙 にいとまがない。 顧客は、経営課題の解決のために IT を活用しようとしており、システムを作ることが目的 ではない。IT を活用してもたらされる効果、すなわち IT サービスの受け手の「価値」に注 目した IT 化2が、これらの問題解決の糸口になると考え、以下の論を進める。 (2) 事例分析と評価 本事例では、成功した大規模システム構築事例（以下、新システム）をサービス改善後と みなし、サービス工学の手法を用いて分析する。その結果を、旧システムの構築事例（以下、 旧システム）と比較し、成功要因を見出すという逆分析を試みる。BtoB（企業から企業）、 とりわけ IT 分野において、サービス工学がどのように適用できるかを考察する。 1) 研究アプローチ 本事例分析では、以下のアプローチを採用した。 ① 新・旧両システムのサービスモデルを作成し、その差異を比較し考察する ② サービスモデルから判明した BtoB（IT）分野の特徴について考察する ③ ②で判明した IT 分野における RSP 抽出の特殊性について考察する ④ 新システムにおける RSP 抽出プロセスを紹介する ⑤ 開発テンプレートを用いた機能展開を行い、その有効性を検証する 2) 事例概要 2-1) 新システム ユーティリティ企業の設備部門における業務システムであり、設備データベースを中心に、 設備計画、工事、保全、運用といった基幹業務を網羅し、PDCA（Plan, Do, Check, Action） サイクルによる部門の業務運営を下支えするものである。システム構成は、4 業務 24 サブシ ステム、サーバ 20 数台からなり、総データ量は 3TB（テラバイト）超え、2000 人以上が利 用する大規模システムである[西岡他 2006]。筆者らは、本システムの構想策定段階から構築、 運用に至るまで、設計事務所として参画し、利用者（以下、ユーザー）の側に立った IT 化を 支援した。 IT 化の特徴は、以下の通り。 ① 顧客が主体性を持ち、トップの意思を反映した IT 化を推進した ② 顧客、メーカー、設計事務所が一丸となり、システムを短期間で構築した ③ 顧客がシステムを活用し、IT 化の目的（業務改革）を達成した その後、本システムを他の設備部門 3 箇所に横展開し、極めて短期間で実運用に持ち込み、 業務改善・改革を推進できた。加えて、資材、経理などの全社共通システムとの連携方式を 1 日経コンピュータ：動かないコンピュータ Forum（http://itpro.nikkeibp.co.jp/ugokanai/index.html） システムの構想段階から、構築、運用段階を経て顧客の最終目的を実現する意味合いまで含め、 「IT 化」と表現 する。 2 114 標準化し、財務的には、従来の同等システム開発に比べ IT 化投資（TCO：Total Cost of Ownership）が半減するなど、数少ない成功事例として社内外から評価を得ている（澁澤賞 2005、オーム賞 2006 受賞）。 2-2) 旧システム 新システム導入前に使われていたシステム。設備情報管理システム、保全システム、工事 業務システムからなり、設備資産情報はホストと連係し、次のような問題を抱えていた。 ・遅い、使い勝手が悪い、端末が不足、入力項目が多い、わかりにくい、再入力が必要 ・必要なデータが入っていない、業務で関連するデータが取り出せない ・手管理を併用、システムだけで業務が回らない、業務間の連係がなく不便 ・ニーズの変化に対応できない、ホストの制約でシステム変更できない など 3) 事例分析 3-1) サービスモデル 新旧システムのサービスモデルを概観する（図 3-6-1 新旧サービスモデル（概要））。 図 3-6-1 は、サービス工学の表記に、価値、情報／モノの流れを加えている。新旧サービ スモデルを比較すると、新システムでは、設計事務所というサービスの提供者が存在し、従 来、顧客自身が行っていた IT 化の企画、導入、運用、IT 化（業務改革推進）、IT 化マネー ジメントといった機能を、外部サービスとして切り出し、実施・支援している点が大きく異 なる。 青太線矢印で示す「価値」の連鎖に注目すると、設計事務所は、顧客から要求（Needs） を吸い上げ、それを機能仕様（Requirements）に落とし、設計情報（Specification）として 噛み砕き、開発会社、運用会社に提供している。開発会社、運用会社は、IT 化サービス実現 のチャネル（手段）としてのシステムと運用（Product）を開発し、顧客に提供した。 一方、旧事例は、顧客の提示した仕様に基づき、開発会社がシステム開発とメンテナンス を実施する、というモデルである。表 3-6-2 新旧システムサービスモデルの違い を参照され たい。 115 新システムサービスモデル Product 開発会社 【システム開発／メンテナンス】 システム 経営方針 【システム開発支援】 【ＩＴ化マネージメント】 調整事項 【システム開発支援】 【IT 化構想策定支援】 業務試験 システム仕様 【顧客 IT 化実現支援】 業務知識 IT 化ニーズ（問題点課題） Specification 【サポートデスク運営】 システム課題（障害 顧客 Needs Requirements 等） 設計事務所 【IT 化（業務改革推進）支援】 Specification システム改善要望 【システム運用】 運用 【凡例】 ：サービス／機能の流れ Product ：情報／モノの流れ ：価値の流れ 運用会社 旧システムサービスモデル 【システム開発／メンテナンス】 システム仕様 Product システム 顧客 開発会社 図 3-6-1. 新旧サービスモデル（概要） 116 【システム運用支援】 運用仕様 調整事項 【ＩＴ化マネージメント】 調整事項 【システム運用支援】 【IT 化マネージメント】 表 3-6-2. 新旧システムサービスモデルの違い 新モデル 旧モデル 変化点 設計事務所という提供者が存在する 存在しない →代行 【顧客 IT 化実現支援】サービスを提供している いない →代行 【システム開発支援】、 【システム運用支援】サービスを提供している いない →補強 運用会社という提供者が存在する 存在しない →代行 【システム運用】サービスを提供している いない →代行 ここで、サービスモデル（概要）を一段詳細化し、各エージェントの RSP とそれを実現 する機能を関係づけた図を示す（図 3-6-2 新サービスモデル、図 3-6-3 旧サービスモデル）。 ①新サービスモデル IT化構想フェーズでは、サービスの受給者である顧客は、部門のミッション実現するた めのIT化を検討した。そこでは、顧客の価値（RSP） ： 「業界のIT動向を知りたい～IT化の イメージ／実現計画が欲しい」に対応して、供給者である設計事務所が「IT化動向調査～ IT化構想の策定」というサービスを提供した。顧客は、その構想を承認し、実現化フェー ズの要求仕様（RSP）として関係者に示した。いわば、IT化のクレド 3 を提示したといえる。 実現化フェーズでは、IT 化の目的として構想に謳われた「IT を活用した業務改革の実現」 に向けたシステム開発、運用、IT 化実現、IT 化マネージメントを実施した。 IT 化構想フェーズで明らかになった顧客の要求価値は、設計事務所から開発会社へのシス テム開発支援機能として形を変え、開発会社の「正しい仕様が欲しい、業務上の問題を解決 して欲しい」という RSP に作用し、開発会社が顧客に提供するシステム開発／メンテナン スサービスに形を変えた。システム運用では、設計事務所が顧客の要求価値を運用仕様とし て焼き直し、運用会社に提供したことにより、運用のアウトソースが可能となったといえる。 ②旧サービスモデル 旧サービスモデルでは、新サービスモデルの設計事務所機能がなく（網掛け、取消線部 分）、顧客のシステム構築の目的も不明確であり、「システムを導入したい」という顧客の 要求価値（RSP）を満たすためのシステム開発とメンテナンスが実施されたことを物語っ ている。 3 ホテル、ザ・リッツ・カールトンの信条「サービスの心」を示したもの（井上他 2007） 117 部門のミッション 機能の流れ 価値（モノ／情報）の流れ シーン RSP 機能 【凡例】 ・業務のＰＤＣＡを回したい ・TCOを最小化したい ・腐らない設備DBを実現したい ・ROIを最大化したい ITを活用した業務改革の実現 実現化フェーズ 構想フェーズ ・業務の品質を向上させたい ・業務の効率化を行いたい 顧客 IT化の検討 構想書 ・ＩＴ化PJ管理をしなければならない －現状の把握をしたい －各社間の調整をしなければならない －正しい意思決定をおこないたい IT化マネージメント ・業務改革を実現させたい IT化実現 ・システム利用率を向上させたい ・システムを維持しなければならない －システムを安定稼動させたい －運用コストを抑えたい －障害時、早く復旧させて欲しい システム運用 ・システムを導入したい －高品質なシステムが欲しい －早く運開させたい －投資を抑えたい システム開発 実現フェーズのRSPへ ・IT化のイメージ／実現計画が欲しい ・業務のあるべき姿が知りたい ・現状業務の問題点課題を把握したい ・業界のIT動向を知りたい 顧客 運用 運用会社 システム 開発会社 システム設計 IT化のChe Check／Action フェー フェーズへ 調整事項 事項／連絡事項 システム テム改善要求 システム テム課題／要望 ・障害時、各社の協力が欲しい 障害対応 システム運用 ・正しい仕様が欲しい ・業務上の課題を解決して欲しい システム運用設計 ・業務的に問題ないか検証したい システム試験 システム開発 ・正しい仕様が欲しい ・業務上の問題を解決して欲しい 118 図 3-6-2. 新サービスモデル 運用会社 ・システムを安定稼動させたい ・障害時、早急に復旧したい システム運用 【システム運用】 開発会社 ・出戻りをなくしたい システム開発 【システム開発／メンテナンス】 伺い・承認（定義されたＲＳＰに に対してのコミット） ージ／ＩＴ化計画 IT化イメージ ＩＴ化 化ニーズ 経営方針／業務知 務知識／問題点・課題 ＩTに関 関する情報 状況 運用仕様書 業務試験実施 システム仕様作成 プロジェクト統括管理 【IT化マネージメント】 現場改善活動支援 【IT化（業務改革推進）支援】 ヘルプデスク運営 【ヘルプデスク運営】 障害対応フォロー 運用仕様作成 【システム運用支援】 業務試験仕様書 仕様書 【システム開発支援】 IT化構想の策定 将来像の策定 現状業務分析 IT化動向調査 【IT化構想策定支援】 設計事務所 各社調整／連絡 状況把握 会議体の運営 要望・懸案事項取りまとめ 問合せ対応／アナウンス 利用者教育の実施 状況 システム変更要求 （障害／要望／改善） 業務運用課題検討 SLAの要求 業務試験実施 運用要求 業務試験実施 試験仕様書作成 品質要求 業務システム課題検討 システム全体設計 IT化イメージ／ＩＴ化計画 IT化計画策定 システムモデリング 将来業務モデリング あるべき姿の抽出 現状業務モデリング 問題点課題の抽出 設計事務所 119 図 3-6-3. 旧サービスモデル ここで、新旧システムにおける顧客と開発会社、設計事務所の係わりの差異を示す（図 3-6-4）。 旧システムでは、一部の業務をシステムに置き換えただけであり、 「OA 化」と称す。片や、 新システムは、データベースを共有し業務と IT は切り離せない。業務の PDCA を回し、業 務を改善・改革するという最終目的を実現する意味合いまで含め、 「IT 化」と称す（図 3-6-5）。 旧システム（OA 化）では、顧客と開発会社は独立し、ウォータフォール型で役割分担し ている。それに対して新システム（IT 化）は、顧客／設計事務所／開発会社が一体となり、 常に改善しながら IT 化を推進している。 これは、サービス工学の唱える、商品開発時のコンカレントエンジニアリングの手法、す なわち、マーケティング、営業、設計、製造、運用、サポート部門が一同に介し、改善を加 えながら商品開発を進めるという方式と合致している。 顧客 顧客／設計事務所／開発会社 開発会社 OA 化セグメント IT 化セグメント 現状業務分析 現状業務分析 システム仕様 IT 化構想(業務の将来像) システム設計 システム開発 システム開発 システム試験 システム試験 改善 システム設計 IT 化の実現 OA 化の実現 「IT 化」=業務 with システム 「OA 化」＝業務 and システム 顧客 設計事務所 図 3-6-4. 顧客との係わり方の違い 開発会社 旧システムは「OA 化」 業務 4 業務 5 業務 2 業務１ 業務 3 置換え 業務 2 置換え システム システム 新システムは「IT 化」 業務１ システム 業務 2 業務 3 業務 4 データベース 図 3-6-5. OA 化と IT 化の違い 120 業務 5 システムを使っ て業務フローの 整理 3-2) BtoB（IT）分野の特徴 サービス工学で対象とする BtoC モデルでは、サービスの受給者である消費者（Consumer） をペルソナとして仮想的に定義し、サービスの提供者である企業（Business）がペルソナに 提供するサービスを論じる。ペルソナの RSP は、機能的価値、情緒的価値へと抽象度が高ま り、ペルソナの内面的な状態を表す要素が多くなる。 一方、BtoB（IT）モデルでは、受給者と提供者の合意により提供サービスに関する契約を 取り交わす。受給者は、業務実施母体である「組織」の RSP（機能的価値）を提示し、それ を充足するサービスを提供者に要求する。特に IT 分野では、組織とその構成要員である IT ユーザーを対象とした最終目的である経営課題の解決に繋がる IT サービスを求められる。 BtoC と BtoB（IT）の違いを図 3-6-6 に示した。 Business (Receiver) ：企業ドメイン ：役割ドメイン ：マーケット Consumer 組織 IT ユーザー (Receiver) ：組織 RSP ：人 RSP ：機能 ：サービス IT 担当＋設計事務所 Business (Provider) Marketing 組織 (Persona) Consumer (Persona) IT ユーザー (Persona) 契約 Manufacture／Maintenance Business (Provider) Liveware Software 組織の IT ユーザーの RSP RSP Software Hardware Liveware BtoC モデル Hardware BtoB モデル（IT） 図 3-6-6. BtoC と BtoB（IT）の違い 3-3) BtoB（IT）分野におけるRSP抽出 ここで、BtoB（IT）分野におけるサービス設計と RSP の抽出について考察する。 前述の通り IT 分野では、提供者である企業の要求仕様（RSP）が明確になっていることは まれである。前述の新システム事例では、2000 人を超える設備部門の業務をシステム化対象 としたが、業務は多岐にわたり、陰に陽に複雑に絡み合っている。業務のサイクルも瞬時か ら数十年先の計画まで、長短様々であり、全体像が見えず、どこが問題で何をしたいのか、 121 漠としており、重要度も優先度も見えない状況であった。 今回の新システムが成功した要因は、IT 化構想のフェーズに設計事務所が参画し、当該設 備部門の組織 RSP を「IT 化構想」として明確に示したこと、IT 化構想をオーソライズでき た（当該部門がその RSP にコミットした）ことに依るところが大きい。 実現化フェーズ以降、組織 RSP を業務、店所、人（IT ユーザー）の RSP に段階的に詳細 化し、それぞれの RSP に対する機能をサービスの提供者が実現し、提供したといえる（図 3-6-7）。 ペルソナ法以外 の方法論 組織的 【IT 化構想】 AsIs 仕様 ToBe RSP の設定と承認 【システム開発】 【システム運用】 【IT 化実現（業務改革）】 組織 アーキ テクチャ 機能 組織機能 ・画面 ・操作性 ・応答性 ユーザー 属人的 Software Hardware メンテナンス ヘルプデスク コンサル ペルソナ法での RSP 洗出し 図 3-6-7. RSP 段階的詳細化 IT 化構想フェーズは、部門の将来像を実現するための IT 活用を検討するフェーズである。 企業の基幹業務を対象とした IT 化では、多様なエージェント（利害関係者）が係わり、複雑 多岐にわたる企業活動が存在し、混沌の中から顧客要求（RSP）を顕在化させる必要があり、 部分の積み上げではなく、全体を鳥瞰し、全体最適を議論する方法論が必要であろう。 IT 化実現フェーズでは、全体構想（部門としての RSP）を具体化し、各々の業務機能、組 織機能（各組織の RSP）に展開し、それらを実現するための IT のアーキテクチャ、システ ム機能に落としていく。具体的な画面のレイアウトや表示項目を設計する段階では、利用者 （IT ユーザー）の顔が見えてくるため、ペルソナ法による RSP の洗い出しが有効となろう。 3-4) IT化構想段階におけるRSP抽出プロセスの紹介 ここで、新システムの IT 化構想フェーズで設計事務所が実施したプロセスを紹介する。部 門の RSP を設定し、部門の合意を形作り、承認を得るプロセスである。図 3-6-8 にその実態 を示す。 122 図 3-6-8. IT 化構想における実施プロセス 設計事務所は、IT 化構想フェーズをプロデュースし、以下を実施した。 ①現状分析において、顧客（トップ／中間管理職／現場）が議論する「場」を提供し、 ファシリテートし（仕切り）、議論を集約させ、そこで得られた業務知識、問題点・課 題を咀嚼し、全体像として提示し、顧客内での共通認識とした。 ②部門将来像の検討では、顧客とあるべき姿を議論し、現状分析で明らかになった業務 を「機能」に因数分解し、リソースを最適配置した将来像を描いた。この過程を通じ て顧客と議論を繰り返し、将来像を部門の合意とした。 ③IT 動向調査の結果を踏まえ、実現可能な IT 化計画を策定、 IT 化構想としてまとめた。 トップを交えた報告会の場で、部門のオーソライズを取り付けた（顧客が、IT 化構想 を実現するとコミットした）。 123 (3) 開発テンプレートの適用 1) IT 化業務における適用 IT 承認者を例に、ペルソナ定義（図 3-6-9）、脚本（図 3-6-10）、4W1H（表 3-6-3）、RSP （表 3-6-4）を下記に示す。 図 3-6-9. ペルソナ定義 図 3-6-10. 脚本 124 表 3-6-3. IT 承認者の 4W1H 表 3-6-4. IT 承認者の RSP 上述に示すように、開発テンプレートを用いた RSP 抽出を試みたが、違和感を覚えた。 次節以降、BtoB（IT）分野における開発テンプレートの適用について考察する。 125 2) 開発テンプレートの評価 2-1) ペルソナに関する考察 サービス工学では、「BtoB のサービスにおいても、実際に会話を交わし取引を行う相手は その会社の一事業部一個人であると予想されることから、企業に勤める個人としてペルソナ を用いることに違和感はないと考えられる」との前提を置いている（3.2 節(3)-2)）。 しかしながら、BtoB 分野において、個の集合として組織あるいは企業を捉えるのは議論の 余地がある。個人の意見と組織の役割を混同したために失敗したプロジェクトを多々見受け る。個人の意見を集約し、抽象化することも必要であるし、他のリソース要件や環境要件と 併せた組織の Wants を明確にすることが肝要である。特に組織の新たな Wants を発見する ことが求められる。 サービス工学の考え方は、BtoB 分野においても普遍であると考えるが、個人ペルソナのテ ンプレートをそのまま流用するのは、内容の記述、語彙、作業ボリュームからも難がある。 組織ペルソナ向けのテンプレートを新たに開発すべきであろう。下表 3-6-5 に、個人ペルソ ナと組織ペルソナの比較を示す。 表 3-6-5. 個人ペルソナと組織ペルソナ 組織と個人のとの対応 大項目 小項目 個人 （テンプレート） 識別情報の 詳細 役割と仕事 ・名前、肩書き、簡単な説明 ・年齢、性別 ・キャッチフレーズ ・引用文 ・会社名または業界 ・仕事の肩書き、役割 ・通常の活動 ・その他の大切な活動 ・苦手な分野、弱点 ・責任 ・他のペルソナ、システム、製品／ サービスとの関わり 組織（IT 化事例） [名前] ・部門情報 [年齢] ・運営方針 [性別] ・運営計画 [メモ] ・体制図 ・企業情報 [キャリア] [能力] [行動特性] [脚本] ・経営理念、経営方針 ・経営計画 ・組織図 ・社内規約 ・職務分掌 ・業務フロー ゴール ・短期的なゴール、長期的なゴール ・やる気 ・仕事に関連したゴール ・製品／サービスに関連したゴール ・全般的（人生の）ゴール、志 ・製品／サービスに対する希望 126 [基本 LOV] [キャリア] [目的] [目標] ・現状業務の問題点課題 ・業務の将来像 ・IT 化構想 セグメント 技術と知識 状況と環境 心理学的、 個人的な詳 細 ・マーケット・サイズと影響 ・国際マーケットの検討 ・入手しやすさの検討 ・一般的統計と分野別の統計 ・コンピュータやインターネットに ついての一般的な知識 ・頻繁に使う製品／サービスとその 知識 ・経験年数 ・分野についての知識 ・トレーニング ・特殊技能 ・競争相手に関する認識 ・器材 ・「ある一日」の説明 ・特定の使用場所 ・一般的な仕事、家事と娯楽 ・ほかのペルソナとの関係 ・個性 ・価値観と考え方 ・恐れ、障害、不満の種 ・個人所有物 [メモ] ・経営戦略 ・全社 IT 化戦略 ・コア技術 ・コアコンピタンス ・技術戦略 [メモ] ・人材開発計画 ・スキル表 ・IT リテラシ ・技術動向、他社動向 [ライフスタ イル] [脚本] ・リソース（ヒト、カネ、 モノ、情報） ・組織、体制、制度 ・市場環境、社会情勢 [個性] [基本 LOV] [志向] ・部門戦略 ・部門 IT 戦略 [脚本] 2-2) RSP抽出に関する考察 BtoB（IT）分野の特徴は、IT システムが経営課題を解決する道具と位置づけられること にある。そのため、IT 化構想フェーズでは、IT 化実現の「価値（RSP）」を明らかにするこ とを重視する。要求仕様の定義よりも、将来像を見定めることが先決であり、将来像の実現 に向けた IT 活用を検討した結果として、IT 化の要求仕様が明らかになる。 IT 化構想フェーズでは、今回提示されたテンプレートでの RSP 抽出の方法は特に馴染ま ない。IT 化戦略を明確にできている企業はまれであり、もやもやとした中から IT 化の方向 性を導き出すには、個人の機能要求より、組織の機能要求を明確にすることが先決である。 以下に、ペルソナを用いた RSP 抽出アプローチと本事例で採用した MUSE[西岡 2007]に よる IT 化構想策定のアプローチを（図 3-6-11）に対比した。 ペルソナアプローチでは、仮想的な人物像としてペルソナを定義するが、MUSE のアプロ ーチでは、実在する業務の担い手を抽出する。そこでは、｢業務は変わるがデータは普遍｣の 原則に基づき、データをまず洗い、データの使い手として登場人物（エージェント）を抽出 する。 127 MUSE アプローチ ペルソナアプローチ 【現状業務モデリング】 １．データ項目の洗出し ２．登場人物の洗出し ３．実在物の洗出し ４．業務全体像の作成 ペルソナの基本定義 ペルソナの性格・志向の構成 【将来業務モデリング】 １．組織枠から機能枠へ ２．重複業務の削除 ３．不足業務の追加 ４．将来業務全体像の作成 ペルソナの脚本の作成 キーワード整理 ・経営方針 ・問題点・課題 ・あるべき姿 ・IT 戦略 【システムモデリング】 １．将来業務モデリングに システム機能を配置 ２．機能を体系化する 要求項目／要求品質、品質要 素の関連付け コミット IT 化構想（IT 化の RSP） コミットはなし 図 3-6-11. RSP 抽出に関する比較 次に、ペルソナアプローチでは、ペルソナの性格・志向ならびに脚本を想像して作り、脚 本からキーワードを整理し、要求項目／要求品質、品質要素の関係づけを行う中から RSP を 見出すが、BtoB の世界では、企業の構成要素である「組織」の機能を果たすこと、全体最適 の視点をもつことが重要であり、組織ペルソナを扱う必要がある。MUSE では、部門の業務 を大づかみにし、部門の進むべき方向、ゴールを示し、そこから IT 化のコンセプトに落とし、 IT 化構想としてまとめたものを部門 IT 化の RSP としている。 具体的には、現状分析では、データと登場人物、実在物からなる業務の全体像を作成し（現 状を鏡に映す）、顧客と再認識する。将来像検討の段階では、業務を機能単位に分解し、組織 枠から機能枠に視点を変えて再編成し直し、将来業務の全体像を描く。将来像を顧客と一緒 に仮想的に図中を歩き、鳥瞰する（ウォークスルーする）ことにより見えてくる業務の無理、 無駄、ムラの排除、不足機能の追加といった業務改善を協働で行う。各作業の区切りでトッ プを交えた報告会を行い、確認を取る。 この裏では、プロの知恵を借りている。トップ／中間管理層／現場の各階層のキーマンと のブレーンストーミングを繰り返し、現状の問題点、課題を抽出し、あるべき姿を協働で探 り、専門家（業務のプロ、IT のプロ、外部有識者）の意見を取り入れながらまとめていく。 その上で、IT 活用を考え、システム機能を配置し、システムの全体像を描き、システム機能 の体系化を図るという作業を行っている。 実は、そうしたプロセスを通じて関係者が意識共有を図ること、関係者が将来像を受け入 れ、部門の合意とすることが一番大事なことである。共感が人を動かす原動力となる。 128 2-3) IT 分野における RSP の特殊性 上述したように、IT 化実現の RSP は、将来像という一枚の「絵」であり、実現化計画と いうチャートで表現される。IT 化実現フェーズでは、QCD（品質がよい、安い、早い）など の語彙で RSP は表わせるが、IT の世界には開発品質、コスト、開発進捗を測る尺度がなく、 評価が難しい。これは、IT 業界が内包する問題であり、別次元での検討が必要であろう。 2-4) その他の課題 下記に、実分野への適用に際して気づいた開発テンプレートならびにサービス CAD の改 善要望を挙げる。 ①膨大さをカバーする、縮退（全体表記）／伸展（部分表記）のしくみが必須である ②エージェントは、対称性を持つべき（受給者かつ提供者となりうる） ③エージェント間の双方向、循環性のやり取りがある ④エージェントのグルーピング、仮想エージェントが必要である ⑤価値連鎖の表現手段が必要である ⑥別シーンを、またがる一貫性を表記したい ⑦時間を経たプロパティを継承したい (4)考察 1) 設計事務所サービス 総括すると、新システムの成功要因は、顧客のニーズを充分に把握し、IT 化の仕様・運用・ マネージメントを最適化する｢設計事務所｣を導入したことにある。設計事務所は、 「顧客の IT サービスを実現させるためのサービス」を実施した（図 3-6-12）。 ：エージェント IT を活用して、業務品質の向上、 業務の効率化を実現したい （低価格、短納期、高品質で） ：コンテンツ ：チャネル IT 化 実現 顧客 顧客 ・開発会社 ・運用会社 ：サービス ：状態変化 設計事務所 設計事務所サービス ＝「顧客の IT サービスを実現させるためのサービス」 図 3-6-12. 設計事務所サービス 本事例分析を通じ、「社内でできる」と顧客が信じていた要求仕様の提示から IT 化の推進 まで、第三者がプロデュースし、オーガナイズすることによって、 「軸のブレない、調和の取 れた IT 化」を実現し、TCO を低減するという設計事務所サービスの価値が明らかになった。 サービス工学の理論（フレームワーク）により、受給者である顧客の最終価値（RSP）を 見定め、フェーズ毎に展開した詳細の RSP に対してそれぞれの提供者が機能を提供し、それ 129 らを統合したものが IT サービスである、という価値の連鎖を「見える化」できた意義は大き く、諸問題解決の手がかりをそこから見出すことができる。 IT 化の上流工程では、混沌の中から顧客の価値を見出す方法論を必要としており、サービ ス工学の設計手法（開発テンプレート）をそのまま適用することは難しかったが、IT 化実現 フェーズでは、利用者（IT ユーザー）を想定した開発テンプレートの適用は有効であろう。 今回の事例分析では深掘りできなかったが、プロの協力を得て顧客の暗黙知を形式知化し、 それらを抽象化・純化して、顧客の「思い」としてシステムに注入できたこと、また、IT 化 のプロセス全体を見通し、関係者間の通訳となり、落穂を拾い、軌道修正を促すといった陰 のサービス、いわば「コンシェルジェサービス」に相当する機能を設計事務所が担ったこと も成功に繋がったと考えている。その価値を「見える化」すべく、引き続き分析を行いたい。 今後の設計事務所の課題は、IT 化構想フェーズの定式化（Miracle から Repeatable へ）、 必要性のアピール、IT 化実現フェーズにおける開発品質の評価方法の確立、運用サービスの 充実、顧客満足度とコストのバランス評価に関する検討などであり、更なるサービスの向上 を図っていきたい。 2) ITサービスマネージメント ところで、IT 分野では、システム開発が終わるとプロジェクトは解散し、IT 活用の評価は 殆どできていないのが実状である。運用結果を評価し、スパイラルアップ（段階的改善）を 図る、すなわち、「IT 化の PDCA を回す」ことは必須であるが、それで終わりではない。 上述の設備部門であれば、設備の軸、運用の軸、現場の軸、カネの軸、ヒトの軸を立て、 IT 活用を考え、IT 活用の将来像を描き、既存のシステムを活かしながら、統制の取れた IT サービスを実現することが肝要であり、IT 投資の質の向上がより一層求められる。 また、設計事務所サービスは、さらに「IT Strategic Planning Office」として、IT サービ スを戦略的に企画・立案し、実施をマネージメントする「IT サービスマネージメント」サー ビスへと展開していくべきであろう。 3) 今後の期待 本事例では、RSP を「価値」の同義語として扱ったが、サービスとして提供する機能の裏 返しを「機能要求パラメータ」とし、機能要求パラメータの時系列・複合組み合わせで充足 される顧客の価値、満足度を上位概念として「価値パラメータ」とし、別のものとして捉え るべきではないだろうか。 元々、モノづくりの 2.5 次産業化という領域から出発したサービス工学であるが、今回の 事例を通じ、BtoB 分野においても普遍の考え方であると確信した。特に IT 分野は、サービ スの最たる業界でありながら、その生産現場は工業化が進まず、3K と称されるほど、非効率 かつ非合理がまかり通っている。製造業で鍛えられたサービス工学が、IT 分野のイノベーシ ョンの引き金となることを期待して止まない。 130 【参考文献】 [横浜他 2005] 横浜他「マッキンゼー IT の本質」ダイヤモンド社 2005 年 [日経コンピュータ 2003] 日経コンピュータ：2003 年 11 月 17 日号 2003 年 [山岸他 2003] 山岸他「要求開発 価値ある要求を導き出すプロセスとモデリング」, 日経 BP 社 2006 年 [情報処理推進機構 2006] 情報処理推進機構「経営者が参画する要求品質の確保 第 2 版」, オーム社 2006 年 [西岡他 2006] 西岡他「事例紹介 第 6 回サービス工学研究会」 2006 年 [井上他 2007] 井上他「リッツ・カールトン 20 の秘密 － 一枚のカード（クレド）にこめら れた成功法則」オータパブリケーションズ 2007 年 [西岡他 2007] 西岡「システム構築に向けた MUSE Concept」 大阪大学, マルチメディア工 学特別講義 2007 年 131
© Copyright 2024 ExpyDoc
