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

デザイナーのようがいです。この投稿は 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

「今年は洗練の年」と言っていた年初。その実態は？？

この記事は、ユニファAdvent Calender 2020の三日目の記事です！

こんにちは。 ユニファでエンジニアのマネージャーをしております田渕です。

めっきり冷え込んだなぁと思ったら、知らぬ間に今年の最後の月になっておりました。。。

この一年は本当に、みなさん色々なことがあったと思います。 いつもの年とは異なる状況だった今年、一年を通し、新型コロナウイルスに対しての取り組みなどを、マネージャー視点で書くことが多くありました。

それらの自分の記事を振り返りながら、その後の状況、通して感じた課題や学びについても触れたいと思います。

2020/1/10 「ユニファ開発チームの2020年-今年は洗練の年！」

tech.unifa-e.com

新年初のブログは、「今年はどんなことを目指していくのか」と言ったことをエンジニアマネージャー視点で書いたものでした。 記事中にも記載がある通り、2019年はチーム構成の多様化が一気に進んだ年であり、試行錯誤の連続でした。 2020年はそこから一歩進んで、多様性のある環境での安定的な開発、サービス運用を行いたい、という目標を書いたのがこの記事。

その後どうなったのか？

2019年は手探りで進めることの多かった仕事も、それぞれのメンバーの頑張りにより、春以降はかなり洗練されてきていました。 多国籍チームでの開発における一番の課題となるのは言葉の壁だと思いますが、海外メンバーが日本語を勉強し、日本人メンバーが英語を勉強し、 互いに少しずつ上達することで、結果的にコミュニケーションの質は2019年と比べると飛躍的に向上しました。 「絶対に英語とかムリ。」と言っていたメンバーが、始めてみればSlackでサラサラと英語を書くようになっていたりと、 嬉しい誤算が数多くありました。 これは本当に、頑張ってくれたメンバーに感謝しなければいけないところで、 ここまで色々な言葉が飛び交いコミュニケーションがとれる環境を短期間で成立させられるとは年初には考えていませんでした。 2019年の試行錯誤の結果がようやく実を結び、さて今年は更なる飛躍を！……と思ったところで、新型コロナウイルスが襲来します。

2020/5/15 「新型コロナウイルスと多国籍チーム」

tech.unifa-e.com

ようやく多国籍チーム環境にも慣れて来たかな？と思ったのも束の間、今度は顔を合わせて仕事をすることが難しい環境になってしまいました。 また、前例のない事態の中、どうやってメンバーのケアをしていくのか、ということについて試行錯誤した内容について書いていました。

その後どうなったのか？

この時に書いていた「リモートワーク主体の勤務」は現在でも続いています。 これまでもエンジニアはリモートワークが認められていましたが、緊急事態宣言以降は基本がリモートワークとなり、そして今後もそのままであろうと思います。 スタートアップの中には「オフィスそのものを解約する」会社さんもいらっしゃると聞きますし、今年はそう言った動きが一気に加速した年でした。 顔を合わせて仕事をすることに慣れていたため、始めこそ「やりづらい」「寂しい」という声が多く聞かれていましたが、 良くも悪くも自宅での仕事に慣れた今、「離れた環境で出来ることの限界」について、皆が冷静に見極めるようになったと感じています。

対面での作業の方が効率の良い場面はやはり存在し、そしてそれをリモートで再現しようとすること自体が無理であるケースもあることを分かってきた、という感じでしょうか。 無い物ねだりをしても仕方がない、今の環境で出来ることを精一杯やろう、という空気に変わったように思います。

実はこの記事の頃、メンバーの一部は諸々の事情があり、一時自国へ戻ることがありました。 出国や入国の規制がいつ出て、いつ解除されるのかも分からないという不安定な状況、更にチームの中で時差もある環境でも 成果を出すことができたのは、上述したようなある種の「割り切り」が出来ていたことが大きかったと思います。

2020/8/11 「緊急事態宣言下でのシステム運用振り返り」

tech.unifa-e.com

緊急事態宣言が出ていた時、システムはどんな風に動いていたのか、その課題についてをまとめた記事でした。

その後どうなったのか？

この記事中で記載されていた「リモート主体勤務時のトラブル対応体制の整備」に関してはその後実施し、今日ではその決定されたフローに従い、運用が行われています。 始めたばかりの頃は皆慣れないため、連携に時間がかかることもありましたが、何度か実施するうちにスムーズに遠隔での障害対策本部の設置などが行われるようになりました。

今では当たり前のように行っているのであまり気にしていなかったのですが、 この振り返りのために記事を書いていて「そうか、まだ8月はこの運用出来ていなかったんだな。」と始めて気づいた次第です。

一年を振り返って

保育園、幼稚園、こども園といった場所が、いかに現代の生活にとって欠かせない場所なのか、ということを強く痛感した年でした。 仕事を通じ、大変な中でも強い意思をもってお仕事をされている保育士の方々のお声を聞く機会も多くあり、これまで以上にユニファの目指す世界、提供していくサービスの必要性を感じました。

ベンチャー企業と言うのは多かれ少なかれ思ってもみない壁にぶつかるものですが、今年は世界的な課題も加わり、例年以上に目まぐるしい一年でした。

以前に私が本ブログでも記載しているように、現在の教育課程に於いては子供たちが「主体的に状況を改善できる」ことを目指しています。 それは、いつか来るであろう「予想も出来ない事態、これまで経験したことのない事態に対応し、生き抜くため」だったのですが、今年がまさにそのような状況であったと思います。

一年間、例年にない状況についての記録として、このブログにて数々の取り組みやその成果を記録してきましたが、それらの情報を使い、来年以降もまだしばらく続くであろう現在の状況をよりよくするべく、考えて行きます。

そんなユニファで、一緒に働いてくれる方を募集しております！ 少しでもご興味のある方は、ぜひお声がけください。

unifa-e.com

採用面談・面接はお互いにとっての選考の場

皆様こんにちは、ユニファ CTO の赤沼です。この記事は、UniFaアドベントカレンダー 2日目の記事となっております。

最近いろんなところでアピールさせていただいておりますが、ユニファでは現在開発職の様々なポジションを絶賛募集中です。
私自身の直近のミッションとしても採用を最優先としていまして、様々な採用施策の検討や、候補者の方へのアプローチ、カジュアル面談、面接など、手を動かすところも含めてがっつりと入り込んでいます。

unifa-e.com

そこで今回は、私がカジュアル面談や面接にて候補者の方とお会いさせていただく際に、どんなことを意識しているかを書かせていただきたいと思います。
ユニファへの応募を検討されている方はもちろん、この記事をきっかけに少しでも興味をお持ちいただけたら、ぜひカジュアル面談等でお話しさせていただければと思います。

基本的な選考フロー

現在開発職で募集しているポジションは幅が広いため、選考フローはポジションによって違ってくるのですが、基本的なフローとしては、下記のような形になっています。

書類選考 -> カジュアル面談 -> 一次面接 -> 二次面接 -> 内定

応募経路によってはカジュアル面談なしで最初から一次面接であったり、ポジションによっては上記に加えて技術課題をご提出いただくケースもあります。
また、個々のケースによっては面談機会を追加したり、柔軟にフローを調整しています。

面談・面接はお互いにとっての選考の場

採用の選考というと、企業側が候補者を一方的に選別するというイメージを持たれている方も多いかもしれません。
ですが私が選考フロー全体に対して思っていること、とりわけ面談・面接については特になのですが、選考フローは企業・候補者お互いにとっての選考の場であるということです。
私たちが候補者の方を、ユニファにマッチする方かを判断させていただくのと同時に、候補者の方が、ユニファがその方にとって入社するに値する企業かを判断いただく場でもあります。
特に私たちのような小さなスタートアップ企業は、知名度があるわけでも、条件が良いわけでもありませんので、そういった中でユニファを選んでいただくための努力が必要だと思っています。

カジュアル面談はほとんどのポジションで私がお話をさせていただいているのですが、まずカジュアル面談ではユニファのことを候補者の方に知っていただき、事業や開発チームに興味を持っていただくことを最優先と考えています。
なので私からユニファの事業やプロダクト等についてご紹介させていただき、候補者の方が気になっている点があればその点を中心にさらにお話をさせていただいています。

unifa-e.com

その上で時間に余裕があれば、候補者の方が現在どんなことをされていて、どんなことに興味があるのかなどを伺わせていただき、カジュアルにお話をさせていただいています。

一次面接と二次面接は、私がどちらに参加させていただくかはポジションによるのですが、カジュアル面談なしで一次面接に対応させていただく場合は、まずユニファのことをご紹介させていただく上で、カジュアル面談と同様の点も意識しています。
それ以外の点としては、候補者の方がユニファにマッチしそうな方かを判断させていただくのですが、 それぞれのポジションの技術面の詳細なところは私以外のメンバーによる判断に任せ、私としては下記のような点を主に見させていただいています。

• 気持ちの良いコミュニケーションが取れる方か
• 技術面でのご経験、基本的なスキルはマッチしていそうか
• 今後どんなことをやりたいと思われているか、その機会をユニファが提供できそうか
• そのポジションに期待している課題解決が可能か

もちろん考え方は人それぞれ、各社それぞれだと思いますが、私は技術職であってもコミュニケーション力は重視しています。
どんなに高い技術力を持っていても、円滑なコミュニケーションが取れなければチームとしての業務は遂行できませんし、本人のアウトプットだけでなく、他のメンバーの業務にも支障をきたしてしまいます。

tech.unifa-e.com

とはいえコミュニケーション力が高ければスキルがなくても良いということでは当然ないので、これまでに経験されてきた領域や、基本的なスキルセットがマッチしていそうかという点も会話の中で見させていただいています。

また、今後候補者の方がどのようなキャリアを志向されているかという点も重要です。
コミュニケーション面やスキルセットがマッチしていても、今後候補者の方がやりたいことに対して、ユニファがその機会を提供できなければ、お互いに不幸になってしまいますので、その点もお話の中で聞かせていただいています。

そして各ポジションを募集している背景として、それぞれに解決してほしい課題があります。
課題の内容は各ポジションで異なりますが、どれだけ良い方でもそこにマッチするかが重要になってきます。

今のユニファにはマッチしないことも

選考の過程において、私たちとしてはぜひ次のステップに進んでいただきたく思っていても、候補者の方が辞退されることもあります。
理由は様々ですが、私たちの取り組みに足りていない点があった結果でもありますので、真摯に受け止め、次回以降の取り組みに活かしていきたいと思っています。

また、私たちからお見送りの判断をさせていただくケースもやはりあるのですが、こちらも理由は様々です。
候補者の方の能力不足というよりは、現在のユニファが求めているポジションとマッチしなかったというケースも多く、将来的にお互いの方向性がマッチするフェーズが来ましたら、その時はまたぜひ機会をいただければと思っています。

まとめ

ということで、今回は面談・面接でどのようなことを意識しているかを書かせていただきました。
この内容はあくまで執筆時点のものですので、今後状況によって変化してくる可能性はもちろんありますが、何はともあれまずは色々とお話しさせていただいて、お互いの理解を深めていくことが重要ですので、ご興味お持ちいただけましたらひとまずご連絡ください！！

unifa-e.com