DXやソフトウェア開発の戦略や生産性について週1本くらいで書いてみようと思います

harajune

エンジニアもすなる戦略がたりというものを、非エンジニアもしてみむとてすなり

不明

紀貫之がそんな事を言ったかどうかはよくわからないのですが、ここ10年くらい「エンジニアの生産性」「組織論」「戦略論」というものが多数出てきています。代表的な書籍には例えば下記のようなものがあります。

こうした生産性への関心はACMなどの学会やベンチャー[sq, ft]にも広まっており、いかに「エンジニアの生産性を高めるか」はそれ自体が一大テーマとなっています。年々このあたりに関する議論は増していく傾向があるように思います。

しかしながら一方で、エンジニアの生産性を測ることに意味はあるのでしょうか？果たして生産性とは何でしょうか？こうした視点に関する共通見解はあまりないように思われます。

こうした共通見解の不足は、経営やビジネスサイドとエンジニアとの間のコミュニケーション不全の一因にもなっているように思われます。私のところにも公式に私的に「エンジニアが思ったとおりに開発を進めてくれない」というようなご相談は毎年来ます。そこで、技術ロードマップ・戦略というものを作りがちなのですが、結局なんだかうまく機能しません。

私見ではありますが、この原因は下記によるものであると考えています。

  • エンジニアリング、ソフトウェアビジネス、DXに関するメンタルモデルのばらつき

  • "生産性"はエンジニアの問題である、という勘違い

  • 人間でスケールさせることに対する過信

  • 運用コストの軽視

特に1点目については致命的です。Buid Trap[bt]という書籍が話題になるほどに、「ソフトウェアを開発すればするほどに儲かる」と信じているビジネスパーソンは多いのです。

実際のところ、ソフトウェア開発の多くのメンタルモデルが製造業や古いProject Managementに侵されています。製品を製造すればするほどに、それが売れて、価値に変わるのだから、どんどん大量に製造すればよいという発想です。そのために、エンジニアをラインに並べてベルトコンベア式に製造させようという組織構成と管理を目指しがちです。

しかし実際は違います。ユーザはスマホのアプリを開き、その上で購入するなどのアクションをとったり、エンゲージメントを高めることでサブスクリプションを継続したりすることを通して、ソフトウェア企業は収益を上げているのです。極論、システムが安定稼働していれば、エンジニアが全員寝てたところで収益は上がるのです。

では、エンジニアは本質的に何をしているのでしょうか。それが、この連載（予定）の着眼点です。予定は未定ですが、主に下記について取り上げていきたいなと思います。故あって結構忙しいのもあって、ほぼ週1連載をめざして色々書こうかと思います。

  • ソフトウェアビジネスのメンタルモデル： プロジェクト脳、製造脳からデジタルサービス脳への転換

  • 大規模組織開発は原理的に効率が下がる。例外はない。

    • 大きな組織は管理コストの割合が増える

    • プロダクトはメンテフリーではない

    • オーパーツ化する機能と失われたノウハウ（1年も立つとわかんなくなる）

    • 複雑な工程、無限に広がる影響、そして終わらない開発： 待ち工程、不意の事故による遅延、事故と遅延の連鎖

    • 十徳ナイフはなんでもあるのになんにもできない（技術負債）

    • 生み出される仕事のための仕事、コンウェイの法則

    • 伝わらない情報

  • それでもなぜ開発組織を大きくするのか

    • コア・バリュー、PDCA、投機実行。捨てる前提でのプロダクト開発。

    • ビジネスが拡大すれば、エンジニアが取り扱うべき問題領域も拡大する（DX）

    • プロダクトを作る道具を作ることの価値。模倣困難性による競争力の向上。

    • 競争力の高いプロダクトの一部は、それだけでビジネスになる（かもしれない）

  • 何をしなければならないのか

    • プロダクトのバリュー・プロポジションを理解する。何が価値の源泉なのか。

    • ソフトウェアで1万倍にできる「価値」を特定する。100倍ならやらなくていい。

    • 十徳ナイフを分解して作り直す：技術負債は踏み倒して借り直すしかない。というか返せるものではない。

    • 投機実行するための仕組み

    • 開発工程の困難を排除する。手作業の排除、イテレーションの短縮、統制の取れたリリース

    • リスクや課題を認識する。大きな組織で。

    • 機能の撤退ラインとは？（僕もよくわからない）

    • プロダクトの価値を見直す。

  • ソフトウェア開発の戦略論

    • これは、エンジニアリング戦略ではなくてプロダクトの戦略である

    • プロダクトの価値の共通理解

    • いろいろな価値をどうあげていくか。人的・技術的・組織的な戦略を統合する。

    • 役割分担、価値の探索、価値の実現、実現する手段と資源の供給

    • 戦況をどう把握するか

適宜、調査してアップデートしたところは変更を加えていく予定です。思い出しながら書くので順番は多少前後します・・・

Reference

筆者


この記事が気に入ったらサポートをしてみませんか？