🤔

なぜDevOpsは開発内容にフォーカスを当てないのか

2023/01/31に公開

こんにちは島田です。
今日は私がDevOpsについてあれこれ考えていたときに生じた1つの疑問と私なりの仮説・理解について話していきます。

なぜDevOpsは開発内容にフォーカスを当てないのか

DevOpsについての本や記事を読んでいると、

  • 📊FourKeysを測定しよう
  • 📈開発生産性を高めよう
  • 🚀CI / CDを整備しよう

など、仕組みやメトリクスについての話題を多く見かけます。
これはLeanとDevOpsの科学でも語られているように、開発生産性の向上によって、会社の競争優位性が高まることを論拠にしていると思われます。

しかし、ここで1つの疑問が生じました。

🤔「なぜ、開発した内容にフォーカスを当てないのだろう」

いくら早く機能を届けたとしても、よりユーザーに価値を届けられる機能を開発した方が会社の競争優位性は高いはずです。

  • 一般的な理論へ落とし込むために、具体の内容を切り捨てている
  • それはDevOpsではなく企画の仕事だ

とも言えますが、もう少し深掘ってみます。

第4次産業革命の時代

いきなりソフトウェアと関係ない話で申し訳ありませんが、製造業における産業革命の変遷についてみていきます。


革命 特徴
第1次産業革命 18世紀後半、蒸気・石炭を動力源とする軽工業中心の経済発展および社会構造の変革。イギリスで蒸気機関が発明され、工場制機械工業が幕開けとなった
第2次産業革命 19世紀後半、電気・石油を新たな動力源とする重工業中心の経済発展および社会構造の変革。エジソンが電球などを発明したことや物流網の発展などが相まって、大量生産、大量輸送、大量消費の時代が到来。フォードのT型自動車は、第2次産業革命を代表する製品の1つといわれる
第3次産業革命 20世紀後半、コンピューターなどの電子技術やロボット技術を活用したマイクロエレクトロニクス革命により、自動化が促進された。日本メーカーのエレクトロニクス製品や自動車産業の発展などが象徴的である
第4次産業革命 2010年代現在、デジタル技術の進展と、あらゆるモノがインターネットにつながる IoTの発展により、限界費用や取引費用の低減が進み、新たな経済発展や社会構造の変革を誘発すると議論される


参考:第4次産業革命における産業構造分析とIoT・AI等の進展に係る現状及び課題に関する調査研究
https://www.soumu.go.jp/johotsusintokei/linkdata/h29_03_houkoku.pdf

大量生産・大量消費の時代から、個々のニーズにマッチしたものづくりへシフトしています。
今までは物を作れば作るほど儲かっていたが、消費者のニーズは多様化していきました。
そこで出てきているのが、3Dプリンタによるプロトタイピングの高速化や情報の統合による高精度な予測です。
これは裏返すと、消費者が何を欲しているか、予測が困難であり、消費者自身も何が欲しいか言語化できない状態にあるわけです。

お客様のニーズの変化

もう少し一般的な話をしましょう。
消費者は一体どんなモノが欲しいと考えているのでしょうか。そしてどう変化して行ったのでしょうか。

もの自体が貴重だった時代から必要なものはある程度揃うようになり、価値が飽和していきました。
その結果、消費者は画一的な製品に飽きてしまい、より自分の好みに合った、製品・サービスを欲するようになります。
さらにその先で何が欲しいか、消費者自身も言語化できないようになりました。

ビジネススタイルの変化

上記のニーズの変化に伴って、ビジネススタイルも変容していきました。

欲しいと言われたものを作るビジネススタイルから、一般的な提案ではなく、よりお客様の状況に沿った解決策の提示が必要になっていきました。
さらには、お客様自身がどんな問題を抱えているかを言語化するところから併走し、問題発掘から解決策の提案までを担う必要が出てきたのです。
これはカスタマーサクセスやCustomer Reliability Engineeringの概念に似ています。

これからリリースする機能は"仮説"である

さて大分遠回りしましたが、表題に戻ります。

🤔「なぜ、開発した内容にフォーカスを当てないのだろう」

大前提として、リリースした機能が実際に使われる(価値を発揮する)かどうかは実際にリリースするまでわかりません。
そのためPDCAを高速に回して、リリースした機能の検証(ユーザーからのFBをもらう)を行い改善を回して行く必要があります。

重要なのは試行回数

機能の良し悪しはもちろん重要ですが、開発段階ではそれはあくまで仮説でしかありません。
そのため早くリリースして早くユーザーFBをもらう必要があります。
試行回数を増やすために開発生産性を高める必要があります。
デプロイ頻度や変更のリードタイムは1サイクルがどれだけ速く回っているかを示す指標なので、理に適っていると言えそうですね。

終わりに

表題の疑問に対する私の結論は「価値仮説の検証サイクルを回すスピードを早くすることで、企業の競争優位性を高めるため」というものです。
DevOpsは「あくまでリリース前の機能は価値仮説なんだし、ユーザーに使ってもらうまでわからないんだから、早くサイクル回そうぜ」という前提の上に立っているのかなと感じています。
「推測するな、計測せよ」に似たものを感じますね。最初からあれもこれもと考えるのではなく、まずは作ってみましょう。

https://qiita.com/e99h2121/items/e8f899756b21b0414835

ソーシャルデータバンク テックブログ

Discussion