プロダクトファーストな開発組織で、あなたの技術力を最大限発揮しませんか？

こんにちは。HRBrainでVP of Engineeringを担当している川田です。本記事は、開発組織の概要を伝えるために書きました。

カジュアル面談ではよく伝えている内容ですが、対外的な発信はしていなかったので、改めて実例を交えながら紹介します。

想定読者は、HRBrainの開発組織に興味を持った方、興味を持つかもしれない方です。カジュアル面談の前などに軽く目を通しておいていただけると、より深い話ができるのでぜひご一読ください。

HRBrainとは

HRBrainは、HR TechのSaaSプロダクトを提供するスタートアップです。

開発組織として、開発者が顧客の本当に求めているものを作り出し、しっかり届けられていることを実感できることを大切にしています。

HR Techのサービスと言うといわゆる業務アプリケーションのような古いイメージを持たれがちですが、HRBrainではより良いユーザー体験が得られるWebアプリケーションを開発しています。

嬉しいことに、顧客からも使いやすいというフィードバックを多くいただきます。

開発体勢

私たちは開発者だけでなく、各機能組織から成るプロダクトチーム体制を採用しています。大きく分けて開発を推進するDevelopment(Dev)と、顧客と接するセールスやカスタマーサクセスなどのメンバーを含むRevenue(Rev)に分かれています。DevもRevも対等にディスカッションをし、一緒にプロダクト開発を行っています。この体制により、「何のために作るのか？」「何を、いつまでに作るのか？」といった問いから、実際の開発までの過程を歩調を合わせながら推進することができます。

仕様策定フェーズ

仕様を決める段階では、プロダクトオーナーに全てを任せるのではなく、開発者も積極的に関わります。なぜなら顧客の普段の業務の解像度が高くないと、求められていない機能を作ってしまう可能性があるからです。

私たちはデザイナーやエンジニアに対しても、顧客の会社の人事や社内の顧客接点が多いメンバーと直接対話をし、普段の課題のヒアリングや開発中の案を見せながらフィードバックを得ることを奨励しています。そうすることで、顧客が真に求めている機能を最初から提供することが可能となります。

SaaSプロダクトでは、一度リリースしてしまうと顧客に利用し始められてしまうため、取り下げることが難しいといった特徴があります。そのため最初から本当に顧客が求めていた機能を開発しないと本来残したくないコードが残り続けてしまうことになります。顧客のためだけでなく、開発者自身のためにも仕様を決めることに力を割くことは重要です。

開発中

私たちの開発組織では、常に多くの開発ラインが稼働しています。リリース予定の機能はnotionにまとめて社員の誰でも見れるように整理されています。

プロダクトごとに分かれたチームが各々の裁量で開発を進めます。ほとんどの意思決定はプロダクトチームで完結します。セールスたちと調整をしつつ自分たちで決めた期日に向けて開発を進めます。

Branch Deploy

検証環境ではバッティングを防ぐために、開発Branchごとに独立した環境を立ち上げる仕組みがあります。通常、「Dev1, Dev2, Dev3の環境があり、開発者で奪い合う」といった状況になりがちですが、HRBrainは各々が任意のタイミングで自身の環境を立ち上げることができ、他の開発ラインに影響なくスムーズに開発を進めることが可能です。

Branch Deployについては別記事にまとまっているので、ぜひ御覧ください。

times.hrbrain.co.jp

検証環境の立ち上げは、以下の画像のようにBranchのコメントに「/deploy」とコメントするだけです。その後環境が立ち上がった後で、自動的にコメントが編集され検証環境のリンクが書き込まれます。

Feature Flag

私たちが開発する機能は、ある程度まとまった単位で提供して初めて顧客が価値を享受することができます。一方、ソフトウェア開発のセオリーとしては小さくmainにマージして小さくデプロイを繰り返すことが推奨されます(参考)。

この矛盾を解決するために、Feature Flagという仕組みも用意しています。この仕組みにより、大きい機能開発であってもソースコードをこまめにmainにマージして日々小さい単位でリリースすることができます。

詳しくは、こちらも別記事があるので御覧ください。

qiita.com

リリース前

リリース前には、プロダクトの機能を社内に説明する定例会を実施し、市場投入の準備を行います。これは主にプロダクトオーナーが行いますが、開発者が直接説明することもあります。なぜなら、開発者自身が作ったものがどのように使われるのかを理解していることで、より具体的なフィードバックや改善点を発見しやすいからです。

実際に、評価サービスのカスタマイズシート機能という1年がかりの大規模な開発では、開発中の機能を社内で勉強会を細かく実施したり、直接顧客からフィードバックをもらうことで、リリース直後から非常に大きい反響を得ることができました。

この開発フローでは、リリース前から社内のセールスやカスタマーサクセスメンバーが機能について既に詳しくなっているため、リリース前から顧客に詳細に説明することができてリリース直後からすぐに使ってもらうことができました。

リリース後

リリース後は、まずプロダクトチームから社内全体に向けてアナウンスをします。称賛しあうことで、隠れてしまいがちな開発者の活躍が分かったり、モチベーションの向上につながります。

また顧客からのフィードバックも非常に大切にしています。作ったものが実際にどのように喜ばれているかを知ることで次の開発に活かすことができます。顧客との会話の録画やカスタマーサクセスチームからの定性的なフィードバックにより、リリースした機能が具体的にどのように喜ばれたか、という具体的な事例を教えてくれます。

「サクセスニュース」というemojiがついた投稿のみが流れてくるSlack Channelがあり、ここでポジティブなフィードバックをまとめて閲覧することができます。

変遷

最初から今まで継続的にこのような文化があったわけではありませんでした。従業員が少ない頃は自然とできていましたが、人員増加に伴い組織の壁が大きくなってきました。そんな中、開発者自身がプライドを持って最高のプロダクトを開発するという原点を再認識し、様々なチャレンジを積み重ねた結果、組織文化が大きく変化しました。