エンジニアとして働く上で、どのような開発体制が取られているのか、またエンジニア組織が何を大切にしているのかについて、多くの方が興味を持つことでしょう。

そこで、今回はCTOの藤井に、Hubbleの開発体制について聞いてみました。

専門性を伸ばし、自分の性格に合ったチームへ所属する

ーーHubbleのエンジニア組織の特徴を教えてください。

Hubbleの開発組織では、開発の専門領域（フロントエンド、バックエンド）で分けることはもちろんのこと、ビジネス領域（新規受注、顧客満足度向上）の文脈でも分けています。いきなり少しややこしい印象を与えてしまったかもしれませんが、独立した組織にすることでの、意思決定のスピードを一番大事にしています。もちろん組織が分かれていても、垣根を越えたコミュニケーションの場は設けてあり、Slackや定例を通して１チームとしてプロダクトを開発しています。

このようにHubbleではエンジニアにも一定数ビジネス的思考を要求しており、セールス部門やカスタマサクセス部門との連携がしやすいように、それぞれ別の指標を追うスクワッドモデルを採用しています。

エンジニアにとっても「僕は世の中に新しい価値をどんどん出していきたい！」「俺はリファクタ大好き。メンテナンス性の高い開発をしたい」と、自分のスタイルに合ったチームに所属することが可能となっています。
スクワッドモデルに関する詳しい背景は下記のnoteをご覧ください。

ーーどのように開発を進めているのか教えてください。

毎週月曜日にリリース日を設け、開発は最低2週間のスプリントになっています。仕様が定義されてから、最短1週間開発、その後1週間のステージングチェック経てリリースされます。これはあくまでもミニマムのスプリントであって、プロジェクトによって開発期間の設定はエンジニアに委ねています。

開発期間の設定をエンジニアに委ねているのも、ひとつ特徴的なものかもしれないです。過去の経験で、“この機能があれば、あそこが受注できる。”という要望に対して、無理に期間を狭め挑戦したものの、指定日に間に合わず、ビジネス側のKPIに影響を与えてしまったことがありました。開発者の心理的安全性を確保することは会社の使命の一つであり、無理な納期を要求することなく、クオリティを担保した開発をお願いしています。

プロジェクトが始動する時にキックオフMTGを実施するのですが、これはビジネス部門やQAチームなども含めて様々な部署から意見を集めます。仕様の策定も決してトップダウンではなく、キックオフを通して該当者全員でコミュニケーションをとって、最終的な決定へとつながります。エンジニアも売り方やプライシング設定等の議論に参加することができ、ビジネス部門とも細かなコミュニケーションができる今の体制は、とても良い文化だと思っています。

ーーみなさん、日々のコミュニケーションはどのようにとっているのでしょうか。

何かあったらSlackのHuddleで会話しています。気兼ねなく会話しているので、Slackで「Huddleいけますか？」って調べるといっぱい出てくると思います（笑）。

他にもいくつかの定例MTGがあるので、ご紹介します。

開発定例

プロジェクトの進捗や採用状況、その他部門全体に伝えたいことを共有する時間です。あとはビジネス側の進捗も簡単に共有しています。

フロントエンド / バックエンドごとのMTG

フロントエンドは毎週月曜日の16時から、バックエンドは毎週水曜日の14時から定例でMTGを実施しています。ここでは技術的な相談や意見交換をするためのMTGとなっています。困ったことがあったら相談したり、リファクタや新機能の提案をしたり、自由に1時間使ってミーティングをしています。

NewMRRチーム / NPSチームのMTG

冒頭に申し上げた、新規受注チーム（NewMRR）と顧客満足度向上チーム（NPS）のミーティングです。エンジニアだけでなく、NPSチームにはCSが参加したり、NewMRRチームにはセールスが参加したりと、ビジネス部門も交えて意見交流の時間を設けています。開発ロードマップの大枠が決まるのがこのミーティングになります。

プロジェクト単位

Hubbleではビジネス側もプロダクト側も1チームになって、仕様策定・機能の背景・実装ディスカッションまでを見える化して管理しています。新しいプロジェクトが始まると、そのMTGが最低週に1回程度行われます。

開発の特徴

HubbleはフロントエンドにAngular、バックエンドにはRailsを採用しています。社内にこれらの二つの領域において、スキルの高いエンジニアが属しています。

ただこの二つだけでなく、新しい技術への挑戦は会社として後押ししています。影響範囲の選定や、メンテナンス性の可否は検討しますが、基本的に1エンジニアとして挑戦したい技術は積極的に提案してもらっています。使いたいツールがあれば試験導入してみますし、AWSの環境は社員専用の環境を提供しており、自由に使うことができます。外部のカンファレンスへの参加も推奨してますね。

技術研鑽という話の延長になりますが、現在Wantedlyの元CTOの川崎さんに、メンターとしてジョインしてもらっています。僕だけでなく、開発メンバーから直接質問したりコミュニケーションを取ってもらっています。

ーープロダクトを大切にしている会社だからこその合理性と、スキルの幅を広げる環境が掛け合わせっているのですね。

そうだと思っています！

最後に念をおして伝えたいことは、安心して開発できる環境であること。これは創業以来続くカルチャーです。例えば他のエンジニアが開発を行って、自分がレビューする立場だったとします。そのとき、まずは開発してくれたエンジニアに感謝の気持ちを持とうと伝えています。

「ここまで作ってくれてありがとう」「レビューしてくれてありがとう」という相互リスペクトがあるからこそ、良いコミュニケーションを築き、安心して開発することができると思っています。また、何か議論するときも経験が長い人が正義ということもなく、何が一番Hubbleにとって良いのかという観点で議論を行なっています。

だからこそ、安心できる環境だからこそ開発組織のコミュニケーションはフラットで、横の連携も強固です。

開発をする上での特徴

ーー最後に、開発をする上で、大切にしていることを教えてください。

一言にまとめると、Purpose & Valuesに基づいて開発する、ということでしょうか。

HubbleのPurposeは「手触りのある課題をテクノロジーによって解決し、働く人の個性や創造力が発揮される未来を創出する」と表現しています。
このPurposeを、開発では「契約業務に関わる多くの人が、100回中100回行う作業を究極的に便利にできるか」という観点に落とし込んでいます。そのため特殊で他社が持っていない機能開発を行うのではなく、お客様に寄り添った、本当に必要な機能をいかに今以上に良い体験にするかという視点を大切にしています。

さらには、事業部門にも使ってもらうことで、契約業務の生産性をあげていきたいとも考えているので、学習コストなく、ある種説明書がなくても感覚的に使えることも非常に意識しています。

ーーPurposeが行動指針になっているのですね。

そうですね、開発部門だけでなく、全社で大切にして意識しているものだと感じています。

今後Hubbleにジョインしていただく方は、お客様に本当に使ってもらえるプロダクトはどんなものだろうというのを意識して、一緒にプロダクトを育てていければと思っています！

Hubbleではエンジニアやデザイナーを募集しているので、興味があればぜひご連絡ください！