トレタ開発者ブログ

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

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を構築したいと考えています。

トレタ開発組織振り返り 2019年版

この記事は トレタ Advent Calendar 2019 12日目*1の記事です。

こんにちは。最近、子供に荷物に買い物かばんにとリアルポーターごっこに腰がつらくなってきた@joy04dです。

前回のAdvent Calendarでこんな事を書いていた自分ですが、その後、今年1月から VP of Engineering の役割を頂いております。まだ1年足らずのひよっこですが、日々頑張ってお仕事しております(=ω=)

今回の記事では、せっかくなのでこの1年の振り返りと知見(あるいはアンチパターン)の共有を兼ねて、つらつらと*2書いてみたいと思います。

どんなことしたか

今年のコンセプトを一言でいうと 個からチームへ になります。

トレタの開発組織では、創業期から 自治 をコンセプトとしており、フラットな組織のなかでエンジニアそれぞれが自身の裁量と責任を持って行動することを大事にしていました (この辺りで軽く触れられています)

これは個の力を全面に押し出すアプローチであり、創業期の小規模組織などにおいては理想的に働く一方で、今のトレタのように100人を超える組織規模では、様々な面でデメリットが目立つようになってきていました。対策としてプレイングマネージャー的な人を置いてみたりもしたのですが、皆がゴリゴリと手を動かさなくては行けない状況では、なかなか腰を据えてそちらに力を入れるのも難しく、組織のコンディションも徐々に悪化する形となってしまっていました。

そこで改めて専門職としてのマネージャーを置き、皆が効率的に動ける体制を作ろう、個人の頑張り依存ではなくチームで組織的に課題に向かえる体制を作ろう、と気合を入れたのが今年の流れになります(>∀<)

やったこと

ということで、今年の動きをつらつらと書いてみます。
地味です( ´_ゝ`)


採用編

課題

  • 事業や組織の成長にエンジニアの採用が追いついておらず、常に人手不足
    • ベンチャー企業の必然ではある
  • 即戦力を求めすぎて、間口が狭い。また組織として同質化が進みすぎる
    • 組織の成長には適度な多様さが大事

対策

  • 会える機会を増やす
    • 採用は人と組織のマッチングであり、接触機会が多いほど求める人(あるいは組織)に出会いやすい
      • 巡り合わせ大事
    • 面接フローのスリム化・レイヤー化
      • これまではできる限り全員で判断する方針
        • 面接回数が多く、双方にとっての負荷が大きい。
          • 6回面接したことも
        • 全員が採用に責任を持つ ≒ 誰も責任を持っていない状態になりがち
          • 各々が求めるすべてにマッチする人はそういない
      • これをエンジニアによる技術面接とマネージャーによる組織面接に分割
        • 誰がどの観点に責任を持って見るのかはっきりと
          • それぞれの立場からの擦り合わせも大事に
  • ヒット率を上げる
    • リファラル採用の強化
      • 自分の会社にマッチする人は中の人が一番知っている
      • エンジニアに限らず社員総出で頑張る
  • 自分たちをもっと知ってもらう
    • これも機会が大事

結果

  • エンジニアの人数が倍になった。ヤッタゼ
  • ジョインされた方々もすぐにvalueを発揮、楽しく仕事をしていただいている。ヤッタゼ

反省点

  • 急激に人が増えたために、オンボーディングやコードレビューのコストが大変なことに
    • 裾野が広がるより早く人が増えたために一極集中化
      • 古株の方々、特に @m_nakamura145 の頑張りでどうにか乗り切れたところが大きい。正直タスカッタ
    • 組織の拡大と地盤固めのバランス大事

組織編

課題

  • エンジニアを共有資源的に捉え、あちらこちらのプロダクトで隙間なくタスクをこなす状態
    • キツキツパイプライン問題
      • 人手不足もありタスクが同時進行となることも多いが、人のコアはひとつでスイッチングコスト大
      • 1つのプロダクトの影響が他のすべてに伝搬するため、スケジュールの不確実性大
        • 優先度の判断も難しい
      • 隣の人が何やってるかわからない状態になりがちで、ノウハウの継承がされにくい
    • 傭兵化問題
      • 腰を据えて1つのプロダクトに向き合う時間が取りにくいため、関わりが薄くなりがち
        • 目標(と評価)の軸も定めにくく、どうしても受け身寄りの動きとなる
      • 常に同じ技術領域で呼ばれるため、新たな技術領域に挑戦する機会を作りにくい
      • 継続的な保守・改善や技術的負債の返済に時間を割きにくい
        • 各々の隙間で頑張り対応だが、徐々に追いつかずに

対策

  • マトリクス型組織への移行
  • 構成イメージ
    f:id:joy04d:20191225141431p:plain
    • 縦軸に事業戦略の軸に合わせた開発チーム、横軸に横断的に動く基盤チーム
        • 開発チーム → Toreta nowチーム
        • 基盤チーム → SREチーム
          • ちなみにSREチームは今回新設
            • 攻めの運用を目指す
      • チーム単位でミッションを持つ
        • 縦 or 横 → チームが効率的に動きやすい方向を主軸に
    • 各チームにリーダーを設定
      • チームのミッション達成に責任を持つ
      • ある程度チーム体制が固まるまではマネージャーが兼務で乗り切る
        • 何もないところからいきなりリーダーをやってくれといわれても厳しい
    • 技術的な横断役として各領域ごとにテックリードを設定
      • 技術的なよろずサポート・レビューから中長期的な技術戦略などを担当
  • 事業・組織・個人の3軸の成長に目標を設定
    • 事業 → Issue First
    • 組織 → Respect All
    • 個人 → Dive!
    • に合わせた形。
      • 三方良し
      • 元々の自治の流れを失わないように
        • 人によりアプローチは様々で、特に組織・個人軸はその人次第
          • みんなで幸せになろうよ

結果

  • チームで集中して開発が行えるようになった。スケジュールの確実性も上がった。ヤッタゼ
  • 改善などに向けた主体的なアプローチがしやすくなり、個人・プロダクトともに成長機会が増えた。ヤッタゼ
  • チーム内でノウハウの共有が活発化した。ヤッタゼ
  • テックトークなどの横断的な社内勉強会も活発化。ヤッタゼ
    • 開発者ブログも活発化。ヤッタゼ
      • (AdventCalendar効果だけど)

反省点

  • マネージャー集中問題
    • チームリーダー兼務はチーム体制が固まるまでの繋ぎだったが、早々にオーバーフロー
      • 当初の想定よりもだいぶ早く各チームリーダーにバトンタッチ
        • 割とぶん投げになってしまったが、皆に助けられていい感じになった。正直タスカッタ
      • 人にちゃんと仕事を任せよう
        • 自分のキャパも考えよう
  • チームの柔軟性問題
    • トレタのようなベンチャーでは短い期間で状況が変わることもある
    • その変化に対してチーム構成が固くなりすぎて、運用でカバーなところが出てきてしまっていた
      • チーム間のアサイン問題など
      • バックオフィスのツールとの兼ね合いもある
    • どんな体制も柔軟に運用できる遊びが大事
      • 準備不足・ω・

技術編

課題

  • モノリシックなアーキテクチャ
    • そろそろ分割を考えたい規模感
  • Go入門
    • トレタといえばRubyだが、新しいプロダクトの一部にはGoを採用している
      • 適材適所。今後は2本柱に
    • が、やはり6年の経験があるRubyに比べるとノウハウ不足は否めない

対策

  • テックリード主体で次世代のアーキテクチャを議論
  • Goの技術顧問として @tenntenn さんに来ていただいた
    • 貴重な知見を惜しまず提供いただいており、感謝しかない状態

結果

  • トレタ民が一段上のGopherになりました。ヤッタゼ

反省点

  • 次世代のアーキテクチャについてはアクションまで行けず
    • 来年の目標に・ω・

まとめ

そんなわけで、つらつら書いてみました。

今年一年で色々と大きく変える形となったため、反発もたくさん来ると思っていたのですが、そんな事は全然なく、皆が前向きに行動してくれました。 まだまだ課題もありながらも開発組織として大きく前に踏み出すことができたのは、皆の協力あってこそだと思います。オマエラサイコウダゼ

来年はこのチームの力でより事業を加速していきたいと思います。
そんなトレタに少しでも興味を持っていただいた方がいれば、ぜひ遊びに来てください。 仲間も募集してます(>∀<)

*1:大変遅れて申し訳ない

*2:誤用かも

台帳アプリのカラーリファクタリングをした話

こんにちは。
サンタ業務を控えているパパiOSエンジニアのkentaroです。

今年実施したトレタ iPad台帳のカラーリファクタリング(v35.0にて対応しました)についてご紹介します。

なぜ行ったのか

これは担当デザイナーの言葉をそのまま引用します。

トレタはリリースされてから5年、デザインが大きく変わることはありませんでしたが、機能追加で画面が増えていく過程で、微妙な差の色も含めて120色も使用されていました。
色数が多いと下記のような問題が発生します。

  • プロダクト内の統一感がない
  • どの色を使用すればいいか考えなくてはいけないので、デザイナーの作業工数がかかる

今回は2つ目の業務効率化をメイン目標にリファクタリングしています。

どう変わったか

ホーム画面

キーカラーを少しだけ濃くして白文字の視認性を上げています

f:id:kenkenken_3:20191224155827p:plain

予約フロー画面

背景に埋もれがちだったテキストのコントラストを上げて視認性を上げました
フッターも装飾を少なくし、入力を邪魔しないよう修正しています

f:id:kenkenken_3:20191224155856p:plain

タイムテーブル・テーブルレイアウト

背景に埋もれがちだったテーブルレイアウトのステータスのコントラストがはっきりするよう調整しました

f:id:kenkenken_3:20191224155916p:plain

自分が担当したこと

新しい色の管理方法やソースコード上での利用方法の設計提案、実装の補助(困ったときに相談してもらう)、ソースコードレビューを行いました。

デザイン担当

date001 (去年のアドベントカレンダーにも登場いただきました)感謝!

note.com

去年のアドベントカレンダー

tech.toreta.in

実装担当

実際に手を動かしてくれたのは CSからエンジニアにジョブチェンジしました でおなじみの@yukimura03です。感謝!

tech.toreta.in

QA 担当

三度の飯より寿司が好きでおなじみのQAエンジニアの林です。感謝!

tech.toreta.in

実装について

実装について紹介していきます。

色の定義

Asset Catalogに定義しました。
これによりソースコード上でもIB(Interface Builder)上でも名前をkeyにして同じ色が扱えるようになりました。
ある名前の色を少し調整したい、というときもAsset Catalogを編集するだけですみ、変更にも強くなりました。

ソースコード上で使いやすくする工夫

色名を表す EnumUIColorExtension を用意し、Enumcase を渡して UIColor を取得できるようにしました。

/// Assetsに定義した色を表すEnum
@objc enum ColorPalette: Int {

    case green500
    case green400
    case green300
    case green200
    case green100
    case green50

    // その他の色も定義していく

    // MARK: - Property

    /// Assetsで定義した色名を返す
    ///
    /// ObjcでrawValueが使えないので暫定
    /// トレタで実際に利用している命名とは異なります
    var rawValueString: String {
        switch self {
        case .green500: return "green-500"
        case .green400: return "green-400"
        case .green300: return "green-300"
        case .green200: return "green-200"
        case .green100: return "green-100"
        case .green50:  return "green-50"
        }
    }
}
extension UIColor {

    /// カラーパレットに対応するUIColorを生成する
    ///
    /// - Parameter palette: ColorPalette
    @objc convenience init(_ palette: ColorPalette) {

        // ここで落ちたらColorPaletteかColorSetに定義ミスがある
        self.init(named: palette.rawValueString)!
    }
}

呼び出し

// Swift
let green50 = UIColor(.green50)
// Objective-C
UIColor *green50 = [[UIColor alloc] init:ColorPaletteGreen50];

終わりに

カラーリファクタリングはiOSエンジニアだけではなくデザイナー・QA等様々なロールの仲間と取り組んでおります。
その中で「すでにカッチリ決まった仕様を実装していく」よりも「早い段階から複数職種が議論して作り上げていく」ほうが性に合っていると感じました。

同じような考えをお持ちの方にはトレタと相性がいい可能性高いと思いますので、是非遊びに来てください!
立ち呑みトレタ という交流イベントもやっています。
前回のお知らせはこんな感じです。
次回は1月下旬頃との噂。詳細決まり次第お知らせ出るかと思いますので興味のある方は是非お越しください!

www.wantedly.com

© Toreta, Inc.

Powered by Hatena Blog