22時に寝ようと思って2時に寝る。

備忘録や日記を書いてます。きょうは早く寝よう。

デザイン組織のつくりかたを読んだ

きょうは デザイン組織のつくりかた という本を読みました。

デザイン組織のつくりかた デザイン思考を駆動させるインハウスチームの構築&運用ガイド

デザイン組織のつくりかた デザイン思考を駆動させるインハウスチームの構築&運用ガイド

  • 作者: ピーター・メルホルツ,クリスティン・スキナー,長谷川敦士,安藤貴子
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2017/12/22
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (2件) を見る

この本を読むきっかけは、とある記事の一文でした。

どうしてデザインが大切なのか、ここ最近デザインが盛り上がっている歴史的背景を一通り話して、「あーやっぱりデザインって大事だね!」って思ってもらうまでにまずひと苦労。 (中略)だんだんめんどくさくなってきたんですよね… もうめんどくさいから、そういう説明するのはやめることにしました。この本に委ねます。

「デザイン組織のつくりかた」がめっちゃ良かったので、100冊ぐらい配ってみようかと思う | TECHNICAL CREATOR

昨今の「デザイン大事だよね」という流れの歴史的経緯を学んでいきたいというモチベーションで購入し、しばらく積読となっていました。

一通り読んでみて、いくつか学びになったところを備忘録として残しておきたいと思います。デザイン組織の構築の部分より前の、デザイン組織が必要になってきた経緯が中心です。自分なりの言い回しでメモしているため、原著との解釈が異なる部分があります。

コンシューマライゼーションの波

何十年ものあいだソフトウェアは MicrosoftOracleAdobe といった会社が作る製品だったのが、インターネットの急速な普及によって、大きく変化してきた。業種に関わらず、業務の中心にソフトウェアが存在し、インフラとなり、程度の差はあってもすべての会社はソフトウェア会社になりつつある。

ソフトウェアは性質上抽象的なものであり、ほとんどの人にとってその抽象性を理解することは容易くない。そのため、ソフトウェアの分野では「ヒューマン・コンピュータ・インタラクション」「インタラクションデザイン」「インターフェースデザイン」「ユーザビリティ」といったデザインに対して、相対的に多くの投資が行われている。

単純に作られているソフトウェアの数が増えているだけでなく、高いレベルの性能を要求される。「高いレベル」という曖昧な表現だが、ただ要求にこたえられる「すべての機能の全部盛り」ではもはや不十分である。ソフトウェアの分野はそれくらいに成熟したフェーズにあり、他社と横並びに機能するサービスを提供すれば戦略的にまずまずだった時代は終わり、体験価値の点でも競争していく段階に来た。業務や作業に使うソフトウェアの数が増えていくにつれ、ユーザーの知識も高度化し、効率的に機能するソフトウェアは評価されても、そうでないものはそもそも見向きもされなった。

そういう傾向は長い間、消費者向け(toC)の製品に限られたものだった。というのは、何を買う・使うかは個人がそれぞれに選ぶ立場にあったからだ。一方でエンタープライズ系のソフトウェアはデザインがずっとひどいものだった。というのにもいくつか理由がある。

  • 購入者が必ずしもユーザーではなかった
  • ユーザーに選択肢がなかった
  • デザインのひどさはトレーニングによって克服できると信じられていた
  • 仕事は面白くて楽しいものであってはならないからソフトウェアにもその堅苦しさを反映すべきという空気

しかし、今のエンタプライズ系ソフトウェア市場は進化しており、企業は”ひどいデザイン”のソフトウェアを使うことで生産性の足を引っ張ると悟った。エンタープライズ系ソフトウェア会社は、デザインがお粗末だと顧客を失いかねないことに気づいた。高度な知識を持つようになったユーザーは”ひどいデザイン”を我慢することを嫌うようになった。

そして、子供の頃からデジタルテクノロジーに浸かってきたミレニアル世代が社会人になってきてから、ITのコンシューマライゼーションが加速している。

Everything-as-a-Service

これまでソフトウェアは、プロダクト、つまり製品だと考えられてきた。完成すると、箱に入れてパッケージ化され販売されるか機械に直接インストールされる。しかし、常時ネットワークに接続されるようになってからの世界では、ソフトウェアが完成することはなく、より最適化され、より強化され、デプロイされ続ける

そうした変化から、今では顧客がソフトウェアそのものを手に入れることはなくなり、そのライセンスへのアクセス権を購入するサブスクリプションモデルによって収益を生み出すのが当たり前になってきた。修正され続けるソフトウェアの性質が、売り手と買い手の関係性を変えた。両者の関係が継続的なものになってから、すべての会社はソフトウェア会社であるのと同時にサービス会社になりつつある。

まだ、サービス会社になることができていないソフトウェア会社は、顧客をどう捉えて、どうやり取りするかを根本的に再考する必要さえある。今は、製品を使うために顧客はアカウントを発行し、その行動は細かく追跡されている。企業には、顧客のことをよく知り、ソフトウェアを修正し、サービスを提供し続ける責任がある。

ユーザーエンパワーメントという諸刃の剣

ただ「サービスを提供する」会社を目指せばいいわけでもない。これまでになく現状は複雑化している。1990年代半ばまでは、企業に連絡するツールは電話や FAX、または郵送を使って直接働きかけた。その後、Web や E-mail が登場し、やがてオンラインチャットやソーシャルメディア、モバイルアプリが加わり、デジタル上での顧客とのタッチポイントが爆発的に増えた。

インターネットにつながったソフトウェアはコミュニケーションだけにとどまらない。インターネットが普及する以前は、銀行であれば、ソフトウェアは主に訓練された専門の銀行員によって使用される社内ツールだった。顧客が直接アクセスできるのは ATM やテレフォンバンキングくらいで、それらでできることは基本的なものに限られていた。デスクトップから Web へのアクセスが可能になると、銀行はかつて社内システムとして公開していた機能を顧客に提供するようになった。

こうした複雑なシステムを顧客は喜んで利用した。自分で直接管理できることを高く評価した。一方の銀行も人件費の削減に役立つため、それを促進した。

だが、社内の訓練された専門の銀行員(ユーザー)は一日に何時間もそうしたツールを利用するのに対して、一般のユーザーの場合は一週間、あるいは数ヶ月の数分のために利用する可能性が高い。専門家以外の比較的使用頻度の低いユーザーに分かりやすいものを作るには、根本からじっくりと考え直す必要が出てくる。

そして、競合するソフトウェアと機能が横並びである以上、ユーザーエクスペリエンス(UX)も顧客がサービスを選ぶ際の理由になる

複雑さと単純さという正反対の性質を抱えないといけない矛盾は、携帯電話の登場でますます深刻化した。アクセスポイントを一つ増やすと、その分だけ複雑さは増す。だが、モバイルデバイスには画面の小ささや処理能力の低さなどの制約がある。その範囲内でデザインするにはさらなる合理化と単純化が必要になる

デザインのポテンシャル

ソフトウェアによってビジネスはより一層複雑さを増した。それに対処するために、企業はデザインに投資する。一方で、デザインを企業に導入する責任を負うほとんどの人はデザインが持つ力について初歩的な理解しかない。デザインを主に美的価値を高め、スタイルや外見をよくするものだと認識している。

ジョブズの有名な言葉に以下のものがある。

ほとんどの人はデザインを見た目のことだと思っているが、それは間違いだ。デザインをうわべだけのことだと勘違いしている。デザイナーには箱を渡して、「見た目をよくしてくれ!」と言えばいいのだと。私たちは、デザインとはそういうものではないと考える。どのように見えるか、どのように感じるかではない。デザインはどのように機能するかなのだ。

プロダクトデザインのコンサル会社 Ammunition の設立者のロバート氏は、「デザインはプロセスだ。イベントではない。」と語り、最近までデザインは一つの流れの中での一つのステップだとみなされてきたという。

f:id:azuuun:20181008203733p:plain

彼は、図.1 のようにデザインは単独で存在しうるものではなく、図.2 のように製品開発のライフサイクル全体に取り入れてこそ、最大の効果が発揮されるプロセスであると主張している。

f:id:azuuun:20181008203942p:plain

すべてのデザインはサービスデザイン

「サービスデザイン」という新しい領域は、企業によるデザインの活用方法をリフレーミングする。これまでのデザインは作ることに焦点を当てるよう求められてきた。サービスデザインも本質は変わらないものの、視点はもっと高く、広いものであり、作られた成果物自体を重視するより、ステークホルダーとそれらと関わるすべての活動の関係性を理解しようとする

作られた成果物は独立した存在ではなく、より大きなサービス・エコシステムのなかの一つのツールに過ぎないと考える。

さいごに

この記事は、本書籍の導入部のみの備忘録です。この後、書籍では「組織に広く貢献するデザインの力」へと解説が続きます。私が所属する会社もエンタープライズ系のソフトウェア会社の一つで、実際にデザイングループが存在し、日々製品/サービスの顧客体験を考え、提供し続けています。そういった背景があり、本書を読むことで組織の中でのデザイングループの位置付けや重要性を改めて学ぶことができたように思いますし、ITエンジニアの立場からも積極的にデザインに関わっていきたいと感じています。

以上です。

fish - Macのシェル環境を新しくした

f:id:azuuun:20180919233241p:plain

これまでシェルにそこまでこだわりがなかったのですが、身の回りの方々を見ていると、かっこいい・便利な感じにカスタマイズしている人が多く、「おっ、良さそうだな」と思ったので シェル環境を一新しました。

どのシェルを選ぶか

fish にします。

導入手順

Homebrew を使って導入します。

$ brew install fish
$ fish -v
fish, version 2.7.1

ログインシェル(デフォルトで立ち上がるシェル)を bash から fish に変更します。

$ sudo vi /etc/shells
# 末尾に以下を追加
/usr/local/bin/fish

保存した後、以下を実行します。

# ログインシェルを fish に変更
$ fish
> chsh -s /usr/local/bin/fish

これで、次シェルを立ち上げたときも fish になります

パッケージマネージャー fisher を導入する

github.com

> curl -Lo ~/.config/fish/functions/fisher.fish --create-dirs https://git.io/fisher
> fisher -v
fisherman version 2.13.3 ~/.config/fish/functions/fisher.fish

個人的にとりあえず以下の2つを入れてみて便利でした

環境変数とPATHの設定

fish の環境変数の設定ではexport AWS_ACCESS_KEY_ID=HOGE1234 というような見慣れた記法が使えません。

ターミナルに直接以下のようにsetを叩くか、~/.config/fish/config.fishに以下を追記します。-x環境変数としてsetするオプションで、これがないとシェル変数として定義されます。

> set -gx AWS_ACCESS_KEY_ID HOGE1234

PATH は以下のように設定します。コロンで区切るのではなく、配列で管理されています。

> set -gx PATH $HOME/.rbenv/bin /usr/local/var/pyenv $PATH

テーマを変更する

github.com

結構、いろいろあります。今回は、oceanを入れてみます。 fisher omf/theme-{color-theme-name}で導入できます。

> fisher omf/theme-ocean
Installing 1 plugin/s
OK Fetch ocean github.com/oh-my-fish/theme-ocean
Done in 1s 558ms

フォントによっては、アイコンが Apple Emoji になったりしますが、以下のような powerline 対応のフォントを導入すると良さそうです。

fonts/Meslo LG L Regular for Powerline.ttf at master · powerline/fonts · GitHub

さいごに

乗り換えてみて、とても便利ですし、いい意味で”驚きが少ない”(予想に反する挙動がない)です。また何かカスタマイズしたときに、追記したいと思います。

以上です。

参考

UIが消えて何もしなくてよくなっていく

最近読んだ2つの記事がつながって、「なるほど」と腑に落ちた。

サービス開発において「ユーザーがしたいことをできるようにさせてあげる」という議論は活発だが、いっぽうで「しなくていいことをしないようにさせてあげる」分野はまだまだ発展途上だと思う。 (中略) システムで吸収してあげれば、人間がしなくていいことはまだまだある。

しなくていいUX|小山田翔子 / GMOペパボ|note

つまり・・・

UIとかUXとか、サイコーな状態になると、使ってる側はまったくその存在を気にしなくなるのだ。

UIがサイコーになるとUIは消える|米光一成|note

サイコーな状態のUXは、「しなくていいことをしないようにさせてあげる」分野が発展していくと、徐々に増えていく。ユーザーが「しないようにさせてあげられる」システムを作れるようになりたい。

引用した記事

note.mu

note.mu

デザイン - 信頼感を持たせる色・透明感のあるデザイン

今回は、「信頼感を持たせる配色」「透明感がある配色」に着目して、カラーコードと色見本を見ていきます。

信頼感が生まれる配色

f:id:azuuun:20180917222830p:plain

一般的に、信頼・冷静といった印象を与える色は青系、安心感を与えるのは緑系の色だと言われています。

色の数を少なくナチュラルな印象

f:id:azuuun:20180917222954p:plain

冷静な印象を与える

f:id:azuuun:20180917223032p:plain

意欲的な赤色を添える

f:id:azuuun:20180917223058p:plain

緑をメインに安定感を与える

f:id:azuuun:20180917223124p:plain

参考

デザイン - 色の持つイメージ

色について

色というのは、人によって違ったイメージを持つもので、その人の経験や住んでいる国、その土地にある文化によって変化する。色によるイメージをポジティブ・ネガティブの2つの視点からまとめ、それに適した領域を以下に示す。

f:id:azuuun:20180917190404p:plain

ポジティブイメージ
  • 情熱
  • 愛情
  • 勝利
  • 積極的
  • 衝動
ネガティブイメージ
  • 危険
  • 怒り
  • 争い
適したサイト
  • 飲食
  • キャンペーン

f:id:azuuun:20180917190917p:plain

ポジティブイメージ
  • 明るい
  • 活発
  • 幸運
  • 躍動
  • 希望
ネガティブイメージ
  • 臆病
  • 裏切り
  • 警告
適したサイト
  • 食品
  • スポーツ

f:id:azuuun:20180917190925p:plain

ポジティブイメージ
  • かわいい
  • ロマンス
  • 若い
ネガティブイメージ
  • 幼稚
  • 繊細
  • 弱い
適したサイト
  • ブライダル
  • 女性向けのサイト

f:id:azuuun:20180917190937p:plain

ポジティブイメージ
  • 親しみ
  • 陽気
  • 家庭
  • 自由
ネガティブイメージ
  • わがまま
  • 騒々しい
  • 軽薄
適したサイト
  • コミュニティー
  • 飲食
  • キッズ

f:id:azuuun:20180917190946p:plain

ポジティブイメージ
  • 高級
  • 神秘
  • 上品
  • 優雅
  • 伝統
ネガティブイメージ
  • 不安
  • 嫉妬
  • 孤独
適したサイト
  • ファッション
  • ジュエリー
  • 占い

f:id:azuuun:20180917190952p:plain

ポジティブイメージ
  • ぬくもり
  • 自然
  • 安心
  • 堅実
  • 伝統
ネガティブイメージ
  • 地味
  • 頑固
  • 汚い
適したサイト
  • ホテル
  • 旅館
  • インテリア
  • クラシック
  • レトロなサイト

f:id:azuuun:20180917191001p:plain

ポジティブイメージ
  • 知性
  • 冷静
  • 誠実
  • 清潔
ネガティブイメージ
  • さみしさ
  • 冷たい
  • 悲しさ
  • 臆病
適したサイト
  • コーポレート
  • 医療
  • 化学

f:id:azuuun:20180917191012p:plain

ポジティブイメージ
  • 祝福
  • 純粋
  • 清潔
  • 無垢
ネガティブイメージ
  • 空虚
  • 殺風景な
  • 冷たい
適したサイト
  • 医療
  • ニュース
  • EC
  • 美容
  • コーポレート

f:id:azuuun:20180917191024p:plain

ポジティブイメージ
  • 自然
  • 平和
  • リラックス
  • 若さ
  • エコ
ネガティブイメージ
  • 保守的
  • 未熟
適したサイト
  • アウトドア
  • 食品

f:id:azuuun:20180917191047p:plain

ポジティブイメージ
  • 実用的
  • 穏やか
  • 控えめ
ネガティブイメージ
  • あいまい
  • 疑惑
  • 不正
  • 無気力
適したサイト
  • 工業
  • 家電
  • ファッション

黄緑

f:id:azuuun:20180917191108p:plain

ポジティブイメージ
ネガティブイメージ
  • 未熟
  • 子供っぽい
適したサイト
  • 新生活
  • 新年度
  • 先進的なサイト

f:id:azuuun:20180917191057p:plain

ポジティブイメージ
  • 高級
  • エレガント
  • 洗練
  • 一流
  • 威厳
ネガティブイメージ
  • 恐怖
  • 不安
  • 絶望
適したサイト
  • ジュエリー
  • ファッション

参考

iOS - AppExtensions Today の概要

前提としてToday ウィジェットは以下のように動作することを期待しています。

  • 常に最新の情報が表示される
  • ユーザーの操作に的確に応答する
  • 効率よく動作する(特に iOS 向けウィジェットはメモリを浪費すると強制終了させられる)

簡潔に、きびきびと動作することを期待される上、成約も多いので合理的なUI設計が求められますし、対話的に操作する要素は最小限に留める必要があります。特に iOS の場合は、キーボード入力はできないという特徴があります。

また、Today のウィジェット内でスクロール要素をもたせるのは困難です。なぜなら Today ウィジェット自体がスクロールする仕様のため、個別のウィジェット内でスクロールするのはユーザーフレンドリーではないためです。

UI を設計する

ビューのレイアウトには AutoLayout を使用しましょう。Today ビューが占める面積は限られており、着目する情報を迅速に表示する必要があるので、必要以上に大きなウィジェットは避けましょう。 ビューの幅に合わせる必要がありますが、高さは表示内容に応じて調整できます。

内容を更新する

Today の拡張ポイントには、ウィジェットの状態を管理して、内容を更新するためのAPIが用意されています。

ウィジェットが常に最新の状態であることが期待されているので、システムは随時、ビューのスナップショットを取得しようとします。ウィジェットが一旦消えて、再び可視化状態になると、直近のスナップショットを一旦表示した上で、最新のビューに置き換わるように動作します。

スナップショットの取得前にウィジェットの内容を確認するにはNCWidgetProvidingプロトコルに従い、処理します。ウィジェットwidgetPerformUpdateWithComletionHandler:が呼び出されたら、ビューを最新の内容に更新して、完了ハンドラを呼び出すことで、状態を管理します。

完了ハンドラ、次のいずれかの定数を渡します。

  • NCUpdateResultNewData: 内容が入れ替わったのでビューの再描画の必要がある
  • NCUpdateResultNoData: 内容が同じなので更新は不要
  • NCUpdateResultFailed: 更新処理中にエラーが起きた

参考

developer.apple.com

RxJava - BackpressureStrategy の種類

今回は Backpressure の挙動を指定するための列挙型、BackpressureStrategy について見ていきます

BackpressureStrategy とは

Flowable は場合によって生成スピードが Subscribe の処理速度以上に速い場合があります。そういった場合は、データは通知されるのを待つことになります。その待つデータに関する挙動を指定するのが BackpressureStrategy です。

BackpressureStrategy の種類一覧

概要
BUFFER 消費者に通知されるまで、すべてのデータがバッファされる
DROP 消費者にデータが通知できるようになるまでに生成されたデータを破棄する
LATEST 生成された最新のデータ(1件)のみをバッファし、生成される度に最新のデータで上書きする
ERROR 通知待ちとなっているバッファデータが最大バッファサイズを超えた場合に MissingBackpressureException が発生し、エラー通知する
NONE 処理は行わず、onBackpressureBuffer(int capacity) または 他のパラメータ化された onBackpressureXXX メソッドを使用する場合に使用可能

参考

RxJavaリアクティブプログラミング (CodeZine BOOKS)

RxJavaリアクティブプログラミング (CodeZine BOOKS)