【GIG勉強会Vol.59/GIGLT.47】ディレクターとUXデザイナーが語る「上流設計」「プロジェクトマネジメント」「セキュリティ」のこと

こんにちは！ 広報インターンのmozukuです。

GIGでは毎月さまざまなテーマで勉強会を開催しており、現在はコロナウイルス感染拡大防止のためオンラインにて実施しています。

今回は、UXデザイナーの瀬島さん、ディレクターの廣瀬さんと山口さんが、

• 上流設計でやっていること〜ペルソナ／カスタマージャーニーの活用方法〜
• ファシリテーション・プロジェクトマネジメント
• 開発系プロジェクトってなにやってるの？ 〜事例から学ぶ開発系プロジェクトの基礎〜
  という3つのテーマでそれぞれのノウハウを共有してもらいました！

上流設計でやっていること〜ペルソナ／カスタマージャーニーの活用方法〜

1人目の登壇者は瀬島さん。

今回は、実際に担当した事例をもとに、上流設計で行ったことをはじめ、ペルソナ／カスタマージャーニーの活用方法について教えてくれました。

■登壇者プロフィール

瀬島 香里（せじま かおり）
株式会社GIG DX事業本部 プランニングチーム所属。上智大学を卒業後、新卒で企業出版をメインとする出版社へ入社し、新規開拓法人営業を担当。後、2020年3月にGIGにジョイン。Webサイト制作のディレクションや効果のあるサイト構築を目指した上流設計などを担当している。

上流設計とは？

瀬島：
サイト制作における上流設計とは、「誰にどんな価値を届けるWebサイトにするのか」といったサイトの方向を設計することです。Webサイトを設計する際、クライアントには何かしらの目的があります。

クライアントが、Webサイトを通して誰に何をどんな情報を届けて、どうしてもらいたいのかという部分を練らないと、画面設計やデザインのイメージのすりあわせで齟齬がおこってしまいます。公開後に「こんなはずじゃなかった」とならないためにも、戦略部分をすりあわせることが重要です。

ペルソナ設計・カスタマージャーニーの活用方法とは？

瀬島：
私が担当した、数学検定協会さんの事例をもとに紹介します。ご依頼をいただいたときは、「数学が好きではない人」をターゲットに、メディアサイトを制作したいとのことでした。当初のゴールは「数検受験者を増やしたい」でしたが、上流設計を組んで最終的には「毎日の暮らしに役立つ数学の情報を発信するメディアサイト」に。

具体的にどのような工程を組んで設計をしたかお話ししていきます。

今回はメディアサイトの制作なので、

• 誰が
• 誰に
• どんな価値を提供するのか

を定義して、コンテンツ施策の提案・制作、デザイン制作が目的となります。上流設計においては、次のような流れで行いました。

• ステップ1. メディアに訪れて欲しいユーザー層（ペルソナ）を定義
  ペルソナ設計として、「数学に関心を持ってくれそうな人はどんな人か」ブレストを実施しました。次に、挙げられた案をグルーピングし「どの情報を優先するか」お客さんとすりあわせます。そのほか、デスクリサーチやインタビューを行い、ペルソナ設定をより細かく落とし込みました。
• ステップ2. ユーザーの行動やどういう心情を持っているのかを俯瞰的に整理したカスタマージャーニーマップを策定
  ペルソナごとのカスタマージャーニーマップを設計します。ペルソナの動きを時系列で可視化し、細かい心理状況や目的を行動フェーズで洗い出すことで、ユーザーニーズを挙げました。
• ステップ3. 挙げられたユーザーニーズに対して、どのような価値を提供できるのか定義し、コンセプトを決定
  カスタマージャーニーマップで具体的なユーザーニーズが挙げられたので、そのニーズに対して数学検定さんがどういう価値提供をできるのかを明文化します。

瀬島：
ペルソナ設計やカスタマージャーニーマップは、サイト制作をゴールに導くためのツールです。なので、何のために実施するのか、カスタマージャーニーマップをどう活用するのかプロジェクト内で認識を合わせながら進めるのが非常に重要になってきます。

ファシリテーション・プロジェクトマネジメントについて

2人目の登壇者は、廣瀬さんです。

GIGに入社する前も制作会社や広告代理店に勤務しており、今年でWebディレクター7年目になるという広瀬さん。トラブルが発生している、いわゆる「炎上案件」へ放り込まれることが多々あったという廣瀬さんは、炎上の原因が「コミュニケーション齟齬」にあることに気づき、ファシリテーションとプロジェクトマネジメントの重要性を再認識したそうです。

そんな廣瀬さんが、ファシリテーションとプロジェクトマネジメント（PM）で気をつけていることについて話してもらいました。

■登壇者プロフィール

廣瀬 祐也（ひろせ ゆうや ）
株式会社GIG DX事業本部 ディレクションUnit1所属所属。成城大学を卒業後、新卒でアパレル企業へ入社。その後、Web制作会社にてディレクター職へ。後、2021年9月にGIGにジョイン。主にプロジェクトマネジメント、Webサイト制作ディレクションを担当している。

ファシリテーション・PMとは？

廣瀬：
僕にとってのファシリテーションとプロジェクトマネジメントの定義を、上のスライドにまとめました。

ファシリテーションとプロジェクトマネジメントは、どちらも言葉を介したコミュニケーションです。ファシリテーションは言葉を介して会話になり、プロジェクトマネジメントは、言葉を介してテキストやドキュメントになります。

ファシリテーションで気をつけること

ファシリテーションの際に気をつけることは次の2つです。

ポイント1. 納得してもらう

説得とは、こちらの考えを相手に理解させようとするはたらきかけ。納得とは、こちらの考えを相手の腹に落として、自発的に動かすことです。

次のように話し方を変えるだけで、説得は納得に変わります。

• お客さんの質問に答えるときや、案件のクロージングに向かうときは、話すスピードをゆっくりにする
• 相手の質問を聞いて、「本当に聞きたいこと」を捉える

ポイント2. 質問と共感／感想をワンセットにする

MTGやヒアリングの際はクライアントに質問しますが、制作進行のことだけ考えて質問を連続させてはいけません。質問の連続は詰問に聞こえることもあります。質問と共感・感想をワンセットにすることで、相手をより理解できるし、相手も「自分の話を聞いてくれている」と思えます。

たとえば、デザイン提案などで「A案とB案どちらががいいと思いますか？」、「なんでA案が？」、「どこがいいんですか」と聞くより、「その色合い、いいと思います」など、自分の感想を入れると会話になってくると思います。

プロジェクトマネジメントで気をつけること

プロジェクトマネジメントは、言葉を介して、テキストやドキュメントになるものです。僕が気をつけているのは次の2つ。

ポイント1. 精度の高いフィードバックをすること

デザインやテストが終わったあとに、「〜〜制作しました。ご確認お願いします」と言う人がいますが、送られてきた側からすると「どこの何を確認するの？」「どういうフィードバックが欲しいの？」「伝えた内容が反映されているのかな？」等、いろいろと考えてしまいます。そのため、

• フィードバックしてほしい内容
• どのような意図で作ったか

など細かくテキストで伝えるのがよいでしょう。

ポイント2. テキストドキュメントの作り方

クライアントと制作会社間で制作フローや作業内容に対する認識が一致することはほとんどありません。ただ、テキストやドキュメントを制作することで、認識のずれを少なくすることはできます。テキストドキュメントを作る際は、次の順番を意識しましょう。

1. ゴールから作成
2. プロセスを作成
3. 作業依頼

何をゴールとするか分からないのにプロジェクトをスタートさせるのは問題です。目的（ゴール）が見つかったら、プロセスを明確に。「どこに給水ポイントあるよ」「今日は坂が多いよ」などの道筋・スケジュールを立てることで、クライアントもペース配分ができるようになります。

ファシリテーションもプロジェクトマネジメントも「言葉」を介して成り立つコミュニケーションです。プロジェクトの成功も失敗も些細な「言葉」で変わります。まずは言葉に臆病になることから始めてみるとよいかもしれません。

開発系プロジェクトってなにやってるの？ 〜事例から学ぶ開発系プロジェクトの基礎〜

最後の登壇者は、山口さんです。

「開発プロジェクトってどんなもの？」という前提知識から、プロジェクトで得たノウハウまで教えてくれました。

■登壇者プロフィール

山口 春香（やまぐち はるか）
株式会社GIG DX事業本部 ディレクションUnit2所属。筑波大学を卒業後、新卒で入社した会社で会計系システムの要件定義やテストを経験。その後、2020年2月にGIGにジョイン。中〜大規模のWebサービス開発のディレクションや要件定義などを担当している。

開発系プロジェクトとは？

開発系プロジェクトとは、

• 既存の業務の効率化や最適化
  いままで紙でやってきたことを、Web上でやっていきましょうなど
• 新たな業務の仕組みづくり
  新しく求人を作って、給与や勤怠の管理をしたいといった目的やサービス構築など

山口：
開発系プロジェクトの特徴としては、やりとりする金額が大きいということです。初期開発は大体1,000万円ほど。プロジェクト期間が長めで、最短でも半年ぐらいかけてやることが多いです。バックエンドやインフラエンジニアの方が活躍されています。

今回はほかの受託案件にもいかせそうな開発系プロジェクトの2つのノウハウをシェアしようと思います。

• 「やることと」と「やらないこと」を決めてテキストに残す
• セキュリティを学ぶ

「やることと」と「やらないこと」を決めてテキストに残す

山口：
このような悩みは、ディレクターの永遠の悩みとして、解消したいと願っている方も多いと思います。コミュニケーションによるトラブルを減らすために、私は次のような進め方をしています。

まずは要求定義書に、次の点を書きます。

• ワークフロー：その機能を使用して誰が何をするかをまとめたもの
• この機能を使うことでできること・発生する挙動：このボタンを押したら、ここにリンクするなど
• 入力項目や入力規制（フォームがあるなら）：お問い合わせフォームなら、氏名・お問い合わせ内容など

次に「やらないこと」、つまりスコープ外機能を挙げます。

• 作らない機能／やらないことを決める
  ログイン機能は作るけど、SNS投稿機能は対象外にするなど
• お客さん側がやることを書いておく
  最低賃金のバリデーションは設定するけど、規約の変更はお客さんに任せる
  など

要件が後々明らかになると、見積もり想定からはずれてしまうリスクもあります。なので、プロジェクトのはじめに「やること」と「やらないこと」をクライアントと共有して、書類に残しておくと安全です。

セキュリティについて学ぶ

山口：IPA「安全なウェブサイトの作り方」を読んで、説明できるようになりましょう。ディレクターの経験では理解が難しい点もあるので、エンジニアに質問してみたり、相互で教え合ったりするといいかもしれません。

そもそもセキュリティはなぜ大事かというとお話を。平成22年にある企業で顧客の個人情報の流出がありました。基本的な脆弱の対策がなされていなかったことが指摘され、システムを開発した企業は約2,000万の損害賠償を支払いました。

セキュリティに関しては、エンジニアだけでなく、ディレクターも認識して対策する必要があります。セキュリティや、システム開発の専門業者だから「あたりまえにやってくれているだろう」が前提になっているので、知らなかったは通用しません。

まとめ

今回の勉強会では、部署を超えて使えるノウハウをたくさん紹介してもらいました。プロジェクト進行というマクロな視点からスキルや業務を考える内容が多かったため、明日からでも実行できる・意識できるポイントがたくさんあったのではないかと思います。

また勉強会後のアンケートでは、

「セキュリティの話　エンジニアとして気を付けないとと思った」
「コミュニケーション周りの話について、自分の普段のコミュニケーションにも生かせる部分があると感じた」

といった回答も。

今回の勉強会も、学びの多い実りあるものでした！

GIGではGood is goodなチームを築ける仲間を募集しています！

現在、GIGでは「一緒に学びながら成長していきたい！」と意欲のある仲間を募集しています。

（この記事はGIG BLOGからの転載です）