【読書メモ】オブジェクト指向UIデザイン ─ 使いやすいソフトウェアの原理

UI/UX系の知識を身につけるということで、少し前に発売して話題にもなった「オブジェクト指向UIデザイン」を読みました。

UIまわりの本ですが、こういうボタンはどういう見た目にしよう、のようなスタイル的な話ではなくソフトウェアの設計が主題です。

タイトルに入っている「オブジェクト指向UI(OOUI)」について、特にスマホアプリを普段扱っている人にとってはおそらく慣れた(普段から意識している)指向なのかなと思います。
ただ実際にソフトウェアを設計する際の方法論や実例を学ぶことなく「なんとなく」決めていることが多いと感じています。(自身はそうでした)
この本にはその方法論や実例が多く説明されていたので、気に留めておこうというポイントを中心にメモしておきたいと思います。

目次

使いやすい or 使いづらいと感じる画面(UI)にはどんな特長があるのか、なかなか論理的・客観的に説明するのは難しいですが、技術評論社の記事 動詞ではなく名詞を起点に画面を構成する ~OOUIでソフトウェアを使いやすく~ にも書かれている通り、下記の考え方で設計することであらゆるソフトウェアの構成が整理され使いやすくなります。

タスクではなくオブジェクトを起点に画面を構成する。もっと一般的な言葉を使うと,「動詞(やること)」ではなく,「名詞(もの)」を起点に画面を構成する。たとえば「本を買う」であれば,「買う」ではなく「本」を起点にする。これだけのことです。ごくシンプルですよね。

4章の実践では、こういう要件があるものはどのような考えで作るのかが説明されていますが、本を通してメインで説明されている核は上記です。
5章のワークアウト基礎編では何個かお題があり、これまで説明された内容で自身でアプリケーションデザインをしてみて答え合わせしましょう、という内容です。
6章のワークアウト応用編では既存のタスク指向のアプリケーションをどのように改善すると良いUI(OOUI)になるかを考える設問と答えが掲載されています。

ソシオメディアさんというUI分野で古くから有名な会社に所属する方が書いており、さまざまなプロジェクトを通して得たノウハウが詰まっているように感じました。

ポイント

なぜオブジェクト指向UIなのか(はじめに)

ユーザーインターフェースという言葉は「コンピューター画面」などにとどまらず、使う人とその対象をつなぐものすべて。

そもそも扱うべき対象 = オブジェクトが「在る」という前提そのものが、UIの概念なのです。UIははじめから存在論的であり、オブジェクト指向なのです。

オブジェクト指向UIとは(p.9)

オブジェクト指向UIとは、オブジェクトを手掛かりに操作設計されたUIのことです。

オブジェクトとは、アプリケーションが扱う情報 オブジェクトのことであり、ユーザーが操作するときの対象物のことです。

例えば蔵書アプリの場合、最初に表示される画面で

  • 「登録する」「確認する」・・・などユーザが行うタスクを始点とするのではなく(動詞 → 名詞)、
  • 本の一覧表示でその中のひとつを選択すると編集作業や詳細ページでの確認ができるような、対象物が始点となるソフトウェア(名詞 → 動詞)

オブジェクト指向となる。

オブジェクト指向UIの原則(p.11)

  • オブジェクトを知覚でき直接的に働きかけられる
  • オブジェクトは自身の性質と状態を体現する
  • オブジェクト選択 → アクション選択の操作順序
  • すべてのオブジェクトが互いに協調しながらUIを構成する

タスク指向UIとは(p.17)

CLIのように、動詞を起点として設計された操作モデル。動詞 = やることを指向しているという意味
タスク指向の例としてATMや券売機、自動販売機など。

UIがタスク指向になってしまう背景(p.29)

UXへの注目の高まりによって、ユーザーの体験価値の向上がUIデザインのひとつの重要なゴールとして認識されてきていることも関係しているのではないでしょうか。

体験をデザインするということが、ユーザーの利用手続きをデザインするという意味で捉えられることが多いのです。

オブジェクト指向UIの設計プロセス ソフトウェアデザインのレイヤー(p.42)

モデル、インタラクション、プレゼンテーションのレイヤーに分けることができる。

  • モデル
    • ユーザーの関心対象の模式
      • ユーザーの特性、業務の形態、情報の書式、要求事項の種類と関係性などをもとに、システムが扱うオブジェクトの構成をモデリングする
  • インタラクション
    • 構造と機能(フィール)
      • 構造と機能に関する層。モデルとプレゼンテーションをつなぐためのメカニズム。CRUD(作成、閲覧、更新、削除)などが含まれる。
  • プレゼンテーション
    • スタイルやレイアウト(ルック)
      • 表層。オブジェクトを表象するグラフィックの形や色、画面レイアウトなど。

オブジェクト指向UI設計の基本ステップ(p.51)

ステップ1,2,3はどこからはじめてもOK、行きつ戻りつ進めていく。

  • ステップ1. オブジェクトの抽出(モデルレイヤー)
  • ステップ2. ビューとナビゲーションの検討(インタラクションレイヤー)
  • ステップ3. レイアウトパターンの適用(プレゼンテーションレイヤー)

下記の各ステップ例は学校名簿アプリケーションを想定

ステップ1. オブジェクトの抽出(モデルレイヤー)

  • タスクのサンプルを何個か挙げる
    • 「ある生徒が所属している部活を確認する」、「3年C組のある生徒の成績を確認する」など
  • 名詞を抽出する
    • 「ある生徒」「部活」、「3年C組」「ある生徒」「成績」など
  • 名詞とそれらの関係を抽出する
    • 「ある生徒」-「部活」、「3年C組」-「生徒」-「成績」など
  • 名詞を汎化し、粒度を揃える
    • 「生徒」-「部」、「組」-「生徒」-「成績」など
  • 名詞の関係性をつなげ、オブジェクトを特定する
    • 「成績」-「生徒」-「部」など
  • オブジェクトの中で「メインオブジェクト」となるものを特定する
    • 「生徒」など、ユーザーの関心領域に置いて主要なものは何か?を考える
  • メインオブジェクトに負づいするオブジェクトをプロパティとする
    • 「生徒」の場合、氏名/成績 など
  • タスクからアクションを見つける
    • タスクとは最初に挙げたもの。「新規」「削除」など。「確認」は詳細ビューで表示されるので特記しない。

ステップ2. ビューとナビゲーションの検討(インタラクションレイヤー)

  • 基本のビュー形式
    • コレクション(一覧)とシングル(詳細)の2通り。
    • メインオブジェクトにコレクションとシングルのビューを与える
  • コレクションビューとシングルビューの呼び出し関係を検討する
    • 互いに参照可能性のあるビューを矢印でつなぐ
  • メインオブジェクトの中からルートナビゲーションを選定する
    • メインオブジェクトで優先度の高いもの、ユーザがアプリケーションを使用する際に最初に思い浮かべるオブジェクトを選定する。
    • 動詞ではなくオブジェクト名を用いる(語尾に「管理」などを用いない)
    • ルートナビゲーションを選択すると、そのオブジェクトのコレクションが表示される

ステップ3. レイアウトパターンの適用(プレゼンテーションレイヤー)

特にこれは書籍の図解のほうが分かりやすいです。
(参考)ソシオメディアさんWebの UIデザインパターン

  • ルートナビゲーションの配置パターン
    • 下固定 / 開閉式
  • ビューの配置パターン
    • 単一メインオブジェクト / 複数メインオブジェクト
    • ドリルダウンの方向性(上→下、左→右、同ページなど)の決定
  • コレクションビューの表示パターン
    • コレクションの性質や用途に合わせて表示形式を決定
      • 1項目1行の1次元リスト / 1項目複数行の1次元リスト / 1項目複数行の1次元リスト(高さ可変) / サムネールのグリッド/ マッピング
    • フィルタリングのパターンとしては下記がある
      • キーワード検索 / グループ / AND条件 / クエリビルダー / ソート
  • シングルビューの表示パターン
    • 他のオブジェクトのコレクションの一部を表示する
    • 他のオブジェクトのコレクションを強調する
    • 他のオブジェクトのコレクションだけを表示する
  • シングルビューの性質や用途に合わせて表示形式を決定する
  • アクションの性質や用途に合わせて表示形式を決定する
    • 作成
      • ブランク / パラメータ / プレースホルダー / セーブアズ / テンプレート / マスター / ワンタイムモード / ガッツ
        • 印象に残ったので、ガッツパターンとは図形作成時などにオブジェクトを選択するとすぐにアイテムが作成されるもの。Keynoteの四角形作成など。「操作をモードレスにするためにガッツをみせた仕様」
    • 削除
      • モーダルコンファーム / アンドゥアブル / モードレスコンファーム
    • 更新
      • モーダルエディット / モードレスエディット
  • ビジュアルデザイン
    • やっとこさUIのグラフィックに着手します

オブジェクト指向とは(おわりに)

オブジェクト指向UIは、単にナビゲーションのラベルを「名詞」にしたり、操作順序を「対象選択 → アクション選択」にするといった表現上のスタイルのことではなく、ユーザーの前に対象の理念をストレートに表象するということです。ユーザーに手順を指示するのではなく、目当てそのものを差し出す態度なのです。

とあるように、決まりきった手順で操作するのではなくユーザーが自由にUIを触れる感覚を持たせるようにする。

良かった点

  • 図やイラストが分かりやすい
  • 基本的な思想や設計方法の説明〜ワークアウトまで網羅している
  • 章構成もよい感じ。6章のフィロソフィーがはじめの方に来てたら心折れそうな気がするので
  • 補足も適切

中身の話でないですが、レイアウトはきれいだったのですが文字が小さいところが残念ポイントでした。

まとめ・感想

なかなか会社のプロジェクトでこのレベルの設計面から携わる(口が出せる)機会はないのですが、設計する人 / デザイナー / エンジニアみんながこの思想や設計方法を理解していると、かなりスムーズに機能を絞れたり開発が進むような気がします。
読む前は正直ちょっと胡散臭い感じがしていましたが、ふだん触っているアプリ(SpotifyUber Eats)もオブジェクト指向UIですし、その仕組みや設計の方法を学べたのでとてもよい機会になりました。

本で出される例に関して、例えばメールアプリ、メモ帳アプリ、アドレス管理アプリなどがありますが、どれも Apple の純正アプリと画面構成が同じでオブジェクト指向UIになっています。
HIGなどにも書かれているとは思いますが、Appleも社内で設計する際に同じような手法なのかなと感じました。

これから使うアプリやサービスを見るときもこの本で学んだ視点で見ることができるかなと思います。

ほか参考

Yarn のインストール(MacOS Catalina)

MacOS Catalina でやります。

$ brew install yarn

homebrewでインストールしてみると

The following directories are not writable by your user:
/usr/local/share/man/man3
/usr/local/share/man/man5
/usr/local/share/man/man7

You should change the ownership of these directories to your user.
  sudo chown -R $(whoami) /usr/local/share/man/man3 /usr/local/share/man/man5 /usr/local/share/man/man7

And make sure that your user has write permission.
  chmod u+w /usr/local/share/man/man3 /usr/local/share/man/man5 /usr/local/share/man/man7

と権限エラーがでるのでパーミッション変更してあげる

$ sudo chown -R $(whoami) /usr/local/share/man/man3 /usr/local/share/man/man5 /usr/local/share/man/man7
$ chmod u+w /usr/local/share/man/man3 /usr/local/share/man/man5 /usr/local/share/man/man7

もう一度

$ brew install yarn

とするとインストールは済むがエラーが出る

Error: An exception occurred within a child process:
  CompilerSelectionError: yarn cannot be built with any available compilers.
Install GNU's GCC:
  brew install gcc

gcc というのをインストールしてねと出るので

brew install gcc

をすると

$ yarn -v
1.22.5

と出るのでインストール完了

e-Stat API

f:id:jotaki:20200906153656j:plain

調べごとのメモです。

e-Stat とは?

政府統計の総合窓口
e-Stat APIでは統計データを機械判読可能な形式で取得できるAPI機能を提供している。

e-Stat のユーザー登録

e-Stat APIのサイトにアクセス
https://www.e-stat.go.jp/api/
f:id:jotaki:20200906154124p:plain

「ユーザ登録」でメールアドレスを仮登録
https://www.e-stat.go.jp/mypage/user/preregister
f:id:jotaki:20200906153610p:plain

メールに送られる本登録ページで「利用する機能」は全部にチェックを付けてパスワード設定し本登録
f:id:jotaki:20200906153618p:plain

ログインして登録作業完了
f:id:jotaki:20200906154154p:plain

アプリケーションIDの発行

API呼び出しに必要なアプリケーションIDを発行する
トップ > マイページ表示 > API機能(アプリケーションID発行) から発行
f:id:jotaki:20200906153636p:plain

実際のデータはどんなものか

一覧から調べてみる
https://www.e-stat.go.jp/stat-search/database?page=1
f:id:jotaki:20200906154211p:plain

例えば「企業のワーク・ライフ・バランスに関する調査」を選択すると、そのテーマで177件の切り口(API)がある
f:id:jotaki:20200906153656p:plain

その中から「正社員の残業時間」を選択してみると、統計を行った時期や担当、回答企業数などが出てくる
f:id:jotaki:20200906153705p:plain

API」をクリックするとAPI URLが表示される
f:id:jotaki:20200906153720p:plain

「DB」をクリックすると表組みやグラフでデータが表示される
f:id:jotaki:20200906153728p:plain

参考記事
政府統計の総合窓口(e-Stat)のAPIを使ってみよう

のぞき見企画!mofmof×Goodpatch Anywhere合同勉強会

先日、のぞき見企画!mofmof×Goodpatch Anywhere合同勉強会 を視聴して特に気になったところをメモに残しておきます。

タイムテーブル

timed session
19:00 イベント開始
19:05 株式会社mofmof発表
19:35 Goodpatch Anywhere発表
20:05 質疑応答・ディスカッション
20:30 終了

発表内容

質疑応答・ディスカッションの内容も含めたものになります。

株式会社mofmof発表

岩井 寿樹さん(株式会社mofmof テックリード
月額制受託開発の mofmof でテックリードの役職に就いている方。
ご本人は技術力ごりごりに出してリードするほうではないと仰っていた。

仮説検証は事前にクライアント側で済ませている場合が多く、その後に実際にサービスを開発・グロースさせる段階でのお手伝いが多い。
そのなかでいかに方向性を絞って主に開発面でどういう視点で案件を進めているか、という話が中心。

基本的にはアジャイルスクラム

カイゼン・ジャーニー正しいものを正しくつくるの話に近かったと思います。

プロジェクト管理は Pivotal Tracker、簡単にバックエンドのプロトタイプ作るなら Hasura がよい。

Goodpatch Anywhere発表

大堀 祐一さん(Goodpatch Anywhere サービスデザイナー) と質疑応答はGoodpatch Anywhereの皆さん

mofmofさんに比べて、クライアントの事前の検証などがない状態からすすめることが多い。

戦略 → 要件 → 構造 → 骨格 → 表層
UX 虎の巻 を読んだときに調べたギャレット氏の5階層モデルに近い話。
Goodpatchさんの解釈は UXの5段階モデルにおける各段階での具体的なデザイン手法とは? に書かれており、この中で「戦略」と「要件」がクライアントからの要求になる。
「戦略」と「要件」はふつう「ビジネス要求」と「技術的制約」の重ねた部分を考えるが、それに加えて「ユーザー視点」の切り口を加えるのを大事にしている。

MVPを作る段階で何をするのが正しいか?

  • インタビュー
  • SNSで情報発信
  • noteで情報発信
  • ワイヤー作成
  • プロトタイプ作成
  • WordPressでさくっとつくる

のうち、すぐできることはやるスタンスで「WordPressでさくっとつくる」以外を行うのが正解ではないか。

ユーザーテストはどこから始めたらよいか?
同じ会社でもプロジェクト知らない人とか気軽に聞いてみる

Webサイトのノーコードサービスは WebflowStrikingly を使ったが STUDIO が一番細かいところも手が届くし使いやすい。

まとめ

聞きながらにメモしたものなのでところどころ正確ではないかもしれません。
自分の所属する会社でもUXに力を入れていこうとしていますが、取っ掛かりをどっから作っていいのか試行錯誤しているので、実際に行われている話を聞けてよかったです。
本でしか読んだことのない話を実際に聞けてさらに興味を持つことができたかと感じます。
時間の制約もあるので難しかったと思いますが、実際の案件の話しも聞きたいなと思いました。

2020年8月 振り返り

結果

ブログ

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

読書

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

反省点など

SAPに受からなかったのが痛かったです。

来月に向けて

久しぶりにNuxtでアプリ1つ作る予定です。

YouTube APIで複数動画

ちょこっとやったやつのメモ

HTML

<button class="js-player-start" data-movie="0">再生</button>
<button class="js-player-stop" data-movie="0">停止</button>
<div id="player_0"></div>

<button class="js-player-start" data-movie="1">再生</button>
<button class="js-player-stop" data-movie="1">停止</button>
<div id="player_1"></div>

JavaScriptjQuery

var tag = document.createElement('script')
tag.src = "//www.youtube.com/iframe_api"
var firstScriptTag = document.getElementsByTagName('script')[0]
firstScriptTag.parentNode.insertBefore(tag, firstScriptTag)

// make player array
var players = new Array()

function onYouTubeIframeAPIReady() {
  players[0] = new YT.Player('player_0', {
    height: '100%',
    width: '100%',
    videoId: 'IqKz0SfHaqI'
  })
  players[1] = new YT.Player('player_1', {
    height: '100%',
    width: '100%',
    videoId: '-bNMq1Nxn5o'
  })
}

$(function () {
  // 再生
  $('.js-player-start').on('click', function(){
    const target = $(this).attr('data-movie')
    players[target].playVideo()
  })
  // 停止
  $('.js-player-stop').on('click', function(){
    const target = $(this).attr('data-movie')
    players[target].stopVideo()
  })
})

横幅をレスポンシブにするには、

  ...
    height: '100%',
    width: '100%',
  ...

とすればよい

YouTube Data API の概要
https://developers.google.com/youtube/v3/getting-started?hl=ja

AWS ソリューションアーキテクト プロフェッショナル 受験記(再・再々)

不合格の記録なのでほぼ参考になりません。ごめんなさい。

f:id:jotaki:20200105065609p:plain

これまで・今回の結果

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

7月に受けて730点(合格スコア750点)だったので、これはいまのうちにやっておかないと一生できなそうと焦りを感じたため。

結果

結果から言うと、2週間ごとに2回受けましたがダメでした (´・ω・`)
723点・730点ということで、もうひと押しが足りないようです。

今回分の勉強計画

1回目の試験で基礎的なことや使う教材の選定はそんなに間違ってなかったかなという感じがしたので、問題集を解くのは同じでしっかり解説や出てくる用語を漏れなく理解しようと心がけました。

やったこと

koiwaclub の SAP問題集

前から気になっていながら使ったことなかったkoiwaclubに手を出してしまいました。
https://aws.koiwaclub.com/exam/sap/
SAPはサンプル問題が7問ありますが、それ以外は有料会員登録が必要なので少し悩みましたが、合格体験記見ても評判良さそうですしここでケチってまた落ちるのも嫌なのでお金で解決しようとしました。

ボリュームは7問x50セットなので計350問。3回目の試験までに2周。
問題の難易度も本番に近く、解説もUdemyのよりきちんとしていると思います。

ただ結構クセのある設問や回答が多く試験前に以前よりも分からないこと多くなっちゃったなという感覚になってしまいました。
基礎力ないのが原因と思いますが、これで勉強完了せずに最後に公式の模試やサンプル問題やっておくのがいいかなと思います。

その他

その他は1回目のときと同じもの。
全部2回は通しでやっているので3・4回目ということになりますが、いろんな教材で問題やっているのと設問も長いので答えを覚えるぐらいの記憶はついていないのでそれはそれでよかったと思います。

  • 【読書】AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説
  • 【公式】Exam Readiness: AWS Certified Solutions Architect – Professional
  • 【公式】サンプル問題の復習
  • 【公式】模擬試験の復習

足りなかったこと

信じられないような本当の話ですが、3回ともスコアが同じくらいで、スコアレポートに出るセクションごとの評価も同じでした。

再学習の必要あり

  • 分野 1.組織の複雑さに対応する設計
  • 分野 4.コスト管理

ともに全体に占める割合が低いセクションですが、ここのあと20点(2問程度?)落としてるのが合否を分けてるのかなと分析しています。

ただ複合的にサービス組み合わせるので、なかなか勉強しづらいのですよね・・・
SAP本やExam Readinessでもこの2分野は繰り返しやりましたが、これがコスト分野なのか?っていうものもあり、なかなか特定サービスの理解だけでは難しいところがありました。

ただ今でもぼんやりしか分かってないことはありまして、

  • ネットワークやオンプレ系の知識全般(BGP、パブリック/プライベートVIF、静的/動的ルート、IPv6
  • 複数リージョン or AZでのVPCや +オンプレ環境での通信制御系(DX、DXGW、VPNVPCピアリング、TransitVPC、TransitGW、VPCエンドポイント...)
  • Organization でのアカウント/権限/コスト管理(SCP・一括請求)
  • Organization と Cfn を組み合わせたアカウント管理
  • 権限の委任手順(クロスアカウントアクセス、Saasサービスなどほかアカウントに対して)
  • Cfn のマルチアカウントでのスタック運用(クロススタック参照、ServiceCatalogとの組み合わせ)
  • EC2のインスタンスタイプ

あたりでしょうか。
アカウント管理は「◯◯◯アカウント」が設問に何個も出てきて訳分かんない・・・みたいになっちゃうときがあります。
EC2のインスタンスタイプについては、それぞれの特性は分かっているものの、実際にユースケースでどれを選ぶと聞かれてかなり悩むので理解度が足りてないのかなと思っています。

新しめのサービスも覚えた

不合格な自分が言うのもなんですが、よく合格記で◯◯◯は出題されなかったみたいなことが書かれていますが、あまり真に受けずに新しめのサービス含めて覚えれるのは覚えたほうがいいんじゃないかと思います。
そういう意味ではUdemyやkoiwaclubで出てくるサービスはいい感じで網羅できている気がします。

自分が試験対策のなかで概要程度は身につけたもの

オンライン試験

最後の1回はオンラインで受験しました。(ピアソンVue)

自分の場合システムテストはうまくいったのですが、試験が開始されたときの画面切り替え直後(規約などが表示される画面)でチャットの文字を打つたびにローディングが走り次の画面へ遷移できない問題が起こってしまいました。
1度リスタートしますねと試験管にメッセージをもらい画面を閉じられましたが、その後しらばく待ってましたがちょっと待ってね画面で進行せず・・・
一度画面を閉じて何度かonVueアプリを立ち上げてやっと試験が始められました。
※ちなみにチャット機能と自分のPCが合わないみたいでインプット挙動するたびに重くなる現象は解決させてなかったっぽくできるだけチャットせずに過ごしました。

試験終わってから気づきましたが、1時間半くらいこれで遅れてしまってました。
まあこういうものと割り切って試験はやって、1通りを40分残しでフラグの問題見直しできたので、なかなか集中はできた気がします。
あまり推奨はされないと思うのですが、自宅だと問題文や回答を小声でも読むことができるので自分の場合は頭に入りやすい気がしてよかったです。

8/27追記
上記の不具合?の件で、試行錯誤していた1時間30分の間にサポートに連絡していたのですが、本日連絡が来て8/23の試験スコアは無効になりました。
それと同時に試験のバウチャーを配布いただきました。

明確な理由は書いていなかったのでおそらくなのですが、システムチェックはOKになるなど受験者側での瑕疵ではないのと、その後に受けた試験結果が不合格だからかなと思っています。

まとめ

というわけで点数的にはもうちょっととはいえ3回目の今回でわりと心が折れました。。。(毎回折れてはいます)
今のやり方だとあと10回続けて受ければどこかで受かるような気もしますが、それなりに毎回試験対策はしているのでそこまでのエネルギーは湧かず
アソシエイトレベルに比べてもより色々なサービスや考え方も知れたので、その点は後悔ありませんがやっぱり結果が付いてこないと達成感がないので残念です。

というわけで不合格のままですがSAPは放置しようかと思っています。
AWSだけに専念できる年末年始など長期休暇があればまたやってみるかもしれません。

4月くらいからAWSの勉強しかやってなかったので、9月からフロントエンドまわり頑張りたいと思います。