ビジュアルファシリテーターの阿呆な研究

Read Article

ユーザー中心デザインの導入vs納期 -仁義なき戦い-

新年あけましておめでとうございます。
11月から恐るべき忙しさとなり、ブログを書くのが久しぶりとなってしまいました。
本年もゆっくりしたペースではありますが、更新してゆく所存です。

さてさて。11月からなんで忙しくなってしまったかというと。
担当するプロジェクトが変わり、販促とUI設計半々くらいだったのが、UX&UI設計がメインとなったというのが大きな理由だったりする。

11月まで、私は販促のかたわら、開発系プロジェクトでの簡単なUI設計、スマホサイトのUI改善全般をやっていた。そのプロジェクトが11月中旬に落ち着くや否や、UX&UI設計が相当必要なプロジェクトに参加することになった。社運をかけたそのプロジェクトにコミットできるのは有難いこと。抜擢してくれた上司達に心底感謝した。特にUX分野についてより予算と権限をもって経験を積むよい機会になる・・・ユーザー中心デザインを本格的にできる!と思ってワクワクしていたのだ

しかし、世の中は甘くなかった。
ユーザー中心デザインを考えようにも、時間も予算もなかったのである。
というわけで、年始早々、ユーザー中心デザインの導入 vs 納期 の戦い(葛藤)に明け暮れていた昨年年末の私の状況について記したいと思う。

ユーザー中心デザインの敵:迫る納期、足りない工数(そして予算)

工数が足りなくても、戦わざるをえない理由

まずびっくりしたのは、UXに関われる案件で、ユーザーインタビューとかして考えたいと思ったら、突如ワイヤーフレーム書かなきゃ納期に間に合わない状態だったこと。

ユーザー中心デザインを実施するには、まずはチームでユーザーインタビュー(コンテクスチュアル・インクワイリアリー)、ユーザー体験シナリオ作成、ペルソナ作成・・・というフローが基本だと思われる。でもそんなのやってる時間がない!!
excelでひいたプロジェクトのスケジュールは、線が多すぎて意味不明。既存の工数だけでは足りない。しかも後輩達に引き継がねばならない案件も大量。直属の上司にそのスケジュールと引き継ぎリストをみせたところ、上司が一言「できる気がしない」。漂う絶望感。

「いいプロジェクトにしたいなら、きちんと工数をとるべき!」という理想論はいくらでもいえる。というか声が枯れるくらい今までだって叫んできた。
でも反面、販促に関わる中で、そうも叫んでられない事情もあると痛感していた。理由は、自社の事業内容がより「納期命」だからという点につきる。

納期命の理由1:扱う商材の都合上

私が関わっているのは、旅行系ECサイトだ。制作会社時代からいくつかのECサイトにかかわってきたけど、特に旅行は繁忙期と閑散期の差が顕著だと感じた。旅行の繁忙期は年3回=年末年始、GW、夏休み。そのような繁忙期の前以外は、連休や学生の春休みのようなちょっとした盛り上がりはあれど、閑散期が続きがちとなる。閑散期と繁忙期の差がとても顕著な業界なのだ。

また、旅行は得てして決済額が高額であり、リピートするにしても四半期〜一年に一回、という性質のものだ。デイリー、週単位での頻繁なリピートは期待できない。したがって、繁忙期前から繁忙期、いかに早く検討中のユーザーを取り込むかが販促の鍵となる。(また、粗利は低いとはいえ、決済額が高額であればあるほど件数あたりの利益額も大きい。)

だからこそ、繁忙期のユーザーのとりこみは至上命題となる。ユーザーのとりこみの施策としてのサービス開発は、繁忙期前のリリースが必須となるのだ。
同じように、賃貸住宅や保険関係も閑散期と繁忙期の差が極端な傾向にある。そうした商材のサイトは、納期が厳しめになりがちなんだろうなあ。。。逆に、食料品、日用品、化粧品は消耗品だから、時期による売れ筋の変動はあれど、旅行や賃貸、保険ほどには閑散期と繁忙期で差がでないんじゃないかと思う。

納期命の理由2:開発工数確保

さらに納期がずらせない理由がもうひとつ。エンジニアさんの工数確保のため。私たちUI設計、制作の次行程にいるのはエンジニアさんなのだけど・・・エンジニアは人月単位でベンダーさん、もしくはシステム会社の方がアサインされるから、エンジニアさんへの納期をおくらす=エンジニアさんの着手がおくれ最初はすることがない、ともなりかねない。もちろん納期はそん工数の無駄遣いは当然リソース管理上NG。

———-

そんな状況から納期命の案件やってると、どこでユーザーの意見を聞く場を実施するかの判断が難しいと感じた。完成してからやってもなおせるところは微々たるものだし、初期のペルソナ構築のためのインタビューなんてやってる時間ないし。。と葛藤していた。

私が参加したプロジェクトでは、当然ユーザーインタビューの時間はなく、シナリオと主要画面のワイヤーフレームをまとめて5営業日程度で書き上げる。。。という状態。インタビューやったらユーザーのリクルーティングだけで終わるwwwww無理ゲーwwww

ついでに、自社は超有名大企業でもないから、予算だってそうふんだんにつくわけじゃない。「金がない分頭を使え」というシビアな状況におかれてる。ない頭をふりしぼって考えざるをえないのである。

ユーザー中心デザインをあきらめたくなる瞬間

でもまあ。私の経験は決して特殊な状況ではないんじゃないかなと思う。きっと、インタビューやシナリオ作成など、検討に十分な時間をもらえる案件よりも、そんなのやらないでいきなりアサインされる案件のほうが圧倒的に多いように思う。予算もしかり。

そこで「インタビューが必要です!」「シナリオ書いてペルソナ作るのに○営業日!」と平社員が叫んでも納期なんてのびやしない。ユーザー中心の立場をさけばなきゃいけない立場だけど、その立場をいったんおいて、今までの延長でそれっぽい実装さえさせればいいんじゃないかとさえ思った。

でも、そうして割り切ろうとするたびに「よりユーザーが使いやすい、価値ある何かを作らないと意味がない・・・」という気持ちがずっと頭の中から離れなかった。このもやもやをはらすきっかけが欲しくて、ユーザビリティやマーケティングに関する書籍を数冊買ってみたのだけど、仕事が忙しくて読み切れないまま年末年始休暇へ突入。ああ無情。

あまりに嫌な状況だったので、今年の年末年始は実家へ帰省せず、引きこもって本を読む時間を確保する決意を固めた次第である。まあ引きこもったら必ず何かが見えるわけじゃないんだけどね・・・

現実的なおとしどころ

そんな状況で私が選んだ書籍のうち、一冊がまさにどんぴしゃだったのでびっくりした。
ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック

現実的なUX品質担保のフローや具体的なテスト方法が記載されているのだが、なんといっても本書の特徴は、「現実的な落としどころがある」という点だった。
たとえば本書では、ユーザー調査ができなかった場合での対応について以下のように述べている。

ユーザー調査を全く行えないとすれば、設計チームのあてずっぽうで”架空”のペルソナを定義することは避けた方が無難です。その代わりに、”会話の中”で徐々にペルソナを形成していくのです。

設計チームが議論するときには、絶えず「どんなユーザー?」「そのユーザーの目的は?」「なぜそうする?」といった問いかけを行います。これによって、往々にして設計者が陥りがちな「自分がユーザーである」「自分はユーザーのことを知っている」という思いこみを排して、改めてユーザーのことを客観的、論理的に考えるようになります。

多少時間はかかりますが、これらの議論を通じてペルソナの姿が浮かび上がってくれば、設計チームは実質的にはペルソナを設定したのと同じような意志決定が行えるようになります。

実は、私は前のプロジェクトにおいて、ペルソナはまったく作っていなかった。にも関わらず、チーム内では主要メンバーはユーザー像を具体的に思い描くことができていた。ペルソナ設定をチーム内で仮説検証し常に共有できていたからだと思う。
そのプロジェクトは、既存ECサービスのスマホサイト運営だったので、私をはじめメンバーはまず自社の既存PCとモバイルサイトのユーザーを比べ、PCサイトとモバイルサイトの中間の性質をもつユーザーを仮想ユーザーとしてみたてた。

・PCよりは購入単価は下がる
・複雑な選択をともなう商品はうれづらい (セット販売でカテゴリAから一個、カテゴリBから一個選ぶとか。あと入力フォームの個数が多いとかもNG)
・女性がやや比率が高めとなる。
・「自力で探すのめんどいから電話する」という層が一定数はいる

など。
そしてサービス公開とともに、購入者のデータ、ログの解析を繰り返し行い、チーム内で結果をシェアし、ユーザー像を浮き彫りにしていった。サービスリリース前に考えたユーザー像、あたったものもあれば、大幅に外れた予測もあった。しかし、1年近くこのプロジェクトに関わってきた中で、CVRがどんどんあがって販売数も伸びてきた。エンジニアとUI設計者、そしてマーケターが同じユーザー像と問題をシェアしながら、うまくコミュニケーションをとり施策を実施してきたことにあると思う。まさに、ペルソナなくともペルソナが存在するかのようなプロジェクトだった。(自画自賛。笑。でも、本当に皆で議論しあえるよいプロジェクトだったのですよ〜。ありがたい。)

ユーザー中心デザインで大事なこと

大事なのは、「思い込みのユーザー像を各メンバーそれぞれ持つような事態にはせず、皆が具体的なユーザー像を思い浮かべる」ことだ。納期命スケジュール命の案件において、ユーザーインタビュー等のフローをへてペルソナを設けるのは厳しいときが多いけど、これまでよんだ書籍では「ユーザー中心デザインにはユーザー調査が絶対大事」という価値観一色でぬられていたように思った。だからこそ、ユーザー調査できない自分の状況に、私は葛藤していたわけで。
同じユーザーを想定するための手法を記載してくれていることに、正直とても救われた気持ちになった。

また、「ユーザビリティエンジニアリング」では、限られたリソースについても以下のように言及している。

ほとんどのプロジェクトでは予算もスケジュールも限られています。その貴重なリソースを定量的データの測定に費やすべきではありません。それよりも、思考発話法などの少人数のテストを繰り返す法がインターフェースの改善には役立ちます。

そうそう!公開直前でのユーザーテストに伴うタスク達成度計測とか、何の意味があるんだよと思う。
大事なのは、少人数でのテストを繰り返していくことなんだよね。。

ユーザー中心デザインの手法導入について

現場でUXをより考える立場になって、つくづく感じたのだけど・・・ユーザー中心デザインはいきなり現場で取り入れるのは相当大変だと思う。

ユーザー中心デザイン手法で完全にプロジェクトをすすめるには、納期や進行方法、予算を考えるとチーム内合意のみならず、何より最終の会社の意志決定者(社長?)が必要だと思う。他方、弊社のように、納期命で金より頭つかえという文化圏内においては、本書のユーザビリティ成熟モデルのように段階的に進んでいくのが現実的だと思った。

■1:原始期
ユーザーインターフェースの設計は、デザイナやソフトウェアエンジニアの技量にゆだねられている。ガイドラインなどは参照しているが、実際のユーザーと対話する活動を行っていない。ユーザビリティエンジニアはプロジェクトに参加していない。

■2:黎明期
製品リリース前に最終チェックとしてユーザーテストを実施する。ユーザビリティは従来の品質保証活動の一部にすぎない。ユーザビリティエンジニアは製品完成後に”評価者”としてプロジェクトに参加する。

■3:揺籃期
有効な設計手法としてユーザーテストが定着する。前期ではプロトタイプを使ってユーザーテストを実施する。後期ではプロトタイプとユーザーテストを繰り返す(反復デザイン)。ユーザビリティエンジニアは設計チームの要請に応じて”助言者”として随時プロジェクトに参加する。

■4:躍動期
シナリオやペルソナを開発してユーザーニーズを探索する。要求定義から実装まで、設計プロセス全体にユーザー中心のアプローチを用いる。ユーザビリティエンジニアは設計チームの”主要メンバー”の一人としてプロジェクトにレギュラー参加する。

■5:拡充期
リリース後の製品の利用状況について追跡調査を実施する。製品のライフサイクル管理全体にユーザー中心のアプローチを用いる。ユーザビリティエンジニアは(プロジェクト単位でなく)”製品マネジメント”チームの一員として参加する

■6:完熟期
ユーザビリティ知識管理データベースを構築する。組織全体にユーザー中心の文化が浸透し、ユーザビリティ(およびユーザー体験)の管理は重要な経営課題になる。ユーザビリティエンジニアは”経営マネンジメント”チームの一員として参加する。

少なくとも「3:揺籃期」にはたどり着こうぜ、と本書では述べている。

ユーザビリティ活動を始めたのならば、少なくとも揺籃期までは到達すべきです揺籃期に達すれば、プロトタイプの段階で問題点を発見して修正できるようになります。立派な大人が”紙芝居”を作成して、質素なラボでテストを繰り返していると、一見するとレベルの低い活動を行っているように感じるかもしれません。しかし、こういった地道な活動が具体的な成果を生んで、ユーザビリティ活動の本当の価値が設計チームや社内に認められるようになるのです。

たしかに、「3:揺籃期」までは、現場でどうにかがんばれる範囲なのかもしれない。
「4:躍動期」〜「6:完熟期」を引っ張っていくとしたら、当然会社では一定以上の権限が絶対に必要となると思う。平社員の私は「3:揺籃期」,そしてあたりを目指して納期&予算と戦うのが現実的だ。
納期や予算と戦って、ユーザー中心デザインの考え方を用い、成果(売り上げ)を残す。売り上げを達成すれば、より予算も考慮してもらえるかもしれないし、納期も社内調整しやすくなると思う。

完全なリリース時期はずらせなくても、エンジニアに渡すデータの順番を相談しやすくなるとか。「こっちはこういう検証が成果残すために必要だから、ちゃんと工数ちょうだい!かわりに別のところは早めに渡すね。」というかんじ。エンジニアの方にもユーザー中心デザインの大事さが成果という形で伝わっていれば、「UI設計側がわがままいってる」という見方はされないと信じている。

—–

「3:揺籃期」を自分のプロジェクトで実施していく。
そんな新年の抱負を胸に、2013年も頑張ります。
相変わらず人間関係苦手&挙動不審で、仕事について人様に伝えるのがすこぶる下手なので、このブログを中心として仕事とその思考を記録してゆこうと思います。お読みくださってる方がいてくださり、とてもありがたいなあと思っています。

本年もどうぞよろしくお願いいたします。

URL :
TRACKBACK URL :

Leave a Reply

*
*
* (公開されません)

Facebookでコメント

Return Top