エンジニアリング組織のリーダーに求められることの1つに、ビジネスサイドとの緊密な連携体制の構築があります。
エンジニアサイドとビジネスサイドとの間に隔たりがあると、正しい優先度で開発ができなかったり、開発リソースの逼迫を招いたりといった弊害が生じます。本当にインパクトのある開発をできないだけでなく、エンジニアが不満を溜める原因にもなります。
この記事では、株式会社EXIDEAで執行役員CTOを務める梶野尊弘さんに、いかにしてビジネスサイドと距離を縮めていくか、CTOとしてどういう立ち回りをすればいいかについて、ご自身の経験をもとに解説していただきます。
スタートアップでありがちな開発の優先度に関する課題
プロダクト開発において、エンジニアサイドとビジネスサイドの連携は欠かせないものです。しかし、この両者をうまく噛み合った状態にするのは決して簡単ではありません。私自身を振り返っても、CTOになって最初に苦労したところがエンジニアサイドとビジネスサイドとの関係構築だったと思います。
スタートアップの企業であれば、創業者などビジネスサイドが中心となって、必要だと思うものからどんどん作っていく形でプロダクト開発をしていくことが多いのではないでしょうか。ちょうど私がこの会社のCTOになったときはそのような時期で、ビジネスサイドからの「あれを作りたい」「これを作りたい」という要望が開発側へどんどん降ってきていました。言葉を選ばず言えば、プロダクト開発の優先度にしっかりした根拠がなく、信頼性もない状態でした。
また、エンジニア側にも課題がありました。1つは自分たちが作ったものが、実際にどのように使われているかや、顧客のニーズの理解があまり進んでいなかった点、もう1つがプロダクト開発に関するコストへの意識が薄かった点です。これらによって、ただビジネスサイドから要望があったものをそのまま作っているようなところがありました。
双方がこのような状況で、しっかりと連携や議論ができておらず、情報もきちんと整理されているわけでありませんでした。これにより、どれから着手すべきなのか、プロダクト開発の優先順位付けがあいまいになっていました。
CTOとして開発組織もビジネスサイドも意識改革
ここからはこの課題を解決するために、それぞれに対して取り組んだことをお話ししていきます。
はじめに取り組んだのがビジネスサイドへのITやデータドリブンの啓蒙でした。開発側が業務で何をやっているかなどを理解してもらうとともに、データに基づいて意思決定をしてもらうように意識づけしていきました。さらに、インセプションデッキを作り、カスタマージャーニーを組んで、プロダクトのサイクルを回していくこともやりました。
そうやって、情報の透明性の担保・可視化や整備を実施しつつ、エンジニア側も要求定義の段階から関与していくようにしていきました。双方が同じデータを見たうえで開発優先度を決め、それに基づいた開発をしていくような体制づくりをCTOとして推進しました。
一方で、エンジニア側ではビジネスの背景やクライアントの課題がしっかりと見えていなかった点の改善に取り組みました。特に正社員のエンジニアに対してはその理解を深めることを求めました。事業会社で働くエンジニアとして、データを見て仮説立てし、何を開発するのがプロダクトにとって最良なのかを意識しながら業務してもらうようにしています。
また、コスト面の啓蒙も進めました。どこでどれぐらいコストがかかっているか、というコスト意識の改善です。サーバの費用や使用しているツールの費用などは比較的把握できていましたが、それだけではダメで、人的リソースまで含めて理解している必要があります。はじめはコストの全部一覧を作り「ここにこれだけコストがかかっているよ」という感じで共有していきました。
これらを通じて、エンジニアにもビジネスサイドの考えや顧客のニーズを理解してもらうようにしました。
結局はコミュニケーションの改善
以上、ここまでいろいろと当社で取り組んだことを書いてきましたが、結局両者がしっかりと連携をしていくために最も必要なのは、コミュニケーションの改善にあるといえます。
業務フローの整備など、仕組みを整えたり、啓蒙する内容を決めたりすること自体はあまり時間を必要とはしません。しかし、それを浸透させて正しく機能させるためには、双方がお互いに相手を理解することが非常に重要です。もともと当社では情報の透明性自体はある程度確保されていたと思いますが、それでもロールが違う者同士、どうしても相手を理解することは簡単ではありません。その情報をもとに業務として連携するためには、一段上の相互理解が必要でした。
ですから私はCTOとして、何よりまずはビジネスサイドから信頼を得ることを心がけました。そして、業務のフローを整えて、社内に浸透させる。エンジニアにもビジネスサイドやプロダクトへの理解を求める。それを粘り強くやり続けました。実際にCTOとしてこの課題の改善に取り組み始めてから、プロダクトサイクルがうまく回り始めるまでには半年ほどが必要になりました。
そして、スタートアップであれば、プロダクトの方向性や組織体制も柔軟に変わっていきますから、常に開発体制をそれに合わせていく必要があります。今も状況に応じて最適値を求めていく作業を繰り返しています。
開発組織の中を整えることだけがCTOの仕事ではない
CTOは開発部長ではありません。技術部門のリーダーであるとともに経営陣の1人として、ビジネスの観点も求められます。当社ではエンジニア一人ひとりがCXOクラスの人材になってもらいたいと考えているので、開発に関わる全員に求めている観点とも言えます。
私はもともとデータサイエンティスト業務の経験があり、データを分析したり、BIツールなど、データを分析するための基盤を整えたりすることをしていました。その経験がCTOとしてとても役立っているように思います。プロダクトオーナーやプロジェクトマネジャーなどの経験がある人も、CTOの業務に生かせるところは多いでしょう。
開発の先にプロダクトがあってビジネスがあるので、開発組織だけを見ていてはCTOは務まりません。ビジネスサイドと連携するとともに、しっかりとプロダクトに関わる情報を整理し、正しい開発ができるように開発組織を導かなければいけません。そのうえで、いかに開発のボトルネックをなくし、滞りなく開発ができる体制を整えていくかを考えながら開発組織を整えています。
まだまだ当社の開発体制の構築は道半ばです。よりよいエンジニアリング組織を作り、よりよいプロダクトを開発していけるように仕組みづくりや意識改革を指揮していきたいと思っています。
最後に、当社では、一緒にプロダクトを作ってくれる仲間を募集しています。当社はビジネス視点を持ってサービスを作っていきたいエンジニアの方にとって、とても成長できる環境だと思います。もしご興味をお持ちの方がいましたら、ぜひご応募ください。お待ちしています。
