【論文】

ウェブサイトおよびスマートフォンアプリケーションのサービス制作における、ユーザー理解のためのプロセスを判断するフレームワークの開発
Development of the Framework to choose Method for Understanding User's Needs on Producing Website
or Smartphone application Services

片山 智弘

Tomohiro Katayama

株式会社電通五十嵐 健祐加藤 浩晃

Kensuke Igarashi

お茶の水循環器内科 院長 ／ デジタルハリウッド大学 校医兼 デジタルハリウッド大学大学院 准教授

Hiroaki Kato

デジタルハリウッド大学大学院

客員教授

サービスはその受容者になるサービスのユーザーを理解することが非常に重要であることは自明である。しかし、ウェブサイトおよびスマート
フォンアプリケーションのサービス制作では、ユーザーを理解するプロセスは既にあるものの、それをサービスの性質や実情に合わせて判断するフレームが存在しない。
そのため、リリースの前段階で誤った手法を選択してしまい、サービスのコスト効率を下げたり、ユーザーの受容性を誤認したままリリースし、サービスを停止・終了させてしまうということも起きている。
本研究では、実際に開発された一定のユーザー数を獲得しているか、売上総利益が黒字化しているウェブサイトおよびスマートフォンアプリ
ケーションのサービスにて、変数を割り当てて集計を行う調査を実施した。
結果、最適なユーザー理解手法を判断するマトリクス図を用いたフレームワーク開発に成功した。
キーワード：ユーザー理解、フレームワーク、サービス制作、開発プロセス

1. 背景

で参考にして取り入れてサービスの価値を高めていく。各プロセス

1.1. サービス開発上のユーザー理解の重要性の代表的な手法とその概要を次に示す。

「サービス」とは「サービスの提供者が、対価を伴って受容者が望む状態変化を引き起こす行為」（下村ら , 2005）と定義されている。

(1) 想定ターゲットプランニング

つまり、受容者がサービスに対してその対価を支払い、かつその想定ターゲットプランニングとは、サービス設計者がそのユーザー

受容者がサービスを受けた上で精神的または物理的な何らかの状態を想像したり、自身がユーザーになる場合はその経験値を思い出し変化を引き起こすことが前提にあるので、その受容者となるサービス

た上で、ユーザーの属性やペルソナ、カスタマージャーニー、課金のユーザーについて、サービスを提供する側はそれを深く理解する

するニーズの想定を行う作業である。

ことが非常に重要であることは自明である。
表 1：想定ターゲットプランニング手法の概要

1.2. ウェブサイトまたはスマートフォンアプリケーション上におけるユーザー理解のための基本的なプロセス

プロファイリングターゲットとなるユーザーの属性をできるだけ細かめに書く。

特にウェブサイトやスマートフォンアプリケーションで提供する

ペルソナ策定プロファイリングしたデータでターゲットとなるユーザーの代表的なイメージを作る。

カスタマー
ジャーニー策定

当該ペルソナの人物がこれを認知して興味を持ち使って、その後どうするかの行動パターンを考えて明文化する。それをペルソナ別・ユースケース別に行う。

課題と課金ニーズ策定

どういう欲求や課題を持っていて、それを何によって解決し、解決した後にどういう状態になるのか検討する。

サービスにおいては、サービスの内容に関するアイデアが企画された後、そのユーザーを理解するための手段として大きく４つのプロセスが存在している。
図 1：ユーザーを理解する 4 つのプロセス(2) ユーザー調査
ユーザー調査とは、実際にユーザーになりうると考えられる人物にあらかじめ決められた質問ルールに沿ってインタビューを行う方法
この 4 つのプロセスは右側に行くほど、原則、設計および開発が進んでサービスの形が具体化している状態であるため、通常はユー
ザー理解のための仮説がより精緻になっていればいるほど右側のプロセスを用いていくことになっている。
次節にてそれぞれの各プロセス内の手法について解説する。

1.3. 各プロセスの解説
各プロセス内にはそれぞれ一般的な手法がすでに存在しており、この精緻化を行って得た示唆を、サービスの企画から設計、実装、デザイン、運営、マーケティングや広報と、サービスのあらゆる面

9 ｜ DHU JOURNAL Vol.05 2018である。インタビューを行うシチュエーションや形式、人数や設問数
がそれぞれ異なり、最適な方法を適宜選択する。

【論文】ウェブサイトおよびスマートフォンアプリケーションのサービス制作における、ユーザー理解のためのプロセスを判断するフレームワークの開発
Development of the Framework to choose Method for Understanding User's Needs on Producing Website or Smartphone application Services

表 2：ユーザー調査手法の概要

大規模パネル
調査グループ

統計的に有意なサンプル数で選択式の質問を中心に調査票を作ってインタビューを行う。仮説を誘導的に持っていきやすい。
そもそものターゲットボリュームが多いときやペルソナ自体が不明瞭なときにも有効。
ユーザー候補のターゲットを3 ～ 5 程度集め、同時にインタビュアーにヒアリングをしてもらい、インタ
ビューを行う。ターゲット間のやり取りや共感度で抽象度の高い仮説を検証するのに有効。
ユーザーにできる限りリラックスした状態で話してもらうために、食事会形式で行ったり、インタビューのやり取りを別室で眺めることもある。

インタビュー

１人に対してインタビューを対話形式で行っていく。
質問が定型でない場合や、細かい表情を見ながら観察したいとき、やや聞きにくいことなどのときにも本音を引き出しやすい手法。

1 on 1

ユーザーにできる限りリラックスした状態で話してもらうために、食事会形式で行ったり、インタビューのやり取りを別室で眺めることもある。

表 4：リリース後の PDCA の概要

定量解析

KPI/KGI の各数値をファネルとして管理する。
ボトルネックを見つけたら定性に移行する。

定性解析

各数値ではなく、反応や動きを解析していく。
どこをクリックしたかというヒートマップなどを用いたり、ユーザーサポートに来ているお問い合わせのデータなど定性的な文字データを扱う場合もある。

こういった定性や定量の解析を、サーバーから直接ログを貯めて解析を行ったり、例えば Google Analytics など簡易的に収集できるツールを活用することで、ウェブサイトではタグを埋めたり、スマート
フォンアプリケーションでは効果測定用 SDK を埋めたりして、データ取得環境を整備して行う。

1.4. 本稿の仮説と目的

エスノグラフィ

１人の、または１組織内にその一員として入って、その動きを追い続ける。
サービスの利用サイクルが長い場合と、ターゲット
自体が自分の理解とかけ離れているときに有効。

前述の 4 つのプロセスは、一般的な流れでは本稿 1.2 に記載の通り、左から右に行くほど、サービスの完成形に近づいていくため、左から右に順番に行っていくこともあるが、本来どの順番で用いても良いし、自明であったり、不要と見られるプロセスであれば飛ばしても良いものであり、必ずしも左から順番に実施しなければならないというものではない。
むしろ、例えば、昨今話題のリーンスタートアップ手法にあるよ(3) プロトタイプ検証

うな、仮説策定後に先に素早くMVP を制作して、制作することでプロプロトタイプ検証とは実際に動くサービスの本リリース前段階のトタイプ検証から行うサービス検証手法も多数存在している。

制作物を用いて、それを実際にユーザーに使用してもらう、または

しかし、どのプロセスと手法を使うかという判断を誤ってしまう

一度販売・公開をすることで検証を行うものである。プロトタイプと、本稿 1.3 に記載した手法を行う分の、時間や工数、費用などを見せながらインタビューを行う場合もある。

に損失を与えてしまう。
更にそれだけではなく、その判断を誤ったということは得られる

表 3：プロトタイプ検証手法の概要

モック

画像の張り合わせで作る。デザインと導線を確認するために使う。

プロトタイプ

公開で発売されていない試作品。製品への反応を見たり、動作の確認に用いる。

MVP(Minimum
Viable Product)

最低限の価値があるプロダクトを実際にユーザーに販売して検証する。
原始的な最低限のサービス提供環境を作り、実際にそれに課金がされるかを見る。

示唆も誤ったものになったり、そもそも示唆自体が全く被験者から得られないこともあるため、目的であるユーザー理解も正しくできない可能性が高い。
この立ち上げ前段階での余計なコスト損失やユーザー理解の見誤
りは、軽微な修正や追加で数日ほどの人的工数や、数十万円程度の損害など比較的インパクトのない損害ですぐにリカバリーできる場合もある。
しかし、サービスのインフラなども含めて大幅にメンテナンスやリニューアルを加えないと軌道修正できないような大規模なサークローズドβ版
リリース

事前に募ったユーザーにのみサービスを限定公開する。
初回の囲い込みをしつつロイヤリティを与えながら、サービスを運用する。この検証がうまくいった場合
そのまま本リリースを行う。

ビスや、テクノロジー的に難しいサービスの場合は、そのミスで最大で数億円近いコストの損害を引き起こすだけではなく、サービスを一定期間クローズしたりすることもある。
また、一般的にベンチャースタートアップで事業を立ち上げる場合(4) リリース後の PDCA
リリース後の PDCA とは、文字通り一度サービスを本リリースしてから、改善サイクルを回していく手法を示している。

は金銭や人員が限られていて、コスト・リソースが少ないことが多いので、最悪の場合はこの判断ミスが原因の１つになり、市場から撤退する要因にもなりうるレベルの高いリスクも存在する。

尚、この文言で使われている「PDCA」は、通常の Plan（計画）、

ユーザー理解のための 4 つのプロセスはそれぞれ性質が異なって

Do（施策の実施）、Check（確認）、Action（次回対策の策定）をしていたり共通性を持っていたりする。例えば、1.3(1),(3)と1.3(2),(4)また Plan に戻るという PDCA サイクルの意味を指すだけではなく、を比較すると、前者の想定ターゲットプランニングやプロトタイプ

軍事手法の OODA サイクルやフィードバックループ、PMF（プロダク

検証はユーザー自体が不確かな仮説がない状態やユーザー側が全くトマーケットフィット）に戻る場合がある運用サイクルなども含んだ、

内容を理解できない状態でも行うことができるが、後者のユーザー

広義的な意味でのサービス運用上の数値計測を行い、それに沿って調査やリリース後の PDCA は、実際にユーザーの存在や仮説がある

サービスを改善する打ち手を行っていく流れを繰り返すことの総称

程度明文化されて理解できうる状態になってから行うものになってである。

いる。また、1.3(1)(2) と、1.3(3)(4) においては、後者は実際にリリース後の PDCA は解析するデータの対象が定量的なデータか
定性的なデータかで、運用上定量と定性に分けて判断する。

エンジニアが開発をしているという特徴があり、工数がかかるものである場合は、それを出してからでは修正が利きにくくなるので、容易に変更ができるものではない場合は採用しにくいなどの特徴がある。

DHU JOURNAL Vol.05 2018 ｜ 10

以上から、どのプロセスを用いるべきかの判断において、そのプロセスでそのサービスをユーザーが理解するまでにかかるハードル（理解のハードル）と、サービスのその開発工数や立ち上げる場合の

表 6：それぞれのハードルと各パラメータ

ハードル

パラメータ名リスクなどの立ち上げるまでのハードル（工数のハードル）、この

評価基準

新規性

既存に同じビジネスモデルとユーザー
フローのサービスが存在しない。

使用語彙

言語化した際にも単語が高等学校教育
でも習わない単語の漢字または科学技術用語を用いる。

操作性

トレ ー ニングを専 門でしないとい けない。なれるまでに時間がかかる。

制作工数

リリースまでに１年以上かかったもの。

知財・権利

特許や意匠、または実用新案、ライセンスが必要なもの。またはリリース後に取得しているもの。

法務リスク

知財以外で日本国内の法律に違反するリスクがあるもの。

2 つのハードルを用いて規則性を出すことができるのではないかというのが本稿の仮説である。
よって、本稿では前述した判断ミスによるリスクを低減するため、

理解の
ハードル
（ハードルⅠ）

実際に制作されて世に出ているサービスのリリース時の手法判断事例を対象に、制作における前述した 2 つのハードルになるパラメータとその 4 つのプロセス選択の相関を調べ、サービス立ち上げの成功確率を上げていくサービス立ち上げ時のユーザー理解のためのプロセスの判断方法に関して研究していく。

工数の
ハードル
（ハードルⅡ）

2. 調査
2.1. 調査対象
本稿の調査対象は、ユーザー理解に成功して、リリース後に一定のユーザー獲得ができていることと収益が上がっているものを対象として、下記の定義Ⅰ、定義Ⅱのどれかを満たすものにした。

各対象サービスにおいて該当するものは 1 点、しないものに 0 点をつけて、各対象サービスサンプルにて集計した。
そして、ユーザー理解のためのプロセスの 4 つのどれかで、サー尚、サービスが終了したものに関しては、調査対象から除外した。

ビス制作の中で実際に制作時に最初に行ったもの、またはリリース

定義Ⅰ（ユーザー獲得）：10 万人以上の登録会員を保有している

したものか、制作者のインタビュー記事などで事実として公表され時に最初に行ったと制作元の責任者または担当者からヒアリングを
ウェブサイトサービスまたは iOS, Android 合計で 10 万インストール
以上を獲得しているスマートフォンアプリケーションサービスているものを記載した。
その各パラメータの因子と点数を横軸と縦軸に分けて、4 つの定義Ⅱ（収益獲得）：定義Ⅰではないが、売上総利益が 2018 年

プロセス別に集計して平均値の差異のマッピングを行った。また、

8 月段階で黒字化していることが官報または決算、または事業主と4 つのプロセスと理解のハードルと工数のハードルを点数別に集計しての実数値で確認できているウェブサイトサービスまたはスマートも行った。

フォンアプリケーションサービス
以上から、国内のウェブサイトサービスおよびスマートフォンアプリ
ケーションサービスとして、表 5 の 49 サービスを対象に実施にした。

サービス名称

定義Ⅱ

各プロセス別のそれぞれのパラメータの平均値は図 2 のようになった。

表 5：本調査対象のサービス一覧

定義Ⅰ

3. 結果

Airbnb,Anyca,cameran,CASH,facebook,PIAZZA,Pinterest,
radiko,Smart HR,Spotify,Uber, キャンディークラッシュ（日本Ver.), クイズ RPG 魔法使いと黒猫のウィズ ,スタディサプリ大学受験講座 , 白猫プロジェクト , パズル＆ドラゴンズ , ポケモン
GO, マガストア , マンガほっと ,メルカリ, モンスターストライク
Begin,BiCYCLE CLUB,CROSS-VALCON,ESSE,f l i c k ! ,G O E T H E , G r o w t h E d g e , H i V i , M a c F a n , MEN's E X ,NHK ラジオ 入門ビジネス英語 ,NHK ラジオ ラジオ英会話 ,pen,RIDERS CLUB,Wantedly People（ 広 告 サ ービス ）,Web
Designing, サンキュ！, サンデー毎日 , 週刊 Gallop, 週刊 SPA!,
週刊ゴルフダイジェスト , 週刊東洋経済 , 将棋世界 , ステレオサ
ウンド, たまごクラブ , ひよこクラブ , 料理通信 ,ワイン王国

図 2：各プロセスでのパラメータ平均値
1.2
1.0
0.8
0.6
0.4
0.2
0
制作工数

知財・権利

法務リスク

新規性

使用語彙

操作性

プロトタイプ検証

ユーザー調査リリース後のPDCA

想定ターゲットプランニング

平均

2.2. 調査方法
最初に調査対象サービスへ、仮説である理解のハードル（ハードルⅠ）と工数のハードル（ハードルⅡ）に分けて、その中を区分する
パラメータ名を付けた。

11 ｜ DHU JOURNAL Vol.05 2018

次に各パラメータではなく、理解のハードルと工数のハードル
別に平均点数をまとめて、カラースケールを割り振った表にすると
表 7 のように各プロセスで有意な差になる。

【論文】ウェブサイトおよびスマートフォンアプリケーションのサービス制作における、ユーザー理解のためのプロセスを判断するフレームワークの開発
Development of the Framework to choose Method for Understanding User's Needs on Producing Website or Smartphone application Services

ユーザーが操作しないとならないものに関しては、プロトタイプを

表 7：各プロセス別のハードルのパラメータ平均値

4 つのプロセス

平均 /
ハードルⅠ

平均 /
ハードルⅡ

作ってそれをユーザーに見せて実際にその受容性を検証することで、ユーザーの受容性を確かめて理解を深めることができると言える。
この考察で導いたフレームワークは、今後もサービスの検証数を想定ターゲットプランニング

2.20

2.00

ユーザー調査2.00

0.50

このフレームワークを用いながら成功するサービスを生み出せるか

プロトタイプ検証

0.78

2.22

実際に実験することで、再現性を実務で実証していくことが可能でリリース後の PDCA

0.90

0.14

増やしてこの再現性を確かめていくことが可能である。また、逆にある。
また、今回はサンプルの中にゲームや電子書籍が多いが、BtoB
サービスや、メディアや情報ポータルサービスのアプリ、顧客管理のつまり、理解のハードル、工数のハードルどちらも高い場合にために制作するポイントやクレジットカードなどの会員ポータルア

想定ターゲットプランニングを選択しやすく、理解のハードルは高いがプリなど、中のサービスが違うものをもっと細分化して集計すると、工数のハードルが低いとユーザー調査を選択しやすく、逆に理解の更に傾向値が見えた上でこのフレームワークが仮説が強固になる

ハードルが低いが工数のハードル的には作れるものに関してはプロことが検証できると考えられる。

トタイプ検証から入りやすく、どちらのハードルも低い場合はすぐにリリースしていることがわかった。

他、実際にかかった工数の人月の実数がわかるサンプル数を増やしたり、更に理解のハードルを細かく定義してプロットしていけば、
より正確にマトリクスのどの部分で判断するべきかを判定できるように精緻化できる可能性がある。

4. 考察
集計の結果から、縦軸にサービスの内容や操作などの理解のハードル、横軸に工数のハードルをまとめて配置してマトリクス図を作成
すると図 3 のようになる。

5. まとめ
実際に世に出ている一定規模のサービスのリリースまでの流れを集計した結果、今後の検証の余地はあるものの、どのユーザー理解

図 3：サービスの理解難易度と工数によるプロセス判断のためのプロセスから判断すればいいのか簡易に判別できるフレーム
ワークとなるマトリクス図を導き出すことに成功した。

6. 今後の展望
本稿はサービスサイエンスの中で、特にデジタル分野の立ち上げ時の開発プロセスに特化したものであるが、まず、サービスサイ
エンスのコンセプト自体が表に出たのが 2004 年 12 月にアメリカ
IBM 会長のパルミサーノが共同チェアマンとして発行した全米競争力評議会の提起書「Innovate America」の中と言われており（安部 ,2005）、まだ 14 年程度の歴史しかない比較的新しい学問である。
今回のような先行研究は見つかっていない。
また、サービス開発やシステム導入も含んだデジタル化推進の流れ
そのものも日本では遅れており、一般社団法人日本情報システム・
上図のそれぞれの象限について考えると、第一象限のようにユー
ザー理解におけるプロセスの選択において、工数が低く、内容が簡単な 場 合 はリリース後の PDCA ということで、一旦リリースをして市場に先に出してしまい、その反応を定量または定性で確認して、それに沿って素早く改変を加えていくことをしていく。
次に、第二象限のようにサービスの内容としてはわかりやすく、ユーザーに伝えることが比較的簡単でかつ操作などのイメージもしやすいものであるが、工数やリスクを伴うものであれば、すぐには制作せず、ユーザー調査のインタビュー手法を使ってユーザーへの受容性をテキストやインタビューベースで検証して確証を得ていくべきと言える。
また、第三象限のように、サービス内容や操作なども難しく、工数がかかる場合やハイリスクである場合は、できるだけユーザーをプランニングしてユーザー像とそのユースケースの正確性を上げてから、他象限の内容に取り掛かるべきと言える。
最後に第四象限のように、制作にかかる工数やリスクは少ないが、ユーザー協会と野村総合研究所の共同調査においては、日本企業自体も欧米に比べて圧倒的に遅れている危機感を持っている会社が 9割以上ある中で、デジタル化によって新しいサービスの創出やビジネスモデルの発見、顧客体験価値の増大などを目指している会社が最も多いことが判明している。更に実際の活動意向や実施率も高まっているが（日本情報システム・ユーザー協会ら , 2018）、その課題として、成果の出ている企業ほど「検討体制やリソースの不足」や「デジタル人材の確保」「既存システムの改修スピードやコスト」が挙げられている（日本情報システム・ユーザー協会ら , 2018）。
以上から考えても、このウェブサイトやスマートフォンアプリケー
ションを中心にしたデジタルサービスを立ち上げ推進していく上でのプロセスを判断していくポイントの研究は今後も深く分析していく必要があるテーマであると言える。
本稿で提示したフレームワーク自体の結果を更に考察して検証・
深堀りする要素は本稿 4. 考察の後半でも述べたが、本稿のテーマは
具体的には 3 つの拡張性がある。

サービスの内容が難しいときや、複雑な要素を加えて設計しており、

DHU JOURNAL Vol.05 2018 ｜ 12

まず、初期のユーザー理解のためのプロセスおよび手法判断をし【参考文献】

た後の推移や流れを体系化することができないかを再現性をもって試すことができるかである。そもそも本稿 1.2, 本稿 1.3 で紹介した

下村芳樹・新井民夫 (2008).「 サービス工学におけるオントロジー中心

ようにプロセスそのものに一般的な流れはあるので、どのプロセス

設計の展開」『人工知能学会誌』, Vol. 23, No. 6, 721-727.

でどの手法をどの順番で実施したかまで細かく追えると、更に法則性を発見できる可能性がある。
次に、プロセスを判断したのち、各プロセス内の具体的な手法で最適なものを選んでいく方法にまで拡張していくことができる可能性

下村芳樹・原辰徳・渡辺健太郎・坂尾知彦・新井民夫・冨山哲男 (2005).
「サービス工学の提案：第 1 報 , サービス工学のためのサービスのモデ
ル化技法」『日本機械学会論文集』C 編 , Vol.71, No.702, 669-676.

である。ユーザーインタビューのプロセスを選択したのちに、例え

田崎勝也・二ノ宮卓也（2013）．日本人のレスポンス・スタイル：構造方

ば大規模パネル調査で済むにもかかわらず、エスノグラフィで入って

程式モデリングを用いた探索的研究

社会心理学研究，29, 75–85.

しまわないためにはどうするかや、プロトタイプ検証手法はモックでいいのか、それともフロントの一部は通信も利くプロトタイプにすべきかなど、プロセス内の手法を選択することにまで深められる
可能性がある。
最後に、本稿はプロトタイプ制作が可能かつ、修正したい部分が上野啓子 (2004). 『マーケティング・インタビュー 問題解決のヒントを「聞き出す」技術』, 東洋経済新報社 .
ライアン・ホリデイ (2015)『グロースハッカー 第 2 版』
（加藤恭輔 解説 , 佐藤由紀子 訳）日経 BP 社

ある際にすぐに修正ができて PDCA を回しやすいウェブサイトやスマートフォンアプリケーションでのデジタルサービスを対象にしてエリック・リース (2012)『リーン・スタートアップ ムダのない起業プロ

いるが、デジタルではない、例えば医療サービスや飲料・食品など

セスでイノベーションを生みだす』（井口耕二 訳・伊藤穰一 解説)日経BP社.

の他のリアルサービスの領域にもこのプロセス判断手法を拡張して用いることができないかである。2010 年代前半から「フィンテック」
や「ヘルステック」、「アド（広告）テック」「不動産テック」といった、
領域×テクノロジーの造語が現れはじめ、IoT などの技術を用いた

安部忠彦 (2005)『研究レポート No.246 December 2005「サービスサイ エ ンス 」と は 何 か 』(http://www.fujitsu.com/downloads/JP/
archive/imgjp/group/fri/report/research/2005/no246.pdf)

デジタルとリアルが融合したサービスが出ている。そういったリアル

松山貴代子 (2005)『ＮＥＤＯ海外レポート ＮＯ.949, 2005. 2. 9とデジタルのハイブリッドになった場合には、それをコントロールし【特集】産業政策 米国「国家イノベーション・イニシアティブ」の報告書

たり、役務提供を行うデジタルサービスの開発が必ず入ってくるた『Innovate America』：（概要）』(http://www.nedo.go.jp/content/

め、この判断手法を用いることができる可能性があると考えられる。

100106165.pdf) (2005 年 2 月 3 日 )以上からサービス開発や立ち上げでのプロセスの推移や具体的な手法の選択、リアルサービス領域への応用に至るまで多数の研究余地がある。

片山智弘 (2015)『ウェブサービスとアプリの「提供価値」と「哲学」|ウェブ
電通報』(https://dentsu-ho.com/articles/2522) (2015 年 5 月 19 日 )そのため、今後も、デジタル化が遅れた日本のサービス開発環

上阪徹 (2014)『 上阪徹が探る、リクルートのリアル：月 980 円のオン境下での推進手法の発展を担っていける可能性があるという点で、

ライン 予 備 校「 受 験 サプリ」は、どのようして生まれ た の か (1/6) 』

ポテンシャルのある研究テーマの１つであると考えられる。

(http://bizmakoto.jp/makoto/articles/1404/25/news009.html)(2014 年 4 月 25 日 )謝辞
本稿の執筆にあたり、共同研究者である、五十嵐建祐准教授および加藤浩晃客員教授には、執筆機会と、内容に関するご指導とご鞭撻

上阪徹 (2014)『 上阪徹が探る、リクルートのリアル：月 980 円のオン
ライン 予 備 校「 受 験 サプリ」は、どのようして生まれ た の か (2/6) 』(http://bizmakoto.jp/makoto/articles/1404/25/news009_2.html)(2014 年 4 月 25 日 )をいただいた。
そして、この 調 査 研 究 の 元となった 私 の 2018 年 6 月 28 日 の授業に出席していただいたデジタルハリウッド大学大学院デジタル
ヘルスラボの大学院生の皆様および当日参加した株式会社電通の後輩社員の３人からも、様々な視点から示唆のある質問やディスカッ
ション、フィードバックをしていただいた。
そして、英文の抄録に関しては、株式会社電通にて同じ部署の後輩である渡邉久也さんに英文法表現や語法に関して海外での実務

上阪徹 (2014)『 上阪徹が探る、リクルートのリアル：月 980 円のオン
ライン 予 備 校「 受 験 サプリ」は、どのようして生まれ た の か (3/6) 』(http://bizmakoto.jp/makoto/articles/1404/25/news009_3.html)(2014 年 4 月 25 日 )井上理 (2016)『ポケモン GO の開発秘話から今後まで、幹部語る

ポケモン宇都宮専務インタビュー（後編）』(https://business.nikkeibp.co.jp/
atcl/report/16/081700063/082900009/)(2016 年 8 月 30 日 )経験を活かしてご指摘をいただいた。
また、デジタルハリウッド大学事務局の山口豪様には、原稿の入 稿 に関する応対を丁寧にしていただいた。そのおかげで業務の合間での論文執筆を諦めず実施することができた。
以上の方々へ深く感謝の意を表する。

Newspicks 編集部・福田俊介 (2015)『 教育界の破壊者 受験サプリに集う７人のイノベーター #01 受験サプリの生みの親・山口文洋。自称「 暑 苦 し い 男 」の 生 き 方 』(https://newspicks.com/news/1035089/
body)(2015 年 6 月 29 日 )西本守人 (2016)『ヒアリング回数は 200 回超え。ユーザーの声が私たちのサービスを作り上げた。| 株式会社 KUFU』(https://www.sekai-lab.
com/times/?p=4056)(2016 年 9 月 28 日 )13 ｜ DHU JOURNAL Vol.05 2018

【論文】ウェブサイトおよびスマートフォンアプリケーションのサービス制作における、ユーザー理解のためのプロセスを判断するフレームワークの開発
Development of the Framework to choose Method for Understanding User's Needs on Producing Website or Smartphone application Services

佐野正弘・山下博人 (2014)『「クイズ RPG 魔法使いと黒猫のウィズ」開発者に聞く、アプリ開発秘話｜ Mac』(https://weekly.ascii.jp/elem/000/
000/242/242004/)(2014 年 8 月 2 日 )appbank(2012)『【徹底インタビュー】「パズル &ドラゴンズ」はこうして作られた。』(http://www.appbank.net/2012/04/11/iphone-news/
395927.php)(2012 年 4 月 11 日 )吉田大樹 (2017)『 テクノロジーを駆使した、リアルでつながる街づくり』(http://parallelq.com/job-offer/ テクノロジーを駆使した、リアルでつな
がる街づ )(2017 年 8 月 11 日 )Henrik Kniberg (2013)『 How Spotify builds products』(https://blog.crisp.se/wp-content/uploads/2013/01/HowSpotify
BuildsProducts.pdf )(2013 年 1 月 18 日 )高橋睦美 (2016)『フリマアプリ勝敗を分けた要因は「遊びと早さ」メルカ
リ・BASE社長対談（前編）』(http://hrnabi.com/2016/04/11/10636/)(2016 年 4 月 11 日 )高橋睦美 (2016)『フリマアプリ勝敗を分けた要因は「遊びと早さ」メルカ
リ・BASE社長対談（後編）』(http://hrnabi.com/2016/04/13/10638/)(2016 年 4 月 13 日 )ログミー株式会社・インフィニティベンチャーズ LLP (2015)『コロプラ
千葉氏が語る「白猫プロジェクト」「黒猫のウィズ」開発の裏側』(https://logmi.jp/113457)(2015 年 6 月 26 日 )一般社団法人日本情報システム・ユーザー協会・野村総合研究所シス
テムコ ン サル ティン グ 事 業 本 部 (2018)『「 デ ジ タ ル 化 の 取り 組 みに 関する 調査」ーデジタルビジネスに関する共同調査ー ＜デジタル化
は ど の よ う に 進 展 して い る の か？ ＞ 』(http://www.juas.or.jp/cms/
media/2018/05/Digital_17_ppt.pdf)(2018 年 5 月 23 日 )濱口翔太郎，ITmedia ビジネスオンライン (2017)『欧米に追いつくには？：企業幹部の 9 割、「デジタル化の遅れ」に危機感』(http://www.itmedia.
co.jp/business/articles/1703/02/news055.html )(2017年3月2日)
平 野 武 士 (2017)『 ス マ ホ で 撮 影「 即 入 金 」の 質 屋 ア プ リCASH、
STORES.jp 創業の光本氏が公開―ノールック少額融資を可能にしたその方 法とは 』(http://thebridge.jp/2017/06/bank-cash)(2017 年
6 月 28 日 )DHU JOURNAL Vol.05 2018 ｜ 14

【論文】ウェブサイトおよびスマートフォンアプリケーションのサービス制作における、ユーザー理解のためのプロセスを判断するフレームワークの開発
Development of the Framework to choose Method for Understanding User's Needs on Producing Website or Smartphone application Services【Paper】

Development of the Framework to choose Method for Understanding User's Needs on
Producing Website or Smartphone application Services
Tomohiro Katayama 1, Kensuke Igarashi 2, Hiroaki Kato 2( 1DENTSU INC., 2Graduated School of Digital Hollywood University)
Understanding user needs is obviously important to produce services.
When it comes to producing websites and smartphone apps, there are some methods to understand user needs. However, there
is no framework which enables us to choose the best method, depending on its nature and situations.
Therefore, some developers chose wrong methods prior to its launch and fail to improve the cost efficiency. Some developers
misunderstand user needs and launch services, and it leads to a termination of the services.
In this paper, based on a survey with the samples of websites and smartphone apps which gained a certain number of users, or
which went into the black, I have developed a framework and a metric to clarify the best method to understand user needs.
Keywords: User needs, Framework, Service production, Methods

15 ｜ DHU JOURNAL Vol.05 2018