フロントエンド の記事一覧

こんにちは、GMOインターネットの吉田です。UI/UXディレクターのお仕事とプロジェクトの流れについて、引き続き連載でお伝えしていきます。 プロジェクト全体の流れ 前回エントリーでは、「企画/調査」フェーズまでをご紹介しました。 何を開発して誰にどんな風に使ってもらうのか、少しずつ作るものの全容が見えてきたところです。 それでは続きのフェーズを解説していきます。 要件定義 「要件定義」のフェーズでは、「企画/調査」フェーズを元に開発する内容を資料にまとめます。 開発する内容がだいたい固まってきたところで、プロジェクトメンバーを募ってキックオフMTGを開催するので、参加者とプロジェクトの概要について認識合わせをするための資料づくりというイメージです。 要件定義の資料には、主に以下を記載します。 開発の背景や目的解決すべき課題ターゲット期待効果開発の概要や要件スケジュール GMOインターネットは事業会社なので、企画から開発まですべて社内で完結します。そのため、一般的な「要件定義」の内容とは少し異なるかもしれません。開発仕様の詳細についても「要件定義」の段階では確定している状態ではなく、次の「設計」フェーズで開発メンバーと一緒に議論しながら検討を進めていくことが多いです。 ちなみにGMOインターネットには「手をあげる」文化があるので、希望者は社歴や経験は問わずプロジェクトに参加できます。入社1〜2年目でも、比較的大きなプロジェクトを任せてくれるので、積極的にチャレンジしていきたいですね。（もちろん先輩社員がちゃんとバックアップしますよ！） 設計 「設計」のフェーズでは、具体的な開発の仕様を検討します。大きく分けると「機能設計」と「画面設計」があります。 「機能設計」には、API設計、ファイル仕様、DB設計などが該当しますが、基本的には開発エンジニアのメンバーを中心に検討を進めてもらいます。 「画面設計」では、主にUI設計をしますが、まずディレクターがワイヤーフレーム、モックアップ、プロトタイプを作成します。ディレクターの草案を元に、さらにデザイナー、開発エンジニアと議論しながら詳細な仕様を決めていきます。 Adobe XDで作成したモックアップの例 画面設計時の使用ツールは、「Adobe XD」をメインに使っています。 「Adobe XD」は、作成した画面イメージをかんたんに共有しやすい点が便利です。プロジェクトの規模や内容によって、その時に合ったツールを選択しているので、過去にはmoqups、Skecth、Figma、InVision...なども使用していたことがあります。 また、画面設計をするうえで「企画/調査」フェーズで作成した「ペルソナ」がとても役に立ちます。（ペルソナの詳細はUI/UXディレクターのお仕事とプロジェクトの流れ Vol.1を確認してください。）例えば、クリックして別のページに遷移するUIを検討する場合、お名前.com のペルソナは、「比較的年齢層が高めでITスキルは低〜中程度」を考慮して、アイコン表示だけではなく、アイコンとテキストを表示して何の機能なのかを認識しやすいようにしています。 評価 「評価」のフェーズでは、「ユーザビリティテスト」を実施します。「ユーザビリティテスト」とは、ユーザーが迷わずにタスクを完了できるか観察するもので、Adobe XDで作成したプロトタイプを使います。テストで課題が見つかると、改善→テスト→改善→テスト…を繰り返します。 Adobe XDで作成したプロトタイプの例 GMOインターネットでは、基本的に社内の人にテスターとして参加してもらい、テストを実施しています。（リサーチ会社を使って、テスターをリクルートする場合もあります。） 「テストはリリースしてからやればいいのでは？」と思うかもしれませんが、開発実装する前の段階でテストすることがとても大事です。 一般的にテストを2回実施することで不具合を50%軽減できる。と言われていて、テストすることで開発の手戻りを防ぐことができます。また、検証フェーズでは機能の不具合を見つけることができますが、ユーザビリティの問題を解決するのは難しいです。自分たちが設計した画面でお客様が迷わず操作できるかどうかの確認をするためにも、評価フェーズの段階でユーザビリティテストを実施することが重要です。 おわりに 次回いよいよ怒涛の「開発」フェーズに入ります。ディレクターは開発作業はしないですが、開発段階で色々な問題が判明することが多く...実はけっこう忙しいフェーズです。 続きはまた次回のブログで！ 連載記事はこちら https://developers.gmo.jp/technology/9080 https://developers.gmo.jp/technology/11603 https://developers.gmo.jp/technology/12838

こんにちは、GMOインターネットの吉田です。ふだんナゾに包まれた（？）UI/UXディレクターのお仕事とプロジェクトの流れについて、連載でお伝えしていきます。本エントリー後半では、GMOインターネットが提供するサービス「お名前.com」UX向上のために作成したカスタマージャーニーマップも紹介いたします。 はじめに 私の所属しているディレクターチームは、現在7名です。 中途採用の人もいれば新卒採用の後輩もいて、前職の経験などバックグラウンドはみんなバラバラです。同じチーム内でも違う役割を担っているため、チーム全員がUI/UXディレクターという立ち位置ではありませんが、ディレクターチームとして目指していることは、"ユーザー体験（UX）を向上して、ブランド、サービスのファンをたくさん作ること"です。 また、GMOインターネットではドメイン「お名前.com」やプロバイダー「とくとくBB」など比較的大きなサービスを提供しているため、「サービスデザイン」の考え方も取り入れながら、売る人、創る人、守る人、お客様など関わるすべての人が満足できる持続可能なサービス設計を心がけています。 プロジェクト全体の流れ ディレクターのお仕事は、ひとことで言うと「デザインと開発（プログラミング）以外は何でもやる！」です。 プロジェクトの内容によっても異なりますが、企画からはじまり、仕様決め、ミーティングの開催、資料作成、検証作業...などなど、果てしなくさまざまです。 それでは、各フェーズごとにディレクターのお仕事を解説します。 企画/調査 「企画/調査」は、まだプロジェクト化する前のフェーズです。 発案はディレクターチームに限らず、事業部（マーケティングやサポート）、開発部、グループ会社から企画が出ることもあります。 このフェーズでは「市場調査/競合調査」、「ペルソナ作成」、「カスタマージャーニーマップの作成」を行なっています。 市場調査/競合調査 情報収集をして、ターゲットとなる市場や競合他社の調査をします。競合とのスペック比較表などを作成して、競合のターゲット層や売り方、強みの部分などを資料化。自分たちのサービスはどこを狙っていくべきかを探っていきます。 調査は比較的しっかり時間をかけて、企画の根拠となる情報をたくさん集めることがプロジェクト成功のカギです。 ペルソナ作成 企画内容がある程度決まったら、「ペルソナ」を作成します。 「ペルソナ」とは、サービスや機能を利用するユーザーの人物像を具体的に表したものです。利用シーンや使い方など、ユーザーの気持ちをイメージしやすくなるメリットがあります。 お名前.comのペルソナ お名前.comのペルソナは、会員情報やアンケートの情報から作成しました。お名前.comのユーザーさんは男性が多く、比較的年齢層が高めでITスキルは低〜中程度の方が多い傾向にあります。 ペルソナは、サービス設計や画面設計を検討する重要な判断材料にもなります。「これ大島さん操作できる？」、「大島さんこのボタンの意味わかるかな？」というように、ミーティング中にペルソナの名前が飛び交ったりします。 ディレクターとしては、プロジェクトメンバーがペルソナに愛着を持って議論してくれるとすごくうれしいです。 カスタマージャーニーマップ作成 ペルソナが完成したら、次に「カスタマージャーニーマップ」を作成します。 「カスタマージャーニーマップ」とは、ユーザー体験を旅に見立てて可視化したものです。サービスの利用前〜利用中〜利用後の状況、行動、思考、感情を1枚のマップにまとめます。 ユーザーが不満に思っている箇所を洗い出し、改善が必要なポイントを見つけることができます。 お名前.com レンタルサーバーのカスタマージャーニーマップ レンタルサーバーリニューアルのプロジェクトでは、複数の社内メンバーに参加してもらい、模造紙と付箋を使って情報をまとめていきました。 感情曲線を見ると申込み後に下降しているポイントがいくつかあります。利用に関する不明点や申込み後の不安感を解消するために、お名前.com Naviやサーバーコントロールパネルではサポートコンテンツの表示や、チュートリアル機能の実装など、改善策として検討した内容を開発していきました。 おわりに 次に「要件定義」のフェーズに入りますが...今回の解説はココまでです。ディレクターのお仕事について、ちょっとだけ興味湧いてきましたか？？ 続きはまた次回のブログで。 連載記事はこちら https://developers.gmo.jp/technology/10336 https://developers.gmo.jp/technology/11603 https://developers.gmo.jp/technology/12838

本エントリーは、サイト高速化の一手法とされるファーストビューのインライン化に関する記事です。2020年にリニューアルしたGMOインターネットの採用サイトを高速化する試みのなかで行った、ヘッダーの改修について記しています。 要約 目的：弊社採用サイトのヘッダーの読み込み速度を上げたい方法：ヘッダー部分のCSS/JSを切り出してインライン化結果：低速環境下でもヘッダーの挙動・デザインの崩れがなくなった はじめに Webページの表示スピードを改善する手法はさまざまありますが、その中の1つにページのファーストビュー部分のCSS/JSをインライン化する方法が挙げられます。 背景としては採用サイトリニューアル後、低速回線環境下だとページの読み込みが終わるまでヘッダーメニューの表示が崩れるという困り事がありました。 リニューアル後のヘッダーは、PC・タブレット・スマートフォンのデバイスサイズを問わず、メニューはハンバーガーメニューから開く形式になっています。トップページからはヘッダーを経由しなくてもすべての下層ページへ遷移できますが、下層ページからはヘッダーを経由した遷移が基本になります。そのため、採用サイトを開いたあるいは再読み込みが走った際、ヘッダーが読み込まれないと他のページへ移動する際に不便です。 就活、転職活動をしている方は面接前の移動時間等に採用サイトを確認される方も多いかと思います（※）が、とくにすべてのコンテンツが読み込まれるまで別ページ（ニュース、企業理念、会社概要など）への動線が早く利用できるように改修が必要でした。このため、採用サイトヘッダー部分のJavaScript（以下JS）/CSSを切り分け、インラインで読み込むことにより表示の高速化を図りました。 ※2021年記事執筆時点でのGMOインターネットの選考フローにおいて、最終以外の面接はzoomを用いたオンライン面接になります。 改善前の挙動 https://youtu.be/XT4MZ75v9Ts ヘッダーインライン化前の表示速度を確認した動画がこちらです。chromeの開発者ツールでNetworkタブのThrottling Profileを変更し、最も遅い「slow 3G」でエミュレートしています。動画でページを更新してから開閉ボタンが表示された直後にヘッダーを開くと、ヘッダー内のメニューが正常に表示されていないのがわかります。このときの採用サイトヘッダーの挙動は下記のようになっていました。 変更前のSCSS CSS：共通ファイルをまとめ、1cssファイルにコンパイル 変更後のJS JS：jQueryを使用している＆機能ごとに分かれたファイルを一つのscript.min.jsにコンパイル CSS、JSともにすべてのコードを1つのファイルから読み込んでいるため、ヘッダーのようにはじめに表示される箇所も、正常に動作するにはページ全体用のコードが読み込まれるまで待つ必要がありました。 基本的には読み込むCSS、JSは分かれていない単体のファイルが望ましいとされていますので、優先して表示したい箇所によりインライン化するかの判断は変わってきます。 ヘッダーインライン化のために行ったこと 変更後のSCSS まずCSSでは、すべてのスタイルがコンパイルされていたのをヘッダーとそれ以外に切り分けました。 ヘッダーに必要なスタイルを個別にコンパイル、ページ内でコンパイルしたファイルをテキストとして展開します。 変更後のJS JSも同様、ヘッダーに必要な記述のみを切り分けてコンパイルし、ページ内で展開しました。 採用サイトではjQueryを使用していますが、読み込みに時間がかかるためヘッダーの記述を純粋なJSのみを使用した記述に書き換えています。 最終的に、ブラウザ上では下記のような記述になっています。 結果 https://youtu.be/aL177_2Wgik ヘッダーインライン化後の表示速度を確認した動画がこちらです。 改善前同様、chromeの開発者ツールを用いネットワーク速度をもっとも遅い「slow 3G」でエミュレートしています。 ヘッダー開閉ボタンが表示された直後にクリックしても、ヘッダー内メニューがすべて表示されていることがわかります。 https://youtu.be/Hl3ds1ohUyY 変更前と変更後を比較した動画がこちらです。 レンダリングが始まってから、全メニューが表示できるようになるまでの時間に90秒程度差があることがわかります。 課題 改修後の課題として、ヘッダーを優先して読み込み・レンダリングするため、JSにおけるデバイスサイズの判定・CSSにおけるサイト内共通設定などもインライン化しており、一部共通ファイルとコードが重複しています。ページで読み込むコードは可能な限り削減したいため、やむを得ず重複する箇所以外をなるべく棚卸しできればと考えています。 また、低速環境下でヘッダーを開いた際、矢印（>）が読み込まれず文字化けとして表示される場合があります。こちらは採用サイト用に作られたSVGをアイコンフォントとして読み込んでいるためで、今後合わせて読み込み速度か表示方法の改善を図りたいです。 おわりに サイト高速化の一手法とされる、ファーストビューのインライン化に関する記事でした。 今回はページ読み込み直後のヘッダー表示を高速化する、という目的の改修だったため、ヘッダー箇所のJS/CSSをインライン化する方法を選択しました。ファーストビュー箇所をインライン化する、という手法がすべてのWebサイトで有用であるかは未知数ですが、ページ表示スピードの改善、ひいては閲覧する方のストレスを軽減したいと考えている方へ、一つの改善例としてお役に立てたなら幸いです。