皆さんこんにちは！スマートラウンド CTO の小山（ @doyaaaaaken ）です。
このオープン社内報は、CTOである自身が普段「なにを感じて、どんなことを考えているか」について、月に一回、社内へ共有する試みです。
“オープン社内報” という名称のとおり、この文章の内容は一部編集した上で会社ブログに公開します。
第一回ということもあるので、オープン社内報を始めた背景について紹介します。
スマートラウンドも事業成長に伴い順調に社員数も増え、30人の壁と呼ばれるフェーズに差し掛かっています。
それに伴い「エンジニア組織の目指すところや現状が見えにくい」という声も社内からフィードバックとしていただくようになりました。
このオープン社内報はそういった課題を軽減するために始めました。
社内報という形にすることで「皆さんが好きなタイミング気軽に読め」「（将来入社した人が）過去の背景を簡単に見返せる」のがポイントです。
そして社外にオープンにするため、「これはしっかり書かなければいけないぞ」という気持ちになれます！（ネットの海に恥をさらさないよう頑張っていく所存です！）
最近のことについて書きたい気持ちなのですが、まずはベースとなるエンジニア組織の思想を理解していただくことが大事なので、はじめのほうは過去の組織設計・制度設計の背景を中心に説明していきます。
今回は様々な立場の方からよく聞かれる質問である「CTOとCPOの役割分担」というテーマについて書きます。
そもそもCTOとCPOとの役割分担より前に、そもそも「スマートラウンドにCPOという役割が必要な理由」について話すところから始めるべきでしょう。
私自身なりの考えを書いてみます。
スマートラウンドではシリーズAの直前ぐらいのタイミング（昨年5月）に加納さんにCPOとして入社いただいています。
一方で世の中の同フェーズのSaaSスタートアップにおいては、プロダクトオーナーにあたる役割は創業者自身やCTOが担うケースも多く見られます。
これはCXOのようなハイレイヤーの役職が創業初期から多いと、色々と困ったことが起きるからです（意思決定の遅延、責任の分散、組織のフラットさの低下、より適任の人が現れた場合の対処など）。
CPOに限らない話ですが、役職は会社の成長のために必要な場合に設けるべきです。
スマートラウンドもそういった考え方でこれまで成長してきており、CPOという役割は会社に必須だったため設けられました。
ではその理由は何でしょう？
社内の皆さんはよくご存知の通り、スマートラウンドは特定領域のサービスだけを手掛けてるのではなく、「スタートアップと投資家のコミュニケーション」に関わる領域を中心とし、スタートアップ・投資家・士業の方向けに、これまで連続的に隣接する領域へどんどん事業を広げてきました。
スタートアップ向けのサービスだけを例にとっても、創業当初はスタートアップが資金調達するタイミングで利用する機能群（資本政策・DD資料共有・チャット）から始まり、その後「経営情報の管理・共有」「株主名簿・新株予約権原簿の管理・共有」「株主総会の開催」「ストックオプションの管理」と、主にスタートアップの創業者やCFO・管理部長の方々の業務をラクにする様々な機能をリリースしてきました。
そして今後も同様の戦略を取り、スタートアップがフェーズを問わずエグジットするまで使い続けられるよう、機能群をリリースしていきます。
smartroundのスタートアップ向けサービスページに記載のキャッチフレーズ。右の方にある温かみのある色のスマートラウンドロゴが個人的お気に入りです。
こういった戦略を実現するためには、1つの業務領域について詳しいだけでは駄目です。
複数の業務領域を束ねるプロダクト全体をマネジメントするため、最低でも以下のようなスキルが求められます。
この役割は到底CTOである自身ができることではありませんし、創業者自身が時間を割き続けるのも不可能でしょう。
また一人の優秀なプロダクトマネージャーの方に担ってもらう責務としても重すぎます。
加納さんのようにFinTech領域の経験が非常に豊富で、またプロダクトや事業について幅広い視野で見れる方（インタビュー記事にも記載のように、加納さんはうまくいっている大企業・スタートアップの両方を経験し、またプロダクトマネージャのみならずエンジニア・事業開発・営業も経験されています）が優秀なチームとともに取り組んで、はじめて務まる役割でしょう。
こういった背景で、スマートラウンドにはCPOという役割が初期から必要でした。
本題のCTOとCPOの役割分担について、簡単にいうと、このような形になっています。
『CTOはプロダクト開発組織に責任を持ち、プロダクトという資産を創り、良いものに改善し続ける。
CPOはプロダクト企画組織に責任を持ち、プロダクトという資産を上手く活かし、目指す価値を創り出す（KPIを達成する）』
「プロダクト開発組織」にはエンジニアが、「プロダクト企画組織」にはプロダクトマネージャー・デザイナーが所属し、二つを合わせて「プロダクト組織」と呼んでいます。
より具体的な分担については、元資料から以下に画像として引用しましたので、ご覧ください。
なおCTOの責務範囲としては、プロダクト開発組織の他にコーポレートITもありますが、その詳細は次回あたりに説明しようと思っています。
私がエンジニアの方の採用面談を担当していることもあり、CTOとCPOの役割分担に関する質問は、特に採用候補者のエンジニアの方からよくいただきます。
背景としては「プロダクト組織が二つに別れることで、エンジニア組織が受託構造（＝注文を受けて作るだけの形）になってしまわないのか」という心配があるようです。
この心配はもっともだと思っており、ただ単純に組織を分けると自然に受託構造に陥ってしまいます。
「受託構造になっていないか？」はCTOの役割として常日頃から注意を払っているポイントの1つで、そうならないように様々な仕組みがあります。
ここではその一部やその背景となる考え方について紹介します。
そもそも受託構造だと何が問題なのか、プロダクトを創った経験がないと分かりづらいと思うので説明します。
自社サービス開発の場合、よほど単純なタスクでない限りは、開発着手してからリリースするまでに通常イテレーションが発生します。
創業時からおり、smartroundのユーザ像・仕様・ソースコードを知り尽くしている私でさえ、実装に入ったあとにほぼ毎回何かしらの議論を行っています。
最初に想定した仕様や実装そのままに開発が行われることはほぼなく、実装していく中でUX面・仕様面・実装面での様々な問題点・改善点に気づきます。
そこで修正についてプロダクトマネージャ、デザイナー、エンジニアと議論し軌道修正していく必要があります。
この議論が行われないと、「一応要件は満たしているけど、実用に耐えない機能」ができあがります。
（例えば「ストックオプション管理機能で、データの管理はできるけれども、誰に何個割り当てたかはストックオプションを割り当てた社員の詳細ページまで見に行かないといけない」とかなると使いにくいですよね。営業としては売れるかもしれませんが、使ってくださっているユーザは満足してくれません）
僕が大好きな『顧客が本当に必要だったもの』と呼ばれる風刺画を添付しておきます。個人的には「プロジェクトの書類」の部分が好きです。
もちろん受託構造が一概に悪いというわけではありません。
例えばUXが重要ファクターではない、例えば銀行のシステムや社内システムであれば、むしろ受託構造のほうがいいケースもあるでしょう。
一方でSaaS開発の場合、不特定多数のユーザ様が使いやすいものにするためUXが必須であり、そのためには受託構造では良いプロダクトが作れないのです。
スマートラウンドのエンジニア組織の1つの大きな特徴として「エンジニアが実装だけでなく、仕様策定・プロジェクトマネジメント・テスト・リリース後の運用まで一貫して関わる」という点があります。
また「予め決められたとおりに作ること」ではなく「ユーザに良い価値を届けること」が仕事と捉えており、そのプロセスを円滑に行うためにフロントエンド・バックエンドを問わず開発するのも1つの特徴です。
（ユーザへ価値を届けるための全工程に関わる役割という意味で、こういった役割は最近では”フルサイクルエンジニア”と呼ばれています）
幅広いスキルが要求されるため採用のハードルは上がってしまいますが、これらの事が実現できる優秀なエンジニアがいることで良いプロダクトを創ることができるため、創業時から大事にしているポイントの1つです。
エンジニア採用情報スライドより引用。フルサイクルについての説明
例えば仕様策定を例に取ると、＃dev-spec-discussionというSlackチャンネルで、エンジニアからプロダクトマネージャ・デザイナーの方へ仕様議論（提案・質問）を行っています。
エンジニアの方が仕様議論を行っている図。皆フルリモート勤務なので、画像や文章などを使い相手にわかるよう、丁寧に説明を行うことを組織全体として大事にしています。
またプロジェクトマネジメントに関しては、水曜日のプロダクト会議で全社員に対し、エンジニアからのプロジェクト報告を行なって進捗や予定を共有しています。
そのプロジェクトのオーナーとなったエンジニア（Epicオーナーと呼んでいます）自身の手で、リリース時期の見積もりを決め、その進捗を共有していただいています。
こういったフルサイクルな動きをしやすくため色々な工夫をしています。
一例としては会議体も工夫しており、話す機会を得やすいように、10時からの朝会にはプロダクトチームのメンバー全員が集まるようにしていたりもします。
このようにエンジニアが良いプロダクトを創るため、プロダクトマネージャ・デザイナーの領域にも越境し、積極的に議論を行っていく文化です。
逆にプロダクトマネージャの方にもエンジニアのプロジェクトの進捗や途中成果物のUXを気にかけていただいていたり、デザイナーの方にもエンジニアの途中成果物のデザインについて意見をいただいたりしています。
プロダクト開発が「創って終わり」、プロダクト企画が「企画して依頼したら終わり」となってしまうと良いプロダクトはできないので、今の互いに越境する関係性を今後も続けていけるようにしていきたいと思います。
いかがだったでしょうか？スマートラウンド社内の雰囲気が少しでも伝わっていれば嬉しいです。
ここまでご覧になってスマートラウンドに興味を持っていただいた方や、もっと話を聞いてみたい！と思われた方は、ぜひWantedlyからご連絡ください。
/assets/images/3229411/original/694acbe0-66c3-4f30-a5fa-ee343f2a97f3?1551337866)
/assets/images/3229411/original/694acbe0-66c3-4f30-a5fa-ee343f2a97f3?1551337866)
/assets/images/3229411/original/694acbe0-66c3-4f30-a5fa-ee343f2a97f3?1551337866){kind=avatar}