勉強会をtsudaる技術

メリークリスマス!🎄

この記事はMisoca+弥生 Advent Calendar 2019の25日目です。

qiita.com

最終日の記事は、初日から24日ぶり2回目となる黒曜(@kokuyouwind)がお送りします。

💎 Ruby 2.7 will be released!

ついに本日、Ruby 2.7 が正式リリースされますね!

Misocaでは id:eitoball の尽力により、すでにRuby 2.7対応のPull Requestがマージ待ちの状態です。年末までにリリースするかは未定ですが、遅くとも年明け最初の週にはリリースできると思います。

また、アドベントカレンダー初日に書いたActivePattern gemMethodMatchable gemも、Ruby 2.7.0がリリースされたら合わせてバージョンを上げる予定です。

Experimentalな機能とはいえパターンマッチには無限の可能性を感じるので、色々と試していきたいですね!

🗣 RubyKaigiでのTwitter実況

パターンマッチはRubyKaigi 2019で紹介された機能ですが、そのときにTwitterで実況した様子がTwilogに残ってました。

f:id:kokuyouwind:20191224164631p:plain:w300

こんな感じで、自分がカンファレンスや勉強会に行ったときはTwitter実況を行っていることが多いです。

いわゆるtsudaるというやつですね。*1

今回の記事ではこういった勉強会での実況について、なぜやっているのかや、意識していることなどをつらつらと書いていこうと思います。

なお記事タイトルの「技術」は、TechnologyではなくTechnicの方、ということでよろしくおねがいします。

❓ なぜTwitter実況するのか

自分がカンファレンスや勉強会でTwitter実況する理由はいくつかあります。

発表の理解度を高められる

Twitter実況では単にメモを取る場合と違い、140文字という文字数制限があり、また1つ1つのツイートをある程度独立させる必要があります。

このためうまく実況するためには「スライドの丸写し」や「トークの書記」をするのではなく、発表の内容を解釈した上で「背景」「主張」「例示」などを再構成する必要があります。

そうすると、発表を単に聞くのではなく「この話のポイントはどこだろう」「どういう文章だとこの主張が伝わるだろう」といった聞き方をすることになり、理解がかなり深まります。

間違いの指摘や補足情報を集められる

もちろん、ツイートすることで他の参加者の目に触れるということも重要です。

「ここはよくわからなかった」というツイートに説明をもらえたり、理解を間違っていた部分に指摘をもらえる場合もあります。

発信した内容を元に情報が集まってくるというのは、SNS実況ならではの利点といえるでしょう。

他の人の参考になる(かもしれない)

難しいところを自分なりの理解に落とし込んでツイートすることで、他の参加者の参考になる場合もあります。

実際にカンファレンスの懇親会などでは、「実況が参考になった」と声をかけていただくことがままあります。

せっかく発表を聞いて知見を広げるなら、参加者全員の利益になるように発信していけるとより良いんじゃないかなぁと考えています。

楽しい

いろいろ書きましたが、ぶっちゃけ一番の理由はこれです。

ただ話を聞くだけよりも、Twitterで実況しながら意見も色々出し合って交流しながら聞くほうが絶対楽しいと思います。

📝 Twitter実況のテクニック

そんなわけでメリットいっぱいのTwitter実況ですが、「発表を聞くこと」「140文字にまとめてツイートすること」を「両方」やらないといけないのが「Twitter実況」のつらいところです。

実況の際、個人的に意識しているテクニックをいくつか挙げておきます。

スライド中のキーワードを、トークで補い文章化する

だいたいのセッションは「スライド」と「トーク」から成り立っています。このうち、スライドには「重要なキーワード」や「分量の多い参考情報」などが抜き出され、文脈や詳細をトークで補う、というスタイルが一般的です。

そのため、ツイッターで実況する際はこの2つの情報をうまく混ぜないと「単にスライドを書き写す人(たいてい後で公開される)」「ただトークを書記する人(要点がまとまっていないない)」のようになってしまいます。

自分が実況をする際は、スライドを見て「キーワード」を把握しつつ、その意味が文章として伝わるようにトークの内容をまとめる、という書き方をすることが多いです。この書き方だと、要点を抑えた短い文章に再構成できることが多いです。

ツイートごとに話をまとめる

Twitterでは各ツイートが独立して人の目に触れる可能性があります。一方で、発表は前から順に流れがあり、スライド間で話が続くことがよくあります。

このため、スライドの区切りにはこだわらず「ひとつの題材や主張」ごとに話を再構成すると、読みやすいツイートになる場合が多いです。

それでも長くなりそうであれば「例示を別ツイートに分ける」「詳細をある程度省く」「短く言い換える」「略称を使う」などで短くしていくと、なんとか140文字に収まる…こともあります。

自分の意見・解釈は区別できるように書く

「tsudaる」という単語は「自分の主張を交えずにひたすら発表を垂れ流す」という意味ですが、勉強会の実況では自分の意見や解釈を発信することも重要だと思います。

ただし、このときに実況の中に突然自分の意見が混じると、他の人や後から見返した場合に「どれが発表内容で、どれが実況者の意見か」がわからなくなってしまいます。

このため自分の意見を混ぜる場合は、以下のように実況部分を鉤括弧でくくって区別が付くよう意識しています。

また1ツイートまるまる自分の意見の場合は、「なるほど」「とのことだけど」「じゃないかなぁ」「だと思うな」などの言葉を交えることで、主観的な意見であると伝わるようにしています。

🤔 気になっていること

タイムラインの流速

勉強会ではひたすら実況していることが多いのですが、普段のツイート量とあまりに違うため、フォロワーのタイムラインを埋めていないかはちょっと気になるところです。

場合によっては実況用にアカウントを分けても良いのかもしれません。

また勉強会ハッシュタグの流速も、他に活発な人がいないと一人で埋める感じになって申し訳なくなることがあります。

逆に実況者が多すぎると同じ話が何度も流れてくることになるため、うまい実況が他にあるときは感想メインで呟くようにすることもあります。

後から遡るのが大変

Twilogを使ってさかのぼったり、Togetterにまとめられたのを見たりすることもできますが、やはり後から確認しようとおもうと検索性が悪いです。

これについてはアイドルマスター Advent Calendar 2019で書いたセトリを見ながら感想を書けるサービスを作りたかった話とつながる部分があり、もしかしてセッションに紐づけて実況できる & セッションごとに見返したり、イベント通したレポートが見たりできるサービスがあれば解決するのでは…? と思って色々考えています。

勉強会もカンファレンスもライブイベントだからね。何もおかしくないですね。

🎅 まとめ

勉強会の実況について、つらつらと書いてみました。

来年もNGK2020SBurikaigi2020RubyKaigi 2020などに出没してはTwitter実況しまくる構えですので、みなさま何卒よろしくおねがいします。

それでは、良いお年を!

宣伝

Misocaでは勉強会でTwitter実況したいエンジニアを募集しています! 勉強会補助制度もあります!

*1:単に発言をまとめるだけではなく自分の意見を混ぜたりするので、厳密にはtsudaるとはちょっと違いますが。あと、もはや死語かもしれません…

統計的な分析を基にチュートリアル機能を廃止した話

こんにちは!遊軍チームに所属しているRKTMです。

先日、ボルダーの課題開拓で3本の課題設定&初登できました。簡単な課題ですが、初登者として名前が残るのは特別な気分ですね。

f:id:RKTM:20191124134247j:plain:w350
未開拓の岩。倒木と、クラックの落ち葉と土とコケを処理してやっと登れます。

機能の廃止を分析に基づいて決断する

さて、最近Misocaでは、「チュートリアル機能」を廃止しました。

機能を廃止するというのは大きな決断でしたが、今回はその廃止にいたるまでの経緯と分析について書くことにします。

当たり前のことを当たり前にやっているだけですが、Misocaの意思決定の一例としてお読みいただければ幸いです。(分析は、機密情報に触れる部分があるため、概要に留めています。また、KPIについても同様に詳細は省略しています。)

「チュートリアル機能って効果あるの?」

Misocaにおけるチュートリアルは契約直後のお客様全員に表示される機能でした。 内容は最初の請求書を1枚作る手順をインタラクティブに説明するものです。 f:id:RKTM:20191125154436p:plain

チュートリアルを導入したのは4年前。 当初はKPIに効果があることを確認しましたが、それ以降ユーザー新規登録導線に様々な変更があったものの、チュートリアルは大きく変更されないまま残ってきました。

ですが、ここ数ヶ月で「チュートリアル、消したほうが良いのでは?」という気運が高まりました。

理由は以下の通りです。

  • 開発面:古いコードであり改修もほとんど行われておらず、またメタプログラミングも使われており、改修できる開発者も限られてレガシーコードと化していた(注:開発当時は目的を達成するためにこれで正解だったのですが、開発者の構成の変化などによりメンテしづらくなってきました)
  • 効果面:「ユーザー新規登録導線が色々変わったのに、今もチュートリアルは効果あるの?」という疑問
  • 改善要求:ユーザー体験を向上するために、現状のチュートリアルではない別の施策を実施したい

消す?残す?データを基に判断しよう

開発者としては

  • メンテしづらいコードは削除してスッキリしたい気持ち
  • せっかく作ったものだから残しておきたい気持ち

の両方を感じます。

が、そこは感情ではなく、データを基に効果の有無を判定することにしました。

データ分析

以下の通り仮説を立てました。

  • 帰無仮説: チュートリアルを開始した群とチュートリアルを開始しなかった群において、KPIに与える影響に差はない。
  • 対立仮説: チュートリアルを開始した群とチュートリアルを開始しなかった群において、KPIに与える影響に差はある。

地道な作業(チュートリアルを開始した/していないの判断方法をどう定義するか、どのKPIを対象とするか)を経て、データを集め、JupyterLabを使ってデータを分析します。

f:id:RKTM:20191125154756p:plain
KPIに与える影響を比較

棒グラフで見てみると、チュートリアル開始した群も、開始しなかった群も、ほぼ同じ値を示していました。

ぱっと見でも差がないのでこの段階で「差はなし!」と結論を出したいところですが、念の為、カイ二乗検定を行います。

f:id:RKTM:20191125154957p:plain
カイ二乗検定の結果

p値は5%よりも大きなものであり有意差があるとは言えません。 よって、「帰無仮説: チュートリアルを開始した群とチュートリアルを開始しなかった群において、KPIに与える影響に差はない。」は棄却できないことがわかりました。

前述の「開発面、効果面、改善要求」の通り、

  • チュートリアル機能はレガシーコードと化していたこと
  • 明確に効果があると言えなくなったこと
  • チュートリアル以外の施策に取り組みたいこと

以上の点からチュートリアル機能を削除することを決定しました。

今後は、チュートリアルがなくてもわかるようなUIを設計する、など、施策を試して行きたいと思います。

データ分析によって、自信をもって判断する

一度作り込んだ機能はサンクコストもあり、感情的にも消しづらいものです。

今回は統計的な分析を行うことで、感情ではなく論理によって、機能を削除する決断ができました。

チュートリアルは「過去効果があった」「今も効果が(多分)ありそうだ」という印象で残されてきた機能だったので、このタイミングで改めて分析し、効果を測ることができて良かったです。

Misocaでは、まだまだ分析して改善すべきところがあるため、今後も統計的な分析を続けていこうと思います。

採用

Misocaでは、データを分析して、ロジカルに判断できるエンジニアを募集しています。

www.wantedly.com

参考サイト

カイ二乗検定 | Logics of Blue

研究の有意性とは?p値に頼るべきでない理由 | エディテージ・インサイト

🎄Misoca、今年もアドベントカレンダーやるってよ

メリークリスマス!よいお年を!@mugi_unoです!

🎄今年もアドベントカレンダーやります🎅

3年連続となりますが、今年も弥生と合同でアドベントカレンダーをやります。

qiita.com

まだ何を書くかノープランですが、「フロントエンド周りでなんか楽しくて愉快な感じのことを書く」という説明で私もひとまずエントリーしてあります。

なんか楽しくて愉快な感じのことを書ければいいなと思います。

昨年の様子

ちなみに昨年はこんな感じでした。↓

tech.misoca.jp qiita.com

なんと560ブックマークも記録した記事もあったようですよ。すごいですね!

あっ、私の書いたやつですね!

mugi1.hateblo.jp

というわけで

きっと今年も(私以外から)去年を超えるクオリティの記事が爆誕することでしょう。

楽しいアドベントカレンダーをMisoca/弥生からご提供できれば思います!

木曜の夜はもくテク!!(Misoca冬のLT大会のご案内)

こんにちは。 @KawamataRyo です。
最近、ダイエットも兼ねてボクシング🥊をはじめました。(Fit Boxingではなくリアルボクシング)
「良いコードは良い筋肉から」ということで、頑張って行きたいです。

f:id:ba068082:20190918113348p:plain

皆さん、もくテク はご存知ですか?
もくテク は弥生株式会社が1年以上主催している勉強会です。
10月にもMisoca主催の「秋のLT大会」を開催し好評でした。

今回その第二弾として、12月5日19:00よりの「もくテク powerd by Misoca 冬のLT大会」を東京、名古屋、松江会場にて開催します!!
(公募LT枠もあるので、どしどしご応募お待ちしてます!! )

mokuteku.connpass.com

この記事では、その告知としてMisocaエンジニアのLT内容をご紹介します。

Misoca LT枠テーマ一覧

Redash で作る「じぶんダッシュボード」 @mallowlabs

計測できないものは改善できない。
じぶんのパフォーマンスを可視化する仕組みを Redash で作ったのでそれを紹介します。
運動量や、体重や睡眠時間、心拍数、生産性などを一つのダッシュボードで見られるようにする仕組みの裏側について話します。

Slackワークフロー活用術 @kokuyouwind

Slackでワークフロービルダーが利用できるようになりました。
Misocaでも早速様々な作業でワークフローを活用しているので、事例やTipsを紹介していきたいと思います。

Androidで郵便番号から住所を得る @k0matatsu

iOSではCoreLocationという標準ライブラリで郵便番号から住所を取得できますが、Androidには標準で用意されたものがありません。
Google Map APIも使わずに郵便番号から住所を得る処理を書いたので、その経験を踏まえ郵便番号の仕組みから解説しようと思います。

サクッと理解 GraphQL 入門 @KawamataRyo

GraphQLは昨年ごろからよく聞くようになりましたね。
Misocaでも新機能開発でのGraphQL導入の機運が高まっています。
今回はそれに向けて個人で勉強した内容(主に「初めてのGraphQL*1」より)をGraphQL入門者向けにまとめて話したいと思います。
(当初Firebase 関連で考えてたのですが、テーマ定まらず変更しました..)

当日のスケジュール

公募LTの応募状況で前後しますが、大体このようなスケジュールで考えています

時間 内容
18:45〜19:00 受付
19:00〜19:10 会場説明・Misoca説明
19:10〜19:20 Misoca LT1
19:20〜19:30 Misoca LT2
19:30〜19:40 Misoca LT3
19:40〜19:50 Misoca LT4
19:50〜20:00 休憩
20:10〜20:20 公募 LT1
20:20〜20:30 公募 LT2
20:30〜20:40 公募 LT3
20:40〜20:50 公募 LT4
20:50〜21:30 懇親会

おわりに

いかがでしたしょうか?
最近話題のSlackワークフローのMisocaでの活用術からRedashでの自分ダッシュボードまでかなりバラエティに富んだ内容になっています。
イベントの詳細な情報はconnpassの募集ページ をご確認ください。
公募LT枠も絶賛募集中です!!(マジで応募頼むで!!🙏 )

会場は東京、名古屋、松江、またYouTubeでのLIVE配信も予定しています。

採用情報

Misocaでは、技術について語るのが大好きなエンジニアを募集しています。

recruit.misoca.jp

*1:O'Reilly Japan 発行 初めてのGraphQL ――Webサービスを作って学ぶ新世代API

認証機能のないアプリケーションでOAuth2認証を提供する - OAuth2 Proxy 編

こんにちは。Misoca 開発チームの eitoball です。先日、いびがわマラソン2019 を走ってきました。フルマラソンは2回目ですが、初めてサブ4(グロスで3時間55分、ネットで3時間47分)を達成しました!

はじめに

今回は、Webサイトへのアクセス制限に GitHub や Facebook の認証を簡単に使えるようにできる OAuth2 Proxy というソフトウェアの紹介です。

OAuth2 Proxy

この記事、https://tech.misoca.jp/entry/2015/04/07/145743 では、mod_auth_openidc という Apache のモジュールを利用して、ウェブサイトに認証機能を追加する方法を紹介しました。認証に使うサービスは、OpenID Connect Provider である必要があります。OAuth2 Proxy では、認証に使うサービスは、OAuth2 での認証を提供していれば、利用することができます。

OAuth2 Proxy は、リバースプロキシサーバーのように動作して、下の図の secured upstream http service で表現される認証をつけたいWebサイトの前段でリクエストを受けつけます。外部サービスで認証済みの場合は、リクエストを後段で動作しているWebサイトに渡して結果を返します。認証していない場合は認証用のページを表示します。

OAuth2 Proxy の前段に、Apache や Nginx などを置いて、SSLターミネーションとすることもできますし、OAuth2 Proxy が直接、SSLを使った通信をすることを可能です。

設定例

GitHub を使って、認証する例を説明します。

インストール

aptやrpmパッケージは提供されていないようです。そのため、https://github.com/pusher/oauth2_proxy/releases より、使用するオペレーティングシステムに応じたパッケージをダウンロード・解凍して、/usr/local/sbinoauth2_proxy というバイナリを配置します。

$ curl -L -o oauth2_proxy.tar.gz https://github.com/pusher/oauth2_proxy/releases/download/v4.0.0/oauth2_proxy-v4.0.0.linux-amd64.go1.12.1.tar.gz
$ tar xzf oauth2_proxy.tar.gz
$ sudo cp oauth2_proxy-v4.0.0.linux-amd64.go1.12.1/oauth2_proxy /usr/local/sbin/

GitHub 側の認証情報の取得

「OAuth Apps」で認証情報を設定します。組織の場合は、ダッシュボードページの「Settings」タブから「OAuth Apps」からアクセスできます。多分、http://github.com/organizations/<組織名>/settings/applications のようなURIになります。個人の場合は、ここ から設定できます。

「New OAuth App」ボタンをクリックして、「Application name」、「Homepage URL」、「Authorization callback URL」を指定します。「Authorization callback URL」には、「https://<開発サーバーのホスト名>/oauth2/callback」を指定します。指定したら「Register Application」ボタンを押して、設定を保存します。

New_OAuth_Application.png (144.3 kB)

OAuth2 Proxy の設定

以下のような内容を/usr/local/etc/oauth2_proxy.cfgとして配置します。

http_address = "127.0.0.1:4180" # OAuth2 Proxy のアドレスとポート

upstreams = [
  "http://127.0.0.1:3000/" # 認証情報を付与したいサーバーのURL
]

email_domains = [ 
  "*" # 今回はどんなメールアドレスも認証する
]

client_id = "<GitHubで設定したOAuth AppのクライアントID>"
client_secret = "<GitHubで設定したOAuth Appのクライアントシークレット>"

provider = "github"

github_org = "<認証したいGitHubのorganization>"

cookie_secret = "<クッキーの暗号化鍵>"

設定できる項目などについては、OAuth2 Proxy の Configuration を参照して下さい。

cookie_secret には、ruby -rsecurerandom -e'puts SecureRandom.base64(16)'python -c 'import os,base64; print base64.urlsafe_b64encode(os.urandom(16))' のようなコマンドを実行して生成するのがお勧めです。

後、OAuth2 Proxy が自動起動できるようにします。systemd を使っているので、以下のような内容を /etc/systemd/system/oauth2_proxy.serviceに配置します。

[Unit]
Description=OAuth2 Proxy

[Service]
Type=simple
User=root
ExecStart=/usr/local/sbin/oauth2_proxy -config=/usr/local/etc/oauth2_proxy.cfg

[Install]
WantedBy=multi-user.target

そして、以下のコマンドを実行して、設定の有効化とOAuth2 Proxyを起動をします。

$ sudo systemctl enable oauth2_proxy
$ sudo systemctl restart oauth2_proxy

Apache の設定

Apache 側では、mod_proxy モジュールを有効にして、OAuth2 Proxy のリバースプロキシとして設定します。以下のような設定をします。

<VirtualHost *:443>
  ServerAdmin admin@example.com
  DocumentRoot /var/www/html
  ServerName sugoi-server.example.com
  
  # SSL の設定
  
  ProxyPass / http://localhost:4180/
  ProxyPassReverse / http://localhost:4180/
  ProxyPreserveHost On
  ProxyRequests Off
</VirtualHost>

確認

Apache を再起動して、認証を設定したサイトにアクセスすると以下のような画面が出ると思います。

Sign_In.png (18.6 kB)

「Sign in with GitHub」ボタンを押すとGitHubでの認証画面が出るので、ログインとパスワードを入力すれば、サイトにアクセスできるはずです。

最後に

OAuth2 Proxy の紹介とそれを使って、認証機能のないWebサイトに簡単に認証を提供する方法を紹介しました。

Misoca では、このようなちょっとしたことに興味もあるソフトウェアエンジニアやサイトリライアビリティエンジニアを募集しています。

recruit.misoca.jp recruit.misoca.jp

アプリの新しい画面がどのように生まれたか

こんにちは、こまたつです。
先週リリースされたAndroid版Misocaにて請求書などの詳細を表示する画面のリニューアルを行いました。
あたらしい詳細画面で表示する内容は元の画面とほとんど変わりありませんが、より見やすく項目を整理しました。

今回はこのリニューアルの過程でどのように検討・決定してきたかを少しだけご紹介したいと思います。

抱えていた課題

昨年6月にアプリをリリースしてから、様々なアップデートや軽減税率への対応を経て請求書などの詳細情報を表示する画面(以下、詳細画面とします)は複雑度を増していました。

詳細画面はアプリのなかでも中心となる存在で、郵送・メール送信などの発行処理のほか、プレビューや複製などの多数の操作が行えます。
また軽減税率によって税率別の合計欄などが追加され、表示したい項目が非常に多く情報の優先度づけも困難を極めていました。

初期のバージョンは絶妙なバランスの上でなりたっており、ジェンガのように積み重なったアップデートで抜き差しならない状況になっていました。
これは新たな機能追加がしにくいだけでなく、はじめて使うユーザーがアプリを使いはじめるのを困難にしてしまっていると考えました。

どうあるべきか

Android版Misocaでは取引にまだあまり慣れていない層をメインターゲットに据えています。
ユーザーのITリテラシーは必ずしも高くはなく、なかには各項目の合計を電卓で検算したいという方もいます。
請求業務そのものも「やらなければいけないこと」であり、低いモチベーションでも間違いなく請求できる必要があります。

煩雑な画面はひと目でその学習コストの高さが伝わりモチベーションを削いでしまうので、よりシンプルな画面にする必要があると考えました。

問題提起と検討

新たな機能追加のタイミングで、現行バージョンが既に限界であることと議論の元とすべく改善案を提案しました。

f:id:komatatsu:20191107192124p:plain

これは使い方によって表示を切り替えられるようにした案です。
ここからどのような画面であるべきか、デザイナーと一緒に今あるものは抜きにして理想の姿を探しはじめます。

f:id:komatatsu:20191107192140p:plain f:id:komatatsu:20191107192150p:plain

これは数日後にデザイナーのみずのが出した検討案です。
この時点でほぼ原型ができています。

ほとんど同じタイミングでまるやまも検討案を作ってくれました。

f:id:komatatsu:20191107181542p:plain

どちらも値を右側に置くことでレシートに近い表現になっているのがわかります。
この配置によって大事な金額部分が目で追って確認しやすくなっています。
また現実世界に既に存在するものに似せることで、ユーザーの学習コストが抑えられます。
他にも取引先を確認しやすいように導線を追加したり、たくさんの工夫が詰め込まれています。

これらのいいとこ取りをしてベースの案ができたので、ここから表示のバリエーションも含めた検討にはいります。

変換先文書

f:id:komatatsu:20191107192207p:plain

これは変換先文書一覧という、複製機能で作成した文書一覧へのリンク位置を検討している様子です。
表示している文書との関連性や、他の導線との兼ね合い、表示の意味などで議論が白熱しました。

しかし調べてみると利用頻度が非常に低くく、白熱する議論に対してユーザーに与えられる価値が釣り合ってなさそうな事がわかりました。
このリストを代替できる機能もあるため、総合的に考えたうえで削除しようという判断になりました。*1

回収保証

f:id:komatatsu:20191107192217p:plain

これは回収保証という、売掛金の回収ができなくなった場合に損害を補填してくれるサービスのステータス表示です。
今までは最下部に表示されていましたが、合計欄が下にきたので最上部へ移動しました。
利用登録が済んでいる場合にしか表示されない*2うえ、健全な取引のためにぜひ使ってほしいサービスなので最上部に来ても違和感なく、満場一致でした。

最終的にどうなったか

f:id:komatatsu:20191107182028p:plain

日付などの項目が右側に揃っているので、視線移動が抑えられ迷いにくい配置になりました。
件名が強調され、情報の階層がわかりやすくなっています。
操作の必要な処理のうち利用頻度の高いものを下側に集めたので、多くのユースケースでスマホを持ち直さなくても片手で素早く目的が達成できます。
郵送などを行うステップ数がひとつ多くなっていますが、これは慎重に行うべき操作なのであまりネガティブな意見は出ませんでした。

これからのはなし

Android版Misocaではユーザーが本業に集中出来るよう、それ以外の部分をかんたんに手早く済ませられる状態を目指しています。
まだまだ足りない部分が多いですが、ペースを上げて開発に取り組んでいますので引き続きよろしくおねがいします。
開発を手伝ってくれるメンバーもまだまだ募集しております。
ぜひ一度御覧ください。

recruit.misoca.jp

*1:あるものが消えるインパクトはとても大きいので、消して軽い気持ちで削除したわけではないです

*2:まだモバイルからの使い勝手がいいとは言えない状況なので、表示は控えめになっています

OOUI社内勉強会を開催しました

こんにちは、@torimizunoです。

10月になってHiGH&LOWの新作映画が公開されたことが嬉しく、強く生きているこの頃です。

f:id:torimizuno:20191028155150p:plain

最近Misocaのデザインチームでは、全6回に渡りOOUIの社内勉強会を行いました。

その後メンバーでオブジェクトについて議論する機会が増えたり、思考やアウトプットに効果を感じているので、どのような目的や流れで勉強会を実施したのかを共有したいと思います。

目的

OOUI(オブジェクト指向ユーザーインターフェース)について、雰囲気理解でなく、個々が理解して考え、UIに落とし込む能力を鍛えるため勉強をする。 知見が高まってきたら、社内でのオブジェクト指向を親会社 (弥生株式会社)との共同プロジェクトにも発展させていきたい。

実施方法

  • 1回1時間の全6回で実施
  • 社内デザイナーは共通理解度を深めるため、基本的には参加
  • デザインパートナーの方や社内メンバーは自由参加
  • Zoomでつなぎ、Scrapbox上で勉強会を実施

流れ

ソシオメディアさんのOOUIの記事をベースに、前半はインプット、後半はアウトプットに重点を置いて勉強会を組み立てました。

(ソシオメディアさん、記事とても活用させていただきました!ありがとうございます!)

  • 第1回 輪読会
    • https://www.sociomedia.co.jp/7279
    • 記事を30分黙読しながら各自メモや話したいことをまとめる
    • メモを共有して、ディスカッション
  • 第2回 輪読会
    • https://www.sociomedia.co.jp/8740
    • 記事を35分黙読しながら各自メモや話したいことをまとめる
    • メモを共有して、ディスカッション
    • この回はエンジニアも参加してくれて、継承や細分化の話をしてくれました
  • 第3回 準備運動
    • https://www.sociomedia.co.jp/8753
    • 記事を参考に、OOUIの実践を実施
    • 記事のユーザー要件をもとに、35分のラフスケッチ
    • 各自のラフスケッチの共有とディスカッション
  • 第4回 準備運動
    • https://www.sociomedia.co.jp/8753
    • 前半
      • 記事を参考に、10分でモバイルアプリケーションのメインオブジェクトを探す
      • この時はメルカリ、Spotify、SmartEXを各自調査しました
      • 調査後、10分で共有とディスカッション
    • 後半
      • 記事を参考に、10分でデスクトップアプリケーションのメインオブジェクトを探す
      • この時はGoogleカレンダー、Trello、Gmailを各自調査しました
      • 調査後、10分で共有とディスカッション
  • 第5回 実践
    • 40分でMisocaのメインオブジェクトを抜き出す
    • 残りの時間で共有、ディスカッション
  • 第6回 実践
    • 抜き出したMisocaのメインオブジェクトで、40分で改めてラフスケッチをする
    • 残りの時間で共有、ディスカッション

↓Scrapboxでの様子

f:id:torimizuno:20191028152851p:plain

勉強会を開催してみて

全6回とも、社内だけでなくデザインパートナーの方にも参加いただけて開催することができ、純粋に嬉しかったです。

実際に自分たちのサービスのオブジェクトを見つめ直し、未来の話ができたことで、有意義な時間になりました。

自分自身、勉強会前と比べ強くオブジェクトを意識するようになり、UI設計やレビューでも言葉にする機会が増えました。

特に文言については、デザインチーム内ですぐに改善に移ろう、という話ができたので、今後の改善に活かしていきたいです。

参加メンバーの感想

@kanizmb

勉強会に参加したことでソフトウェアにおけるオブジェクト同士のつながりやそれぞれが持つふるまいを意識したり、使用する言葉づかいに気を配ったりするようになりました。 見た目のデザインを行う前に、オブジェクトの構造をふまえた情報の設計を行う手順を入れることで、より骨太なデザインを提供していけるのではと思います。

またリモートワーク体制の都合上、業務以外で交流する機会が少ない弊チームですが、会を通じてわいわいやれてよかったです。いろいろな感想や意見が飛び交い、一人で学ぶのとはまた違った角度で捉えられました。 今回のように時間を区切って即興でデザインしてレビューし合うのも、続けていくと良い訓練になりそうです。

@rikanezu

OOUIへの知識が全く無かったためまずは輪読会のみに参加しました。 単純に読む機会ができたことで内容について理解できたのはもちろんのこと、 読みながら思ったことを各々でScrapboxに書いていき、そのあとに各々の感想を発表したので自分だけでは噛み砕けなかった部分も理解することができ良かったです。 実務でもデザイナーが言おうとしていることが理解できるようになったので、やり取りもスムーズになりました。 デザイナーでなくてもUIの良し悪しの判断をする機会は多いため、感覚的ではなく共通言語で話せるようになり今回参加して学ぶことができてよかったです。

@masarumaruyama

「何がオブジェクトで、それがどのようにUIと関係するのか」を意識しながら、色んなプロダクトに触れてみたり、実際に画面を起こしてみたり、意見を交換したりと、発見の多い勉強会でした。

オブジェクトとアクションの関係を明確にすることで、画面遷移・ナビゲーションのつくり方、言葉の選び方、プラットフォームに依存しない体験の考え方など、大小さまざまな視点がリンクしました。

また、同じプロダクトに関わっているメンバーで開催したことで、日常業務ではOOUIの考え方が共通言語として扱えるようになり、コミュニケーションの解像度が上がりました。

今回は基本的にデザイナー中心の参加でしたが、直感的に理解できる内容が多いため、プロダクトの設計に関わる、あらゆる立場の人が馴染みやすい考え方だと思いました。今後、チームでプロダクトを考える上で、コミュニケーションの軸の一つにできそうな可能性も感じています。

採用情報

Misocaでは、一緒に活発に勉強していけるデザイナーを募集しています。

recruit.misoca.jp