astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

UIを選ぶとき考慮すべき4つのこと

f:id:astamuse:20200826100717j:plain こんにちは。デザイン部でフロントエンドエンジニアをしているkitoです。
今回は、アプリを作成する際、最適なUIを選定する4つの指針について書きたいと思います。

UIは、人間の心理や認知に深く関わり、アプリへの信頼性を左右する重大な要素ですが、我々がアプリを作成するとき、ほとんどの場合直感的にUIを選択しています。経験豊富なUIデザイナーなら、その直感は間違っていないことが多いでしょう。

ただ、そうはいってもUIはUIデザイナーだけで決定できるわけではないので、直感を言語化して共有することがプロジェクトを前進させる力になります。本文は、学術的な内容ではなく、数多くのUIを実装してきた「現場」からのひとつの私見として書きたいと思います。

UIって?

UIがユーザーインターフェイスの略であることは言うまでもないですが、そもそもUIがアプリで果たしている役割とは何でしょうか。

よくあるUIであるモーダルを例にして考えてみましょう。モーダル型のUIは、ユーザーがボタンをクリックすることで小さなウインドウが展開されて新しい情報が出現します。当たり前のことを言うようですが、UIには、このように隠されていた情報を出現させる役割があります。   

では、なぜ予め情報を隠すのでしょうか。
それは、あらゆる情報が整理されず一挙にユーザーに提供されれば、ユーザーの認知的負荷が上昇しアプリに対する信頼性を低下させるからです。アプリの信頼性が下がれば、自ずと利用率は下がるでしょうしコンバージョンも低下していくでしょう。 見方を変えるなら、UIを作成する作業は情報を整理して隠す作業であると言えます。

1.情報の量と質

UIを決定する主な要因は、情報の量と質です。

ツイッターなどで採用されているタイムライン型のUIを思い浮かべてください。
あのような情報が流れるタイプのUIが採用されているのは、ユーザーが接する情報が膨大でかつ個々の情報を見逃したとしてもクリティカルではないからです。

ツールチップは、少ない情報を付加する際に有効でしょうし、バリデーションのアラートは、情報としては少量ですが、質としては確実に視認させなければなりません。
ただし、情報の質と量が変わらなかったとしても、ユーザー環境の変化で、UIの流行り廃りはあります。

例えば、スマートフォンが普及したことで、Webサイトは縦型になり、スクロールさせるUIやトグル型のUIでコンテンツを折りたたむことが増えました。また、iPhoneでflashが動かないので、その代わりとして、パララックス型やカルーセル型のUIが流行しました。

2.優先度

情報の質のなかでも、その情報がどれぐらい優先度の高い情報であるのかもUIを決定する上で無視できません。優先度によって、情報を表示する場所やタイミングが決まってくるからです。
優先度の高い情報は、アクセス時に画面を専有させたUIで表示させたり、headerの直下など視認性の高い場所に表示します。

情報の優先度は、ビジネスサイドの判断が不可欠なことが多く、UIデザイナーやフロントエンドエンジニアだけで決められるわけではありません。 もっとも、問題になるのはビジネスサイドも情報の優先度を知っているとは限らない点です。

行政のサイトなどでよくある、注意喚起のメッセージが画面のほとんどを専有して、眉をひそめるようなファーストビューになっているサイトを見たことがあるかもしれませんが、これは情報の優先度の決定がうまく機能していないからです。注意喚起やalertメッセージを羅列しても、ユーザーの認知負荷が高まり離脱してしまえば、注意喚起は注意喚起として機能しません。

いらぬ詮索かもしれませんが、行政のサイトを運営している公務員の言い分を忖度するなら、彼らとしては、ある市民にとっては重要な情報であるけれどある市民にとっては重要でないという、多様なユーザーを相手にする行政組織の特殊性や、また公務員の人事評価が減点主義なので、注意喚起のメッセージを表示させないリスクの方が、情報を整理して埋もれてしまうリスクより大きいのかもしれません。
なんにしろ、UIがそれを運営している組織のロジックに影響されるのは、妙なことですがありえることです。

UIの優先度は、ビジネスサイドとのコミュニケーションで解決することが多いですが、解決しない場合は、コストはかかりますがA/Bテストを提案してUIをユーザーに決めてもらうのも一案です。
(なおA/Bテストの限界については、過去私が書いたこのエントリーが参考になるかもしれません)

3.学習済みUI

UIを選定するうえで、そのUIの使い方について想定しているユーザーが学習済みであるかどうかも考慮するポイントです。

ハンバーガーメニューは、一般的な学習済みのユーザーであるなら、メンタルモデルが出来上がっているのでサイトを回遊するためのメニューが隠されていると認知できます。
一方、ITに疎いユーザーにとっては、ハンバーガーメニューは三本線の謎の模様に過ぎず、何ができるのかすぐには把握できないでしょう。だからハンバガーメニューを使うべきではないと言いたいわけではなく、UIの選定に想定ユーザーのリテラシーを考慮すべきだと言いたいのです。
UIデザイナーやフロントエンドエンジニアは、なまじ自分がUIについてよく知っているだけに盲点になりがちです。

ITに疎いユーザーを対象にアプリを作成するなら、ハンバガーメニューを使うとしても下に文字で「メニュー」と情報を付加するような対応が考えられます。
ヤフーのiPhoneアプリでは、様々なユーザーが使うことを想定してか、画面下部のナビゲーションには、アイコンと文字が並べて表示されています。こういったことが参考になるでしょう。

また、優れたUIは新規につくるというより既にあるものなので、デバイスに標準的に備わっているUIかBootstrapのような広く使われているUIライブラリを優先的に使用したほうが、ユーザーの負荷だけではなく実装の負荷も低くなります。

4.考えさせない

ユーザーに考えさせないでという観点も重要です。

単にスムーズに使えて認知的負荷がかからないというだけではなく、人間が意識していない「無意識」にアプローチする手法です。
例えば、アプリの最上部と最下部は、コンテンツの両端にあるので人間の認知として注目しやすい場所です。無意識に目が行きやすい場所なので、コンバージョンポイントやナビゲーションが設置されることが多いはずです。UIの設置場所や目線の導線を適切に設計するなら、ユーザーの意識に顕在化させる前に意図した行動を促せるでしょう。

また、UIに没入させることを少し考えてみても良いかもしれません。ボタンをクリックしてスッと画面が切りかわり、それがなんとなく心地よいので気がつくと登録フォームを完了していたということがあります。
正直言って胸を張って言えることではないですが、ユーザーが熟慮の末、慎重にボタンを押さなければならないUIは良いUIではなく、(適切なマーケティングで集めた対象ユーザーを)軽率に登録させるUIの方が良いUIと言えます。

あるいは、バナーデザインでよくある、人間が美男美女を無意識に信頼してしまう傾向を利用し、美男美女の画像を掲載してサイトの信頼性と混同させる手法がありますが、UIデザインにおいてもこの手法が使えるでしょう。
例えば、信頼性の高いデータを心地よいUIで見せることで、サイトへの信頼性と混同させ・・・
人相が悪くなってきた気がするので、今日はこのあたりで終わりたいと思います。

アスタミューゼでは、エンジニア・デザイナー・PM・コンサルタントを募集中です。ご興味のある方は遠慮なく採用サイトからご応募ください。お待ちしています。

全員リモートでの開発ミーティングを振り返ってみる

立秋の候、残暑が続きますが暦の上ではもう秋ですね。 多分に漏れず、我々 ICP 開発チームも3月4月頃から在宅での仕事が行われているので開発での打ち合わせ/スクラムイベントを中心に工夫や変わったことなどを振り返ってみたいと思います。

同じように打ち合わせで工夫されている方、開発チームの様子に興味ある方に軽い気持ちで読んでいただければ幸いです。 (スクラムに関する用語説明などは省略しております、ご了承ください)

スクラムスタートの経緯などは @yukung がこちらの記事にしております。 スクラムに興味がある方はこちらもご参考にしていただければ! http://lab.astamuse.co.jp/entry/we-started-scrum

目次

  • デイリー・スクラム(通称 DS)
  • スプリント・プランニング(通称 プランニング)
  • スプリント・レビュー&振り返り(通称 レビュー/振り返り)
  • オフィス勤務との兼ね合い
  • ツールまとめ

デイリー・スクラム(通称 DS)

(基本は)毎朝定時に開催される DS から朝が始まります。

開始時間になると、Google Meets にメンバーは集合します。カレンダーに予定を入れておけば、自動でミーティング開催場所が準備されるので非常に便利です。開発のミーティングは殆どが Google Meets で行われます。突発的なものは slack で済ませることもあります。

さて、最近ではその日の司会が決まっているので司会の人が画面共有をしながら、取組中のストーリー/タスクを確認していきます。 かつてはオフィスに模造紙でスクラムボードを作っていたこともありましたが、編集の便利さや画面共有を簡単にしたいということから Jamboard でスクラムボードを運用しています。 模造紙→Jamboard への移行は、リモートをテストしてみようと言う話になった3月頭頃からスタートしていました。

f:id:astamuse:20200819105423p:plain

Jamboard 内の構成は模造紙の頃と大きく変わってはいないですが、必要に応じてお知らせ欄を追加したり、それぞれのアイコン画像を設定したりと工夫もしています。

アイコン画像は視認性が高いので良いですね。 注目して欲しいコメントは、みんな自然と文字を大きくしてアピールしています。

スプリント・プランニング(通称 プランニング)

一週間の計画をたてるプランニングも Meets で行っています。

こちらも司会を立てています。リモートでの司会業は試行錯誤と行った感じでしょうか。 PdMからの説明で話を振ってもらったり、発言が少ない人に話を促してみたりと、司会の仕事は瞬発力が求められる面もあるので少し大変です。 お休みの人がいても大丈夫なように当番を回す形になってきました。大変さをシェアするという意味合いも結果的に大きいです。

プロダクトバックログ・スプリントバックログは Asana で管理しています。

f:id:astamuse:20200819105443p:plain

Asana はリモート前から使っていましたが、最近はプランニングで話し合うことを事前に開発の Wiki 上でまとめるようにしました。

Asana 上にはカード説明を最新の状況にしておくのが望ましいと思うのですが、説明が長くなりすぎると読みづらく、すぐに一番話したいことがどこなのか伝わりづらかったので議事録の場を事前に設けて読んでもらうことにしました。

話す話題を明確にするということは、リモートに限らず大事だなと実感しています。

スプリント・レビュー&振り返り(通称 レビュー/振り返り)

作業の完了をデモを中心に見ていく場なので、Google Meets で適宜画面を切り替えてデモをしてもらっています。

デモはオフィスでもディスプレイに繋いだものを見ていたので、個人的には変わりはないですね。 レビューは質問をするメインが PdM だから、話の交錯が起きづらいのかもしれません。

一方で振り返りはほとんどが話し合いです。 チームで issue だと感じていることと、スプリント内での各自の困りごとなどをテンショングラフを中心に振り返っています。

f:id:astamuse:20200819105630p:plain

伝わりづらいかもしれませんが、各自のアイコンと日時コメントをつけています。

タスクとして忙しくなりがち/悩みがちなことを共有することも出来ていますし、制限時間内で雑談をする場としても機能しているかと思います。 直近覚えているものだと、一人4分以内で振り返っていました。

リモートで顔を合わせていないこともあり、重要性が以前より増しているかもしれません。

オフィス勤務との兼ね合い

全員リモートを前提として各種ミーティングを開催していますが、色々な事情で出社をする人もいます。

自分が出社の機会に感じたことは、やはりディスプレイの違いでしょうか。 打ち合わせとは関係なさそうですが、リモートの打ち合わせは共有される画面を写す必要があるので、やはりディスプレイが大きいに越したことはないですね。

幸い、在宅でも会社がディスプレイを送る手配をしてくださったので開始当初から助かりました。 最初の時期に総務の方などの負担があったと思いますが、確実に生産性の向上につながっていると思います。

椅子も在宅で座る時間が長いので影響は大きいですね。姿勢をサポートする座椅子を個人的に使っています。 とはいえ、椅子はさすがに家に送られてきても、、、少なくとも自分は困ります。。

ツールまとめ

リモートで積極的に導入された - Google Meets(カレンダーから自動でルーム生成) - Google Jamboard(Web のみ)

以前より - slack - G Suite - Asana - Crowi(社内で立てている Wiki に利用)

また、会議中での会話が重ならないように、画面上にチャットを表示しやすくするアプリケーションを試してくれているメンバーもいます。 今後も、柔軟に試行錯誤をして生産性を上げられればと思います!

いかがでしたでしょうか

少しでもリモートでの雰囲気が伝われば幸いです。 それと同時に振り返ることで改善点も話し合いをしやすくなるかと思うので、定期的に振り返る機会は大事ですね。

また、リファインメントとの向き合い方がスクラム自体を非常に改善させたと感じています。 それを振り返るには時間が足りないのでそれはまたの機会に。

暑さ厳しき折、どうか皆様お元気でお過ごしください。 勝手にブログにお盆休みを設けた gyopi でした。

こんな情勢ですが、お約束のご案内となります。

チームメンバーと議論を深め合いながら成長していきたいエンジニア、デザイナー、PM の方を絶賛大募集中です! ご興味のある方は下記バナーの採用サイトからご応募いただければ幸いです。

SQLからC言語を呼ぶ方法 ~MeCab編~

前書き

お久しぶりでございます。Scalaでバックエンドを開発しているaxtstar(@axtstart)です。

ずいぶん昔になりますが、OracleDBでアプリ開発をしていたころ、DBの中でデータが(なぜか)バイナリで格納されていて、そのビット演算を行いながら検索するみたいな案件をやったことがあります。はじめはアプリサイドからSQLで頑張って演算していたのですが、あまりにも遅くて、結局OCI(Oracle Call Interface)を利用して、C++でバイナリを扱うように書き換えたら激的に速度が改善したことがありました。

今回ふと思い立ち、Postgresqlってそういうことができるのかしら?と思い至り今回のブログ担当を利用して検証してみることにしました。

なので、(確実に)プロダクション環境で実施するのははばかられるような内容ですのでご注意下さい。

f:id:astamuse:20200729085523p:plain

使用できる言語は...

ちなみに、今回対象としたPostgresqlはDockerHubから持ってきたpostgresql:latestを対象としています。

select version();

結果

version
PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit

現時点*1だとPostgreSQL12.3のようです。

上記imageの初期状態で、Postgresqlで使用できる言語は下記でした。

select * from pg_language;

結果

oid lanname lanowner lanispl lanpltrusted lanplcallfoid laninline lanvalidator
12 internal 10 False False 0 0 2246
13 c 10 False False 0 0 2247
14 sql 10 False True 0 0 2248
13398 plpgsql 10 True True 13395 13396 13397

なんと~デフォルトでcの文字がありますね!

どうやるのか?

OracleのOCIにあたるものがないのか調べているとspi(Server Programming Interface)というものがあることがわかりました。

Oracleの場合と同様、PL/SQL(PostgresだとPL/pgsql)からC/C++で書かれたプログラムを何らかの与えられた方式で呼び出せばよい感じ。

libpqというのを初めに見つけましたが、こちらはPro*C*2みたいなものっぽいですね。

  • C/C++ から SQLを呼び出す(libpg) ←これじゃない
  • SQLからC/C++を呼び出す(spi) ←これ

Server Programming Interface(spi)

PostgresqlはC言語とのインターフェースにサーバプログラミングインターフェースという名前の機構を用意していて、ユーザ定義のC関数をSQLから呼び出すことができるようです。

調べた限りだと、ソースコードのビルドに必要なパッケージとして以下が必要でした。*3

※imageのpostgresql:latestからの差分として必要という意味です。

apt-get install -y make clang llvm gcc postgresql-server-dev-12

またdb serverのインストール時にpg_configというプログラムが同時にインストールされ、これが様々な情報を教えてくれるようです。

例えば、PostgreSQLのサーバプログラム作成用のCヘッダファイルの格納パスとか

pg_config --includedir-server

結果

/usr/lib/postgresql/12/lib

詳しくはこちら

また、どのように作成するのかというのもかなり詳しくマニュアルに記載がありました。

C言語関数の部分を要約すると

  • 共有ライブラリとして作成すること(so、dll、dylib)
  • バージョン互換性マクロを一度だけ記述すること
  • 「version 1」呼び出し規約をサポートすること
  • 参照渡しの入力値の内容を決して変更しないこと*4

などなど。。。

なので結構マクロを多用する実装になるようです。

作るもの

せっかくなので、ちょっとだけ実用になりそうな(気がする)ものをサンプルで作ってみます。今回は、MeCabをインストールしてそちらを呼び出して、結果を返すことにします(本当はC言語のライブラリがあるので対象として適切だったのが本音)。

とはいってもこちらはメインではないのでサクっとaptで導入します

apt-get install -y mecab libmecab-dev mecab-ipadic-utf8

※MeCabの詳しい記事は↓こちら↓からどうぞ~ lab.astamuse.co.jp

作るものはこんな流れになります。

No 使用マクロ 意味
1 PG_MODULE_MAGIC 非互換性のチェック
2 PG_FUNCTION_INFO_V1(function) 関数宣言
3 Datum function(PG_FUNCTION_ARGS) Version-1呼び出し規約、引数引き渡し
4 PG_GETARG_xxx() SQLからの引数取得
5 palloc/palloc0 メモリアロケーション(マクロではない。。と思います。)
6 SET_VARSIZE サイズ確保
7 PG_RETURN_xxx() SQLへの返却設定

できたソース

ビルド用のmakefileはこちら

ビルドしてインストールしておきます

make
make install

下記ディレクトリにmecab_simple.soという名前で配置されます

/usr/lib/postgresql/12/lib

このユーザ定義関数を呼び出すにはファンクションとして定義する必要があります。

CREATE FUNCTION mecab(text) RETURNS text
     AS 'mecab_simple', 'mecab'
     LANGUAGE C STRICT;

その際、パス、ファイル名に関しては以下のルールに従います

第一引数

  • 絶対パス
  • 名前が$libdirという文字列から始まる場合、その部分はPostgreSQLパッケージのライブラリディレクトリ
  • 名前にディレクトリ部分がない場合、そのファイルはdynamic_library_path設定変数で指定されたパス内
  • 拡張子(.so、.dll、.dylib)を補って上記パスを検索
  • 上記以外は失敗

第二引数

  • 省略時は第一引数と同じとみなす
  • 指定時は関数

結果

f:id:astamuse:20200729011832p:plain
すもも

おお!どうやらうまくいったみたいですね!!

上記の一式をDockerfileでまとめているので、 ↓こちらに置いておきます。

github.com

おまけ

デフォルト機能ではないのですが、Postgresqlの拡張機能にplpython3uというものがあり、Postgresqlからpythonのスクリプトが実行できるようです。

事前準備として、postgresql-plpython3-12といったパッケージが必要なようです。

事前準備

apt-get install -y postgresql-plpython3-12

Postgresql上でExtensionを有効にします。

CREATE EXTENSION plpython3u;

Pythonのバージョンを確認してみます。

ファンクションを定義します。

CREATE FUNCTION pyversion()
  RETURNS text
AS $$
  import sys
  return sys.version
$$ LANGUAGE plpython3u;

バージョン確認

select pyversion();

結果

3.7.3 (default, Dec 20 2019, 18:57:59) 
[GCC 8.3.0]

こちらも機会があればもう少し調べてみたいと思いました。

最後に

Oracleと同様PostgresqlでもC/C++の呼び出しはサポートされていました。今回速度検証まではできませんでした、また、このような組み込みモジュールを使うのは一般的ではないかもしれないですが、マクロが充実していて、以前のOracleの時よりは楽にプログラミングできる印象*5でした。またpythonを利用するのも比較的簡単に実現できたので、こちらはもう少し深堀したくなりました。

最後になりましたが、アスタミューゼでは現在、エンジニア・デザイナーを絶賛大大大募集中です! 興味のある方はぜひ下記バナーからご応募ください!!

*1:2020/07/28現在

*2:もう比喩が若い人に通じない話をしているかもしれない

*3:条件によってはさらに必要かもしれません。

*4:変更すると、ディスク上のデータを破壊してしまうかもしれません。とのこと。。こわい

*5:llvmなどその他の技術の発展のおかげかもしれませんが。。。

Copyright © astamuse company, ltd. all rights reserved.