【イベント】うちのデザインレビューは“ここ”を見る

「うちのデザインレビューは“ここ”を見る【デザナレVol.11】」 を視聴したのでメモと感想を残しておきます。

目次・概要

ポートフォリオを介したマッチングプラットフォーム ViViViT を提供している 株式会社ビビビット さん主催の勉強会。
今回は3名の方が各社どのような目的や手法でデザインレビューを行っているかの発表。
個人の発表というよりは、ViViViT のサービスの宣伝感が強いイベントでしたが、特に興味のあった SmartHR 小木曽さんの登壇 についてまとめます。

  • 前段
  • 「デザイン」とは本来何を指す?
  • デザインレビューとは?
  • 品質とは何か?
  • SmartHRのデザイン組織紹介
  • 開発組織での事例

ポイント

前段

ソフトウェアの「デザイン」の重要性と期待値はますます高くなっている。

  • 不確実性が増した世界で、優れたアウトプットは1人の知見だけで生み出せるものではない
  • UIデザインだけに限らず、すべての「デザイン」という行為に当てはまる

「デザインレビュー」とは、設計品質を高め、理想を現実に近づける手段のひとつ

「デザイン」とは本来何を指す?

Wikipedia より

審美性を根源にもつ計画的行為の全般を指すものである。

つまりデザインの本来的な意味は、「UIやモックデザイン」ではなく 「設計や計画全般」 を指している解釈

デザインレビューとは?

このふたつの難解そうだが、今回は 「成果物の『品質』について精査・検証する儀式」 と解釈

品質とは何か?

  • 「品質」という言葉は本来主観的なもの
  • 評価するステークホルダーによって、品質の定義はさまざま
  • 1人のデザイナーの「主観」で出した答えが、客観としての「品質」の良さを証明することは難しい

よって、

  • プロダクトは誰のために作っているのか?
  • ユーザーにとっての価値とは何か?

これらの疑問を開発者(プロダクトデザイナー含め)は常に持つべき、とのこと。

ユーザーの目線にたち、常に主観を疑い、検証していくため にデザインレビューが必要となる。

SmartHRのデザイン組織紹介

開発組織での事例

主なレビューイベントとしては、

  1. スプリントレビュー
    • 一般的なスクラムイベントのスプリントレビューと同じ(開発PBI含む全てが対象)
  2. プロデザレビュー会
    • プロダクトデザイングループが中心になって行う
    • 対象はSmartHRのプロダクトデザインに関わる成果物全て

の2つがあり、今回はプロデザレビュー会にフォーカスする。

プロデザレビュー会とは

目的

  • プロダクトを中心とした成果物の精度・品質の向上
  • 各プロダクトの状況把握と情報共有
  • ナレッジや判断材料のシェアと標準化

レビュー対象

  • UIデザイン
  • オブジェクト、UML
  • ユビキタス言語
  • 組織の方針・体制

実施内容

  • 完全オンライン
  • 週1回1時間
  • デザイナーが多めだが、他職能の人も参加やレビュー依頼あり

レビューのやり方

  • レビューのお題を決めるのは、原則レビュー依頼者(レビューイ)
  • レビューイが用意したアジェンダに沿って進行
    • 特に手順に決まりなし
  • ツールはFigmaが多めでMiroやGoogle Docsスプレッドシート、実装画面等

実際の事例

  • UIのバリデーション設計
  • アクセシビリティ改善
    • 発表ではひとつのコンポーネントのデザインに対してのカラーコントラスト改善について
    • スコア基準の共有やモブデザインの実施
  • スペシャルサイトの設計
    • RubyKaigi Takeout 2021 のUIデザインの設計
    • エンジニアと協力してサイトの設計、意匠を決めた事例
  • 非同期の改善案募集
    • レビュー枠を待たずに非同期で改善提案が走ることもある
    • 今回の例はページのレイアウトへの改善提起をSlackで実施

RubyKaigi Takeout 2021 のWebサイト

レビューで生まれる効果

  • 三者視点の気づきと多様なフィードバック
  • 創発的なアイデアとディスカッション

デザインレビューの場作り

  • デザインを見るってどんな観点でみればいいの?
  • レビューはどんな粒度で持っていけばいい?
  • レビューを受け取ったら必ず反映しないといけない?
  • レビューでは何を言ってもいいの?

これらの疑問があると思うが、

レビューは「チームの知見や気づきを勝てに品質を向上し、よりよいインターフェースにたどり着くための儀式」という前提があり、

  • レビューはレビューイの気づかないところに気づきを与えるもの
  • レビューは押し付けではなく、ディスカッション
  • レビューは考えを否定するものではない

という共通認識があるためうまく行えているとのこと。

SmartHR Design System

詳細: デザインレビューの手引 | デザインプロセス | SmartHR Design System
関連: デザインシステムはピクセルグリッドと開発をすすめている

感想

もともとこのイベントを視聴した理由は、最近SmartHRへデザイン〜フロントエンド界隈で強い人が移っているため、その人たちがどのようなことをしたり、どのような組織構造で働いているのかに興味があったため。
またデザインレビューについて深堀りして他社の話を知ることのできる機会もあまりないと思ったため。

結果的に上記の目的はおおむね把握できてよかったです。
特にレビューの粒度など、受託と事業会社で大きく異なることはあるなとは思いましたが、場作り的なことは取り入れれる部分も多いと思うので今後の参考にしたいと思いました。

【イベント】事業とカルチャーを進化させる、Amebaのブランド戦略とデザインシステム

サイバーエージェントさんのオンラインイベント【CADC2022】内の 「事業とカルチャーを進化させる、Amebaのブランド戦略とデザインシステム」 を視聴したのでメモと感想を残しておきます。

目次・概要

  • CHAPTER1 広がるデザインの役割
  • CHAPTER2 Amebaでのケース
  • CHAPTER3 ブランド再定義の全プロセス
    • Phase1. 未来構想、価値の顕在化
    • Phase2. らしさの共通言語化
    • Phase3. 戦略の設計とデザインシステム
    • Phase4. らしさの体現
  • CHAPTER4 効果測定
  • CHAPTER5 まとめ

15年を超える歴史を持つAmebaでは「Amebaらしさ」を改めて解釈するために、ブランドを再定義し、それを体現するためのデザインシステム「Spindle」を構築しました。
今回は、Amebaという大きく長い歴史を持つサービスで、どのようなプロセスでブランドを定義、デザインシステム構築までに至ったのかを今日のデザインの役割と共にご紹介します。

とのことで、デザインシステムの中身についてのことはそこまで語られてなく、そもそもブランディングを行った経緯や設計や構築フローについて語られていました。

ポイント

CHAPTER1 広がるデザインの役割

狭義のデザインから広義のデザイン、経営のデザインへ

  • 社会のデザイン
    • コミュニティ、ソーシャルビジネスの設計
  • 経営のデザイン
    • ビジネスモデル、エコシステムの設計、
  • 広義のデザイン
    • ユーザーの体験、製品/サービスの全体設計
  • 狭義のデザイン
    • グラフィック、UI

デザインからデザイン思考

デザイン思考というプロセスが一般化されつつある。
CAでは5年ほど前からデザインスプリントを実施。
デザインスプリント:ユーザー体験を軸に発見・定義→展開・検証を繰り返す。

ブランディング

  • BRAND(らしさ)
  • ING(届け方)

すべてのタッチポイント(SNS・広告...)でブランドメッセージを伝えること。

CHAPTER2 Amebaでのケース

なぜブランド再定義が必要だったのか?

Amebaはブログを中心としたメディアプラットフォーム。

  • 市場や組織の様々な変化があった
    • SNSの台頭など
  • 事業も成熟
  • 古い機能やシステムが多く残り負債を重ねていた

→ ブランドとして再生する必要があるタイミングだった。

見えてきた課題

  • Ameba全体としてあるべき姿がぼやけていた感覚。
  • 何かを作るにしても、何を指針にすればいいのか分かりづらい。

→ 内側(ビジョン、意思)からのアップデートを行った。

ブランド再定義の目的

根幹を定義することで、組織の向かう方向を作る。 → 「Amebaらしさ」とは何か?を問い、サービスのベクトルを定めて、強固なカルチャーの創出を行う。

CHAPTER3 ブランド再定義の全プロセス

デザイン思考のプロセスを応用してつくる。

Phase1. 未来構想、価値の顕在化

共創メンバー

  • 事業責任者
  • BXデザイナー
  • フロントエンジニア
  • 広報
  • サーバーサイドエンジニア
  • PM
  • UXエンジニア
  • 編集
  • CS
  • デザイナー

手法

  • 社内イメージアンケート
    • ポジティブな部分とネガティブな部分を洗い出す
  • ワーク形式でありたい姿を探す
    • 事実と未来予測と意思をもとに、他にはないらしさを顕在化する
      • 事実:独自性/歴史性/普遍性/未来予測/意思
      • 未来予測・意思:ありたい姿

Phase2. らしさの共通言語化

共通言語化

  • ブランドコンセプト = 生きたコンテンツをつむぐ
  • ビジョン = 100年愛されるメディアを創る
  • ミッション = 人と情報をつなぎ、暮らしと心を豊かにする場所を提供し続ける

最近で言うパーパスは、ミッションに近いところ

Phase3. 戦略の設計とデザインシステム

ブランドの浸透戦略(届けるための施策)を考えていく。
ゴールデンサークル理論(WHYからはじめる)を使う。

  1. 組織
  2. パートナー
  3. 市場コミュニケーション
  4. カスタマーリレーション
  5. キャッシュポイント
  6. ユーザーが払うコスト

の領域をもとに、それぞれに対してアクションを出していく。
状態目標の設定と、どのようなアクションが必要なのかの設計。

デザインシステムの構築

サイバーエージェントのデザインシステム Spindle のWebサイト

  • ブランドを体現するための手段、仕組み
  • 組織のインナーブランディング
  • 負債解消

のため投資判断を行った。

ブランドのパッケージ化

これらを丸々込みにして、デザインシステムを利用すればアメーバのブランドが分かる&らしくなる状態を目指す。

Phase4. らしさの体現

実際のアウトプット

  • 記事デザイン
  • イラスト
  • ステッカー

プロダクト、社内ツールなどあらゆる場所でブランドを体現していく。
アウトプットしながら、改善、洗練を反復していく。

CHAPTER4 効果測定

体現したことが、どこまで浸透したのか。

  1. 組織
  2. パートナー
  3. 市場コミュニケーション
  4. カスタマーリレーション
  5. キャッシュポイント
  6. ユーザーが払うコスト

の領域ごとの自己評価を行った。

社内アンケートも実施。

  • ビジョン、ミッションに共感できる
  • コンセプトに共感できる
  • サービスバリューに共感できる

など。

ブランド浸透度を可視化

浸透度1〜4まで

  • 浸透度1
    • ビジョンなどが存在していない
    • ブランドの定義ができている
  • 浸透度2
    • ブランドを認知している
    • ブランドを理解している
    • ブランドに共感している
  • 浸透度3
    • ブランドを体現する行動ができている
    • ブランドを体現する行動が定着している
  • 浸透度4
    • 社外に発信されている
    • ブランドに共感しファンが増えている

感想

Spindleについてはリリースされてから知ってはいたので興味があり視聴しました。

最後のQ&Aでも言っていたが、もともとデザインシステムのようなものが作りたいという声は社内からあがっていて、そこにうまくブランディングを紐付けられたので、モチベーション等も高かったという話がありました。

ただ最近各社構築しているデザインシステムというものでも、ブランディングの一部に過ぎないということや、やるだけの根拠みたいなものがここまで考えているんだなと感じました。

関連記事

【読書メモ】はじめてのUXリサーチ ―ユーザーとともに価値あるサービスを作り続けるために

目次・概要

  • Chapter1 UXリサーチの捉え方
  • Chapter2 UXリサーチの始め方
  • Chapter3 UXリサーチの組み立て方
  • Chapter4 UXリサーチの手法を知る
  • Chapter5 UXリサーチを一緒にやる仲間の増やし方
  • Chapter6 UXリサーチを活かす仕組みの作り方
  • Chapter7 UXリサーチのケーススタディ
  • Chapter8 UXリサーチの実践知の共有

本書は、メルペイ にてUXサービス開発に携わっている方(松薗さん、草野さん)の著書。

  • 1人でも実践を小さく始めて続けられるように構成していること
  • UXリサーチのリアルな実践事例を扱っていること

を特徴として掲げており、UXリサーチに関する理論的な背景や詳細な手法については、専門家向けの他書籍に譲っています。
「サービス作りのためにUXリサーチを実践し始め続けていきたい」という、わりとライトな層向けの書籍と捉えることができそうです。

ポイント

Chapter1 UXリサーチの捉え方

UXリサーチとは

この書籍では、「UXリサーチ」を

「様々な場面で起きる人の知覚や反応(UX)について調べて明らかにすること」

と定めている。
UXリサーチの対象は、UIを使っているときに限らず、人の生活そのもの、既存の他サービスなど多岐にわたる。

UXリサーチの必要性が高まっている背景

  • サービスが増え、人が一生かけても使い切れないサービス数の存在
  • 他と比べて使いやすいことや、使っているときの体験の品質が高いことが求められる
  • 市場の変化が年々激しくなっている(コロナの影響も然り)
  • ユーザーの多様性

体験の品質が重視され、市場の変化が激しく、多様性が高い状況では、どういう人がどういう事情で使っているかをサービス提供者が推測する難易度が上がっている

背景からUXリサーチの重要性が増している。

UXリサーチのメリットを捉える

  • リリース前から学びが増やせる
  • データを解釈する精度を高められる
  • 組織づくりに使える
    • ユーザーが実際にサービスを使っている様子を目の当たりにすることは、組織内の関係者にとって大きな刺激に

UXリサーチを手段として捉える

UXリサーチをして明らかになったことがきちんと組織の関係者に伝わり、議論や意思決定に活用されることが重要です。

UXリサーチの分け方を捉える

  • 探索/検証のリサーチ
    • 探索のリサーチの手法としては「デプスインタビュー」
      • 期待できる結果は、今まで知らなかった新しい洞察が得られること
    • 検証のリサーチの手法としては「コンセプトテスト」や「ユーザビリティテスト」
      • 期待できる結果は、自分たちが持っている仮説が支持されるか否かがわかること
  • 質的/量的リサーチ
    • 質的データは、ユーザーは実際にどのような行動をしているのか、そのときにユーザーはどのようなことを考えているのかを調べることに向く
    • 量的データは、どこで、何が、どの量で起こっているかを調べることに向いている
  • UXの要素ごとのリサーチ

Chapter2 UXリサーチの始め方

始めること自体が目的ではない

UXリサーチはあくまで目的のための手段のひとつであることを見失わないようにしましょう。

「最近入ったばかりのメンバーもいるし、みんなでユーザーのイメージをあわせてコミュニケーションを円滑にするために実際にユーザーの声を聞く機会を作りたい」といった具合に状況に合わせて目的と手段を考えるのがよい。

まずは小さく始めてみよう

「ユーザーのことを理解したい」という気持ちを忘れずに、相手に興味と尊敬を持って接することを心がけていれば十分です。

  • 高い専門性がなくても始められる
  • 予算がなくても始められる
  • 特別な設備や機材がなくても始められる
  • 時間がなくても始められる
  • 上司や同僚の理解がなくても始められる

「上司や同僚の理解がなくても始められる」については「UXリサーチ」という言葉を使わずに説明することがおすすめの手段。「デザインのヒントを得たい」などの目的とセットで、「その手段としてユーザーを理解したいので、何人かにお話を聞いてくる時間を業務中に取ります」などすると上司としても賛同しやすいのではないか。

何から始めるか

  • 探索のリサーチから始める
    • サービスの課題がいまいちわかっていなかったり、課題は把握しているものの優先順位がつけられていない状態
  • 検証のリサーチから始める
    • すでに課題が明らかで解決方法のアイデアもある状況
  • すでにあるデータの活用から始める
    • 使えるデータがすでにあるなら、まずはそれを活用するのもひとつの手

より良いUXリサーチを目指す工夫

  • ウォークスルーをやってみる(調査する前に模擬的にやってみる)
  • 自分1人で振り返りする
  • 他の人にフィードバックを依頼する
  • 他の人のスタイルから学ぶ

「実はもう始めていたUXリサーチ」の例のように、普段からユーザー目線で考えることを1歩進めることで、「UXリサーチ」になり得る or つながることになる、というのは良い視点だと感じた。

Chapter3 UXリサーチの組み立て方

UXリサーチで歩む7つのステップ

  1. 状況理解
  2. 問い立案
  3. 手順設計
  4. 調査準備
  5. 調査実施
  6. データ分析
  7. 結果活用

全体を「UXリサーチの運用」と捉える。

組み立て方の概要

大きく2つのパートに分けて考える。

1.状況理解
2.問い立案 3.手順設計

なぜやるのか、何を明らかにするのか、を明確にするパート。
状況を理解することで、自分たちが何が分かっていないのか、何を調べて明らかにするべきなのか考えやすくなる。

4.調査準備
5.調査実施
6.データ分析

何をどのように明らかにするのかを決めるパート。

状況理解

どのような背景でこの事業がはじまっているか、リソース(ヒト・モノ・カネ)をどのくらい活用できるか、権限はどの程度持っているか or 必要か、等を状況理解で行う。

問い立案

「状況理解」で把握した内容を加味して身の丈にあった「問い」を立てて関係者と合意する。
また身の丈に合わせるために「明らかにしないこと」も明確にしておく。

手順設計

  • 調査対象を決める
  • 調査・分析手法を具体化する
  • スケジュールを決める
  • 調査の実施手順を具体化する

また、調査結果がどのようにプロジェクトで活用されていくのかを明確にイメージすること、を考えるのが効果的。

調査準備

  • 調査の実施手順を具体化する
  • 協力者を集める準備を進める

Chapter4 UXリサーチの手法を知る

だいたい以前読んだユーザビリティエンジニアリング(第2版)と同じ内容の掲載。
この書籍の目的に書かれている通り、手法を細かく記しているわけではないので、ユーザビリティエンジニアリングの方が詳しい。

Chapter5 UXリサーチを一緒にやる仲間の増やし方

段階に応じた仲間の増やし方

  • まずは一度引き込む
  • 継続的な関係を構築する
  • より広く・多くの人に認知してもらう
  • UXリサーチを文化にする

ますは一度引き込んでみよう

  • UXリサーチという単語を使わず、相手の視点から説明する
  • 小さく実績を作って共有しながらおすすめする
  • キックオフとラップアップで関わりやすい雰囲気をつくる

なぜUXリサーチという手段を用いると良いのかを引き込みたい相手の視点から語る とよい。
関係者が「目的を達成できそうな手段だから使ってみたい」と思われればよい。

継続的な関係を構築しよう

  • UXリサーチが必要な状況を察知できるようにする
  • UXリサーチに関する情報を蓄積して参照しやすくする

より広く・多くの人を引き込もう

  • 組織の中で情報発信する
  • 外部に情報発信して、組織の中に伝搬させる
  • 主体的にUXリサーチを継続できる人を増やす

主体的に継続してくれる仲間が増えることは、長い目で見れば組織でUXリサーチを活用できる機会が広がる。

UXリサーチを文化にしよう

UXリサーチを活用して、ユーザーとともに価値のあるサービスを作っていく文化を根付かせることを考える。

  • UXリサーチを続けやすい仕組みの整備
  • 定期的な勉強会や相談会の開催
  • UXリサーチャーという役割の定義
  • 専任のUXリサーチャーの採用や育成
  • UXリサーチチームの組織化

このあたり難しいなあと感じます。
案件でなかなかUXリサーチ何かしらやってます、という話はそこまで多く聞かないので、それこそこの本で書かれているようにスモールスタートでやっていくことが必要なのかなと思いました。

Chapter6 UXリサーチを活かす仕組みの作り方

ResearchOpsとは

UXリサーチの運用を単に効率化するだけでなく、標準化して品質を保つことや仕組み化していくこと。
ResearchOps Community というコミュニティもある。

ResearchOpsには6つの要素がある。

  1. リクルーティングの効率化
  2. ガバナンス
  3. ツール
  4. ナレッジマネジメント
  5. コンピテンシー
  6. 広報活動

概念的には他のOpsと同じ感じですが、文化的な雰囲気がします。

ツール

Dovetail というもの始めて知りましたが、こういう感じで分析できるの楽しそうですね。
私の愛するリサーチツール「Dovetail」について語らせてください|mihozono|note

Chapter7 UXリサーチのケーススタディ

事例のラインナップ

筆者がメルペイで行ってきたUXリサーチのプロジェクト事例

  • 利用上限金額の設定機能
  • ブランディング直後のサービス認知や利用実態の把握
  • おくる・もらう(送金サービス)
  • 定額払い
  • 初期設定フロー
  • Weekly UXリサーチ(週次のUXリサーチ日の設定)
  • リモートUXリサーチ

これまでの始め方、組み立て方、手法を踏まえて実際にはどのように行ったかが記されている。
ひとつのプロジェクトの粒度や、具体的にどのタイミングでどのようなことをしているのかが分かりやすかった。

感想

改めて、なぜUXをやる必要があるのかを考えるきっかけになった気がします。
個人的には、流行りや必要に迫られての部分もありますが、これまで一方方向だった作ることから、一歩踏み出しして使う人の意見を聞いてみて、それをもとに作る、ということで何かしら気づきや自身の成長ができるのではないかな、という期待があるからだと思い起こしました。

ちょっと思い出したつながりで、オフィスで働いていたときは「これが使いやすいか、見えやすいか」みたいな話はすぐ近くの席の人に聞きやすかったり話してたが、今はそのような細かいところは自身の感覚や判断で過ごしてしまっているのではないかと反省。
共通言語でものを作れることや、良い or 悪いの基準や感覚が揃っていることは、とても大事と思っているのでそのあたり見直しながら仕事をしたいなと思いました。

【読書メモ】UXデザインの法則 ―最高のプロダクトとサービスを支える心理学

目次・概要

  • CHAPTER1 ヤコブの法則
  • CHAPTER2 フィッツの法則
  • CHAPTER3 ヒックの法則
  • CHAPTER4 ミラーの法則
  • CHAPTER5 ポステルの法則
  • CHAPTER6 ピークエンドの法則
  • CHAPTER7 美的ユーザビリティ効果
  • CHAPTER8 フォン・レストルフ効果
  • CHAPTER9 テスラーの法則
  • CHAPTER10 ドハティのしきい値

著者である Jon Yablonski さんの Laws of UX というWebサイトから10の法則を紹介している本です。

「UXデザインの法則」という本ですが、実際にはUIやユーザビリティに関するTips集といった所感。
同じ類の書籍はオライリーから出ていますが、インタフェースデザインの心理学 シリーズや 「インタフェースデザインのお約束」 よりは広義のUI(UX)について書かれています。

原書 のカバーのほうがおしゃれです。

ポイント

CHAPTER1 ヤコブの法則

ユーザーは他のサイトで多くの時間を費やしているので、あなたのサイトにもそれらと同じ挙動をするように期待している。 - ユーザーが慣れ親しんだプロダクトと見た目が似ていれば、同じように動くことを期待される。 - すでにあるメンタルモデルを活かせば、ユーザーは新たなメンタルモデルの学習なしにタスクに集中でき、ユーザー体験の質が高まる。 - 変更時の違和感を最小限にとどめるためには、慣れ親しんだバージョンを使い続けられる移行期間を設けよう。

Jakob Nielsen さんが2000年に提唱した法則。

  • ページの構成や定番の要素(ナビゲーションや検索)の配置に、普及したデザインパターンや慣例を活用する。
  • ユーザーは他のウェブサイトでの経験の積み重ねを通じて「デザインはこうあるべき」という期待を築き上げる傾向がある。
    • その要因の根源には、メンタルモデル という心理学の概念がある。
      • メンタルモデルとは、システム、特にそのふるまいについて、わたしたち自身がどう理解しているかという概念のこと。
  • 大規模なリデザインを行う場合はGoogleのサービス(GoogleカレンダーYouTubeGmail)のように、ユーザーが新たなバージョンを使うか選択できるようにしましょう。

Gmail最近新デザイン展開されてましたが、自分はすぐに試す派です。 - Gmailの新デザインの展開が個人アカウントに対しても開始 | ソフトアンテナ

どこまで他のサイトのレイアウトや動きを活用するかは難しいところではあるなと感じます。
ただ本の中でも触れられていますが、このような「同質化」の多くはデザインの慣例に従っているまでで、レイアウト、ナビゲーション、スタイル、検索機能の場所などすべてがバラバラだとすると、ユーザーは以前の経験に頼ることができなく腰砕けになってしまう。
デザイナーは独創的である前に、ユーザーのニーズや文脈、それと技術的な制約を常に考えて最適な方法を選び抜かないといけない、と記されています。

CHAPTER2 フィッツの法則

ターゲットに至るまでの時間は、ターゲットの大きさと近さで決まる。 - タッチターゲットには、ユーザーが正確に押せるために十分な大きさが必要だ。 - タッチターゲット同士は、十分な間隔が空いていなければいけない。 - タッチターゲットは、インターフェース内で、ユーザーが簡単に到達できる場所に置かれてなければいけない。

Paul Fitts さんが1954年から予測、提唱した法則。

  • ユーザーが対象に到達するのにかかる時間は対象の大きさと近さに反比例する
  • モバイルインターフェースでは、画面の中でタッチできる範囲が限られているため、とりわけこの法則が重要になる。

タッチターゲットの推奨最小サイズ

企業・組織 サイズ
ヒューマンインターフェースガイドラインApple 44 x 44 pt
マテリアルデザインガイドラインGoogle 48 x 48 dp
ウェブコンテンツアクセシビリティガイドライン(WCAG) 44 x 44 CSS px
Nielsen Norman Group 1 x 1 cm

タッチターゲットの要素の間隔 Googleマテリアルデザインガイドラインでは「8dp以上の余白を空けること」とされている。

タッチターゲットの位置 デスクトップでは一般的に左上から右下に目を走らせる。 スマートフォンでは画面中心部に焦点が寄りやすい。

どこに焦点が当たりやすいかと、どこに届くか、も考えなきゃですね。 - Mobile UX Design in 2022: A Complete Guide | Net Solutions

タッチターゲットのサイズについては所属の会社の仕事の場合、例えばハンバーガーメニューのタップ範囲についてデザイナーさんから「タップエリアはここからここまで」という指示があるのは稀なので、マークアップエンジニアのさじ加減でやっている感じです。

CHAPTER3 ヒックの法則

意思決定にかかる時間は、とりうる選択肢の数と複雑さで決まる。 - 応答に時間がかかって意思決定が遅くなっているときは、選択肢を最小限にまで減らそう。 - タスクが複雑なら、小さなステップに分解して認知負荷を減らそう。 - ユーザーが情報量に圧倒されないように、おいすすめの選択肢を目立たせよう。 - 段階的なオンボーディングを採用し、新規ユーザーの認知不可を最小限にしよう。 - 単純化によって抽象的になりすぎないように注意しよう。

W. E. Hick さんと Ray Hyman さんによって1952年に定式化された法則。

  • インターフェイス上であまりに多くの選択肢があると、効率も優雅さも失われてしまう。
  • プロセスで面でも、わかりやすく目に入る行動喚起要素がない、情報設計が曖昧、ステップに無駄がある、選択肢が多すぎる、情報を盛り込みすぎる・・・、これらすべてがタスクを実行しようとするユーザーの妨げになる。
  • オンボーディングはSlackbotのようにメッセージでユーザーが学習し終えてから段階的に追加機能の説明が始まるのが有効となる。

悪い/良いナビゲーション構造 - Hick’s Law: Making the choice easier for users | Interaction Design Foundation (IxDF)

本のなかでは認知負荷についても触れていますが、ユーザーが最終的に達成したい目的が合った上で

  • UIがどのように動くか
  • 目的のものをどのように探さないといけないか

に対してメンタルリソースが求められ、しかも「そもそも何をしたかったのか」を覚えておく必要がある、というのは大事なポイントだと感じました。
どうしても作っていると「UIがどのように動くか」のみに囚われがちなため。

CHAPTER4 ミラーの法則

普通の人が短期記憶に保持できるのは、7(±2)個まで。 - 「マジカルナンバー7」の数字に惑わされて無用なデザイン制約を作ってはいけない。 - コンテンツを小さなチャンク(かたまり)に分けることで、ユーザーがその情報を扱い、理解し、記憶しやすくできる。 - 短期記憶の容量は、個々人が持っている知識や状況、文脈によって大きく幅があることを覚えておこう。

George Armitage Miller - Wikipedia さんが1956年に発表した論文に由来。

  • ミラーの発見の中心は、制約のある短期記憶を最大限有効活用するために、情報の断片をいかに意味のあるチャンクに整理するかということである。
    • 保存できるチャンク数の上限は、その情報に関する個々人の前提条件によって異なっている。
    • 例えば、ナビゲーションの選択肢は常に見えているもので、適切にカテゴリ分けをしていれば7個以上でも成立する。
  • チャンク化の最も単純な例は、電話番号の書式
    • 4408675309
    • (440) 867-5309
  • もう少し複雑な例は階層性や書式が全くないこと。

✕のほうは「文字の壁(wall of text)」と呼ばれるらしい。 - ウェブ・ユーザビリティの簡単9原則 | knowledge / baigie

主に情報設計やデザイン領域の話になるので、エンジニアは意図を汲み取ってスタイリングすることが大事そうです。

CHAPTER5 ポステルの法則

出力は厳密に、入力は寛容に。 - ユーザーがとりうるアクションや、入力しうる情報すべてに対して理解を示し、柔軟に対応し、寛容であろう。 - 信頼性高くアクセス可能なインターフェースを提供しながら、入力、アクセス、および機能の面で実際に起こりうるあらゆることを予測しよう。 - 予測・対応できることが多ければ多いほど、デザインはより柔軟になる。 - ユーザーからの多様な入力を受け入れ、それを要件に合わせて変換し、入力の境界線を定義し、ユーザーに明確なフィードバックを提供しよう。

Jon Postel さんがTCPの初期実装の際に「ロバストネスの原則」と呼ばれる考え方を導入。もともとはコンピュータネットワーク間のデータ転送を意図したものだったが、ユーザー体験のデザインにも応用されている。

  • ユーザーにとって良い体験をデザインすることということは、人間にとって良い体験をデザインするということ。
    • わたしたちは、プロダクトやサービスが自分のことを直感的に理解してくれていて、寛容であることを期待している。
    • また、常に自分がコントロールできていると感じたがり、必要以上の情報を求められるとイライラしてしまう。
  • ユーザーが、どのような環境で、どの程度のスキルがあるのかについて、実際に起こりうるあらゆるパターンを予測した上で、信頼性やアクセシビリティが担保されたインターフェースを提供すべき、という考え方。
    • 例として、Apple の Face ID、レスポンシブウェブデザイン、プログレッシブエンハンスメントなど。

閉じタグがなくても表示されるHTMLの例 - ポステルの法則 | UX TIMES

やはり身近なのは入力フォームのバリデーションでしょうか。
全角縛りや予測できないエラーなどはいちユーザーとしても辛いですね。

CHAPTER6 ピークエンドの法則

経験についての評価は、全体の総和や平均ではなく、ピーク時と終了時にどう感じたかで決まる。 - ユーザージャーニーの中で最も重要な瞬間(ピーク)と最後の瞬間(エンド)に細心の注意を払おう。 - エンドユーザーを喜ばせるためには、プロダクトが最も役立つ瞬間、最も価値がある瞬間、あるいは最も楽しい瞬間を見定めてデザインしよう。 - 人はポジティブな経験よりも、ネガティブな経験をより鮮明に思い出すことを心に刻んでおこう。

Daniel Kahneman さんらの1993年の論文ではじめて見い出された法則。

  • わたしたちの記憶は、できごとを完全に正確に記録したものではない。
  • ユーザーは最も感情が高まったときに感じたことと、終わりの時点で感じたことが混ざり合い、それが経験全体に対する評価を大きく評価する。
  • Mailchimpの例
    • 会員向けに書き上げたメールの送信ボタンを押そうとする瞬間が「最も感情が高まるとき」
      • シンプルな確認モーダルにとどまらず、イラスト、アニメーション、ユーモアを通してブランドの個性を吹き込むことで、ストレスの多い瞬間を和らげる。
    • 送信確認画面でリダイレクトされるキャンペーン詳細画面が「終わりの時点で感じたこと」
      • ユーザーの頑張りをねぎらうハイタッチのアニメーションで、やりきった安堵感を与える。

IKEAでのショッピング体験もピークエンドの法則の活用事例として挙げられる - ピークエンドの法則:用語集 | UX TIMES

まずジャーニーマップのような設計をしていることが前提ですが、UXっぽい法則ですね。
メールチャンプはどのUXの書籍でも事例として出てくる印象です。

CHAPTER7 美的ユーザビリティ効果

見た目が美しいデザインはより使いやすいと感じられる - 見た目が美しいデザインは、人の脳にポジティブな反応をもたらし、実際の場面でもよく機能すると受け取られる。 - プロダクトやサービスの見た目が美しければ、人は些細なユーザビリティの問題に対してより寛容になる。 - 見た目が美しいデザインはユーザビリティの問題を覆い隠し、ユーザビリティテスト中に課題を発見しにくくしてしまうこともある。

1995年に日立デザインセンターの 黒須正明 さんと鹿志村香 さんが実施した研究が起源となる効果。

  • 見た目が美しいデザインは、ポジティブな感情的反応を生み出すとともに認知能力を拡張しユーザビリティがよいと感じやすくする、且つ信頼性を高める。
  • Braun や そのデザイン哲学に影響を受けている Apple プロダクトの例。

iPodiPhoneiMacなどのデバイスは、使いやすさを重視しながらも、Braunの製品群からミニマルな美しさを受け継いでいる - アップル製品と約50年前のブラウン社の家電製品がどれくらい似ているか比べてみた - DNA

iOSの電卓もBraunと似ており、インターフェースにも落とし込んでいるのが面白いですね。
ユーザビリティの問題を覆い隠してしまうところは、例えばユーザーインタビューはモックアップから段階的に行うことが解決策かなと思いました。

CHAPTER8 フォン・レストルフ効果

似たものが並んでいると、その中で他とは異なるものが記憶に残りやすい。 - 重要な情報やアクションを視覚的に目立たせよう。 - 視覚的な要素を強調する際には、互いに競合したり、目立ちすぎて広告だと勘違いされたりしないようにしように抑制をかけよう。 - コントラストを伝えるのを色だけに頼ると、色覚障がい者やロービジョン(弱視者)を排除することにつながる。 - コントラストを伝える上で動きを使用する際には、動きに対し敏感なユーザーに配慮しよう。

Hedwig von Restorff さんの1933年の研究を起源とする効果。

  • 人は周囲へ集中力のキャパシティと持続時間の制約から、関連性のない情報を犠牲にいして関連する情報に集中する。
    • これは認知心理学では「選択的注意」として知られている生存本能
      • 一例としてはバナーブラインドネス(広告だと認識されたものが無視される性向)
  • 実例

周囲のパターンと似通っていると□や赤丸と違って特異性があると認識しづらい - レストルフ効果 | UX TIMES

デザイン4大原則の「強弱」や、先ほどのミラーの法則にもつながるところかと思います。
逆にあまり立たせ過ぎたり、その量を増やすと力が薄れ、他の要素に埋もれやすくなるのでデザイナーさんの腕の見せどころといった印象です。

CHAPTER9 テスラーの法則

どんなシステムにも、それ以上減らすことのできない複雑さがある。複雑性保存の法則ともいう。 - どんなプロセスも、その核となる部分にはデザインの工夫をもってしても取り除くことのできない複雑性を抱えている。この複雑性による負荷を負うのは、システムかユーザーだ。 - この固有の複雑性をデザインと開発の過程でどうにかしながら、できる限りユーザーの負荷を減らそう。 - シンプルにしすぎてインターフェースが抽象的になりすぎていないかを気にしよう。

Larry Tesler さんがDTP開発の鍵となる対話型システム言語の開発に携わっていたときに発見した法則。

  • どんなプロセスにも固有の複雑性というものがあり、これ以上減らせずどこかにしわ寄せするしかなくなるときが必ずやってくる。
  • 例としてEメール送信では、差出人と宛先の2つの情報が必要だが、最近のメールアプリでは2つのことが行われている。
    • 差出人を事前に入力しておくことと、宛先の入力開始時に候補をサジェストすること。

優れたデザインは、複雑さの負担がユーザーではなくサービス側で処理する必要がある。 - UXデザイナーなら知っておきたいデザインに関する10の法則 デザイン会社 ビートラックス: ブログ

後から追加で出てくる仕様のようなことではなく、サービスを提供するにあたって本質的に必要なプロセスでも複雑性は介在する、といった内容と理解しました。
現場の立場からすると、どこにしわ寄せがいってるかを対処する人以外が把握できているかも大事な気がします。

CHAPTER10 ドハティのしきい値

応答が0.4秒以内のとき、コンピューターとユーザーの双方がもっとも生産的になる。 - 0.4秒以内にフィードバックを行うことで、ユーザーの注意を引きつけ、生産性を高めよう。 - 体感性能を改善し、感じられる待ち時間を減らそう。 - アニメーションをいれることで、バックグラウンドで読み込みや処理が行われている間も、ユーザーをつなぎとめられる。 - プログレスバーは、正確であってもなくても待ち時間へのいらだちを和らげる。 - ほとんど処理時間がかかっていない場合でも、意図的に遅延させることで体感性能が改善して信頼感の醸成につながる。

IBM社員のWalter J. Doherty さんと Ahrvind J. Thadani さんによって提唱された基準。

  • 人は0.1秒程度の応答時間であればほとんど気づかない。しかし、0.1〜0.3秒の遅延になると目につくようになり、同時にタスクをコントロールできないと感じ始める。
  • 規定時間を短縮できない場合、何かしらフィードバックを返すことが有用。
    • ケルトンスクリーンを表示
    • ブラーアップ(画像を初期はぼかし表示)の利用
      • Mediumの例
    • プログレスバーの表示
      • Gmai、AppleのOSアップデートの例
    • 楽観的UI(処理完了前に楽観的なフィードバックを提示)

ローディングプレースホルダーよりもスケルトンスクリーンという方が一般的なよう - UXを向上させる5種類のアニメーションの使い方 | UX MILK

フィードバックの仕方について、フロントエンドの実装では時間がかかればかかるほど、ユーザー体験はよくなりそうな印象でした。( プログレスバーよりもローディングアニメーションのほうが簡単など)

感想

どの法則も言われてみればそうだなと感じる反面、いざ制作や開発をしている際に説得力を持って持って言えるかは、知識的なところも必要なのかなと感じました。
すべてのプロジェクトでこのような話ができない場合もありますが、常に具体例を出して伝えて改善できるように日々ウェブサイトやアプリを見てみようと思いました。

AWS認定試験 プラクティショナーから始めた人のためのアソシエイト資格取得

🔰 対象読者

  • クラウドラクティショナーを取得済みで、次は各アソシエイト資格にチャレンジしようとしている方
  • 開発、インフラ構築以外の業務を普段行っている方

💡 背景

業務でAWSに触れる機会が少なめな人観点での記事は少なく感じましたので、かなり主観が入ったものにはなりますが、それらを踏まえて共有のためにまとめてみました。

なお、2年ほど前に各アソシエイト資格を取得した際の記憶ため、一部情報が古かったり記憶違いがあるかもしれません。
出題内容等についても詳しくは書いていませんのでご了承ください。

🐥 前提

業務でのAWSとの関わり

主にHTML/CSSでのマークアップを行っており、業務でAWSに触れる機会は多くありません。
S3バケットGUIを使用してファイルをアップするのが定期的に触れる程度です。

アソシエイト資格までの取得経過

受験日 試験名 結果 スコア
2019/6/8 CLF 合格 830点
2019/7/6 SAA 不合格 630点
2020/1/4 SAA 合格 771点
2020/2/9 DVA 合格 845点
2020/2/14 SOA 合格 801点

CLF(プラクティショナー)に合格し、調子に乗ってSAAを受けて一度不合格でして、その後半年は諦めていました。
再びやる気が起きて年明けにSAAに合格し、DVASOAもその勢いで受けました。

🛤️ 受験まで

おおまかな流れ

  • 受けてみようかな♪
  • 情報収集
    • 試験ガイドを見る
    • サンプル問題をチラ見する
    • いろいろググって体験記を漁る
    • 対策本を買う
  • スケジュール
    • 受験日をざっくり決める
      • なんとなく案件が落ち着いていそうな頃を見計らう
    • スケジュールを引く
      • 受験日から逆算して、いつにどこまで本読んだり問題集解くか
        • 平日2〜3hでこなせる量にして週末は少し多めに設定する
  • 勉強(できる限り繰り返す)
    • サンプル問題を解く
      • 落ち込む
    • 公式の対策動画を見る(デジタルトレーニング・ある資格のみ)
    • 対策本を一通り読む、付属する問題集を解く
      • 落ち込む
    • 模擬試験を受ける
      • 落ち込む
    • BlackBeltを見る、読む
    • まとめスプシ見直す
  • 受験

ポイント

反復する

1度で全てを暗記しようとするとパンクしてしまうので、例えば対策本を読む際は、1周目を出題範囲の把握のみと割り切って最後までとりあえず読むことを意識しました。
2周目以降はある程度用語に馴染みが出てくるので、気になったものは追加でググるなどしました。

苦手なサービスはBlackBeltで補完する

ラクティショナーの際には使ってませんでしたが、出題範囲でメインになりそうなサービスや、問題集で理解が不足しているサービスはBlackBeltを通して理解を深めました。
動画があるものは1時間弱の尺ですが、全てを頭に入れるのは難しいため、ある程度出題される内容を把握した段階で見るのがおすすめです。

自分にとって理解しやすい解説を探す

同じ機能の解説なのに、書籍では分かりづらいけど、BlackBeltや公式のFAQでは分かりやすいみたいなことが時々ありました。
あまりその媒体の解説に固執しないでググってみるのも手かもしれません。

まとめスプシを作る

スプレッドシートを作成して頻出サービスの理解しづらいところを都度まとめておき、受験前に見直す方法が漏れなくできたと感じます。

📙 各試験の対策

私が対策した内容を書きますが、今考えるともう少しやり方は違うほうが良いと思いますので、失敗した部分も含めて記載します。

例えば、65問セットの問題集は1度の問題数が多く、難易度もバラツキがあったりするため、今からやり直すのであれば、 AWS WEB問題集で学習しよう(koiwaclub) を使う、などです。
対策本についても新しいものが出ていると思うので、そちらをおすすめします。

AWS Certified Solutions Architect - Associate(SAA)

対策本

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト
SAAのときだけでなく、他の2つの試験前にも読みました。

問題集

【2022年版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問)
めっちゃ難しくてへこみまくりました。
問題集は解説を読んだり調べたりする時間のほうが多くなりがちだったので、それを踏まえて教材選びしたほうがいいと思います。

ハンズオン

【2022年版】これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座
ハンズオン形式で結構やった意味があった記憶があります。これだけでOKではなかったです。

所感

アソシエイトがはじめてだったので問題文が長いなというのと、範囲が広いなと思いました。
ハンズオンはUdemyでなくともサービス網羅できるような教材をこなしておくと自信がつきました。
1度不合格になった際はこんな難しいの無理と思っていましたが、やればできました。

AWS Certified Developer - Associate(DVA

対策本

AWS認定アソシエイト3資格対策~ソリューションアーキテクト、デベロッパー、SysOpsアドミニストレーター~
当時専用の書籍はなかったのでこちらを読んでました。

現在はDVA用でありますのでこちらをおすすめします。
ポケットスタディ AWS認定 デベロッパーアソシエイト (アソシエイト試験ポケットスタディ)
DevOpsプロフェッショナルの受験前に読んだのですが、DVAのためと思うと詳しすぎるため若干オーバースペックな印象でした。

問題集

AWS 認定デベロッパー アソシエイト模擬試験問題集(5回分325問)
これも難しかったです。

ハンズオン

ハンズオンはどれもやってみて身になった印象があります。

所感

それなりに1ヶ月勉強して割とやっとで合格だったため、巷で言われている「SAA取れたらDVAも簡単」は普段AWS触っている開発者目線の話かなと思いました。
API GatewayやCodeシリーズなど開発案件に携わっている方は少しはなじみのある用語が多いため、とっつきづらさはそこまでない印象です。

AWS Certified SysOps Administrator - Associate(SOA

問題集

AWS Certified SysOps Administrator Associate
当時Udemyで問題集がなかったため、Whizlabsという海外のサイトを利用しました。
こちらも本番よりちょい難しかった感触です。

所感

はじめにサンプル問題やってみたら全問正解できてしまったので、DVAの受験から1週間挟まずに勢いで受験しました。
SAAのときにあやふやにしていたCloudWatch周りの設定値など、結局はここで覚えることになるんだなと思った記憶があります。
現在はハンズオンがあるとのことなので、合格できる自信はありません。

💬 受験する前に知りたかったこと

どのくらい勉強すれば受かるのか

もともとの関心度合いや、プラクティショナー含め前回受験からの期間等、人によってまちまちだと思います。
私の場合、

  • SAA:60h
  • DVA:40h
  • SOA:20h

ほどの感覚で、後にいくにつれて前回までの上積みが活かされる感覚でした。

アソシエイト資格に1度合格していると、ここまで理解できていれば受かりそう、というラインも分かってくる気がしています。
※ 私の場合は、解答の選択肢を見なくても問題文を読んだ段階で答えが分かるものが50%くらいになったら、がそのラインです。

アソシエイトの中でどれが一番難しいのか

こちらも人にはよると思いますが、私の場合はSAAが一番難しかったです。
勉強した時間に比例してそう感じるところもありますし、プラクティショナーと比べると長い問題文に慣れるところもあり難しく感じました。

受験する順番はどうすればいいのか

最初に受けるのはSAAがおすすめです。
SAAが網羅的で、DVASOAは細部を聞かれる問題が多い印象のためです。
その後、DVASOAの順にしましたが、SAAとの被り具合はSOAのほうが大きい印象のため、SOADVAのほうが正攻法かもしれません。
開発知識のある方は一番最初にDVAがとっかかりやすい場合もあると思います。

ハンズオンはしたほうがいいのか

できる限りしたほうがいいと思います。
私もハンズオン面倒くさがってあまりしてきませんでしたが、画面いじった経験のあるものはその後記憶に入りやすく、問題文を読んだ際にもイメージがしやすかったりしたためです。

アソシエイト3資格を取得したらAWSをどのくらい理解できるのか

業務上で使用する観点では、深くは理解できている状態でないと思います。
マークアップでも同じことが言えると思いますが、例えば職業訓練校の課題で作られるコードと、案件で納品までに作られるコードはほぼ別物だと思うので、そのような雰囲気です。
※ metaの設定、コンソールエラーやブラウザチェック等までを自主学習でできる人は少なく、仕事で複数案件リリースまでして理解できることが多いなど、そのような雰囲気です。

さいごに

向き不向きがありますし、何に学習機会を費やすかは人それぞれかなと思います。
私は社内での会話で分からないことが少なくなったりすることが資格取得を通して特に良いことかなと感じました。

長くなってしまいましたが、もし受験の際の手助けになりましたら幸いです。

AWS DevOps エンジニア プロフェッショナル 受験記

f:id:jotaki:20200105065609p:plain

これまで・今回の結果

受験理由・モチベーション

ここまでやったら取りたいなの精神で。

今回分の勉強計画

合格記を見ているとSAP取れればDOPも取れる風潮がありますが、SAA → DVAのときになかなか苦戦したので、そこは信じずこれまで通り公式リソース + koiwaclub で行こうと思いました。
またSAPはダラダラやってしまったので、今回は2ヶ月で仕留められるように予定を組みました。
※ 結果は約3ヶ月

やったこと

  • 【公式】Exam Readiness: AWS Certified DevOps Engineer – Professional
  • 【公式】サンプル問題の受験・復習
  • 【読書】ポケットスタディ AWS認定 デベロッパーアソシエイト
  • 【問題集】koiwaclub の DOP問題集
  • 【公式】模擬試験の受験・復習
  • 【公式】BlackBelt Online(YouTube中心に)

【公式】Exam Readiness: AWS Certified DevOps Engineer – Professional

SAPのときのおじさんではなくて残念でしたが、DOPのほうが細かく動画での説明されていました。
ただ量も多いので誤訳などもちょくちょくあり頭に入りづらかった印象です。
だいたいの範囲はここで把握しました。

【公式】サンプル問題の受験・復習

4月の中旬に最初に解いてみて3/10。
おそらく今までで一番取れていないので長くなりそうだな・・・と思いました。

試験当日にもう一度解いてみて8/10。
ちょっといけるかもと思いました。

【読書】ポケットスタディ AWS認定 デベロッパーアソシエイト

感想
DVAのときこんなに覚えたかなというくらいには細かく載っているので、DOP対策にもなるんじゃないかと思いました。

3ヶ月だいたい寝る前に読んで3周。

【問題集】koiwaclub の DOP問題集

7問1セットの計47セットを2周。

【公式】模擬試験の受験・復習

koiwaを1周した5/9に受けてみる。

総合スコア: 55%
1.0 SDLC Automation: 75%
2.0 Configuration Management and Infrastructure as Code: 33%
3.0 Monitoring and Logging: 66%
4.0 Policies and Standards Automation: 66%
5.0 Incident and Event Response: 0%
6.0 High Availability, Fault Tolerance, and Disaster Recovery : 100%

難しくスコアもひどいものでしたが、DOPはそんなもんという記事を見ていたので平静を装いました。
Incident and Event Response は CloudWatch Events あたりが主なのでその後は少し意識して勉強。

【公式】BlackBelt Online(YouTube中心に)

受験前日6/4に一通りみる。

覚えたこと

主に Exam Readiness や koiwaclub で頻出するものなどは公式ドキュメントなど見て復習。
NRIネットコムさんの AWS 認定 DevOps エンジニア – プロフェッショナル(AWS Certified DevOps Engineer – Professional)の学習方法 も参考にしました。

  • AMI
    • 事前作成のAMI
    • ゴールデンイメージ
  • AutoScaling
    • AMI の起動設定
    • ライフサイクルフック
  • Beanstalk
  • API Gateway
    • リリース手法
    • エラーシューティング
  • CloudFormation
    • テンプレート構文(Parameters, Conditions, Mappings, Outputs..)
    • DeletionPolicy
    • カスタムリソース
    • デプロイ対象(Auto Scaling Group, Lambda)
    • デプロイ手法とロールバック
    • CodePipeline を使ったデプロイ
  • CodePipeline
    • CloudWatch Events との連携
    • カスタムアクション
  • CodeCommit
    • IAMポリシー
    • ブランチとステージ
  • CodeDeploy
    • デプロイ対象(Auto Scaling Group, Lambda)
    • デプロイ手法とロールバック
    • CodePipeline を使ったデプロイ
  • CloudWatch
    • Logsのカスタムメトリクス
    • Eventsでできること
  • Systems Manager
    • Automation
    • Run Command
    • Patch Manager
  • Trusted Advisor
    • CloudWatch Events との統合
    • サービス制限
    • キー漏洩時の対応
  • その他
    • ECS/ECR
    • Config + Lambda, GuardDuty, Inspector
    • Health Dashboard
    • Service Catalog

本試験

オンラインで受験。
2回目の再受験が無料キャンペーン をしていたので、最近そこまで身が入ってなかったけど1回受けてみようと考えました。

2hちょっとで一通り完了してトイレ行きたくてすぐに終了。
手応えは、

30%: 正解
20%: たぶん正解
40%: 微妙
10%: 不正解

のような感じ。

結果スコアは845点とのこと。思ったより取れてました。
分野ごとの成績がPDFに入ってなかったけどまだ処理中なのかもです。

まとめ

振り返ってみると4月頭から勉強していたのでそれなりの勉強量だったのですが、ここ何週間かサボってしまっていたので、合格と出たときは受かっちゃったなーという感想。これまでで一番手応えない内容でした。

ラクティショナー → アソシエイト → プロフェッショナルの順で6個目とれました。
SAP取れたときにも感じましたが取る前にイメージしていた理解度には到底及んでいなく、勉強すればするほど分からないことも増えていきます。

調子乗ってSCSとか受けるとまた沼にハマるので、本当にここでAWS資格はおしまいです。
3年後の更新はそのとき考えます・・・

2021年3月 振り返り

結果

ブログ

目標:月 8 回(週2回)更新
結果:月 10 回 更新

読書

目標:月 1 冊
結果:月 3 冊

反省点など

満遍なくインプットできました。

来月に向けて

AWS資格と並行しつつフロントエンド領域もとなると難しいですがなんとかやっていきたいです。