Tebiki社のエンジニアリング組織【2024年3月版】

※この記事は 2024年03月07日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。

これまで全く外部公開してきていませんでしたが、ここ1年くらいで Tebiki 社のエンジニアリング組織がかなり整ってきたということもあり、現時点でどういった状態かを軽くまとめてみたいと思います。

( 渋谷 @shibukk

顧客の課題を解決できる技術スタックの選択

Tebiki 社では tebiki 現場教育tebiki 現場分析という2つのプロダクトを開発していますが、解決すべき顧客の課題は、プロダクトごと、機能ごとに異なります。 私たちは、その課題に合わせて最適な技術スタックを選択するよう心がけています。

詳しくはこちらの記事にてまとめています。

技術スタック概要技術スタック概要

スクラムチームがオーナーシップを発揮できる組織設計

現在エンジニアだけでも20名以上いる組織になりましたが、その規模であっても、スクラムチームがアジャイルにフィードバックサイクルを回し続けられるような組織設計にしています。 Enabling Team / Platform Team / Engineering Manager / QA Engineer / CRE といった専門領域を持った人たちがスクラムチームのサイクルを支えるような形です。

Scrum Teamを中心としたサイクルScrum Teamを中心としたサイクル

これにより意思決定がスクラムチームに閉じるようになり、チーム自身がオーナーシップを発揮できるようになっています。 ※一部スクラムではないXPっぽいチームも存在します

アジャイルの価値観を大事にしたスクラム

Tebiki 社のスクラムはまだまだ守破離の守のフェーズですが、スクラムのルールにこだわるよりもアジャイルの価値観を大事にしています。

詳しくは以下のスライドにてまとめています。

speakerdeck.com

スクラムチーム自身による継続的なアーキテクチャ改善

Rails や React、 Go などは最新のバージョンとなっているのですが、専任のチームがいるわけではなく、スクラムチーム自身の判断で追随しています。 それだけでなく Vite の導入や VueUse / react-use の積極的な活用、クリーンアーキテクチャの思想に基づいた Go のコード基盤リファクタリングなどもチームの判断で行動しており、継続的な改善への意識が組織に根付いていると感じています。

その活動をより積極的にできるよう、20%ルールを取り入れているチームもあります。

フロー効率を高めるペアプロ・モブプロの推進

Tebiki 社では顧客により早く価値を提供しフィードバックを得るために、フロー効率を重視しています。 そして、いくつかのチームでフロー効率を高めるために、ほぼペアプロ・モブプロによる開発を行っています。

詳しい雰囲気(?)は以下の動画をご覧ください。

www.youtube.com

スクラムチームがコントロールできるインフラ環境

最近では当たり前かもしれませんが、インフラはすべて Terraform で管理され、変更は GitHub の Pull Request だけでできるようになっています。

またアプリケーションコードのリリースは ecspresso で行えるようになっていて、これはよりアプリケーションに近いところで作業できるように、という意図での技術選定となっています。

Four Keysのより柔軟な計測と改善

もともと LinearB というサービスを使って Four Keys を可視化していましたが、土日の扱いや前述の20%ルールなどチームごとに計測したいものがでてきたため、より柔軟さを求めて BigQuery を利用して自前で計測するようにしています。

この辺をガッとできるのは開発組織の強みでもありますね。

障害を迅速に検知・対応できる監視基盤

以前から Bugsnag や CloudWatch を使ってエラートラッキングや障害検知は実施していたのですが、ここ一年で Datadog の活用度合が大きく向上し、より広範囲の障害をカバーしつつ、迅速に検知・対応できるようになりました。

Datadog の Session Replay は問い合わせ時の調査にも役に立ちますし、今となっては Datadog がない世界は考えられないくらいです。

セールスとともに開発するサイクルの構築

プロダクトを価値向上させるためには、開発だけでなくセールスも開発の活動に参加してもらう必要があると考えています。

開発活動と営業活動の関係図開発活動と営業活動の関係図

セールスは顧客の課題を発見したらその大小に関わらず Jira に起票し、スクラムチームがそのチケットを分析し解決手段をチーム全員で考えます。 そしてチームは解決手段を提供したのちに、その手段が本当に顧客にとって価値があるのかを毎週セールスにスプリントレビューという形で検査してもらっています。

こうした活動を通じて、セールスとスクラムチームが一緒になって開発するサイクルを構築できています。

ドメイン理解のための入社オンボーディング

BtoB のプロダクトづくりにおいてドメインに対する理解は最も重要であり、究極的には全員がドメインエキスパートであることが理想です。 ですので、デスクレスワーカーのドメイン理解を主な目的として、全社員向けに入社後2ヶ月程度掛けてオンボーディングを実施しています。

ちなみに、オンボーディングは tebiki 現場教育のプロダクトを利用しているので、ドッグフーディング的にプロダクトへのフィードバックと改善が日々行われていたりもします。

ドッグフーディングの例ドッグフーディングの例

最後に

他にも組織でアラインメントされたOKR設定についての話や、技術的に難易度の高い話はいろいろありますが、また別途記事にできればと思います。

Tebiki社では一緒に働く仲間を募集してます!

自分で考え自分で動くメンバーがいたからこそ、ここまで組織を整えることができたと思っています。そういったメンバーと少しでも話してみたいなどありましたらぜひお声がけください。 3.エンジニア の求人一覧 - Tebiki株式会社 Tebiki株式会社が公開している、3.エンジニア の求人一覧ですherp.careers