コネヒト開発者ブログ

コネヒト開発者ブログ

チームの議論を活性化する。ボックスミーティングのススメ。

🎅この記事はコネヒトアドベントカレンダー2022 11日目の記事です🎅

昨日は aboy さんによる Win Session についての記事でした！ tech.connehito.com

こんにちは！@TOC です。 今回はチームで行っている議論の場を設ける工夫について書きたいと思います。

tl;dr

  • チームの人数や役割が増えてきて、日程調整難易度が上がっていた
  • 固定で自由に話せる枠を設けるようにしてみた
  • チーム内の議論が最近活性化してる気がするよ！

目次

もっとチームで議論したい！でも日程調整難しい！

背景

僕が所属するチームはママリアプリのユーザー体験向上を目指しています。

チーム構成としては PdM、PMM、エンジニア、デザイナーなど様々な職種で構成されており、各職種目線でユーザー体験向上のために日々議論することが多いです。

議論しているお題は、「なぜこの機能を作るのか、ユーザーのためになっているのか、について話したい」、「日々のスクラムイベントの改善案を壁打ちしたい」など様々。

都度時間を取ってもいいですが、以下のような課題感がチーム内で上がりました。

  • チーム横断で関わっている人もいるためミーティングの調整難易度が高い
  • 突発的なミーティングが作成されることもあるので、スプリントのリズムが予想しづらい

レトロスペクティブでも話題に挙がるように、チーム内での関心が高い議題でした。

レトロスペクティブで挙がった声

関心度が高く、何回も議題になっていた件だったので、チーム内で解決できる工夫を考えました。

都度予定を抑えるのが難しいならイベント化しよう！

チームメンバーのカレンダーを見ると直近1週間は予定が埋まっているけど、3週間後とかはまだ予定が入っていない状態でした。

また、スクラムイベントのような固定化したイベントは開催できていることを考えると、ディスカッションもスクラムイベントの一つのように考えて、固定化すればいいのでは、という話になりました。

そこで誕生したのが、チームのボックスミーティングです！

（ボックスミーティングのコンセプトは既に開発組織で行われていたミーティングを参考につけました。ボックスという枠を用意しておいて、好きに使ってね🙌という意味を込めております）

どう運用しているのか

ミーティングの議事録に下記のようなテンプレートを用意しております。 何か話したいことがある人は、空いているボックスに必要な時間と内容を書いておきます。

ボックスミーティングのテンプレート

弊社では Notion と Slack を利用してますが、記入をすると通知が飛ぶようにしておけば、次回何を話すのかをメンバーが知ることができるので、心の準備ができる工夫もしてたりします。

連携メッセージ

話題がないときはチームでもくもく会をしようって話してますが、大体ボックスが埋まるので、まだもくもく会にはなっていません笑

今までに話した議題を一部紹介します。

ボックスミーティングでの議題1
ボックスミーティングでの議題2

このようにワークの導入説明や、ブレインストーミング、今期やることの共有など、利用の仕方は様々ですが、毎回議論が白熱しています 🔥

導入してみどうよ？

導入してみると、何か話したいことができた時に「それボックスミーティングで話しましょうか」という会話が増えて、話し合いの場として最初に想起される場になりつつあります。

また、イベントとして固定化されているため

  • 都度日程調整をする必要がない
  • スプリントのリズムが掴みやすく突発的なミーティングが減った

といった嬉しい効果がありました。

メンバーからも「ボックスミーティングは機能している」という声も上がっているため、引き続きこのイベントは続けていこうと思っています。

まとめ

今回はチームでの議論の場を設けるためのアイデアとして、イベントとして固定化する方法を紹介しました。

もし、チーム内での議論を活性化させたい、日程調整に悩んでいる方がいたらアイデアとして参考になれば幸いです。

とはいえ、余計なミーティングを減らしたり、ミーティング時間を有意義なものにする、といった別の課題は今後も向き合っていかなければいけないことだとは思うので、時間を取ることの意味をちゃんと考えていかなければいけないな、と思います。

改善していく！💪

チームでWin Sessionを始めて1年が経ちました

こんにちは、コネヒトでエンジニアをやっているあぼ(aboy)です ԅ( ˘ω˘ԅ)

コネヒトアドベントカレンダー2022の10日目になります。

私の所属するテクノロジー推進部というチームは1年前にWin Session (ウィンセッション)を始めました。その時に書いた記事がこちらです。導入背景など知りたい方はご覧ください。

tech.connehito.com

チームとしてWin Sessionを継続して1年が経ったので、何か記事を書こうと思いこれまでを振り返っていました。

チームにもたらした変化という切り口で振り返ると、Win Sessionはチームにとってお互いの行動を讃えあう場としてすっかり馴染んでいます。途中で向き直りをしたり、時間帯の調整や司会を置かなくても進められる仕組みなど、やり方はつど改良していますが、大体の型はできて落ち着いたかなと思います。そういう意味では前述した記事と大枠は変わっていません。

チームのWin Sessionで印象的だったのは、この1年間でチーム構成が若干変化しつつ過ごす中で、チーム力が上がっていると感じるようなこちらのWinです。

チームメンバーの1人がその週いなかったり

カンファレンスに参加した週のWin

チームに手応えを感じたWin

ただ、これだけでなく、自分たちのチームの外に目を向けると面白い変化がありました。

自チーム以外にもたらした変化

まず、チーム外の人がたまにWin Sessionを見に来てくれるようになりました。

チーム外の人がWin Sessionに顔を出してくれるようになったきっかけは、チームメンバーの一人が、Win Sessionが始まる際に全社員のいるSlackチャンネルで告知し続けたことです。

全社員がいるSlackチャンネルでWin Sessionを周知している様子

これによって、なんか面白そうなことやってるぞという認知が得られていき、ふらっと参加してくれる人が現れました。

そして、この継続によってさらに次のような変化が起こっていきました!!

  • 他チームがWin Sessionをトライする
  • 開発組織で技術Win Sessionが始まる
  • 全社イベントでWin Sessionみたいな催しが行われる

Win Sessionに顔を出してくれた人が、自分たちのチームで試そうとしている様子

このように徐々に取り組みの輪が広がっていくのはとてもコネヒトっぽいと感じています。誰かが何かトライしたいと言った時に、その行動をまずは肯定して、周りがフォローしていくことで、たくさんのトライが生まれます。

チーム視点だと、自分たちが楽しんで継続することと、その様子を周知し続けたことも、周りに変化を与えられた大きな要因だったと思っています。

他のWin Sessionを覗いてみると、自分たちのWin Sessionと出ているWinの傾向が違ったりして楽しかったです。

ユーザーインタビューに湧いていたり

チームを超えて集まったフォローに対するWin

さいごに

チームがチームのためにやっていたWin Sessionは、チーム外にも影響を与えられた部分がありました。Win Session自体はOKRの文脈ですでに世の中に存在するものですが、継続的にやっていたことが誰かの背中を押すきっかけになったと思っています。

この記事で、コネヒトの雰囲気を知っていただけたり、何か全社に取り組みを波及させたいと思っている人が希望を持っていただけたら嬉しいです。

肯定から始めてフォローする、良さそうなことは試してみるといった文化が根付いているコネヒトに少しでも興味を持っていただけたら、お気軽にご連絡ください。

www.wantedly.com

形骸化しない/させない定例的MTGアップデートの歴史

この記事はコネヒトアドベントカレンダー2022の6日目の記事です。

こんにちは。2017年11月にAndroidエンジニアとしてjoinした@katsutomuです。

前回のエントリーで、髪の毛のアップデート予定について触れましたが、今は黒髪7割金髪3割りといったところです。

さて今回は、コネヒトの開発組織で行われている定例的*1なMTGについて紹介させていただきます。

目次

コネヒト開発組織の定例的MTGはどんなものか？

コネヒトでは2018年ごろから、エンジニア全員が参加する定例的なMTGを実施しています。定例的なMTGは、ともすれば形骸化しがちですが、コネヒトではその時々で注力する課題から目的を定め、定期的なアップデートを行っていきました。今回はその変遷を紹介しようと思います。

ぜひ皆さんに読んでいただきたいですが、以下の方に特に届けられたらと思います。

対象読者

  • チームや部署間の情報同期の進め方にお悩みの方
  • 定例に課題はないが、他社の事例を知りたいという方
  • これから定例することが、決まっているが、やり方がわからない方

MTGの変遷

さて、まずはこれまでの定例の変遷を以下の図と表にまとめました。

名前 目的 時期 規模 内容
一歩MTG •部署/チーム間の相談&課題解決 2018年 ~ 2019年 スクラムチームが3。部署が1つ。 • 各チームのやったことや、アピールしたいことを話す
• みんなに質問・共有・相談
• 周知事項共有
戦略MTG • 戦略を実行精度を向上のための、課題の早期発見/早期対処 2019年 ~ 2021年 チーム3~4。部署が2つ。 • OKR進捗確認
• 開発チームトピック共有
• みんなに話したい！タイム
ボックスMTG ・「なぜつくるか」「どうつくるか」のノウハウ展開
・部署/チーム間のコラボのきっかけの場		 2021年 ~ 2022年 チーム4~6。部署が2つ。 ・10分の共有・相談タイム*4枠
・連絡共有事項

日々アップデートしながら、大体1~2年が経つころに、大幅なアップデートをしています。次のセクションでそれぞれの課題と背景をふまえて、MTGの内容を具体的に紹介していきますが、MTGに正解の形はなく、今回紹介するもベストなものばかりでは無いものの、少しでも思考の刺激になればと思います。

一歩MTG時代 2018年 ~ 2019年

課題と背景

スキルを網羅したチーム編成から、ミッションを元にしたチーム編成するように変更した時期です。同時に会社の規模が大きくなり、従来のスクラムの枠では収まらない仕事やプロジェクトが増え、単独のチームで業務を完結出来ないケースが増えてきました。その状況を踏まえ、部門全体の目標達成を円滑にするべく、横串で情報や課題を共有して、解像度を上げる場が必要でした。 ちなみに名前はママの一歩を支えるという弊社プロダクトのママリのミッションからつけています。

各チームでやったこと・これからやることシェア

名前の通り各チームが取り組んだ施策や結果を共有し、次に何をするかを同期していました。スクラムチームで、取り組んだワークショップを紹介することもありました。当初は各チームの代表者が読み上げていましたが、質問・相談の時間を増やすために、読み上げなしとしました。

みんなに質問・共有・相談したいことタイム

チームの連携周りやシステム全般に関わることを相談する時間です。

例えば、画像にあるように特定ブランチのライブラリアップデートの進め方どうする？ということを話していました。

戦略MTG時代 2019年 ~ 2021年

課題と背景

中期ビジョン策定がなされ、ビジョン実現のために戦略の重要度が高くなった時期でした。ビジョン実現を念頭に各部門戦略を策定し、実行の精度を上げることを組織的に力をかけ始めました。そのため部門の全体像を可視化し、課題の早期発見/早期対処を進める場が必要でした。

OKR進捗確認

半期毎のOKRの進捗状況を共有し、打ち手の検討をおこなっていました。事前に課題を書き、状況をみんなで点検し、対策を打ちやすくしていました。

テックビジョン小噺

テックビジョンが策定されたので、全員が理解度を深めコミットする状態を目指すために、CTOに質問をぶつけて、どのようにテックビジョンを実現するかの議論をするコーナです。以下のフォーマットで、CTOとメンバー全員で議論をしていました。

テックビジョンはIntroduction · Connehito Tech Visionを是非お読みください！

みんなに話したい！タイム

相談したいことや、共有したいことを話せる時間です。例えば、画像にあるようにアプリケーションエンジニアと、インフラエンジニアコミュニケーションの課題や、既存プロセスの改善などの相談が行われていました。

ボックスMTG時代 2021年 ~ 現在

課題と背景

単独チームで戦略を実行できるが増え、チームの独自性が高まったこ反面、OKR進捗共有が共有のための共有になる、ナレッジのサイロ化とチーム間の協働がゆるくなり始めました。ノウハウの循環が止まり、チーム内に閉ざされたことで、本来上げられたはずの成功確率が上がらない状態となっていました。この課題に対し、戦略MTGのみんなに話したい！タイムを強めた、話したいことを話したい人が話せる場としてアップデートを行いました。

コンセプト

💡 レンタルボックスを借りて、そのボックスの中で自分のお店を開くように色んな人が、 期間限定で臨時開設されるポップアップストアのように柔軟に、関わっていける場

目的

  • 部門を跨いで情報を同期的にブロードキャストする場
  • 「なぜつくるか（Why）」や「どうつくるか（How）」をノウハウとして展開する場

このやり方で、2021年前半からMTGを実施しています。具体的な進め方は以下の通りです。

かためな内容〜ゆるめな内容まで話される課題に向き合ったMTG

  • 会場：Zoom
  • 頻度：隔週
  • 議事録：notion
  • 進め方
    • ボックス①~④を共有&議論(40分)
    • ライトな共有周知事項&WinSession(10分)

ボックスと呼ばれる枠を10分×4つの自由枠を用意したことで、議題のバリエーションが増え、結果的に以前よりも部署・チームを跨いだコラボレーションの場として機能するようになったと感じています。なおボックスは、以下のガイドラインに従って事前に抑えます。せっかくなので議題のいくつか例示します。

このように組織全体の目標の話から、技術的、チーム的な運用面の課題提起・改善議論をできる場となっています。開発部オンボーディングのテンプレを作りたいというテーマでは以下の画像のように話し合いがされました。

例示したように、チームや部署を跨いで相談し(少しでも)課題を解決するための場として機能していて、以前までの決まった方式でなく、ボックス方式にしたことで議題に柔軟性がでて、メンバーやチームが、それぞれの課題やアイディアをシェアし、コラボレーションを行う場になったと思います。細かい部分では、議事録担当を持ち周りにする、不在メンバーのために録画を残しておくという工夫をしています。最近はボックスMTGの中で、各メンバーのGood Acitionを自薦・他薦で紹介するWin Sessionも実施しています。

コネヒトの強いカルチャー

改めて振り返ってみると、コネヒトの肯定から始めよう~Affirm&Follow~というカルチャーを強く感じられました。まずは肯定から初めて乗っかりやフィードバックをしていくことで、コトを進めていくカルチャーです。そのカルチャーとの相乗効果を高めるためにも、どのMTGでも全員が参加し議論するオープンさに拘り続けていました。いわゆる定例的なMTGは形骸化しがちで、参加する側が必要性を感じない環境も多いと思いますが、コネヒトの場合、定期的にMTGの役割をアップデートし、課題を放置せずにフォローし合う仲間がいることで、長い期間意義のあるMTGを作れていると思います。

最後に

今回は、エンジニア組織の定例MTGの変遷とフォーカスポイントを紹介させていただきました。同じような課題に悩んでいる方の参考になればと幸いです。

私自身も改めて振り返ってみたことで、組織の成長を実感できこれからのアップデートが、より楽しみになってきました。

最後までお読みいただき、ありがとうございました！ 7日目はインフラエンジニアの @laugh_k の記事です。

tech.connehito.com

日曜日には、Webエンジニアの@TOCが、チームで実施している別のボックスMTGの事例を紹介してくれます。どちらもお楽しみに〜〜〜！

*1:定例呼ぶのが好きでなく的をつけてます

コネヒトでNotion導入活動を始めて1年以上経過した

notion

🎅 この記事はコネヒトアドベントカレンダー2022の7日目の記事です。
前回は… katsutomuさん…. !!!

インフラエンジニアの @laugh_k です。 今回は私が中心となって去年から行っていたコネヒトにおけるNotion導入に関する話をまとめます。

tl;dr

  • コネヒトにおけるNotion導入を1年間でどのように進めたか紹介します
  • Notionの基本的な使い方や細かなプラクティスは書籍・インターネット上に多くの情報があるため、この記事では深くは触れません
  • 導入して終わりではなく、まだまだ課題はあるものの、確実にコネヒトのワークスタイルが進歩しました

アウトライン

なぜNotion導入を進めようとしたのか

最初になぜインフラエンジニアである私が中心となってNotion導入を進めたのか簡単に紹介します。

背景

昨年2021年の3Q始まりのタイミングで私の所属するテクノロジー推進部にて、リモートワークで一緒に仕事しつつも、どんなことを感じていたりするかといった「コンディション」をお互いもっと把握したいねという課題が出たことがきっかけです。

当時のコネヒトではリモートワーク中心の中のコミュニケーション系のことは大体「SlackかZoomでどうにかする」が主流でしたが、この課題に関しては非同期でも実現するべくアプローチの方が良いという話になり、以下の記事をベースとした「チーム日報」をやってみようという話になりました

razokulover.hateblo.jp

この記事では Scrapbox を用いていますが、当時安定したリアルタイム同時編集が可能でカジュアルに利用できる社内のツールに決定的なものもなかったため「せっかくならよりコネヒト全社で活用できそうなものを導入してみてはどうか」と動き始めることになりました。

Notion の選定

最低限必要になったのは「カジュアルにリアルタイム同時編集可能なツール」でした。ただ、これに加えて「インラインコメント可能なものの方がよりメンバー同士のコラボレーションを加速させられそうだ」と考え、さらには「ドキュメントツールと言うより、オンライン上でテキストベースのプロジェクト・ToDo管理、議論、社員の活動の可視化などのコラボレーションを加速させるものがいい」と考え Notion に白羽の矢が立ちました。

何でインフラエンジニアなのにNotion導入担当になったのか

「コンディション」をお互い把握するためにチーム日報の提案をしたのも、その手段としてNotionを選定すると全社に対しても良い影響を与えれそうだと直感的に思ったのも私だったことが大きいです。これに加えて他のメンバーの業務状況を考慮してもすぐに動け出せそうだったのが私だったこともアリ「じゃあ自分がやるか！」と腹をくくり、自称社内Notionエバンジェリストを名乗っていくことになりました。

結果論ではありますが、当時インフラエンジニアは @shnagai と私の二人体制で裁量も高く、新しいツールを業務にガンガンねじ込むのが比較的容易な立場にあり、むしろ適任であったようにも思えます。

ざっくりとした導入の流れ

大まかな導入の流れは以下の通りです。

  1. 自分の所属チームでトライアル（2021年11月～）
  2. エンジニア組織全体でのトライアル（2021年12月～）
  3. 全社員でトライアル（エンジニア以外はゲストアカウント）（2022年2月～）
  4. 経営会議に議題持ち込み（2022年2月～3月）
  5. 正式導入、全社員を対象にチームプランで契約（2022年4月）
  6. 各チームで本格的に業務投入が開始（2022年4月～）

正式に社内ツールとして承認されたのは2022年4月ですが、そこから全社でNotionを業務に取り入れていくのにあたり、各部署・チームによって少しずつ慣れていったところもあり、「Notionがあるのが当たり前」となったのは2022年10月ごろではないかと個人的には考えています。

ざっとどういった活動だったのかを紹介します。

1.自分の所属チームでトライアル / 2. エンジニア組織全体でのトライアル （2021年11月～）

一番最初は私の所属するテクノロジー推進部（テク推）でトライアルとして少しずつ利用をはじめました。利用用途としては背景でも紹介した「チーム日報」であったり、部内のMTG議事録をNotionにまとめてみるなどです。

チームでトライアル開始してから5日目くらいの「チーム日報」の様子
チームでトライアル開始してから5日目くらいの「チーム日報」の様子

部内でのトライアルと同時進行でエンジニアメンバー全体にトライアルの範囲を拡大すべく、開発組織ボックスMTGに議題として持ち込みチームプランの予算の確保にもも動きました。この時点でエンジニアの人数分でチームプランを契約しています。

チーム以外の開発組織全体に「Notionを使いたい」という表明をしている様子。メインのドキュメンテーションツールである Docbase で行っている
チーム以外の開発組織全体に「Notionを使いたい」という表明をしている様子。メインのドキュメンテーションツールである Docbase で行っている。

チーム以外の開発組織全体に「Notionのトライアルやってくよ」という表明をしている様子
チーム以外の開発組織全体に「Notionのトライアルやってくよ」という表明をしている様子

3. 全社員でトライアル（エンジニア以外はゲストアカウント）（2022年2月～）

エンジニアメンバーのみでトライアルを進めるも、すぐにエンジニア以外のメンバーともNotion上でコラボレーションしたいという状況が発生しました。

エンジニア以外の人にもNotionを早めに使えるようにしたいという意見が出ている様子
エンジニア以外の人にもNotionを早めに使えるようにしたいという意見が出ている様子

そこで、全社へ正式に導入されるまでの間は暫定対応としてすべてのページにエンジニア以外のメンバーもゲストアカウントとして招待する対応を取りました。人数が多く、APIで出来るものでもないので力業ではありますが、結果としてより多くのメンバーにNotionを使ってもらえる状況になり、業務に組み込みやすい状況にできました。

全社向けにゲストアカウントを発行したアナウンスの様子
全社向けにゲストアカウントを発行したアナウンスの様子

4. 経営会議に議題持ち込み（2022年2月～3月）

トライアルを通じた手ごたえから、正式に全社への導入提案を議題として経営会議に持ち込みました。最初に2月時点で中間報告としてどのような導入状況か、導入によってどのような問題が解決できそうな見込みがあるのかを報告をしました。

実際に中間報告の時に使ったNotionページの一部’
実際に中間報告の時に使ったNotionページの一部’

その更に1か月後に中間報告の結果を受けて最終的な形として提案議題を持ち込みました。

実際に全社への導入提案をした際に使ったNotionページの一部
実際に全社への導入提案をした際に使ったNotionページの一部

その際さらに追加の議論が発生し、合計で3回ほど経営会議に議題を持ち込むことにはなりましたが、2022年3月末に最終的に承認され無事に全社への導入が決定します。

5. 全社に正式導入（2022年4月）

4月に正式に全社向けの導入が承認され予算も確保できたため、チームプランの対象が全社員になりました。ここで改めて正式に利用可能になったアナウンスを出しました。

正式に全社導入が完了した際のアナウンスの様子
正式に全社導入が完了した際のアナウンスの様子

また、「Notionのアカウントができたんだけどとりあえず何すればいいの？」という人向けのページも用意し、少しでもNotionを触るための障壁を下げる試みもしています。

Notionに初めてアクセスした人向けのページの様子
Notionに初めてアクセスした人向けのページの様子

6. 各チームで本格的に業務投入（2022年4月～）

4月以降は全社員がNotionを利用できるようになりました。これをきっかけにエンジニア以外でも業務への導入が進み、全社的に「Notionを使おう」という流れができました。

コーポレート系の情報が集まるページの例
コーポレート系の情報が集まるページの例

一方で、トライアル期間に差があるのはもちろん入社時期や得意不得意によってもNotionそのものの習熟度は人によって異なります。日々Notionに関する困りごとの解決のお手伝いは続きます。

Notionの使い方に関する質問の様子(1)
Notionの使い方に関する質問の様子(1)

Notionの使い方に関する質問に答える様子(1)
Notionの使い方に関する質問に答える様子(1)

時間の経過とともに私以外の誰かが回答・解決してくれる機会も増えてきていますし、質問の内容もより突っ込んだものも増えてきている印象です。

Notionの使い方に関する質問の様子(2)
Notionの使い方に関する質問の様子(2)

Notionの使い方に関する質問に答える様子(2)
Notionの使い方に関する質問に答える様子(2)

導入の際に意識したこと・工夫したこと

実際、ここまで進めるには様々な困難があり、工夫したことや意識したことは数え切れません。この記事にすべてを詳細に書くととんでもない長さになってしまうので簡単に厳選すると以下のようなものがあります。

意識

  • 社内Notionエバンジェリストを名乗るからには「コネヒトで一番のNotionヘビーユーザーであるべき」と意識の元、隙さえあれば業務にNotionねじ込み、活用しつづけました
  • 「社内で一番Notionに詳しい人」を演じ、「@laugh_k に声をかければNotionに関する悩みは解決するぞ」という雰囲気づくりの徹底。特にトライアル時は Notion相談ワイガヤ Slack チャンネルに張り付いていました
  • 勝手に導入するのではなく、関係各所と調整しチームのプロジェクトとして立ち上げ正面から進めました。特に四半期の部署としての目標にNotion導入を掲げさせてくれ、布教活動の際にいっぱい助けてもらったテクノロジー推進部には感謝しています
  • ボトムアップで新たなツール・サービスの導入には現場が納得していることが一番重要と考え、「そっちのチームのこの業務でNotion使ってください」というお願いは一切せず、「こういう活用ができて便利です！」という提案にひたすら徹して布教活動をしました。

工夫

Notion 相談ワイガヤSlackチャンネルを用意

「Notionに関する話ならここで！」というSlackチャンネルを用意しました。Q&Aにとどまらず、新しい機能や便利な使い方を見つけた際に「これ便利！」という共有やNotion導入時に必要な議論も行われました。

Notionの新機能を見つけてはしゃいでいる様子
Notionの新機能を見つけてはしゃいでいる様子

Notionに関する疑問を話している様子
Notionに関する疑問を話している様子

Notionの理解具合をつぶやいている様子
Notionの理解具合をつぶやいている様子

Notionのページ階層のやり方に関する議論の様子
Notionのページ階層のやり方に関する議論の様子

また、@NotionJP やNotionの中の人である @katsu2488 さんの Tweet が流れるようにして情報のキャッチアップをできるようにしています。

Notionのリリースに沸く人々
Notionのリリースに沸く人々

「Notionに何書けばいい？」問題の解決

トライアル初期の「Notionに何書けばいい？」は日報のような既存の社内文化や、自己紹介データベースなどの緩めなコンテンツを置く場所を用意したり、なるべくルールを設けず自由に使ってもらうようにしました。

誰でも自由に何を書いてもいい日報置き場（もともとSlackにあった文化を踏襲）
誰でも自由に何を書いてもいい日報置き場（もともとSlackにあった文化を踏襲）

自己紹介ページを置いておくデータベースの様子
自己紹介ページを置いておくデータベースの様子

また、議事録やドキュメントと言ったものは自分たちのチームに制限する必要のないものは共通のデータベース置き場を用意し、本体はそこに作成。各チームごとに必要なページに必要な形でリンクドビューを設置できるようなやり方にしました。

議事録など自分のチーム以外でも使えそうなものはチームに閉じない形でデータベースを設置
議事録など自分のチーム以外でも使えそうなものはチームに閉じない形でデータベースを設置

ドキュメント置き場も、特定のチーム向けではなく全社員で利用する前提で用意しています
ドキュメント置き場も、特定のチーム向けではなく全社員で利用する前提で用意しています

自分の裁量がある業務領域ではガンガン使いまくる

自分が所属するインフラエンジニアチームやテクノロジー推進部の業務には多少強引にでもNotionを組み込んでいき、Notionを扱う知見を先行して習得しつつ、先行事例として他のチームへも提案していきました。実際ちょうど1年前の時期に書いたブログの時点でも、インフラチームでNotionを活用していました。

tech.connehito.com

定期的に集まってNotionに関する知見共有できる場を用意

Notion の知見をゆるく共有し合うオンライン定期イベントを開催しました。その際に、会の様子をNotion上にリアルタイムでメモを取ることによって、Notionのことを知るだけでなく同時編集可能なツールでの議事録の取り方を体験してもらう機会を提供する試みもしました

社内Notionイベントを告知する様子
社内Notionイベントを告知する様子

Notionイベントの議事録の様子。文末にあるアイコンは自己紹介ページへのメンションで、その行を誰が書いた/発言したのかがわかるようにしています
Notionイベントの議事録の様子。
文末にあるアイコンは自己紹介ページへのメンションで、その行を誰が書いた/発言したのかがわかるようにしています

イベントの議事録は全社共通のデータベースで管理します。プロパティでフィルタすればいいので誰がどんな目的でやったものでも利用できます
イベントの議事録は全社共通のデータベースで管理します。プロパティでフィルタすればいいので誰がどんな目的でやったものでも利用できます

Notionが導入されてどうなったか

Notionが導入されたことにより、様々な変化がありました。

議事録やボードビュー、通知による社内の動きの可視化

これまでなかなか見えなかった社内の活動も一か所の議事録データベースに集まりやすくなりました。

データベースのボードビューを活用したタスク管理が社員ならだれでも見れる場所で行われるようになり、「あのチームが何をやっているのか分からない」となったときにも気軽に見にいけるようになりました。

他にも、通知欄からワークスペースにおける更新状況を眺めることができるので、なんとなく「今こんなことが動いているのか」という情報をキャッチアップ出来るようにもなりました。

同時編集とインラインコメントによるコラボレーション

リアルタイム同時編集とインラインコメントも当たり前となり、オンライン上のテキストベースの議論やレビューが活発に行われるようにもなりました。

また、導入のきっかけとなった「チーム日報」については私が所属するテクノロジー推進部にとどまらず複数のチームのものが毎日更新されるようになり、新たなコネヒトの文化となっています。

課題や不満ももちろんある

Notion はかなり自由度が高く利用できるため、ページの階層や、データベース自体の整備はまだやりきれていないというのはあります。特に導入時は「まずNotionに触ってもらう」事が重視されるので必要ではあるもののどうしても後手になりがちですし、各チームでのワークフローに依存するところもあるのでボトムアップでのアプローチはなかなか難しいです。

また、実際に業務で利用してみると導入時点では見えていなかった不満が出てきている部分もあります。Slack通知か細かすぎてあまり柔軟にコントロールできないことや、メンションに続けて日本語入力をする際の挙動が安定しないところなどは改善してもらいたいところです。

それでも、Notion の導入は確実に組織にとってプラスになった

課題もあるものの、Notion導入を通じてコネヒトにおける業務をより濃密なものとなりました。

職種関係なく一つの会社のメンバーが平等に利用できるオンライン上のコラボレーション環境として、大いにその力を発揮しているのは間違いないです。Notion を選定する際に「ドキュメントツールと言うより、オンライン上でテキストベースのプロジェクト・ToDo管理、議論、社員の活動の可視化などのコラボレーションを加速させるものがいい」としていた期待には大いに応えてもらっています。

さいごに

Notionはコネヒトにおける利用状況は全社員で平等に利用できるようになった段階で、まだまだ未成熟な部分も多いため、これからも発展させていく段階ではあります。しかし、Slack・Zoomと並び業務になくてはならないものとなりました。

あわよくば、この記事が少しでもNotionの導入を検討している方の助けとなれば幸いです。

明日の コネヒトアドベントカレンダー2022 は PdM の @soracoco440 の記事です。 お楽しみに。

ママリへのSwiftConcurrencyの導入

Swift iOS

こんにちは！コネヒトでiOSエンジニアをやっていますyanamuraです。

Xcode13.2からSwift ConcurrencyがiOS13からでも使えるようになり、遅ればせながらママリのiOSアプリでSwift Concurrencyを導入してみました。

ママリのアーキテクチャ

現在ママリのiOSアプリのアーキテクチャはMVVMになっています。 全体的にRxSwiftを用いてView, ViewModelのbindingだけでなく非同期処理を実装していて、新しく追加したところはCombineを使っているといった状況です。

どこに導入したか

今回Swift Concurrencyを導入したのは、Web APIとの通信部分です。これまではRxSwiftやCombineを用いて通信の非同期処理を行なっていました。しかし、基本的やっていることは通信して終わったら処理をするといった単純なことで、reactiveなことをしなくてcompletion handlerやResult型などでも事足りる感じでありました。Swift Concurrencyを導入することでasync/awaitでシンプルに書け、RxSwiftの依存部分を減らすことができないかと考え今回試してみました。

実装

通信周りは外部ライブラリに頼らずシンプルにURLSessionで実装していたので、以下のようなfunctionを用意してasync/awaitを使えるようにしました。

// 例 (見やすくするためかなり端折ったものでこのまま使わないでください）
func request(url: URL) async throws -> Data? {
    try await withCheckedThrowingContinuation { continuation in
        let task = URLSession.shared.dataTask(with: URLRequest(url: url)) { data, response, error in
            if let error {
                continuation.resume(with: .failure(error))
            } else {
                continuation.resume(with: .success(data))
            }
        }
        task.resume()
    }
}

呼び出す時はawaitすることで同期っぽく書けるようになります。

let data = try await API().request(url: URL(string: "https://connehito.com")!)

このawaitする関数自体も結果待ちする場合はasyncし

func fetchUserID() async -> UUID {
  let data = try await API().request(url: URL(string: "https://connehito.com")!)
  … // dataをparseしてuserIDを取得

  return userID
}

結果待ちしなくてもいい場合はTaskで投げっぱなしにします。

func refresh() {
  Task {
      let data = try await API().request(url: URL(string: "https://connehito.com")!)
      …. // dataをparseしてuserIDを取得
      
      self.userID = userID
  }
}

まとめ

RxSwiftだとこんな感じだったものが

func fetchUserID() -> Observable<UUID> {
  return API().request(url: URL(string: “https://connehito.com”)!)
      .map { data in
          … // dataをparseしてuserIDを取得
          return userID
      }
}

async/awaitを使うと直感的な記述になりました。

func fetchUserID() async -> UUID {
  let data = try await API().request(url: URL(string: "https://connehito.com")!)
  … // dataをparseしてuserIDを取得

  return userID
}

一部に導入してみて割と良い感じだったので、どんどん使っていきたいと思います！

コネヒトでの開発に興味を持っていただいた方はカジュアルにお話しましょう〜
TwitterのDMなどでも大丈夫ですのでお気軽にどうぞ
日本中の家族をITの力で笑顔にしたい、iOSエンジニア募集！ - コネヒト株式会社のモバイルエンジニアの採用 - Wantedly

BigQueryのシャーディングされたテーブルをOpenSearchへ連携する方法

BigQuery OpenSearch AWS

皆さん，こんにちは！最近は検索エンジニアとしての仕事がメインの柏木（@asteriam）です．

はじめに

今回はTips的な記事になります．背景としては，アプリの検索ログをBigQueryに溜めているのですが，それを検索エンジンのサジェスト機能で使用するために，BigQueryからAmazon OpenSearch Serviceへデータ連携を実施しました．その際にBigQueryのシャーディングされたテーブルをどのようにして連携したかというお話になります．

検索システムのデータ基盤構築に関する過去のブログでも紹介していますが，我々はGlueを用いて検索エンジン（OpenSearch）へのデータ連携を行っています．今回はGlueを用いる点は同じですが，データソースはBigQuery，ターゲットソースをOpenSearchとしてデータ連携しました．

今回は以下の内容を紹介していこうと思います．

  • BigQuery→OpenSearch連携の概要
  • BigQueryのシャーディングされたテーブルを連携する方法

目次

BigQuery→OpenSearch連携の概要

今回紹介するデータ連携は至ってシンプルです．

下図にあるように，BigQueryにある検索ログをGlueでExtractし，検索エンジンであるOpenSearchへLoadする流れになります．

  • データソース：BigQuery
  • ターゲットソース：OpenSearch

データパイプラインの概略図

Glueには，BigQueryに接続するためのコネクターが用意されており，簡単に連携ができるようになっています．接続方法の手順はクラスメソッドさんのブログが参考になるので，そちらに譲ろうと思います．（コネクターをSubscribeする画面にも英語ですが，説明が記載されています）

参考：AWS Glue Connector for Google BigQueryを使ってBigQueryからS3にデータを転送する

データソース（BigQuery）の設定では，BigQueryのプロジェクトIDや連携したいテーブルIDなどの情報が必要になります．一方で，ターゲットソース（OpenSearch）の設定では，インデックス名やエンドポイント名などが必要になります．

ここで，連携したいBigQueryのテーブルは日付でシャーディングされており，そういったテーブルをどうやって連携するかが問題になります．

BigQueryのシャーディングされたテーブルを連携する方法

日付でシャーディングされたテーブルとは，下図のようにtable suffixが日付になっていて，日ごとにインクリメントされた形式のテーブルのことを言います．

シャーディングされたテーブル

このようなテーブルを連携したい場合にどうすればいいか？

Connection optionsのKeyにqueryを使う

BigQueryコネクターのConnection optionsに幾つかの設定が必要になりますが，そのうちの一つとして，queryというkeyを使うことでシャーディングされたテーブルの連携に対応することができます！

参考：Push down queries when using the Google BigQuery Connector for AWS Glue

下図はGlue StudioでのBigQueryコネクターの設定画面になります．

BigQueryコネクターで設定する内容は4つになります．

  • materializationDataset: <BigQuery側で連携用に一時的に作成するデータセット名>
  • parentProject: <プロジェクトID>
  • viewsEnabled: <ビューの許可>
  • query: <データ抽出するためのクエリ>

Glue Studio: BigQueryコネクターの設定

queryには実行したいクエリをそのまま入力します．例えば，現在から30日前までの検索ワードとそのカウント数を集計したデータを抽出したい場合は，以下のような感じになります．

SELECT
    word,
    count(word) AS word_count
FROM `hogefuga.search_events_*`  # 検索ログが入ったテーブル
WHERE 0 = 0
AND _TABLE_SUFFIX >= FORMAT_DATE('%E4Y%m%d', CURRENT_DATE('Asia/Tokyo') - 30 )
GROUP BY word

ただし，注意点があります．

  • materializationDatasetに設定するデータセットは予めBigQueryに作成
    • 試行錯誤の結果，データセットがない場合にGlueは勝手に作ってくれず，エラーになってしまうので，予め作成しておく必要があります
    • 加えて，このデータセット配下に一時的に作られるテーブルに対するwrite権限が必要で，それがないとエラーになります

最後に，OpenSearch側の設定も載せておきます．

  • path: <インデックス名>
  • es.node: <エンドポイント名>

Glue Studio: BigQueryコネクターの設定

おわりに

単一のテーブルは簡単に連携できたのですが，シャーディングされたテーブルを連携する時にハマってしまったので，今回のTipsが誰かの役に立てば幸いです！GCP側の権限などはハマりポイントかなと思うので，試しながら試行してみて下さい．

検索ログが連携できたことで，サジェスト機能も前進しているので，これからも検索エンジンの改良を進めて行こうと思っています！

最後に，コネヒトではプロダクトを成長させたいMLエンジニアを募集しています！！（切実に募集しています！）
もっと話を聞いてみたい方や，少しでも興味を持たれた方は，ぜひ一度カジュアルにお話させてもらえると嬉しいです．（僕宛@asteriamにTwitterDM経由でご連絡いただいてもOKです！）

www.wantedly.com

また，コネヒトにおける機械学習関連業務の紹介資料も公開していますので，こちらも是非見て下さい！！

tech.connehito.com

参考

スキルマップを使ったチームビルディング

チームビルディング

こんにちは！エンジニアの富田です。先月末に開催したスキルマップを使ったチームビルディングがとても良かったので、内容を紹介したいと思います。

なぜやろうと思ったのか

前提として私が所属しているプロダクト開発チームは以下の構成です。

  • PdM 1名
  • デザイナー 2名
  • エンジニア 4名

ご覧の通り職能横断型のチーム構成になっており、チームとして4ヶ月ほどプロダクト開発を進めているのですが、お互いのことをあまり知らないなと感じることがありました。もちろん自己紹介をしたり、スクラムの朝会でちょっとした小話をしているのですが、なかなか自分の得意なこと、苦手なことを開示する機会がありませんでした。

自己開示することで、自分のことを知ってもらったり、周りのことをより知ることができるので、結果としてパフォーマンスやモチベーションが向上するのではないかと考えました。何かしらチームビルディングのワークをやりたいと考えていたものの、稼働時間の限られている業務委託メンバーも一定数いるため、「作業時間を奪ってしまうかもしれない？」という懸念からなかなか一歩踏み出せませんでした。

そんな困っていた中、弊社のデザイナーチームが「スキルマップは自己紹介、リモート前提の業務設計ですごく役立つよ」と話していて、これは簡単で面白そうだと思い、スキルマップの進め方及びテンプレートを教えてもらい、スキルマップを使ったワークを試す運びとなりました。

どんなことをやったのか

好き・嫌い、できること・できないこと、を軸にして、付箋を貼ってチームメンバーで共有するというものです。それぞれ発表した後、チームの他のメンバーが「得意そうだとと思っていること」「苦手そうだと思っていること」を付箋に書いていって、認知のずれを確認し合うワークです。

スキルマップのテンプレート

テンプレートは上記の通り Miro で作成しており、3つのステップに大別されます。

1.(事前準備)自分のスキルを黄色の付箋に書いて貼ってみよう

  • ハードスキルでもソフトスキルでもOK
    • ハードスキル：Swift、PHP、Photoshop・Notionを使ったタスク管理
    • ソフトスキル：ファシリテーション・コミュニケーション、誰とでも仲良くなれる

自分のスキルを付箋に記入して、好き・嫌い、できること・できないこと、を軸にマッピングします。 一見簡単そうに見えますが、自分のスキルと聞かれてパッと思いつく人は少ないのではないでしょうか。 実際、事前準備なしにワークをしたところ、悩んでいるメンバーも多く、付箋を書くのに15分ほどかかりました。 ですので、スキルに関しては事前に記入してもらうと、効率的にワークを進められるのでオススメです。

2.参加メンバーに自分のスキルを発表します

  • 1人5分程度で発表します。ポジティブな話題の方が共有しやすいため、右上の得意なところから時計回りに話していくと良いです
  • メンバーはチャットなどで感想を書いたり、質問をしてみましょう
  • また、周囲から見て得意そうなこと・苦手そうなことを付箋に書いていきます

マッピングした内容を各自共有します。周囲からのコメントは周りにどう思われているか知る良い機会ですので、ぜひ感想や質問、または周囲から見て得意そうなこと、苦手そうなことを付箋に記入してみてください。

3.周囲から見て得意そうなこと・苦手そうなことをマッピングします

  • 他のメンバーの認知と自分の認知の違いを見てみましょう
  • ギャップがある時はなぜそこにマッピングしたかを議論してみましょう

周囲から記入してもらった得意そうなこと、苦手そうなことをマッピングします。周りから見て得意そうなことが自分にとっては実は苦手だったまたはその逆も然り。マッピングすることで暗黙知のギャップを埋めることができます。

結果はどうだったのか

実際にスキルマップを使ってワークを試してみました！

実際に試したスキルマップの一部

メンバーのコメントをいくつか抜粋します。

  • デザイナーだけどフロントエンドの実装もしたい！
  • 周りからは取捨選択得意そうに見えていたけど、ちょっと苦手に感じていた
  • グラフィックデザインはできるんだけど、あんまり好きではない
  • ファシリテーションが苦手なんだけど、周りは得意だと思ってくれていた
  • コンテンツディレクションをしているけど、コンテンツ制作が若干苦手

結果として意外な発見も多く、認知のギャップを解消できました。今回のように職能が異なるメンバーが混在したメンバー編成時に試すと効果が高いと思います。

最後に

スキルマップを使って「得意そうだと思っていること」、「苦手そうだと思っていること」の認知のギャップを埋めるワークを紹介しました。

当初の「お互いのことをあまり知らない」という課題感に対して、一定の暗黙知を解消できたように思います。同じような課題感をお持ちでしたら、コストも低く、試しやすいワークになっていますのでお試しください。

直近ではドラッカー風エクササイズも試していますので、よろしければご覧ください。 tech.connehito.com

コネヒトでは一緒に働く仲間を募集しています！ そして興味持っていただけた方は気軽にご連絡ください！

www.wantedly.com