テキストコミュニケーションは「まろみ」が重要!という話

こんにちは Misoca 開発チームの id:mallowlabs です。 社内では「まろさん」「まろぶさん」などと呼ばれています。

Twitter のタイムラインなどで「リモートワーク」という言葉をよく見かけるようになりました。 Misoca では、承認や事前連絡なしで、オフィスでも自宅でも働ける運用を長く続けています。 そんなリモートワークに慣れたメンバーに「リモートワークでなにか工夫してることある?」と聞いたところ、「テキストコミュニケーションで表現がキツくならないように気をつけている」という意見がいろんな人から出ました。

この工夫のことを「まろみ」を出す、と名付けたところ、色々な「まろみ」の出し方が集まってきて、私自身も「確かにやってるなぁ」という内容が多かったので、まとめて紹介します。

語尾に「ー」をつける

「よろしくお願いします」よりも
「よろしくお願いしますー」の方が柔らかく感じるよねという意見が出ました。

f:id:mallowlabs:20200221142348p:plain

私の例だと昼食に出るときまでまろみを出していますね。

同じ理由で「〜」をつけるという人も多くいました。わかる〜。

語尾に「!」をつける

「わかりました」よりも
「わかりました!」の方が柔らかく感じるよねという意見も出ました。

f:id:mallowlabs:20200221142816p:plain

私の例だと、とにかくたくさん「!」をつけていますね。 「!」や「?」を重ねることでまろみを出す人が多い印象です。

「ぁ」「ぇ」を多用する

「そうですね」よりも
「そうですねぇ」の方をよく使うという意見が出ました。

f:id:mallowlabs:20200221143335p:plain

私の例だと「かなぁ」という感じでまろみを出していますね。 個人的には「修正すべきだと思います」と断定してしまうと、受け取り側に強制的な印象を与えてしまうと感じているので、100%の自信がないということを伝えたいときは「修正した方がいいかなぁと思います」という表現を使っています。

絵文字を多用する

絵文字を使うとそれだけで柔らかくなります。

Misoca の絵文字の使い方については以下の記事がまとまっていて雰囲気がつかみやすいです。

tech.misoca.jp

f:id:mallowlabs:20200221144005p:plain

私も絵文字を多用していますね。 使いすぎると年齢がバレるという意見もあり、使い方が難しいです。

他にも

  • 「…!」をよく使う。
  • 「では?」という表現は避けてる。

など、それぞれ気をつけていることがいろいろ出てきて興味深かったです。

まとめ

意外とみんなが気をつけてテキストコミュニケーションをしていることがわかって面白かったです。 テキストコミュニケーションは表情や声のトーンがわからない分、対面でのコミュニケーションよりも、相手がどう受け取るか?を考えてコミュニケーションするのが重要だなぁと思いました。

採用

Misoca ではまろみのあるテキストコミュニケーションが得意なメンバーを募集しています!!!

www.wantedly.com

Misoca とRuby コミュニティの関わり

id:eitoball です。先日、2020年01月31日(金)と2020年02月01日(土)の2日間に通算5回目となる Rails Girls Nagoya が開催されました。Misoca は会場スポンサーとして、セミナールームを貸し出しました。僕自身は、コーチとして参加しました。

Rails Girls 以外にも、Misoca はカンファレンスや勉強会などの Ruby コミュニティに色々な関わりをもっています。どのような Ruby コミュニティに関わっているかを紹介したいと思います。

RubyKaigi

RubyKaigi は、Ruby言語に関する国際カンファレンスです。日本国内外から参加者が集まる世界でも大きなカンファレンスと1つです。2020年は長野県で開催 されます。

Misocaが、RubyKaigiと関わるようになったのは、2013年から、請求書スポンサーからでした。 2016年はドリンクアップスポンサーとして、2017年からは通常のスポンサーとして協力しています。RubyKaigi 2020 も引き続き、協力させてもらう予定です。

地域Ruby会議

地域Ruby会議 は、「RubyKaigiのようなイベントをいろんな地域でやってしまおうという」という試みです。いくつかの地域Ruby会議にMisocaがスポンサーとなったり、Misoca の社員が個人的に運営を手伝ったり、登壇しています。

名古屋Ruby会議

名古屋で開催される地域Ruby会議です。2011年から4回開催されています。最近は、大須演芸場 を会場として利用しています。

Misoca はスポンサーとして、協力しました。id:eitoball は、第1回からスタッフとして参加しています。@kokuyouwind が、前回「入門 関数型-ish プログラミング on Ruby 」 で登壇しました。

富山Ruby会議

富山で開催される地域Ruby会議です。昨年11月に第1回が開催されました。

Misoca は懇親会スポンサーとして、協力しました。@mugi_uno は、スタッフとして参加していました。@kokuyouwind が、「読みやすいコードとRubyらしいコード」で登壇して、@mizukmb が LT に参加しました。

地域Rubyの会

地域でのRubyistの集まりです。このページ に記載されているように全国にたくさんの集まりがあります。Misoca の社員が個人的に運営している会がいくつかあります。

Ruby東海

Ruby東海 は、名古屋近辺にて Ruby に関する活動を行っているコミュニティです。主に id:eitoball が運営しています。月に約1回開催しています。会場は、Misoca のセミナールームです。

Toyama.rb

Toyama.rb は、富山県とその周辺地域のRubyistのためのコミュニティです。@mugi_uno が運営しています。月に1回開催しています。

さいごに

Misoca は、会社として、社員が個人として、RubyKaigi、地域 Ruby 会議、地域 Ruby の会へと様々に関わっています。今回は、Ruby コミュニティのみでしたが、

@k0matatsu が、DroidKaigi の運営に参加していたことがあったり、MISO MOKU といったもくもく会を定期的に開催しています。Ruby コミュニティにもさらに関わりを強くしつつ、他のコミュニティにも関わっていくことができればと考えています。

ということで、Misocaではコミュニティにも興味あるエンジニアを募集しています。

Redashから始める計測生活

Misoca開発チームの黒曜(@kokuyouwind)です。

先週の土曜日に富山Burikaigi 2020でパターンマッチの話をしてきました。

M@S寿司… もとい鱒寿司も食べられたので満足です。

📊 社内Redash

去年の開発合宿で社内Redashが立ち上がり、現在では社内KGI/KPIやSREチームのSLOなど、いろいろな指標の可視化に活用されています。

tech.misoca.jp

tech.misoca.jp

とはいえ、もっといろいろなものを測りたくなってきますよね。

🤖 リリース準備にかかる時間の計測

リリース準備にかかる時間が意外と長いのでは? またリリース前のトラブルが多いのでは? という問題意識があり、これをRedashで可視化したくなりました。

Misocaでは現在、以下のような流れでリリース準備が行われています。

  1. Slackの特定チャンネルで「リリースしたい」と発言する
  2. 以下の2つが並列で起動する
    1. リリース前のテストジョブ(Jenkins)
    2. ステージング環境へのデプロイ(CodePipeline)
  3. 2b. が終わったらビジュアルリグレッションテストのジョブが起動する(Jenkins)
  4. 2a.3.のジョブが両方完了したらリリース準備完了
    • それぞれのジョブ完了はSlackに通知される

順序を図にすると以下のような流れです。

f:id:kokuyouwind:20200129183113p:plain

「リリース準備にかかる時間」は1.から4.までの時間ですが、いくつかのツールをまたいでいるため、どうやって計測するかという問題がありました。

🐍 Python Data Source

ここで1.4.はどちらもSlackを介しているため、Slackの発言時刻を使えば簡単に計測できるのでは? と思いつきました。

RedashにはPythonデータソースがあるので、Slack APIを叩くことができますね。

ただしPythonデータソースはオンプレミスでないと利用できず事前の設定も必要なので、データ加工が必要なければJSON data sourceを使うほうが良いかもしれません。

例えば #release チャンネルで「リリースしたい」と発言した時刻を集めるためのクエリコードは以下のようになります。

import requests
import json
import datetime
import re

url = "https://slack.com/api/search.messages"
token = "(your_token)"
payload = {
    "token": token,
    "query": 'in:#release "リリースしたい"',
    "sort": "timestamp",
    "count": 100
}
response = requests.get(url, params=payload)

json_data = response.json()
messages = json_data["messages"]["matches"]
result = {}

for i in messages:
    add_result_row(result, {
        'datetime': datetime.datetime.utcfromtimestamp(float(i["ts"]))
    })
add_result_column(result, 'datetime', '', 'datetime')

これで「リリースしたいと発言した時刻」だけが入ったテーブルができあがります。

UTCになっていますが、これは後でJSTに補正します。

f:id:kokuyouwind:20200129184900p:plain

同じように「リリース前のテストが完了した時刻」と「ビジュアルリグレッションテストが完了した時刻」もそれぞれクエリを作ります。

💻 Query Resultデータソース

この3つが取れれば、あとは「リリースしたいと発言した時刻」に対して、それ以降で最も近い「リリース前のテストが完了した時刻」と「ビジュアルリグレッションテストが完了した時刻」を対応づければ「リリース準備にかかった時間」を計算することができます。

こちらはQuery Resultデータソースを利用すれば書くことができます。

SELECT
    datetime(release_start_time,"+9 hour") as jst,
    *,
    (strftime("%s", test_finish_time) - strftime("%s", release_start_time)) as test_duration,
    (strftime("%s", visual_finish_time) - strftime("%s", release_start_time)) as visual_duration,
    MAX(
        strftime("%s", test_finish_time) - strftime("%s", release_start_time),
        strftime("%s", visual_finish_time) - strftime("%s", release_start_time)
    ) AS prepare_duration
FROM (
    SELECT
        release_start.datetime as release_start_time,
        (
            SELECT test_finish.datetime
            FROM query_2 as test_finish
            WHERE test_finish.datetime > release_start.datetime
            ORDER BY test_finish.datetime ASC
            LIMIT 1
        ) as test_finish_time,
        (
            SELECT visual_finish.datetime
            FROM query_3 as visual_finish
            WHERE visual_finish.datetime > release_start.datetime
            ORDER BY visual_finish.datetime ASC
            LIMIT 1
        ) as visual_finish_time
    FROM query_1 as release_start
    WHERE test_finish_time IS NOT NULL
    AND visual_finish_time IS NOT NULL
) as t

ここで、query_xはそれぞれ以下のクエリです。

  • query_1: リリースしたいと発言した時刻
  • query_2: リリース前のテストが完了した時刻
  • query_3: ビジュアルリグレッションテストが完了した時刻

「ある時刻以降で直近のレコード」を取るためにサブクエリを使う必要があったり、JSTに補正したりといった部分で複雑になっていますが、基本的にはquery_1をベースに情報を混ぜているだけになっています。

これで「リリース準備にかかる時間」を可視化できるようになりました!

f:id:kokuyouwind:20200130113909p:plain

縦軸は隠していますが、たまにリリーストラブルが起こり準備完了までにものすごく時間がかかっていることがわかりますね。

よくないけどヨシ!

💬 感想

Redashは普通にRDSなどの情報を可視化するだけでも便利ですが、Pythonデータソースを使ってAPIを叩けるようにすると活用の幅がめちゃくちゃ広がって便利でした。

特にSlackを使ったChatOpsをしている場合は、とりあえずSlackに投げておいてAPIから集計・可視化ということができるのは大体何にでも応用できそうです。

📢 宣伝

Misocaでは計測生活したいエンジニアを募集しています!

Misoca iOSでiOS10のサポートを終了したら実装がすこし楽になったはなし

こんにちは Misoca 開発チームの うえの です。

最近いっきに冷え込んできましたね、みなさまいかがお過ごしでしょうか?
ぼくは毎年この時期になるとすぐに風邪をひいてしまうので、加湿+足元ホットマットでなんとか乗りきっています。

さて、Misoca iOSでは、先日のアップデートで iOS10のサポートを終了 させていただきました。

今回はサポートを終了するまでの流れと、それによって実装がすこしだけ楽になったはなしを書いていきたいと思います。

iOS10のサポートを終了するきっかけ(レイアウト崩れがつらい😢)

iOSのバージョン、どこまでサポートするのか悩ましいですよね。
ぼくは新しいiOSが発表されるたびに悩んでいる気がします。

できればすべてのバージョンで使えるようにしたいけど、実装やメンテナンスのコストを考えると、なかなか厳しいのが現状です。

Misoca iOS では、iOS10には悩まされることが多く、とくに "iOS10でのみ発生するレイアウトの崩れ" に手を焼いていました。最新のiOSを使って実装 → ビジュアルリグレッションテストを流す → iOS10でレイアウトが崩れている というのがよくあるパターンで、その度にワークアラウンドのコードを書いて対応していました。

でもだんだんとつらくなってきて、ちょうど去年の今頃(2019年1月)「iOS10がリリースされてから3年ほど経過してるし、そろそろサポートの終了を検討しても良いのでは?」と考えるようになりました。

iOS10をお使いの方はどのくらいいるだろう?

サポート終了を検討する上で一番気になったことでしたが、割合としてはかなり少なく、全体の1%未満でした(Misoca iOSでは Firebase を導入していたので、簡単に調べることができました)

さらに日を追うごとに少なくなっていったため、他チームにも相談したのち、iOS10のサポートを終了することに決まりました。

サポートを終了してもしばらくは使い続けられるようにしたい

サポート終了した後、すぐにアプリが使えなくなってしまっては困りますよね。
Misocaはビジネス寄りのアプリなので、特に気をつけたい大事なポイントでした。

このときのロードッマップでは、半年後に軽減税率への対応に向けた大きめのアップデートが予定されていて、同じタイミングで古いアプリには利用制限をかける方針にもなっていました。

いまiOS10のサポートを終了してしまうと半年後に使えなくなってしまう....

これはよくないなぁということで、軽減税率対応向けのアップデートを済ませてから、iOS10のサポートを終了させていただくことにしました。

iOS10のサポートを終了したら実装がすこしだけ楽になった

iOS10のサポートを終了したことで、iOS10時代には扱えなかった機能が使えるようになりました。

せっかくなのでその中から "アセットカタログで独自の色を定義する" というのをやってみました。

使い方はとっても簡単です。

  1. Xocdeメニュー → File → New → AssetsCatalog でxcassetsファイルを追加する
  2. 追加したxcassetsファイルを開いて +ボタン → New Color Set で色を定義していくだけです

こんな感じで色を定義できます。色が実際に見れて良い感じですね!
f:id:yueno12:20200121153302p:plain

定義した色はIB(インターフェースビルダー)から使うこともできます!
f:id:yueno12:20200121144232p:plain:w240

いままでは↓のようにコードで独自の色を定義していて、@IBOutlet や @Inspectableを使ってIBと繋いでいたんですが、アセットカタログに色を定義することですべて不要になりました!

extension UIColor {
    public static let main700 = UIColor(......
}

おわりに

今回は "iOS10のサポートを終了したら実装がすこし楽になったはなし" をご紹介しました。

サポートの終了ってネガティブな印象がありますが、一方では、開発効率が上がったり、新たな価値を生み出すきっかけになったり良いこともあります。
旧バージョンをお使いの方へは、できる限り不便のないよう配慮しつつ、適切に判断していきたいですね。

以上になります!ひきつづき Misoca iOSをよろしくお願いいたします!

MisocaではiOSエンジニアを募集しています!

リモートワークもあって働きやすいですよ〜、お気軽にご応募おまちしてます!

recruit.misoca.jp

🎍Misocaメンバーの新年の抱負 2020

あけましておめでとうございます!@mugi_unoです。

みなさん初売りで何か買いましたか。私はプロテインを買いました。


f:id:mugi1:20200120094645p:plain

さて、昨年2019年の年明け一発目のエントリーは「新年の抱負」でした

今年も開発メンバーに2020年の抱負を聞いてみました!

f:id:mugi1:20190925141630p:plain:w50 mizukmb

  • ハーフマラソンを2時間〜2時間半で完走したい
  • おいしいコーヒーを淹れる修行

f:id:mugi1:20190925142042j:plain:w50 RKTM

  • GoかKotlin使いになりたい
  • なんらか便利サービス作りたい
  • 統計分析頑張る

f:id:mugi1:20190925141503p:plain:w50 kawamata

  • GitHubに草をはやし続ける
  • 個人開発のWEBサービス or アプリを何か作る(自分以外の誰か1人以上に使ってもらえるものを)
  • ボクシング続けておやじファイトに出場する

f:id:mugi1:20200115095645j:plain:w50 kosappi

  • Elm でなんか作る
  • Vue と TypeScript でなんか作る

f:id:mugi1:20190925141653p:plain:w50 mallowlabs

  • AWS の知識をつける > AWS の使ったことがないサービスを業務で使う
  • 業務知識をつける > 簿記3級の勉強する(リベンジ)
  • 運動する > リングフィットアドベンチャーをクリアする

f:id:mugi1:20200115095547p:plain:w50 thara

  • 自作ファミコンエミュレータで子どもの頃にクリアできなかった「わんぱくダック夢冒険」をクリアする
  • カンファレンス登壇1回

f:id:mugi1:20200115095526j:plain:w50 eitoball

  • 去年、未達の50km走をやる。
  • 同じく、去年、未達のPhoenix Framework (Elixir) + Elm で何かWebサービスを作る。
  • ウルトラマラソン(100km)完走する。
    • 完走できたら、AWS Dev-ops Engineer Professional Certificate を頑張る。合格するとは言っていない。

f:id:kokuyouwind:20190930142248p:plain:w50 kokuyouwind

  • Elmでなにか作る
  • 国際カンファレンスで海外の人とも話せるよう、英会話を勉強する
  • リングフィットアドベンチャーで運動を習慣化する

f:id:mugi1:20200115114355j:plain:w50 mugi_uno

  • 昨年習慣化した運動を続ける
  • 英語の勉強を習慣化する
  • GraphQLを息をするように操れるようになる

まとめ

ウルトラマラソン...!!!(ゴクリ)

MisocaとMisoca開発者ブログを2020年もよろしくおねがいします!

📢宣伝

Misocaでは2020年もやっていくぞという開発メンバーを募集しています

www.wantedly.com

勉強会を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値に頼るべきでない理由 | エディテージ・インサイト