2012. 2.23 リコーITソリューションズ 晴海アイランド トリトンスクエア
AITC 2011年度 第3回「ユーザーエクスペリエンス技術部会」＆「ネットデバイスアプリケーション部会」
招待セミナー1

モバイルアプリ開発と軽量型開発プロセスCYCLONEの適用事例
クラスメソッド株式会社 マーケティングチーム
マーケティングマネージャー
認定スクラムプロダクトオーナー

嵩原 將志
タケハラ マサシ (Tw:@take3000)

自己紹介
タケハラ マサシ

嵩原 將志
Takehara Masashi

TwitterID:@take3000
Blog「たけはらですが」
http://slideshare.net/takelog3000
http://design.classmethod.jp/

Marketing/Procurement/Project Management/Agile(Scrum)/RIA/UX Design

認定スクラムプロダクトオーナー
FxUG(TOKYO)
DevLOVE
職人(LT,KPT,釣り)ADK48/ナナナナ会
デスブロガー/雨男−−執筆−−「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」−−Web記事−−・達人ライトニングトーカーへの道（＠IT自分戦略研究所）：連載
・Flashは死んでしまうのか？
（Codezine）

スクラムについて簡単に説明

http://www.ryuzee.com/contents/blog/3629

プロダクトオーナー製品に対して責任をもち機能に優先順位を付ける

スクラムマスターチーム (6±3人)

スクラムプロセスがうまくいくようにする。
外部からチームを守るプロダクトの開発を行う。
製品の成功に向けて最大限の努力をコミットする

ステークホルダー
製品の利用者、出資者、管理職などの利害関係者。鶏と称す

デイリースクラム

プロダクトバックログ
製品の機能をストーリー形式で記載
プロダクトオーナーが優先順位を付け、プランニングポーカーで相対見積もり。
項目の追加はいつでも自由だが実施有無や優先順位はPOが決める。

毎日チームが以下の３つの質問に答える
・昨日やったこと・今日やること
・困っていること

バーンダウンチャート

Doneの定義

スプリントタスクの「推定残り時間」を更新してグラフにプロットする

何をもって「完了」とするかを定義したリスト

スプリント計画会議

スプリント

プロダクトバックログを再度分析・評価し、そのスプリントで開発するプロダクトバックログアイテムを選択する。また選択した項目をタスクにばらす

最大4週間までのタイムボックス
各スプリントの長さは同一。この間は外部からの変更を受け入れない

タスク
時間で見積もり毎日の繰り返しスプリントバックログ

スプリントレビュー

そのスプリント期間中に行うタスクのリスト

スプリント中の成果である
動作するソフトウェアをデモする

ふりかえりスプリントの中での改善事項
を話合い次に繋げる

出荷可能な製品の増分

複数回
ス
プ
リン
トを繰り
返す

94. タケハラマサシが誰かに何かを伝えたい人にオススメしたい1冊

お近くの書店かかでお買い求めくださいhttp://classmethod.jp/service/voucher/アジェンダ1. 最近の開発
 コストの下げ傾向
 短期間の開発
 技術的な選択肢の増大
 UXデザインへのニーズと普及 ビジネスモデルと向きあう

2. 事例紹介
3. サイクロン4. まとめソフトウェアのコストのダウン
トレンド

http://www.senyo.co.jp/cosmo/attraction/img/002-1.jpg

2008.9.15 リーマンショック
http://img4.blogs.yahoo.co.jp/ybi/1/95/00/mitumusshi/folder/473696/img_473696_20301212_4?1307005819

プロジェクト
規模縮小による開発チーム縮小

短納期のプレッシャー

早くサービスを開始することで先行者優位をつくりだしたい。

業務システムでも「すぐ結果を求める」
傾向が強い（というか実験的なものが多いので、芽が出るかダメそうかはさっさと判断したい）

技術の選択肢増大3ヶ月ほど前にTwitterのタイムラインを蹂躙したとある画像

「それHTML5で出来るよ」とそそのかされた照英が泣きながらFlashで実装し直す画像ください

Flashが、HTML5が、に限らず特性を理解しないで採用すると当然ハマるマルチデバイス対応

マルチデバイスを・同じように使う？
・デバイスの特性を活かす？

テクノロジーの進化が早い

http://k-s-psobb.way-nifty.com/pso/2005/06/index.html

Androidのアップデート

短納期ゆえに技術選定が今まで以上に重要。

① 移植容易性② 開発生産性（向き不向き）③ テスト（環境種類別）④ 技術習得難易度⑤ 技術者数⑥ 開発期間＋稼働期間

プロダクト開発のサイクル
ストーリー

開発のサイクル
タスク サブタスク

出荷可能な(利用可能)なプロダクト

間延びしたプロダクト開発のサイクル

更に分割された
サブタスク

ストーリー
タスク

サブタスク

開発のサイクル

出荷可能な(利用可能)なプロダクト

採用した技術によっては必要以上のタスク分割が発生し、リリースのスピードを下げてしまう。

ユーザーの満足（と不満足）ユーザエクスペリエンスデザイン

ユーザの知覚と振る舞いに影響を与えることを目的とし、特定の企業に対するユーザの体験に影響する要素を創造しシンクロさせること、である
ＵＸデザインプロジェクトガイド「優れたユーザエクスペリエンスを実現するために」「スペック」が良いではなく「人」にとって「良い」体験をつくるユーザエクスペリエンスデザイン

３つの理由① 「本質的な価値」の可視化
ユーザーの目的と潜在的な要求に注目し、魅力的なフィーチャを設計する。

ユーザー調査ペルソナ

ストーリーボード

ユーザーの感情（喜び）を設計する

② ユーザーと密接になれる「技術的な制約はいったん置いておく」ので、ユーザーの要求に対してフラットな姿勢で望める。

技術的制約 ＜ ユーザー要求

③ ＲＯＩへの貢献
適切に取り組めば確実に結果がでることは実証されている。

Microsoft PROJECT UX より

http://www.microsoft.com/japan/powerpro/projectux/activity/roi.mspx

Suica 改札機の読み取り角度は13.5度傾いている。

「本当に使える」
かどうかはやってみなければわからない

・どのような場所で使うのか？
・利用者は誰か？
・使い慣れているのか？
・片手で使うのか？
両手で使うのか？

 屋外で使うなら色調を強くしなければ視認性を損なう
 片手で使うならコントロールは画面下部に寄せる
 環境によっては情報の取り方も考える

組織の収益 ＞ ユーザーの満足

http://www.kabegamilink.com/act/0802/04442x.html

ビジネスモデルとデザイン

ライフスタイルを変える（ワークスタイルを変える）

アウトプット
↓
アウトカム
↓
インパクト

事例

世界初！
SAP ERP × AIR for iOS × AWS2012/01/18

Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓ Ｆｒａｍｅｗｏｒｋｆｏｒ Ｍｏｂｉｌｅ Ａｐｐｓ (ver 1.0)
サイクロン・ワーキング・グループ

サイクロンは（コミュニケーション）プロ
セス・フレームワークである。いくつかの原則（Principle）を基礎に構成されている。
クラスメソッド株式会社において実践されてきたプラクティス類を体系立て、他の人や組織でも利用可能にすることを目的としている。尚、体系化にあたりスクラムの用語と考え方を参考にしている。適用するプロ
ジェクトは軽量なアプリケーションをターゲットとしている。

サイクロンロゴ アジャイル開発が普及し、開発プロジェクトはやりやすくなったが、肝心のプロダクトやビジネスをどう考えるかがイマイチ。
 市場と技術の変化のスピードが早すぎて、サービスをリリースする頃には時代遅れになることがざら。とくに技術面での追従が困難になっている。
 ビジネスの成功と、技術的な妥当性も重要だが、利用者の満足も重要。利用品質の低下は即サービス終了を意味する。

 利用者にとっての満足 適切な技術の利用
 ビジネスの成功
個別に考えられることが多く、それぞれに最適化を図ると、作業が段階的になり、スピードが損なわれるスクラムについて簡単に説明
ここを考えるのがものすごく難しい

http://www.ryuzee.com/contents/blog/3629

？
DISCOVERYストーリー

開発のサイクル
タスク サブタスク

DELIVERY

出荷可能な(利用可能)なプロダクト

プロダクトオーナー

コーディネーター
デザイナー

エンジニア

サイクロンチーム
３＋１の視点実装してほしい要求がある①要求のリストを渡す

要求が正しい前提で作る（例）よくある話

実装してほしい要求がある①要求のリストを渡す②要件定義書を作る

要求が正しい前提で作る（例）よくある話

細かく書いてあるけ
ど、これが欲しかった
んだっけ…？

③要件定義書をレビューする
実装してほしい要求がある①要求のリストを渡す②要件定義書を作る

要求が正しい前提で作る（例）よくある話

弊社の購買と法務がチェックするので体裁を直して下さい③要件定義書をレビューする
実装してほしい要求がある①要求のリストを渡す②要件定義書を作る④ツッコミを入れる

要求が正しい前提で作る（例）よくある話

弊社の購買と法務がチェックするので体裁を直して下さい③要件定義書をレビューする
実装してほしい要求がある①要求のリストを渡す②要件定義書を作る④ツッコミを入れる⑤承諾

はいわかりました。
ちゃんと読んだのかなあ…？

（例）よくある話

要求が正しい前提で作る

要求仕様書や要件定義書でコミュニケーションをしている、これを作っている間にアイデアの大事な部分が逃げてしまう(あるいは冷めてしまう)〜私たちが抱えている課題〜
・細かいところまで詰める
時間はない
・要件定義に半年、一年もかけてられない（その間にニーズが変化する）
・テクノロジーの進化が早すぎて、時間をかけすぎると陳腐化してしまう

対処法
・要求を整理する・要求を元に、画面デザインを行う。必要なら人の動線も含めてシナリオを描く
・実装可能か調査をする
サンプルプログラムを構築し選定技術の比較をする
・この活動を繰り返す

（提案）考え直す実装してほしい要求がある

要求が正しい前提で作る①いきなりこの二者で話をしない「ビジネスの専門家」に専門外の技術文書を書かせたり読ませたりしている時点で重大な無駄を発生させている

課題をもっている②現実を認める（要求は固まってない）よくあるパターン・◯◯までに何かやらないといけない
・予算は◯◯ぐらいで決まっている（開示されるとは限らない）
・実現できて上手く行きそうなアイデアがほしい昔と違って、あらゆることが複雑で多くの選択肢をもつようになった。情報化すれば結果が必ずでるような単純な世の中ではない。

課題をもっているあるべき姿を描ける③視覚化をして認識の共有を徹底する

③視覚化をして認識を共有を徹底する・ストーリーボード（シナリオ）
・ユーザー調査・ペルソナ分析・デザインラフ（コンセプト）
・ワイヤーフレーム・ペーパープロトタイピング※都度、適したツールを選んで使う

ストーリーボード

ペルソナ

ユーザー調査ドキュメントの体裁より全員がゴールを正しく認識できること

課題をもっているあるべき姿を描けるあるべき姿をを作れる④「あるべき姿」の実現方法を考える

④「あるべき姿」の実現方法を考える
制約（コスト・期間）の下で、実現できる方法を考える。場合によっては、ＩＴの専門家としてより良い解決方法を提案する。

課題をもっているあるべき姿を描けるあるべき姿をを作れる⑤見通しを確認し投資に値するか検討⑤見通しを確認し投資に値するか検討
システムにプロダクト（サービスやアプリケーション）を組み込んだ時、それがユーザーに対してどのようなインパクトを与えられるのかを再度考える。

課題をもっているあるべき姿を描けるあるべき姿をを作れる⑥このサイクルを繰り返す(一定期間)

⑥このサイクルを繰り返す(一定期間)
・本当に役立つのか？を問い続ける
・本当に役立つ状態を模索し続ける課題をもっている

ファシリテートするあるべき姿を描ける⑦サイクルを軌道に乗せるあるべき姿をを作れる

⑥サイクルを軌道に乗せる
通常、オーナー(発注者)は忙しく、デザイナ／技術者と頻繁なコミュニケーションをとることが難しい。
ここにファシリテーターを入れることで調整役とオーナーの代弁者を兼ねることで、サイクルのスピードを下げないようにする。

課題をもっている

ファシリテートするあるべき姿を描けるあるべき姿をを作れる

プロダクトオーナー

コーディネーター
デザイナー

エンジニア

サイクロンチーム

プロダクトオーナーの専門アクティビティ
課題をもっている

共通のアクティビティ
ファシリテートするあるべき姿を描ける

デザイナーの専門アクティビティ

あるべき姿をを作れる

エンジニアの専門アクティビティ

プロダクトオーナーの専門アクティビティ

問題の提起
課題を事業化への組織内調整もっている事業領域における法令の確認

共通のアクティビティ
ファシリテートするあるべき姿を描ける

デザイナーの専門アクティビティ

あるべき姿をを作れる

エンジニアの専門アクティビティ

プロダクトオーナーの専門アクティビティ
課題をもっている

共通のアクティビティ
ファシリテートする

デザインコンセプト提案
あるべき姿をあるべき姿をインフォメーションアーキテクチャ
描けるを作れる
インタラクションデザイン
デザイナーの専門アクティビティ

エンジニアの専門アクティビティ

プロダクトオーナーの専門アクティビティ
課題をもっている

共通のアクティビティ
ファシリテートするあるべき姿を描ける

デザイナーの専門アクティビティ

実装方式の提案
あるべき姿をフィージビリティスタディ
を作れる
プロジェクトマネジメント計画
エンジニアの専門アクティビティ

ビジネスゴールの設定
プロダクトオーナーの専門アクティビティ
ゴールの認識を共有する
ペルソナ作成課題をストーリーマッピング
もっている
プロダクトバックログの作成
妥当性の検証
共通のアクティビティ
ファシリテートするあるべき姿を描ける

デザイナーの専門アクティビティ

あるべき姿をを作れる

エンジニアの専門アクティビティ

http://books.shoeisha.co.jp/book/b94967.html

ビジネスモデルキャンバス
KP

KA

VP

CR

パートナー

主要活動

価値提案

顧客との関係 顧客セグメント

KRCH

リソース

チャネル

CSRS

コスト構造

収益の流れCSCopyright©2010 by Alexander Osterwalder All Right Reserved.

プロダクトオーナーの専門アクティビティ
課題をもっている

共通のアクティビティ
ファシリテートするあるべき姿を描けるあるべき姿をを作れる

２種類のアクティビティ

デザイナーの専門アクティビティ

エンジニアの専門アクティビティ

プロダクトオーナーの専門アクティビティ
課題をもっている

共通のアクティビティ
ファシリテートするあるべき姿を描ける

デザイナーの専門アクティビティ

あるべき姿をを作れる

エンジニアの専門アクティビティ

大切なことは
1. 「本当に使える」のか？
2. 現実的な期間とコストの範疇で実現できるのか？

明確なゴール設定と効率的な開発チーム

生産性を上げる2つの方法

1.熟練度を上げる
2.やり方を変える2012/01/18

Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓ Ｆｒａｍｅｗｏｒｋｆｏｒ Ｍｏｂｉｌｅ Ａｐｐｓ (ver 1.0)
サイクロン・ワーキング・グループ

・個々のツールや技法は普通・CYCLONEはそれらを体系化し、誰でもはじめやすいようにしている

このサイクルを効果的に回すには経験と、これを良しとする組織の文化が必要 プロジェクト初期段階の無駄を排除し本質に踏み込むこと
 体裁にとらわれ過ぎな要件定
義のあり方を変えること
 受託システム開発の会社が、これまで以上にお客様のビジネスの成功に寄与すること
 １日でも早く「本当に役立つ」システムを届けることご清聴ありがとうございました

お問い合わせはこちらまで
info@classmethod.jp