価値を生み出すソフトウェアエンジニアの秘密 ~改善を積み上げて維持できるか~
こんにちは。EC系サービスの会社でプロダクトマネージャーをしている @rilmayer_jp です。
最近、ビジネス価値を生み出しているソフトウェアエンジニアについて考えています。
今回はそうしたエンジニアの特徴を整理してみようと思います。
注意点：主にWebサービス等を作るエンジニアの話です
今回はSNS、EC、検索サービスなどのアプリケーションを作って提供しているソフトウェアエンジニアについての話がメインです。
ソフトウェアの生み出すビジネス価値と時間軸
ソフトウェアが価値を生み出す瞬間
まず、アプリ等のソフトウェアでは新たな価値が創出される瞬間は「機能のリリース」であることがほとんどです。この記事ではこうした「機能のリリース」にフォーカスして話をしようと思います。
機能リリースの例としては以下のようなものとなります。
新しくアプリをリリースした
既存のECサイトに新しく検索機能を追加した
動画視聴サービスの推薦モデルのアップデートをした
注意：既存機能の提供も大きな価値を生み出している
この記事ではあまり触れませんが、すでに提供している機能の維持やメンテナンスにより生まれる価値が大きいことに注意してください。
ある程度の規模のサービスにおいて、日常的に生み出される価値を考えると、既存機能の維持・メンテにより生まれる価値の方が、新機能リリースよりも圧倒的に大きいことがほとんどでしょう。
創出価値と時間軸
ここでは、リリースした機能によって生み出される価値がどのように変化するかを考えてみます。
機能のリリースによって生み出される機能は以下のように時間軸×創出価値軸で表現することができます。
上記のようなグラフを考えたとき、リリースによって価値を提供し始めた機能がその後どうなっていくかを考えてみましょう。
2つの価値創出パターン：スパイク v.s. 積み上げ
価値変化のパターンとして、重要な2つのパターンを紹介します。
スパイク
「スパイク」は以下のような創出価値の変化パターンです。
ポイントは「一瞬価値が高まるがすぐに戻ってしまう」ところです。
例えば・・・
UIの変更によってユーザーが最初は物珍しがって使うが、すぐに誰もその機能を使わなくなる
精度高く商品を推薦できるようになったが、システムが複雑すぎてシステムがすぐに壊れた
定期的に特定オペレーションが必要な機能だが、作った担当者がリリース後すぐに退職した
積み上げ
「積み上げ」は以下のような価値の変化パターンです。
ポイントは「高まった創出価値が持続する」ところです。
このパターンの詳細はまた後ほど触れるとして、まずはそれぞれのパターンで生み出される価値の違いをみていこうと思います。
価値の大きさの違い
ここまでで確認した2つのタイプの機能による価値の生まれ方を確認します。
ここでは簡単のためにECサービスを想定して、機能リリースによって売上がどのように変わるかをみていきます。
先程のグラフの例で考えると、サービスが生み出す価値（売上）が一定であれば、時間経過に従って価値はそのまま積み上がっていきます（総売上）。
先程紹介した「スパイク」と「積み上げ」の価値の生まれ方を比較してみましょう。
このように大きな違いが生じることが分かります。
例えば、機能リリースによって一時的に売上が100万円/日上がったとします。
スパイクタイプの改善で2週間しか持続しなかった場合は総売上が1400万円（14日×100万円/日）ですが、積み上げタイプの改善でその改善が半年続く場合は1億8000万円（180日×100万円/日）となります。
もちろんこれは理想的なシチュエーションなので、現実はこんなにきれいにはなりません。ですが、両者のインパクトの違いがわかる事例ではないでしょうか。
積み上げタイプの価値を作るには
ただこうした積み上げタイプの機能をリリースするのはとても難しいものです。私が特に難しいと思うのは以下の2点です。
長期に渡ってユーザーに価値を提供することができる
長期に渡ってアプリケーションが価値を提供することができる
長期的ユーザー価値
ユーザーに企業に対して価値を支払ってもらう王道のアプローチはユーザーに対して価値を提供することです。そのため、ユーザーの価値を考えることが、サービスが生み出す価値を考えることにつながります。
例えば、「アプリケーションでユーザーが繰り返しぶち当たる課題は何か？」や「新しく導入することで、アプリの利用方法そのものが変わる機能は何か」などを解くことで長期的ユーザー価値につながる場合が多いです。
多くの企業ではプロダクトマネージャなどと呼ばれる職種が検討することが多いかと思いますが、エンジニア中心のテック企業ではソフトウェアエンジニアもこれを検討します。
こうした機能を検討して定義できることが、価値を創出できるエンジニアの1つめの特徴だと感じています。
長期的なアプリケーション稼働
ここでは、詳細には踏み込みませんがいくつか例をあげることで、長期的にアプリケーションを動かすことの難しさに触れてみたいと思います。
変更に強いアプリケーションが一つのポイントとして挙げられます。
アプリケーションや機能は作った瞬間から古くなりますが、それはサービスを取り巻く環境が常に変化しているからです。
例えば、仕事探しサービスで法律の変更に対応できないためにサービス停止となってしまったり、Eコマースで新しい商品タイプを扱えないために追加機能がお蔵入りとなってしまったりすることがあるでしょう。
こうした事態を避けるために、変更が安易なソフトウェア設計を行う必要があります。
メンテナンス可能な組織体制を構築することも重要です。
例えば、機能を作ったあなたが退職した後にその機能はメンテナンスされるでしょうか？あなた一人が永遠に面倒を見なくてはならないか、それともチームとして面倒を見ていく体制になっているかも長期的に動くサービスのポイントとなります。
上にあげた例以外にも検討すべきことは多岐に渡りますが、詳細はソフトウェア工学や組織論 (アジャイル開発なども) などの分野を参照することである程度キャッチアップできると思います。このようなソフトウェア開発の知識やスキルを持っていることが、価値を創出できるエンジニアの2つめの特徴だと感じています。
まとめ
この記事では主にWebアプリ等の構築に関わるソフトウェアエンジニアがどのように価値を生み出すかの検討をしてみました。
価値を生み出すソフトウェアエンジニアには以下のような特徴があるのではないかと考えています。
「スパイク」ではなく「積み上げ」で価値を生み出せる
積み上げ型の価値を作るために、長期的視点を元に
稼働し続けるアプリを作成できる
ユーザー体験を改善できる
また、この記事ではあまり触れていませんが、すでに提供されている機能を維持するということもまた価値を生む重要な要素であることに注意してください。
私も素敵なエンジニア目指して頑張っていきたいと思います💪
（今はプロダクトマネージャーとして働くことが多いですが・・・）
おまけ その1 ~A/Bテストの限界~
データに基づく意思決定を重視している企業では、A/Bテストと呼ばれる方法を用いてリリースした機能の効果を測定することが多いと思います。
非常に強力な手段ではあるのですが、A/Bテストでは「スパイク」と「積み上げ」の改善を見分けることが困難です。
A/Bテストでは1〜2週間などの期間で計測することが多いため、当然長期的な影響がわかりません。
そうした問題にどう対処するかについて、以前書いた以下の記事が参考になりそうです。
A/Bテストは有効ですが、長期的にどのような価値をもたらすかはそれ以外の要素も含め慎重に検討する必要があります。
おまけ その2 ~その他の価値創出パターン~
上記で紹介した以外にも、機能のリリースによる価値変化には色々なパターンがあります。ここでは特徴的な3つのパターンを取り上げて見ようと思います。
緩やかな価値低減
現実世界のアプリケーションはほとんどの場合がこのパターンになると思います。なぜなら、作成した機能はその瞬間に古くなっていきますし、時間が立つほどトラブルが起こる確立も高まるからです。
ここまでで「積み上げ」と言っているパターンも、実際はほとんどこのパターンです。
リリースした機能の価値を検討するにあたって、この低減がどのくらいのスピードで起こりそうかを見極めることは有用です。
焼き畑農業
例えばヘビーユーザー優遇施策などを行うと一時的に事業指標が改善する場合がありますが、長期的には新規ユーザーが入ってこなくなりサービスがどんどん使われなくなっていくといったことがあります。
サービスの死
ネタのように見えますが、実際にあります。
一番わかり易いのはバグを含むためにサービスが停止してしまうといった状況かと思いますが、セキュリティー要件を満たさなかったためにサービスそのものを持続することができなくなるといった復帰できないパターンもあります。