組織構造で余力を生み出す!「遊軍」チームを作ったらこぼれタスクをどんどん消化できるようになった

はじめに

こんにちは、 @rktm です。

Misocaではプロジェクトを開発プロセスの基本としています。

recruit.misoca.jp

ですがプロジェクトの枠からこぼれるタスクが増えてきました。 それらタスクをこなすべく、1年ほど前に「遊軍」というチームを作りました。

遊軍チームは当初はお試し運用でしたが価値を継続的に出せており、今は定着しています。 その遊軍チームについて、創設の背景、運用結果について書きます。

前回のブログ記事「フロントエンドチームはじめてました」と合わせて、Misocaでの、問題を個々人の努力だけではなく、組織構造の変化によって解決する事例としてお読みいただければ幸いです。 tech.misoca.jp

遊軍創設の背景:個々人の「余裕」「余力」に頼っていてはこなせないタスクが積み上がってきた

Misocaでは、2018年末ぐらいから大規模な機能追加・改修プロジェクトが複数走り、余裕のない状態が続いていました。

サービスを運営していると、日々お客様からの要望や、マーケティング担当からのリクエスト、不具合・障害の対応、分析作業、リファクタリングなど「 重要度も大きさも緊急度も様々」なタスクが発生します。

大規模プロジェクトに追われていた結果、気づけば以下のようなタスクが山積みになっていました。

  • 重要度: 非常に高いわけではないが、無視できるほどは低くない
  • 大きさ: プロジェクト化するほどは大きくないが、一人がプロジェクトの片手間でやるには手に余るボリューム

この記事ではこれらを「こぼれタスク」と呼んでおきます。

余裕のない時に起こること1: 「このタスク誰かお願いできますか?」「…(誰も手を挙げない)」

余裕がない状態では、プロジェクトメンバーはプロジェクトの目標やゴール達成に注力するため、プロジェクト外の作業にリソースを割くことに躊躇しがちです。突発的な問い合わせや障害の対応に取り組みづらくなりました。(この時の「誰かやってくれ〜 🙏 」という無言の空気は、なかなかつらいものがあります)

ということで、個々人の余裕に頼るとこぼれタスクの消化は安定しませんでした。

余裕のない時に起こること2:「余裕ができたらやる(やらない)」

「このプロジェクトが終わって余裕ができたらやる」というタスクは、プロジェクトの終了が延びがちであり、その結果次のプロジェクトがすぐに始まるため、結果的に後回しになりがちでした。

ということで、期間で余裕を作ろうとしてもなかなかうまく回らないものです。

解決策としての遊軍チーム: 組織構造として「余力」を作る

上記を踏まえ、Misocaでは個々人に頼ることなく定常的に「余力」を生むべく、遊軍チームを創設しました。

遊軍(ゆうぐん)とは - 遊軍の読み方 Weblio辞書

①  待機していて、時機を見計らって出動し、味方を助ける部隊。遊撃隊。
②  特定の所属や任務がなく、忙しい仕事やむずかしい仕事を状況に応じてする者。 「 -記者」

遊軍が対象とするスコープは以下の通りに定義しました。

  • 不具合対応等、突発的なタスク
  • お客様サポート部門・マーケティング部門などから上がってきた要望の対応
  • プロジェクト化するほど大きくないタスク
  • タスクのボリュームは、最大でも2週間ほどで終わるもの。

遊軍とプロジェクトの対比は以下の通りです。

f:id:RKTM:20200414174057p:plain
プロジェクトと遊軍の差

遊軍を運用してどうだったか

チームの規模としては、最低2人、新メンバーの受け入れやプロジェクトの狭間のメンバーの参加などで平均すると3人程度でした。

遊軍がやってきたこと

直近でブログに公開したタスクは以下の通りです。

その他にも、

  • お客様の要望:文書の件名の最大文字数を40文字から70文字にする(簡単なように見えて、いくつかのPDFテンプレートを変更するなど意外に大変でした)
  • 軽微な修正:日付系の入力フィールドにてautocompleteをオフにする
  • CIでしばしば失敗するテストを安定させる
  • 社内メモの文字数についての調査
  • デザイナーチームのビュー変更によりテストが失敗するようになったときも、ヘルプに入って迅速にマージまで持っていけた

などを行ってきました。

(ここに書ききれないような、小さな改善、リファクタリング、他プロジェクトのレビューによる支援など、多くの「こぼれタスク」をこなしています)

遊軍チームを作って、どうだったの?

遊軍内の評価

  • 溜まっていたお客様からの要望に対応できるようになり、よりお客様によりそえるようになった
  • CIの安定化に貢献することで開発チーム全体のスピードを落とさずに済んだ
  • 後回しになりがちな仕様書のアップデートにも時間を割けるようになった(斧を研ぐ時間を確保できている)
  • 新しくジョインしたメンバーの受け入れ先として機能している

外からの遊軍の評価

プロダクトマネージャーより

「プロジェクトにするほどでもない大きさの価値を、継続的に提供できるのがとても助かっています。

遊軍はある意味「余力」と捉えられがちで、最初の頃は廃止してプロジェクトにリソースを回した方がよいのでは?という声もありましたが、守ってよかったです」

デザイナーチームより

「長期間をかけて生み出すチームとは別軸で、短期間で価値を提供できるチームが発足し、実際に価値提供の頻度もあがっていると感じています。(リリースのお知らせ数が過去最高になりました)

いつでも相談できる窓口が仕組み化されたことで、細かなデザイン改善でやりたいことが発生した時も迷うこともなく相談でき、とても助かっています。」

マーティング担当より

「未来に向けた大きな取り組みを進めつつも、日々生じる改善や新規要望への対応も止めるわけにいかない。Misocaがその両輪を回すために無くてはならない、『縁の下のスピードスター』みたいなチームです。

こちらからの要望対応だけでなく、「え、そんな改善を進めてくれていたの?」というサプライズもちょくちょくあって、『縁の下のファンタジスタ』みたいなチームでもあります。」

お客様対応(カスタマーセンター)担当より

「これまで製品ロードマップに沿った計画的なリリースが中心とならざるを得ない状況でした。

そのため日々、お客さまからいただく改善要望などがなかなか反映できない(後回し)になる状況でした。遊軍チームが出来たおかげて、順次、機能改善を中心とした要望がリリースされています。

その結果、お客さまからも感謝のコメントをいただいたり、これまであった問合せがなくなったり(問題点が解消)する効果が出ています。カスタマーセンターとしても感謝していますし、何より、お客さまにとっても目に見えて実感できる改善が継続して提供できるような体制ができたことが嬉しいです!」

おわりに

遊軍チーム創設当初の目論見通り、

  • 組織構造として余力を作ることで、
  • 余力の中で「こぼれタスク」をスムーズに処理する

ということができていると評価しています。


Misocaでは、問題を解決するにあたり、個人の意識や頑張りだけでなく、仕組みや組織の変更で対応したいと思う人を募集しています。

www.wantedly.com

フロントエンドチームはじめてました

こんにちは @mugi_uno です。 某ウイルスで不安な日々が続きますが、ひとまずうがい・手洗いをちゃんとやっています。

フロントエンドチームができてました

f:id:mugi1:20200403115327j:plain:w600
最近買ったiPadProが嬉しくて書いてしまった謎のロゴ

Misocaでは半年ほど前にフロントエンドチームを新たに立ち上げました。 自分たちなりの形でひっそりと活動を続けてきて、幾つか成果も出てきています。

なぜチームを作ったのか / 何をやってるのか といった点をご紹介したいと思います。

徐々に表面化してきたフロントエンドの課題

Misocaでは個々人が「バックエンドエンジニア」「フロントエンドエンジニア」といった肩書を持っておらず、必要に応じてバックエンドもフロントエンドも触ります。

しかし、全体的にはフロントエンド側に比重を置くのは一部のメンバーに限られており、それに伴うさまざまな課題が表面化してきました。

個々人による改善活動が厳しくなってきた

フロントエンド全般に関わるような改善作業は、気になった人が隙間時間を見つけて対応していました。

それはそれで良いことですが、ボリュームの大きいタスクでは「途中で他の作業が忙しくなって続けられなくなる」「永遠に終わる気がしない」といった状態が危惧され、なかなか手をつけづらい状態が続いていました。

誰に頼めば良いのかわからない問題

フロントエンドに注力した作業は、プロダクト・デザインなどさまざまな方面から発生しますが、受け口が存在せずに「これは一体誰に相談すれば...??」となることがありました。

属人化とスキル・知識の偏り

適宜難しい技術要素については勉強会やペアプロ・モブプロを実施していましたが、気軽に相談する口も無いため、一部のメンバーに作業が偏ることも多く、スキル・知識の共有が上手くいかない部分が出てきていました。

→「チームが必要なのでは?」

問題について色々考えてみましたが、「個々人でバラバラに対応可能なフェーズを過ぎてしまったのだろう」と予想し、何らかのチームとして対応する体制を試してみても良さそうだな、という結論に至りました。

チームを作るにあたってやったこと

小さくはじめる

そもそも「チームを作って課題を解決できる」が既に予想でしかなく、空振りに終わる可能性も考えられます。 いきなり大体的にドカンとスタートするにはリスクがあるため、まずは活動時間短め&少人数で立ち上げることにしました。

具体的には次のような形です。

  • 興味のあるメンバーを数人募る
  • プロダクトチームに所属したまま、一部の時間をチームの活動に充てる

万が一「チーム意味なかったな」となっても、スパッとやめられるのが理想と考えました。

フロントエンドチームって一体何?を定義した

チームで集まって最初にやったのは、

  • 自分たちが一体何を目的として集まっているのか
  • 何をする(しない)べきか
  • 誰のために活動するのか

といった点を話し合い、「フロントエンドチームって何?」の認識を揃えました。 (この場はチームメンバーのみではなく、PdMやデザイナーにも参加してもらいました。)

「こんなフロントエンドチームはいやだ」

場の中で、チームのアンチパターンを話し合ってみました。 結果、次のようなものが出てきました。

  • ビジネスの成長に繋がらないことばかりをやってる
  • 全体の生産性向上に繋げられていない
  • 「それはバックエンドの仕事ですから」とか言い出す
  • 「面白そうだし流行ってるから良くわからないけど○○入れようぜ!!」とか言い出す

チームとして不穏な方向に走り出してしまわないよう、あらかじめガードレールを敷設しておくようなイメージです。

ミッションは何か

そしてチームが取り組むべき課題は何なのかを定義します。

最終的には、Misoca全体が望む方向に進むためにベストな支援をしていくのが理想の形だろう、という結論に至り

Web版Misocaにおいて、皆が思い描く理想のユーザ体験を実現するための技術領域での障壁を取り払う

をミッションに定めています。

f:id:mugi1:20200403112433p:plain
esaのREADMEでいつでも読める

チーム稼働から、今までにやったこと

実際にチームが走り出して実際に達成したこととして、わかりやすいタスクとしては

  • TypeScript型定義の強化
    • 皆がコードを書いた時に、無意識に負債を生まないためにコードを堅牢化
    • noImplictAny の無効化
  • Boostrap依存の撤廃
    • Bootstrap(驚異の2.x系)へのJS依存の完全撤廃
    • ユーザー体験統一プロジェクトの支援*1

などが挙げられ、直近ではAPIのGraphQL化などが計画されています。

また、日常的にフロントエンドチームのSlack上で技術相談を受けてペアプロ・モブプロを実施することで、開発チーム全体の支援を行ったり、今までは個人で対応していたような細かい依頼もチームとしてカバーしながら消化しています。

結局チームを作ってどうだったのか

現在もまだ試行錯誤を続けていますが、ひとまず順調に回るようになっており、概ね良い効果が出てきているかなと感じています。

  • 困ったときに気軽に相談できる受け口ができた
  • 長期的な改善計画を立てて、個々人が忙しくなってもカバーできる体制ができた
  • メンバー間でスキルや知見の共有ができるようになった

従来目立っていた明らかな課題は徐々に解消されつつあります。

とはいえチームだからこそ見えてきた課題もまだまだありますので、少しずつより良い形になるように見直していければな〜と思っています。

採用

Misocaではフロントエンドエンジニアを募集しています!

はじめまして、リモートワーク

2月からMisocaの松江オフィスに勤務している原田です。
入社して2ヶ月程立ちましたので、入社してからのことを書こうと思います。


自分は、前職ではオフィスワークをしていたのですがMisoca入社をきっかけにしてリモートワークを始めました。*1
今回は、恥ずかしい話ですがオフィスワークをやってきた人間がリモートワークを始めた時の失敗話を書いていきます。


Misocaのリモートワーク事情は下記の記事に詳細がまとめてあるので、こちらではさらっと書きます。

tech.misoca.jp

MisocaではZoomを利用して常時接続のミーティングをしており、コミュニケーションツールはSlackを利用しています。
常時接続のミーティングには、入社した際に支給されるZoom接続用のiPadを使っています。


仕事風景です。
仕事風景です。

失敗話: ミーティング遅刻

オフィスワーク時代だと、開発作業に集中している時でも他のメンバーが会議室に移動し始めることで気づいたり、早く気づいた際には事前に会議室の前で待機したりしていました。
ただ、リモートワークになると開発作業に集中しているとそういったことも無くなるので、時間が過ぎてSlackで呼び出されてからミーティングに向かうことがありました。


一緒の空間にいる時には、その人が単純に忘れていただけなのか重大な問題が発生していてミーティングに出られないのかデスクに向かえばすぐに聞けます。
リモートワークの場合は、応答が無い限り自分がどうしているか待っている相手は分からないので不安にさせてしまいます。*2


今は、カレンダーの通知時刻をミーティングの2分前にセットするようにして通知が来たら手を止めるように意識しています。

失敗話: 何をやっているか分からない

オフィスワークでは同じ空間にいるので、集中していてそっと話しかけた方が良いのか逆に何があったのか聞いた方が良いのかといった雰囲気は大体分かりますが、リモートワーク上だと詰まっているのか順調なのか状況が中々分かりづらいという所があります。


ありがたいことにMisocaでは分報の文化が整っていたことやタスク管理に利用しているTrelloのコメントがプロジェクトメンバーのいるSlackのチャンネルに流れるようになっていました。


この辺りを利用して、自分がこれからやろうとしていることを分報に投稿しつつ、タスクの分からない点や触ってて気づいた点をTrelloのカードにコメントするようにして、自分が何をやっていてどういう理解をしているのかというのをなるべく周りにアウトプットするようにしています。


分報
分報(一部)

まとめ

以上 2 点が、リモートワークを始めた自分の失敗話でした。


振り返ってみると当たり前の話だなと感じつつ、働く環境が変わることで今まで出来ていたことが出来なくなっていたのだなと思いました。
リモートワークでは物理的な距離が無いので、いかに周りのメンバーのことを意識できるかが大事なのかなと考えています。
周りの人のアウトプットを拾ってサポートしつつ、自分自身もアウトプットを出して周りの人がサポートしやすくする。そういった所をこれからも意識していこうと思います。


拙い話でしたが、新年度になってこれからリモートワークを始める方々の参考になれば幸いです。


Misocaではこれからリモートワークを始めてみようかなと考えているエンジニアを募集しています!

*1:気分転換を兼ねて週1程度松江オフィスに出勤しています

*2:ミーティングに限った話では無いですが…

さようならrrrspec、いままで速度をありがとう

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

今回の記事タイトルは銀河ヒッチハイクガイドからの引用です。*1

その水棲動物を見よ。

🤖 MisocaのCIとrrrspec

MisocaではCIが短時間で終わるよう、rrrspecを利用してRSpecを分散実行していました。関連記事もいくつか書いています。

tech.misoca.jp

tech.misoca.jp

自分の入社時に20分ほどかかっていたビルドが5分ほどで収まるようになり、またメンバーが増えても並列性を担保できたのはrrrspecの力による部分が大きいといえるでしょう。

…が、残念ながら昨年2月にrrrspecのActive Maintenanceが終了してしまいました

その後もMisoca社内でforkしたリポジトリを保守しながら運用していたのですが、次第に以下のような問題が顕在化してきました。

  • RubyやGemのバージョンアップにどこまで追従できるかわからない
  • 問題が発生したときに、関与するミドルウェアが多く調査に時間がかかる
  • rrrspecの仕組みに詳しいメンバーが少なく、保守や問題対応でそのメンバーに負荷が集中する

上記にはActive Maintenance終了と直接関係ないものもありますが、いずれにせよこのままrrrspecを使い続けるのは厳しいだろうと判断し、仕組みを載せ替えることになりました。

🧭 載せ替え先の検討

結構な力技でrspecを回していたため、載せ替え先でもある程度並列実行できるものにしないと現実的な時間で終わらないということはわかっていました。

このため以下のようにいくつかの案を作り、それぞれの速度や運用コストを見積もった上でどれにするかを判断しました。

  • 並列実行をサポートしているCircleCIに載せ替える
  • knapsackを使ってテストスイートを分割し、Jenkinsfileのparallelでノード分散実行する
  • parallel_testsを使い、スペックの高いJenkins Slaveノード1台の内部で並列実行する

それぞれを試験実装してみたところ、CircleCIは運用費用が現状から大きく跳ね上がってしまうこと、knapsackでの分散はparallel_testsに比べてノードの性能を引き出しづらいことがわかりました。

またCircleCIに載せ替える場合は現状のJenkins + parallel_testsから一本化する必要があり乖離が大きいこと、他のJenkins Jobが残っているためJenkins自体は止められずCI環境が複数になること、などの懸念もありました。

これらの調査結果を踏まえて、実行速度と運用コストのいずれも許容範囲内であったparallel_testsへ載せ替える方針としました。

🏎 parallel_testsへの載せ替え

rrrspecからparallel_testsに載せ替えるにあたり、もともと使っているJenkins Slaveではspec実行環境が整っていないという問題がありました。

頑張ってMySQLなどの依存ミドルウェアを立ち上げ、Rubyもバージョンアップに追従させて… というのはしんどそうだったため、Dockerを使ってspecを実行することにしました。

細かいところを端折ったJenkinsfileは以下のようなものです。

node('parallel_worker) {
  withEnv([
    "COMPOSE_FILE=docker-compose.test.yml"
  ]) {
    stage('checkout') {
      checkout(scm)
    }
    stage('build') {
      sh 'docker-compose build'
    }
    stage('test') {
      sh 'docker-compose run --rm app rake parallel:rake[db:reset,18] parallel:spec[18]'
    }
  }
}

Pipeline組み込みのDocker文法を使う方法もありましたがサイドカーコンテナの扱いがややこしそうだったため、単純にdocker-composeを使うだけにとどめています。

また18並列という数字は並列数を変えながら検証して得られた数字で、これ以上に並列数を上げてもほとんど実行時間が変化しませんでした。

spec実行にはc5.12xlargeインスタンスを利用しています。このレベルのインスタンスだと1台でも結構なコストなので、JenkinsのAmazon EC2 Pluginを利用して必要なときだけspotインスタンスが立ち上がるようにしました。

🏁 結果

さすがにDocker立ち上げやRails起動などのオーバーヘッドが大きく5分には収まりませんでしたが、6分ほどでrspecの実行が終わるようになりました。

f:id:kokuyouwind:20200317190135p:plain

🛠工夫が必要だったところ

作業中にいろいろと罠を踏んだり工夫したことがあるのですが、それぞれ細かく書くと長くなるのでざっくり箇条書きしておきます。

  • parallel_testsのparallel_runtime_rspec.logはJenkins Artifactに格納して、次以降のジョブでcopyArtifactを使って引っ張ってくるようにしました
  • Docker内で出力するファイルのオーナーがホストとずれてしまい消せなくなってしまったため、user namespaceを使って揃えるようにしました
  • EC2 Pluginremoting.jarに実行権限が付与されておらずslave立ち上げに失敗していたため、Slave command prefixchmod a+rx /tmp/remoting.jarを挟んでいます
  • 同じくEC2 Pluginで、Ubuntuを使う場合はRemote userubuntuの指定が必要でした。Usageに書いてありますが、ちょろっとしか書いてないので見落としやすいです

💬 感想

今回の置き換えでCIにかかる時間は少し長くなってしまいましたが、以下のように得られたメリットも多くありました。

  • rrrspecクラスタがなくなったことで管理する対象が格段に減った
  • Jenkinsローカルでテストを実行することで、失敗時スクリーンショットなどの収集を簡単に行えるようになった
  • Dockerベースにしたことで環境の切り替えが楽になり、レイヤーキャッシュが効くため複雑な自前キャッシュを減らせた

rspec実行に時間がかかるのも、テストが多すぎる・重すぎるという問題の比重のほうが多いため、ここからは仕組みの改善ではなく既存テストの棚卸しといったことが必要になってくるのではないかと思っています。

最後に、rrrspecには導入してからの3年半ほど、MisocaのCIを支えていただきました。コミッターの皆様、これまでありがとうございました。

📢 宣伝

Misocaでは「生命、宇宙、そして万物についての究極の疑問の答え」を探求するエンジニアを募集しています。

あとCIの仕組みを改善したいエンジニアも募集しています。

*1:前回タイトルはRe:ゼロ引用でしたが1ミリも伝わらなかったので、今回は自ら言っていくことにしました

Misocaのユーザー体験統一プロジェクトとは?

こんにちは。

デザイナーの@torimizunoです。

最近はリモートの日が増えたこともあり、リングフィットアドベンチャーで運動不足を解消する日々です。

今回は、現在進行形で進んでいる「ユーザー体験統一プロジェクト」について、1年間の歩みについてご紹介します。

まだまだ真っ最中ですが、1年という区切りでどのような取り組みや成果があったのか、お伝えしていきます。

立ち上げ

立ち上げについては、過去入社エントリーで触りだけ、取り上げました。

Misocaはサービスリリースから5年以上経ち、Web・iOS・Androidと3つの手段で提供されています。

長年サービスを運用していく中、プラットフォーム内、OSをまたいでユーザー体験の違いが発生してしまっていました。 f:id:torimizuno:20200310112706p:plain

社内でもデザインの生産性の低下につながったり、実装時に調査と意思決定に負荷が発生しており、「サービスでユーザー体験を一元化することで、社内の意思決定を加速させ、統一されたユーザー体験を提供する。」を目的に、プロジェクトが発足しました。

この時意識したこととしては、プロジェクト名を「デザインシステム」にせず、あえて「ユーザー体験統一」というラベリングにしたことです。

「デザインシステム」はあくまで成果物の手段であり、私たちが実現したいことは「統一されたユーザー体験を提供する」にあります。 関わるメンバーにも同じ意識を持ってもらいたかったので、常に共有時も「ユーザー体験統一」という伝え方をしました。

そのおかげか、このプロジェクトの話があがる時、「ユーザー体験統一」というコンテキストで会話がされたり、遊軍という改善チームでも活発的に統一の軸の改善が行われているように感じています。

どう計画したか

個人の経験談になりますが、過去にデザインシステムを検討〜適用を試みた時、適用まで進めることができなかった経験があります。

その時のふりかえりとして、「大きくやろうとしすぎた」という学びがあります。

今回はその時の学びを活かして、「最小工数でスコープを当て、少しずつ確実に検討・適用していく」方針で進めることにしました。

f:id:torimizuno:20200310121231p:plain

やり方としては、現在課題に感じている項目を洗い出し、それらをひとつずつ解決していくやり方です。

また、Misocaはユーザーが業務で使う道具にあたるサービスです。

道具の使い勝手が使っている途中に予期せぬものに変わってしまうと、ユーザーが業務上困ってしまいます。 その点にも注意を忘れないよう、「基本的には機能の変更はせず、あくまで体験を揃える」を方針としました。

どう進めたか

基本的にはどの項目も下記の手順でスケジュールを立て、実行しました。

  1. 調査
  2. 検討(作成→レビュー→調整を繰り返す)
  3. 定義
  4. 適用準備(レビュー環境に適用→レビュー→調整を繰り返す)
  5. 適用
  6. 共有

まず最初に着手した色を例に、具体例をご紹介します。

1.調査

現在プロダクトで使用されている色一覧を抽出し…

f:id:torimizuno:20200310114258p:plain

分類します(95色使われてたという衝撃の事実が発覚…😱)

f:id:torimizuno:20200310114325p:plain

2.検討

分類した色を、統一して置き換えられるか検討を重ねていきました。

f:id:torimizuno:20200310114410p:plain

3. 定義

そこから意味、命名、使用ルールの定義を固めていきます。

f:id:torimizuno:20200310114426p:plain

4. 適用準備〜5.適用

定義が固まったところでCSSコンポーネント化し、レビュー環境に適用します。

レビュー環境を確認しながら調整を繰り返した後、本番へと適用を進めていきました。

f:id:torimizuno:20200310174826p:plain

6.共有

開始時や合間合間で関係者を巻き込みつつ、適用後定義したデザインシステムが使える状態になったところで全体に共有をします。

f:id:torimizuno:20200310114645p:plain

進めてみて…

順調に進み、色・文字サイズ・アイコンの統一が落ち着いたので、今はボタンやリストなどの各コンポーネントに着手しています。 その後は文言の体験統一を予定しており、そこで一区切りをつけ、運用改善をしていきたいと考えています。

f:id:torimizuno:20200311094018p:plain

もちろんうまくいくことばかりでなく…大きな学びもありました! 学びについては、また別の機会にご紹介できればと思っています。

効果測定について

効果測定についても少し触れたいと思います。

Misoca内では、共通言語でコミュニケーションが円滑になった効果を感じています。

例えばボタンについて会話をする時、「primaryのbtn-sで」など、同じイメージを同じ言葉で伝えあうことができ、齟齬がなくなりました。

f:id:torimizuno:20200310143018p:plain

機能を考える時も、すべてをゼロから考える必要がなくなり、デザインシステムで定義されている箇所については意思決定の速度が早くなったと感じています。

今後は

デザインシステムは作って終わりのものでなく、社内での浸透や運用が重点と考えています。

浸透に関して何で計測できるか?を社内で相談したところ、「適用が進んできたタイミングで各プロジェクトでデザインシステムが利用されているか確認してみるのはどうか?」という助言をもらい、利用具合を調査してみることにしました。

2つのプロジェクトで調査したところ、どちらもデザインシステムの利用が見られ、定性にはなりますが、浸透を感じることができました。 もう少し進んだら、社内メンバーにヒアリングを実施して効果を測っていきます。

まだユーザーにとって体験統一でどのような変化があったかは未測定の領域なので、その点も今後検証していきたいです…!

終わりに

ユーザー体験統一プロジェクトの構築中に、何度か社外でデザインシステムを構築中のデザイナーの方とお話させていただく機会があり、同様の課題を抱えていたり、効果測定の話ができたり、とても刺激になりました。

引き続き気軽にお話できればと思っていますので、現在構築中の方も、これから始めようと考えている方も、お気軽にお話できると嬉しいです…!

twitter.com

Misocaではユーザー体験を一緒につくりあげてくれるデザイナーを募集しています。

recruit.misoca.jp

リモートワークでも改善のサイクルを回す。Misoca流の「ふりかえり」を紹介。

こんにちは。 最近、スラムダンクの新装版を買ってバスケ熱があがっている @RyoKawamata です。気になるキャラは森重 寛です。

さて、今回はMisoca流のふりかえり についてまとめてみました。

ふりかえりというと、一つの空間に皆で集まり、ポスト・イットにKPTを書いてホワイトボードに貼って、、、というイメージがあると思いますが、Misocaはフルリモートワークの会社です。
リモートでどのようにふりかえりを行うのか?まだあまり事例がないものだと思うので紹介します。

ふりかえりとは?

最初にふりかえりの定義を確認。
ふりかえりはスクラムの文脈だとスプリントレトロスペクティブです。スプリントレトロスペクティブは、下記のように定義されています。プロジェクト、チームを継続的に改善していくために、とても重要なものですね。

スプリントレトロスペクティブは、スクラムチームに考える機会を与えるものである。チームで何が起きているのかを調査したり、自分たちの仕事のやり方を分析したり、改善の方法を見つけたり、改善の計画を立てたりする。(中略)スクラムフレームワークで最も重要で、最も使用されているプラクティスである。

(引用元: エッセンシャル スクラム 第22章 スプリントレトロスペクティブ)

使用ツール

ふりかえりで使うツールを紹介します。 ここで通常だとポスト・イットや、ホワイトボードなどが出てくるところですが、MisocaではTrelloとZoomを使います。

Trello

Trelloはカンバン方式でチケットを管理できるタスク管理ツールです。 これをポスト・イット、ホワイトボードの代わりに使います。 ふりかえり用のボードを作成し、一枚のカードが一枚のポスト・イットに、各リストがKPTのKeep, Probrem、Tryなどの分類に該当しています。

f:id:ba068082:20200304172806p:plain:w300

Zoom

Zoomは高品質なビデオ会議ツールです。 それぞれリモートで参加するので音声通話、画面共有のためにZoomを使用します。 Zoomのミーティングルームに皆集合し、ファシリテーターがTrelloの画面を共有した上でふりかえりを行っています。

f:id:ba068082:20200304172628p:plain:w300

ふりかえりの手順

ここからはふりかえりの手順を説明します。

f:id:ba068082:20200303084008p:plain
ふりかえり用ボード(イメージ)

1. 前回のアクションを確認

まず前回のふりかえりで出たActionの進捗を確認します。 ここで完了してたらDoneのリストに移します。また、何らかの問題で進められていない場合は、都度調整を行います。

2. タイムラインを確認(3分程度)

プロジェクトのタイムラインを別途ドキュメントツール(esa)にまとめているので、そちらを見ながらこのスプリントで何をやってきたのか思い返します。

3. KPTを一斉に記入(5分程度)

5分程度時間を図りながら、それぞれKPTのカードを一斉に記入します。 自分が書いたものには自分をアサインします。気になったカードがあれば、適宜コメント、投票等のリアクションをしていきます。

4. 一枚づつカードを共有(10秒/枚程度)

記入が終わったら、全体でカードを共有します。ファシリテーターがカードを一枚づつ開きながら、書いた人が10秒程度でサクッと説明していきます。 このタイミングで、気になったものがあれば、次の深堀りにつながるラベルをつけていきます。

5. ラベルがついたものについて深堀りの議論

4のカード共有の時にラベルがついたものについて深堀りの議論をします。 話した内容はファシリテーターが適宜、コメント欄でメモします。

6. Actionを洗い出す・担当者を決める

改善につながるActionを洗い出します。5の深堀りの段階で出てくることが多いですね。 またActionにはその場で必ず誰か担当者を決めて、カードにアサインします。

7. 共有カードを選ぶ

最後に全体に共有するカードを選び出しラベルをつけます。 このカードは週次で行っているふりかえり結果共有の全体ミーティングの際に発表します。

手順は以上です。一つのプロジェクト(4〜6人)の場合、全ての手順を行ってもで30分程度で完了します。

ふりかえりのポイント

情報の共有と議論を分ける

手順の4, 5の部分の通り、Misocaのふりかえりでは情報の共有と議論を明確に分けています。
理由としては、一つの議論が白熱して進行を妨げることを防ぐ、ラベル付けという一つのアクションを挟むことで、考慮の時間が生まれより深い話し合いを行えるからなどです。

全体への共有カードを絞る

プロジェクト内でのふりかえりだけでは、プロジェクトで得た知見が全体に広がりません。ただ全体に全てを共有しようとすると、今度は全体でのミーティングが長引き、結果として生産性が落ちてしまいます。

その問題を解消するため、Misocaではふりかえりの最後に共有のカードを選び出すというステップを加えています。これを行うことで、大事なことは全体に共有しつつ、ミーティング時間を削減しています。

Actionには必ず誰かがサインアップする

ふりかえりでありがちなのが、毎回Actionは生まれるものの実行できず、ただタスクが積み上がっていくことだと思います。 その理由は、Actionが明確ではなかったり、そもそも時間がなかったりと色々あると思うのですが、大きな理由のひとつは「誰かがやるだろう」という傍観者効果によるものが多いと思います。

Misocaではそれを回避するため、毎回Actionが出た際には必ず誰かがその場でサインアップします。粒度によっては、複数人サインアップして協力して進めることもあります。 そして、毎回のふりかえりの前に前回のActionの進捗を確認することで、Actionが風化することを防いでいます。

終わりに

以上、Misoca流ふりかえりの紹介でした。
私自身Misocaに入社してもうすぐ1年という所ですが、実際にこのふりかえりによって、プロジェクトの運営からプロダクトの開発規約、組織の制度的なものまで改善されていく過程を見てきました。ふりかえりとても大事ですね。

他、開発チームの@mugi_unoがMisocaのミーティング・ふりかえりについてまとめたスライドもあります。よろしければこちらもどうぞ。

採用情報

Misocaでは自分でも組織でも、改善のサイクルを回していくのが好きなメンバーを募集しています!!

www.wantedly.com

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

こんにちは 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