「なぜやるのか」を突き詰める。丁寧な議論で開発をリードする、PdM兼エンジニア・藤原のオーナーシップ
※注意事項
本記事は2022/01/24に投稿されたものをリライトした記事です。
情報は投稿当時のものになります。
まだ社内が混沌とていた時期に入社した古株のエンジニア・藤原。落ち着いた雰囲気の中に熱量を感じさせ、メンバーからもCTOからも信頼の厚い彼がこだわるのは、「WHY」を深掘りすることでした。
Go言語での開発と、カジュアルな雰囲気に惹かれて入社
HRBrainを知ったきっかけは、IT人材向けのスカウトサービスでのオファーからでした。ずっとSESで働いていたのですが、転職する1年ぐらい前に、自社開発に近い仕事をしていて。そのときにHRBrainと同じ、Go言語を使っていたんです。その点で興味を持ち、会社のサイトを覗いてみたら楽しそうな空気感が伝わってきて、話を聞いてみることにしました。最初の面談がCTOの鈴木と当時のVPoEで、2人のカジュアルで親しみやすい雰囲気にも惹かれましたね。
後で聞くと、エンジニアの面談でスーツを着てきたのは自分が初めてだったみたいです（笑）。
SESはご存知の通り、顧客のプロジェクトを短期間で転々とする仕事です。やりがいや学びはもちろんあるのですが、「自分でプロダクトを作った」という達成感が少し足りなかったんですよね。だから転職活動でもそこにこだわり、自社開発ができることを条件に企業を探していました。自分でプロダクトを作り、さらにそのプロダクトがビジネスの成長に直結する環境でチャレンジしてみたかったんです。
その中でもHRBrainは、まだ規模も大きすぎず、これから創り上げていくフェーズで、自分がバリューを発揮する余地があると感じました。また会社のカルチャーとして、人の役に立つことやホスピタリティを持つことを大事にしているところがあり、そこにも魅力を感じ、入社を決めました。
とにかく自主性を求められる環境
入社当時はまだ人数が少なく、コロナ禍の前だったので、ワンフロアのオフィスに全員が出社していました。セールスやCSのチームがワイワイしている一方で、開発チームはみんな静かに集中してシーンとしていることも多く、少し不安だったのを覚えています（笑）。すぐに慣れていきましたけどね。
入社してすぐ強く感じたのは「とにかく自主性を求められる」ということ。これまで働いていた環境ではマイクロマネジメントでの開発が主流だったので、そのGAPに驚きました。しかも入社したタイミングは、人事評価システムのリニューアルの直前。みんな慌ただしい時期だったので、自分にできることを自主的に見つけて、必死でついていく…という日々でした。
入社してから半年後に、社員名簿の新機能を作ることになりました。VPoEの川田との面談で、「既存の人事評価システムか、新機能を作る仕事か、どっちをやりたいか？」と聞かれ、新機能を作ることにチャレンジしたいと伝えました。今思うとそこが、自分の転機だったように思います。
新機能の開発リーダーになり、転機が訪れた
新機能を作るチームのリーダーとなったことで、自分のオーナーシップがより明確になったように思います。最初は4名ほどのメンバーで仕様策定などを行っていましたが、徐々に人数が増えて最終的には10名ほどのチームになり、自分の責任感がグッと高まりましたね。
初めは全ての機能を完璧にして、リリース期限に間に合わせることが重要だと思っていました。でもそれは難しいことがわかり、品質を担保できるスケジュールを引き直し、かつセールスやCSとも会話を重ねて、まずはコンパクトな機能でリリースし、段階的に機能を拡充していく形にしました。
チーム構成は、スケジュール管理や実装をバックエンドが担当し、開発は、自分とジュニアのメンバーの3名という体制。うち2名は初めての開発だったので、細かいサポートをしながら開発を進めていきました。「なぜこれをするのか」という、メンバーからの細かい疑問にも、根気強く対話を重ねながら進めました。その過程で自分自身が学ぶこともすごく多かったですね。
開発のスタイルとしては、リリース前はウォーターフォール型、リリース後はスクラム開発でした。リリース前はどうしてもスケジュール重視になるので、ガントチャートに忠実に進める必要がありましたが、リリース後はチームで話し合い、いろいろな開発方法を試しました。
スクラム開発の中にも、様々な種類があります。例えば、ひとつのタスクにみんなで取り組んで、早く終わらせる方法。あるいは、それぞれのタスクをお互い把握しながら細かく分担する方法。人によって何が合うかは異なるのですが、みんなの負担がが軽減されるのは前者の方法だということがわかりました。レビューもみんなでやるので、気づきや学びも多くなります。効率を重視するとやや劣るかもしれませんが、自分たちはチームの特性も踏まえてこの方法を選びました。
丁寧に議論し、「WHY」を突き詰める
今年の4月（※2022年1月当時）からは、同じプロダクトのPdM兼エンジニアとなりました。と言っても、これまでも仕様を考えることころから携わっていたので、業務内容は大きく変わりません。意識するようになったのは、プロダクトの機能について「なぜそれが必要か」「どれを優先すべきなのか」をより突き詰めて考える、ということでしょうか。
自分の考えは開発メンバーにもシェアし、みんなの意見を聞いて、「WHY」を一緒に深掘りします。顧客からの要望を大事にしつつ、その要望は他の顧客にもメリットがあるのか？を冷静に検討していきます。エンジニア経験のあるPdMだからこそ、作り手の気持ちや工数を考えて、作ることのメリットを整理し、丁寧に説明するようにしています。
開発やマネジメントで、本当に煮詰まったときは、迷わずに周囲に相談します。特にCTOの鈴木はいつも快く相談に乗ってくれるので感謝しています。「困ったら声を上げてくれるから、安心して任せられる」と言ってくれているので、こちらとしても心強いです。CTOに限らず、全体的にHRBrainには相談しやすい雰囲気があるので、責任をもって仕事を進めやすいと思います。
こんな人と働きたい
HRBrainの開発組織に求められることは、一言で言うと「オーナーシップ」です。「WHY」「WHAT」が決まったら、それをいつまでにどういう順番でつくり上げていくのかを考え、ステークホルダーが納得する形でリリースまで完遂することが重要です。それには、どんな小さなことでも必ずオーナーシップを持ち、責任を持ってやりきる必要があります。
ですから、技術はもちろんですが、それ以上に「自分はここは誰にも負けない」という何かがある人が強いと思いますね。マネジメントでも開発でもなんでもよいのですが、その「何か」にオーナーシップをもち、やりきれる人が活躍できるのではないでしょうか。チームの総合力をとても大事にしているので、自分の持ち場で責任をもってバリューを発揮できる人と一緒に働きたいですね。
また、完璧じゃない状況を楽しめる人も、HRBrainのカルチャーに合っていると思います。自分も入社してすぐ、不具合対応を謎解き感覚でやってましたし。やりきりたいことや自分だけの強みがあって、楽しんで前進していける人が仲間になってくれると嬉しいです！
HRBrainでは一緒に働く仲間を募集しています！
カジュアル面談のみでもOKですので、お気軽にご応募ください。
歴史に残るトライをしましょう！