トレタ開発者ブログ

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

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

始めに

皆さま、こんにちは!
トレタのサーバサイドエンジニア兼佐久間まゆちゃんのプロデューサーの@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を構築したいと考えています。

トレタ開発組織振り返り 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:誤用かも

© Toreta, Inc.

Powered by Hatena Blog