Photo by Davidlohr Bueso
今回のpaiza開発日誌は片山がお送りします。
paiza運営元のギノでは、これまでも不定期で社内勉強会を何回かやっていましたが、エンジニアの人数が増えてきてスピーカーの頭数が揃ったので、社内勉強会を定期開催する事にしました。
9月の頭に第一回目の「自社サービスエンジニアの為のUX設計、情報設計勉強会」を開催したので、今回はその内容を共有してみようと思います。
■今回の勉強会の目的、背景
paizaの開発部隊はそれぞれ色々なバックグラウンドを持ったメンバーで構成されているのですが、普段の業務の中だと、なかなかそれを共有する機会や、お互いを深く知る機会が無いものです。そこで過去の仕事の事だったり、得意分野についての共有を順番に発表する形で社内勉強会をやってみる事にしました。
業務的なTipsの共有も重要ではあるのですが、普段の業務の周辺領域だったり、少し畑の違う事や、違う言語・技術に触れる事で視野を広げたり、共通言語の幅を広げられる場にできれば良いなと考えています。
第一回目は企画した人がやるべきだろうという事で、自分が発表してみる事にしました。
自分はpaiza運営元のギノ株式会社の代表もやっていますが、開発面においては、現在でも企画、設計とデザイン周りのディレクション、デプロイ前の最終調整でコードも少し書いたりしています。開発の前後の部分を担当する事が多いので、そのあたりのUX設計と情報設計についてエンジニアと共通言語を持てるといいなと思って発表してみる事にしました。
自分自身のバックグラウンドとしては、Web系のわりと何でも屋(営業から実装まで)ではあるのですが、デザイン面と技術面の両方のバックグラウンドがあり、その上でUX設計や情報設計をする機会も多かったので、そのバックグラウンドの共有という意味でもこのテーマにしました。
◆今回のゴール
UX設計、情報設計のためのフレームワークを体験してみる。
頭の片隅に「こんなやり方あったなと」インデックスされればOK。
一回の勉強会で実践的な成果を出すのは無理なので、何かのときに思い出してもらったり、こういうやり方があるという事を知ってもらうという事をゴールにしました。特にエンジニアからするとUXは知っててもIAとか情報設計はあまり知らないジャンルなので、知っていると視野は広がるかなと。
喋るだけだと忘れてしまって脳みそにインデックス化されないので、前半1時間喋り、後半30分ワークショップ形式で、実際に手を動かしてみて、体験する事で頭の片隅にインプットされるようにしてみました。
■勉強会アジェンダ
- 情報設計とはなんぞや？
- UX設計とはなんぞや？
- 情報設計の成果物を知る
- やってみよう(ストラクチャ、エリア定義)
スライドだけだと伝わらない部分もあるので軽く補足も交えて説明しておきます。
アップしたスライドには入れていませんが、最初に改めて自己紹介と昔作ったものの紹介などは最初にしました。あんまり自分の過去の仕事の事をみんなに話す機会もないので、実際の昔仕事で作ったものの画面等を見せて話をしてみました。
■勉強会の解説
◆1.情報設計とはなんぞや？
情報設計(IA)については、ちゃんと話すとすごく長くなってしまい、定義がどうのこうのという話になりがちなのでさらっと。エンジニアが開発する際は、自分が開発している機能から考える事になるため、いきなり画面設計から入りがちです。その前後の導線設計、ナビゲーション設計やコンテンツ設計も考えると、より価値のあるサービスが作れるよ、という意味で情報設計は役立つよと言う話。
◆2.UX設計とはなんぞや？
UXは言葉の定義が結構ボンヤリしがちなので、概念としては、UXは結果、UX設計は結果を生み出すための手段、情報設計はUX設計の中の一分野という整理をしてみました。（このあたり色々な解釈とか定義とか有りそうですが、今回は社内で共通言語化出来れば良いので。。）
UXは「結果」と言っても、スライドにもあるように、「プロダクトの使用や使用予測に際しての【知覚や反応】」という意味での結果です。より良い【知覚や反応】を定め、その結果を得る為の設計が重要、という事です。
より良い【知覚や反応】について、「ユーザーにとって良い【知覚や反応】」という考え方もありますし、「プロダクト提供側にとって良い【知覚や反応】」という考え方もあります。
UXを考える際に「ユーザーにとって良い【知覚や反応】」を追求しがちですが、それだとビジネスとして永続性がなく、サービスを止める事になると結果的にユーザーにとっても不利益（最悪なUX）となってしまいます。
逆に「プロダクト提供側にとって良い【知覚や反応】」ばかり追求すると長期的にはユーザーが離れていく事になります。（思わず課金しちゃうけど、後で考えてみると後悔する、というような事）
そのためビジネスでUXを考える場合は、マネタイズやそれを生み出すビジネスモデルとセットでUXを考えていかなければいけません。つまり、「ユーザーにとって良い【知覚や反応】」であり、かつ「プロダクト提供側にとって良い【知覚や反応】」を目指す必要があります。
◆3.情報設計の成果物を知る
時間の関係もあり今回はUX設計といいつつ、そのなかの情報設計が中心なので、情報設計にの成果物についてのみの説明です。情報設計を専門にやる人の成果物についてごく簡単に解説をしました。
情報設計を専門にやる人（インフォメーションアーキテクト）は、基本的には受託側にいる人なので成果物として沢山ドキュメントを作ります。しかし自社サービス側ではそんなにドキュメントは重要ではないので、ペルソナやUXジャーニーマップについてはさらっとサンプルについてのみの説明としました。
関係者が多くなったり、サービスが巨大になってくるとこういうドキュメントを作ってまとめていく必要も出てきますが、例えばpaizaぐらいだと、いつもみんなで話をしてるのであえてドキュメントに落とす必要もないと思います。UXジャーニーマップは一回作ってみましたが、特に発見もなく、あくまで共有ツールだなと思いました。外部の人や、新しく入った新人がが全体を見渡すために作ると整理されるかもしれませんが。
エンジニアとって必要なのは、共有ツールとしてのドキュメントではなく、頭を整理してより良い結果を出すためのフレームワークです。色々できたほうが良いですが知っておくと良いなと思ったのは下記の4つ
- コンテキストメモ
- 競合調査
- ストラクチャ(サイトマップ)
- ワイヤーフレーム（エリア定義）
コンテキストメモというは業界的にあるものでもなくて、適当に付けた名前です（なんかほかに名前があった気がしますが…）。
これは単純に、何かの機能開発をしようという時に5W1Hで整理して考えてみようという事です。なんか作ろうという事で盛り上がっていても、改めてこのフォーマットで考えてみると、なんでこれ必要だったんだっけ？というのが結構あります。
なぜ必要なのか、誰が必要なのかという事が明確でないと意味のない機能なりがちだし、どのようなUIが良いのかを考える際もよりどころがなくなってしまいます。企画サイドが考えるべきことではあるものの、もう一度エンジニアサイドでもまとめてみる事で、不明瞭な点を開発前に明らかにすることが出来ます。
ユーザーは自分たちのサービスだけ使っているわけではないので、いきなり作り始めないでベストプラクティスを知るための行為として競合調査をする事は重要です。これも企画サイドでやる事ですが、自分でもやってみる事で色々な発見があるはずです。
何かの機能を開発していると、自分が作っている機能ばかりにフォーカスしがちですが、ユーザーはサービス全体の中の一機能としてしか見てくれないので、サービス全体(この場合はサイト全体)を俯瞰しておく必要があります。
特にナビゲーションや導線は、開発していて慣れてしまうと気になりませんが、ユーザーにとっては障害になる事がおおいので、サイトストラクチャを作り、どこにどういうコンテンツ、機能を配置するのかの整理をしていくとより良いUXにつなげられれます。結構事業者側だとワイヤーフレームは作るがサイトストラクチャは知らなかったという人も多いので紹介してみました。
ワイヤーフレームはいきなり細かいのを作ると失敗する事が多いので、ここではエリア定義について紹介をしました。
機能を少しづつ追加していくと、たいてい画面がごちゃごちゃして使いにくくなりがちです。近しいような機能が画面の色々な場所に散らばっていたりすると、視線があちこちに行かなければいけなくなり使いにくくなるので、画面をざっくりとエリア分けしてやり、近しい機能をまとめる事で使いやすさの向上を計れます。
これもあまり知らない人が多いと思うので紹介をしてみました。まずはざっくりと三つぐらいのエリアに分けてみて、そこから少しづつ細かく分けていくとうまくエリア分けをする事が出来ると思います。
下記エリア定義による改善例です。
この例だとプロモーションエリアとナビゲーションエリアが一体化しています。プロモーションエリアは広告的なエリアのため、視線がスキップされやすいというのと、一つの絵として見られてしまい、機能として見られにくいため、プロモーションエリアとナビゲーションエリアを一体化してしまうのはあまり得策ではありません。
検索エリアはナビゲーションの機能という意味では近しいので、上部のナビゲーションエリアと近づけ、プロモーションエリアとは分離したほうが使いやすくなると考えられます。
◆4.やってみよう
最後は30分ほどワークショップとしてサイトストラクチャーの作成とエリア定義を実際にやってみました。
サイトストラクチャーはpaizaのログイン前ページについて実際に作ってみました。いきなりやりましょうと言っても、意外とやり方で戸惑ってしまったりもするので、ライブで解説しながらサイトストラクチャーを作ってみるという事をやりました。思考がトレースでき、細かいtipsを見る事も出来る為、これは割と好評でした。
エリア定義もゼロベースではなく、既存ページをエリア分けしてみる形で実際に手を動かしてもらいました。名前の付け方はどうすべきか？という質問がありましたが自分はナビゲーションエリア、サブナビゲーションエリア、プロモーションエリア、関連エリア、本文エリア、フッターエリアなどとする事が多いです。こちらもライブでエリア定義作成をしながら解説を行いました。
■まとめ
やる前は、情報設計の触りの部分しかやらないので簡単すぎるかなとも思いましたが、実際に資料作ってみたり、勉強会やってみると結構知識と経験が必要な事なんだなと言うのを改めて思いました。自分が当たり前に出来る事って、他の人が出来ても当たり前と思いがちですが、紐解いてみるとそうでもない訳です。
久しぶりに勉強会スピーカーになりましたが、発表すると自分が一番勉強になるとよく言いますが、改めてやっぱりそうだよなと思いました。プロマネや新規事業周りについても機会があれば話してみたいなと思います。
今回話した内容がメンバーに実際にどのぐらい役立つかは分かりませんが、「自分が何を知らないか知っている」、「方法論について頭にインデックスされている」というのは重要な事かなと思うので、他の人の話も是非聞きたいなと思いました。
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか（こっそり）腕試しができる、IT／Webエンジニアのための転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
