まえがき
こんにちは。Owners Experience Backend Group の杉浦です。主にサーバーサイドのアプリケーションの実装をしています。
エンジニアとして働いていると、当然、技術的なことには意識を向けるのですが、ROI(Return of Investment = 投資利益率)を意識することはあまりないと感じたので、この観点でエンジニアリングを考察しました。
想定する読者としては、下記を意識しています。
エンジニアの方で、ROIというビジネスの概念を知りたい方
エンジニアではない方で、ROIの観点でエンジニアリングの理解を深めたい方
このため、テックブログではあるものの、エンジニアではない方にも趣旨を理解いただけるように、技術に関しては少々噛み砕いて書いています。普段、コードには触れないビジネスパーソンの方にとっても、エンジニアリングを理解する一助になりましたら幸いです。
なお、筆者である私は、エンジニアに転生する前は、上場企業を対象とした投資会社で働いていました。普段からROICや競争優位性といったテーマに想いを巡らせてきたこともあり、本稿のバックグラウンドになっています。
リーディングガイド
このテックブログは3章からなります。
第1章では、ROIの再定義を試みています。エンジニアリングの世界では、そもそも金額効率を見るのがナンセンスであり、時間効率を意識すべきという、少々過激なスタンスをとっています。
第2章では、ROIを意識したエンジニアリングの実践例を書いています。「Facebookドメイン認証の自動化」というプロジェクトを例に、エンジニアが意識すべきポイントを考察しています。キーワードは「不確実性の可視化」です。
第3章では、ROIを意識したエンジニアリングがビジネスに競争優位をもたらす道筋を提示します。キーワードは「綺麗なコードは見えざる資産」です。
エンジニアではない方は、第1章と第3章をお読みいただければ論旨を理解いただけます。1分で結論を知りたい方は、第3章だけお読み下さい。
第1章 ROIの本質は何か?
伝統的なROIでは資金効率をみるが・・・
ROIはビジネスにおける金額効率を判定する指標です。
分母に投資額(Investment)、分子に利益額(Return)を設定して計算します。少ない投資額に対して、利益額が多ければ多いほど良い、というわけです。
ROIの分母である「投資」を広義の意味で捉えると「ヒト・モノ・カネ」といった希少資源に対する配分と定義できます。
たとえば、製造業の場合は「工場で使う工作機械や金型」、不動産デベロッパーの場合は「土地の仕入れ」、保険会社であれば「営業人員の人件費」、流通問屋であれば「在庫の確保」といった具合です。
企業は競争に勝つために、ビジネスで欠かせない要素に傾斜投資するため、ROIは本質的に「何に重点投資をするか?」という意思を問うものになります。
つまり「利益を生み出す効率を最大化するために、どの部分に、いくら投資すべきかを、よく吟味しましょう」というのが、ROIの存在意義になります。
ソフトウェアは「ヒト・モノ・カネ」で捉えられない
では、ROIの分母である「投資」について、ソフトウェアのエンジニアリングの観点では、どのように捉えたらよいのでしょうか?
伝統的なROIを踏まえると「ヒト・モノ・カネ」が分母の値として適しているように見えますが、ソフトウェアの世界にこの考えを適用するのは少々危険です。
「ヒト」に関しては、エンジニアの頭数を増やせば良いという安易な考えは禁物です。場合によっては、開発現場に混乱をもたらして、逆に生産性が下がるかもしれないからです。
「モノ」に関しては、必要最低限でまかなうことができます。ソフトウェア企業における固定資産への投資はパソコンやサーバーに限られるからです。
「カネ」に関しては、投資金額を増やせば素晴らしいソフトウェアが完成するという、単純な関係は成立しません。
優れたソフトウェアの例では、エンジニアたちに愛されている様々なライブラリーは、OSS(オープンソースソフトウェア)によって、ほぼ無償で開発されています。
逆に、悪いソフトウェアの例では、何百億円、数千億円という莫大な金額をかけたプロジェクトが「稼働したら実は致命的なバグだらけだった」「全く稼働しなかった」というのは、この業界ではよく耳にする話です。
もちろん、お金は大切であり「Cash is King」はまさしくそうなのですが、「単純にお金をかければ良いのだ!」というわけではないところが、ソフトウェアの難しいところです。
ROIを意識したエンジニアリングでは時間効率をみる
では、ROIにおける分母の「投資」は、エンジニアリングにおいて、どのように捉えたらよいのでしょうか?
私の結論は「投下時間」を設定することです。
伝統的なROIが「資金効率」を測定するものであったのに対して、エンジニアリングのROIでは「時間効率」をみるということです。
あえて時間軸を見る理由は、ソフトウェア企業にとって「スピード」こそがサービスの成否を決める重要な要素だからです。
この業界では、厳しいグローバル競争が繰り広げられています。変化し続けるユーザーのニーズに応えるために、素早く機能をアップデートして、サービスの改善改良を継続しないと、長期的には存続できません。
ちなみに、BASEではMove Fastを行動指針の1つとして掲げていますが、同じような方針を掲げる企業は数多くあります。
これは「スピードを意識しないと、その先にはDieが待っているから」であり、明文化して常に意識しなければならないほど、激烈な競争が繰り広げられているからにほかなりません。
利益額を意識すると間違いを犯す
次に、ROIの分子である「リターン」は、エンジニアリングにおいて、どう捉えたら良いのでしょうか?
伝統的なROIのリターンには、利益額が設定されます。当然のことながら、生み出す利益額が多ければ、これに越したことはありません。
では、ROIを意識したエンジニアリングにも、リターンに利益額という指標を使用してよいのでしょうか?
答えはノーです。なぜかといえばソフトウェア企業には「時間軸のジレンマ」が存在するからです。
たとえば、新しい機能を実装してリリースしたとしても、短期的には「ユーザーの獲得」などに大きく貢献しない場合があります。リリースした機能がユーザーにとって使い勝手が悪かった場合、ユーザーが欲している機能であっても、その目的を達成できないからです。
ところが、その後、関連する別の機能がリリースされたり、UIが改善されたときに、かつてリリースした機能がベースとなって、ユーザーの獲得に大きく貢献することは珍しくありません。
ソフトウェアは連続的かつネットワーク的に発展する技術であり、各パーツ(=機能)の統合によって、ユーザーに新しい便益を提供することができるという性質があります。
よって、ある機能をリリースした直後、つまり時間軸の初期段階では「利益」を期待することができません。
このため、利益額を前提とした意思決定はミスを犯すことになります。「短期的に利益が出ないなら、その機能の開発はストップしよう」という判断は、一見すると合理的に見えますが「時間軸によるネットワーク効果」を無視した行動になり得るからです。
エンジニアリングにおいて、短期利益を重視するスタンスは「長期利益を放棄する」ことを意味します。逆説的ですが「目先の利益を最大化するぞ!」という姿勢は「ぜんぜん貪欲じゃないなぁ・・・」とさえ思えます。
ユーザーが抱える問題の解決を意識する
では、ROIを意識したエンジニアリングにおいて、分子の「リターン」には何を設定すべきでしょうか?
その答えは「ユーザーが抱える問題の解決」です。
ただし、問題解決の内容を具体的に定義することはできません。なぜかといえば、ユーザーが抱える問題のパターンは無限に存在しており、一つには決定できないからです。
たとえば、新しくリリースする機能が「ユーザー獲得につながる」のか、「ユーザーの維持につながる」のか、もしくは「コストダウンにつながる」のか、その狙いはプロジェクトの性質や、企業の成長フェーズによってさまざまです。
遂行するプロジェクトの性質によって、リターンに設定すべき値を考えなければならないと言えるでしょう。
第2章 ROIを意識したエンジニアリングの実践
「Facebookドメイン認証の自動化」プロジェクト
それでは、実際に、ROIを意識して、どのようにエンジニアリングを実践していくのがよいのかを見ていきます。
今回取り上げるのは、2021年9月8日にリリースした「Facebookドメイン認証の自動化」というプロジェクトです。BASEとInstagramを連携するために、ユーザーがFacebookを通じてドメイン認証を行う必要があり、このフローを自動化するという狙いでスタートしました。
このプロジェクトは、実装者としては、私が1人で携わる形になり、試験的にROIを意識する良い機会だと思って(こっそりと)実践することにしました。
リリースにいたる背景
このプロジェクトが立ち上がった理由は、いままでのドメイン認証というフローが、Instagramを連携したいユーザーにとって、ボトルネックになっていると考えられたからです。
従来の機能では、ユーザーに「metaタグを設定する」というアクションを求めていました。
metaタグとは、HTMLで定義される要素の1つです。metaタグに認証用のコードを埋め込むことによって、外部のシステムがサイトの所有者を確認するために使用されます。
ですが、metaタグという概念は、エンジニアリングの専門的な知識であり、本来、ユーザーが知る必要はありません。
したがって、metaタグの設定を含めたドメイン認証のフローを、すべて自動化することによってユーザーの不便を解消し、「ドメイン認証が完了したショップ数を増やす」というのが目指したゴールでした。
このような事情があったため、リリースは1日でも早いほうが良い、という状況でした。
そこで、ROIを高める観点で、4つの方針を立てました。
方針1 バックエンドとフロントエンドを1人で実装する
方針2 ユーザーに通知するエラーを限定する
方針3 リリース後の分析項目を限定する
方針4 不確実性を下げるためにコミュニケーションする
方針1:バックエンドとフロントエンドを1人で実装する
素早い改修を行うために、最初に決めた方針が、実装者である私自身がバックエンドに加え、フロントエンドの実装も同時並行で行うことでした。
この理由は、ドメイン認証にあたっては、外部システムから提供される複数のAPIを叩くため、不確実性が高いことが予想されたからです。
本来は、API仕様書に記載された内容を精査することはもちろん、実際にAPIを叩いて、想定されるすべてのパターンを設計に盛り込むべきです。
ですが、限られた時間の中で、API仕様書を抜け漏れなく確認することは非現実的でした。リリースが遅れてユーザーに不便を強いる期間が長引いてしまうことも、好ましくありません。
そこで、今回の実装では「外部のAPIは不確実である」という前提を置き、実装の途中で想定外の仕様を発見した場合は、バックエンドとフロントエンドへの修正が必要になることを考慮しました。
したがって、予期しない修正によって生じる調整コストを最小化するという観点から、サーバーとフロントを1人で実装することが合理的であると判断したのです。
方針2:ユーザーに通知するエラーを限定する
システムが取り扱うエラーのパターンが多い場合、その全てをユーザーに表示することは現実的ではなく、取捨選択が必要になります。
ドメイン認証を実行する際も、外部システムのAPIを複数叩く必要があり、それぞれのAPIに対して複数のエラーのパターンが存在します。このため、ユーザーにエラーを伝えるという観点において、対応範囲を絞ることが有効と判断しました。
今回の実装では、ユーザーにとって遭遇しやすいエラーはその理由を画面に表示する一方で、頻度の少ないエラーが発生した場合は、ヘルプページに取るべきアクションを記載する形をとりました。
方針3:リリース後の分析項目を限定する
リリースをした後に必要なのが分析です。この内容が「次にどうアクションすべきか?」という意思決定の材料になります。エンジニアとしては「分析を楽にする」ことも視野に入れて、実装しなければなりません。
そこで今回は、分析で測定すべき項目を下記に限定しました。
ドメイン認証に成功したユーザー数
ドメイン認証に失敗したユーザー数
失敗した場合のエラーの原因
これらのデータが取得できれば「失敗率」と「失敗理由」が判明するため、仮に失敗率が高かった場合に、BASEとしてとるべきアクションが明確になります。
具体的な実装方法としては、APIの実行時にログを内部出力するコードを仕込み、Elastic社が提供するログ解析ツールのKibanaによって分析できるようにしました。実際に分析結果をまとめるところまで、エンジニアとして対応しています。
なお、今回の分析では、データベースのテーブルに分析用のカラムを追加することを、あえて避けています。
その理由は、外部システムとの連携を前提とするため「認証済みである・認証済みではない」というステータスを、BASEのシステムでは管理できないからです。ユーザーが自分自身でmetaタグを埋め込んで、BASEを介在させずに、外部システムから認証することも考えられるため、この方法で認証に成功した場合、BASEのシステムは感知できません。
一方で、分析用のカラムを使わないことは、代償を伴います。テーブルをjoinするといった複雑な分析の可能性を放棄していることや、ログの分析は実装したエンジニアが行わなければならないからです。
今回は、ログを活用して十分に検証できると判断しましたが、分析用のカラムを活用すべき局面もあります。このあたりの方向性は「何を分析すべきなのか?」「誰が分析するのか?」という観点から考える必要があるでしょう。
方針 4:不確実性を下げるためにコミュニケーションする
あらかじめ完璧に設計したという自信を持っていても、不測の事態は起こり得るものです。
今回のプロジェクトでは、万一の事態に備えるために、頻繁にコミュニケーションを取ることを意識しました。
プロジェクトの責任者の方に毎日進捗を報告し、APIの仕様に不明点があれば詳しい方に質問し、不確実性の共有と可視化に努めました。
社内で検討してもわからないAPIの仕様があったときには、外部の企業に直接問い合わせたため、実装時間と同じくらい、コミュニケーションにも時間を割く形となりました。
つくづく、エンジニアリングとは、不確実性との闘いだと思います。
コードの品質を妥協してはいけない
ROIを意識したエンジニアリングを通じて、妥協してはいけないのがコードの品質維持です。
実装時間を短縮するために、綺麗ではないコードを容認してしまうと、次のエンジニアが実装に取り掛かる際に、ROIが大きく低下します。綺麗ではないコードとは「責務が適切に分離されず、リーダブルでなく、テストが十分ではない状態」と捉えています。
今回の「Facebookドメイン認証の自動化」の実装にあたっては、既存のコードから多くの恩恵を受けました。ビジネスロジックを扱う層が的確な粒度で分離されており、テストコードも過不足なく存在していたため、実装スピードの向上が可能になったからです。
品質の高いコードを将来に継承することも、ROIを高めるうえで大切な事だといえます。
第3章 競争優位をもたらすROIエンジニアリング
綺麗なコードは「見えざる資産」
ROIを意識したエンジニアリングが、ビジネスの競争優位に結びつく道筋は次の通りです。
インターネットを取り巻く技術は常に変化する
それに伴ってユーザーが求めるニーズも日々変化する
したがって、リリース頻度を高めることが競争優位につながる
そこで、時間効率を意識したROIエンジニアリングが有効になる
競争優位の持続には「綺麗なコード」の資産化が欠かせない
このなかで、エンジニアのご経験がない方にとって理解しにくいことが「エンジニアが綺麗なコードに執着する理由」かと思います。
コードにおける「綺麗」をわかりやすく言い換えると「エンジニアの誰もが理解しやすいように書かれており、将来の改修可能性を考慮した状態のこと」をいいます。
つまり「綺麗なコード」がシステムの内部に蓄積されていれば、将来にわたってエンジニアによる実装のスピードは向上するため、リリースの頻度が高まり、結果としてビジネスにおける競争優位をもたらします。
逆に、コードを「汚くても良い。動けば何でも良いじゃないか」と捉えた瞬間、短期的にはリリースのスピードを向上できたとしても、そのシステムは長期的に競争優位を失うことになります。
なぜならば、一度でも窓ガラスが割れてしまうと「綺麗なコード」を書く規律が失われてしまうからです。こうなると、システムにおける不確実性が高まり、エンジニアは疲弊します。そして、その噂は必ず広まり、新たにエンジニアを採用できないという、悪循環に陥ります。ここまでいくと、もはやなす術がありません。
コードの品質には「普通」という曖昧な概念は存在せず、「綺麗である」と「綺麗ではない」の2つしか存在しません。いわば真偽値(boolean)です。
そして「綺麗なコード」への規律を保つことは容易ではないからこそ、規律を維持できれば差別要素になります。
この意味で「綺麗なコード」は、競争優位性を持続させるためのカギであり、貸借対照表における「見えざる資産」なのです。
ROIを意識したエンジニアリングの限界
ROIを意識したエンジニアリングには、ある限界が存在します。
それは、ROIを追求した先に「ビジネスにおける長期利益の最大化が達成されなければならない」ということです。
ROIを意識したエンジニアリングには、利益額を設定できないという限界が存在します。しかしながら、サービスの提供者が株式会社である以上、長期的に利益を生み出すシナリオを描けないと、いずれ財務危機に陥ります。
つまり、エンジニアリングのROIを最大化したとしても、ビジネスを通じて長期利益を獲得する「筋書き」が存在しないと、従業員・株主・経営者の苦労は報われないということです。
この点は、ROIを意識したエンジニアリング「だけ」を追求したときの限界として、胸に刻んでおく必要があります。いくらリリースの時間効率を高めて、綺麗なコードを書き続けたとしても、その事業が長期利益に結びつかなければ意味がありません。
エンジニアリングとは、目的を実現するための手段であり、目的そのものではないのです。
終わりに & 宣伝
エンジニアリングに終わりはない
ここまでROIを意識したエンジニアリングについて考察をしてきましたが、あくまで、現時点の私見であり、未完成の考察になります。エンジニアリングで投資効率を考えるという、少々突拍子のない論考であり、しかもROIの定義を強引に変更しているため、完成された思索でもないからです。
そして、web業界の激しい変化の渦中にあっては、完成することを目指すべき論考でもない、と感じています。仮に完成されたとしたら、それはweb業界の発展がストップしたことを意味しますが、当分の間、このような状況が来ることはないでしょう。
あくまでも、ユーザの抱える問題を解決するために、最適なエンジニアリングの方法を模索し続ける姿勢が大事なんだなと、日々、感じています。
いつもの宣伝
BASEではサービスを発展させるうえで、エンジニアも募集しております! カジュアル面談も実施しておりますので、お気軽にお問い合わせください!
参考文献(書籍)
- エンジニアリングの視点
- Bill Karwin『SQLアンチパターン』オライリージャパン、2013年
- Dustin Boswell、Trevor Foucher『リーダブルコード:より良いコードを書くためのシンプルで実践的なテクニック』オライリージャパン、2012年
- Thomas Kuhn『科学革命の構造』みすず書房、1971年
- 大野耐一『トヨタ生産方式:脱規模の経営をめざして』 ダイヤモンド社、1979年
- 成瀬允宣『ドメイン駆動設計入門:ボトムアップでわかる!ドメイン駆動設計の基本』翔泳社、2020年
- 広木大地『エンジニアリング組織論への招待:不確実性に向き合う思考と組織のリファクタリング』技術評論社、2018年
- 投資の視点
- John Kenneth Galbraith『不確実性の時代』TBSブリタニカ、1978年
- Nassim Nicholas Taleb『ブラック・スワン[上]:不確実性とリスクの本質』ダイヤモンド社、2009年
- Nassim Nicholas Taleb『ブラック・スワン[下]:不確実性とリスクの本質』ダイヤモンド社、2009年
- Scott Kupor(2019). Secrets of Sand Hill Road: Venture Capital―and How to Get It. : Virgin Books.
- 中神康議『三位一体の経営:経営者・従業員・株主がみなで豊かになる』ダイヤモンド社、2021年
- 経営の視点
- 大津広一『企業価値を創造する会計指標入門』ダイヤモンド社、2005年
- 楠木建『ストーリーとしての競争戦略』東洋経済新報社、2013年
- 三品和広『高収益事業の創り方(経営戦略の実戦(1))』東洋経済新報社、2015年
- 社会の視点
- Daniel Bell『脱工業社会の到来:社会予測の一つの試み』ダイヤモンド社、1975年
- 今井賢一『情報ネットワーク社会』岩波書店、1984年