コネヒト開発者ブログ

コネヒト開発者ブログ

カーディナリティが低いINDEXのお掃除をしました

こんにちは!サーバーサイドエンジニアをやっている @otukutun です。

最近slow query起因のレイテンシアラートが発生していてRDB(MySQL)が不安定になってしまう事象が発生し、それはカーディナリティが低いINDEXが使われたことが原因で発生していました。今回は、その対応としてカーディナリティが低いINDEXのお掃除を行ったのでそれについて書きたいと思います。

なぜカーディナリティが低いINDEXを削除したのか?

一般的にカーディナリティが低いINDEXの弊害などはいろんな方が言われていますが、

などがあると思っております。詳しくはSQLアンチパターン「12章 インデックスショットガン」をみてみてください。

今回はカーディナリティが低いINDEXを削除した理由ですが、

  • カーディナリティの統計情報がおかしくなっていた。flag的なフィールドで20ほどの値しかないはずだが、数値はその数百倍の7000ほどになっていた
  • そのINDEXがまれに使われて、実態としては検索パフォーマンスをあげないのでslow queryになっていた
  • その結果、MySQLのパフォーマンスが悪化しサービスが不安定になることが稀にあった

などがあります。対処方法ですが、OPTIMIZE TABLEを実行しカーディナリティを更新することも考えましたが、今回はDROP INDEXすることにしました。OPTIMIZE TABLEとDROP INDEXは5.6.17以降はIn Placeで実行されるため実行時の挙動は同じですが、Tableの再構築が行われるかの違いがあります。今回は元々が効果がないINDEXであることはSQLとアプリケーションコードから把握できていたこと、Tableの再構築は必要ないことからDROP INDEXすることにしました。

やったこと

まずは一旦、一次対応としてインデックスヒントを与える対応をしました。その後、DROP INDEXの準備を進めていきました。

前述したようにMySQL5.6.17以降(InnoDB)ではDROP INDEXはオンラインDDL対応でIn Placeで実行されるため、テーブルロックはされません(公式ページより)。ただ、レプリカでのbinlogの反映の影響が遅延することを考慮してアクセスが少ない早朝に作業することにしました。今回はslow queryの原因になっているINDEXと他2つのカーディナリティがとても低いものを合わせた3つのINDEXをDROP対応しました。

その際,以下手順で順次DROP INDEX対応を行いました。

  1. DROP INDEXの実行
  2. AWS上のアラートの確認
  3. 念の為 SHOW SLAVE STATUS でSeconds_Behind_Masterの値を確認

最終的に何も問題なく(replica lagも発生しませんでした)、1時間ほどで作業を終えることができました。

おわりに

slow queryの原因が解消され、無事平穏な生活が戻ってきました。(ただし、INSERTクエリの改善は前後比較だと明らかな改善は見られませんでした)

今回はslow queryを発生させているINDEXのDROP対応をしました。他にも効果的でないINDEXが行われている箇所が見つかったので削除していけたらと思います。INDEXはRDBを扱う上で便利な機能ですが、無駄なINDEXを張ってしまうことでの弊害もあります。用法要領を守って正しくお使いくださいませ。

チームを異動して成果を出すため取り組んだこと

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

こんにちは!コネヒト歴1年3ヶ月のWebエンジニアの古市(@takfjp)です。今年になってから入社して初めてチームを移る経験をしたのですが、その時に「はじめの一歩」として自分から取り組んだことを書き残したいと思います

入社して初めての異動

今年の7月に新CMSを制作するチームから、ママリユーザー向けのキャンペーンサービスを開発するチームに異動しました。

チームが変わるとKPIや触るリポジトリが変わるのはもちろんなのですが、スクラムイベントの内容や、カンバンの運用方法なども変わってきます。

また、求められるタスクへのコミットメント内容も大きく異なる部分が発生します。そういった状況の中で、新しいチームのメンバーとの信頼関係の構築や、チームが扱うタスクや問題にどうキャッチアップしていったかを振り返りたいと思います。

すぐに取り組めるIssueに取り掛かる

現在のチームに異動して初めて取り組んだのがGAS(Google Apos Script)の改修でした。異動したタイミングで新たにGASを作成する必要があり、以前のチームではフロントエンド開発でTypeScript(JavaScript)を書く時間が多かったため「このIssueなら自分でもすぐに携われそう」と思い、最初のプランニングの時間で手を挙げてすぐ取り掛かりました。

個人的な肌感覚ですが、新しいリポジトリのIssueにすぐ取り掛かろうとすると、ディレクトリの構成や技術スタックが異なるためキャッチアップだけで時間がかかってしまい、元々所属しているメンバーに比べてどうしてもIssueの解決に時間がかかってしまいます。その点、GASの作成であればサービスのビジネスモデルへの理解が途中の段階でも、自分が得意とするJSの知識をすぐ活かしてコミットできるという自負がありました。

自分の見通し通り、GASの作成タスクは異動後の初めてのスプリントで完成させることができ、メンバーからポジティブなフィードバックを多くもらうことができました。

わからないことをメモにして公開する

異動後のチームのスクラムイベントで、リファインメントに営業 / マーケ / PdM / エンジニアと、異なる職種のメンバーが一体となって参加しています。その中でKPIや売上目標の数値などの共有が行われるのですが、あまり耳にしたことがないマーケティング用語や、Google系マーケティングツールの略称が多く飛び交うため最初は内容を理解するのに苦心しました。

そこで、現時点で「自分はここがわからない」「調べて理解した」というのを開示したいと思い、メモ代わりにNotion*1を用いてチーム内でよく使われる用語集を個人的に作成しました。

リファインメントや数値説明があるタイミングで毎回開き、「今日は新しい単語が出てきた」「これは前回聞いたけどまだ調べてなかったな」など確認しつつ、追記していくことでビジネスモデルへの理解度を深めるのに役立ちました。また、作成した用語集を全体に公開することで、より詳しいメンバーからのフォローが入ることもあり、前のめりな姿勢を示すことができ取り組んでよかったなと思えました。

モブプロで一緒にタスクを進める

チームを異動したタイミングで、前回自分が携わったタスクを他の現チームのメンバーにお願いする場面がありました。普段はあまり使わないリポジトリでの作業だったのですが、まだ自分の記憶が鮮明だったため、担当するメンバーとまずペアプロ形式でセットアップなどから始めていきました。Slackのハドル機能が充実し、画面共有やミーティング上のスレッドをフロー情報として残すこともできようになったため、今でもペアプロやリアルタイムのコードレビューで活用しています。

モブプロに関しては自発的に始めたというより、所属メンバーが新メンバーのひとりである私に対して、今後のタスクを円滑に進められるよう機会を設けてくれました。最初はPHPの各Controllerの役割やModelの説明、バッチの動かし方の解説から始まり、エンジニア全員で順を追いながら、改修箇所にコードを追加していきつつタスクを完遂させる方式で行いました。

この時の体験がよかったため、最近はチーム内でのフロントエンドの開発が比率的にも多くなってきたこともあり、自分から知識をお裾分けできるよう他のメンバーを巻き込んでモブプロでReactを書いています。

新しいチームでの信頼関係の築き方

そういえば、ここまで書いてみて「信頼関係をどう築いたか」ということにあまり触れてきませんでした。その理由として、元々コネヒトでは時間がある社員が有志でZoom上に集まって行う朝会や、新メンバーとの親睦を深めるためのシャッフルランチ、コネヒトのビジョン*2を少し広い視点で考える「コネヒトワークショップ」など、社内メンバーが活発に交流し合うイベントが不定期的に実施されています。

そのおかげで、チームを移った時点で「全く話したことがない人」がいない状態でした。そのため、自分自身も「他のメンバーのことをある程度知っている」という状態から出発し、元々の所属メンバーからも名前と顔をあらかじめ知ってもらえていることから、上記のような取り組みを行うことでさらに信頼度・親密度が共に増したのかなと個人的に考えています。

新しいチームに参加してすぐやると良いこと

私が行った3つの取り組みとその効果を1段階抽象化すると、

  • 自分が得意・出来ると思うことが見つかったら進んで取り組む
    • 適度なサイズですぐ着手でき、他のメンバーが気にしていることを率先してやれるとベター
  • 自分がわからないこと・調べてわかったことを開示する
    • 最初はわからないことが多く尻込みしたり、パフォーマンスが低下して自分のモチベーションを保つのが難しい場面もあるが、それを逆手に取り成長していく姿勢を示す
  • 自分が持っている知識・スキルをチームに還元する
    • 自己開示がなによりも大事。 自分が得意なことでソロプレーに走るより、全体に還元することでチームそのものが前進できる

こういった内容になるかと思います。新しいチーム・現場での自分の動き方に悩んでいる方は是非実践してみてください。

来年に向けて

来年は逆に、自分が受け入れる側になる場面を想定して、以下のことを事前に用意していきたいと思います。

  • リポジトリや開発環境構築のドキュメントを更新
    • 古くなっている情報を頼ると時間が吸われるので、クイックスタートができるようにする
  • Good First Issueの整備
    • 日々の開発の中で「やりたいけど時間がない」という理由で敬遠しているIssueの中で、重要度が相対的に低く、すぐ取り掛かってもらえそうなものをお願いすることでチーム内での成功体験を積んでもらう
  • 通常タスクはまずモブプロから始める
    • チーム内での会話量を増やしながら孤立せず効率的にタスクを進められる場を設け、信頼関係をハイペースで構築していく

2023年はどんな新しい出会いが待っているのかワクワクしながらこの記事を終えたいと思います。読んでいただきありがとうございました!

*1:コネヒトでのNotion活用についてはこちらの記事をご覧ください。 https://tech.connehito.com/entry/2022/12/07/182847

*2:コネヒトのビジョンについてはこちらのコーポレートサイトをご覧ください.

私たちについて | コネヒト株式会社

脱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:定例呼ぶのが好きでなく的をつけてます