RevComm Tech Blog

コミュニケーションを再発明し 人が人を想う社会を創る

エンジニア出身ではない CEO にシステムを説明する方法

この記事は RevComm Advent Calendar 2022 の 25 日目の記事です。

はじめに

 株式会社 RevComm 執行役員 CTO の平村 健勝 (@hiratake55) です。2022 年は、AI 搭載 IP 電話 MiiTel の機能改善から大規模なシステム移行、セキュリティ面での改善、さらにインドネシアをはじめとする海外事業の拡大、AI 搭載オンライン商談解析ツール MiiTel for Zoom の正式リリースなど、社会やビジネスにおけるさまざまな課題を解決する製品をリリース・改良してまいりました。

 この記事では、このような急速な発展を遂げるために、技術的な挑戦だけでなく、私やほかのエンジニアリングマネージャー陣が実践している、あまり触れられないユニークな工夫について紹介したいと思います。

エンジニア出身ではないCEOの良いところ

 すべての会社は「エンジニア出身の CEO がいる会社」「エンジニア出身ではない CEO がいる会社」の 2 つのタイプに分類されると思います。中には、エンジニア出身ではないものの一定のシステムの知識がある CEO もいるでしょう。そして、弊社 CEO の會田は、大学も文系学部、三菱商事の出身で、エンジニア出身ではなく、後者のタイプです。

 開発部門にとって「エンジニア出身ではない CEO」は、一見デメリットが多いと思われがちですが、必ずしもそうではなく、次の表のようにそれぞれによい点があります。

エンジニア出身の CEO のよいところ エンジニア出身ではない CEO のよいところ(一例)
  • システム構成やシステムの特徴、開発の方法論などを時間をかけて説明する必要がない
  • セキュリティやシステム可用性、保守性など、非機能面でのリスクアセスメントや経営判断ができる
  • 収益性を見積もりにくい R&D などの活動に対して理解が得やすい
  • マーケティングの知識や営業力があるので、事業や案件の拡大が高速
  • 技術的実現性を度外視した、突拍子もないアイデアが出てくる
  • ファイナンス(P/L, B/S, C/F など)を意識した意思決定ができる
  • 他社のエグゼクティブ層との広く深い人脈がある

 このため、エンジニア出身ではないCEOの会社においては、工夫が求められるところは工夫することにより、エンジニア出身の CEO の会社には難しいことを圧倒的にスピーディーに進めることができると考えています。

 これらを踏まえ、エンジニア出身ではない CEO の会社のよいところを最大限生かしながら、エンジニア出身の CEO の会社のよいところを上回るような組織を目指して、我々が実践していてうまく機能している方策を 5 つ紹介します。

方策 1: 開発スケジュールや開発方針の説明に比喩を用いる

 前例がある開発タスクはある程度正確にスケジュールを見積もることができますが、RevComm では社内どころか世界的に前例がない取り組みであっても、それがユーザーや社会に必要とされているならばむしろ積極的に取り組もうという文化があります。
このため、工数の見積もりが難しかったりそもそも実現できるのかどうかも不明な状態から着手することがあります。

 このため、予定より遅延したり早期にリリースできてしまうこともしばしばあります。このような状況を説明するには、建設工事を例に出すと、スムーズに理解を得ることが多いです。

 例えば、すでに何棟も実績がある戸建住宅の建築工事はある程度正確に工事完了の時期を見積もることができるでしょう。しかし、例えば高速道路や地下鉄のような土木工事で、まだトンネルを掘ったことのない場所にトンネルを作るのは、工事の途中で何が起こるかわかりません。快調に進めば予定より早く完了するでしょうし、工事中に想定していなかった硬い地盤や軟弱な地盤が見つかると、数か月や数年単位で遅れが発生してしまいます。

このように、想像しづらいシステム開発の工程をイメージしやすい現実的な比喩を用いて説明することで、手触り感のある説明にできることが多いです。

方策 2: エンジニアにはそれぞれの得意分野があることを伝える

 同様に比喩を用いるケースとして、それぞれのエンジニアに専門分野があることについては、高い専門性を持ったスペシャリストが活躍する医療現場に例えるとスムーズに理解を得られることが多いです。

 創業間もないシード期には、フロントエンドから、モバイルアプリ、サーバサイド、インフラ、デザインや機械学習に至るまで、幅広い領域をカバーできるフルスタックエンジニアが活躍できることが多くあります。つまりこれは個々の病気に対する専門性は高くないものの幅広い知識を持った "かかりつけ医" のようなタイプのドクターです。

 しかし、組織の規模が大きくなると、高い技術や経験、ナレッジが求められるため、役割が分担されていきます。これは総合病院や大学病院のように、内科、外科、眼科などそれぞれの専門性が高く発揮できる組織に分けられていることに近いです。一方で、フルスタックエンジニアも救急救命医のように、分野横断的な課題の解決に高く貢献できます。

 例えば、優先度を高めて対応しないといけない急な ToDo が生まれた際、エンジニア出身ではない CEO は「エンジニアは全員今の仕事を停めて優先度の高い ToDo に着手すること」といった指示を出してしまいがちです。例えば、サーバサイドアプリケーションの不具合改修をモバイルアプリエンジニアが担当することは、外科のドクターが内科の病気を診察するような状況であり専門領域が違います。
各メンバーが得意な分野で活躍できると、効率的に課題を解決したり早期に目標を達成することができます。このように、役割分担についても納得感があり透明性の高い形で説明することを心がけています。

 また、開発プロセスにおいて、フロントエンドエンジニアとサーバサイドエンジニアのように役割分担して開発することを「カレー作り」に例えて説明しました。
下記の図は全社オフサイトミーティングでも説明したスライドの抜粋です。

 役割分担が進んでも、企画構想から設計、開発、QA、リリースに至る全体のプロセスを俯瞰することで、技術的に高いレベルの取り組みを高速に進めることの重要性を伝えました。

方策 3: 全メンバーが共通の目標を意識する

 これは、CEO に対して行っている取り組みではなく、メンバー全員に対して心がけるようにしている内容です。

 製品開発を進めるにあたって、CEO や事業責任者(プロダクトオーナー)が一方的に指示し、開発やデザイン、マーケティング、セールスを行う形の組織もあると思います。しかし、RevComm ではそのような開発方法はそぐわないと判断し、創業初期からエンジニアやデザイナーだけでなく、セールスやカスタマーサクセス、カスタマーサポートのようなプロダクト・ビジネス部門に加えて、コーポレート部門(管理部門)のメンバーも一体となり、全員が主導で共通の目標を達成することを意識しています

これにより、短期間で高い収益、高い満足度が得られるような新しいアイデアを提案したり、トレンドに合わせて製品をアップデートしたり、今後増えるであろうお客様のニーズを先んじて実装することにつながり、競争力の高い製品をマーケットにいち早くリリースすることができると考えています。

方策 4: 相手の立場に立って、相手に伝わる言葉を選ぶ

 リファクタリングや長期間運用してきたシステムのリニューアルなどのように、収益性が見通しづらい、いわゆる "守りの開発" や、避けてほしいこと、お願いしたいことも、言葉を選んで言い換えることで、その重要性をスムーズに理解してもらえることが多くあります。

以下にその一例を挙げます。

望ましくない伝え方 望ましい伝え方
開発しにくくなったので、追加開発は今後半年間ストップして全面的に作り直します 今後企画されている機能を現状のアプリに組み込むとなると、3 か月程度あればできます。
しかし、半年かけて作り直すと、1 か月程度で済むようになります。さらに、今後他の追加開発も短期間で完了でき、プロダクトアップデートのスピードも速くなるメリットがあります
現在商談中の大型案件では、想定されていない規模のユーザーが一度に増えるので止めてほしいです パフォーマンステストを十分にできていないため、導入後トラブルが発生してお客様にご迷惑をおかけする可能性があります
商談中の会社は我々にとっても大事なお客様なので、受注後に解約なされると心象が悪くなってしまい、今後再提案もしづらくなると思うので、1 か月ほど時間をください。その間に、安心して利用できるための準備が整う可能性があります
現在商談中のお客様から寄せられている要望を期間内にすべて満たすようにリリースすることは不可能です 開発チームのリソースにも限りがあるので、できるだけお客様の期待に多く応えるためにも、重要度の高いものから進めたいので、必須のものを教えてください
セキュリティレベルを向上させるため、製品の導入に数百万円の投資が必要です インシデントの発生確率はだいたいこのくらいで、仮に発生した場合、弁護士費用や失った収益、信用失墜などを考慮すると、大体数千万円〜数億円単位の損失が発生します
同様のセキュリティ事故を起こした事例としては○○社があり、このようなリスクを回避できるため、導入を進めたいです

方策 5: 説明すべき事項を整理する

 プログラミング言語、フレームワーク、クラウドサービスのような技術選定、開発フローなどに関しては、あえて CEO に説明していません(もし質問があればもちろん納得いくまで説明しています)。

 なぜならば、技術選定や開発方針については完全に CTO に権限移譲されているからです。エンジニア出身でない CEO にとって専門範囲外の質問や相談を受けても、適切な判断をすることは簡単ではなく、そのような相談がなされても困るでしょう。

 仮に誤った判断をしてしまったら、CEO ではなく CTO が責任を持ってリカバリする方針にしているので、CEO にとっても本来やるべきことに集中して安心して気持ちよくビジネスの拡大を推進することができます。

まとめ

 RevCommでは "コミュニケーションを再発明し、人が人を想う社会を創る" というミッションを達成するために、上記のような方策を通して、サービスをご利用いただいているお客様の期待に応えることはもちろん、エンジニアやデザイナーが気持ちよく働ける組織を作り、さまざまな工夫やアイデアを組み合わせて目標に向かって取り組んでいます。

 ご興味を持った方は、採用中のポジションの詳細を、RevComm 採用情報で公開していますので、ぜひご覧ください。

hrmos.co