トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、超直前予約アプリ「トレタnow」を開発・提供するスタートアップ企業です。

サービス開発で高速全文検索APIのAlgoliaを使用した際の処理フローと感じたAlgoliaの特徴

はじめに

皆様、こんにちは!
『あつまれ どうぶつの森』でゴリラの住民ばかりが島に集まるトレタのサーバサイドエンジニア兼佐久間まゆちゃんのプロデューサーの@hiroki_tanakaです。
現在、私が携わっているプロダクトでAlgoliaという高速検索APIを使用しています。 今回はAlgoliaとは何か?から実際に使用してみて感じたことをご紹介します!

そもそもAlgoliaとは?

  • 高速な全文検索APIサービスのSaaS。
  • 一番の売りは検索速度の圧倒的な速さ。
    • 公式が出しているデモサイトもあり、試してみることが可能です。
  • Algolia内にJSON 形式でデータを保持し、その中で検索を行います。
    • 検索可能にする属性や検索順の重み付け設定はGUIから柔軟に行うことが出来ます。
  • RubyPHP Java Go Scale Swiftなどの様々な言語向けにAPIを提供しています。
  • Algoliaは登録したレコード数及び検索APIの実行アクセス回数での従量課金制。
    • 1万レコード・10万APIアクセスまでは無料で使用することができます。
  • 既存のサービスではTwitchやStripeで使用されています。
  • 余談ですが、Googleが提供しているBaaS:Firebaseでは『検索を実現したい場合はAlgoliaを併用すべし』という記載があります。これはFirestoreに検索のAPI機能がなく、コレクション全体をクライアント側に保持し、強引にフロントエンドで検索するというのは現実的ではないためです。

用語解説

Algoliaは一般的なRDBとは若干異なる用語でデータを扱います。

  • Index:RDBでいうテーブル。データレコードの集合でデータの大本です。
  • Attribute:RDBでいうカラム。AlgoliaはKey/Valueでデータを保存します。

処理フローとサンプルコード

プロダクトはiOSアプリでフロントエンドはSwift・バックエンドはFirebaseでサーバレスとし、検索をAlgoliaが行う構成としました。
また、必要なテーブルが1つしかないことから、RDBを持たずにデータを全てAlgoliaに集約しました。

検索処理のフローとしては、以下のようになります。

  1. Algoliaに必要なIndexを作成し、JSON形式のデータを登録する。
  2. SwiftからAlgoliaのSearch APIを呼出、Algoliaから検索結果のJSONデータを返却する。
  3. 検索結果を画面に描画する。

以下がSwiftを用いてAlgolia上のIndexからデータを取得するサンプルコードになります。
今回はサンプルとしてIndex:moviesがあり、Attribute:titleを検索可能設定しているとします。

/// 使用するAlgoliaのアプリケーションIDとAPIキーを指定
private let appId = "application_ID"
private let apiKey = "API_KEY"

/// Algoliaクライアントを作成
let client = Client(appID: appId, apiKey: apiKey)
/// 検索対象のIndexを指定
let index = client.index(withName: "movies")
/// 検索クエリの作成
let query = Query(query: "すみっコぐらし")

/// Algoliaへの検索処理実行
index.search(query, completionHandler: { (content, error) -> Void in
  if error == nil {
      print("Result: \(content!)")
  }
})

Algoliaの検索時に特徴的な箇所

  • 検索時にTypoを許容するように設定できる点

Algoliaは検索ワードのTypoを許容し、検索ワードに近い単語を取得するようにデフォルト設定ではなっています。
そのため、先程のすみっコぐらしを検索したいと思った場合、すもっコぐらしすみっコくらしで検索した場合でも検索結果に含まれます。
ただし、2箇所以上のTypoが含まれている場合は、Algoliaは結果を返しません。
Typo許容の設定をオフにして、Typoなしで一致するレコードのみが取得する場合は、typoToleranceというオプションをfalseにすれば解決します。

query.typoTolerance = .false
  • 単数形・複数形の区別を無視できる点

単数形・複数形を無視して、同等の単語としてAlgolia上では扱われるような設定がデフォルトで有効になっています。
そのため、複数形で検索した場合も単数形の単語が検索結果としてヒットしてしまいます。
例:carsで検索した場合、carもヒットします。
単数形・複数形の区別を有効にするためには、下記のようにignorePluralsというオプションをfalseにすれば解決します。

index.setSettings([
  "queryLanguages": ["en"],   /// 設定対象の言語を指定。enは英語。
  "ignorePlurals": false
])
  • 検索ワード自体に一致しなくても、検索ワードを分解した文字を全て含んでいるレコードを検索結果に含める点

Algoliaは検索ワードを文字に分解して、例え検索ワード自体が含まれていなくても分解した文字を全て含んでいるレコードがある場合、検索結果に含めてしまいます。
例:くらしという検索ワードの場合、 の全ての文字が含まれているクラフト紙(くらふとし)などもヒットしてしまいます。
この設定を無効化しようと試してみたのですが、Algoliaの検索設定やクエリへの追加条件ではこれを回避することは出来ませんでした。。。
最終的に、Algoliaから検索結果を取得した後に改めてSwift側で検索ワードとの一致をチェックするフィルター処理を入れるように致しました。
(有効な回避策を知っている方は教えて頂けるととても嬉しいです(´>ω<`) )

終わりに

Algoliaを使用することでSQLを記載することなく、高速な検索処理が作成でき、プログラムからのAPIの操作も非常に使いやすくとても便利でした。
また、導入障壁も低いのでアプリケーションのプロトタイプ作成やクイックスタートには非常に向いていると思います。
ただ、RDBほど柔軟に検索クエリを書くことが出来ないことが少しつらいなーとは感じました。

終わりの終わりに

トレタに少しでも興味を持っていただいた方がいれば、ぜひ遊びに来てくださいヽ(*´∀`)/
仲間も募集しています!

トレタのコードレビューへの取組

始めに

皆さま、こんにちは!
トレタのサーバサイドエンジニア兼佐久間まゆちゃんのプロデューサーの@hiroki_tanakaです。
先日、コードレビューに関する議論が社内で巻き起こり、その時話に上がった内容や実際にトレタで行っているコードレビューの取組に関してご紹介します!

コードレビューの目的

そもそも何故、コードレビューが必要なのでしょうか。
前提としてシステム開発は何もしないと下の”あるある”現象に苛まれます。(身に覚えのある人が多いのではないでしょうか。)

  • コピペの横行
  • 動けば良しのコードの乱立
  • //TODO:後で直す と書かれているコードの散乱
  • 単一責任の原則を無視した巨大クラス・メソッドの発生

ソースコードは継続的にメンテナンスをしないと品質は低下し続けます。
コード品質が低下している状態では、訳の分からないコードや処理を追うのが困難なコードが壁となってちょっとした機能追加や修正がとても困難になります。
そうなると、開発速度の鈍化と既存機能での保守コスト増大でビジネスとして大きな痛手となります。
そのため、コードレビューの目的はチーム全員でシステムのコードの品質を上げることです。大切なのはチーム内の誰か一人の力で行うのではなく、チーム全員で立ち向かおうということです。
(「そんなの当たり前じゃん」と思う人が多いかも知れませんが、チームとしてコードに当たっていくというは意外と盲点なように思います。)

コードレビューでやってはいけないこと

コードレビューでやっていけないことはそれほど多くはありません。ですが、これらはやってしまうと個人間の仲間割れからチームに亀裂が入るかも知れません。

  1. 個人攻撃や人格否定を行う。
  2. 強い言葉を使う。
  3. 感情(特に怒り)でレビューする。
  4. 主観による粗探しをする。

まず1〜3に関して、大前提ですがコードレビューは個人攻撃の場ではありません。
上述した通り、コードレビューの目的はチーム全員でシステムのコードの品質を上げることです。
そのため、強い言葉で個人攻撃のような指摘をするのは意味がありません(例:「こんなクソコードを書くなんてあり得ない」「(キレ気味に)なんでこんなことも知らないの」など)。
強い言葉を使った議論やコードからの個人攻撃をしても良いシステムは出来ません。コードの品質も向上しません。
それどころか人格攻撃された結果、モチベーション低下で書いたコードが将来の負債になる可能性やレビュアーとレビュイーの関係悪化でプロジェクトが進まなくなる可能性を考えると、百害あって一利無しです。
(そして、レビュアーはパワハラで訴えられる可能性もあります。)

4の「主観による粗探しをする」ですが、良くないコードを改善するのが目的なので指摘は必要ですが、指摘に主観を入れてはいけません。

NGな例
「XXXの処理が読みにくく、良くありません。」

「RSpecが…」

どうでしょう、これらレビューは「読みにくい」や「書き方が良くない」は完全に主観なため、具体的にコードをどのように修正すればよいか分かりません。
レビューは客観的根拠に基づいて行う必要があります。
客観的根拠とはチーム内のコーディングルールや過去のエンジニアリング哲学(『リーダブルコード』に載っているようなこと)を指します。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

  • 作者:Dustin Boswell,Trevor Foucher
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本(ソフトカバー)

それを踏まえて、先程のNGな例を修正してみます。

OKな例
「XXXな処理がネストが深くなってしまっています。また、同じような処理のYYYとZZZがあり、DRYじゃないコードになっています><
XXXの処理は下記のURLを参考にするとネストが浅くなって、メンテナンスしやすくなると思います!YYYとZZZは〇〇Utilクラスに切り出し、共通化することを検討してみてくださいm(_ _)m  参考URL:http://~~」

「CIでRSpecが失敗しています。修正後に再度、レビュー依頼をお願いします。」

このように記載すれば具体的にコードの修正方法やレビュアーが何を根拠に指摘しているのがわかりやすいため、レビュイー側も納得感を持って、修正に入れます。
このようにコードレビュー時にやってはいけないことは4点と多くなく、どれも当たり前のことですが、どれも大切でしっかり意識していく必要があると思います。
(詰まるところ、自分がされて嫌なことを相手にしないという相手を思いやる気持ちです。システムの仕事をしているのに、一番大切なのは人なんですよね。)

コードレビュー時に心掛けること

レビュイー編

まず、レビュイーがコードレビュー時に最も気をつけることは、下記を明記することです。

  • PullRequestにソースコードの変更の理由・何故必要なのか。(Why)
  • 具体的にソースコードの何を変更したのか。(What)
    (Viewの改修ならば、Before/Afterで画面がどのように変化したのか。)

当たり前ですが、発行したPullRequestの背景・仕様・実装に一番詳しいのはレビュイーです。
そのため、レビュイーはPullRequestを数年後に自分を含む誰かに読まれても、正しく意図が伝わるようにすべての情報が含まれているように書くのが理想です。
タイトルの付け方も読んだだけで、PullRequestでどのような変更をしているのかパッとわかると良いですね。

また、レビュイーは「レビュアーに直してもらおう」や「良くない点はレビュアーが気づいてくれるだろう」という考えは捨てた方が良いです。
レビュイーが明らかな仕様ミスや設計ミスをPullRequest発行段階で発生させてしまうとすれば、タスクの進め方が間違っているか有識者との相談不足が原因かと思います。 そのため、レビュイーは常に「考え抜いて不足はない、テストも完璧だ。」という状態で初めてPullRequestを作成するのがベストだと思っています。
(私は「レビューで上げられる点数のMAXは20点であって、PullRequest時点で80点ないと100点にならない。」と昔、先輩社員に教わりました。)

レビュアー編

1. 読んでみてよくわからないと思った部分を質問してみる・読んで感じたことを率直に聞いてみる

1つ目は、『読んでみてよくわからないと思った部分を質問してみる・読んで感じたことを率直に聞いてみる』です。
まず、この観点のレビューなら熟練者だけでなく、初心者でも出来ます。初心者でも読んでみてよくわからないと思った箇所は、大体怪しい挙動をするかバグが潜んでいます。
(個人的には、初心者が読んでわからないということはシンプルなコードになっていないということだと思っています。)
また、質問的に聞くことによって、バグを聞かれた側が発見することが多いです。
そしてプラスアルファ、初心者はPullRequestのレビュアーを通じて、コードを読むようになりコーディング知識やFWへの理解も深まります。良いこと尽くしですね。

2. こんなこと言ったら細かい・神経質って思われるかな…という恐怖を捨てる

2つ目は『こんなこと言ったら細かい・神経質って思われるかな…という恐怖を捨てる』ことです。
良くないコードのスタイルを放置しておくと他の人がそのコードを見た際に「このコードでも許されるなら、多少雑なコードを書いても大丈夫だろう」という気持ちになり、どんどん良くないコードが量産されていきます。(『割れ窓理論』:「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」という考え方。)
そのため、コードスタイルの改善は細かいことでも出来るだけ気づいた際に指摘してあげるのが良いです。もし細かいことを言いたいけど角が立ちそうと[NITS] (NITPICK)や[IMO] (In my opinion)と付けてあげればよいかと思います。

3. テストで行ったことの確認

3つ目は『テストで行ったことの確認』です。
そもそもテストコード(Viewの修正だけならば画面打鍵)の結果のエビデンスがPullRequestになければ、「テスト書いて」と言いましょう。
よく緊急度の高い改修は開発者のローカル環境での打鍵確認のみでテストコードは後追いで書くとなりがちですが、本当に後追いでテストが書かれたケースは稀です。その後一生書かれないです。
その上でテストを行った形跡があれば、私は以下のことを確認します。

  • 正常系は仕様を満たしているか。
  • 境界値チェックが行われているか。
  • 異常系のテストが行われ、エラーが出ることを確認しているか。

特に異常系のテストは忘れられがちなのですが、大体これが抜けてて予期せぬ不具合が発生します。正常系と同等に大事なテストケースだと思っています。

4. コードに問題がないかの確認

4つ目はコードレビューで最もポピュラーな『コードに問題がないかの確認』です。
箇条書きになりますが、下記のような観点のことを指します。

  • PullRequestの修正によって、意図せず他のコードに影響を出していないか。
  • Classやメソッドは肥大化していないか。
  • 単一責任の原則に則った単位で切り出しが行われているか。
  • 各Classは期待される役割通りのコードしか存在していないか。(本来、Modelが持つべきロジックがControllerに書かれていないか等)
  • 変数のスコープは適切で、グローバル変数やクラス変数がないか。
  • if文やfor文でのネストが異常に深くなっていないか。
  • 変数名やメソッド名は意味がわかりやすい名前になっているか。
  • コメントやrdoc・ydocが正しく記載されているか、記載漏れはないか。
  • エラーハンドリングは行われているか、無闇に握りつぶされていないか。
  • ログは適切な位置で出力されているか。

コードの問題への観点はやはり経験によって左右されやすいかと思いますが、初学者でも『リーダブルコード』や『プリンシプルオブプログラミング』に載っているDRYやSOLID原則・YAGNIなどこれまでの先人たちの知恵を借りることである程度、指摘できるかと思います。

5. 積極的にLGTMしよう

5つ目は、『積極的にLGTMしよう』です。
良いPullRequestやコードレビュー指摘にしっかり対応したPullRequestにはLGTM!で褒めましょう!
私はLGTMoonというサイトで良く画像を取得しています。(やっぱり、LGTM貰えると嬉しいですよね!)

f:id:hiroki_tanaka:20200207175903p:plain

トレタで実際に行っているコードレビューのやり方

それでは実際にトレタで行っているコードレビューのやり方についてです。
現在、社内で一番大きいAPIリポジトリに対して、サーバサイドチームの人がコードレビューをする時は以下のようなルールに則って行っています。

  • エンジニア8人で2人ペアを4チーム作る。
  • Aチームの人はBチームの2人にPullRequestのレビュワーを依頼する。
  • Bチームの人はCチームの2人にPullRequestのレビュワーを依頼する。
  • Cチームの人はDチームの2人にPullRequestのレビュワーを依頼する。
  • Dチームの人はAチームの2人にPullRequestのレビュワーを依頼する。

二人組みの組み合わせは「レビューに慣れているベテランやエースと新規参加メンバやレビューに不慣れな人」として、各チームのスキル・知識差やレビュー密度の偏りを防ぎ、均一化することを狙っています。

この相互レビュー制が導入される前は全てのPullRequestにベテランやエースエンジニアがレビュアーとしてアサインされるという方法が取られていましたが、開発チームの人数が増えるにつれて、レビュアーの負担が増加していったため限界を迎えました。
スタートアップの初期段階ではエースが全てのコードを確認するといった状態でも良いかと思います。
短いサイクルでシステムをリリースすることの優先度が高いことやシステム規模が小さいのでレビュー負荷がそこまで大きくないためです。
しかし、ある程度成熟したベンチャーや中〜大規模プロジェクトではこのような相互レビュー制が良いかと思います。(というか、そうしないと破綻する恐れがあります。)

この相互レビュー制となって思うことはアプリケーションやFW全体への理解の深まりとコードリーディングの重要性の再認識です。
私は普段、サブシステムの一部を担当しているのですが、担当領域外のAPIやFWのPullRequestを読むことによって、アプリケーション全体への知識のストックが増えます。
この知識のストックがじわじわと効いてきて、自身の担当領域でも「FWが提供している機能を使えば簡単にできるようになる」や「このロジックはアプリケーション全体で共通化した方が良いと思うけど、どこに書けば良いんだろう?」と考えられるようになりました。
また、コードリーディングの回数が増えたことによって、疑問に思う→ググる→理解するor質問するをいうサイクルが回るようになりました。
レビュアーではなかった頃は、疑問に思っても「動いているから良し!」で済ませることが多かったのですが、現在はコード一行一行を咀嚼し理解することでエンジニアとして少しずつレベルアップしていることを感じ、コードリーディングの重要性を再認識しました。

終わりに

ここまでつらつらとコードレビューに関して色々書いてきましたが、
コードレビューの本質はおそらく下記の言葉に詰まって、チームメンバ全員がこの言葉のように行動できたら心理的安全性の高い素晴らしいチームとなってコードレビューが楽しいものになると思っています。

わからないな。君はどう思う?
間違いや能力不足を見せることは弱さではない。
他人の意見を信頼すること。その正直さと強さによって、
みんなが尊敬してくれる。
~『Team Geek』~

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

終わりの終わりに

トレタに少しでも興味を持っていただいた方がいれば、ぜひ遊びに来てくださいヽ(゚∀゚)ノ ワーワー
仲間も募集しています!

Engineering Onboardingの設計

SREチームの中村です。2019年は弊社のエンジニア採用はありがたいことに好調で、たくさんのエンジニアに入社していただきました。2018年比で人数としては2倍近くになっています。

2019年のエンジニア採用戦略についてはVP of Engineeringによる以下の記事に詳しく載っていますのでぜひ御覧ください。

tech.toreta.in

一緒にプロダクトを前に進める仲間が増えることは非常に嬉しいことです。しかし、新規メンバーを迎える側である我々が考えておくべき点がいくつかあります。

新しいエンジニアを迎えるときに考えておくこと

弊社が提供するプロダクト群はバーティカルSaaSです。バーティカルSaaSとしてのトレタについては、弊社代表の以下の記事に詳しく載っていますので、詳細はそちらを御覧ください。

note.com

バーティカルSaaSは特定の産業の課題に深くフォーカスしなければなりません。弊社の場合では、プロダクトを開発するエンジニアは「外食」という産業の構造理解が必須です。

よって、コードに書かれていること以外の部分で知っておかなければならない知識がたくさんあります。そのため、我々が作っているプロダクトの背景知識や存在意義、構築されているシステムの情報を整理しなければなりません。

具体的にプロダクト・システム観点から整理する情報を考えてみます。

個々のプロダクトがどのような課題を解決しているか?

「予約台帳」というプロダクトと「トレタNow」というプロダクトが解決している課題はそれぞれ異なります。新規メンバーに対して、個々のプロダクトが解決している課題について最初にインプットしてもらうことで、実際のプロダクトコードが「どんなユーザのどの課題を解決しているのか」について、具体的にイメージできるようになります。

プロダクト群がどのように連携しているか?

弊社は「課題解決を積み重ねた」プロダクト開発を行っています。つまり、「予約台帳」というプロダクトを基盤として、「トレタCC」や「トレタNow」というプロダクトが連携してさらなる価値を生むという戦略です。

これは、裏側ではプロダクトを構築するシステムやデータが相互に連携していることを意味します。よって新規メンバーに、「プロダクト間の連携方法はどうなっているか」、「データの流れはどうなっているか」を把握してもらう必要があります。

サービスの契約フロー

弊社のサービス契約フローでは、お客様がサービス契約となってから実際に飲食店で利用開始していただくまでにいくつかのステップが存在します。

例えばトレタの「アカウント発行」の業務は社内で行うので、それらはどのチームがどのような作業を実施しているのかについて社内向け管理画面を用いて理解する必要があります。社内向け管理画面は社内のほぼすべての人が利用する大事なアプリケーションで、この社内業務理解はSaaSアプリケーション開発者にとって非常に重要です。社内業務を改善することによって、お客様へのサービスのデリバリー時間を短縮することができます。

プロダクトごとのリクエストの質やピークタイム

主にSRE向けですが、各プロダクトが解決している課題や想定ユーザなどの情報をインプットしておくと、それぞれのリクエストの質やバッチの処理時間などがおおよそイメージできるようになります。

  • 「法人数」や「店舗数」、「予約数」などのコアとなるデータのサイズ
  • 毎日12時と18時周辺に予約確認する店舗が多いため、リクエストが多くなる
  • 定期バッチ群がどんな処理を行っているか。キューイングされるジョブ数はどれくらいか

などの情報が該当します。

入社してから最初のPull Requestを作るまでの時間を短くする

これは一番わかりやすいと思います。各プロダクトコード内の開発環境やテストデータ、CIが継続的にメンテナンスされていると、新規メンバーもスムーズに開発に入れますし、モチベーションが高いまま最初のPull Requestを作ることができます。まずプロダクトにcommitしてもらい、達成感を感じてもらうのも大事だと思います。

Engineering Onboardingの設計

上記に考えたことを片手間で教えるのは難しい規模の組織になってきたので、情報を整理し、体系的にインプットする場を作る必要がありました。

そこで、今年から入社していただいた全エンジニアを対象に、Engineering Onboardingを実施するようにしました。具体的な施策としては以下を行いました。

プロダクト・技術スタック構成図の作成

f:id:m_nakamura145:20191226171229p:plain

まず最初に、個々のプロダクトの説明と、プロダクト群がどのように相互に接続されているかを表現したドキュメントを作成しました。このドキュメントは社内esaのトップページからリンクしてもらい、新規メンバーが必ず見る記事として育てることを目標にしました。

あえてプロダクトの詳細説明を書かずに「どんな課題を解決しているのか」のみを述べるようにしています。プロダクトの詳細な説明の記事や、プロダクトのURL、GitHubリポジトリへのリンクを乗せることで、「この記事から最低限全サービスの情報へアクセス可能」な状態を継続的に維持することを目指します。

開発・本番環境アクセス権限・各種SaaSアカウント発行整理

現在SREチーム主導で、開発チームで利用しているSaaSアカウントの権限管理やプランの整理を行っています。メインのプラットフォームとして使っているAWSは以下の記事によってAWS SSOが使えるようになったので、管理がとても簡単になりました。

tech.toreta.in

まだ手動でinvitationを行う必要があるBugsnagやNew RelicなどのSaaSは、「社内の誰に問い合わせるのか」を整理しました。

アプリケーションコードやDBのリファクタリング

使われていないコードやDBのカラムは存在するだけで認知負荷が高まるので、可能な限り削除しました。また、DBの各カラムに「なんのためのデータ」なのかコメントを追加し、理解するための情報量を増やしました。

開発環境の整備

GitHubリポジトリのREADMEを読んで、そのままコマンドを実行すれば開発がすぐ可能になるようにdocker-composeやCIの整備を行いました。

Onboarding TODOリストの作成

この記事を読んで書いてある通りに進めればセットアップが完了します。と言えるようなドキュメントを作成しました。タスクリスト形式になっており、記事をコピーして自分で埋めていく形です。

  1. よく使うslackのチャンネルに入ってもらう
  2. 発行するSaaSアカウントの依頼
  3. プロダクト・技術スタック構成図への案内
  4. 開発環境の構築
  5. 開発用トレタアカウントの作成
  6. staging・productionのサーバ情報確認

Onboarding Process

今までは新規メンバーの入社時オリエンテーションが終わったあと、開発チームのメンバーがメンターになり一緒にセットアップを進めていたのですが、現在は以下のフローが確立してきました。

  1. 入社時オリエンテーション終了
  2. Onboarding TODOの記事をコピーし、タスクリストを埋めていく
  3. Engineering Onboardingへの参加

3ステップ目の「Engineering Onboarding」ですが、上記で作成したプロダクト・技術スタック構成図を使いながら、私から新規メンバーに対して全体的なプロダクト群に関する情報をインプットしてもらう会を行っています。

1時間 * 5回ほどに分けて、チームやプロダクト・システム構成について理解してもらいます。現在は私以外のメンバーも説明側と参加してもらっているので、一人あたりの負担はかなり軽減してきました。

まとめ

プロダクトが継続的に開発され歴史が積み重なってくると、コードを読んだり単純なドキュメントだけでは理解できない部分も多くなってきます。組織の面で見ても、人の入れ替わりがあったりすると、口頭で伝えられてきた歴史的経緯もどこかの時点失われてしまいます。

そのため、ある一定以上成長したスタートアップでは、Engineering Onboardingを整備して体系的なプロダクトについての説明を継続的に行っていくことが、安定して開発するために必要です。

今回の記事執筆時点では情報を整理しやすい部分から手を付けていきました。今後はさらにセットアップの自動化や各チームの自律性を高めて、スケールしやすいOnboardingを構築したいと考えています。

© Toreta, Inc.

Powered by Hatena Blog