仮説モデルの検証方法

(１)

検証項目

本節では、図 3-2として提示したITソリューションサービスの価値創造のメカニズ ムの仮説モデルの妥当性について、何をもって判断するか、その検証方法について説明 する。

まず、本仮説モデルにおけるアクターである。本仮説モデルには、ITソリューショ ンサービスを提供する「ITソリューションサービスプロバイダー」に属するIT技術者 と、そのサービスの受益者である企業実務者の存在が必須である。また、マネジメント 機能を担っていくアクターとしてバリューオーガナイザーが存在する必要がある。この 時、注意しなければならないのは、これらのアクターはそれぞれ異なる知識空間を持っ ているという点と、バリューオーガナイザーは前述したとおり、バリューオーガナイザ ーとして単独で存在しても良いし、IT技術者または企業事務者がその役割を担うこと もできる点である。

次に、バリューオーガナイザーが担う知識マネジメント機能として、(a) アクター共

32

通の知識空間としての場の設定と、(b)知識共創のマネジメント が組み込まれ、実行 されていなければならない。具体的には(a)としては異なる知識を持つ複数のアクター がひとつの場で議論が行えるように、場が設定されていることである。(b)としては異 なる知識を持つ複数のアクターが、それぞれの知識を相互に共有し、その結果として新 しい知識を生み出すことを促進する行為を行っていることである。

最後に、(a)(b)の行為を実行するアクターが存在しなければならない。

以上が事例の中で検証できれば、図 3-2で説明した仮説モデルの有効性が検証できた といえる。

これらをまとめると、表 3-1のようになる。

表 3-1仮説モデルの検証項目 検証項目名 検証の観点

1 異なる知識を持 つアクターの存 在

ITソリューションサービスのプロバイダー、同サ ービスの受益者が、サービス価値共創のアクター として存在していること。

2 「知識空間」と しての場の設定

異なる知識を持つ複数のアクターがひとつの場で コミュニケーションが行われるように、場が設定 されていること

3 「知識共創」の マネジメント

異なる知識を持つ複数のアクターが、それぞれの 知識を相互に共有し、その結果として新しい知識 を生み出すことを促進するようなマネジメント行 為が行われていること

4 バリューオーガ ナイザーの担い 手

上記のアクター共通の「知識空間」の設定と、「知 識共創」のマネジメントとを実行する主体者とし てのアクターが存在すること。

33 (２)

検証方法

分析に用いるデータは、各事例について、半構造化インタビューまたは文献から収集 する。事例と収集データは表 3-2に示す。

表 3-2 収集データ

分析対象 インタビュー対象者 文献 事例1 ユーティリティ企業

のIT化事例

コンサルティングを専業とする 企業に所属し、「設計事務所」と してMUSEを活用しているIT コンサルタント

ActConsulting Webページ 西岡(2010)

西岡・山村(2010) 西岡・山村(2013) Nishioka &

Kosaka(2014)

第三世代のサービスイノベ ーション研究会(2017)

事例2 CRM業務改革コン

サルティング事例

大手ITベンダーのコンサルティ ング事業部に所属し、CRM業務 改革コンサルティングを担当し ていたITコンサルタント

対象企業のコンサルティン グプロセスのマニュアル

事例3 病院業務改善コンサ ルティング事例

システムインテグレーション企 業に所属するコンサルタント

－

事例4 テクノロジーインテ リジェンス活動事例

－ 成瀬(2010)

本研究では、事例１、事例2、事例3で半構造化インタビューを実施した。

インタビューの基本的な質問は以下の通りである。

（質問１）あなたの基本的なコンサルティングプロセスは何ですか コンサルタントの作業プロセスの確認することが目的。

（質問２）どのようにして顧客の要求/意見を得ますか？

コンサルタントが顧客の仕事に精通していない場合（コンサルタントは顧客 の問題に関する知識を持っていないことが多い。）顧客の知識なしに要求/意 見を得ることは困難であり、これがこの質問をする理由である。この質問の 中で、顧客の要求／意見を引き出すために工夫している点や、どのような場 で顧客とのコミュニケーションを持っているのかをインタビューしている。

前述のとおり、収集したデータに対して、解釈をし、その解釈をもとに表3-1の観点で

34

コード化を行った。その結果をもとに、それぞれの観点が実際に事例の中で認められる か否かを確認した。なお、コード化にあたっては、フリック(2002)が示しているように、

収集したデータに対して意味がありそうな部分についてオープン・コード化を行い、こ こで集めたコードから妥当性検証に必要なカテゴリーを形成し、それに対するコードを 生成して、そのコードに基づいてfocused-codingを行った。