こんにちは。ジモティーのエンジニア部の執行役員をしている鈴木です。

今回の記事ではジモティーのエンジニア組織の特徴を紹介したいと思います。

下記に記載しているのは採用の面談のときにもよくお伝えしている内容で、我々がどういう考えで何を大切にしたいと思っているか、その結果生まれた今の組織の特徴です。

これをお伝えするのが弊社への入社を検討していただくうえで一番重要と考えています。

実際、弊社への入社を考えていただく過程でこのテックブログをお読みになっていただくこともあると思いましたので、この場にてアウトプットさせていただく運びになりました。

それでは行きましょう。

前提 -バリュー

いきなり各論に入るまえに全体を整理する必要があります。

今回、本題にてあげさせていただく特徴というのは、まず我々が大切にしたい価値観・行動指針（=バリュー）があって、それに基づいて生まれた「現在、具体的に行っていること」になります。

引用 : https://www.recruit-ms.co.jp/issue/column/0000000650/?theme=personnelsystem

ここのバリューの部分は別の記事にて詳細はあげさせていただこうと思いますが、簡単に話すと、行動指針は全社のものと、さらに具体度をあげたエンジニア組織版の行動指針があり、それぞれの観点ごとにひとつひとつ規定されていますがそれをサマったワンフレーズがあります。

「継続的に事業価値に直結する成果を出し続ける」

我々のバリューを一言で表現したものがこれになります。

今回お話するのは全社のビジョンをこのバリューに基づいて達成するために具体的にどういう風に普段の業務を設計しているのか、という部分になります。

1. ビジネスと近い距離で要件や仕様に関わっていきながらプロダクトを作る

ジモティーという社会貢献性が高いサービスのイチ社員であると考えたとき、エンジニアでもサービスの要件や仕様に大きく関わり、自らの創造的な働きによって得られたサービス成長を感じられるのが我々ジモティーエンジニアとしてのやり甲斐だと考えています。

弊社の開発フローは大きく 1. ビジネス要件定義 2. システム要件定義 3. 開発 4. テスト 5. リリース

と分けられています。

3〜5はイメージが付きやすいと思いますし、ビジネスと関わる部分というと1と2になりますのでここを説明していきます。

大雑把に言えば、ビジネス要件定義は「目的・課題はなにか」「何を作るか」のフェーズで、システム要件定義は「どう作るか」のフェーズになります。

フェーズ	役割	詳細 - 明確にする部分
ビジネス要件定義	・目的・課題は何か・何を作るか	・解決したい課題・ゴール・どこまでをシステムで実現するのか（スコープ）・粗いワイヤー、業務フロー・リスク
システム要件定義	どう作るか？	・工数・画面設計（モックアップ）・機能設計・細かい仕様（イレギュラー時など）・実装手段の実現可否や代替案の提示

弊社の場合、基本的にはビジネス要件定義の段階でエンジニアを投入します。

冒頭でお伝えした「やり甲斐」が目的でもありますが、生産性の観点でも合理的であると考えています。

まず「機能」を考えるとき良質なインプットがないといけません。そこからユーザーの本質的な課題は何か？ということを推察していきます。そのためにカスタマーにインタビューした内容やログデータを参照しますが、ログデータをどう分析するか？というところはエンジニアのほうが得意だったりします。どこに何のデータがあるか？どうデータを出せばよいか？そういったことは基本的にはエンジニアの得意領域です。

実際に、少し前まではシステム要件定義の段階でエンジニアをアサインしていましたが、ビジネス要件フェーズへの差し戻しが多く発生していました。

スライド1.png (83.0 kB)

現在ではビジネス要件定義フェーズからエンジニアを投入して「目的は何だっけ」「ユーザーの本質的な課題は何？」「じゃあ何作ったらよい？」というところから大きく関わっています。

こうした形で「言われたものを作る」ではなく、エンジニア自らがビジネスに深く関わっていき「事業に直結する成果」を出せるチームで有り続けたいと考えています。

2. 技術の幅を大切にしている

我々は技術は手段、と考えています。技術の幅が広がればそれだけ解決できる課題が増えると考えているのと20名弱のエンジニア組織でのリソース効率性を考えたときに複数領域にコミットできるエンジニアが多いほうがサービス成長に直接的に貢献できると考えています。そうしたエンジニアを増やすために、エンジニアが技術の幅を広げるのを支援する環境を用意しています。

具体的には各技術領域毎に技術評価項目という実務で使う技術項目がまとまっているものを用意しています。領域をコンバートした直後やジュニアのエンジニアが業務で必要な技術スキルを身につけるのに適しています。またチームとしてどの領域の技術が弱い、ということが明確になるので伸ばすべき弱点を明確にできます。

下記のイメージです。

引用 : https://udemy.benesse.co.jp/training/corporate_training/skill-map.html

実際にはもっと技術の具体度が高く、スキルを習得したいエンジニアが何をどの程度まで理解できていればよいか、というレベルを明確にしています。サンプルを記載します。

Module#include, extend, prependの違いの理解し、使い分けできる
クラスの組み合わせレベルでの設計の基本であるデザインパターン、特に、ジモティーで重要視するパターンについて説明でき、実装とレビューに応用できる
top/vmstat/ps/lsofなどのコマンドをつかって負荷・障害原因を調査できる

この粒度の技術知識習得について、まずメンバーがリーダーやマネージャー、テックリード（育成者）と学習とアウトプットの仕方を相談します。そのあとメンバーがアウトプットを出したら育成者がそれをレビュー・FBしています。

こうした形でチームと個人の技術力の向上、それによってプロダクトの成長に貢献できるように努めています。

3. リファクタリングや新技術導入による中長期視点での生産性の維持・向上を大事にしている

ジモティーは2011年から始まり、2022年現在12年目のサービスになります。12年の間にソースコードはサービスと共に進化を遂げ、新しい技術もどんどん生まれてきました。今後も5年、10年とサービスを発展させつづけるという前提に立ったときにリファクタリングや新技術導入を導入し開発を円滑に進められるようにするのが大切だと考えています。具体的には全開発予算の25%をリファクタリングや新技術導入に投下しています。

ただし、25%使えて内容は何でもよい、無鉄砲に新しい技術に手を出して良い、とは考えていません。

目安としては2年程度で投資回収できるぐらいのROIでやりましょう、としています。

例えば簡単な例だと

インフラのコンテナ化に3ヶ月の間エンジニアを一人投下する（20d/1mで20dx3の60d のリソース投下）
その結果インフラのメンテナンス工数が年間あたり30d程度削減される

この場合は2年で回収できます。（実際の数字ではなくイメージです）

また、このテックブログでも度々記事になっているフロントエンド分割なんかでは、単純な人日での工数削減ではなく、リードタイム削減が目的になります。

jmty-tech.hatenablog.com

これもざっとイメージですが、

フロント分割をして「リードタイムが半分になった」暁に、あるPRJに半年間投資しましょうとなった場合、

30d の6回リリースで（ユーザーから）6回フィードバックループを得られる

というのと

15d で12回リリースでき12回フィードバックループを得られる

というのだとプロダクトの成長スピードが全然違うというのはイメージしやすいと思います。

あとは、一回のフィードバックでプロダクトがN%改善する機会を得られる、としたときに、年間に走るPRJの数分だけ差がうまれるので、そこから大体フロントエンドの分割に2年間（1人）ぐらいはかけ続けても全然メリットのほうがでかいよね、というような議論のプロセスを経て意思決定をします。

ただ、実際はそこまで全てを数値化して天秤にかけているわけではなく、他にも、採用しやすくなるよね、とか中のエンジニアがキャリア形成しやすくなるよね、とかそういったことも含めながら感覚も含めて決めている感じです。

定量とある程度の定性的な観点も判断に加えつつ、ビジネスも含めプロダクトを作るチームとして皆が納得感をもって技術投資ができることが重要と考えています。

終わりに

長い記事に目を通していただきありがとうございます。

上記にあげさせていただいた内容も含め、バリューやそこから生まれる業務プロセスについては日々見直すことが大事と考えています。

そのためには会社としての目的・目標に対して、現場がどうワークしているか、それをきちんと観察・ヒアリングして課題を吸い上げて改善し続けていくことが重要と思います。

例えば開発フローの話もフローとしてエンジニアをビジネス要件からアサインしていこう、となったのも比較的最近の話です。ビジネスとエンジニアが阿吽の呼吸でワークするようになり、ビジネスの要件のアウトプットに対してエンジニアの納得感が高くなってきたりしたら、今度はエンジニアは逆に作ることに集中したほうが生産性が高い、という結論にもなりえます。

絶対的な解はなく、内外の変化に対して柔軟に対応していく、それが素敵な組織だと私は考えています。