さくっとGrafana on Heroku

みなさん、メリークリスマス！！

こんにちは、サーバーサイドエンジニアの柿本です。
この記事は、ユニファ Advent Calender 2020の10日目の記事になります。

今年のクリスマス、みなさんはサンタさんに何をお願いしましたか？

私は「自分専用のダッシュボードをください！」とお願いしたのですが、「フォッフォッフォ。それは自分でなんとかしたまえ！byサンタ」とのことだったので、自分で構築することにします。

とはいえ自分へのプレゼントにお金をかけたくないので、無料で入手できるものを探しました。

いくつかの無料や OSS のダッシュボードツールを比較してみて、Grafanaがクリスマスにはもってこいだったのでそれにします！

Merry Christmas Everyone! Thanks for an incredible 2019! pic.twitter.com/sbvjwXFrW8

— Grafana (@grafana) December 24, 2019

24時間動かし続けるわけではないので、 Heroku の Free Dyno を使えば間に合いそうです。

Grafana を Heroku にデプロイする bolierplate はいくつか GitHub にありますが、対象のバージョンが古かったり手順が多かったり sqlite を使っていたり*1したので自分で作ることにしました。

Grafana は docker image を提供しているので、それを使います。

tl;dr

1クリックで Heroku にデプロイすることができます。

コマンドをパチパチ打つのがお好きな方は README.md をご参照ください。

github.com

工夫したところ

ポートのバインドに失敗する（らしい）

Grafana の docker image を普通に Heroku にデプロイするとポートのバインドに失敗する、という事前情報があったので、 Stack OVerflow の回答をそのまま参考にさせていただきました。

やっていることは単純でカスタムの設定ファイル( grafana.ini )にプレイスホルダーをおいておいて、デプロイの直前に sed で置換処理を差し込みます。

// grafana.ini

[server]
http_port = <HTTP_PORT>

// heroku-run.sh

sed -i -e 's|<HTTP_PORT>|'$PORT'|' /etc/grafana/grafana.ini

stackoverflow.com

DB の接続情報を同様にセット

Heroku は Postgres の Add-on を追加すると同時に DATABASE_URL という環境変数をセットしてくれます。

ありがたいことに grafana.ini に database の url をそのままセットすることができるので、上と同じ方法で設定します。

// grafana.ini

[database]
url = <DATABASE_URL>

// heroku-run.sh

sed -i -e 's|<DATABASE_URL>|'$DATABASE_URL'|' /etc/grafana/grafana.ini

最後に

サンタさんにお願い事をしても断られることがあるんだな、と大人になって初めて知りましたが、こういう困難を乗り越えて人は成長するんだなと学びの多い年末になりそうです。

来年のクリスマスは何をお願いしようかなぁ。

それではみなさんハッピーホリデー！！

ユニファでは サンタさんに断られた 保育をハックするエンジニアを募集中です。 一緒にスマート保育園を実現しましょう！

unifa-e.com

*1:Heroku では sqlite は24時間ごとに削除されます！涙

Material Design Guideline 勉強会を始めました

こんにちは。Android エンジニアのあいばです。
寒さも本格的になってまいりましたが、いかがお過ごしでしょうか。
この記事は、UniFaアドベントカレンダー9日目の記事となっております。

今回は、先月の記事でも少し紹介されていたのですが、有志を募りマテリアルデザイン 勉強会を始めたのでその内容をお伝えしたいと思います。 tech.unifa-e.com

勉強会のねらい

• 社内のUI設計に関する知識を増やす
• 部署問わず知識レベルを揃えコミュニケーションを円滑にする
• 感覚ではなくルールに基づいてUIを評価できるようになる

メンバー

ディレクター、デザイナー、QA、エンジニアなど合わせて十数名が参加しています。

対象　

Material Design より以下のテーマを選択しました。

1. Environment
2. Layout
3. Navigation
4. Color
5. Typography
6. Motion
7. Communication

デザインするとき考えていること

デザイナーのようがいです。この投稿は UniFaアドベントカレンダー 8日目の記事になっております。

私個人としては、 昨年のアドベントカレンダー 以来のブログ投稿になりました。今年は例年以上にあっという間の1年でした。

この記事では、今年3月にリリースされたルクミーバス位置情報のデザインについて書こうと思います。

ルクミーバス位置情報は、幼稚園や保育園の通園バスが今どこを走っているか、園さまと保護者さまにリアルタイムでお知らせするサービスです。
ルクミーバス位置情報(Lookmee)｜ユニファ株式会社

私はPCのWeb管理画面と、スマートフォンのユーザーページのデザイン・コーディングを担当しました。
UIデザインについてのトピックはさまざまありますが*1、今回は主にレイアウトとビジュアルデザイン*2についてのお話です。

まず作る

ディレクターから上がってきたワイヤーフレームを元に制作したデザイン案がこちらです。

構成はこのようになっています。
・ヘッダー
・園名
・ルート選択ボタン
・経由点・バス停表示切り替えボタン
・バスの通過情報テキスト
・時刻表

指定された要件はすべて入っています。でもこれで終わりではありません。

自己レビューをしていきます。

*1:例えば、リサーチ/情報設計/ビジュアルデザイン/コーディング、デザインツール悲喜交々、エンジニアやチームメンバーとの共働、スケジュール管理などなど

*2:ここではUIデザインの要素としてのビジュアルデザイン、機能に乗る表層のデザインと捉えていただけると良いかと思います

転職して感じたUnifaのここが素晴らしい！

こんにちは。プロダクトマネージャーのおおたです。
この記事は、ユニファAdvent Calender 2020の7日目の記事になります。
気づけば既に12月！時が過ぎるのが早すぎて夏頃の記憶が既にありません。

そんな私ですが、今年5月、緊急事態宣言の真っ只中にUnifaにジョインしまして、入社の翌日から、社内の状況もあまり分からぬままフルリモート体制で勤務が始まりました。 平行して自身の息子の保育園も自粛要請になり、仕事中も私のPCを乗っ取ろうと席の周りをうろつく息子さま。 Slackの着信音が聞こえる度に「ママ！スットコトって鳴ってるよ！スットコト！」と謎の擬音語を一日に何度も言われ、白目になりながら自宅勤務を遂行して参りましたが、上司や同僚、周りの皆さまに助けられながら本日を迎えている私です。

そんな形でUnifaで働き始めたわけですが、Unifaで働き始めてとても素晴らしい！と思った事を今日はご紹介したいと思います。

Unifaのここが素晴らしい！その①　～企画の進め方～

---

現在私は、新サービスの企画立案に関わっておりまして、今は、顧客の定義～価値の検証、いわゆる仮説検証フェーズを遂行しております。

前職では、息つく暇もなくアクションを行急ぐようとにかく要件定義！みたいな形でコトを進める事が多かったのですが、
Unifaでは、しっかりと課題定義と価値検証に時間とコストをかけ、ユーザーの課題に向き合います。

• ターゲットはどんなユーザー？
• コストを払ってでも解決したい課題とは？
• そのコスト(対価)はお幾ら？

いわゆるターゲット定義と課題の抽出と一言で言っても、 コストを払ってでも解決したい課題とは何なのか？ この問いに対して、辿り着くまでが大変です。

課題を探っている時期って、このままもっと深堀した方がいいのか、一旦区切りをつけた方がいいのか。など、企画者としては色々迷う部分が出てくると思うのですが、相談MTGをしている最中に、案件のオーナーでもあるBossがこう言いました。
「僕たちはまだユーザーの課題を分かっていない。分かるまでしっかり向き合おう」 MTG中は他アジェンダもあったので何事もなかったかのように進めましたが、実はめっちゃ感動しましたよ！！ この言葉を心に忍ばせ、検証作業を進めていきます。

現在進めている案件の企画立ち上げ時は、大枠で捉えていたターゲットと課題ですが、定性調査を進めていくと、ターゲットの中でもいくつかのタイプに分かれてきそうだ。と判明してきました。

• 一概にターゲットと言っても、タイプに分けられそう。
• そのタイプごとに、課題となる範囲が違いそうだ。
• そのタイプごとに、課題となる範囲が異なるからこそ、対価として頂ける金額も変わってきそうだ。

上記のような形で解像度を上げていきます。

定性調査であぶり出された内容を元に、
次は量的な結果をもって判断する為に定量調査へ移行します。
定量調査での結果を元に、

このような形で情報を整理しながら、最大限に貢献できるであろうターゲットを絞り込み、

• 顧客の定義
• 課題の定義
• 価格のスコープ定義
• プロダクトのスコープ定義

それぞれ定義していきます。
そして次のステップでは、課題を解決した結果生まれる価値に関して、 我々が提供しようとしているソリューションで、ユーザーにその価値を感じてもらえるかを、 プロトタイプを用いて検証する価値検証のステップへと移行します。

価値検証の為の設計は現在進行中！でございますので、その内容はまた別の記事でご報告出来れば何よりです。

Unifaのここが素晴らしい！その②　～プロフェッショナルな集団～

---

そして、上記の仮説検証フェーズを遂行できるのは、 何はなくとも、プロダクトマーケティング部の存在があってこそ！なのです。
(プロダクトマーケのリーダーがAdvent Calenderの5日目に投稿していますね～☆)

Unifaには、プロダクトマーケティング部というチームが在りまして、定性・定量共にスペシャリストが在籍しており、様々な疑問を一緒に解決していってくれます！
弊社はスタートアップですし大企業に比べたら少ない在籍人数の中で、これほど専門性を持ったメンバーが在籍しているのもUnifaならではなのでは？と思っております。
このようなプロフェッショナルな人達と一緒に働ける喜びを噛みしめながら、日々業務を遂行している私でございます。
(ちなみにプロダクトマネージャー部の私の上司はHCDの専門家でもあり！Advent Calenderの12/22に投稿予定です。ワクワク)

最後に

---

現在、企画職だけど、ユーザーに向き合う時間が持てないんだよなぁ。とか、ルーティーンの作業ばっかりやってるんだけど…と もんもんとしているそこのあなた！
是非Unifaにジョインして、ユーザーの課題と向き合ったプロダクトを世に出し、共に世の中の課題を解決していきましょ～！

unifa-e.com

プロジェクトを進める上で大切にしていること

こんにちは。プロダクトマネージャーの木曽です。
この記事は、UniFaアドベントカレンダー6日目の記事となります。

2019年のアドベントカレンダー記事を書いた頃は、入社後約１ヶ月といったところでまだまだ緊張感もあったのですが、今となっては相手が苦笑いしてしまうようなダジャレをぶちかますほど、のびのびと仕事をさせていただいております。

さて何を書こうかなあと思っていたのですが、周りの方から「チームの雰囲気がいいよね！」というお言葉をいただいたことがあったので、私がプロジェクトを進める上で大切にしていることについて書いてみようと思います。

大切にしていることを考えたきっかけ

改めて『大切にしていること』について考えたきっかけは、プロダクトマネジメント部で『ドラッカー風エクササイズ的なもの』をやったことでした。

ドラッカー風エクササイズ的なものでやったこと
下記の項目に対して自分で思ったこと、チームメンバーが思ったことをあげていくというものです。

• 自分の得意なこと、強みは何か？
• 自分はどうやってプロジェクトや開発組織に貢献するつもりか？
• 自分が大切に思っている価値は何か？
• プロジェクトや開発組織は、自分に何を期待していると思っているか？

この中でも『自分が大切に思っている価値は何か？』についての各々の回答を見て、大切に思っている価値はその人の行動に表れているなあと思いました。

大切にしていること

私が『大切に思っている価値』としてあげたものはこの４つです。

• 信頼関係、それぞれの役割を尊重すること
• プロジェクトメンバーのモチベーション
• 自社サービスを一緒に作っている感じ
• 納得感

『信頼関係』『モチベーション』については言わずもがなです。

『自社サービスを一緒に作っている感じ』『納得感』
この２つについては、私がユニファに入社して最初に関わったプロジェクトでの失敗から来ています。
その時はスケジュールに追われ、エンジニアからの提案を快く受け入れられず、納得いく回答もできなかったことがありました。

私がかつて他社でwebフロントエンジニアをしていた時、新しいものを作ったり新しい技術を試したりする時はワクワクしましたし、「こうした方がいいんじゃない？」という提案をないがしろにされた時はモチベーションが下がりました。
職種が変わって、過去に自分が感じた気持ちもすっかり忘れてしまっていましたが、これはすごく大事なことなんだと改めて思いました。

とはいえまずはここから

信頼関係は築けていた方がいいし、モチベーションは高い方がいいに決まっていますが、そんなにすぐに変えられるものではありません。
まずはコミュニケーションをしっかりとるように心がけています。
現在はリモートワークでなかなか直接会える機会はありませんが、Daily Scrumで雑談をしたり、MTGやslackでダジャレを言い合ったりしているうちに、少しずつコミュニケーションが円滑になってきたと感じています。

まとめ

せっかく働くのだから、楽しいと思って仕事ができることが一番です。
これからもみんなで楽しくより良いサービスを作っていけたらと思っています。
明日は月曜日、一週間が始まんでーと言うことで、明日からまた一週間頑張りましょう！

ToB領域におけるマーケティングリサーチのお話

こんにちわ。ユニファのプロダクトマーケティングマネジャーの小林です！ この記事は、UniFaアドベントカレンダー 5日目の記事となっております。

今回はじめてブログを書くので、簡単に、プロダクトマーケティングの仕事内容を紹介します！ プロダクトマーケティングでは、主にこんなお仕事をしてます。

• マーケティングリサーチ（定性、定量）
• プロダクトの価値をBiz、Dev側へ発信する
• カスタマージャニー作成
• ペルソナ設計
• 事業試算

仮説検証～リリース可否のPL試算まで手広く対応してます。

さて、本題

---

先日、プレスリリースでも発表させていただきましたが、ルクミーシフト管理がBabytech Award 2020で、優秀賞をいただくことができました！

このような賞を頂けたのも、日ごろからご協力いただいている関係者の皆様のおかげです。本当に感謝しております。 一方、残念だったのが、ルクミーバス位置情報です。最終選考まで進みながら、受賞を逃してしまいました。ルクミーバス位置情報もよいサービスなので、よろしくお願いします！

unifa-e.com

lookmee.jp

今回は、ルクミーシフト管理、ルクミーバス位置情報ともに私が担当していたのですが、受賞に至るまでに、どのようなリサーチや情報収集をして、サービス提供に至ったのか？をご紹介しつつ、ToB領域におけるマーケティングリサーチの方法を簡単にお伝えできればと思います。

企画初期～中期（2019年5月～7月）

---

2019年5月頃から新規サービスの企画を開始しました。 当時、保育者ケアという保育者向けのアンケートを取るサービスの企画担当も兼務しており、それをきっかけに以下のようなことを考えるようになりました。

• 　事象：アンケートを取得しても、アンケート結果をフィードバックする時間が取れないというのが課題だった。
• 　要因：その理由として、管理職の先生に事務作業が集中していることが、要因のひとつであった。
• 　解決策：管理職の先生の事務作業の中でも、作業ボリュームの大きいものを劇的に減らしてあげることはできないか？

まず、この解決策の方向性があっているか？を検証するために、いくつかの調査をしました。

• 　既存顧客（既存保育施設）に対して定量調査（2-3問程度）
• 　対象となった事務作業が本当にユーザーペインがあるかをインタビュー（2-3園程度）
• 　候補になった事務作業の着手から完了までのプロセスを可視化（カスタマージャニーの作成）

＜このステージで意識したこと＞

• 　この時期の企画要件は狭めないようにする
• 　対象範囲を少しずつ狭めていく
• 　対象候補の中にいれたものの作業レベルのブレイクダウン（完了までにどのようなタスクがあるのか？）
• 　作業レベルまでブレイクダウンしたものの中で、ペインの強度をトリアージ

こんなところがポイントだったと思います。簡易的な調査でおおよその当てだけはつけておき、その候補を深ぼってみては、やめるみたいなアクションを繰り返しました。結果、シフトのサービス企画をする際、周辺領域の知識も増えており、周辺作業も意識して企画を進めることができました。

企画末期（2019年7月～9月）

---

この時期には『シフト管理のサービスで企画を進めよう』と方向は決めており、その中の作業レベルまで明らかにしてました。 シフト作成の完成までの具体的な作業は以下でした。

• 配置基準を満たせているかを確認する。
• シフトに偏りがないかを確認する。
• 先生から出勤希望をシフト表に反映する。
• シフトの素案を作成する。
• 確定したシフト情報は、勤怠管理に反映される。

これまでに実施したインタビューで、シフト作成までに、複雑な条件があり、この複雑な条件を調整することが、なかなかシフトの素案が決まらない要因でした。この領域で、劇的に作業時間を減らすには、複雑な条件を考慮した作成支援（自動作成）が必要だというアイディアがでました。

とはいえ、開発を進める上では、できるだけミニマムに進めたいため、以下のような調査をここで実施しました。

• 　コンセプトのABテスト（シフトの自動作成があるものとそうでないもの）
• 　PSM（このコンセプトにいくら払ってくれるのか？）
• 　定性的なコンセプト評価（暫定的なコンセプトをみたときのユーザーの反応はどうだろうか？）
• 　XDを使った機能評価の確認（私たちがユーザーができていてほしいと思っているであろうことはあっているか？）

コンセプトのABテストでは、A：複数の条件をいれると素案が自動作成される、B：素案の自動作成はないが、他の作業が簡略化できるという2つのコンセプトを用意しました。結果、コンセプトAがBに対して、統計的有意に上回る結果でした。

＜このステージで意識したこと＞

• 　定量的、定性的、両側面から『このプロダクトは求められているのか？』を確認する。
• 　機能やコンセプトの華やかさではなく、実際、現場に落とし込まれたときに本当に使えるものなのかをXDを使いながら確認する。

このあたりがポイントだったと思います。 自動作成という華やかなコンセプトを掲げていたものの、実際、自動作成に求めるものってどの範囲のものかというのは受け手によって大きく齟齬が生まれる箇所です。そのため、定性のインタビューを再度設け、実際の画面イメージを見せながら、どのくらいの作業まで機械がサポートしてくれるとうれしいのかなどの詳細を確認していきました。

ToB向けの調査の大変さ

---

ToB向けの調査の大変さはなんといっても対象者が集まらないという点です。 参考になるかわからないのですが、私たちがどのようにリクルートを実施しているかもお伝えします。

定性調査

• 　① 社内で過去保育士や幼稚園教諭として勤務されたいた方に聞く
• 　② 社内の知り合いから現役の保育士、幼稚園教諭を紹介してもらう
• 　③ お客様の園に訪問する
• 　④ お客様の園から紹介して頂く
• 　⑤ 外部のパートナーにご協力をいただく

定性調査だとこんなところが現状の選択肢です。 基本は、①～④の中でなんとかご協力頂けているというのが現状です。 ただ、調査頻度が増えるほど、直近で聞きにいけるご協力者様が減っていってしまうという点やコロナ等でお伺いが難しいことなどを考慮し、定性調査では以下のような試行錯誤をしてます。

① コロナの対策ガイドライン策定

訪問する園様や対象者様にご迷惑をかけないように、ガイドラインを定めました。ガイドラインでは、園に訪問する際や弊社にご来社いただく方への配慮事項を設けてます。

② オンライン面談

調査もオンライン面談でなるべく進めるようにいたしました。コンセプト調査や簡易なユーザーテスト、デプスインタビューであれば、オンラインでの実施も行えるようになりました。

とはいえ、園の現場を見なければわからない類の調査もまだまだ多くあるため、そのあたりの調査を今後どのように進めていくかは課題として残ってます。

定量調査

• 　① 既存のお客様にご協力いただく。
• 　② 外部のパートナーにご協力いただく。

定量でいうと、選択肢が限られてます。 量的に検証したいときは、課題が残りますが、②の外部のパートナーが保有しているパネルには保育士や幼稚園教諭などの属性がわかるパネルもあるので、そこに配信いただくことで、調査に足る回収数を集めたりしてます。

最後に

---

私は、事業会社やマーケティングリサーチの会社を経て、ユニファにジョインしました。

ジョインした当初は『スタートアップは既存データをゴリゴリ分析して、特に外部の調査パネルなどは使わないだろう』と思ってました。実際には、ToBの領域の中で、新しいプロダクトを提供していく際には、基本的な調査手法を駆使しながら、事実を見つけていくという方法は、従来のマーケティングリサーチとなんら変わりませんでした。

今、チーム内では様々な分析を試したり、分析の高速化を試みてます。また、進捗があり次第、発信していければと思います。

今年も残りわずかですが、お体に気を付けて、走りに抜けましょう！

リモートワークでの失敗から学ぶ、プロダクト開発3つのポイント

こんにちは。プロダクトマネージャーの井口（いのくち）です。この記事は、UniFaアドベントカレンダー 4日目の記事になります。

今年もいよいよ残りわずかですね。今年といえば、新型コロナウイルスの影響でリモートワーク主体の勤務になった方も多いのではないでしょうか？

私も今年の3月からリモートワーク主体の勤務を始めています。弊社に入社したのが2月だったので、弊社のメンバーと少し親しくなったくらいの段階でリモートワークを開始しました。その影響もあってか、プロダクト開発の進め方に関する失敗をいくつかやらかしました。

このブログでは、私の失敗の中から3つの失敗を取り出し、そこからの学びをご紹介します。リモートワーク下でのプロダクト開発の参考になれば幸いです。

tl;dr

このブログでは、3つの学びを紹介しています。

1. 関係者との前提のすり合わせが今まで以上に大事

2. 開発チケットは自分たちが管理できるくらいまで細分化すべし

3. デイリースクラムでプチスプリントレビューを行うと問題発見に効果的

詳細が気になる方は下記もどうぞ。

失敗1：コミュニケーション編

発生した事象

リモートワークを開始してからしばらく経ったのち、このような事象がいくつか発生していました。

• 共有したと思っていたスケジュールが上手く伝わっていなかった
• 同じ事柄について話しているのに、話が上手く噛み合わない
• 仕事の完了条件についての認識がズレている

原因

これらの原因を深堀すると、ある1つの原因に辿り着きました。

それは「お互いの前提の共有が不十分である」というものでした。

私はこれまで、関係者のほとんどが出社して勤務する環境で働いてきました。そのため、お互いの仕事のスケジュールや置かれている状況、さらにはお互いの仕事観（例:正確性を求めるのか、スピードを求めるのか）、といったお互いの前提を自然と知りあえる状態でした。

一方で、リモートワークがスタートしたタイミングでは、あまりお互いを知らない状態でした。加えて、リモートワーク下で今までのコミュニケーションスタイルを取ってしまったことで、前提共有が不十分なコミュニケーションとなってしまい問題が発生していました。

学び

この失敗から、

リモートワーク下で協働するには、前提のすり合わせが特に大事

ということを学びました。

手法としては、プロジェクトの前提のすり合わせでは「インセプションデッキ」を作られることが多いと思います。

これに加えて「ドラッカー風エクササイズ」「ワーキングアグリーメント」や性格診断テスト（例:エニアグラム）など、個人の仕事観を共有する施策の実施も重要と感じました。

失敗2：プロジェクトの進め方編

発生した事象

続いては、開発とQAを並行で進める時に発生した事象の紹介です。リモートワークが直接の原因ではありませんが、問題に拍車をかけた要因の1つだったと感じています。

スケジュールがタイトだったこともあり、開発とQAを並行稼働させるチャレンジを行いました（下記の図のような想定です）

開発とQAの並行稼働イメージ

デイリースクラムでお互いの進捗を共有しており、上手く行くんじゃないかと思っていたのですが、実際は開発・QA間の手戻りが多く発生してしまいました。

原因

手戻りが発生した原因を深堀すると、

1つの開発チケットに大きくの内容を盛り込みすぎてしまい、チケット内に完了と未完了の部分が混在する状況になっていました。

そのため、チケットがいつまで経っても終わらず、チケット管理は上手くいかないし、チケット完了できないためベロシティの計測も上手くいかないという状況になりました。

学び

この失敗からは、

開発チケットは自分たちが管理できるくらいまで細分化すべし

ということを学びました。

ちなみにこの学びは抽象化でき、

相互に依存する物を並行稼働するときは、送り手(この事例では開発)と受け手(QA)で受け入れ条件を合わせるが大事

として汎用的に使える学びだと思います。

失敗3：問題発見編

発生した事象

最後にお伝えする事象は、デイリースクラム(朝会)のやり方に関する事象です。

私たちはスクラムで開発を行っており、毎日デイリースクラムを行っています。デイリースクラムでは、今自分が抱えている課題を他のメンバーと共有するプロセスが入っていますが、私たちのスクラムでは上手く機能していない状況がありました。

具体的には、毎日の報告では問題ないと共有されていたが、実は問題が解決されずに残っていました。それに周りも気づくことができず、問題の発覚が遅れ、対処や支援も遅れてしまいました。

原因

この事象を深堀すると以下の3つの可能性が見えてきました。

1. 問題を話せるレベルまで、心理的安全性を高められていなかった

2. (周囲は問題だと感じるが)本人が問題と気づかなかった

3. 本人が報告を忘れてしまった

主観的ではありますが、話に上がってくる問題もあったので、1の心理的安全性はそれなりに高かったのではと思います。そのため、2と3の原因の方が強いと考え、この問題を軽減する方法を検討しました。

学び

検討するにあたり、下記図の「周囲が気づいて支援できる箇所(盲点の窓)」をいかに明らかにするかが重要と考えました。

盲点の窓

そこで私たちはデイリースクラムに「プチスプリントレビュー」というものを取り入れました。

やり方は凄く単純で、デイリースクラム内で、その日に各自が開発した内容を画面共有しながら話してもらうだけです。問題発見に気づくことを目的とし、スプリントレビューのようにデザインや仕様の議論は行いません。

プチスプリントレビューを実践したところ、口頭での問題共有では出てこなかった問題に気づくことができたり、忘れていた問題共有も行うことができるようになりました。

副次的には、毎日新しく開発された内容を確認できるので、チームとしてもゴールに近づいている感じを得ることができるようになりました。

まとめ

リモートワーク下での失敗から、以下の3つのことを学びました。

1. 関係者との前提のすり合わせが今まで以上に大事

2. 開発チケットは自分たちが管理できるくらいまで細分化すべし

3. デイリースクラムでプチスプリントレビューを行うと問題発見に効果的

1つでも皆さんのプロダクト開発の役に立てば幸いです。

最後に

もっと詳細を聞いてみたい、ユニファの開発ってどうなの？という疑問/質問がある方はぜひカジュアルにお話できると嬉しいです。

unifa-e.com

それではみなさま、良いアドベントカレンダーシーズンをお過ごしください！

adventar.org