経営と開発組織の橋渡しをする存在になる、取締役CTOに就任しました
アルプの共同創業者で開発を担当している竹尾（@showmant_）です。
アルプでは継続収益ビジネスを行う企業様向けに、今まで手作業や自社開発がスタンダードだった契約や請求の管理をSaaSとして提供するScalebaseというプロダクトを開発しています。
この度、新たに12.5億円の資金調達を実施し、創業時から現在までの累計調達額は19億円となりました。
現在開発チームは急拡大しており、エンジニアは正社員16名、パートナー（業務委託）の方を含めると30名以上と、1年前の2倍ほどの規模になっています。組織拡大に伴い、機能開発に関わることが少なくなり、組織の長としてやるべきことが増えてきました。
今回の記事では、CTOに就任した背景や、所信証明として、急拡大する組織でチームのパフォーマンスを最大化するために考えていることにお話できればと思います。
なぜCTO職が必要だと思ったのか
1. 組織マネジメントに関する業務が増えてきた
少ない開発メンバー間では阿吽の呼吸で全員で進められていた開発が、プロダクト・組織が大きくなるにつれて、プロダクトの方向性に共通認識を持つこと、どうやって効率よく開発をすべきかということを組織で揃える難易度が日増しに高くなってきました。
自律性を高め開発効率を最大化するために、最近ではチームを分割するというアプローチにチャレンジしました。
チームを分けた結果、チーム内で意思決定ができるようになり、生産性は向上しましたが、全体としてどのように事業とプロダクトの方向性をあわせ、それを作るチームが最大限効率良く開発する仕組みが必要になりました。その整合性をとるために、トップの発信とそれに合わせたルールや仕組みづくり・アップデートし続けることが必要になっています。
2. 役割と責任を明確にすべきフェーズに突入
組織拡大に伴い、「この人はここにコミットするんだ」という社内メッセージングを強化していくべきフェーズに突入していると感じています。人数も増え、組織としてやれることの範囲は増えましたが、それが誰の責任範囲なのかということを明確にしなければ課題解決の速度が上がりません。役割を決めることで常に開発イシューに向き合い改善し続けられると考えています。
具体的な例としては、昨年からエンジニアリングマネージャー体制を作り、採用・組織マネジメント、アプリケーション＆プロセスマネジメント、サービスマネジメント、プロジェクトマネジメントなどにそれぞれ責任を持つエンジニアリングマネージャーを据えました。
上記のような切り分けだけでなく、チーム単位においても、役割の再設計が必要になってきていると感じています。
チームを分けた意図としては、コミュニケーションパスを限定し、チーム内のコミュニケーションを活性化させ、自律して開発を進められる推進力を持ってもらうためです。ただ、他チームとコミュニケーションを取らなくて良いわけではなく、チーム間で知見を共有するために横串のコミュニケーションの場が必要になります。そのコミュニケーションの場に参加する人は誰か、発生した課題のレポートラインをどうするか、ということを考えなければなりません。
役割と責任を持ってもらうことの重要性を日々感じていて、現状”事実上”のトップの自分がはっきりとしたロールを設定すべきだと思いました。
なぜ自分がCTOに？
アルプにおけるCTOの職責をJob Description のような形で書き出してみました。するとこれまで自分自身が開発の責任者として担ってきた責務が、現フェーズのCTOのあるべき姿の一部であるということがわかりました。それならば現時点で自分が誰よりも適任であり、自身がコミットしたいという気持ちも非常に強かったので、最終的に自分がCTOに就任するという経営判断となりました。
もちろん足りない部分はたくさんあるのですが、非常に強力なメンバーに恵まれ、周りのすべてのメンバーの力を借りれば役割を全うできると考えています。
CTOとしての責務
経営と開発組織の橋渡しをする存在として、エンジニアのパフォーマンスを最大化し、事業目標の達成にコミットすることが第一だと思っています。
その上で「会社の長期的な技術・開発戦略の責任を持つ」、「採用力向上のため開発組織の社外プレゼンス向上に責任を持つ」、「開発組織の精神的リーダーとして規範を示し続ける」が特に大事だと考えています。
1. 会社の長期的な技術・開発戦略の責任を持つ
技術戦略については、開発組織の生産性を長期的に最適化していくために、自分たちの使っている延長線上の技術とそうでない技術の2つの側面から考える必要があると思っています。
延長線上の技術については、例えば、現在Scalebaseのバックエンドはモジュラモノリスを採用していますが、マイクロサービス化すべきなのか、マイクロサービス化したときにどのようなアーキテクチャ・言語選定をするかといったものが例としてあげられます。
延長線上でない技術については、例えば機械学習をプロダクトにどう利用していくかの検討・検証、あるいはWeb3など、少し距離のある技術に対して、会社としてキャッチアップしながらスタンスを表明していくことが大事だと思っています。
開発戦略については、例にあげたチーム分けなど、生産性をあげるためにどのような組織構造とアーキテクチャを取るべきか、どういうスキル・経験を持ち合わせた人を採用していくかの採用戦略も含まれます。
2. 採用力向上のため開発組織の社外プレゼンス向上に責任を持つ
自らが先頭に立って、さまざまな場に出ていくのはもちろん、会社としては開発者コミュニティに対してコミットしたいと強く思っています。
自分自身、昨年は登壇する回数を意識的に増やしました。これからも重要なKPIとして、露出を増やしていきたい所存です。
会社としては毎年ScalaMatsuriにはスポンサーとしてコミットさせていただいています。これまではすべての技術においてかなりコミュニティに助けられてきましたが、”タダ乗り”のような状態にならないように、これまで以上に会社全体で貢献していきます。今年はReact界隈でも会社として存在感を出すぞと思っています！
3. 開発組織の精神的リーダーとして規範を示し続ける
やや精神論的な話ですが、エンジニアとしてどういう振る舞いをすべきかは、その組織のトップこそが手本となり、バリューを示すべきだと考えています。
例えば、会社の中でプロダクト品質が課題になっていれば、自分が一番品質に拘るような人間でなければならないですし、スピードが大きな課題になっていればその解決のために先頭に立って、必要なことを何でもやらなければならないと考えています。
採用について
ソフトウェアエンジニア、QAエンジニアの仲間を特に募集しています。率直に申し上げて、本当に困っています 🙏
アルプの開発の特徴としてビジネスサイド・顧客との距離感が異常に近いこと、1チームで価値提供ができる構成をとっていて、個人個人が複数の職能をこなす形になっていることがあげられています。顧客へのヒアリングからリリースまで一気通貫で実行する少人数チームで開発してくれるソフトウェアエンジニアを募集しております。
また、プロダクト品質の向上は現在の最重要課題となっております。お客様の基幹業務を任せていただくプロダクトであり、会計・決済とつながるプロダクトでもあることから、堅牢性が非常に重要となっております。組織が拡大しソフトウェアも複雑化しています。会社全体でクオリティ高く、スピーディに価値提供する組織づくりをしてくれるQAエンジニアをお待ちしております。
どちらの職種もそうですが、究極的には ”プロダクトをもっとよくしたい”という意思が重要であると考えております。その意志がプロダクトを改善し、顧客からWow(ワオッ)が返ってきます。もし現時点のスキルに懸念があったとしても、プロダクトを良くするために一緒に学んでいけばいいと思っており、そういった方も大歓迎です。
アルプはこれまでの3年間でどちらかといえば強い個の力を足し合わせて開発してきました。これからは単に強いだけでなく、多様性のある個の掛け算によってどう”圧倒的に”強いプロダクトを生み出していくかというところが大きなチャレンジになります。
そんなアルプで高い山に一緒に登ってくれる仲間を大募集中です！
よかったらTwitterもフォローよろしくお願いいたします！
@showmant__
この記事が気に入ったらサポートをしてみませんか？