Webに足りなかったもの

私はWebが大好きです。リンクを1つクリックしたら（インストールなど煩わしい手続きなしで）すぐに新しいコンテンツを読めるのは最高の体験だなと常日頃感じています。ただし、今までのWebアプリのユーザー体験は決して最適なものではないとも思っています。たとえば以下のような体験をした覚えはありませんか？

• 朝の満員電車でも情報収集に勤しむ現代のビジネスパーソンのあなた。つり革に捕まりながらなんらかの記事コンテンツを見ようとリンクをタップする
• 途端にHTMLのレスポンス待ちで真っ白な画面。レスポンスが返ってきたと思ったら今度はWebアプリ側のローディングGIFが動き出す。
• しばらく待つとテキストが表示され読み始めるものの、時間差で画像が差し込まれレイアウトがずれる（どこを読んでいたんだっけ？）。極めつけは全画面広告が画面を占拠し、嫌になってそっとブラウザを閉じる（代わりにソーシャルアプリやゲームアプリを起動する）。

このように世に出回っている多くのWebアプリはパフォーマンスに課題があります。特に、さまざまなスペックなデバイスがあらゆる環境で利用されるモバイルにおいては、Webアプリは単純に耐えられないくらい遅く、実測で3G回線と同等な環境における平均ページロード時間は19秒もかかっているという統計もあります[1]。 Webアプリはとにかくこのパフォーマンスをどうにかしなければなりません。

一方ですでにネイティブ アプリに慣れ親しんでいるユーザーの期待値を満たすためには、パフォーマンスを改善するだけでは十分ではありません。

• ホーム画面にアイコンを追加したり
• プッシュ通知がタイミングよく送られてきたり
• オフラインでも動作する信頼性だったり

「ユーザー体験の基準」がどんどん上がっていくなか、Webアプリだけがこのような体験を提供できずに取り残されている状況がずっと続いていました。時代に合わせて、ユーザーが求める機能性もWebアプリで実現できなければならないのです。

PWAはベストプラクティス集である

そこで満を持して登場したのがPWAです。PWAと聞くと何かを特定の技術を指すものと思われるかもしれませんが、実はそのコンセプトは幅広く、どちらかというと前述した Webアプリ本来の課題を解決し、よりよいユーザー体験を実現するためのベストプラクティス集のようなものです。Googleが提供しているProgressive Web App Checklist なるものがあり詳細な内容はそちらを確認いただければと思いますが、PWAのコンセプトをざっくり申し上げると以下となります。

• とにかくパフォーマンスいいWebアプリを作りましょう。SPAでもSPAじゃなくても、どんなフレームワーク使っても使わなくても、なんでもいいので、表示が速くて画面遷移がスムーズなものにしてユーザーに好かれましょう。
• また、最新のWeb APIを積極的に使って、機能性も身につけましょう。たとえば、Webアプリをホーム画面に追加できるようにしたり、オフラインでも動作するようにしたり。そんな今までWebアプリでは実現できなかった機能が実装できるようになったんだから、やらない手はないでしょう？

少し上記でも触れていますが、PWAはあくまでベストプラクティス集なので特定のサードパーティーフレームワークやライブラリには依存しません。世の中には ReactやAngularを使ったPWAもありますし、Vanilla JavaScriptなPWAもあります。また、サーバーサイドの構成には一切言及しません。したがって技術スタックを変えずとも適用可能なベストプラクティスでありますし、一度に全部を適用するのではなく段階的に（= Progressively）最適化することもできます。

以下の項目でPWAの特徴をより具体的に見ていきます。

ハイパフォーマンス

何より重要であり最も難しいテーマとなります。パフォーマンスの基準としては、2015年にChromeチームが発表したユーザー中心に考えるパフォーマンスモデルであるRAIL[2]を前提に考えていただければ間違いありませんが、各Webアプリの特性や環境に応じてそれぞれのサービスごとに Performance Budget（ロード時間やファイルサイズ等の上限を決め、それを「予算」として管理する）を設けることをオススメします。たとえば、2017年のChrome Dev SummitでChromeチームが推奨したPerfromance Budgetは、TTI（Time to interactive)を5秒以内、それを実現するためにクリティカルパスのファイルサイズを170KB以内に収めるというものです。[3][4]

何事もまずは現状分析から。Webアプリのパフォーマンス測定やプロファイリングをするLighthouseやChrome DevTools等のツールを使って現状の評価とボトルネックを確認し、対応すべきポイントを決めて最適化を進めます。その後はCalibreやSpeedCurveといったパフォーマンスモニタリングツールを利用して定点観測するといいでしょう。

ハイパフォーマンスなPWAを作るためのデザインパターンであるPRPLパターンもまた参考にすべき方式です。PRPLパターンはPush 、Render、Pre-cache、Lazy-loadの頭文字を取ったもので、主にApp Shell モデルやSPAを採用したWebアプリのために用意されたパターンですが、それ以外の構成に関してもパフォーマンス向上のヒントとなる点が多くあります。

• Push/Render: 初期描画に必須なリソースをHTTP/2 Server Pushするか link rel=preload を利用することで先行取得します。そしてそのリソースを利用し、特にAbove the fold [5] (スクロールしないで見える範囲)を優先してレンダリングします。
• Pre-cache: 次ページ（またはルート）で使用するであろうリソースを先読みします。これにはService Workerを利用するといいでしょう。
• Lazy-load: 初期描画に必要なもの以外はすべてLazy-loadします。SPAであれば別ルートの取得がこちら該当しますし、スクロールに合わせたフラグメントの取得であればIntersection Observer APIを利用するといいでしょう。

上記のとおり、Webアプリでもパフォーマンスをあげるためのツールやデザインパターンなど、使えるナレッジが多くたまってきました。ぜひともこれらを利用してハイパフォーマンスなWebアプリの開発を実現してください。

ホーム画面に追加

Web App Manifestを実装するとWebアプリをホーム画面に追加できるようになります。以下のようなJSON形式のマニフェストファイルを用意し、

{
   "name": “PWA Demo Application”,    
   "short_name": “PWA demo”,
    "icons": [{
        "src": “/assets/icon.png”, "sizes": “192x192”
     }],
    "start_url": “/index.html”,
    "display": “standalone”,
    "scope": “/”
}

link タグでページにひも付けた上で、Service Workerをインストールすると、

<link rel="manifest" href="/manifest.json">

<script>
if ('serviceWorker' in navigator)    
   navigator.serviceWorker.register('/sw.js')
</script>

このようにホーム画面へ追加を促すプロンプトが上がってきます。ホームに追加した後はフルスクリーンで起動しますし、Androidの場合は1つの アプリとしてみなされディープリンクまで可能です。

1点補足すると、この「ホーム画面に追加」は強力ですが、よりユーザーに気持ちよく追加してもらえるように、意味のあるタイミングでプロンプトを表示するとさらにいいでしょう。これを実現するためにぜひともonbeforeinstallpromptイベントハンドラーを利用してください。

onbeforeinstallpromptイベントハンドラーはプロンプトが表示される直前に呼び出されます。そのタイミングでプロンプト表示が適切でなければ表示をキャンセルし、別の任意のタイミングで表示することができます。たとえば、画面上に独自の「ホームに追加アイコン」を作成し、それの onclickのイベントハンドラ内でプロンプトを表示させることも可能です。

var deferredPrompt;
window.addEventListener('beforeinstallprompt', (e) => {
  console.log('beforeinstallprompt Event fired');
  // デフォルトのタイミングでは表示させない
  e.preventDefault();
  // Eventオブジェクトを保存しておく
  deferredPrompt = e;
  return false;
});
// どっか別のタイミングで...
deferredPrompt.prompt();

また執筆時点での最新のChrome Canary (67.0.3394.0)ではプロンプト表示形式を以下のように変更して、ホームに追加の体験をより良くすべく機能検証をしています。ポイントはページ下部に表示されるバナーがコンテンツの邪魔にならないサイズに調整され、PWAが追加済であればそのディープリンク用のバナーに差し替えます。また、前述のprompt関数を利用してユーザーのインタラクションに応じてプロンプトを表示する際は、モーダル表示に切り替わります。

オフライン対応

ハイパフォーマンスの解説でも少し登場したService Worker と Cache APIを利用することでWebアプリをオフラインで実行することが可能になります。Service Workerとはオリジン単位（またはパスの粒度）でインストール可能なJavaScriptで書かれたクライントサイドプロキシのことで、ページ内で発生するHTTPリクエスト / レスポンスを監視したり、それを書き換えたり、必要に応じてリソースを先読みすることもできます。これとCache APIというHTTPリクエスト/ レスポンスオブジェクトをKey-Value形式で保存できるAPIを組み合わせることで、オフライン時でもあらかじめキャッシュしておいたレスポンスを利用すことができるようになるわけです。

このService WorkerとCache APIの組み合わせは「Service Worker の紹介」に記載の方法で使用することができますが、より汎用的な使い方をまとめたWorkboxというライブラリを利用するのも1つの手です。Workbox を利用すると実装が煩雑になる、特定のファイルのラインタイムキャッシュも以下のようにシンプルに記述することができます。

workbox.routing.registerRoute(
  new RegExp('.*\.js'),
  workbox.strategies.networkFirst()
);

Workboxはその他にも、ファイル単位でリビジョンを付与したPrecaching、Expirationの定義やBackground Syncを利用したオフライン時の Google Analytics の計測などの機能も提供します。

オフラインの戦略はWebアプリの特性に応じて変わってくるものです。例えばニュースサイトであれば、トップページに出ている注目記事をすべて先読みし、オフラインでも読めるようにすることも考えられますし、ECサイトであればまた別の戦略が適している場合もあるでしょう。電波状況が比較的良好な日本においても、速度制限や電車内などオフライン（または不安定なネットワーク）になりえるユースケースは存在しますし、最低限でも Offline Dinasourはユーザーに見せないようにフォールバックページを用意すべきです。

その他のWeb API

以下にPWAを実装する上で注目すべきその他のWeb APIを列挙します。

• プッシュ通知: Push API / Notification API
• 自動ログイン: Credential Management API
• 支払いフォームの強化: Payment Request API

上記のAPIも組み合わせることによって、リエンゲージメント性の向上や商品の購買フローを最適化することができます。

クロスプラットフォームなイニシアチブ

上記にあげたPWAで利用するWeb APIは、すべてのブラウザで利用できることを目標に標準化を進めています。個別の対応状況を確認するにはCan I Useをご参照いただければと思いますが、冒頭に述べましたとおりiOSでもiOS 11.3からSafariでService Workerが動作するようになりましたし、Microsoft はWindowsストアにPWAを載せはじめました[6]。このように、さまざまな形でPWAのクロスプラットフォーム利用の機運が高まっていると言えます。

また、PWAはProgressive Enhancementな実装を推奨している点も改めて触れておきます。たとえばService Workerを利用したオフラインキャッシュの実装は、Service Workerが未実装なブラウザでもWebアプリ本来の動作には影響がないように以下のように条件分岐をいれることを推奨しています。

// ServiceWorkerが利用できる場合にのみ
if ('serviceWorker' in navigator) {
  // ServiceWorkerを登録する
  navigator.serviceWorker.register('/sw.js')
}

特定の環境のみでしか動かないWebアプリを作るのではなく、どの環境でもハイパフォーマンスに動作するようにし、最新のWeb APIが利用できる環境では進んでそれをレバレッジするとよいでしょう。

Webアプリ vs ネイティブ アプリ

PWAはその機能性や実現したいコンセプトから「PWAはネイティブ アプリを潰そうとしているのか？」「Webアプリがネイティブアプリにかなうはずない！」など当該テーマにおいては辛辣なコメントを見かける場面もあります。ここで1つお伝えしたいことは、多くのユーザーはネイティブアプリなのかWebアプリなのかというプラットフォームの選択には関心がないということです。大事なのは「うまい、やすい、はやい」ユーザー体験の良いサービスを提供することです。PWAの出現によりWebアプリでもそれを実現する準備が整いつつあり、事業者やソフトウェア エンジニアとしては理想のサービスを提供できるプラットフォームのオプションが増えるという意味で、このWebの進化を前向きに捉えていただければ幸いです。

実際Webアプリにはまだできないこともあります[7]。ただし、Webアプリには他のプラットフォームよりも優れたリーチがあり、その意味でWeb アプリとネイティブ アプリがむしろ手を取ることは、戦略としても決して矛盾しません。

使用したい機能がWebプラットフォームが提供するもので十分であり、技術スタックをWebのみに集約するメリットも感じるのであれば「PWA のみ」という選択肢も今後は出てくるかと思います。しかし、前述した「まだできないこともある」という前提を加味するとネイティブアプリが活躍する場面は引き続きありますし、PWAは「Webアプリ vs ネイティブアプリ」という二者択一を迫る提案ではない点をご理解ください。

ユーザー体験の新たな基準

このようにPWAはWebアプリの「ユーザー体験の新たな基準」を満たすために作られたベストプラクティスでしかありません。重要なのはそれぞれの機能を単純に実装するのではなく、Webアプリの特性に応じて使い分け、ときにはカスタマイズし、ユーザーによりよいサービスを提供することです。今回ご紹介しました各種ツールやデザインパターン、iOSでもService Workerが利用できるようになった点など、舞台は整いつつあります。ぜひとも最高のWeb体験を実現すべくPWAの考え方を取り入れてみてください。

• [1] The need for mobile speed: How mobile latency impacts publisher revenue
• [2] RAILモデルでパフォーマンスを計測する
• [3] Fast By Default: Modern Loading Best Practices (Chrome Dev Summit 2017)
• [4] Can You Afford It?: Real-world Web Performance Budgets
• [5] Above the fold
• [6] First Windows 10 Progressive Web Apps (PWA) published by Microsoft hit the Store
• [7] What Web Can Do Today

E-Commerceから Conversational Commerceへ

ここ最近話題になることが多いAIやBotsですが、私の周りではConversational interface、Conversational UXなどという言葉が去年からたびたび使われるようになっているようです。

これはAmazon Alexaなどのデバイスや、Facebook Messengerなどチャットアプリケーションなどの対話型テクノロジーをいかに活用しその使い勝手をよくするか、ということなのですが、必ずしもアプリケーションのUIデザインそのものを述べているわけではなく、既存のサービスを延長することを指していることも多いでしょう。例えば、今まではモバイル上のアプリケーションのみで車を呼べていたUberが、Facebook Messenger のチャットからも車をを呼べるような機能を加えたり、Slack上でTaco BellからタコスをオーダーできるTacoBot、というのもが挙げられます。

Slack Botを書いてみよう

さて、というわけで何かBotを書いてみたいと思いませんか？ここはNode.jsでSlack botを作成する方法を紹介したいと思います。

このチュートリアルでは、ディベロッパー向けのHTTPステータスコードのルックアップができるスラッシュ・コマンドを作ってみます。ここでは私が５年ほど前に何気なく作って、Mashableなどで紹介され思わぬ反響を得てしまったHTTP Status Catsを使ってみます。具体的には、Slack上でユーザが、/httpstatus [code] （例えば /httpstatus 404）と入力すると、そのステータスコードの意味と猫が一緒に表示される、という簡単なbotです。

まず試してみたい方は、HTTP Status Cats command for Slackを自分がアドミン権限のあるのチャットチームにインストールしてみてください。

さて、このチュートリアルは２つのパートに分けられます。

1. スラッシュ・コマンドを書いて、自分のSlackチームにインストールする
2. OAuthを使ってボットをSlack’s App Directoryなどで誰もがインストールできるようにする

とりあえず動くbotを書いてみたい、と思う方は１だけ試してみてで十分ですが、botをみんなにシェアしたい方は２も読んでみてください。

ソースコードと実際のボットのインストールボタンは両方GitHubにあります。では始めましょう！

1 プライベートなスラッシュコマンドボットの作成

ここで作るのは、Slackの公式な用語でいうところのCustom Integrationsというもので、自分のチャットグループ専用のプライベートなbot、もしくはいわゆるAppとして発表する前にドライ・ランを行うことを指します。アカウントを持っていない方はまずサインアップしてから始めましょう。

1.1 スラッシュコマンドの設定

ログインして、my.slack.com/services/new/slash-commandsでコマンドを選びます。ここでは/httpstatusと入力しAdd Slash Command Integrationボタンをクリックして次のステップへ進みます。

Tokenなどの欄がありますが現時点では、(1) Command、 (2) URL、 (3) Method、の３つが必要になります。

(1)には、/httpstatus、(3)には、POST、そして(2)のURLは次のように設定してください。

開発中に使用するURLを取得するにはngrokを使ってみましょう。いろいろなツールがあるのですが、これは自分のローカルホストをパブリックURLとしてトンネルできるというとても便利なツールなので私のイチオシです。開発途中にデプロイすることなく、Webhookが手軽に使えます。自分のローカルホスト、たとえば http://localhost:3000/ をつかったままOAuthのテストもできるのです。（注：よく聞かれるのですが、ngrokはあくまでも開発ツールですのでプロダクションには適していません。デプロイメントに関しては最後の章を読んでください）

https://ngrok.com/から自分のマシンにngrokをインストールしたら、ターミナルで自分の使いたいポート番号（このチュートリアルでは 3000）を設定します。

$ ngrok http 3000

すると下のスクリーンショットのように、Forwardingアドレスが取得できるので、そのURL（例えばhttps://71f03962.ngrok.io/)をSlackセッティングの、上のスクリーンショットで示された(2)の欄で使います。

すべての設定が終えたらSaveボタンを押します。”Your settings have been saved!”のメッセージが画面上部に現れるのを確認してください。

1.2 Node.js を使ってレスポンスを書く

基本的にbotは、ユーザがSlackインターフェイス上でコマンドを実行した際HTTP POST（または設定次第では GET)によって指定先のURLにメッセージが届け、プログラムでその応答をユーザに返す、という作業になります。

たとえばそのユーザが/httpstatus 302というコマンドを送信した場合、指定URLに送られるデータは次のようになります。

command=/httpstatus
text=302
response_url=https://hooks.slack.com/commands/1234/5678
…

Botは、これに対する応答をユーザに返します。この場合はユーザが尋ねているステータス302の定義とこの猫を返しましょう。

ではそのコードを書いてみましょう。

まず、Express.jsとbody-parserをインストールします。

$ npm install express body-parser --save

index.jsで、expressのインスタンスを作り、先ほどngrokで設定したポート番号、3000でサーバを始動します。

'use strict';
const express = require('express');
const bodyParser = require('body-parser');
const app = express();
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

const server = app.listen(3000, () => { 
console.log('Express server listening on port %d in %s mode', server.address().port, app.settings.env);});

次はHTTP POSTルートメソッドで、コマンドを扱います。

app.post('/', (req, res) => {
 let text = req.body.text;
 // ここでbotを書きます
});

ここでtextの値を取得します。HTTP Status botの場合、/httpstatus コマンドの値、例えば”404″が textの値になります。同時に、ユーザが数字以外を入力した際にエラーメッセージを送るなどのエラーチェックもしておきましょう。

if(! /^\d+$/.test(q.text)) { // not a digit
 res.send('Error: enter a valid status code, such as 200');   
 return;
}

このエラーは、ユーザだけにプライベートに送信されるメッセージでチャットそのものには表示されません。

エラーがない場合は、コマンドに対する応答をJSONとしてレスポンスします。

let data = {
 response_type: 'in_channel', 
 text: '302: Found',
 attachments:[{
   image_url: 'https://http.cat/302.jpg'
 }]
};
res.json(data);

response_typeをin_channelとすることで応答はチャットメンバー全員に見えるように送信されます。デフォルトはその逆のephemeralで、コマンドを送ったユーザのみに表示されます。

このコマンドと応答は次のようになります。

このサンプルコードでは、応答をわかりやすくハードコードで示してありますが、実際はストリングなどは別のファイルに定義しています。下のスクリーンショットのように存在しないHTTPステータスに対してのエラーメッセージも定義しましょう。実際のコードはソースコードを参照してください。

ディスプレイはボーダー色などのカスタマイズが可能です。詳しくはSlackドキュメンテーションのBasic message formattingを参照してください。

次のステップでは、このボットを自分のチャットグループ以外に配布するために必要な認証とコードのデプロイについてです。

2. Slack Botのディストリビューション

この「Custom Integration」をインストール可能な「App」にするには、コードのデプロイをして他のチャットにもインストールできるようにせねばならないのですが、そのためにはあといつくかのステップが必要になります。

2.1 Appセットアップ

まず、自分のAppを申請し、クライアントIDやシークレットなどのクレデンシャルを取得します。https://api.slack.com/appsでCreate an Appボタンをクリックしてください。

このフォームにはいくつもの欄があり少しわかりづらいのですが、スラッシュコマンドのbotには次の3つが最低必要になります。

• Basic Information (at https://api.slack.com/apps/YOUR_APP_ID/general)
• OAuth & Permissions (at …/YOUR_APP_ID/oauth)
• Slash Commands (at …/YOUR_APP_ID/slash-commands)

2.1.1 API Keyを.envファイルに保管

ここで取得したClient ID、Client secret、Verification tokenは .env ファイルに別に保管してbotのメインのコードから切り離すことを推奨します。gitを使う場合は、このファイルを .gitignore ファイルに付け加えるのを忘れずに。

SLACK_CLIENT_ID=12345XXXXX.09876XXXXX 
SLACK_CLIENT_SECRET=535d2f9....
SLACK_VERIFICATION_TOKEN=42P829U...

2.1.2 Foremanを使う

他にも手段はありますが、Herokuにデプロイするために私はNode Foremanを使っています。Foremanを使うには、npmを使ってglobalフラッグでインストールしてください。

$ npm install -g foreman

アプリケーションの Root に .procfile を作成し、この一行を加えます。

web: node index.js

index.jsを実行するには node index.jsの代わりに次のコマンドを使います。

$ nf start

2.2 ユーザの認証

Slackは認証にはOAuthを使っています。実際には自分でOAuthを実装しなくても、Slack ボタンを使えば簡単に認証できるようになっています。

公式のドキュメンテーションのダイアグラムに手を加えて、流れをわかりやすくするためにGIFアニメーションにしてみました。

ここでの実際のフローは次のようになります。

1. ウェブページを作成し、認証ボタンを置く。ユーザがボタンをクリックするとパラメータがSlackに送信される(ユーザは認証ページにリダイレクトされる)。
2. Node appには、SlackからGETで10分だけ有効な仮のコードが送られる。
3. アクセストークンを得るために oauth.access API使い認証コードをPOSTする。Node app側から`200 OK`を受け取り次第、このプロセスが完了。
4. オプションとして、このトークンを使ってSlackの他のAPIにもアクセス。例えば、認証後、ユーザをhttps://team-name.slack.comにリダイレクトするなど。/

2.2.1 Slack ボタンの設定

Slackボタンを使うには、まずウェブページを作成してください。私の場合はこのNode Appとは切り離した別のHTMLページを作成し、GitHub Pagesにホストしました。

次にボタンを設定しましょう。 https://api.slack.com/docs/slack-button に行き、Add the Slack button までスクロールして下さい。

このボタン作成ツールのCommendsのチェックボックスをチェックします。

上で示したフローの４を実行したい場合は、このGETパラメータを下のように変更します。

<a href="https://slack.com/oauth/authorize?scope=commands+team%3Aread&client_id=your_client_id">

ここでscopeに着目してみてください。commandsの他にteam:read(コロンは%3Aとエスケープ)が必要になります。詳しくはOAuth scopes on the Slack API docsで。

2.2.2 トークンの発行

さて、Nodeコードに戻りましょう。仮のコード(req.query.code)をGETで取得するためにまたExpress.jsを使います。

何でもよいのですがここでは/slack routeを使いましょう。この場合ngrokのURL は http://71f03962.ngrok.io/slack のようになります。Slack App設定ページ（https://api.slack.com/apps/YOUR_APP_ID/oauth）の、OAuth & Permissions セクションにある、Redirect URLの欄にはこのURLを設定してください。

仮のcodeを取得されたら、それを自分のAPIクレデンシャルとともにPOSTで送って、トークンと交換します。POSTするためにここではNode.jsのHTTPリクエストクライアントである、Requestを使いましょう。

$ npm install request --save

仮のcodeを取得し、それをtokenと交換するコードが下になります。

const request = require('request');

app.get('/slack', function(req, res){
 let data = {form: {
   client_id: process.env.SLACK_CLIENT_ID,
   client_secret: process.env.SLACK_CLIENT_SECRET,
   code: req.query.code
 }};

 request.post('https://slack.com/api/oauth.access', data, function (error, response, body) {
   if (!error && response.statusCode == 200) {
     // おしまい！
     // ここからはオプションでチーム情報を取得
     let token = JSON.parse(body).access_token; // Auth token
   } ...

2.2.3 オプショナル： ユーザをチームURLにダイレクトする

認証が済んだらそこで終えてもよいのですが、この画面でユーザを置き去りにするのはあまりよいUXとはいえないので、チームページにリダイレクトしてみましょう。

リダイレクトURLのサブドメインとなるチーム名はteam.infoAPIで取得できます。

このAPIを使うにはトークンが必要なので前述のコードでの、トークンにアクセスする箇所に下のコードを追加します。

...
request.post('https://slack.com/api/team.info', {form: {token: token}}, function (error, response, body) {
 if (!error && response.statusCode == 200) {
   let team = JSON.parse(body).team.domain;
   res.redirect('http://' +team+ '.slack.com');
 }
});

これで API からチーム名(team.domain)が返されました。最終的にこれを使ってチームURLにリダイレクトしてできあがり！

このチュートリアルでは簡素化したコードを使いましたが、全ソースコードはGitHubで見てみてください。

2.3 サーバにデプロイする

最後にデプロイしておしまいです。APIクレデンシャルのenv vars設定を忘れないように！私はHerokuを使っているのですが、Herokuの場合、heroku configコマンドを使います。例えば、heroku config:set API_KEY=123456というふうに設定してください。

Slackの設定で画面で指定したngrok URLを、デプロイ先のURLに変更するのもお忘れなく。

さて、プロセスが少し面倒ですが、コード自体は簡単だったと思います。もし何か面白いボットを作った際にはぜひ教えてくださいね！

そこで今回編集部では、スペシャリストにアドバイスを受けながら、データ分析を自動化したり、執筆陣ともっと気軽に議論できる編集プロセスの「自動化＆見える化」にチャレンジしてみました。

「日本にもっとエキスパートを」の指標をつくる

今回編集部が指導を仰いだのは、NTTレゾナントのUX戦略チームで「goo」全体のSEOなどを担当する大谷祥さん。また、全社横断のマーケティング室という組織でアクセス解析やABテストツールを利用したデータ主導によるサイト改善に対する取り組みも行っています。

まずは、HTML5 Experts.jp（以下、HX)が目指す「日本にもっとエキスパートを」というビジネスゴールが、どういう状態になれば達成されたと見なすのか、その成果を測る指標を定めるところから開始しました。

大谷：「日本にもっとエキスパートを」がビジネスゴールといっても、これが指標だと示すのはすごく難しいと思うんです。どうなった状態が、エキスパートが増えたと言えるのか、まずは皆さんの意見をお聞きしたいんですよ。

　▲NTTレゾナント株式会社 UX戦略チーム 大谷祥さん

白石：そうですね。HXは、高い技術力を持ち、専門技術の啓蒙活動を行っている知名度の高いエキスパートや、技術コミュニティや自らの専門技術の知識を世に発信したがっているコントリビューターの方たちを、数多く執筆陣に迎えています。

HXを読むことで専門知識や技術力を高めてもらい、次はその人がいいアウトプットをたくさんしてエキスパートになる。そうした広い意味でのエキスパートの人が増えて、どんどんいい情報や知識が循環されていくことも目標の一つです。技術コミュニティの考え方に近いんですが、それをメディアという場で活性化させたいんですよね。

仲：記事のPVやUU数を増やすことはもちろんですが、有益な情報を発信してくれるエキスパートの執筆陣も増やしていきたいです。コントリビューターがエキスパートになったり、記事を読んでくれた読者がエキスパートになってくれたら素敵ですね。

　▲左から大谷さん、HTML5 Experts.jp編集部 桂 健太さん、仲 裕介さん

白石：ただ、ここでエキスパートって言っているのは、僕らの定義してるHXのエキスパート（エキスパート一覧ページに掲載されている方々）と、一般的な意味（「専門家」という意味）でのエキスパートを増やすっていう、どっちの意味もあると思ってて。広い意味でのエキスパートが増えて、HXというメディアという場で、何か書いていただいたり交流する機会みたいなのを作っていければと。

大谷：技術コミュニティの考え方に近いかんじですね。

白石：HXは、もともとそんなに閉じたコミュニティにするつもりはなかったんです。僕はhtml5jというコミュニティを立ち上げて、管理人をやっていたことがあるんです。それは誰でも入れる『Everyone is welcome！』というかんじで運営していました。でも一方で、入るのにはハードルがあるコミュニティも作ってみたかった。卓越した技術や知識を持つエキスパートだけが入れるような。そのコミュニティというのは、今、メーリングリストで運営されています。でも、メーリングリストって、情報が一方通行なんですよね。HXもメーリングリストでエキスパートたちとやりとりしていますが、それをやめて、Slackに移行したいなと。

企画のアイデア出しはもちろん、執筆の依頼や原稿の催促なども、メールでがっつりやるよりも、Slackとかでbotを作って締め切りを伝えてくれるようなことが、気軽にできたらいいなとか。さらに妄想すると、PV報告botみたいなの作ってみたい。そういう気軽に意見を言い合ったり、お互いに編集し合えるスタイルにしたいですね。

　　▲HTML5 Experts.jp編集長　白石俊平さん

仲：そこを面白がってくれた人がエキスパートになってたくさん記事を書いて、それを見た人が自分も書きたいと言ってくれたら嬉しいですね。

白石：そうですね。あと、エキスパートのサイト登録をしてると毎回思うんですけど、すっごく面倒なんですよ。Googleのスプレッドシートに書いてもらったプロフィールを、僕らが手作業でWordPressに転記しなきゃならない。しかもね、そのやり方が煩雑なので、いつも忘れて、前の人がどんなメールの文面を送ってたか参照して…。ソーシャルログインとか、パスワードをこっちから発行して、これでログインしてってかんじでできるといいんですけどね。

仲：それ、ありですね。

白石：メンバー用のSlackにも登録されて、WordPressにも自動的に登録されたらいいなと。エキスパートやコントリビューターをどんどん増やすなら、こういう作業はどんどん自動化したいですね。

桂：いいですね、URLとか何かアクセススキームみたいなものを相手に送ったら、勝手に登録が簡単にできるようになるといいですね。そうなると、パスワードみたいなものを発行しなきゃですね。

仲：プロフィールページもエキスパートが自分で登録できるようにしましょう。そのほかにも対応できそうなのはこの機会に全部自動化しちゃいましょう。

大谷：ところで、読者のベネフィットはどうでしょう？どのようなバリューを届けたいのか、読者の位置づけって、どう考えていますか。

白石：ほかのメディアとあまり変わらないとは思いますけど、こちらとしては、いい記事を届けているつもりなので、読者にとってのメリットは、やはりいい記事を読めることですね。

大谷：なるほど。読者のほうからコミュニティに入っていくという流れも、あると思いますけど、その辺はいかがですか。

白石：いや、作りたいですね。昔はライター募集みたいなのをやろうとしたんですけど、今はやれてないんです。なので、こっちがスカウトしてくる、みたいな。

大谷：読者と執筆者（エキスパート）のバリューが、どうやったら、マッチングできるのかというところを考えてあげるのが、編集部の役割かもしれませんね。そのマッチングするポイントというのを、見える化することで、エキスパートも、読者も、より改善できていくサイクルになるのが、一番よい気がします。

仲：エキスパートと読者の交流イベントや、コメント欄の設置もやってたことはあるんですけどね。途中でやめちゃったので、また何かのかたちで復活させてもいいかもしれません。

白石：僕はコミュニティ活動を結構していたので、コミュニティの価値って何なんだろうみたいなことを考えたり、いろんなところで話したりするんです。そのうちの一つにですね、暗黙知を形式知化するってことがあると思うんです。それを蓄積する、集積するみたいなかんじで、イベントや勉強会でプレゼン資料が作られる。それが、その道に詳しい人たちが持っている暗黙知が、そこで形式知化される。

そういう機能をコミュニティが持っていて、例えば、Q&Aがすごい盛り上がってたりすると相互にコミュニケーションが発生する。そこで知識が出てくることで、インターネット上に形式知化されていくみたいな。もしかしたら同じように、エキスパートとかが持っている暗黙知を形式知化をすることができるんじゃないか、というのをHXの価値として考えています。

既にエキスパートの人はある程度知名度がある人が多くて、いまさらHXに書かなくても、既に知名度がある。HXに書く意義としては、編集者がついて企画の壁打ちや締め切りをつついてくれる、原稿チェックもしてくれる、で、そこにお金みたいなね、金銭的動機みたいなのを交えて、さらに、なめらかにそれが形式知化されるのを助ける気になる、それも、あるといいのかな、かもしれない。

大谷：なるほど。いまの白石さんのお話を絵にしてみました。

　　▲HTML5 Experts.jp企画会議メモより　by大谷さん

HXのメディアとしてのバリューは以下の3つにまとまると思います。

1. 編集部として、エキスパートから知識を形式知化して引き出す
2. HXを通じたコミュニティを形成し、エキスパートを増やす
3. 上記を繰り返すことで、さらに新しい情報を読者に届け続ける

これらのバリューを最大化させるためには、目指す指標が必要です。その指標をどこに置くか探るために、Analyticsを使ったHXの現状レポートがいくつか作ってきたので、それを見ながら探っていきましょうか。

バリューを最大化するための指標設定をどうする？

大谷：まずは、月別のページビュー数、セッション、ユニークユーザー数などの基本情報から。月別に比較してみると、2013年の7月が一番数字が高く、2014年に一度跳ね上がり、2015年くらいにもう一段階上がってからは、ほぼ横ばいという状況が続いています。

次に時間別に見てみると、日中の時間帯が多く見られていることがわかります。

仲：HXでは、通常午前9時に記事を公開しているから、ちょうど会社に出勤したあたりから、仕事しながら記事を見てもらっているようですね。公開時間は朝・昼・夜のいずれがいいのか悩むことが多いです。

大谷：こうしたボリュームゾーンを見る限り、9時公開は間違っていないと思いますよ。

大谷：曜日別では火曜がもっとも多く、次いで水曜、金曜と続きます。記事の公開が少ない土日が低いのは当たり前として、月曜が低いのは休み明けの影響からかもしれませんね。もちろんこれらのアクセスデータは、メディアの性質やターゲット特性によっても変わってきます。アクセス経路などのデータも検証してみると、8割近いユーザーがPC（desktop）経由です。

桂：スマートフォンやタブレット（mobile・tablet）経由が約2割と少ないですね、その要因も考えていかなくてはならないと感じました。

大谷：次にお見せしたいのは、分析の対象を条件で絞り込めるアドバンスドセグメントと必要な情報だけをチェックすることができるカスタムレポート。記事ページだけではなく、記事毎に付与しているタグや、特集や連載などのシリーズなどからもアクセス数をチェックできるので、効果の検証も効率が上がります。

セグメント条件

• ユーザーセグメント：１回しかこないユーザー
• ユーザーセグメント：月に２回
• ユーザーセグメント：週に２回

▲「行動」から「セッション」と「セッションの間隔（日数）」を設定。月2回は「セッション 2」と「セッションの間隔（日数） 30」、週2回は「セッション 2」と「セッションの間隔（日数） 6」というように設定する。

カスタム レポートの内容

• 流入数
• タグページ
• シリーズページ
• 記事ページ
• 基本情報

大谷：実際に流入経路を見てみると、検索流入の割合が非常に多く、FacebookとTwitterからの流入と、はてなブックマーク（はてブ）からの流入が続きます。技術系のメディアにしてはソーシャルメディアからの流入が少ないのは気になりますね。ソーシャルからの流入が多いほうが記事が話題になるのでそちらも注力すべきですが、検索からの流入が多いということは、白石さんが言う『知識を文章化して残す』という点ではまさにそれができているとも言えます。

そのほかにも、タグのページカテゴリの流入の方や、著者別のページやトップページへの回遊が一般のメディアに比べて少ないです。たしかに一回の訪問で複数記事が読まれないメディアも多いのですが、エキスパートたちが書く技術系のメディアなので、もっと多くてもいいかなという気がします。

あと気になったのは、人気があった記事の滞在時間は長いけど、下位にいくほど短くなる。こうしたユーザーの行動が見えてきたら、いろいろと打つ手が見えるくるはずです。カスタムレポートからユーザーの傾向や記事の貢献度などを著者に伝えることで、より高い価値創造・提供が実現していくのではないでしょうか。

自動化・見える化を、さらに仕組み化する

大谷：メディアとしての傾向がつかめてきたら、次は指標化です。目標値の設定と記事別に期間を定めて、その貢献度を指数化・スコア化していきます。この際に重要なのが、冒頭でディスカッションしたHXのビジネスゴールを正確に測ることのできる指標になっているということ。

そのため、PV数などの数値の高さだけが価値になるとは限りません。例えば、高度な専門技術の場合、どうしても幅広いユーザーを集めることは難しい。その場合は、記事の滞在時間やソーシャルで展開された記事の感想などが指標となってきます。普通は公開後1週間の数字をウォッチするケースが多いですが、レポートを見てみると1カ月とか1年という期間で見られている記事も存在する。サイト全体PVを支えるロングテールとなっていて興味深いですね。

ロングテール事例(1)

▲2015年3月4日公開の「今話題のReact.jsはどのようなWebアプリケーションに適しているか？」

ロングテール事例(2)

▲2013年8月20日公開の「Bootstrap3超速レビュー！刷新されたグリッドシステムを理解しよう！」

HXの場合、まずは指標化しやすい「記事を読む」部分のバリューを評価するための指標を決め、それが機能し始めたら「記事を書く」という指標につなげていましょう。HXならではの技術キーワードのタグや、特集・連載などシリーズ企画に対する記事の貢献度をスコア化して短期・長期で検証した数字を見える化すると、編集企画会議をする時にも必ず役立つと思います。

こうしたサイトでの傾向と著者に求める価値（記事のクオリティなのか、専門性なのか、ソーシャルでの影響度なのかなど）がはっきりすれば、依頼内容も明確になってくるし、記事のスコアリングも伝えやすくなりますよ。

さらに、記事単体の指標化や自動取得だけにとどまらず、メディアで技術コミュニティを実現するという目標に対してKGI（目的を達成できたかどうかを計測する指標）を設定するところまでつなげてほしいです。

グロースハックの話になるんですが、指標化された定常的なデータをもとに、メディアの成長を見える化させてモデルを作るということですね。改善を繰り返していく仕組み化が必要になってきます。どうやって、エキスパートが増えるモデルを作るのか、ここを次のステップとしてやらなきゃいけないところ。編集部のビジョンが重要になります。

▲GrowthHackとは数値やユーザーの声を分析し、ユーザーの数や質をGrowthさせる仕組みをプロダクトの中に組み込むこと

ビジョンを達成するためのゴール設定が決まると、PV数やシェア数を伸ばすとか1年後も検索流入があるといった流入改善や、読了率や回遊率を上げるにはどうすればいいかを考えるようになるし、記事のテーマや書き方をどうするかなどにつながってくると思います。あともう一つ大事なことは、ユーザーである読者のロイヤリティをどう指標化するかですね。読了率はもちろんですが、再来訪してくれかも大事な指標です。

▲ユーザーの行動モデルをもとに5つのステップに分けたフレームワーク「AARRR」

大谷さんの指摘からアドバンスドセグメントの機能を使ってマンスリーアクティブ率、ウィークリーアクティブ率などで見てみると、一回しか訪れてくれないユーザーが95％と、極端に少ない…。エキスパートを増やす＝継続して技術情報にアクセスしてくれる読者を増やすという視点でいうと、アクティブユーザーが少ないのは、編集部側の課題として大きな指標となります。

また、技術専門サイトならではの著者や技術タグをよりクローズアップさせるなど、サイト改善の必要性などについても指摘をいただきました。

さらに議論を重ね、指標化の方針が決まったところで、いよいよ自動化や見えるかを実装していきます。まず、Google AnalyticsのCore Reporting APIを使って数値を自動的に取得し、スプレッドシートのAPIを使って自動的にレポートを作成する実装を行います。

さらにエキスパートとのコミュニケーションツールをSlackに移行し、執筆陣のモチベーションアップや次回の企画へつながる体制をバージョンアップしていきます。個人的には技術用語などの自動校正ツールとかほしいです。

これらのシステム化の詳細についてのレポートは白石さんにバトンタッチするので、ぜひ再来訪してくださいね！

こんにちは、編集長の白石です。

2015年5月20日、第57回 HTML5とか勉強会「UI/UX」に参加してきました！簡単で恐縮ですが、レポートとまとめをお届けします。

チームでつくるUIデザイン

最初のセッションは、Goodpatch社の小島芳樹さん、ひらいさだあきさんによる「チームでつくるUIデザイン」です。

彼らが日々の業務で実践している、UIデザインやプロトタイピングについてのTipsが紹介されました。

チームでつくるUIデザイン

マシュマロ・チャレンジで理解する、プロトタイピングの重要性

まずはマシュマロ・チャレンジというワークショップについて、TEDで動画が公開されているプレゼンテーションを引き合いに出しつつ、プロトタイピングの重要性を強調。マシュマロ・チャレンジとは、スパゲッティの乾麺をテープで組み合わせて上にマシュマロを置き高さを競う、という（ただそれだけの）チーム作業ですが、意外にも難しい。ここで興味深いのは、幼稚園児のチームが意外にも好成績を収めるとのこと。

なぜなら大人たちは、計画を立ててから最後にマシュマロを置こうとしがちなのにたいして、幼稚園児たちはいきなりマシュマロを上に置きたがり、失敗を繰り返すことで、結果的に良い結果を収めるとのことです。 つまり、プロトタイピングを繰り返すことで結果的に良いものができるということですね。

カスタマージャーニーマップを4コマ漫画で！

そして、よくあるカスタマージャーニーマップですが、作るのに苦労する割に、一旦作ったらあまり見られることもないままになってしまいがち。小島さんはそれを4コマ漫画にしているとのことで、確かに顧客に与える価値がものすごくわかりやすいと感じます。

UI Flows

また、37Signalsが提唱したUI Flowsという手法を使って、（画面遷移というより）UIの遷移を表すという手法を使っているそうです。画面はいきなり作らずにまずは言葉だけで整理するのが大事。

prottの紹介

最後に、Goodpatchさんが作成されているprottを引き合いに出しつつ、プロトタイピングをまずは行ってみることの重要性を協調していました。

0から始めるUXデザイン

次は、NTTコミュニケーションズ株式会社の金智之さんによる「0から始めるUXデザイン」というセッションでした。

この講演では、UXデザインそのものではなく、「0からUXデザインの組織を作る」ことについての様々な知見、体験談を紹介されていました。

0から始めるUXデザイン

金さんはNTTコミュニケーションズという大きな（そして固い）会社で、4年間にわたりUXデザインの重要性を説き、啓蒙や組織づくりに尽力されていたとのこと。おっとそういえば、このHTML5 Experts.jpの運営母体も、NTTコミュニケーションズでしたね！:-)

もともと金さんがUXデザインに取り組んだきっかけは、自分で考えたアイデアを実際のビジネスに落としていくにあたり、悶え苦しんだことだそうです。それを救ってくれたのが以下の二冊の書籍。ただし、「ペルソナ作って、それからどうするの？」のほうは絶版のようです。

年間20ほどのプロジェクトに関わりながら、社内にデザイナーという「新しい職種」を根付かせようと奮闘。 例えば、トランクにユーザビリティテストの機材を一式詰め込んで、ゲリラ的にテストを行って現実を担当者に突きつける…なんてこともされていたそうです。すごい。

そのかいあってか、今年「鶴の一声」によりUX向上が全社的な課題となり、大きく動き出したそうです。何事も、継続していくことで開ける道があるものですね。まとめは以下。大きな会社の組織を変えていくご苦労が忍ばれます…。

カヤックHTMLファイ部のUI・UX

イベントのトリを務めたのは、面白法人カヤック HTMLファイ部リーダーの藤澤伸さんです。

「カヤックHTMLファイ部のUI・UX」と題して、（Web業界では有名な）カヤックHTMLファイ部の現状と、彼らが特に手がけることの多い「ペライチサイト」に関するUI/UXについて紹介がありました。

カヤックHTMLファイ部のUI・UX (第57回 HTML5とか勉強会 / 2015.5.19)

カヤックHTMLファイ部はもともと、HTML5のブームに乗って設立されたチームですが、時代の流れとともに、Webに限らずネイティブ技術も使用するようになっているとのこと。結局、お客様のご要望をいかにして満たすかが重要であって、HTML5はその一手段でしかないということですね。

後半は「ペライチサイトのUI・UX」。UXというと、スマホアプリやWebサービスの文脈で語られることが多いですが、カヤックHTMLファイ部はランディングページ（ペライチ）を手がけることも多い。そういうページにおけるUI/UXでは、「どうやってボタンを押させるか」「どうやって印象に残すか」「どうやってシェアさせるか」など、「一度しか来ないユーザーを、どうやって捕まえるか」が重要です。

例えば「どうやってボタンを押させるか」という課題においては、とにかく目立つ「押したくなるボタン」を配置する。

「どうやって印象に残すか」という課題については、ユーザの滞在時間を伸ばすのが重要で、触って気持ちのよいインタラクションを各所に配置するのが重要。

このスライドで紹介されているページはもうアクセスできないそうですが、ソーシャルボタンや「トップに戻る」ボタンなど、様々なものがインタラクティブに動作するのが印象的でした。

「どうやってシェアさせるか」においては、話題になる体験を作ることが重要。こちらのスライドで紹介されている「NARUTO展」のページは、画面最下部の「トップへ戻る」ボタンを押すと、すごいことがおきます。

「ペライチサイトのUI/UXを考える」というトピックは、今まで深く考えたことがなかった点で、とても面白かったです。

プロトタイピング、組織づくり、ペライチサイトというバリエーション豊かな視点からUI/UXを考えるという、とてもおもしろい体験でした。今回登壇された方々に共通していたのは、なんだか「ぶっちゃけ」感が強かったこと。「それ言って大丈夫？」みたいな発言もちらほら…だからこそ面白かったのですが、レポートやスライドではお伝えしきれないのが残念。

ライブの雰囲気を少しでも味わいたい方は、こちらの動画からどうぞ！

ほか、雀巽さんのブログはとても詳しく、よくまとまっていらっしゃってオススメです。 第57回HTML5とか勉強会 －UI/UX特集－ に参加しました！

ひろみつさんのグラフィックレコーディング結果も載せときますね。

今日がんばって手持ちのノートとペンでなんちゃってグラレコをしてみたんだけど、筋肉なさすぎて難しかった…!!! #html5j

@hiromitsuuuuuが投稿した写真 – 2015 5月 19 9:18午前 PDT

この1～2年、Webサービスやスマートフォンアプリの開発現場では、早い段階から評価・検証により課題を洗い出し、制作の効率化を図るプロトタイピングがさまざまな手法・ツールによって試されている。

「UI Crunch」第3回となる今回のテーマは、「今、プロトタイピング開発に求められること」。講座は、元山和之氏（クックパッド）、吉竹遼氏（Standard Inc.）、村越悟氏（グリー）、土屋尚史氏（Goodpatch CEO）デザイナー各氏によるスピーチ、および坪田朋氏（DeNA）を加えたパネルディスカッションを通じて考え、深めていくという構成で行われた。

チーム開発におけるKeynoteを使ったプロトタイピング

最初のセッションは、クックパッドのデザイナー元山和之氏による「チーム開発におけるKeynoteを使ったプロトタイピング」。Keynoteをサービス開発・改善のプロトタイピング・ツールとして活用して得られた、メリット、デメリットを含めた知見について語った。

プロトタイピングの目的は「時間とコストを削減する」「ユーザーを理解する」ところにあるが、さらに言えば、その利点は、「思考」「共有」「検証」の3点だという。

• 試作品としてアウトプットすることを通し、客観視し「思考」を深められる
• それをメンバーとコミュニケーションし、「共有」できる
• さらに最も重要な点として、「検証」することができる

実際のkeynoteを使ったプロトタイピングにおける大きなメリットは以下の3点。

1. 誰でも使えるツールであること
例えば、デザインは簡単なスケッチ（ペーパープロトタイピング）から入ることが多いが、Photoshop、Illustrator、Sketchなどのグラフィックツールは、エンジニアにはちょっと使いづらい存在。しかしKeynoteであれば、比較的誰でも扱うことができる。また、グラフィックに関し高性能過ぎない分、余計な作り込みに力を割いてしまわないという副次的な効果もある。

2.より円滑にイメージを伝えられること
プロトタイピングはメンバーとコミュニケーションをとる手段でもあり、ただの絵や言葉だけでは伝わりにくい部分も、アニメーション、トランジションを使うことで、より明確に伝えることができる。

3.検証のためのインタラクティブな動作
ボタンをタップした時のクリッカブルな動きなど、インタラクションを表現したいこともある。Keynoteはもともと、こうしたものを作るツールではないが、実は表現可能。

動作まで含めたデザインのプロトタイプを、専門家以外でも簡単に作成できるのがKeynoteの利点。しかしその一方で、「実際に使ってみて、これは無理だなと思う欠点もある」と本山氏は語る。

• 画面遷移やインタラクションを複雑に作りこむのは無理
• デバイスなど、手元で確認するのに向いているとは言えない

「すべてをKeynoteでやるのは無理があるが、逆にそこまでやる必要はない」という元山氏。クックパッドではGoodpatchが開発したプロトタイピングツール「Prott」を使っており、keynoteと組み合わせて使うと効果的なのだそうだ。

プロトタイピングの助走と飛躍

続いては、スマートフォンアプリやWebサイトのUIデザインに特化したプロダクションとして活動する、Standard Inc.のデザイナー吉竹遼氏。「プロトタイプはツールだけでは終わらないし、できるものではない」と語り出した。

「プロトタイピング」という言葉をあまり限定的に考えず、「試行錯誤」と捉える。その場合、「試行」がいわゆるプロトタイプ、トライ＆エラーを繰り返す錯誤の部分まで含めてプロトタイピングと言えるのではないかという。その「プロトタイピング＝試行錯誤」を、吉竹氏は「あくまで自分の経験に基づいたもので、個々の現場により、差は出てくるかも」としつつ、このように図解する。

「試行錯誤」といっても多くのフェイズがあり、さまざまなことを考えて要るのだが、ここでのポイントは「勇気を持って試行錯誤しよう」ということ。大事なのは、以下に挙げる3点であり、試行錯誤とは勇気を伴う行動なのである。

• 早い段階で周りと共有する
• 捨てる勇気と変えない勇気
• 言いなりになれというわけではない

ここまでをプロトタイピングの「助走」と考え、では、今後どのように「飛躍」していけばよいのか。
吉川氏はWebデザイナーやUIデザイナーがデザインしているのは「体験・物語」であり、Webやアプリケーションは、あくまで体験や物語を伝えるためのインタフェースの一つだという。

そうした中で、｢プロトタイピング」が広範囲に及んだ際に、基点となりえる考え方を「一つは、さまざまなフェイズの広範囲にわたってきちんと考えること。もう一つは『人に寄り添う体験や物語を届けるために、人への興味を持ち続けること』が大事」と語り、これからの時代を考えるデザイナーや、プロトタイピングという考え方に欠かせない以下の要点を挙げて、セッションを締めくくった。

• 試行錯誤し続けよう
• 勇気を持ち続けよう
• 人間への興味を失わずにい続けよう

プロトタイピングにおける「段階」

次のセッションは、グリーのJapanGame事業本部Art部UXデザインチームマネージャー・村越悟氏。2014年までユーザーテストの仕組み化・ツール化に携わり、今年2015年の自らのキーワードとして選んだのが「プロトタイピング」。現在社内で進めている取り組みをベースに、「プロトタイピングにあるさまざまな手法を、どのような段階を踏んで行っていけばよいのか」を語った。

村越氏は以下のスライドを示し、イメージ、コンテキスト、コミュニケーションの真ん中にあるのがプロトタイピングなのではと語る。また、プロジェクト進行、管理に携わってきた経験が長く、特にその視点から捉えたものとして、チームビルディング（組織進化）モデル「タックマンモデル」をベースに、プロトタイピングの「段階」へと話を進めた。

さらに、最後の散会を除く各段階で生じる関係者間の「ズレ」、およびその現場で起こりえる例と対策はこのようになるという。

1.イメージのズレを埋める
「スッと指でなぞるだけ！」という表現だけでは、人によってイメージされるものが違ってくる。もちろん認識の齟齬がプロジェクトが進行してから発覚するようではダメで、それを埋めるためにペーパープロトタイピングを使い、それぞれ簡単にスケッチしてもらい、それを比較する。

2.要件・認識のズレを埋める
プロジェクトがある程度進んできた段階で起きる要件・認識のズレは、「Prott」「Sketch」の2ツールを併用。「全員が中間成果物を共有」「デザインコンテキストを共有」する。

3.全体品質への意識のズレを埋める
プロジェクトが後半にさしかかってきたところで生まれる全体品質への意識のズレは、「Unity」などで実装プロトタイプを作成。Unity上でかなりインタラクティブなプロトタイプを作り、パラメータやレベルデザインを調整していく。

これらによって、ユーザにとって、作り手にとって最善であること、最適な「体験」がユーザに提供できているか、価値基準――ゲームであれば難易度の設定や、きちんとプロダクトとしての成長曲線をたどっているか、最終的な製品としての品質を達成しているかなどの判断をチームで共有することができる。

主に使用するツールを、各段階にあてはめて整理すると、このようになる。

コンテキストの共有から文化は生まれ、文化の中から良いプロダクトは生まれてくる。つまり、プロトタイピングはイメージを会話するための「言語」でもある――と締めくくった。

Prott Story – Prottができるまで

最後はGoodpatch CEOの土屋尚史氏による「Prott Story – Prottができるまで」。「Prott」はGoodpatchが提供するプロトタイピングツールで、2014年10月に正式ローンチされて以来、世界中のユーザーに使われ、エンタープライズ利用としても、さまざまな企業で導入が進んでいる。2月18日には「Prott」PC Web版がリリースされ、プレスリリースサイトのPR timesで閲覧数トップに立ったのだとか。その注目の高さが伺われる。

2013年春にUIデザインを担当したGunosyのヒットを受け、GoodpatchはiOSの案件は次々に舞い込むという状況だったという。社内のリソースだけでは足りず、パートナー会社のiOSエンジニアと仕事を進めていくことになったのだが、ここで問題が発生。パートナーのiOSエンジニアとのコミュニケーションである。

まずはディレクターが仕様書を作り、デザイナーが静的なデザインを作り、エンジニアに渡す。しかし、それでは動きの部分はうまく伝わらない。その結果として手戻りが多い。さらに実装してみたら、何か違う……。そんなもどかしい事態が頻発したのだ。ちょうどその頃、「Flinto」というプロトタイピングツールがβローンチ。Goodpatchはこれを使い始め、デザインプロセスは一気に変わったそうだ。

利点を整理すると次のようになる。

• 設計段階から、動かしながら考えることができる
• デザイナーが動きや遷移、ストーリーを想像しやすくなった
• クライアントや開発エンジニアとのコミュニケーションが劇的に改善

しかしその一方、「Flinto」を使い込んで行く中で、若干の不満も出てきたのだという。

• チームでプロジェクト共有がしづらい
• フィードバックがプロトタイプ上で返せない
• さらに言えば、ワイヤーもツールで書けるのが望ましい

そこであらゆるプロトタイピングツールを調べてみたのだが、結局行き着いたのは、「自分たちで理想的なプロトタイピングツールを作る」こと。だが、「Prott」ができるまでには、数々の事件があった。

• 【事件簿その1】プロジェクトはスタートしたのに、エンジニアがいない！
• 【事件簿その2】実はデザイナーが乗り気じゃなかった！
• 【事件簿その3】競合ツールでプロトタイピング！
• 【事件簿その4】イケてると思ったUIが、実装してみたら全然使いづらい！
• 【事件簿その5】ろくなキャラクターが上がってこない！
• 【事件簿その6】バグが多すぎる！
• 【事件簿その7】iOSアプリなかなかでき上がらない！
• 【事件簿その8】ランディングのデザインをパクられた！

こうした数々の試練の中、ユーザーインタビューと改善を繰り返し、2014年10月に正式ローンチ。登録ユーザー数は約1万7000人。世界38カ国、1658都市で利用されている。

ユーザーに求められるプロダクトを作るには、コミュニケーションが活発なチームが必要であり、そのためにも、プロトタイピングは非常に重要なプロセスとなる。日本のデザインプロセスにプロトタイピングを浸透させ、素晴らしいプロダクトをより多く生み出せる土壌を作る。それが自分たちの使命であり、さらには、「Prott」を日本発のサービスとして世界で使われるようにしたい――と、土屋氏は今後の抱負を語った。

現場でどのようにプロトタイピングを回してる？

2部のパネルディスカッションは、DeNA坪田氏による司会進行で進められた。

坪田：まずは、現場でどのようにプロトタイピングを回しているのか、エンジニアやプロダクトマネージャーの理解はどうなっているのかについて、聞かせてください。

村越：グリーのゲーム開発現場では、割とプロトタイピングを実施していると思います。ただ、Unityでグリグリと操作できる状態でのプロトタイピングが多かったりします。やりすぎると最初から具体的になりすぎるので、デザイナー主体の場合はペーパープロトを使ったり、Sketch上でワイヤーフレームを切るほうにシフトするようにしています。Prottを使ったプロジェクト数も増えてきていて、いろんな人が使っている感じになってきました。

元山：今日はKeynoteの話をしましたが、吉竹さんの「試行錯誤がプロトタイピングの役割」というところは僕も同感です。クックパッドでは、グラフィックの前の部分やコンセプトを考える部分で、アプリケーション定義ステートメントシートといったものを最初に書いて、メンバー間でのすり合わせを行い、実際のビジュアルに起こしていきます。Sketchするなり、Prottに落とし込んでいったり、というところですね。

吉竹：前職での話になりますが、僕は個人的にプロジェクトに使っていました。「簡単に確認ができるので、実装に入る前に早めにこれで確認しましょう」と提示することが多かったですね。特殊な例としては、営業が会社の売り込みツールとしての活用。案件を取る前にBriefsでプロトタイプを作り、営業に持たせて提示してもらうと、客先で結構喜ばれたりしました。

坪田：それ、めっちゃいいですね。受注する前に、ある程度動いたり触れたりするものを作って営業していたということですか？

吉竹：そうです。前職では、いきなりフルでデザインして持っていく慣例があったので、「だったら、動かせるものを見せたほうがいいんじゃない？」という感じでした。

土屋：ウチはもう、プロトタイピングは文化になっています。普通にプロジェクトを進める場合、例えば、答えの出ない議論にはまってしまう時ってあるじゃないですか。そんな時は「じゃあ、まず動かすものを作ろうぜ」ということになる。

昔はそれで煮詰まってしまって長期間滞ってしまったものが、すごく話が進めやすくなるんですよね。そこで声の大きい人間の意見が優先されるとかではなく、きちんとパターンを作って、ユーザーに触ってもらって比較検討ができる。そうしたプロトタイピングの姿勢が一つの案件ではなく、「まずトライしよう」という会社の文化として定着したと思っています。

坪田：確かに開発スタイルの文化を変えた、というのは大きいと思います。

使えるプロトタイピングツールは何？

――ここで会場に集まった人たちに、坪田氏が「現在プロトタイピングの手法を導入しているか」を確認すると、およそ3割という結果に。

坪田：これは多いのか、少ないのか……。ちなみにDeNAでProttを使って開発しているデザイナーの数は、アカウントベースで20～30くらいでしょうか。導入前後で比較すると、コミュニケーションが非常によくなっています。コミュニケーションツールとしても有用だし、スクラップ＆ビルドする分、いいものができる。会場で、まだ導入していない方も、本当に簡単に導入できるので、ぜひ使ってみてください。

坪田：ところで土屋さん、最近「Pxiate」とか、プロトタイピングツールでアニメーションまで再現できるものも登場していますね。そういう（Prottの）競合ツールに対してどう考えていますか？

土屋：出てくるのは海外が主ですが、本当に、この2年で増えましたね。吉竹君は僕と同じくらいウォッチをしていて、ブログに全部。かなりわかりやすくまとめてくれていたりしますが――だいぶ増えたよね？

吉竹：増えましたね。たぶん30から40はあるんじゃないですか。最初ブログにまとめ始めた頃は18くらいだったと思います。

土屋：海外のツールは今、詳細なアニメーションを作る方向にいっていますね。ただ、Prottはコミュニケーションツールという位置付け。作りこむところよりも、全体のストーリー設計と、それを元にコンセンサスを得るところ、そしてすぐに早く作れる、ということを重要視しています。ですから、それらは競合というより、プロトタイピングという全体の中でレイヤーが違うと捉えています。

坪田：わかります。僕、Pxiateとかも使っているんですが、めちゃくちゃアニメーションが作りやすいんですよ。ですから、アニメーションを作りこむならPxiate、早く作るならProttみたいな使い分けをしています。

吉竹：アニメーションに関しては、今名前の出たPxiateがいいのかな。ただあれは月額なんで、僕は個人でも会社でも使っていなくて、個人的には、Facebookは開発したOrigamiというライブラリを使っています。おすすめかと言われるとちょっと難しいけど、Framerとかのほうがいいかもしれません。

土屋：でもQuartzコンポーザーもOrigamiも、ほぼプログラミングなのでハードル高いよね。デザイナーだと、作れる人は限られてきちゃう。

吉竹：そうですね（笑）。僕もそこは結構使い分けをしていて、ちょっとだけ伝える、ということなら、AfterEffectsを使ったり。反復の動きを確かめたいときには、Origamiで確認したりします。

プロトタイピングの意思決定権は誰が持つべきか？

坪田：「プロトタイピングの結果に対しての意思決定権は誰が持つべきか」という質問が来ていますが、これは皆さんにお伺いしたいですね。

村越：やはり意思決定者は、プロダクトオーナーだと思うんです。プロトタイピングで思考のプロセスもちゃんと共有して一緒に議論していけば、プロダクトオーナーが「これでいこう」と言った時に、周りが「マジかよ！？」というふうにならない――それは可視化することのメリットだと思います。

坪田：意思決定はプロダクトオーナーがするにしても、プロセスで、もうある程度皆の方向性は定まっているので、最終的にひとつにまとまりやすいということですね。その後で、社長が出てきてひっくり返したりということはないんですか。

村越：ありますね（笑）。そこはまあ、もう一回組み上げていくしかない。

坪田：質問の内容が変わってしまうかもしれないんですが、元山さんにお聞きしたい。現場でプロトタイピングしながら作っているメンバーと、トップとの意思疎通が取れていなかった時に、ミスリードしていたりするとマズイ事態になってしまいますよね。そういうことって、現場で起きていませんか。

元山：クックパッドでは、開発プロセスの中に「デザインレビュー」というのを挟んでいて、それはGitHub上で行っているんです。そこで皆で共有して、後々大きくひっくり返らないようなプロセスで進むようにしています。

土屋：それは対面レビューということですか？それとも上がっているものを見て、ということでしょうか。

元山：対面の場合は少ないですね。必要があれば、当然対面でということもあります。

土屋：ちょっとずれてしまいますが、皆さんは対面レビューの重要性というのはどうお考えでしょうか。ウチの場合、なるべく対面で行うことにしているのですが。やはりどうしても、テキストだとニュアンスがうまく伝わらない部分もあると思うので。

元山：テキストのみの場合、弊害はやっぱりありますね。意図がうまく伝わっていない部分などは、どうしても出てくると思います。ただ、時間的な制約もあるので、GitHub上がメインという感じですかね。

吉竹：僕はクライアントとの間ではやりますが、チーム内で定例的にというか、頻繁にやるということはないですね。でもまあ、対面のほうが個人的には好きです。

村越：今僕がコミットしているプロジェクトでは、スプリントごとに対面で集まってレビューというのもやります。プラスして、何かあった時に、GoogleDocsで意見を集約できるようにもなっています。対面と文章、2パターン併用ですね。

坪田：僕の場合は、対面レビューする案件としない案件がありますね。本題の意思決定に関しては、プロダクトオーナーがするんですけど、意思決定よりもプロセスが大事……ところに着地しました（笑）。受託だとなおさらそうかもしれませんが、意思決定者を早めに巻き込むことは重要かもしれません。

今後プロトタイピングツールに欲しい機能は？

坪田：プロトタイピングツールなど、何らかのツールを使ってデザインしていくわけですが、その時、アニメーションの実装では、Pxiateとか、AfterEffectを使う。それが、そのままiOSやAndroidに実装できるコピペボタンがあったら欲しいですね。これは結構切実なので、今後の、アニメーションやデザイン、プロトタイピングの分野の課題かなと思っています。

土屋：プロトタイピングツールではないですが、プロジェクト管理ツールは欲しいですね。僕はプロジェクト管理ツールフェチなんですけれど、未だにしっくりくるものがない。これはやっぱり自分たちで作るしかないかなあ、と思っていたりします。

吉竹：僕も坪田さんと同じで、アニメーションをエンジニアにちゃんと渡せるのがいいですね。あとは、ユーザーテストの時に役立ってくれるようなプロトタイピングツールが欲しい。今は普通に触っているだけですが、そこからいろいろ取得できるようにすると、またプロセスが変わってくるのではと思います。

土屋：そのままユーザーテストにかけるというのは、Prottでやる予定ですよ。

吉竹：楽しみにしています。

元山：今は静止画を動かすUIやユーザビリティのプロトタイピングが主ですが、クックパッドの場合、ユーザーに向けたサービスを作っているので、そのユーザーがどう受け取っているのかが最も気になります。もっと早い段階で検証できるプロトタイピングのツールや手法が確立されていくといいですね。

村越：僕もプロジェクト管理ツールはいいものが欲しい。でも結局いろいろ試した挙句に、GoogleDocsに落ち着くとか。プロトタイピングのツールでいうと、今後Prottに実装されますが、ワイヤフレームを書く機能は待ち遠しい。ワイヤーフレーム大好き人間なので、ワイヤーフレームから直接プロトタイピングとか、打ち合わせの場でライブでできたらいいなと。そういう、リアルタイム感のあるプロトタイピングをやってみたいと思ったりします。

こうして非常に中身の濃い、約2時間の講座は終了した。イベント募集開始後30分で満席となり、ここでは紹介しきれないほど質問も寄せられ、その関心度の高さを示したプロトタイピング。日本では実際に導入している事例はまだ少ないが、Prottの登場や現場での試行錯誤を繰り返すことによって、現場が抱える課題を解決できる可能性を感じた。今後もプロトタイピングの動向には注目したい。

＜関連資料＞

• UI Crunch 03 『プロトタイピングの助走と飛躍』
• UI Crunch#3：「プロトタイピングにおける『段階』」
• Prott Story 「Prottができるまで」
• UI Crunch #3 渋谷ヒカリエから生放送！「schooアーカイブ」

IoTの時代、それはモノのデザインとWebのデザインが交錯する時代と言えます。 そんな時代に必要とされるデザイン思考とはなんでしょう？モノのデザインとWebのデザイン、そこにある違いは、そして共通するものは何でしょう？

この記事ではそんな疑問の答えを探るべく、この記事では、プロダクトデザインとWebデザインのプロフェッショナル2人を引き会わせて、デザインについて、デザイナーについて、UXについて、Webについて、IoTについて、気になることを全部語っていただきました。

プロダクトデザインとWebデザイン、その境界線から見える景色を、それぞれの分野のエキスパートが語ります。

久下玄（くげはじめ）: デザイナー／エンジニア／ストラテジスト。東京造形大学卒業。家電メーカーのプロダクトデザイナーを経て、2009年にtsug,LLC創業。事業戦略、技術開発、製品デザインまで手がける。統合型デザインで、国内外の企業のイノベーションプロジェクトに携わる。並行して2012年Coiney,inc創業に参加し、以後プロダクト開発を担う。2010~2013年まで慶応大学SFC研究所にて、研究員として通信とデザインの研究および教育に携わる。近作に脳波ヘッドフォンmico（neurowear）やスマホ決済サービスCoiney（コイニー）など。受賞多数。近著は「リアルアノニマスデザイン」（学芸出版社・2013年・共著）。

秋葉秀樹（あきばひでき）: 株式会社ツクロア（tuqulore）代表取締役／デザイナー。HTML5 Experts.jp公認エキスパートNo.16。 本業はデザイナー。DTP・グラフィックデザイン・Webフロントエンド全般・Flashゲーム開発・3DCGと幅広く携わる。主な作品は海遊館やサンシャイン水族館とコラボしたAndroid／iPhoneアプリ「Ikesu」。NFC技術を世界で初めて水族館で利用して魚をスマートフォン内に持ち帰られる体験を提供し、2ヶ月足らずで一万人が利用、人の集まる場所に私たちのデザインがどうビジネスに貢献するかをテーマに仕事をしている。近著に『Firefox OSアプリ開発ガイド』（リックテレコム）。その他、共著として『10倍ラクするIllustrator仕事術』（技術評論社）や『すべての人に知っておいてほしい HTML5+CSS3の基本原則』（MdN）など多数。2013年4月に株式会社ツクロアを設立。

聞き手: 白石俊平（しらいししゅんぺい）: HTML5 Experts.jp編集長

Webデザイナーの制約、そしてアドバンテージ

白石: まずは、簡単な自己紹介からお願いできますか？

久下: Coineyではプロダクトの統括を担当しています。Web、モバイル、ハードウェアなど様々な分野のデザイナー、エンジニアたちをまとめているという立場ですね。

久下玄さん

秋葉秀樹さん

久下: なるほど。最近は秋葉さんのように、「Webサイトを作るだけ」っていう取り組み方にフラストレーションを貯めているWebデザイナーも多そうですよね。今までWebデザイナーって、「スクリーンの中だけ」というかなりきつい制約の中だけで戦ってきてるわけじゃないですか。

秋葉: そうなんですよね。ぼくもWebデザイナーという職種からは一歩踏み出してしまったな、と感じているところです。

久下: とは言え、Webデザイナーという職種にはすごいアドバンテージもあるな、とは思います。というのは、「目の前にお客さんがいない状況で、その行動を推測する」ということに長けているわけですからね。

「もの」のデザインっていうのは、人がその「もの」を使っているところをこの眼で確かめることができる。一方Webは、お客さんがほとんど見えないんですよね。それを、推測だけでグロース（サービスを成長）させていくってことを、これまでもずっとやってきているわけじゃないですか。

もちろん今は、トラッキングツールも増えてきていますけど、根本的にはスクリーンに対する反応しか確かめられない。ユーザーの操作を追うことはできますが、そのときユーザーがどんな感情だったか、どんな表情をしているかといったところは結局わかりません。

そういうところを類推しながら作っていくというのが、Webの人たち独特のカルチャーでありスキルだな、とは思いますね。プロダクトやモノの世界には、そういうことはほとんどありませんね。利用シーンを目にするのは簡単なので、そんなことをしてたら怒られますからね。「お前、客のところいけよ」と(笑)。

秋葉: 確かにそういうところはありますね。それがアドバンテージであるというのは、言われてみるまで気づきませんでした。

デザインの根拠、目的、成果物

秋葉: ただ、「推測」に頼る度合いが大きい分、デザインに対する根拠が薄弱であるというところはあるかもしれません。デザインを何案か提出して、お客さんがその中から一つ選ぶ。でも、それを選んだ根拠は何なんだ、と(笑) 。そもそもそのデザインが正解かどうかなんて、納品の時点では絶対にわからないはずなんです。

久下: そもそも新しく何かを作るときに正解なんてわかるわけないですよね(笑)。特にWebサービスとかって「ローンチしてみないとわからない」ってのがホントのところじゃないですか？対象となるお客さんも多いし、多様だし。

秋葉: そうなんですよ。なので、最初に全てをデザインしようとするというのはなんか違うな、と思うようになって。

久下: 最初からそんなに大きなコストを払っても、リリースしてみないと当たるかどうかわからない。というか、ほぼ外れるじゃないですか(笑)。大きな賭けですよね。

久下: 僕がやっている別のデザイン会社の方でも、「納品物体がある前提」をやめてもらえるようにしたんです。目的ベースで考える。例えば、「このサービスのお客さんを増やしたい」とかそういう目的。そのために、リソースを何ヶ月使えます…という仕事のかたちにしたんですね。

なんでそういうふうにしたかというと、通常の納期ありきの仕事だと、「納期に間に合わせること」が目的になってしまうんです。「納期が残り3週間しかない、じゃあ、3週間の中でできることをやろう」というふうに、目的が変わってしまうんですよね。

秋葉: ミッションが変わってしまうんですよね。

久下: コンペとかについても同じようなことが言えます。僕が仲良くしていただいてる、尊敬するデザイナーで西澤明洋さんという方がいて、コエドビールとかのデザインを手がけられた方なんですが、彼が言うには「コンペは誰も幸せにならない」と。

なぜかと言うと、クライアントはいろんなものを見たいという目的でコンペを主催するのですが、それを受ける側は「コンペに通るため」のアイデアを出そうとしちゃうんですよね。そもそも持っている課題に対するアイデアは出てこない。

「A社はこうくるだろう、B社はこうくるかな、じゃあうちはこういこう…」ってな感じで、そもそものお客さんが関係なくなっちゃうんですよね。だから、コンペに参加するのは一切やめたと言っていました。

秋葉: 僕もコンペは参加しないことに決めてます。っていうのはですね、最後にコンペに参加した時に他のチームの人が「とりあえずプレゼンの時だけいいものを作って、実際に制作する段階で無理が判明したら言い訳すればいい」ってことを言っていて、それがショックで。僕は「コンペで印象深いものを作る」ということを目的にはしたくなかったので、やめちゃいました。

久下: でも、そういう問題って至るところにあるんですよね。自社でプロダクトを作っているCoineyでも、似たようなことはありました。十分な検討がなされずに納期だけが先に決まっちゃってて、そこまでに作らなくてはならない…みたいな状況ですね。ビジネス側からの無理な要求が開発に負荷をかけてしまうようなことが往々にしてあって、そうなるとクオリティが上がらなかったり、あとでサポートとかバグフィックスとかにコストがかかってしまったりして。

今回のインタビューはCoiney社に伺いました。

IoT時代のデザイン思考

秋葉: ただ、そういうスタイルに変えていくのは一筋縄でいかないのが、最近悩みの種でもあります。従来の一括納品というかたちではなく、デザインもエンジニアリングもお客さんと一体になって、サービスを少しずつ成長させていく。そういう関係にしていきたいのですが、どうすればそこに辿り着けるのか、と。

久下: 作る側だけじゃなく、お客さんにも学んでいただく必要があるかもしれませんね。幸い今は、そういう考え方での成功事例がたくさんありますし。デザインとエンジニアリング、プランニングといった言葉がすごく近いというか、ほぼ一緒になってきているような事例が増えてきていますよね。アップルがその典型的な成功例だと思いますが。

秋葉: そういう事例が増えていく中、「デザインそのものに対する考え方を見直そう」と考える人たちもやはりすごく多くなってきている感覚があります。仕事の進め方もそうですし、IoTの時代と言われている中で、PCやスマートフォンのスクリーンの中だけで終わらせようとすることも見直されつつある。「果たしてそれでいいのか」と考える人が増えています。

久下: 僕も、そういう意識の変化には賛成です。スクリーンの外のものも、すべて統合して考えるべきだと思います。そういう点で言うと、「UXデザイン」ってぼくはすごくいい言葉だと思うんですよね。だって、いろんなことをUXデザインって言葉で表すことが可能じゃないですか。「世の中に対して、体験そのものをどう作るか」っていうところから、全体を統合して考えようとする姿勢をよく表せる言葉だと思います。

で、体験を作るにあたっては、結局のところ「人の気持ちがわかる」っていうのが勘所になってくる。

秋葉: わかります。いろんなデザインがあるけど、必ずその先に人がいて、その人の生活や感情がある。

久下: そういう勘所が分かる人っていうのは、デザインという領域の中においても、だいたい何をやらせてもうまいんですよね。スキルの分野とは関係なく。

例えば工業デザインだったら、モノを作るために加工法や素材への精通、3DCADや量産設計等のいろんなスキルが必要になります。Webだったらフロントエンドの知識から、サーバサイドどうするかなどの知識やスキルが必要になる。ただ、そういうスキルって後からいくらでも習得可能なものじゃないですか。特に最近は、スキルを身に付けるスピードがみんなすごく早い。それはなぜかというと、スキルって当たり前ですけど人のために作られているので、ちゃんとした材料とフローさえ踏めば、だれでも割と学べちゃうんです。

それよりも、そういうスキルを使って何を作るか、どういう体験を作るかという点が重要です。みんなここを簡単だと思っているけども、実はここが一番難しい。逆にここの勘所を掴んだ人は、あとからスキルはいくらでも身につけていける。だからWebだとかモバイルアプリだとか、そういう区切り方自体もはやナンセンスで、必要に応じて学んでいけばいいものだと思っています。

秋葉: ハードウェアとソフトウェアとかで区切るのも、もはやナンセンス、ということですね。

久下: そうです。例えば、僕がすごく尊敬するインタラクションデザイナーで中村勇吾さんという方がいるんですけど、東大建築科を卒業した後に橋梁設計の仕事をやりつつ、Webもはじめた…というおもしろいキャリアをお持ちなんです。その後Flashで、2Dのビットマップ画像でアニメーションさせるのが全盛だったような時代に、アルゴリズムと無機質な描画だけで不思議な気持ちよさを出すというカルチャーを作り、それがインタラクションデザインの分野に多大な影響をもたらしました。

中村さんは、「構造」とか「気持ちよさ」っていうものに対するフェチなんだそうです。あの「気持ちよさ」って概念は、今のユーザインタフェースデザインにおける基礎の基礎だと思う。でも彼は元々Webの人でもなんでもない。気持ちよければメディアなんて何でもいいじゃん、と。まさに今の時代に求められる典型的な先輩みたいな人だと思うのですが、ああいう人が今後もっともっと増えていくんだろうなあ、と思っています。

近いところで言えば、Webの人がモバイルアプリケーション作るなんてのも、もう珍しくないじゃないですか。それくらいのスキルコンバートは今や普通だし、WebディレクターとかWebデザイナーとかWebエンジニアとか全部やってるよ、なんて人も普通にいたりする。今は電子工作がブームになっているので、これまでソフトウェアしか作ったことない人が、ハードウェアをプロトタイプレベルで作るというのも増えてきている。たぶん10年も経ったら、「肩書きを書きたくても書けない」って人がほとんどじゃないでしょうか。

秋葉: 僕も、「UIデザイナー」とか肩書きに付けたくないなあ…って気持ち、正直言うとありますね。

久下: 肩書きのせいで、勝手に狭く解釈されちゃいますよね。

Webデザイナー／エンジニアの仕事は変わる？なくなる？

秋葉: 最近ぼくも、電子工作にチャレンジしているんです。例えば最近、猫の自動餌やり機を作ってみたんです。そしたら、猫がその機械を攻撃するわけですよ。「ここから餌が出てくる」と学習しちゃって、餌欲しさに機械を壊そうとするんです。なんでそんな当たり前のことを、先に気づかなかったんだろう…って。 新しいことにチャレンジすると、「やってみなければわからない」ということだらけなのを実感しますね。

久下: チャレンジ、重要ですよね。一方でチャレンジ自体を否定する人たちもいます。何事も最初からうまくいくわけないのに、失敗を恐れてチャレンジしなかったり、人がチャレンジした成果をバカにしたりするのはカッコ悪いと思う。

今、ハードウェアスタートアップと呼ばれる企業が増えていますが、今はまともなものを作っている会社だって、昔はショボいものしか出せてなかったんです。でも、そうやってチャレンジすることで学びがあり、仲間ができ、だんだんいいものを作れるようになってくる。最初にクソプロダクト(笑)を出す、というステップを踏まないとそうはなれないわけで。

秋葉: チャレンジを否定することは、自分の可能性も閉ざしちゃうことにも繋がりますよね。

久下: だから、思い切って踏み出してみるというのは、とても大事ですよね。

僕はハードもソフトも扱うサービスをやっているおかげで、両方のカルチャーを行き来する立場なのですが、最近のIoTブームが面白い現象を引き起こしているな、と思っています。

というのは、ハードの人もソフトの人も「自分の仕事がなくなっちゃうんじゃないか」と危惧してるんですよ(笑)。ハードの人たちは「ソフトの人たちがハードを扱うようになる」、ソフトの人たちは「ハードの人たちがソフトを扱うようになる」って。

僕から見ると、Webの人たちは「情報」を扱うのがすごく得意ですが、モノを扱う人たちはそれが苦手だったりするので、お互いの得意不得意を補い合う関係になるだろうと思っています。

残念ながら、単発の技術的スキルで面白いものを作れる時代は終わってしまいました。でも僕は、「そういう時代がやっときた」という気持ちです。みんなで手を取り合って面白いものを作れるぞ、と。

プロダクトデザイナーという仕事

白石: 最後にお聞きしたいのですが「プロダクトデザイン」という仕事は、具体的にはどんなことをされているのでしょうか？

久下: 「プロダクトデザイン」という言葉は、実際にはとても広い意味を持つ言葉です。ただ一般的に言われている「プロダクトデザイン」というのは、多分「インダストリアル（工業、産業）デザイン」のことを指していると思うので、そういう前提でお話しますね。

とは言え、インダストリアルデザイナーの仕事もどんどん変わってきているんです。
90年代くらいまでは、基本的にはハードウェアエンジニアが作ったものを「スタイリングする」「お化粧する」という仕事が中心でした。そういう仕事は、依然として重要な仕事として存在してはいますけどね。

その次に、「その道具がどうあるべきか」「道具の内部構造がどうあるべきか」を考えるという時代が来て、エンジニアリングの領域もカバーするようになりました。今、大きなメーカーのデザイナーとかはこのフェーズにいると思います。


そして最近は、「そもそもデザインやエンジニアリングがどう使われるか」という統合的なストーリーを考えて、そのストーリーを実現までプロデューサーのように走らせるのが、今の若い世代のインダストリアルデザイナーの仕事です。

久下: 昔…90年代後半とかは、ストーリーを考えてスケッチを描き、モノとして成り立つかを確かめるためにモデルを作ったり…といった、「動かないもの」でデザインを説明するのが工業デザインの仕事でした。
最近はそもそも動くハードウェア – ホットモックと言ったりするのですけど – を用意して、それを組み替えたりしながら小さくしていくことで、エンジニアリングと一体になりながら「モノの形はどうあるべきか」を探っていくというやり方になっています。

中身と形を分けずに、そもそもひとつの体験としてどうあるべきかを探る。例えば素材を考えるといったところから、どうやったら理想的な形に加工できるかという「製法」を考えたり、どこで作ってもらうべきか、値段はコミットできるのか…といったところを総合的に考えながら、物質的な人とのインターフェースを考えていくのが、今の工業デザイナーの仕事なのかなと思います。

白石: 例えばCoineyでいうと、どんな仕事をされているイメージですか？

久下: まずCoineyは、定期的にモノがはけていくビジネスモデルです。カードリーダーを無料で配布するので、ユーザーが増えれば増えるほど部材を調達しなくてはなりません。
ただ、部品の調達ってかなり時間が必要で、平気で数ヶ月かかったりするんですね。だから、全体のリードタイムをきちんと見るということはやってますね。
僕らのサービスはリーダーが常に適切な量で生産されないと、顧客を獲得するという活動にも影響が出てしまう。なので、ユーザーの増加ペースに合わせて、工場の生産ラインを調整しています。

Coiney (コイニー)はモバイル決済サービス。専用リーダーをモバイルデバイスのイヤホンジャックに指すと、デバイスがカード決済端末に早変わりする

白石: 管理するという作業が主ですか？例えばCADでモデリングしたり…という作業はもう手がけられていない？

久下: いや、やってます。狭い意味でのデザインも、基本的には全部手がけていますよ。Webやモバイルのデザインについても、UXプロトタイプレベルまではぼくとデザイナーチームの方で作ります。ハードだけじゃなくて、ソフトも一丸になってやってかないとクオリティ高いものにならないので。僕の仕事は、Coineyというプロダクトにおけるユーザ体験のデザイン全体を引き上げることなんです。

白石: 実に広いですね。すごい。

久下: やはり物理的なオブジェクトを扱うサービスのデザイナーなので、オブジェクトに関わるデザインとエンジニアリングは基本全部手がける、って感じですね。会社のオフィスもデザインしましたよ。今いるこの会議室も、僕とFLOOATという仲良くしていただいてるデザイン会社でデザインしたんです。

久下さんがデザインされた会議室。「外国人がイメージする和室」をテーマにしたとのこと。黒く見える床も実は畳敷き。

おわりに

白石: では最後に、「IoT時代のデザイン思考」という記事の締めくくりとして、読者の皆様に対してお二人からメッセージをいただけますでしょうか？

久下: IoTの時代は、ハードウェアもソフトウェアも一緒くたになった、みんなが力を合わせて製品づくりをしていく時代です。個人的には、「やっとそういう時代が来たか」という感慨もひとしおです。せっかく、「いろんなジャンルの人が手を取り合って作る」というのが違和感のない時代になったのだから、みんな一緒になってどんどんモノづくりしていきましょう！

秋葉: これから、Webデザイナーも新しいことにどんどんチャレンジしていかなくてはなりませんね。そういう過程では、失敗事例もどんどん出てくると思いますが、みんながチャレンジしてみんなが失敗するのだから、それも許されるというのがIoTの時代だと思います。Just Do It!ですね。

DeNAとGoodpatchの現役クリエイターが中心となって立ち上げられた、UIデザインを追求していくコミュニティ「UI Crunch」。11月27日に開催された第2回目の勉強会のテーマは「UIデザイナー不要説について語る」。

サービスやプロダクトを作る上で大きな差別化要因となっているUIデザイン。とはいえUIデザインに携わるUIデザイナーが、業界や企業において高い評価を受けているわけではない。そんな状況にもやもやした状況からネット上では「UIデザイナー不要論」まで飛び出すことに。「UI Crunch #2」はそのホットな話題「UIデザイナー不要説」について、徹底討論が繰り広げられた。

「UIデザイナー不要説」を書いた真意

最初のスピーカーとして登壇したのは、今回のイベントテーマとなった「UIデザイナー不要説」というブログを書いたTaiki Kawakamiさん。スピーチタイトルは「UIデザイン最終防衛マニュアル」。KawakamiさんはWebサービスUI設計やフロントエンド実装を行っているデザイナー。また個人でもTwitterクライアント「YORUFUKUROU（夜フクロウ）」のUIデザインを作ったり、Λ Structure Designというブランドを立ち上げたりしている。

　▲Taiki Kawakami（@seabream）さん

そんな中、UIデザインについてもやもやしている気持ちから「UIデザイナー不要説」という記事を書いたところ、業界に「波紋を起こした」と語る。「UIデザインが不要だとは思っていない。しかし企業としては投資しても短期的に大きなリターンが得られるものではない。だから投資されづらいという趣旨の記事だ」とKawakamiさんは極端な例を挙げて説明を続けた。

あるWebサービスにおいて、これまでの経験から1カ月で10個の新機能をリリースすれば5000万円の売上が上がると見込まれるとしよう。1カ月に10個リリースするには最低限のデザイン。しかしデザインに時間をかけると5個しかリリースできない。

その場合、経営者はどっちを選ぶかというと前者となる。そんな状況の中で、デザイナーは後者の方が、価値があるんだよとどうやって説得すればよいのか。このような状況からすぐ脱却できる方法について、Kawakamiさんが示したのは4つ。

1.革命：何らかの方法で社内にUIデザインの必要性を認知させる

例えば、簡単に作れるプロトタイピングを提出して議論をしたり、自主的にUIデザインが優れたものを作ったりして、数値測定をしてみるのも一つの手だ。ただ数値測定については「UIデザインを変更すると、これまでのユーザーの慣れにより数値が一時的に落ちることがあるので諸刃の剣になることも」とKawakamiさん。それでもダメなら上司、上層部に掛け合うことだ。

2.転職：よりUIデザインを重視している企業へ転職する

自分がこのプロダクトがいいなと思っている企業など、優れたアウトプットができている企業かどうかで判断するのである。もし分からない場合は、転職エージェントに相談するのも一つの手だ。

3. 独立：起業するかフリーランスになる

自由になるが、何もかも自分で考える必要があり、毎月固定の給料が入るわけではないので、生活が苦しくなることもある。

4. 趣味：仕事ではなく趣味でUIデザインを重視したものを作る

「僕の場合はこれ」とKawakamiさん。今日のスピーチも趣味で引き受けたのだそう。趣味なら自分でやりたいことを単純に追求できるし、アウトプットしていると「いろいろお願いされるので副業になることがある」のだという。あまり大きなことはできないが、1から3番と両立することができるので、「今いる環境に不満のある人は試してみるといいのでは」とアドバイス。

長期的な解決方法としては、「UIデザインの重要性を啓蒙していくことだ」と言う。そのためには「エンジニアがコードをどんどん公開して議論しているように、デザイナーもUIに隠されたデザインコードを公開し、どうしてそういうUIを作ったのか意図も含めて議論していくことだ」と語る。

いろいろ議論することは、自らの成長にもつながる上、会社の広報にもなるとも言う。もちろんコンプライアンスなどもあるが、公開することで、非デザイナーもUIデザインへの理解が高まっていく。Kawakamiさんは最後に「UIデザイナー不要説なんて見向きもされない世の中を目指しましょう」と締めくくった。

丸裸になって自分がやりたいUIデザイナーを考える

続いて登壇したのは、nanapi CCO デザイナーの上谷真之さん。スピーチタイトルは「風呂場で考えるUIデザインの未来」。

　▲株式会社nanapi CCO デザイナー　上谷真之さん

UIデザイナー不要説について語ると、どうしてもUIデザイナーの市場価値や求められるスキル、さらにはUIを生み出す価値などが話題となるが、これらは組織や業界のトップダウン的な考え方。

またUIデザイナーと一口に言っても、所属している企業やその人が描いているキャリアイメージによってそれぞれ異なる。統一的な指標やフレームに当てはめて議論にすると大抵は不毛に終わる。そこでここでは既存の考え方から解き放って考えたい」と上谷さんは言う。それが「風呂場で考える」ことなのだ。

風呂に入るときは、みんな裸になる。つまり既存の考え方（衣服）を脱いで、ゼロベースで話し合い、キャリアについて俯瞰していこうというのである。「思考のリフレーミング。枠組みを外して考える」を行うというわけだ。

思考のリフレーミングは「こわす」「ならべる」「もどす」の3つを行って整理することで可能になる。

1. こわす

今置かれている組織や肩書きを外すのである。例えば上谷さんもnanapiや職種などすべてを外してしまえば、33歳の単なる独身男性という状態になる。

2. ならべる

壊した状態、フレームを外れた状態で自分のキャリアについて見直してみるのである。上谷さんの場合は、UI設計、ユーザーリサーチ、組織作り、情報設計、サービス改善、企画などのスキルを並べ、さらに「心に届くデザインで世界を変えたい」という自分のビジョンやライフテーマも挙げた。

3. もどす

自分の目指すキャリアややりたいことを社会や組織に戻してみるのである。自分を起点にして社会や組織にこんなキャリア、こんな価値を届けていきたい、それができるよう組織、社会にアジャストさせていくことを考えるのである。こういう手法を使い、UIデザイナーとはどういう仕事なんだろうということが、整理できる。

「業界や社会が求めるUIデザイナーを気にしすぎるのは時間がもったいない。誰かに合わせて決めるのではなくて、自分がやりたいように決めるのが重要だ」と上谷さんは強調する。

* 誰かが決めたUIデザイナーという肩書きはいらない
* 自分がやりたいことをやろう

「デザインを楽しんですばらしいサービスを作ってほしい」と語り、スピーチは終了した。

B2Bアプリ・サービスにおけるUIデザインの価値とは

3番目に登壇したのは、トレタ COOの吉田健吾さん。スピーチタイトルは「UIデザインの価値」。

　▲株式会社トレタ COO 吉田健吾さん

吉田さんは自身のブログ「Parallelminds」にKawakamiさんの「UIデザイナー不要説」のアンサー記事「UIデザインの価値」を書いた一人。この業界に所属して13～14年。2014年7月より「トレタ」という飲食店向けの予約台帳サービスを提供している会社で、COOを務めている。

「UIデザインに価値はないのかと問われたとしても、もちろんあると答えるしかない」と吉田さんは言い切る。その理由は、「ユーザーが触れるところはUIであり、そこが良くなければ優れたビジネスモデルも高い技術力も評価されないと思う」からだ。UIはユーザーのアプリに対する印象に加え操作感も決定づける重要な要素である。従って「UIデザインは競争力の源泉になると考えている」というのだ。

「ただUIデザインよりも他の要素が優先されるケースはある」と指摘する。その一つは価格訴求力が強い場合。またポイントが付くなど、デザイン以外の何か強力の魅力がある場合。さらにB2Bアプリで多いのが、デザインの善し悪しで利用可否が決まらない場合。「自分の例で言うと会社で使っている勤怠申請のサービスは使いにくいが、決められているので使うしかないというようなことがそれだ」と吉田さん。

つまりUIデザインは数ある要素の一つである。ビジネスの結果を出すために万能ではないが重要なもの。先述したように、特にデザインの善し悪しで利用可否が決まらないケースが多いのが、B2Bアプリ・サービスである。そこでB2BのおけるUIデザインの価値とは何か。

トレタが提供している飲食店向け予約台帳サービスは、仕事のために使うアプリである。飲食店は非常に忙しい。操作に迷ったり、ミスを誘発したりするようなUIは大きなコストにつながる。

そのため、「B2Bの現場でのUIの価値は大きく説明しやすい」と吉田さんは言う。とはいえ、「1年も使っていれば慣れる」というセリフがまかり通るのもB2Bの世界ならでは。特に稟議を回すときは「高機能、多機能、低価格」なものほど通りやすい。

つまりUIが優れていることの価値について、稟議を通すのは容易ではないのだ。そこで「シンプルで簡単であることがどれだけ重要かを伝えるようにしている。UIデザインにちゃんと価値があることを伝えている」と語る。

同じようなB2Bアプリが登場している中で、一番差別化できるポイントがUIデザインなのだ。最後に「UIデザインを競争力としてその価値を証明していきたい」と語り、スピーチを締めくくった。

過去を振り返りUIデザイナーの必要性を考える

ラストに登壇したのはBASEのCTOである藤川真一（えふしん）さん。スピーチタイトルは「経験に基づくUIデザイナーの必要性」。

　▲BASE株式会社 取締役CTO　藤川真一（えふしん）さん

製造業の技術者としてキャリアを積んできたえふしんさんは、2000年にネット業界に転身。2004年頃に在籍していた会社では、UIデザイナーという職種がなかったという。「その頃の話をしたい」と語る。当時のWebの制作はどんな状況だったのか。

1. 営業部門でWebの重要な仕様が決まっていた

2. もう言っちゃったから、今さらやめられない。どうにか実現せねば。

3. 案の定、制作部門が不満たらたら

（営業やディレクターが起こした簡単なパワポを下にデザインを起こしていくので、不備が出てくる）

4. 制作部門は納得いかないので、自分たちのコストで作り直してしまう

（アーキテクチャ不在。作った階段を自ら壊す）

5. 開発チームがとばっちりを受ける

そのときに思ったのが、「Webの設計は誰がやるの」ということだったという。えふしんさんは当時書いたブログを披露してスピーチを続けた。

Webを設計する人は技術者でもないしビジュアルデザイナーでもない。その中間の人だ。いずれデザイナー的な側面の人か技術者的側面のいずれかの人が傾倒し、そういう職種の人が登場してくるだろうということを予言していたという。

だが、業界はそうではなかった。だからこそ当時のえふしんさんは「設計の重要性がそこまで認知されておらず、誰もWebサイトの実現性に責任を持てない状況であること」「スキルセットが不足しており、とりあえずデザイナーやディレクターにアサインされてしまう状況を問題視していたのだ。

そして今もこのような状況があるという。当時から役割として必要だなと思っていたのは、情報の設計=Web UIデザインに責任を持つ人、プリセールスとポストセールスに関わる人（受託の場合）、そしてチームの一員としてWebサイトが目標とするフィロソフィーを円滑に実現する役割を担う人（楽しさ=UX、ユーザビリティ、実用性）である。

しかし「そんな人材いないよね」という説が登場する。もちろん「すべてができる人材を求めているわけではない」し、「チームとして補えればいい」というのだ。またこういう役割が「職業分野としてFIXしているとは思っていない」とも言う。

「お母さんでも使えるネットショップ」+「モノを売るたのしさ」が味わえるサービスを提供しているBASEではどういう人を求めているのか。成果の原資として必須なのが、ビジュアルデザインのスキルである。次に論理的思考。つまり物事を順序立てて考えられ、ちゃんと説明できること。第三にネットがすごく詳しい人もしくはすごく興味がある人だ。

「UIのスキルはぼくたちがカバーできる」えふしんさん。BASEというサービスがチャレンジなので、ジョインする方にも会社と自分を成長させていく人がくればいいというのだ。その中で「UIデザイナーは不要なのか。その存在意義をついて改めて考えていきたい」こう語り、スピーチを終えた。

「UIデザイナー不要説」をテーマに語り合う

10分間の休憩を挟み、UIデザイナー不要説について語り合うパネルディスカッションが始まった。パネラーはゲストスピーカーとして登壇した4人にDeNAのUI Designerの坪田朋さんの5人。そしてGoodpatch CEOの土屋尚史さんがモデレータを務めた。

　▲左から、DeNA デザイン戦略室室長 UI/UXデザイナー坪田朋さん、株式会社グッドパッチ 代表取締役 土屋尚史さん

土屋：なぜ「UIデザイナー不要説」という記事を書こう思ったのでしょう。UIデザイナーが不要だと思ってないですよね。

Kawakami：不要と書くと逆に必要だという議論ができると思ったんです。

土屋：そしてKawakamiさんのブログを見て書いたのはアンサー記事を吉田さんが書いた。

吉田：タイトルを読んだ感想となんかイメージが違ったんです。

土屋：その頭の整理のために、えふしんさんが記事を書いた。

えふしん：けんごっち（吉田さん）が書いた記事を読んで、そういうことあるよね、と思いつつ、UIデザイナーや開発者を募集しているので、そこで思っているとことを書いたんです。そもそも、当社でも募集するときに職種名の出し方をどうするか、WebデザイナーかUIデザイナー、フロントデザイナーなのか工夫していたんです。でもなんかはまらないなと思っていたときに、そういう記事が上がったんです。

土屋：みなさんの会社にUIデザイナーと呼ばれる方は何人いますか？DeNaの坪田さん。

坪田：クリエイターは200人ぐらいいますが、UIデザイナーと呼んでいる人は20～30人です。当社のUIデザイナーのミッションはUIの設計はもちろん、プロトタイプまでも回す人。ディレクターとグラフィッカーとタッグを組み、UIデザインを開発していきます。

上谷：うちはUIデザイナーがゼロです。単にデザイナーはデザイナーと呼んでいる。うちのエンジニアはプロトタイピングまでを作るので、UIという言葉をあまり意識していないのかもしれません。デザイナーは僕を含めて6人。

デザイナーの仕事はかなり広くてビジュアルデザインはもちろん、マークアップ、UIの設計、情報設計、数字にもかなりコミットする。もちろん、一人で全てに責任を持つのではなく、特異な分野アサインしています。

土屋：Kawakamiさんの会社は、UIデザイナーは何人いますか？

Kawakami：10人ぐらいですね。デザイナー全体だと50人くらいいます。

土屋：その中でKawakamiさんはUIデザイナー。デザイナーになったのは？

Kawakami：2013年です。もともとは別の会社でWebデザイナーとして経験を積み、今の会社でUIエンジニアを経てUIデザイナーになりました。社内で必要だと言う風潮が高まったことがきっかけです。

吉田：トレタは20人ぐらいの会社ですが、デザイナーは一人。その彼はUIデザイナーだけをやっている。いわゆるWebデザインは外注にお願いしています。アプリを担当しているデザイナーしかいません。

えふしん：BASEはデザインを担当しているのは3人です。そのうちUIデザインを設計するのは1人です（2014年12月からは2人）。人それぞれ得意分野が違うので、パーソナリティに応じてお願いしている。いちばん広い職域の人はデザイン、UI設計、マークアップ、さらにはPHPのテンプレートまでいじってもらっています。

土屋：うちはデザインの会社なので、UIデザイナーは12～3人います。元々はWebデザイナーとグラフィックデザイナーだった人たちが、現在、UIデザイナーとして活躍しています。

UIデザイナーが持つ権限について

土屋：プロジェクトの中でUIデザイナーはどのくらいの決定権を持っているのでしょうか。

坪田：プロダクトの最終の意思決定権はプロデューサーが持つべきだけど、サービスを作る人、つまりUIデザイナーがハンドリングやコントロールの意思決定権を持つべきだと思います。

土屋：UIデザイナーが最終の意思決定権を持つ人になってはいけないんですか？

坪田：僕は昔サービスを造ったときにプロダクトオーナーとしてUI設計をしたこともあるので、ケースによってはあってもいいかなと思う。僕はある程度の意思決定権がないとサービスを作りたくありませんね。

土屋：nanapiはどうですか？

上谷：うちはデザイナーの意思決定権は一般的には強いと思っている。最近、新規開発を行っているチームはデザイナーとエンジニアのみで構成されており、KPIも全員が持っている。そんなプロデューサー、ディレクターはいないチームが何チームもあります。KPIを達成するための施策は承認がいらないんですよ。

土屋：承認がいらないんですか？　デザイナーがこうしますと言ったことが実装されるということですか。

上谷：新規開発はスピードが優先されるので、意思決定で遅くならないように権限を移譲しているんです。

土屋：Kawakamiさんの会社ではデザイナーはどんな立ち位置ですか。

Kawakami：非常に権力が弱い状態です。だから不要説を書いたということもある。本当に自分必要なのと感じるぐらい低い。

土屋：もう少し具体的に話してくれますか。

Kawakami：元々、デザイナーがUIを考えるという工程がないんです。ディレクターのつくったそれほど凝っていないパワポから画像を作り、それをエンジニアがそれを組み込むという感じです。ただ、最近は徐々に改善してきており、僕自身がワイヤーフレームを書いたりするようになりました。

吉田：うちは権力というか権限ということで言うと、代表の中村がプロダクトオーナーを兼務しているので、最終的な意思決定は全部彼が担います。中村は飲食店の現場にいた経験があるので、彼以上にユーザーに近い人材はいないんです。

土屋：BASEはどうですか？

えふしん：うちも代表の鶴岡がクリエイティブディレクターという立ち位置なので、最終の意思決定権は彼が担っています。ただ、当社では機能マターではなくデザインマターで開発するように言われています。つまり使いやすさ、楽しさが先になかったら、機能を追加しても仕方ないという考え方があるんです。

土屋：まさにデザインドリブンですね

えふしん：そうです。

UIデザイナーとして求められる人材とは？

土屋：デザイナーの募集条件について教えてください。

坪田：すごくグラフィック勉強してきましたとかデッサン力ありますと言うより、作ったものをきちんと自分たちで自己否定して、何がユーザーに刺さるのかという思考を巡らすことができる人ですね。

今は2Dだけでなく、アプリケーションの開発はアニメーションやレイヤー、トランジションなども含めて、機能としてデザインしていくことが求められます。それらを頭の中でシミュレーションしてUI設計できる人ですね。総括するとユーザーが本当に使うかどうか、機能を選別してディレクションできる人です。

土屋：そんな人はいません（笑）。

坪田：全てできる必要はないんです。足りないことはコミュニケーションできて、ユーザーを意識しながら頑張る人。楽しみながらプロトタイプを回せる人です。えふしんさんとも話していたけど、UIデザイナーはスタートアップ時のCTOと似ていると思うんです。名称は魅力的だけど、やることは何でも屋さん。

上谷：うちはUIデザイナーではなく、デザイナーを募集しています。重視しているのは情熱と視座の高さ。この2つがあればスキルは付いてくると考えているからです。

吉田：同じような答えだが素養や姿勢が大事だと思っている。デザインに対して、代表の中村が全身全霊をかけて聞いてきます。そのときに、なぜこういう風にしたかを自分の中でロジックを立ててちゃんと説明できることが大事になるからです。

えふしん：UIの担当で言うと、普通に採用するときはいいビジュアルデザインができるかどうかを見ます。Webもアプリもぱっとみて使えなければ、その後ろにどんな高機能があっても使えないからです。かっこいいデザイン、魅力的なデザインがあって、その後ろに使い勝手があると考えています。

だからビジュアルデザインを見るんです。次に重視するのは論理的思考です。物事を順序立てて説明できる、ユーザーにとってどうハッピーかを議論できること。そういうデザイナーであれば育成できます。あとは度胸のある人ですね。スキルはできなくても立ち向かう勇気が必要だからです。

土屋：と企業は言っていますが、Kawakamiさん、いかがでしょう。

Kawakami：そんなに募集しているんですね。デザイナーの需要があるということは、もっと発信していってほしいと思います。

土屋：Kawakamiさん周りにいるデザイナーさんたちは、どういうところで働きたいと思っているのでしょうか。

Kawakami：それなりの権限が与えられており、意思決定に携われて、給与も平均以上ぐらいもらえる会社ですね。

デザイナーの給料は上がるのか？

土屋：以前、Webデザイナーの給与が非常に安いという議論がありました。デザイナーの給与はどうやったら上げられるんでしょう。

えふしん：マネジャーになれば上がります（笑）。というのはさておき、成果物の評価が難しいんですよね。

土屋：デザインは定量的（数字に換算できない）な評価ができないことが多い。これをやったら売上がこれだけ上がるという証拠が提示できませんからね。こう点が、デザイナーが冷遇される要因になっていると思うんです。

吉田：ぼくはもっと単純に考えていて、需給関係の問題だと思います。UIデザイナーが採れないというのであれば、UIデザイナーの給与は高く出さないと来ないと言うこと。Webデザイナーは供給が多いか、できる人、できない人の判別ができていないからではないでしょうか。

社内の対策としてはえふしんさんがおっしゃったように、上級職を作っていくということもありますが、評価軸もデザイナーたちで作っていくという動きがあればよいのかなと思っています。前職（ペパボ）にいたときに、エンジニアが上級職制度を作ったんですよ。みんないろんなアウトプットしてもらって、業界的に上がっていくのでは。

えふしん：Goodpatchさんが単価を上げて公開すると、「デザインってこんなにコストがかかるんだよ」というというのがわかるようになるのでは（笑）。業界としてこれぐらいのクオリティを保つにはこれぐらいかかるよというのを示してください。

土屋：今、それをやろうと思っているんですよ。そしてデザイナーの評価制度も今、作っています。デザインの単価はこの1年半で人月単価が倍になっているんです。

坪田：デザインの受託会社は、グラフィックのみ納品しており、プロセスは納品していないんです。グラフィックだと人月単価でそこそこの単価で出せるし、相見積もりをとると他の会社が安く出すと平均値を取られてしまう。デザイナーも強気に言っていった方がいい。

土屋：ソーシャルゲームが流行ったことで、それに携わるエンジニアの給与はかなり上がりましたからね。今はデザイナーでも同じことが起きようとしているということですね。

坪田：あと1年ぐらいしたら、デザイナーにオファーレターがたくさん届く時代がくるのではないでしょうか。そのときに大事になるのは自分のプレゼン力。海外のデザイナーは自分のプレゼンがうまいんですよね。自分はこれだけ高い価値を持っているしポートフォリオを持っているからちゃんと高く評価してくれないと仕事をしないというスタンスなんです。

土屋：低い給料で働いてしまっているデザイナーさん達にも問題があるということですね。

Kawakami：今日は本当に勉強になります。

稼げるデザイナーになるために

土屋：稼げるデザイナーになるためにはどうすればよいでしょう。

Kawakami：ぼくは稼げていないので、教えてほしいですね。

坪田：オリジナルのUIデザインをなぜこのUIにしたのかという理由とともに、毎月、BehanceやDribbbleに上げていくんです。おそらく1年以内に200万ぐらい給料を上げられるオファーが来ると思います。自分で発信してプレゼンして目立つ人は、企業からオファーが来るんです。だまされたと思って、半年やってみてください。よければぼくがスカウトしますので。

土屋：日本では自分でデザインを作っても公開できないみたいな風潮があります。坪田さんは会社のデザイナーでも全部、公開しようとしているんですね。

坪田：自分でつくったものは言いたいじゃないですか。言えない環境は不健全だと思うんです。そこで当社では仕事で作ったものをBehanceやDribbbleなどで発信していこうという文化に変えました。企業努力すれば変えられます。それが優秀な人材を確保することに、そして企業の存続にもつながるからです。

吉田：オープンソース活動と同じです。有名になった人に仕事以外にも話がくる。これはみんなが努力をすれば登れる山です。エンジニアはソースコードを公開することができるが、デザイナーは最終のアウトプットだけ出してもダメなので、意図なども出していくとこの人はちゃんと話が通じるデザイナーだと見えるようになりますよね。

土屋：Kawakamiさん、個人でも仕事を受けていますよね。個人だとある程度、単価を上げて出しますか。

Kawakami：出しますけど、値切られることが多い。

土屋：負けちゃダメですよ。こんなに価値を出すのでといって、言い切れるのが重要だと思います。

デザイナーはプロダクトをリードできる立場になれるのか

土屋：デザイナーがプロダクトをリードできる立場になれる時代が来るのでしょうか。

坪田：その人次第ですが、そういう環境はすでにできています。

えふしん：スマートフォンのアプリはデザイナーがリードしないと作れませんしね。

土屋：とにかくこれから1～2年、UIデザイナーはスター状態だと思います。

坪田：もし今の環境がデザイナーの価値を感じてくれていないのであれば、別の価値を感じてくれる場所に行くべきだと思います。

会場からの質問はもちろん、スクーでの受講者の質問にも答え、盛り上がったまま終了時間を迎えた「UI Crunch #2」。UIデザイナーは不要どころか、今後ますます求められる存在となることがわかった。ビジュアルデザインが得意なら、開発側からも転身ができる。これからの注目の職種と言えるのではないだろうか。

HTML5 Experts.jpが誇るエキスパートたちに、「UX」というテーマでインタビューするシリーズ、いよいよ最終回です。

今回は、面白法人カヤックでHTML5を使ってバリバリ仕事をしていらっしゃる田島真悟さんと君塚史高さんに、いろいろとお話を聞いてきました。 カヤックさんに聞いてみたかったテーマは主に二つあります。

• 技術力に定評のあるカヤックさんが、HTML5やJavaScriptとUXについてどう考えているのか？
• 一見自由が利きそうにない「受託開発」という形態の中で、いかにUXを追求しているか？

ではどうぞ、お楽しみください！

クライアントのニーズを掘り下げると「体験」に行き着く

白石: 今回は、HTML5を普段からお仕事で活用していらっしゃるお二人に、UXというテーマでいろいろお話をお聞きしたいと思っています。どうぞよろしくお願いします。

田島＆君塚: よろしくお願いします。

白石: 皆さんは、普段どんなお仕事をされているのですか？

田島: 私たちはクライアントワークを行うチームで、普段は受託開発をしています。企業のお客様から依頼を受けて、キャンペーンサイトを作るお仕事が多いですね。

君塚: 私も田島と同じチームで働いています。あと、弊社にはHTMLファイ部という部署がありまして、私はそこのリーダーを務めています。

田島真悟さん

君塚史高さん

(invalid jsdo.it code)

君塚: RAIZIN Coolは、もともとRAIZINというエナジードリンクの「クール」版を発売する際に、「クールさ」を表現したいというご要望があったんですね。そのご要望を満たすためにどうしたらよいかを考えて、結局HTML5のCanvasを使用しました。ついでに言うと、技術的にもクールでしょ、と(笑) 。実際に技術的な部分が評価されて、海外でも話題になったのはうれしかったですね。

「絞り込み」こそ、とがったユーザー体験のカギ

白石: 体験という観点から、他に面白い事例とかありますか？

田島: 「キュウソネコカミ グッズでんたく」は、ユーザー体験という点では面白いんじゃないかと思います。これは、キュウソネコカミというバンドのライブイベント向けに開発したWebアプリです。どんなアプリかというと、ライブのグッズ売り場で並んでいる時に暇つぶしをしてもらうためのアプリですね。「電卓」という名前からも分かる通り、グッズを選んでいくと、事前にいくらお金がかかるのかわかるというサイトです。

キュウソネコカミ グッズでんたく

公式キャラクターの「ネズミくん」が、選んだアイテムに関して一言つぶやく

Webアプリとネイティブアプリ、その長所と短所

白石: 今の事例は、Webじゃなくてスマホアプリであっても成立しそうな事例ですよね。インストールのひと手間はかかっちゃうでしょうけども。何か、「Webならでは」の事例ってありますか？先ほどおっしゃっていた、Webとアプリの長所と短所という点について掘り下げて聞いてみたいんですが。

田島: 以前ドミノ・ピザ様向けに「世界最短のタイムセール」というキャンペーンアプリを作らせていただいたことがあります。どんなアプリかというと、「時・分・秒・0.1秒」の数字が全部揃った時にタイミングよくボタンを押すと、ピザが半額で買えるというFacebookアプリです。チャンスは1時間に1回、0.1秒しかありません。

世界最短のタイムセール

「受託開発だけどUXに妥協しない」ための仕事術

白石: 以前長谷川さんや木達さんにインタビューした際に、「受託という仕事の形態だと、作り手がユーザー体験をコントロールできる範囲はどうしても限られてしまう」という議論がありまして。一方でカヤックさんは先程からお話をお聞きしていると、受託開発をしつつも「体験」には妥協していないように思えます。どのような仕事の進め方をされているのでしょう？

田島: まずお客様からご要望をいただいたら、それを満たす手段を検討するためにブレインストーミングを実施します。弊社はブレストを非常に重視していまして、そのブレストにはデザイナーやエンジニアも参加します。技術的な知見がないと出せないアイデアもありますし、新しい技術を積極的に活用していくためにも、デザイナーやエンジニアと一緒にブレストするのは非常に大事ですね。

以降は、そんなに変わったところはないと思いますよ。ディレクターがワイヤフレームを作って、デザイナーがデザインカンプを起こす。そうしてお客様と仕様を詰めていって、その後サーバサイドエンジニアとフロントエンドエンジニアが共同で実装にあたる…という流れです。

白石: そういう「仕様が固まってない」状態からの提案・開発となると、お客様からの仕様変更とかも多いんじゃないでしょうか。開発のスピード感はどうやって出しているんでしょう？

田島: うーん…うちらは、普段から結構短納期の仕事をよくこなしているので、普段から鍛えられている、っていうのはあると思いますね。

君塚: 一言で言うと「頑張る」(笑)。

君塚: とはいえ、仕様変更を「前提」として考えているという態度を徹底しているのは、大きいかもしれません。限られた期間、予算の中でできる限りお客様の要望の変化に追随していく。それを続けていくと、勘も養われてくるんですよね。仕様が変わりそうなところ、そしてもっと大事なのは、仕様が変わらなそうなところがどこか…というのがわかってくる。

そういう「固い」部分って、プロジェクトが違っても共通している部分がある。繰り返すごとに、再利用できるコードも増えてくるわけですね。以前使ったコードを組み合わせて作る…ということで、もっと早くなる。また、仕様が変わりそうなところのあたりがつくと、あとから変わってもいいように作っておく。そういう積み重ねがあるおかげで、仕様変更自体は多いけど、無駄な作業があまりないという状況が作れているんだと思います。

白石: なるほど。こうしてお話をお聞きしていると「作り手であるカヤックさんの裁量が大きい」ということが感じられるんですよね。カヤックさんの中でブレストして提案していくっていうのは、結局のところ作るものを自分たちで企画しているということですよね。それってよく考えると、「お客様のご要望に従って作る」という受託開発のイメージとは、逆と言ってもいいかもしれない。

君塚: そうですね、「言われたとおりに作れ」っていう「プリンター」みたいな仕事は、ごく稀にしかないです。クライアントさんと一緒に作り上げていく…という感覚の仕事が多いですね。

白石: ぼくもカヤックさんとお仕事させていただいてます（※HTML5 Experts.jpのサイトはカヤックさんが制作）が、「面白法人」に向かって「プリンター仕事」発注する気にはなかなかならないですしね(笑) 。企業としてのブランディングが確立しているというところも、要因の一つかもしれませんね。

ただ、営業の時点でお客さんとの上下関係ができちゃっていたり、契約上作り手に自由度が全くなかったり…ということはないんでしょうか？ぼくも以前受託案件を生業にしていましたが、作り手の自由度って、そういう「立場」「力関係」や「契約」と言った、開発以外の部分に相当縛られると感じています。

君塚: 弊社には営業専門の社員はいなくて、ディレクターの繋がりでお仕事をいただくことが多いので、そもそもそういう問題が起きにくいというところはあるのかもしれません。ただぼくは前職で飛び込み営業やってた経験がありまして、その経験を踏まえてお答えするのですが、うちの会社はコミュニケーションに裏表がないなあ、とは思いますね。

例えば、デザイナーやエンジニアなどの作り手が、お客さんに伝えたいことがあったとします。その仕様変更は受けるのが難しいとか、より良いアイデアとか、なんでもいいんですが。そういう現場の意見を、間に入っている営業が「お客さんとの関係がこじれると面倒だから」とか、そういう理由で握りつぶしたりしてしまうことがあるんですね。

この会社（カヤック）にはそれがないなあ、と。基本的に、ディレクターはお客さんに何もかも正直に伝えるんです。例え面倒な話だったとしても、その時点で「正しい」と思ったことは正直に伝える。それが通らなかったなら、相応の理由があるわけだし、その理由を聞いて現場も納得する。こういう、みんな正直で正しいことが通りやすい、駆け引きのないコミュニケーションを行う文化が、結局はフラットで対等な関係を生んでいるんじゃないかなあ…と思いました。

白石: なるほど。率直なコミュニケーションと鍛えあげられた現場力が、クライアントとの対等な関係を生み、それがユーザーにとっての最高の体験を追求できる環境づくりに繋がっている…とまとめさせていただいて、本日のインタビューは終わりにしたいと思います。

長い時間のインタビューにお付き合いいただき、本当にありがとうございました！

年間読まれた記事ランキングTOP20！

＜1位＞
Googleはなぜモバイルに力を入れるのか？これからのWebパフォーマンスで注力すべきポイント
── 川田寛

＜2位＞
モバイルWeb開発に役立つ！Chrome DevToolsの新機能「デバイスモード」
── Tomomi Imura

＜3位＞
Googleのベストプラクティスに沿ったモダンな製作の出発点「Web Starter Kit」
── 中島 直博

＜4位＞
Web Componentsが変えるWeb開発の未来
── 泉水翔吾

＜5位＞
HTML5とかモバイルとかJSフレームワークとか、ぶっちゃけどうなの座談会
── 村地彰

＜6位＞
初心者でも絶対わかる、WebGLプログラミング＜three.js最初の一歩＞
── 小山田 晃浩

＜7位＞
いまや最も優れたJavaScriptフレームワーク「AngularJSリファレンス」出版記念会
── 佐川 夫美雄

＜8位＞
HTML5で実現できる！環境光に合わせたレスポンシブなUI
── Tomomi Imura

＜9位＞
いま、UXを語るのはなぜ悩ましいのか？─長谷川恭久ロングインタビュー
── 白石 俊平

＜10位＞
エンタープライズで使える！実践から学ぶJavaScript MVCフレームワークの選び方
── 酒巻瑞穂

＜11位＞
Web技術者も知るべきデモ・プレゼンの極意（西脇資哲氏）「Microsoft de:code」イベントレポート
── 岩瀬 義昌

＜12位＞
HTML5が変える、エンタープライズITの可能性とこれから
── 川田寛

＜13位＞
【速報】Google I/O 2014 キーノート ライブレポート
── 岩瀬 義昌

＜14位＞
自分の書いたコードが即座に解析できる「StyleStats」でCSSを測ろう！
── 石本 光司

＜15位＞
キミはionicを知っているか？AngularJS+PhoneGap+美麗コンポーネント群！
── 金井 健一

＜16位＞
話題のMaterial DesignをWebで実現！Polymerで「Paper Elements」を試そう
── 佐藤歩

＜17位＞
HTML5ハイブリッドアプリ開発、最新動向はやわかり！
── 久保田 光則

＜18位＞
ミツエーリンクスのCTOに「UXとWebアクセシビリティ」について聞いてきた─木達一仁ロングインタビュー
── 白石 俊平

＜19位＞
Web Componentsを構成する4つの仕様 ー Web Components基礎編
── 泉水翔吾

＜20位＞
NUCで手のひらサイズの格安WebSocketサーバーを立ててみた(ハード組立編)
── 高橋 登史朗

モバイルWeb、WebComponets、AngularJS…

モバイルWebというキーワードは今年注目を集めましたね。関連記事がいくつかランクインしています。また、WebComponets、AngularJSという今年話題になった技術の記事もランクインしています。特集では、GoogleI/O特集やExperts Opinions「UX」特集が注目を集めました。UX特集は年明けにも記事公開を予定していますので、お楽しみに！

HTML5 Experts.jpは2014年も多くの方々にご愛読いただきまして、執筆陣・編集部共々感謝しています。ありがとうございました。来年も引き続き宜しくお願いいたします。

HTML5 Experts.jpが誇るエキスパートたちに、「UX」というテーマでインタビューするシリーズ第五弾です。

ぼくも昔はSIerの孫請けとして、エンタープライズ業界の片隅で働いていたので、エンタープライズというキーワードにはつい反応してしまいます。とはいえ、今のエンタープライズ業界がどういう状況かはよく知らないのですが、UXに関する特集を行うにあたっては、「エンタープライズとUX」というテーマで必ず誰かに話を聞きたいと考えていました。

そこで株式会社セカンドファクトリーの新谷剛史さんに、このテーマをぶつけてみたところ、取締役副社長 シニアUXストラテジストの齋藤善寛さんも参戦し、めちゃくちゃテンションが高くて密度の濃いインタビューになりました。 今回、「(笑)」が多いのは（主に齋藤さんの）テンションの高さの表れだと思ってください。

エンタープライズとUXについて、ここまで濃くてぶっちゃけ気味のトークはなかなかないんじゃないかな、と自負しております。では皆さんどうぞ、今回もお楽しみください！

　　▲左から、株式会社セカンドファクトリー 新谷剛史さん、同・取締役副社長 シニアUXストラテジスト 齋藤善寛さん

エンタープライズシステムはネガティブな宿命を背負っている？

白石: では、本日はよろしくお願いします。まず最初にお聞きしたいんですが、「エンタープライズ」という言葉をどのように捉えていらっしゃいますか？

　　▲インタビュアーHTML5 Experts.jp 白石俊平編集長

齋藤: エンタープライズというと、一般的には業務用アプリってことなんでしょうけど、私たちの会社としてはあんまりそこをハッキリ定義してはいないですね。というのも、私たちはエンタープライズに特化した企業というわけではないんです。システムと人間が接するところに新たな価値を生み出せないか、そういうことをずっとやっている。

新谷: 私たちはデザインとエンジニアリングの両輪を回しつつ、ビジネス的な価値を創造することにはすごくこだわってる会社です。それが、私たちが「エンタープライズ系企業」と見なされがちな理由かもしれません。

齋藤: 確かにFlashの仕事を中心にしていた頃から、「エンタープライズ」と呼ばれる領域の仕事はやってきていますね。出退勤のシステムや、社内のアラートシステムをFlashで構築したり。それらの経験を踏まえつつ、あえてエンタープライズとは何かと言えば、「働く」という環境において利用されるものということでしょうね。「働く」という環境においては、人を働かそう、動かそうとするエネルギーがある。
それに対して、時には「動きたくない」と反発するエネルギーもあったり…って、こんなんで伝わります？(笑)。

白石: はい、大丈夫です、伝わってます(笑)。

齋藤: ってことで、業務で使用するアプリって、どうしても「（会社から）使わされる」という感覚が付きものだと思うんです。勤怠管理システムとかは、使わざるを得ないでしょ。それに、企業は何かと「管理したい」という欲望を抱いてしまいがちですが、それを形として表したものが業務アプリだったりもするわけです。つまりエンタープライズシステムっていうのは、最初からユーザーである従業員からネガティブな印象を持たれがちなもの、そういう宿命を背負っているシステムなんですよ(笑)。

白石: なるほど(笑)。ではお二人は、そのネガティブさをどうにか乗り越えて、価値を生み出すよう改善していく…っていうお仕事をされているってわけですね。それがエンタープライズにおけるUXを改善していくってところに繋がりそうですね。

エンタープライズアプリにUXが必要な理由

齋藤: 先程も申し上げたように、ぼくらは「エンタープライズかどうか」というところにはあまりこだわってはいないつもりです。ただ、UXには非常にこだわっている。例えば「エンターテインメント」であっても、「働く」ということであっても、人と情報が交錯する地点というのは必ずあり、そこにはUXが存在します。

白石: 「働く」という行為についてもUXがあるというわけですね。言われてみると当たり前ですが、気づいてませんでした。

齋藤: その通りです。だから、エンタープライズアプリのUXについて考えることは、「オフィスの椅子や机をどうするか」と言った、オフィスデザインを考えるのと本質的には変わらないわけです。

白石: なるほど。そういう捉え方は新鮮です。じゃ、オフィスデザインに真剣に取り組むような企業は、「働く」ということのUXを真剣に捉えていると言ってもいいわけですね。

齋藤: そうそう。そういう企業は、「働く」という体験を改善することにすごく前向きです。ならば当然、日々使うアプリとかも改善の対象になりますよね。職場のUXが改善されることで、職場がエネルギッシュになったりコラボレーティブになったりするなら、素晴らしいことじゃないですか。ちなみに私たちも、オフィスデザインには相当こだわってますよ。

白石: そうした、自社内のUX改善に投資する企業というのは増えてきてますか？

齋藤: 増えてきてる、と言っていいと思います。例えばBYOD（Bring Your Own Device: 個人デバイスの職場利用）なんかも、UX改善の文脈から語ることができます。使い慣れない／使いにくい端末を会社が押し付けるんじゃなくて、従業員が普段から使って慣れ親しんでいるスマートフォンやタブレットをそのまま業務用端末として使おう、という流れですね。

新谷: そういう流れの中で、エンタープライズの世界もモバイル中心になりつつありますね。今の若い人なんて、「PC持ってないけどスマホ・タブレットなら持っている」という人はザラにいるわけですから。いまだに「PC向けのWebアプリをスマホやタブレットに対応させる」という発想でシステム開発している場合がありますが、その発想はもう古いと言っていいと思います。「スマホ・タブレットで使えるものが、たまたまPCでも使える」という感覚に変えていかないと。

白石: モバイルファーストとか、今じゃモバイルオンリーなんて言葉も出てきてますもんね。

齋藤: こうしてBYODが進んでいくことで、個人のデバイスが「業務用端末」にもなっちゃうわけです。いわば業務時間はどんどん広がってきていると言ってもいいですよね。

そう、そして触れる時間が長ければ長いほど、UXも重要。だから、UXが磨かれたコンシューマー向けアプリを仕事に使うシーンもどんどん増えているんだと思います。FacebookやLINEで仕事のやりとりをするのとかも、珍しいことではなくなりました。こういう消費者向け製品を業務用に使うという流れのことを、コンシューマライゼーション(Consumerization of IT)と言ったりしますね。

今や、消費者向け製品のほうが進化が速いんですよね。以前は「企業が使っているものが安くなって、そのうち一般消費者が使うようになる」って感じだったのに、今はそれが逆になっちゃっている。例えばKinectみたいなものも今は1万数千円で買えるけど、昔ぼくらがああいうのを使ってアプリを作っていた頃は100万円くらいしていたんです。コンシューマー向け製品を使って企業が安価にモノを作る。そういう時代ですね。ここでも、発想を逆にしないといけない。

「エンタープライズアプリにUXは必要ない。だって『慣れる』から」という考えについて

白石: エンタープライズとUXというテーマで以前新谷さんとお話した時、「慣れる」というキーワードがありましたね。「最初は使いにくくても、使っているうちに慣れるから大丈夫」という考えがエンタープライズには根強い…というお話だったかと思いますが。

齋藤: その意見については、「何をおっしゃる！」…って感じですね(笑)。「慣れ」を考慮してUXの設計をするのと、「慣れ」を逃げ道にしてUXの設計を怠るのは、似ているようで全然違います。前者は熟練者への配慮。「初心者にやさしい」は、熟練者にとってはまだるっこしかったりしますからね。でも、後者はただの怠慢。ユーザの慣れを理由にして、UX改善の努力を放棄してはいけません！

「慣れ」を逃げの理由にしてはならない理由の一つに、まずは大きな話として、働き方の変化があると思います。派遣の方に来ていただいたり、いろんな企業を渡り歩いたりっていう働き方が普通になってきていて、一つの会社に腰を落ち着けて業務アプリにじっくり慣れる…っていう状況じゃなくなってきてるんですよ。

齋藤: それに、使うこと自体に「慣れる」ことはできるかもしれないけど、だからといって気持ちよく使えるようになるわけじゃないですよね。最初に触って「嫌だ」と思ってしまったら、その印象はずっとついて回るし、それが毎日のことになるとなると、働くモチベーションにも影響するでしょう。毎日アプリの使い勝手にイライラしつつ、出退勤の申請業務とかに時間取られちゃうっていうのは、バカにならないコストだと思いませんか？

白石: なるほど、言われてみればその通りです。それでも「慣れ」の話が付いて回るのは、結局のところUXへの姿勢の違いが現れる部分なのかもしれませんね。例えば、「リモートデスクトップをモバイル機器から使えるようにしとけばとりあえず事足りるだろう」みたいな。

新谷: ああ、そういう企業いっぱいありますね(笑) 。従業員にiPad渡したと言いつつ、従業員の皆さんはiPadでWindows XPの画面見てるとか。おっと、XPって言っちゃ怒られちゃうか…(笑)。

齋藤: ただですね、企業がとにかく何かしようとしている。そのことについては、肯定的に捉えるべきだと思うんです。「iPadでPCの画面を見る」のだって、機能は満たしている。ただそこに「UXがなかった」ということです。

なぜエンタープライズのUXはコンシューマー向けに比べて遅れているのだろう

白石: コンシューマー向けのWebサイトやアプリのUXは、この数年で本当に良くなってきましたよね。それは、言ってしまえばUXがサービスの売上に少なからず影響を与える…という意識が根付いたからだと思うんです。エンタープライズにおいては、そういう意識の変化は出てきていますか？例えば、「UXが業務の生産性を上げる」とか。

新谷: エンタープライズだと、UXの改善がもたらす影響についてのわかりやすい指標があまりないので、どうしても投資の優先度が落ちちゃうんですよね。UXの改善が、わかりやすく結果に結びつくといいんですけど。「オフィスデザインにこだわったらメディアに取り上げられた」みたいな、「褒められた」という経験でもいい。

齋藤: UX改善の結果がわかりやすいっていう話でいうと、パソナさんの事例があります。これ事例として紹介してくれていいと言われてるんですけど、システムに対して年間3,000件の問い合わせがあったのが、ぼくらが手を入れたあとはゼロになったんです。

白石: それはすごい！そのことによって削減される問い合わせコストもバカにならなそう。

齋藤: そうでしょう？何をしたかっていうと、よくある問い合わせを全部UIに仕込んじゃったんです(笑)。

白石: それはわかりやすい話ですね(笑)。

齋藤: 問い合わせの結果を分析して、「次に何をしたらいいかをわかりやすく記述する」とか、「エラーメッセージをわかりやすくする」とか、そういう努力を積み重ねた感じですね。

「UX的にイケてる」エンタープライズアプリって、どんな感じ？

白石: 具体的に「優れたUXを持つエンタープライズシステム」の例ってありますか？

齋藤: そうですね、二つ挙げられるんじゃないかな。

どちらも社内システムの話ですが、一つは従業員自らがUXの改善を行っていくという事例。もう一つは、その企業のコアコンピタンスを突き詰めるため、社内システムのUXを徹底的に改善したという先進的な事例です。

新谷: では、一つ目の事例は私の方からお話しましょう。

とある大きなメーカーの社内システムの構築を任されたのですが、そこの社員の方々にヒアリングすればするほど、どんどん要件が収集つかなくなっていくんです。ユーザーとなる従業員の数が多すぎて、ニーズがまとまりきらないんですね。一言で「社内システム」とは言うけれども、ユーザーそれぞれに話を聞いていくと、欲しがっているシステムが部門ごとに全く別ものだったりする。

そこで結局、MicrosoftのSharePointをプラットフォームとして導入することにしました。SharePointは非常に柔軟なシステムで、ユーザ自らがシステムに手を入れていくことができる。いわば、自分たちでUX改善を継続的に行っていけるようなものです。

齋藤: 私たちの会社だと、サイボウズのkintoneを使って、人事や総務の人たちが自らUIをこしらえたりしてます。こうした「フレキシビリティ」は、今後のエンタープライズシステムにおいてはとても重要になってくるでしょうね。

新谷: また、これらのサービスはクライアント技術としてHTML5が使われているというのも非常に重要です。HTMLやAjaxの知識があるなら、UIは自在に作っていける。データは一箇所に集約したまま、です。

齋藤: 二つ目の事例は、「ドモホルンリンクル」で有名な再春館製薬所さんのコールセンターシステムです。

コールセンターというのは、「同じ時間内で、どれだけ多くの問い合わせを捌くことができたか」が重視されるのが普通です。しかし再春館製薬所さんは、「お客様とどれだけ密なコミュニケーションをとれたか」が会社にとっての価値だと考えている。例えばコールセンターのオペレーターが、「最近お肌のトラブルはありませんか？」とか「お孫さんの誕生日もうすぐですね」とか、そういう話をお客様に向かってするわけです。 お客様としては、「あなたとお話したことないのに、なんでそんなことわかるの？」「私のことをどれだけ知ってくれているの？」という驚き、そして感動に繋がりますよね。

お客様にこういう体験を提供するために、コールセンターの画面 ― 再春館製薬所さんは「お客様」画面と呼んでいますが ― がどれだけ情報ポータルとして洗練されているか、その人自身を感じられるか、というところが彼らの課題だったのです。 かつ、オペレーションはミスなく、素早くこなせる必要がある。

そのために私たちは検討を重ねた結果、スクリーンを複数に分割した形のUIを採用しました。複数のお客様の情報を同時に表示して一覧性を確保しつつ、どれか一つの分割ビューにタッチすると素早く拡大表示される。再春館製薬所さんは「パネルウィンドウシステム」と呼んでいらっしゃいますが、私たちなりにカッコよく言うと、エキスパンド（拡大）型の「コックピットUI」です(笑)。

　　▲再春館製薬所コールセンターの画面「お客様画面」※写真提供：再春館製薬所

白石: ちょっと感動的なくらいの事例ですね。その話を伺って、以前エキスパートの竹洞さんにインタビューをした際に、「『自社が提供するサービスのユニークな価値とは何か？』という問いに対する答えを持たなければ、真のUX改善は望めない」とお聞きしたのを思い出しました。

再春館製薬所さんにとっては、お客様との密なコミュニケーションこそが会社の中核的な価値であり、そこを突き詰めた結果が、そうしたコールセンターのUI構築につながったんですね。あらゆる企業が自社のコアコンピタンスを自覚して、それを元に業務アプリのUXを改善していく…というのが理想なんでしょうね。

齋藤: その通りです。ただ、これは業務アプリとしては相当レベルの高い例ですよね。残念ながら世の中には、UXへの配慮が足りていない業務アプリも沢山ある。まずは、そうしたアプリを「普通」のレベルに持っていくのが大事かな、と。

白石: それは、「地に足のついた議論」って感じでいいですね(笑)。

齋藤: まずは「普通」を目指さないと。「事故がないオフィス」とか「事故がない厨房」とか、言うまでもなくあたりまえじゃないですか(笑)。それと一緒ですよ。

新谷: そうそう。まずは普通を達成して、その後初めて、CI (Corporate Identity) に基いてUXを向上…とかって話になるんですよね。

まとめのひとこと

白石: いやー、まだ聞き足りないことがたくさんあるんですが、お時間がきてしまいました。特に、「UXがエンタープライズ開発をどう変えるか」とかは、お聞きしたかった…。

齋藤: ぼくらだって、全然話し足りないですよ！
今回は、全5回のうちの1回目ってところじゃないですか(笑)。

白石: ぜひまたお話を伺いに来たいです！では最後に、今回のテーマである「エンタープライズとUX」について、一言いただけますでしょうか。

齋藤: 「エンタープライズアプリにUXは必要か？」なんて、ぼくから言わせると「何をいまさら」って感じです。むしろ、エンタープライズだからこそUXでしょ？と。企業は人材こそ命でしょ？従業員あってこその企業でしょ？

従業員に建付けの悪い椅子とかあてがってたら、みんな腰痛で会社来なくなっちゃうよ、と(笑)。いい椅子買おうよ、と。エンタープライズアプリのUXに配慮するというのは、そういうことです。ぼくは、業務システムのUX改善は、福利厚生の一つだとすら考えてますから。

新谷: 私は、エンタープライズのUXがなかなか改善されないのは、UXという言葉や技術に対して「食わず嫌い」する姿勢も原因の一つだと思ってるんですよね。難しく考え過ぎているところがあるんじゃないかと思うんです。

特に最近はSharePointやkintoneなど、ものすごく手軽にUIを修正したり構築したりする環境が整ってきているのに、結局それを外のSIerに発注したりしてしまう。すると、せっかくUXを自分たちで改善していける環境があり、流れも来ているのに、台なしになってしまう。難しく考えずに、自分たちの使っているアプリがどうやったらもう少し使いやすいかを考えて、実際に自分たちで改善していく。そういう流れを作っていけたらなあ…と思っています。

白石: おふたりともお忙しい中、インタビューにお時間を割いてくださって、本当にありがとうございました！とても楽しくてためになる時間でした。