コネヒト開発者ブログ

コネヒト開発者ブログ

脱RosettaしてiOSアプリのビルド時間を短縮

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

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

Apple Siliconを搭載したMacをつかって開発していますが、ママリのiOSアプリはXcodeではRosetta2上でしかビルドが通らずCPU性能を生かしきれていませんでした。

なぜRosetta2上でしかビルドが通らなかったのか

原因はいくつかのライブラリでソースコードではなくバイナリで提供されているものがあり、それらがsimulator 向けarm64のバイナリを含んでいなかったためです。

Apple SiliconはiPhoneのCPUと同じARM系チップの64bit CPUなので、fat binaryにarm64のバイナリが含まれていれば普通にsimulatorでも動くだろうと思っていたのですが、なんとそうはいきません。

なぜなら、arm64向けのbinaryでも、simulatorとdevice用では若干違い(LC_BUILD_VERSION、LC_VERSION_MIN_IPHONEOSの有無)があるためdevice用のarm64のバイナリをsimulatorで利用することはできません。また、これらの両方のarm64バイナリを含んだfat binaryが生成できないため、XCFrameworkにしてかつApple Silicon Macでビルド1してバイナリを生成する必要があるのです。

この辺の話の詳細が知りたい場合はこちらの記事を読んでみてください。 https://bogo.wtf/arm64-to-sim.html

ママリiOSアプリでやったこと

基本的な手順としては以下になります

  1. XcodeをApple Silicon上で起動(Open using Rosettaのチェックをはずす)してビルド
  2. Ld: XXX, building for iOS simulator, but linking in object file built for iOS, file YYY for architecture arm64 のエラーがでたframeworkをXCFramework版に変更する

2の対応で一部ライブラリがXCFrameworkに対応していないという問題が発生しました。

具体的には、2022年12月現在GoogleMapsSDKがXCFrameworkに対応していませんでした。

GoogleMapsSDKのXCFramework対応

正式版ではXCFrameworkにまだ対応していませんが、ベータ版が公開されていたのでこれを開発用にだけ利用することにしました。

ママリではCocoaPodsを利用しているので、CocoaPodsでのやり方を紹介します。

本番用では以下のようにReleaseビルドのときだけGoogleMapsSDKの正式版を使うようにし

pod 'GoogleMaps', '~> 7.2.0’, :configurations => ['Release']

開発用ではベータ版をダウンロードしたものをprivateリポジトリに作成してつかっています。

pod 'GoogleMaps-dev',  :configurations => ['Debug']

改善結果

RosettaとApple Siliconでビルドした時間を比べてみました。

結果としては約140secだったのが約90secとかなりの改善効果を得ることができました。

ビルド時間(sec)
Rosetta 140
Apple Silicon 90

ビルド時間が早くなるとビルド中にTwitterを見る時間は減りますが生産性があがるので脱Rosettaはおすすめです!


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


  1. Apple Silicon Macでビルドする必要が本当にあるかは未確認です。クロスコンパイルできると思うので不要そうな気はしています。

日本語サジェスト機能の実装にあたり試行錯誤した話

こんにちは。エンジニアの永井(shnagai)です。

今回は、現在進めている検索システム内製化プロジェクトの中で、日本語サジェストを実装するために試行錯誤した話を書こうと思います。

内容は、ざっくり下記の構成になっています。

  • 日本語サジェストの難しいところ
  • よりよい日本語サジェストのために試行錯誤した点

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

日本語サジェストの難しいところ

日本語のサジェストをOpenSearch(Elasticsearch)で実装するにあたりいくつか難しい点がありました。

この話の前提として、コネヒトではインデックス作成に使えるデータとして下記を持っています。

  • 検索ログデータ
  • 検索対象のテキストデータ

以後の話はこのデータを使いサジェストを実装する際に、どのような点を意識したかについて話していきます。

①よみがなの考慮

サジェストの実装を考えるに当たり、「赤ちゃん」「妊娠」のような1語として意味をなす入力に対するサジェストは比較的簡単に出来ました。(elastic社のElasticsearchで日本語のサジェストの機能を実装するを参考に実装することでそれなりのベースラインとなるサジェスト機能を作ることが出来ました。良記事に感謝)

ですがそう一筋縄ではいかず、よみがなの部分で苦戦しました。参考実装では、ローマ字入力を考慮し、カナをすべてローマ字にするchar_filterを噛ます実装になっていました。

ママリはスマホアプリなのでローマ字の考慮は不要なのですが、「あかち」「にん」のようなかなの入力途中の語に対して、当然ユーザの検索を補助するためにサジェスト候補を表示する必要があります。

つまり、「赤ちゃん」というワードに対して、「赤ちゃん」「あかちゃん」という2パターンのトークンを持つ必要があります。

後で詳細は述べますが、「あかち」でヒットさせるためにedge_ngramを使いトークンを先頭からn文字という形に分割させることで「赤ちゃん」「あかち」の両方にヒットするような工夫をしています。

また、ユーザの入力途中のワードを分かち書きしてしまうと意図せぬ分割が起こるため、よみがな用のアナライザーを用意する必要があります。(後述)

整理して書くと当たり前だよなって気もするのですが、腑に落ちるまではある程度の時間がかかりました。

②単語の区切り

これはサジェストだけに限った話ではなく日本語の解析全般にいえることなのですが、英語等のスペース区切りで単語が分割される言語と異なり、日本語は単語の区切りが曖昧なためルールベースで単語分割することが難しく、形態素解析が必要になります。

形態素解析することで、単語分割とよみがな振りが出来、トークンとして検索システムで使える形になります。

検索ログ(スペースで単語が区切られた日本語)をデータとして使う場合に、どうトークナイズするのが出したい結果に対してベストなのか色々と試行錯誤しました。

よりよい日本語サジェストのために試行錯誤した点

日本語サジェストの実装にあたっては、先程の紹介した下記のブログが非常に参考になりここで紹介されているマッピング定義をベースに試行錯誤しながらより理想に近づける作業を行いました。

Implementing Japanese autocomplete suggestions in Elasticsearch

ここからは、いくつか理想に近づけるためにチューニングを行った内容を紹介していきます。

これらはまだ本番リリースまではしてないので検証の中で得られた知見の共有という点にご留意ください。

検索ログ活用のために、kuromojiで形態素解析はせずkeywordトークナイザーを使う

既に述べましたが、今回使えるデータとしては下記2つがありました。

  • 検索ログデータ
  • 検索対象のテキストデータ

検索ログの件数をソートの要素に使いたいという理由から今回検索ログデータを利用してサジェストを実装することにしました。

この検索ログデータですが、「つわり△いつから」「保育園△見学」「義実家」のように、単語もしくはスペース区切りのある程度整ったデータが格納されています。

※ちなみに文中の「つわり△いつから」△はスペースを表しています。

また、データパイプラインで全角/半角スペースの正規化とログデータなのでノイズも多いため、しきい値を設けて特定件数以上のワードをデータとして使うことでノイズ除去しています。

最初このデータを、参考実装に則りkuromojiトークナイザを使い分かち書きする手法で検証を進めていました。

そこで、問題にぶち当たります。

これが一番わかりやすい例で、「ほい」という入力が来たらママリだったら「保育園」をサジェストしたいですが、「ほっけ △いつから」がヒットしました。

※チーム内では「ほっけいつから問題」と言われしばらくホットワードになっていました。

この事象、形態素解析に明るい方なら勘づかれるかもしれませんが、search_analyzerに指定したkuromojiが「ほい」を ほ/い にトークン化して検索をかけにいくため「保育園」ではなく「ほっけ△いつから」が候補としてヒットしていました。

中々頭で理解するのが難しいので、自分の中で手書きで分解して何が起きてるのかを理解しようと下記のキャプチャのようなことをいくつか繰り返し理解しました。手で書いて整理すると不思議と理解出来て不思議なものです。

この件でとっかかりを掴み、analyzerの設計方針が固まりました。suggest_analyzer(読みではなく入力ワードに対するサジェスト)では、searchとindexでアナライザーを分けているので、その内容も簡単に解説します。

search_analyzer

search_analyzerの役割はユーザの入力文字列を最低限の正規化だけすることです。入力途中の文字が入ってくることが前提なので、形態素解析はせずkeywordトークナイザーを使ってスペースも1語として扱います。

例えば、「つわり△い」のようなワードが来た時に、そのままの形で検索を行うのが役目。出来るだけそのままの形にするという部分が大事なことに気づいたのが大きな転換点でした。

index_analyzer

index_analyzerの役目は、入力データである検索ログを正規化し、edge_ngramを使って入力途中の文字列にもヒットするようなトークンを転置インデックスとして格納することです。

こちらのトークナイザーも最初はkuromojiに始まり、whitespace、textと試し、結果的には検索ログをそのままの形で格納するのが一番良いという結論になりkeywordトークナイザーを使うことにしました。

具体例がわかりやすいと思うので説明すると、

「つわり△いつから」という入力に対して、それぞれ下記のようにトークン化され転置インデックスとして登録されます。

keywordトークナイザーだと つ/つわ/つわり/つわり△/つわり△い/つわり△いつ/つわり△いつか/つわり△いつから

whitespaceトークナイザーだと つ/つわ/つわり/つわり/い/いつ/いつか/いつから

この場合に、サジェスト観点で検証すると明確な差が出ます。

  • 「つわり」という入力に対してはどちらもヒットする
  • 「つわり△い」という入力に対してはwhitespaceトークナイザーだとヒットしない

サジェストやオートコンプリートと言われる入力補助の機能にとっては、「つわり△い」に対して、「つわり△いつから」「つわり△いつまで」のような補助をしてユーザの検索体験をサポートしていきたいのでkeywordトークナイザーを採用しています。

よみがなで当てるためのアナライザーでは、search_analyzerは同じくkeywordトークナイザーを使い、index_analyzerには、カスタム辞書のくだりでも話したよみがなでのヒットさせる必要があるのでkuromojiトークナイザーを使う形にしました。この当たりの全体像はまた機会があれば書こうと思います。

カスタム辞書にカナを振る

今使っているKuromojiのカスタム辞書は、カナを使う機会がなかったのもありカナ振り作業を後回しにしていました。

ですが、 kuromoji_readingform filterで単語のよみがなを使う必要が出てきたので、カスタム辞書へのカナ振りが必要になりました。

初期のカスタム辞書を作るフェーズでは、よみがなを使わないケースでの導入だったためその時のツケを払う形だったが中々に骨の折れる作業でした。

# before
ママリ公式,ママリ公式,ママリ公式,カスタム名詞
# after
ママリ公式,ママリ公式,ママリコウシキ,カスタム名詞

よみがなを振ったおかげで、「ママリ公式」という単語がこのような形で読みでもヒットするようになりました。つまり「ママリこ」という入力に対して、「ママリ公式」がヒットするようになります。

before: マ/ママ/ママリ/ママリ公/ママリ公式

after: マ/ママ/ママリ/ママリコ/ママリコウ/ママリコウシ/ママリコウシキ

※最終的に、カタカナでトークン化するtoken filterも入れているのでトークンはカタカナに

他にもいくつか試行錯誤した点はあるのですが、それらの紹介はまたの機会に取っておきます。記事にすると意外とあっさりした内容になりますが、1つ1つ動作確認しながらのチューニングになるので時間はかなりかかるしやろうと思えばいくらでもチューニング出来るので、そこがこの分野の面白さだなと実感しています。

プロジェクトとしては、ある程度の性能のサジェストを作ることが出来たのでこれからABテストに向かうところです。良い結果が出ることを願いつつここらで筆を置こうと思います。

この試行錯誤のログが日本語サジェストを実装しようとする方の一助になれば幸いです。

明日は @takapy0210による記事です!お楽しみに。

最後にコネヒトでは一緒に働く仲間を募集しています。

今回のテーマの検索システムだけでなく様々な技術要素でチャレンジ出来る環境があるので、少しでも興味を持っていただけたら気軽にご連絡いただければ幸いです。

www.wantedly.com

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

🎅この記事はコネヒトアドベントカレンダー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年以上経過した

🎅 この記事はコネヒトアドベントカレンダー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の導入

こんにちは!コネヒトで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