記事を書く背景
ばんくしさんの「エンジニアとビジネスの距離感の難しさ」というブログを読みました。
経営とエンジニアリングをつなぐ立場であるCTOとしては永遠のテーマだと思います。
申し遅れましたが、私はファストドクター株式会社CTOの宮田 芳郎です。昨年、ファストドクターの開発組織は、大きな技術的意思決定を経営陣とともに実施できました。具体的には次の2点です。
- アプリのFlutter化（意思決定は2022年5月）
- 新規のバックエンド開発時の言語をRubyからTypeScriptへ切り替え（意思決定は2022年6月末）
いずれも一度の経営会議で、上記の方針について経営陣との合意を取っています。
5秒でわかる記事の結論
経営陣への提案資料は下記の5点をポイントとして記述すると良い
- 実施の意義（≒ 解決したい課題）
- 必要リソース（人・モノ・金 + 時間）
- 実現コンセプト
- リスク
- 手続きの妥当性
当時の自分はさまざまな方針を、これまで積み上げてきたノウハウや経験則に基づいて決めていました。結果的にはスムーズに決定できて良かったのですが「どうして、その方針を選んだのか」をあまり言語化してこなかったことに気づきました。そこで、当時の資料や議事録を振り返って、なぜこのような順序で物事を進めて、このような説明をしたのかをこの場であらためて言語化したいと思います。
今回は「新規のバックエンド開発時の言語をRubyからTypeScript」に切り替えた時のプロセスを振り返ります。Flutter化については、記事の反応を見て読者の方々からの要望があれば書いていきたいと思います。この記事が私と同じように、なんらかの経営的・技術的な方針を考える立場にある方のご参考になれば幸いです。
RubyからTypeScriptへの切り替えを検討した当時の状況（2022年6月）
時をさかのぼって解説しますと、私がファストドクターへ入社したのは2021年の12月です。入社したタイミングでは、マーケティング部と兼任のエンジニアはいたのですが、バックエンドを書く正社員のエンジニアは私が一人目でした。私に任された大きなミッションは、開発組織づくりでした。
2022年6月の時点ではまだ入社7ヶ月目。私がファストドクターに参画してから最初に担当した大きな開発プロジェクトを、2022年5月に終えたばかりでした。そしてこのプロジェクトは、もともとの予定よりも2ヶ月ほど遅れてのリリースになりました。私もメインプログラマーとしてコードを書いていたのですが、当時このプロジェクトを通して感じていた課題は次の3点です。
- RailsのDRYが維持されたコードでよくレビューされていたが、「良くリファクタされたファットモデル」になっていた。モデルのコールバックで記述されている箇所が多く、影響範囲の推定が難しい。
- 開発の時系列のコンテキストを把握している人はコードを触りやすいが、新しく入った人がしっかり影響範囲を理解するまでに時間がかかる。
- コールセンターのオペレーター・医師やドライバーなどのロールに応じて別々の画面を使用しており、データを表示するうえでの不整合を起こしやすい。
このプロジェクトをきっかけに「アーキテクチャレイヤーからこれらの課題を解決したい」と方針を決めました。エンジニアたちとアーキテクチャの課題を話し合い、新しいアーキテクチャ案を検討しました。そして、当時月次で実施していた開発戦略会議で、5枚のスライドを用いて経営陣に説明したのです。実際に使用したスライドは以下となります。
これらのスライドで私が説明したのは次の3点でした。
- バックエンド記述言語の1stチョイスをTypeScriptにする
- NestJSをフレームワークとして利用する
- テンプレートベースマイクロサービスアーキテクチャというコンセプトとして開発していく
今回はこの事例をふまえて「技術的な意思決定を行う立場の人間が、経営陣にどのような方法で説明を行うべきか」や「上記の資料のような構成・内容にした意図」について詳しく述べていきます。
技術的意思決定と経営的意思決定のギャップ
当時の私は他の経営陣に、プログラミング言語やフレームワーク、アーキテクチャコンセプトの承認をしてもらいたいと思っていました。エンジニアにとって、プログラミング言語やアーキテクチャの選択は至極重要なトピックです。ですが経営陣から見た場合、それらの選択において重要なのは「どんなプログラミング言語やアーキテクチャを使うのか」よりも「事業や採用にどんな影響があるのか」です。
つまり、決めたいことがひとつであっても、判断する人たちが異なれば重視するポイントや意思決定のプロセスは異なることを理解する必要があります。経営陣から見た場合には、次の5点が重要なポイントであると思います。
- 実施の意義（≒ 解決したい課題）
- 必要リソース（人・モノ・金 + 時間）
- 実現コンセプト
- リスク
- 手続きの妥当性
この5点としているのは、何かのドキュメントなどに定義があるわけではありません。私のマネージャーとしての経験から、これら5点の原理・原則が重要であると感じています。そのため、経営判断に用いるための資料は、この5点が伝わるできるだけ短い端的な内容が優れていると思います。短い時間で良い判断をできるようにするためです。
経営者によってはもっと違うところを見る人もいると思います。たとえば「結局は担当者の情熱が重要」と考え、説明者の熱量のみで判断する経営者もいるはずです。ある程度は説明する相手の特徴に合わせて資料をチューニングする必要がありますが、あくまで上記の原理・原則を押さえたうえで、説明内容を相手のパーソナリティに沿わせるくらいが良いと思います。あまりに特定の人のパーソナリティに合わせすぎても、結局後で苦労しますから。
端的さの定義も相手に応じて変わります。エンジニアという立場では「Next.jsにするかNestJSにするか」をけっこう悩んだのですが、その比較は冗長になると思って資料には含めませんでした。当社の経営陣はテック分野には明るいものの、プログラマーバックグラウンドではないので、それを説明に含めると内容が散漫になってしまうためです。もちろん、質問されれば説明できる準備はしていました。
説明資料のアウトラインのつくり方
経営提案をする際の資料の構成について、訓練を受けたことのあるエンジニアは稀だと思います。そのため、資料作成における基本の“型”を把握していないエンジニアも、きっと多いでしょう。型を持たずにゼロベースで資料作成し、うまく説明できなかったとすると、それはエンジニアにとっても経営陣にとっても不幸なことです。
経営的意思決定のための資料には一定の型があるように思います。私は提案資料について、次の2つの型から選んで構成しています。
- （背景 →）課題 → 実現したいこと → 実現手法
- ビジョン（実現したいこと）→ 戦略 → 戦術
今回は課題解決のストーリー説明だったので、前者で構成しました。新規性が強いプロジェクトでは後者を選ぶ事が多いです。提案資料の基本構成は知識さえあれば、出来栄えが大きく変わります。これまで研修を受けたことのない方は、ぜひ1冊でも良いので本を読まれることをおすすめします。たとえば以下などは良質な参考書です。
マイクロソフト伝説マネジャーの 世界№1プレゼン術 | 澤 円 |本 | 通販 | Amazon
経営陣へ説明した具体的な内容
ここからは、前述の資料を用いて具体的に経営陣へ何を説明したのかと、その意図を解説していきます。
実施の意義（≒ 解決したい課題）
まず1枚目には解決したい課題を置きました。直前の大きな開発プロジェクトで感じた課題について整理しています。実際にスケジュールも遅れてしまったため、現状や将来的な懸念を正直に説明しています。スケジュールの遅れについては経営陣にもレポートしていたので、その原因について私なりの見解を説明すべきタイミングでもありました。
実現したいこと
2枚目にはアーキテクチャ変更によって実現したいことを書きました。「説明を受ける人たちが、施策の意義に共感できるか」はエンジニアリングに限らず経営判断の大前提です。このレベルの抽象度で聞き手が疑問に思うような状態ならば、提案は考え直した方が良いと思います。
実現したいことを説明するうえで「解決したい課題」と「私が組織上与えられたミッション」をまとめて、少しエンジニアリング方向にブレイクダウンしたものを記述しています。これは、次のスライドの実現コンセプトにつなげるためです。
私が経営から委託されているミッションは「開発組織の立ち上げ」です。あまり難しく捉えず、新しいことをあまり含めず、与えられているミッションを簡単にブレイクダウンした程度の記述で書いています。本質的なことほど、難しくなくシンプルに表現できると思うのです。
メインのメッセージは、開発組織が生産性を落とさずにスケールしていくのに必要な技術選択として説明しました。逆にいうと私のミッションが開発組織のスケールでなく、サイズを変えなくてよいのであれば、技術選択を変える必要はなかったです。
ポイント: 事業実現に直結しない開発工数を抑える
振り返ってみると、スライドには定性的な記述しか書いていないなと感じるのですが、この内容で十分であると当時考えたのには理由がありました。事業実現に直結しない開発工数を1人月程度に抑えたからです。事業的な価値向上に繋がる開発工数・コストは事業投資として理解してもらいやすいです。一方で「技術的負債の返済」のようなストーリーで語られる開発項目は、開発者体験や開発スピードに繋がるものの、開発者以外にとって理解が難しいものです（説明すれば理解してもらえないものではないです）。
これは説明を受ける側の人々が、開発業務を日常的に行う人ではないからです。料理人が使う包丁の良し悪しを説明しても、エンジニアが直感的にイメージできないのと同じことです。「よりスピーディーにお客さまへと料理を提供できるようになる」とか「お刺身の舌触りが良くなる」など、事業上重要なKPIや顧客体験に紐づけて説明されることで、すんなり理解できるものなのです。
料理人にとっての包丁の例と違って、技術的負債の返却は事業上の副作用を伴います。しばらく新規開発を止めることになるからです。開発スピードが上がる可能性があること、開発社体験が向上することと引き換えに、事業上の新規トピックが止まる事になります。異なる軸でのトレードオフでの判断になります。
施策の是非について議論するのは難しいです。軸を揃えることも一苦労です。エンジニアリングはリソース数だけでスループットが説明しづらいです。平気で他のメンバーの10倍・20倍のスループットを出すエンジニアもいます。つまり、決断のための方程式がシンプルではないのです。
こうしたジレンマを回避するために、私は技術的負債の返済のような性質のプロジェクトの場合、投資工数を最小限にして提案するアプローチを取っています。事業実現に直結しない開発工数を抑えるということです。イノベーティブな新規事業をペーパープロトタイプから始めるように、大きな技術的意思決定も小さく始めるのがポイントだと思っています。
必要リソース（人・モノ・金 + 時間）
前述の通り、共通部分として開発する範囲は小さく抑えるアプローチで考えました。「1年間新規開発を止めてすべてを書き直したい」という極端な提案をせず、「小さく始めて手応えを確かめながら拡張していく」ようなストーリーで話しています。
プログラミング言語の変更やフレームワークの変更は、エンジニアから見ると人生に関わるほどの大きな変更です。しかし経営観点では、それが重要であるかどうかは必要なリソースのサイズ次第です。とはいえ、いくら初回のリソース投資がいくら小さいものであっても、言語選択やアーキテクチャ選択は、今後の事業体制や開発進捗の傾きに強く影響するほどの重要な意思決定です。
そのため、他の経営陣へと入念に情報を伝えたうえで、実施の是非を判定すべきだと思っていました。ここからは説明の際に留意したことや、方針を決めてからの行動について述べていきます。
実現コンセプト
エンジニアリングの内容の詳細を伝え過ぎても、他の経営陣に理解してもらうことはできません。
しかし、どのような工夫なのかという本質的な構造は説明すべきだと考えています。What、Why、Howを、2〜3枚くらいのスライドでまとめられると良いと思います。
状況として、今後の
- 拡張するエンジニアリング組織
- 拡張していくプロダクト
を想定したときに、重要になってくる
- 部品の再利用性を高める
- 開発時の影響範囲を切り話す
- リソースの流動性を高める
など、アーキテクチャの骨子になる部分に絞って説明します。
エンジニア的には、トランザクションの分割をどのように実現するか、なども気にはなりますがそこまでは含めません。重要な観点であっても、エンジニア以外と議論が成立するトピックではないからです。こうしたテーマはエンジニア同士で議論し、設計フェーズで解決すべき問題とします。
リスク
「リスクの度合いが適度かどうか」もポイントとしてあると思います。要するに、リスクを取りすぎるのも良くないし、取らなすぎるのも良くないです。
一般論として、リスクを取らなければゲインも少ないです。ただ、大きなリスクを取りすぎるとお客様に迷惑をかけてしまったり、メンバーに負担がかかり離職につながったりすることもあります。基準としては、自分が責任を取れるかどうかだと思います。
もちろん、自分が責任を取れない範囲の提案をしても良いですが、そのようなシーンではリスクについてしっかりした説明が必要です。今回の提案は、「小さく始めたい」というものだったため、リスクについての資料は作りませんでした。
手続きの妥当性 〜エンジニアたちと合意形成をしたプロセスも含めて、経営陣に説明する〜
チームビルディングや内部統制の観点から「どのような手続きでアーキテクチャ方針の検討を行ったのか」は重要です。経営判断において、そのプロセスについても当然チェックされるべきだと思います。今回のシーンで言えば、現場エンジニアの賛同を得られる進め方ができていたのかが重要なポイントです。当時の私の肩書は技術開発部長でしたが、社歴としてはたかだか7ヶ月です。その私が、独断で意思決定していたとしたら、「そもそも、適切な方法で結論を出せているのか」すらも疑われてしまいます。
今回の事例では、事前にエンジニアたちと中長期的なアーキテクチャの課題を話し合う会を1.5時間程度実施して、資料にはその議事録を貼っています。話してみた結果として、前からいるエンジニアも新しく来たエンジニアも、課題の認識に大きなズレはありませんでした。別な部分についてもコンフリクトがなかったので、いい感じに方針をマージしてアーキテクチャプランを考えました。
説明した結果
一度の開発戦略会議にて、その方針で進めて良しという意思決定を頂く事ができました。
テックリードをプロジェクトに2ヶ月程度アサインして、骨子の開発を進めてもらい、少しずつプロダクションシステムへの反映を進めています。
振り返ってみて、経営陣と話して決められて良かった点として「その後の迷いを少なくできた」ことが挙げられます。もしも、きちんとしたプロセスを経て方針を決めていなかったならば、「やっぱりこのやり方の方が良いのではないか」「もう一度立ち直って考え直すべきではないか」などと悩むこともあったかもしれません。でも、そのように思うことはありませんでした。
まとめ
技術的意思決定の経営提案に含める5項目
- 実施の意義（≒ 解決したい課題）
- 必要リソース（人・モノ・金 + 時間）
- 実現コンセプト
- リスク
- 手続きの妥当性
技術的意思決定と経営的意思決定のギャップ
技術的意思決定の大きさと経営的意思決定の大きさは比例しません。方針を考えるうえで大事なのは、追加の投資リソースをいかに小さく抑えるかです。これを極小化するプランを考えられれば、エンジニアから見て大きな技術的意思決定だとしても、経営観点では小さく見えるような構図を作る事ができます。経営を理解し、経営にとって利点のある技術的投資を表現していくべきだと思います。
新しい仲間を募集しています
ファストドクターは仲間を絶賛採用中です。少しでもご関心を持っていただけましたら、お目を通して頂けると幸いです。
