高品質プロダクトを作るためのワークフローについてのトークで使用したものです。

1. 高品質なプロダクトを
作り出すワークフロー
Shingo Suzuki
January 31, 2018

2. 自己紹介
古本屋スタッフ、レコードショップスタッフなどを経験したのち、出版社での編集者兼デザイナーとしての
仕事を通して、本格的にデザイン関係の道に進む。その後、数カ所のデザイン事務所に所属、企業のイン
ハウスデザイナーとしての仕事も経験する。
グラフィックデザイナーとしてエンタメ系広告やグルメカタログなどのデザインを担当、その後オンライン
ゲームやソーシャルカードゲームのアートディレクター職も経験する。UI/UXデザイナーとしてはミュージッ
クプレイヤーアプリ／カラオケアプリ／メッセンジャーアプリ、CRMシステムなどを担当。
鈴木真悟
Shingo Suzuki
Eclipse Lab
UI/UX Designer,Director

3. Menu
ⅰ プロダクトの品質とUXの関係
ⅱ 開発手法と評価・テスト
ⅲ 開発体制
ⅳ プロジェクトの先導者
ⅴ 失敗の実例とまとめ

4. ⅰ プロダクトの品質とUXの関係

5. プロダクトとは
一般的には企業などが顧客に販売する製品の
ことを指し、これにはソフトウェアやデータなど
物理的実体のない無体物も含まれる。
工業製品 ソフトウェア Webサービス データ

6. 品質とは
「品質」とは、品物またはサービスが、使用目
的を満たしているかどうかを決定するための評
価の対象となる固有の性質・性能の全体（JIS
による定義）
つまり、品物やサービスの顧客からの要求事項
や、ニーズに合っているかを決める特性。
（参考：品質管理の知識http://www.sk-quality.com/quality/qc03_quality.html）

7. UXとは
UXは ユ ー ザ ー エ ク ス ペ リ エ ン ス（User
Experience）の略
UXとは「ユーザーが製品・サービスを通じて
得られる体験」

8. Intuitのサービスデザイナーである
Erik Flowersによる概念図
テクノロジー、ビジネス、デザインの重なる領域にUXがある。
UXベン図（３つの円）

9. 品質とUXデザイン
プロダクトは使用し「経験」するもの。つまり
顧客満足度の高い、高品質なプロダクトを作り
出すには、ビジネス・テクノロジー・デザイン
のすべての視点が不可欠。

10. デザインの意味に対する誤解
デザインとアートいう言葉の意味は混同されて
いることが多い。
また、デザインとは単純に見た目の印象を良く
する作業と誤解している人も多い。そのため、
デザイナーが、クライアントやディレクターから
オペレーターのように扱われるケースも多い。

11. ロードマップ作成や
IA（情報アーキテクチャ・情報設計）も
デザインの領域であり、
単純に見た目を整えたり、
装飾を加えたりすることだけが
デザインではない。

12. デザインの定義
デザインは、ユニークな期待に答えるための
ロードマップまたは戦略的アプローチです。そ
の目的を達成するために、法的、政治的、社
会的、環境的な安全/経済制約の中で何をど
のようにするべきか、また、仕様や計画、パラ
メーター、コスト、活動、プロセスを定義します。
（Don Kumaragamage）

13. QA（品質保証）とは
QAとは、Quality Asuuranceの略で「品質保
証」と訳されます。一般にお客様に対して製
品の性能や機能を保証することを指す言葉で
す。～中略～ QAには合格基準を定義したり、
どのような検査で合否判定するかというプロセ
スを決めることも含まれます。
（参考：SI Object Browser PM https://products.sint.co.jp/obpm/blog/serial-umeda15）

14. 源流管理の重要性
「源流管理」とは、「お客様に喜ばれる商品や
サービスの品質を明らかにして、仕事の仕組み
の源流、または担当業務の源流にさかのぼっ
て、品質やサービスの機能や原因を掘り下げ、
源流を管理していくこと」である。
（日本財団図書館）

15. 例えば、
ビジネスの場合は事業戦略、ターゲットやペル
ソナの設定
テクノロジーの場合は開発環境やサーバプラン
デザインの場合は情報設計（IA）、デザイン仕
様（UIパターンなど）
など…

16. 上流工程での決定事項に従い、開発が進行する。
これらの上流（源流）に大きな問題を抱えたまま
開発が進行すると、下流工程で問題が発覚した
場合、解決に必要なコスト（時間・予算）が
肥大してしまう。
問題を応急処置ではなく、根本から解決するた
めに、源流管理という考え方は非常に重要。

17. ⅱ開発手法と評価・テスト

18. https://blog.ganttpro.com/en/waterfall-vs-agile-with-advantages-and-disadvantages/
ウォーターフォールとアジャイル
アジャイル開発とウォーターフォール開発という
方法論の対立については様々な議論がある。

19. ウォーターフォール・モデルでは、開発プロジェ
クトを時系列に、「要求定義」「外部設計（概
要設計）」「内部設計（詳細設計）」「開発（プ
ログラミング）」「テスト」「運用」などの作業
工程（局面、フェーズ）にトップダウンで分割
する。

20. アジャイルソフトウェア開発手法の多くは、反
復 (イテレーション) と呼ばれる短い期間単位を
採用することで、リスクを最小化しようとしてい
る。1つの反復の期間は、プロジェクトごとに
異なるが、1週間から4週間くらいであることが
多い。開発対象を多数の小さな機能に分割し、
1つの反復 (イテレーション) で1つの機能を開
発する（⇒反復型開発）。

21. どちらにもメリットとデメリットがあり、
組み合わせて使用されているケースも多い。
重要なのは、どのような開発手法を
採用したとしても、上流工程（主に企画／要件
定義／設計／開発の初期段階）で
評価・テストのフェーズを設けること。

22. 評価・テスト手法の例
手法は無数に存在する。いくつかのわかりやす
い例を紹介。
1. VSPROモデル
2. ISO/IEC 9126
3. ヒューリスティック評価

23. ビジネスの評価法例
『VSPROモデル』
ビジョン（V）、戦略（S）、プロセス（P）、リソー
ス（R）、組織（O）の5点を検討することで、
現時点での問題点、あるべき姿を明らかにする。
ビジョン（V） どのようなビジョンを掲げているか？
目指すビジョンは適切か？
戦略（S） ビジョンに沿った戦略になっているか？
競合と差別化できる戦略になっているか？
プロセス（P） 戦略を実行するプロセスはどうなっているか？
そのプロセスはビジョンとの整合がとれているか？
評価の例（VSPROモデルについて解説 http://www.nsspirit-cashf.com/manage/vspro.html）
リソース（R） 戦略・プロセスを実行できるリソースは十分か？
（十分な資金、十分な設備、能力の高い従業員）
組織（O） 戦略・プロセスを実行できる組織になっているか？
従業員はビジョンや戦略を腹に落としているか？
中間管理職は従業員を動機づけられるか？

24. テクノロジー（システム）の評価法例
『ISO/IEC 9126』
ISO/IEC 9126 は、ソフトウェア品質の評価に関
する国際規格。
システムを評価する６つの観点
機能性（functionality）- 機能とその特性に影響する特性群。機能には、必要性を明確に述べているものと、
暗に示しているものがある。
信頼性（reliability）- ある状況がある時間続いたときにソフトウェアがどの程度機能するかに影響する特性群。
使用性（usability）- 利用するのにかかる手間、個人の努力などに影響する特性群。
効率性（efficiency）-ソフトウェアの性能やそれに要するリソース量に影響する特性群。
保守性（maintainability）- 何らかの変更を加えるのにかかる手間に影響する特性群。
移植性（portability）- 別の環境にソフトウェアを移行させる可能性に影響する特性群。

25. 評価する10の観点
デザインの評価法例
『ヒューリスティック評価』
ヒューリスティック評価とは、経験則（ヒュー
リスティックス）に基づいてユーザビリティを評
価し、UI上の問題を発見する手法。
システム状態の認知度
システムと実世界の調和
ユーザーの主導権と自由度
一貫性と標準化
エラーの予防
再生より再認
柔軟性と効率性
美的で最小限のデザイン
ユーザーによるエラーの認識・診断・回復のサポート
ヘルプとドキュメンテーション

26. 改善サイクル
プロダクトのリリース前の評価は、必ずしも予
測通りの結果へ導くとは限らない。
リリースしてからのフィードバックではじめて判
明する問題もある。
問題の原因の仮説を立て、解決に至るまで繰
り返し改善に取り組むことが、品質向上につな
がる。

27. 仮説の構築と検証をくり返す改善手法としては
● PDCAサイクル
●リーンスタートアップ
● DMAIC（シックス・シグマ）
などが主流。

28. ⅲ開発体制

29. UXデザイナー深津貴之氏が語った、悪いUIが作られる背景
「そもそも悪いUIの指示が現場に降ってくるのは、企画にUIデザイナーが入っていないか
らです。つまり「これ決まったからやっておいて」と上から降ってきた時点でもう既に手遅
れなんです。そうなってしまったら、どんなにおかしいと思っても基本的に現場から変える
のは無理だと思います。
まず企画チームの中にUIデザイナーがいるべきだし、いない場合にもマネージャーなり
ディレクターなり意志決定できる立場の人が、UIの善し悪しをジャッジできるだけの知見
を持っていないといけません。UIの善し悪しの基本的な基準は、スマホアプリならApple
とGoogleが、それぞれiOSとAndroid用に正しいインターフェイスのガイドラインを公開
しています。それらを読んでその通りにすればいいのですが、経営指標にデザインが入っ
ていないので、まず会社の上層部がガイドラインを理解してないんですね」
（UXデザイナー深津貴之が語る身も蓋もない組織論!?「ユーザー目線のない会社からは逃げるし
かない」「それでもそこでがんばりたいなら……」http://hrnabi.com/2017/12/20/15839/）

30. （参考：経験から感じるWebディレクターとプロジェクトマネージャーの違いについて考えてみた
https://liginc.co.jp/347990）
上流工程の役職者に求められる職能
「ディレクションには演出や指揮、方向といった
より導く役割があるように思えます。PMはプロ
ジェクトの管理をおこない、ディレクターは指
揮を執っていくイメージが浮かびます」

31. （参考：4社のトップディレクターが語る、ディレクターの役割とディレクション術 ー UX生トーク
vol.6 Director’ s Night！https://developers.cyberagent.co.jp/blog/archives/9762/）
ディレクターに求められるスキルの例
『Ameba Ownd』担当ディレクターのチームで設定している、ディレク
ターの6つのスキル
1.設計力
2.技術理解力
3.プロジェクトマネジメント
4.品質管理力
5.運用力
6.企画力

32. 上流工程の役職者に知見（デザインのセオリー
／マネジメント／品質評価手法、など）がない
分野があれば、上流工程からデザイナーや
品質保証など、適宜個別にスペシャリストが
コミットする必要がある。
高品質を追求するためには、いずれの工程でも、
スペシャリストの知見・存在が求められる。

33. ⅳ プロジェクトの先導者

34. （アップルが成功した理由は「なぜ」を示したから‒ サイモン・シネック氏が語る、まず “ビジョン”
を考えることの重要性 http://logmi.jp/13519）
※サイモン・シネック氏は、「人々をインスパイアする方法」を伝授するコンサルタント。アメリカ
連邦議会議員、外交官、国連、国防総省、マイクロソフト、アメリカン・エキスプレスなどで方
法を伝授してきた。
「なぜ」を示す、ゴールデンサークル理論
提唱者、サイモン・シネック氏の説明
「なぜ」を示したときに人は動くのです。「何を」
ではありません。
アップルが成功した理由は「なぜ」を示したから。

35. Why（な ぜ）How（どうやって）What（何 を）
の順＝ゴールデンサークル

36. アップルの伝え方
私達は世界を変えられると信じています。（Why）
そして常に既存の考え方とは違う考え方をします。
（How）
世界を変えるために美しいデザインかつ機能性に優
れた製品を世に送り出そうと努力するうちに、
このような製品ができあがりました。（What）
おひとついかがでしょうか？

37. 大脳辺縁系の層（人の行動、意思決定をコント
ロール）⇒「Why（なぜ）」「How（どうやって）」
大脳新皮質の層（分析的思考と言語を司る）⇒
「What（何を）」
に対応している。

38. 「 なぜ？ どうやって？ 何を？ という風にコ
ミュニケーションを取る時、私達は行動をコントロー
ルする脳の真ん中に直接働きかけることになるので
す。行動を司る部分に働きかけられる、すると人は
自分の行動を合理的に後から考えることになるので
す」
「先導者になれるのは なぜ？ から物事を始めるこ
とができる人」

39. プロジェクトの先導者（上流工程の役職者）は
「なぜ」を示すことで、
プロジェクトを円滑に進めやすくなる。

40. ⅴ 失敗の実例とまとめ

41. 実例その1
オンラインゲームのローンチの時点では外部の開発会社に開発を
委託していたが、コスト削減のため、社長が社内に開発部を設立。
しかし、開発に必要な技術や人員に関する知見もなく、突然全て
の開発を内製化したため、開発スピードは大幅にダウンし、品
質も著しく低下した。
→事業計画の評価のプロセスがなかった。モデルの則った評価
がなされていれば、段階的な内製化などの選択も考えられたか
もしれない。

42. 実例その2
ディレクターが、スマートフォンアプリのタブレット対応の開発を
計画。プロトタイピングが終わり、モック作成まで終えた時点で、
改めて開発予算を見直したところ、当初の計画の予算をはるか
にオーバーしていることが発覚。開発は中止となった。
→要件定義の時点で開発予算のある程度正確な見積もりは可能
だったにも関わらず、画面デザインまで進行してから見積もりの
間違いに気付いた。評価のプロセスがなかった。実装の工程に
まで入っていたため、それまでに費やした予算は水の泡となった。

43. 実例その3
ディレクターが、デザイナーを開発チームに入れない体制で、スマー
トフォンアプリのUIリニューアルを実行。リリース後、ストアでの
アプリの評価欄へは、UIに対するクレームが多く書き込まれた。
→ディレクターにデザインに関する知見もなく、またテストや評価
の手順も踏まずにリリースしてしまった。開発チームの中に、デザ
インや品質保証の知見のある人物が含まれていれば、このような
結果にはならなかったのではないだろうか。

44. まとめ
1.上流工程で評価やテストを実施すれば、下流工程での問題発
生の可能性を下げることができる。
2.適切なUXデザインは、高品質なプロダクトを作り出すために
必要不可欠な要素。
3.上流工程の役職者に充分な知見がない分野があれば、その分
野のスペシャリストがコミットするべき。
4.上流工程の役職者は「なぜ」を示すことで、関係者とのコミュ
ニケーションを円滑にすることができる。