CTO×技術顧問対談vol.1～事業フェーズと必要なエンジニアリング組織について～

みなさん、こんにちは！
ROBOT PAYMENT広報担当の高橋です！

今回は、弊社のエンジニアの内部をお見せしようと思いますっ！

2020年1月より、弊社にCTOとして和賀がジョインし、
エンジニアリング組織強化を進めております👏

具体的な施策としては、テクノロジーソリューション統括室の創設、さらにQA（Quality Assurance）・SRE（Site Reliability Engineering）チームの立ち上げなどなど。

今回は、和賀と外部顧問である相澤氏に対談取材を行いました！

内容盛りだくさんなので、3本立てでお送りいたします🎉

今回は「事業フェーズと必要なエンジニアリング組織について」について語っております。

では、早速ですが、お二方よろしくお願いいたしますっ！

まず、今回のテーマである「エンジニアリング組織」についてですが、スタートアップの会社は、そもそも人数が少ないので、エンジニアを組織化している会社は少ないのではないかと思います。

Q、スタートアップのようなメインの組織機能がない状態で、どのように役割を、どう決めていくのでしょうか。

＞和賀さん
スタートアップ段階としては、何よりサービスをローンチして早く市場に出していく必要があるんですよね。
なので、役割をどうというよりは、動ける人が動いていくというスタイルになるかと思います。

＞相澤さん
アーリーステージでは、プログラミングができる人をCTOにして、システムやサービスを全部作ってもらう感じになるかと思います。
ROBOT PAYMENTでいうと、ビジネスサイドが、管理をして、何を作るかまでを考えるが、実際に作るところは、パートナーに任せるパターンもあると思います。
和賀さんが仰る通り、一般的にアーリーステージでは、早くサービスを出して、プロダクトマーケットフィットを見ないといけないため、組織を構築するより、何をアウトプットするかに重きを置いて組織をつくりがちです。
一方で、早くサービスを作ることによって、犠牲にしたことが多々あるんですよね。
ROBOT PAYMENTもそう。多かれ少なかれ、どの企業にもあると思います。
それはやっぱり「システムをつくる」と「サービスつくる」はニュアンスが違うからだと思います。
ここを一緒くたにプログラマーに任せてしまうことで、サービスが売れ始めるとひずみが出てきてしまうんです。

Q、お金があれば最初から組織構築をしていくのでしょうか？

＞相澤さん
お金があれば、最初から技術志向人を雇って、技術組織を長いロードマップの中で、どう作っていくかを決めることもできます。ただ、そんなことを始めから取り組んでいる企業はなかなかないんですよね。
エンジニアが事業を率いて、エンジニア面が強くなりすぎても、売れないものができてしまったり、ビジネス側が弱くなったりするなどの問題が発生する恐れもあります。あとは、無駄にプロセスがオートメーションしちゃうことも然りですね。

Q、お金がない場合、一番何を優先するのでしょうか？

＞和賀さん
お金がなければ投資できないので、まずは作ることを進めることが大事ですよね。作らなきゃいけないというのが大きいと思います。

Q、組織化が必要となる転換期はいつになるのか？

＞和賀さん
転換期という意味でいうと、技術的負債が膨れてくると、運用費が上がってくるので、そこをいかに抑えていくかが重要になります。そうなると、根っことなる負債の解消、サービスの改善が必要で、ここでやっと役割が決まってくるんですよね。
ROBOT PAYMENTでは、今期、QA・SREチームも立ち上がり、横断的に品質をより良く、信頼性のあるサービスを届けるということを考えています。
ただ、まだ過渡期かなという認識でいます。

＞相澤さん
なぜ、敢えてここで、QA・SREチームという役割を明文化したかというと、今までは、気の利く人たちの行動によって、組織をなんとか維持できていました。それを、品質はこの人・基盤はこの人という風に役割を決めることで、そこにフォーカスした施策を取りやすくしたかったからです。
そして、事業側から見るとエンジニア＝エンジニアリングができると思われがちですが、全然そんなことはなくて、みんながみんな全てのエンジニアリングができるわけではないです。（笑）
得意分野・ミッションによって動き方は違ってくるし、対立も生まれることもあるし、フロントエンド・バックエンドでも全く違う動きをします。
だからこそ、気が利くとかの話ではなく、役割として構造を作っていくことが重要になってくるんですよね。

そう考えると事業部と似ていますね。
営業とマーケティングだったり、今では営業もインサイドとフィールドが分かれていたりなど、それと一緒ですね。

＞相澤さん
まさにそうで、最初はパワーのある営業マンとかが、リード獲得からクロージングまでを一人で回していたけど、それだとスケールしないんですよね。
その考えと、エンジニアリング組織も同じだと思います。

なるほど、、、。
事業側としても「営業」という大きいくくりで見られがちですけど、みんなそれぞれ役割が違っていて、これはどの組織でも起こってしまうんですね。

＞相澤さん
あとは、会社のステージによって、エンジニアと経営層の仲立ちする人の役割が変わってくるということですね。
初期は、CTOという冠があっても、手が動くプログラマーでいい場合もあるのですが、その次のステージでは組織を作っていかないといけないので、そこからは経営インパクトを与えないといけない。
また、CEOは四半期とか年度の単位で、会社のパフォーマンスを見ていますが、CTOはもっと長い目で、その会社の出しているサービス、技術、負債、資産といったものをどういう風に育成していくかに観点を置かないといけません。
そのため、CTOは、1人の人間がやるとすると、会社の成長に対して人格改造を求められることがあります。

Q、大きくいうと、エンジニア組織はどんな部署・役割があるんですか？

＞和賀さん
営業よりのところでいうと、セールスエンジニアがあります。これは、いかに技術的に提案できるかが重要になってくるので、エンジニアと言えばエンジニアですね。

＞相澤さん
セールスエンジニアは、技術的な背景をもとにその製品・サービスをお客様に説明し、価値を理解していただくこと。また、お客様の中でその製品やサービスが価値ある形で利用してもらうように、自社と他社を含めた全体的なお客様側のシステムの構成をしっかりセールスしていきます。
その後、お客様に定着するように技術的な支援を行うソリューションアーキテクトやソリューションコンサルタントと言われる人もいます。
これは、セールスサイドやカスタマーサクセスに近い部署に入っている人たちになりますね。

おおっ！かなりビジネス寄りのエンジニアの方々もいらっしゃるんですね。

＞相澤さん
一方で、わかりやすいところでいうと、まさにフロントでサービスを作っている、アプリケーションエンジニアですね。
ここでは、コードを変えたり、設計をしたり、一番サービスに影響を与える部分に携わっていますが、それ以外にも、アプリケーションエンジニアが働きやすくするための開発環境を整えるという役割もあります。
それが、今回弊社で立ち上げたSREチームにあたります。

＞和賀さん
さらに、作ったものが製品品質として、漏れのないものかというところを、外部の第三者の視点から確認して検証するという役割を持っているチームもあります。
これが、今回僕が作ったQAチームの役割になります。
具体的に言うと、アプリケーションエンジニアが作ったものは、自身で全て解消すべきということではなく、QAチームが第三者視点から品質を上げていく、また、「こういうことをやってください」といった指示をするなど、品質を悪くする活動を削っていく動きをしています。

今回立ち上がったQA・SREチームはそういった役割があるんですね。

＞和賀さん
あとは、クラウドを使っているとあまり出てこないですが、会社によってはサーバーのような、足回りを動かす人たち、ネットワークを管理する人たちとトラッキングするとか、配線するとかもありますね。

＞相澤さん
フロントの画面周りを担当する人と、バックエンドを担う人、あとは、インテグレーション、社内システムとの統合とか社外システムとの統合を担う人をまとめて、アプリケーションエンジニアと言われることがあります。そして、設計の要になるのが、アーキテクトという職種です。
アーキテクトの役割は、色んなところにアーキテクトの成果物であるアーキテクチャーを見出していくことです。アーキテクトは、アーキテクチャーの全体像をどこまでのスコープで見ていくのか。そして、整合性を取りながら、理想も見ながら、そこに向けたステップも考えながら、適切な設計ができるという力は必要です。

アーキテクト、、、？

Q、それは具体的にどういった役割になるのでしょうか？

＞相澤さん
エンジニアリングマネージャーとも違う、プロダクトマネージャーとも違う。アーキテクトというのは構造に責任をもつことなので、例えでいうなら「一級建築士」ですね。大工でも、現場監督でもない。

一級建築士っ！（笑）

＞相澤さん
一級建築士（ここでいうアーキテクト）は、そのデザインの意味とか、なぜこうするのかという哲学を作って、それを構造として表現していく。それが出来る人が、いるかいないかでは、やはり強い意味でのエンジニアリング組織ができるかどうかの一つの基準になるのかなと思います。

＞和賀さん
仰る通りですね。その存在がいるだけで本当に変わってきます。
僕の過去所属していた会社が広告配信プラットフォームを構築運営していたのですが、そのプラットフォームのアーキテクチャーを僕が考えたんですよね。つまり、僕が軸だったんです。
軸が1本立つと、あとはみんなその軸に従って作ればいい話なので、軸をちゃんと握れる人がいると、組織として強くなるなと思います。

なるほど、、。
プロダクトマネージャーが全てだと思いがちですが、アーキテクトの人を選ぶのはとても重要なんですね。

＞相澤さん
もちろんプロダクトマネージャーの存在もとても重要です（笑）
そもそも前提として、大きく分けると3つの役割があると思います。
まず、プロダクトオーナーは、外部的な要因としてビジネスサービスとして正しいかを判断し、アーキテクトはどういう構造が正しいのかというのを決めるんです。これは、プロジェクト実現するために、この構造は正しいと規定する人ですね。そして、プロダクトマネージャーはその正しいものを作りきるためのチームを動かす人になるというイメージです。

＞和賀さん
ただ、アーキテクトの難しいところは、これが正解だというところに根拠をつけますが、結局は自分が捉えた、理解したというのを言っているだけで、それが正しい絶対的保証はどこにもないんです。でも、そこに自信を持てるだけの何か自分なりの論拠とか、哲学とか、チーム状況とか、これまでのしがらみとか全部をインプットして考えているんです。要するに、こうあるべきと言い切れる人は様々な力が必要なんですよね。
そのためには、やはり経験も必要かなと思います。
場当たり的に、設計しろと言っても難しいと思うので。

Q、では、一般的にその指示・命令のすみ分けはどうなっているのでしょうか？

＞和賀さん
そこは、バリューチェーンで分かれているかなと思います。
フェーズや、携わり方によって変わっていくと思うので、プロダクトマネージャーとかは横断的に見るかもしれません。そして、事業オーナーやプロダクトオーナーは売上などの数字も含めて、事業としてどう発展させていきたいかも見ています。
アーキテクチャーを考えるうえでブレずに責任を持つ、というのがアーキテクトと言えると思います。
全体見るときも、縦と横の関係かもしれません。アーキテクチャーは深ぼっていくイメージですね。

＞相澤さん
　そうですね、そしてこれがないとビジネス要求に縛られる組織になってしまい、ビジネスサイドのやりたいことに振り回されてしまうんです。
そのため、目指す方向性や、ゴールに導くための指示というのはアーキテクトの役割になると思います。

なるほど、、！アーキテクトは、ビジネス要求とシステム開発のバランスを取る重要な役割ということですね。

今回のお話しで、エンジニアの個々の役割とエンジニアリング組織の全体像がかなり見えてきた気がします、、！

CTO×技術顧問対談vol.1はここまでですっ！

次回は「事業フェーズとシステムの関係性」について語っております！

お楽しみに～～～😊！

【CTO×技術顧問対談記事一覧】