2013-6
ユーザー起点のサービス開発への移行プロセス― 株式会社エムティーアイの事例 ―
尾形

慎哉

堀口

麻奈

松尾

睦

ユーザー起点のサービス開発への移行プロセス― 株式会社エムティーアイの事例 ―尾形慎哉（株式会社グラグリッド）
堀口麻奈（株式会社エムティーアイ）松尾睦（神戸大学大学院経営学研究科）

1. ユーザー起点によるサービス開発の重要性
経済産業省によると、日本企業は過去 20 年間、コストカットを中心とした「減量経営」を主軸に進めてきており、真の顧客志向に基づいたグローバルに通用する新事業が創造されていない。一方で、OECD 諸国では、「プロダクト」「プロセス」「マーケティング」「組織」の 4 領域での総合的なイノベーションが主流となっており、技術探究
型イノベーションに加えて、ユーザー起点イノベーションを重視することが提唱されている。
近年、ユーザーのニーズや利用状況に基づいたシステムを設計するためのプロセスとして人間中心設計（HCD：Human Centered Design）が認知されるようになってきた。人間中心設計は、1999 年に ISO13407 として規定され、2010 年に ISO9241-210 として改訂されている。その基本的なプロセスは、人間中心設計の必要性を特定し、対象ユーザーとその要求を明確にして、要求に合ったものを設計し、評価から必要に応じて修正を繰り返すといったものである。ただし、ISO9241-210 では基本的なプロセスは規定されているものの、その実行に関する具体的な内容は記述されていない。そのため、現在では実行に関する様々な手技法が、マーケティング、デザイン、品質管理など多様な分野から提唱されている。
このような背景を踏まえ、本稿は、ユーザー起点のサービス開発を組織的に強化する変革に着手した株式会
社エムティーアイ、および同社をサポートしてきた株式会社グラグリッドの取り組み事例を紹介する。なお、本稿はディスカッションのための事例を紹介することを目的としているため、理論的な観点からの考察を掲載していな
い。
2. 株式会社エムティーアイと株式会社グラグリッド株式会社エムティーアイ（以下、MTI）は、1996 年に設立された、モバイルコンテンツ配信を事業の中核とするIT 企業である。「モバイル夢工場」のビジョンのもと、「音楽」「ヘルスケア」「電子書籍」「生活情報」「エンターテイ
ンメント」など、ユーザーの生活に密着したコンテンツの配信を展開している。同社は、有料会員数 813 万人（2012 年 9 月時点）を有しており、最近ではスマートフォン向けの有料会員が飛躍的に伸びている。
MTI の基本的な売上の源泉は、ユーザーが MTI の提供するコンテンツを利用する際に支払う利用料である。
そのため、ユーザーにとって魅力的なコンテンツを提供し続けることが、MTI にとっての重要な経営課題の一つに挙げられている。それゆえ、ユーザー起点によるサービス開発は組織にとってコアとなる技術であり、MTI はその技術を強化する方法を模索していた。
一方、株式会社グラグリッド（以下、グラグリッド）は、人間中心設計で使われる様々な手技法を活用し、企業に対してユーザー起点のサービス開発を支援しているエージェンシーである。グラグリッドは、MTI におけるユー
ザー起点によるサービス開発の仕組みを組織的に定着させるサポート役として、1 年間に渡り MTI と協働で本変革の取り組みに関わった。
以下では、1 年間に渡り MTI とグラグリッドが実施してきた、ユーザー起点のサービス開発への移行プロセスを紹介する。
2.「ユーザー起点の開発」への移行の背景
はじめに、本取り組み当初の MTI の開発体制を確認しておきたい。変化の激しいモバイル業界において、これまで MTI は、その変化に合わせた柔軟な開発体制をとってきた。
従来、MTI はキャリアが主導するプラットフォームに合わせてサービスを提供してきたことで、多くのユーザー
からサービスを受け入れられ、モバイル業界では日本最多の有料会員数を誇っていた。その開発の組織体制
は、「音楽」「ヘルスケア」「電子書籍」「生活情報」「エンターテインメント」など、提供しているサービスごとに業務を分割する事業部制を採用していた。各「事業部」では、提供するサービスの企画案を構想し、事業部で構想された内容をモバイル端末で実現するための設計、プログラミング、ユーザーインターフェイスデザインなどの実装を「制作センター」が受け持つ構造で機能しており、事業部と制作センターの間は社内取引制度で成り立っていた。
そのような状況において、近年は従来の携帯電話に代わりスマートフォンが急速に普及してきた。スマートフォ
ンは従来の携帯電話に比べ大きく機能が拡張され、端末としてできることが拡がり、ユーザーにとっても様々な用途に使える可能性が拡がった。その結果、モバイル端末に対するユーザーのニーズや利用状況が多様化し、提供するサービスも、これまで以上にユーザーを意識した開発をしなければ、よりよいサービスとして成立しない状況になってきた。そのため、MTI は従来の開発体制からこのような状況に対応すべく、開発体制の改編が急務であった。
そこで、制作センターの責任者が実行の中心となって、グラグリッドと協働にてユーザー起点の開発を強化する開発体制の変革に動き出した。
本取り組みとして MTI とグラグリッドが協働で行った内容は、「ユーザー起点の開発プロセスおよびメソッドを
制作センターのメンバーが理解し、それを制作センター内で定着させること」であった。それを実践するために、
図表１に示すような 3 つのフェーズに分けて活動を行った。以下では、各フェーズについて説明する。
図表 1 本プロジェクトの活動プロセス【フェーズ１】
開発プロセスの明⽂化ユーザー起点の開発理念の浸透【フェーズ２】【フェーズ３】

メソッドの習得

プロジェクトでのメソッド適⽤3. フェーズ 1：開発プロセ
セスの明文化化とユーザー
ー起点の開発理念の浸透（2012 年 1 月
月～3 月）
みが始まる以以前にも、ユーーザー起点でで開発を行うたための拠り所となる開発プ
プロセスは構築
築されていたた。
本取り組み
しかし、そののプロセスは一一部のプロジジェクトでは運運用されていた
たものの、全社に浸透してているものではなかった。
それは、案件件によってカス
スタマイズが難しく、実用 的なプロセス
スではなかった
たことが大きなな要因であっった。
そこで、各各プロジェクト
トで活用できる
る実用的な開開発プロセスのの構築をフェーズ１の目標標とした。はじ
じめに、グラググ
リッドは、当初初構築されてていた開発ププロセスを確認
認し、第三者的的な立場から
ら MTI で行わわれている開発
発活動をヒアア
リングし、開発で行われてている活動をを再構成し、開開発プロセスを新しく構築
築するサポートトに入った。そその際、開発発構成する参考ととして、MTI の開発活動にのに類似していいる開発のフレ
レームワークををベースにヒヒアリングを行
行
活動を再構った。参考ととした開発のフ
フレームワークは、Jesse JJames Garrettt が提唱してている 5 つの段段階で考える
るユーザー中中心デザインののモデルでああった（Garrettt, 2005）。
ヒアリング
グでは、制作セ
センターの責責任者・リーダ
ダーを中心に特定のプロジ
ジェクトを振りり返りながら、活動内容やや成果物につついて情報を整整理していった。制作セン
ンターのチームリーダーがが中心となっててフレームワーークに内容をを記述し、グララグリッドがレビビューするといいう進め方でで、3 ヶ月に渡渡って繰り返しし実施した（写写真 1）。こうしした活動の結結果、図表 2 にに示すようなユーザー起点
点の開発プロ
ロセスを構築しした。

写真
写 1 プロセセス構築におおける作業の様様子

図表 2 ユーザー起点の開発プロセス
プロセス

アクティビティ

開発作業を役割でまとめたもの

プロセスを構成する活動目的

1 戦略

1.1

1.2

1.3

2 要件

2.1

2.2

3 構造と骨格

サービス目的を決定する

ユーザーニーズを決定する

開発計画を立てる

コンテンツ要求を決定する

機能要求を決定する

メソッド

タスク
アクティビティの構成要素

タスクの実施内容

1.1.1 マーケティングを実施する

１．マーケティングデータを収集する
２．マーケティングデータを分析する
３．戦略を定義する

1.1.2 ビジネスベネフィットの特定をする

１．ビジネスモデルを立案する
２．ビジネスモデルを分析する
３．ビジネスベネフィットを特定する

1.2.1 ユーザーニーズを把握する

１．ユーザーデータを分析する
２．ユーザーニーズを特定する

1.2.2 ユーザーの状況とゴールの分析をする

１．ターゲットユーザーを特定する
２．ユーザーの状況を分析する
３．ユーザーの目的を特定する

1.3.1 製品コンセプトを決定する

１．コンセプトを立案する
２．コンセプトを検証する
３．コンセプトを定義する

1.3.2 検討する

１．スケジュール、リソース等、関連情報を収集する
２．戦略に基づきバランスをとる

1.3.3 プロジェクトスコープを選定する

１．対応内容に優先順位をつける
２．プロジェクトスコープを選定する
３．開発計画を立てる

1.3.4 可視化と共有をする

１．開発計画を可視化
２．共有と運用

2.1.1 コンテンツ要求を抽出する

１．サービスの価値を明らかにする
２．価値を具体的な形に分解する
３．価値をコンテンツ・機能に分配する

2.1.2 コンテンツ要求を精査する

１．全体として本質的な価値を満たしているか検討する
２．コンテンツ要求を定義する

2.2.1 機能の抽出をする

１．機能検討に必要な情報を収集する
２．情報を整理、分析する
３．サービスを満たすために必要な機能を抽出する

2.2.2 機能要求を精査する

１．機能漏れがないかを確認する
２．よりよい手段がないか検討する
３．機能要求を定義する

具体的な手法・技法

市場分析
競合分析
ステークホルダー分析
ビジネスモデル検討
ユーザーニーズ調査・グループインタビュー
・行動観察・デプスインタビュー
インセプションデッキ
ユーザーゴールスケッチング（仮）コンセプト立案
見積もり
内外折衝
プロダクトバックログ
スプリント計画MTG
朝会
スプリントレビュー
スケッチングブレインストーミングストーリー収集
シナリオ共感度調査
ユーザー参加型ストーリー収集
アクティングアウト
アクティビティシナリオ（構造化シナリオ法）

3.1

情報構造を決定する

3.1.1 機能構造を特定する

１．ゴール達成までの流れを検討する
２．機能構造の定義

カードソーティング
機能ツリー
ラダーリング3.2

インタラクションデザインを決定する

3.2.1 ＵＩを規則化する

１．機能構造を解析する
２．機能構造の表現方法を検討する
３．機能構造の表現方法を規則化する
４．UIの規則を定義する

ワイヤーフレーム
ローファイプロトタイピング
ハイファイプロトタイピング

3.3

インターフェイスデザインを制作する

3.3.1 ＵＩコンセプトモデル（たたき台）を設計する

１．たたき台作成対象画面の選定
２．対象画面の要件を明確にする
３．対象画面を設計する

アクティビティシナリオ（構造化シナリオ法）
インタラクションシナリオ（構造化シナリオ法）
思考フローチェック
操作フロー
画面遷移図

3.3.2 たたき台を精査する

１．たたき台の検証点を明確化する
２．たたき台を検証する
３．インターフェイスデザインの方向性を決定する

リンク解析
設計原則によるチェック
ラベリングチェック3.3.3 UIを定義する

１．画面を洗い出す
２．画面を検討する
３．画面を定義する

ユーザー参加型設計
レイアウトパターンによる設計

4 表層

4.1

4.2

ビジュアルアイデンティティを決定する

ビジュアルデザインを制作する

3.3.4 実装後のＵＩ調整をする

１．問題を特定する
２．改善案を定義する
３．改善を実施する

4.1.1 デザインの方向性を検討する

１．情報を収集する
２．情報を整理、分析する
３．デザインの方向性を検討する
４．デザインの方向性を定義する

4.1.2 デザインのたたき台を設計する

１．たたき台作成対象物の選定
２．対象物の要件を明確にする
３．対象物をデザインする

4.1.3 デザインのたたき台を精査する

１．検証点を明確化する
２．たたき台を検証する
３．たたき台を定義する
１．対象を特定する
２．要件を整理する
３．デザインする

4.2.1 要素をデザインをする

4.2.2 画像制作をする

１．対象を特定する
２．要件を整理する
３．制作する4.2.3 画像の管理をする

１．対象を抽出する
２．要件を定義する
３．画像の制作予定、状況、品質を管理する

4.2.3 実装後のデザイン調整をする

１．問題を特定する
２．改善案を定義する
３．改善を実施する

エキスパートレビュー
エキスパートレビュー＋簡易UT
認知的ウォークスルー
NEM
思考発話法

コンセプトダイアグラム
アイコンチェック
一対比較法
スタイルガイド
簡易コントラストチェック
感性調査
3デバイスレビュー
表示大チェック
デザインテイスト三案比較

4. フェーズ 2：メソッドの習得（2012 年 5 月～9 月
月）
開発プロセススを構築したもものの、それををどのように運運用するかがが次の課題でああった。運用フェーズ 1 において開セスに含まれてている手技法法（メソッド）をを制作センターーのメンバー が使いこなせせる必要がああのためには、開発プロセーのメンバー
ーは各メソッド
ドについて、名名前は知ってているものの実
実際のプロジジェクトで活用った。当時、制作センター
ほとんどない状態だった。
した経験はほ構築した開開発プロセス
スには、制作セ
センターだけ
けでなく事業部部が担当する
る範囲の活動もも規定してあある。それは、
ユーザー起
起点のサービスス開発は、戦戦略に関わる開開発ライフサイイクルの超上上流から活動がが始まるからである。そののため、制作セセンターのメン
ンバーは、部
部門を横断した
た開発プロセセス全体の活動
動の流れ、内内容、メソッドをを把握しておおくことが求めめられた。
そこで、開開発プロセスの全体像を制制作センター
ーのメンバーがが把握するたために、開発 プロセス全体
体から主要な
な
20 のメソッド
ドを紹介する「メソッド紹介
介＆ミニワーク
ク」のセッションンを実施したた。具体的にはは、制作センターのうちユユーザーインタタフェース設計計に関わる 16
1 名のメンバ
バーに対して、、1 回 2 時間で、グラグリッ
ッドが 20 のメ
メソッドの概要
要を制作センタターのメンバーに説明し、その後、各メメソッドの利用
用目的と手順順を理解するた
ための簡単な
なワークショッ
ップを行った。
。
その後、メ
メソッドの中ででも実際のプロ
ロジェクトで活活用しやすそそうな 4 つのメソッドにフォーーカスし、そのの詳細を知るる
ための「メソッ
ッド体験会」をを実施した。メ
メソッド体験会
会は、1 つのメメソッドにつきき 2 時間、合計
計 4 回の体験
験会を行い、
各メソッドの深い理解、定定着を狙ったた。実施対象ととしたメソッド
ドは、「エクスペペリエンスマッップ」「エキス
スパートレビュューニングアンケ
ケート」「ユーザ
ザビリティテススト」である。
ー」「スクリー
写真 2 メソッド体験会
会の様子

5. フェーズ 3：プロジェクトへの適用（2012 年 10 月～12 月）
ユーザー起点の開発プロセスの全体像と各メソッドの概要、そして一部のメソッドの具体的な利用方法を知った制作センターのメンバーは、実際のプロジェクトで運用するフェーズ３に入った。
前述の通り、制作センターでは各事業部からの依頼に対して、制作センター内でプロジェクトチームを組み業務を行なっている。プロジェクトでのメソッド適用においては、構築した開発プロセスや習得したメソッドを無理に適用するのではなく、プロジェクトの状況に応じて適用できそうな場合に限り、適切と思われるメソッドを活用する
方針で進めた。特に活用したメソッドは、「デプスインタビュー」とそのインタビュー対象者を選定する「スクリーニ
ングアンケート」、「エキスパートレビュー」、「ユーザビリティテスト」であった。
これらのメソッドが適用可能なプロジェクトに対しては、制作センターの責任者が全体を管理しながら水平展
開し、制作センター内に広めていった。同時に、コストや開発期間などプロジェクト固有の制約条件などにより、「メソッド体験会」で習得した知識がそのまま使えない状況が発生する想定があった。そこで、MTI がメソッドを適用した際に質問や相談事項に対してグラグリッドが回答をするというサポート体制で、プロジェクトへのメソッド適用は進められた。その中でも特に、デブスインタビューのインタビュー計画・構成については重点的にサポートを行った。
5.1．具体的に実施したメソッド
ここで、フェーズ 2、3 で実施したメソッドの具体例を示す。図表 3 は、セミナーで概要を説明したメソッドであるが、その一部をミニワークや体験会で実施し、実際のプロジェクトに応用された。このうち、体験会で実施した 4
つのメソッドの概要を説明する。
図表 3 フェーズ２、３で実施したメソッドの一覧
No.

概要説明

ミニワーク

1

半構造化インタビュー

メソッド名

○

○

体験会

2

コンテクスト調査

○

3

⽇記法

○

4

エンパシーマップ○5

ブレインストーミング

○

6

KJ法

○

7

XB法

○

8

リッチピクチャー○9

エクスペリエンスマップ

○

○

10

カードソーティング

○

○

11

タスクフロー

○

○

12

画⾯遷移図

○

13

アクティビティシナリオ

○14

インタラクションシナリオ○

15

設計原則によるチェック

○

16

思考発話法

○

17

NEM

○

18

デザイン・テイスト・マトリクス○

19

アイコン・マッチング・テスト○

20

コントラスト・チェック○

21

スクリーニングアンケート

○

○

○

22

ユーザビリティテスト

○

○

○

23

エキスパートレビュー

○

○

○

プロジェクト適⽤

○

○
○

○

○

エキスパートレビュー
エキスパートレビューとは、ユーザビリティの専門家が、評価対象におけるユーザビリティ上の問題点を発見する手法である。ユーザビリティの専門家は、人間の特性（身体的特性、認知的特性、環境的特性など）に精通しており、評価対象を利用する際に発生するであろう現象を想定して問題箇所や要因などを明らかにする。評価
は、専門家の主観で行われるため、専門家のスキルに依存するところは大きいものの、短時間に多くの問題点を発見することが可能である。より評価の精度を高めるために、通常は複数人で実施する。
ユーザビリティテスト
ユーザビリティテストもエキスパートレビューと同様、評価対象におけるユーザビリティ上の問題点を発見する手法である。ただし、エキスパートレビューのようにユーザビリティの専門家が評価するのではなく、評価対象を利用するユーザー（被験者）の行動を観察することで、問題点を発見する手法である。被験者は、評価対象を使って、決められたタスクと呼ばれる課題を遂行する。その様子をビデオカメラで撮影したり、別室から直接モニターしたりすることで観察し、問題点の発見や分析を行う。実施には準備のコストが大きくかかるものの、ユーザーのありのままの反応を知ることができるため、発見された問題点の納得性は高い。プロジェクトの状況に合わせてエキスパートレビューとユーザビリティテストを使い分けたり、組み合わせたりする。
エクスペリエンスマップ
エクスペリエンスマップは、明確な定義はなされていないものの、原則としては、サービス利用の時間軸に沿って、ユーザーの行動や思考を図式化したものである。それによって、ユーザーの行動や思考に合わせたサービスの内容や提供の妥当なタイミングを検討することができる。また、図式化され専門の知識を必要としない形式となっているため、開発者関係者間で共通のコミュニケーションツールとしても活用しやすいという効果もある。
スクリーニングアンケート
スクリーニングアンケートとは、インタビュー調査などを行う際の対象者を絞り込むためのアンケートのことである。
インタビュー調査を行う際は、ターゲットとする属性の対象者を適切に選ぶ必要がある。その属性を判別するためには、アンケートにどのような設問を組み込む必要があるかがポイントとなる。企画意図やターゲットユーザーを特定した背景などを考慮して、できるだけ少ない設問で回答しやすいアンケートを作成しなければならない。

6. プロジェクトに対する反応
本プロジェクトを進める上で、事業部および制作センターで起こった反応は以下の通りである。
6.1. 社内取引の円滑化
フェーズ１では、事業部と制作センターにおける社内取引が円滑化した。これまでは事業部と制作センターの社内取引において、事業部側の依頼内容に対する制作センターが見積もる業務内容・ボリュームに、部門間の意識を合わせることが難しい状況が発生していた。例えば、事業部側から依頼された内容に、制作センターが活動内容を提案する際、これまでは「なぜその活動をするのか？」を明確に提示できず、事業部側が納得できないケースがあった。 しかし、構築した開発プロセスをベースに制作センター側から事業部へ話しをすることで、事業部側からすれば必要のないと思われていた制作センター側の提案する業務内容が、受け入れられるケースが生まれた。
6.2. ユーザー起点の開発組織化に向けた課題の明確化
現在の組織体制において、ユーザー起点の開発を目指すために、本来、事業部が行うべきだった活動や制
作センターが行わなければならなかった活動が明確になった。そのため、事業部、制作センターにおいて、どのようなスキル、ノウハウがユーザー起点の開発を行うためには必要かを知ることができた。そのスキルを獲得する
ための課題、目標ができたことが、組織としてのモチベーション向上につながった。
6.3. メソッド活用イメージに関する混乱
フェーズ 2 においては、各メソッドの目的や実施手順などの概要を知っても、実プロジェクトでどう使うのかが活用のイメージがわかず、混乱が生じた。制作センターのメンバーからの質問もプロジェクトでどう適用すればよいかといった内容が挙げられていた。それは、「メソッド体験会」で行ったワークショップの条件と実際のプロジェクトとでは、様々な制約条件が異なり、その条件を考慮してのメソッド利用の応用が難しいという状況になったことと、メソッドを使うことが目的化してしまい検討の本質を見失ってしまうケースがあったためであった。それでも、制作センターのメンバーは、新しいことを知識として習得しているというモチベーションが高く、試行錯誤をしながら、学びを続けていた。
6.4. 制作センターのモチベーション向上
実際のプロジェクトでメソッドを活用するにあたり、MTI がプロジェクトで適用した結果をグラグリッドがレビュー、
アドバイスをする、という活動サイクルを繰り返すことで、メソッドを使いこなす勘所が制作センターのメンバーに浸透してきた。レビューやアドバイス時の MTI 側からの質問の質も変化した。具体的には、メソッドのやり方の内
容に関する質問から、「ユーザーの本質を捉えるためにどうすればよいか？」という点にフォーカスが当たってきた。これは、プロジェクトでメソッドを使うことを通して、魅力的なサービスを作るためにはどうすればよいかというメ
ンバーの意識が強化されていることを示している。また、以前よりも制作センターのメンバーが自主的にユーザ
ーエクスペリエンスをテーマとした社外の勉強会に参加するようなメンバーが増えてきた。このような現象からも、制作センターメンバーのモチベーションはより高まってきた。また、本取り組みに対して、制作センターの枠を越えて、各事業部や経営層からの評判が広まった。その結果、事業部から制作センターへ、ユーザー起点で開発することに対する問合せが寄せられるようにもなった。

以上が、本取り組みを行ったフェーズごとの主な反応である。これら一連の反応の流れを、制作センターのメン
バーにおける学習という観点でまとめたものが図表 4 である。
フェーズ１のプロセス構築によって、社内取引の円滑化や、事業部と制作センターに求められるスキルやノウ
ハウが明確化されたことは、部署の枠を越えてユーザー起点の開発を進める基盤としての理解はされた、といえる。
しかし、フェーズ 2 の段階で、構築したプロセスとメソッドを用いてプロジェクトを実行しようとしても、メソッドの適用イメージがつかずに混乱が生じた。これは、フェーズ 1 でプロセスとメソッドを知りユーザー起点の開発ができると理解していたイメージと、実プロジェクトでのギャップから生まれた混乱であった。それでも、制作センターの責任者のマネジメントによって、プロジェクトでの適用を模索し続けるモチベーションは維持できていた。
その模索を続けているフェーズ２後半からフェーズ３の段階では、状況に応じたメソッド適用における第三者
からのアドバイスがあれば、プロジェクトでもメソッドが使える、という新たな気づきや腑に落ちた感覚をメンバー
は持つことができた。
これら一連の流れは、もともとは他人の知識（プロセス・メソッド）だったものを、経験を通して自分の知識に変換してきた過程と捉えることができる。
図表 4 ユーザー起点の開発に移行する組織学習プロセス

アドバイス

理解

模索・混乱

気づき/
腑落ち

Phase1

Phase2Phase3

他⼈の知識

⾃分の知識

7. プロジェク
クトの成果
本プロジェ
ェクトはまだ進
進行中であるがが、現時点ででの成果についいてまとめておきたい。
7.1 メソッドの整備
ェクトの第 1 の成果は、ユのーザー起点のの開発メソッド
ドが整備されれたことである 。図表 5 は、
、プロジェクトト
本プロジェ
ごとに実際にに適用したメソ
ソッドの一覧でである。17 ののプロジェクトにに対して、それ
れぞれ何らかかのメソッドを適用することとができた。こここで適用したたメソッドは、プロジェクトででかけられる
る時間やコスト
トを踏まえた上
上で、課題にに対する検討討に相応しいメ
メソッドを採用用している。
表 5 実際のププロジェクトでで活用したメソ
ソッド
図表

７.2 メンバーの意識変化
本取り組みを通しての所感を、事業部側、制作センター側の各メンバーに求めたところ、以下のようなコメントが得られた。
事業部側メンバーのコメント
・機能を考える時に「ターゲット顧客にとってどうか？」という指標が具体化された・本質的価値が明確になることにより、表層的でない機能/サービスを実現できる・制作センター並びに開発関係者と温度感同じく推進できる・複合的な視点でアイデアがたくさん出た・企画として今までで一番納得できるアウトプットになると思った・「一丸となる」という言葉が当てはまると感じた
制作センター側メンバーのコメント
・提案とその説明が事業部にしやすい・ユーザーが誰なのかゴールが一緒なので事業部と意志の統一が取れやすい
・意見がぶれても収束しやすい・ユーザーのために作っているという意識がモチベーションを高める（事業部のために作っているのではない）
これらのコメントから、事業部側、制作センター側ともに部門の壁を越えて共有できる「ユーザー」を重視することで、部門間での開発のギャップが縮まり、より魅力的なサービス開発に組織の力を向けることが出来つつあるよ
うに感じられる。

7.3 ユーザ
ザーインタフェースの改善効
効果
図表 6 はは、ｍｙカーナビのサービススで使われていいるユーザー
ーインタフェー
ースの改修前
前後比較であるる。改修前はは、
画面左上のの到着予定時刻の文字サイ
イズが小さか った。運転中中に確認するという状況を考考慮すると、文字サイズ
が小さいこととで、時刻確認
認の負荷が大大きい。その点点を考慮してて、改修後は文
文字サイズを 大きく変更しした。この改修の観点はは、エキスパー
ートレビューででユーザーの 利用状況を考考慮したことかから生まれたたものであった
た。このようにに、ユーザー起起点の開発を実実行することでで、ユーザー
ーインタフェー
ースの改善につつながる効果果がみられた。
。
図 6 my カーナビのユ
図表カ
ユーザーインタ
タフェースの改改修前後比較
較

8. 今後の課題
本取り組み（フェーズ 1～3）を実施して約 1 年が経過した MTI では、現在もユーザー起点でのサービス開発への移行が進んでいる。本取り組みのフェーズ 1 で構築した開発プロセスは、より現場で運用しやすい開発プロ
セスにカスタマイズされている。また、メソッドの基本的な使い方は、制作センターのメンバーが習得し、現在はメソッドをプロジェクトの条件に合わせて使いこなすために試行錯誤を繰り返している。
図表 7 は、ユーザー起点の開発における成熟度モデルを示したものである。作り手中心の開発が中心であっ
た MTI は、フェーズ 3 の段階まで到達していると思われるものの、発展途上の状況にある。以下、MITI の課題について説明したい。

図表 7 ユーザー起点の開発における成熟度モデル

レベル２
組織の成熟度
レベル１【フェーズ４】【フェーズ５】【フェーズ６】

開発プロセスの最適化

メソッドのカスタマイズプロジェクト推進の⼈材育成【フェーズ１】【フェーズ２】【フェーズ３】

メソッドの習得（知る）

プロジェクトでのメソッド適⽤メソッド

プロジェクト

開発プロセスの明⽂化ユーザー起点の開発理念の浸透

プロセス

学びの対象

8.1. 開発プロセスの最適化
現在、図表 5 に掲載したメソッドをベースに、プロジェクトにより適応する開発プロセスの再構築が行われている。今後は、MTI 版の開発プロセスとして最適化されることで、組織としてのマネジメントが効率化するだろう。そのことで、より多くのプロジェクトで、ユーザーの利便性に関わる品質を、一定の水準を保つことが期待できる。
8.2. メソッドのカスタマイズ
フェーズ 2、3 では制作センターのメンバーがメソッドを知り、そのままプロジェクトに適用しようとしていた。しかし、プロジェクトで適用させようとすると前提条件などが異なり、メソッドの手順や形式をカスタマイズしなければならないケースが発生していた。制作センターのメンバーも「プロセスとメソッドを知っていることが条件」と、コメントしていた。これは、何をどこまでカスタマイズできるのかの判断がつかないことに起因している。今後、これらの判断を各メンバーが独自でできるようなスキルを持つことで、MTI オリジナルのメソッドを創出することができるだろう。

8.3. プロジェクト推進の人材育成
現在、プロジェクトでのメソッド適用は、制作センターの管理者が中心に導入を推進している。しかし、プロジェ
クト数が多くなると、それにも限界が生じる。また、制作センターのメンバーも「実施する上では、ファシリテーターが絶対必要だと思った」とコメントしている。そのため、ユーザー起点の開発計画を立案し、実行をマネジメントしたり、プロジェクトのファシリテーションができる人材を育成していくことが、組織的に広めていく上で重要な課題となってくる。

9. おわりに
これまで述べてきたように、MTI ではユーザーにとって魅力的なサービスを提供するため、ユーザー起点の開発を組織的に行う変革を進行させている。本取り組みでは、開発プロセスやメソッドを組織に定着させるための活動を紹介してきたが、目指すべきところは、本取り組みをきっかけとして、組織にユーザー起点の開発を行う
文化を根付かせることである。組織に属するメンバー一人ひとりが、ユーザーにとって魅力的なサービスを開発するためにどうすればよいかを自ら考え、自律的に行動するための組織的なマネジメントが、変革をより進化させていくためには必要となる。

参考文献
経済産業省（2011）「新しい事業を構想・創造する人材を輩出する仕組みを考える研究会報告書」
Garrett, J.J. (2005) 『ウェブ戦略としての「ユーザーエクスペリエンス」―5 つの段階で考えるユーザー中心デザイン』（ソシオメディア訳）毎日コミュニケーションズ
ISO 9241-210:2010Ergonomics of human-system interaction -- Part 210: Human-centred design for interactive
systems[2013.2.25 1115]