InfoQの「Product Thinking for Cloud Native Engineers」は、クラウドネイティブ時代のエンジニアに向けて、プロダクト思考をどう取り入れるかを語ったプレゼンです。
登壇したのは、DKB（ドイツのオンライン銀行）でPlatform Experience teamに所属する Stéphane Di Cesare と、SyntassoのProduct Managerである Cat Morris。
テーマはかなり実務的で、「エンジニアはどうやって“コストセンター”ではなく“価値を生む存在”になれるのか」という問いです。
これ、地味に見えてかなり重い話です。というのも、インフラや運用、Platform Engineeringの仕事って、うまくいくほど「何も起きない」のが普通だからです。
障害が起きなければ評価されにくい。便利になっても、便利になった瞬間は見えにくい。ここが本当に難しい。個人的には、この問題設定自体がすごく現代的だと思います。
ざっくり言うと、「作ること」ではなく「価値を届けること」から考える姿勢です。
エンジニアはつい「この技術が面白い」「この仕組みを入れれば速くなる」と、解決策から考えがちです。もちろんそれ自体は悪くありません。むしろ技術者として自然です。
でも、今回の話ではそこを一歩引いて、
を先に考えよう、というわけです。
この順番を間違えると、よくある「すごいものを作ったのに使われない」問題が起きます。
これはかなり痛い。技術的には美しいのに、現場ではスルーされる。エンジニアとしては切ないですよね。
Stéphaneは、90年代からITに関わってきた経験をもとに、昔のITは「プリンタを入れる人」「PCを設定する人」と見られがちで、会社からはcost center、つまり「お金を使うだけの部門」として扱われやすかったと振り返ります。
でも今は違います。
ITはビジネスの土台であり、サービスの品質やスピード、顧客体験そのものを左右します。クラウド、Platform Engineering、DevOps、Observability などは、もはや裏方の苦労話ではなく、事業の競争力そのものです。
とはいえ、現実にはまだ「最安で運用できればいい」という発想で見られることもある。
ここに対してこのプレゼンは、「じゃあエンジニア側からどう価値を語るか？」を真面目に考えています。ここはかなり重要だと思います。技術力だけではなく、価値の説明力が求められる時代です。
この発表の中心のひとつが、problem first の考え方です。
Cat Morris は、長いあいだ「問題より先に解決策を考える」失敗をしてきたと話します。
これは実は、多くのエンジニアがやりがちなことです。
「これを導入すれば解決するはず」「このツールならうまくいくはず」と思ってしまう。でも、そもそも問題の定義がズレていたら、答えもズレます。
たとえば、
で、打つべき手は全然違います。
ここで出てくるのが Product Discovery。
これは、作る前に「本当に解くべき課題は何か」を探すプロセスです。
要するに、いきなり工事に入る前に、ちゃんと現地調査をしようという話ですね。かなり当たり前に聞こえるけれど、忙しい現場ほど飛ばされがちな工程です。
プレゼンでは Double Diamond というフレームワークも紹介されます。
これは、問題解決の流れを2つのダイヤモンドで表す考え方で、
という流れになります。
ポイントは、最初から狭く考えないこと。
最初に「原因はこれだ」と決め打ちすると、ほぼ確実に視野が狭くなります。
逆に一度広げると、「自分たちは何を解こうとしていたんだっけ？」を見直せる。これはプロダクト開発だけでなく、Platform Engineeringにもかなり効く考え方だと思います。
この話で個人的に面白いのが、metrics の扱いです。
メトリクスは要するに「数字で状況を把握するための指標」ですが、何でも測ればいいわけではありません。
たとえば、開発者向けツールなら、
などが候補になります。
でも大事なのは「この数字で何を判断したいのか」です。
数字は便利です。便利すぎるくらい便利です。
でも、意味のない数字を増やすと、かえって現場は混乱します。
個人的には、メトリクスは“答え”ではなく“会話のきっかけ”くらいに捉えるのがちょうどいいと思います。
プレゼンでは、shadowing も重要な手段として挙げられています。
shadowing とは、実際にユーザーの仕事ぶりをそばで観察することです。
アンケートや会議だけでは見えない「本当の困りごと」が見えてきます。
たとえば開発者向けの内部プラットフォームを作っているなら、実際に開発者がどうやって使っているか、どこで止まるか、どこでイライラするかを見る。
これ、かなり効きます。
机上の空論ではなく、現場の動きが見えるからです。
「ユーザーはこう言っていた」より、「実際にはここで詰まっていた」のほうが強い。
このズレを埋めるのが shadowing だと考えると、すごく納得感があります。
今回のプレゼンで一番大事なのは、おそらくここです。
エンジニアの仕事は、技術的に正しいだけでは十分ではない。
その仕事がビジネスにどう効いたか を説明できると、価値が伝わりやすくなります。
たとえば、
こうした変化は、単なる技術改善ではなく、事業のスピードや信頼性に直結します。
つまり、「いい設計でした」で終わらず、「だから顧客への提供が早くなった」「だから失敗コストが下がった」とつなげるのが大事、ということです。
これは地味ですが、かなり重要です。
なぜなら、組織の中で次の投資をもらえるかどうかは、「何を作ったか」より「何を生んだか」で決まることが多いからです。
ここで誤解したくないのは、Product Thinking は「エンジニアも営業っぽくなれ」という話ではないことです。
そうではなくて、技術の仕事を、利用者と事業の価値に結びつけて考える習慣のことです。
エンジニアがプロダクト思考を持つと、
というメリットがあります。
特に cloud native の世界は、見た目以上に「何をどう作るか」より「何のために作るか」が問われます。
Kubernetes や Platform、Internal Developer Platform みたいなものは、導入すること自体が目的ではありません。
それで開発体験が良くなるのか、運用負荷が下がるのか、組織のスピードが上がるのか。そこが本丸です。
このプレゼンをひとことで言うなら、クラウドネイティブ・エンジニアが“実装者”から“価値設計者”へ進むためのヒント集です。
特に印象的だったのは、以下の3点です。
どれも当たり前に聞こえるのですが、忙しい現場ほど忘れがちです。
そして、その「当たり前」をちゃんとやるだけで、エンジニアの仕事の見え方はかなり変わるはずです。
個人的には、これはかなり実践的で、しかも嫌味がない良いテーマだと思いました。
「もっと事業を見ろ」と上から言うのではなく、「どうすれば現場のエンジニアが価値を伝えやすくなるか」を具体的に示しているからです。
クラウドネイティブに関わる人ほど、一度立ち止まって読んでみる価値がある内容だと思います。
