はじめに
この投稿はポエムです。 技術的な記事を期待してる人はブラウザバックお願いします！ なおこの文書は諸々の理由により、一部ぼかしたところがありますがご容赦ください。
TL;DR
- 有名になった方法論は、目的が忘れられて、手段だけ広がることがある
- 手段が「守らねばならぬルール」になって目的を達成できないことがよくある
- 何か手法を取り入れるときは手段が目的化してないか気をつけねば
本文
先日、勉強会にて、とあるベンチャー企業の営業職の方とちょっと話す機会がありました。 その方は最近営業チームのマネージャーになられたとのことで、組織設計のお話をされまして「The Model的に営業のプロセスを細かく分割し、分業を進めて、KPIで成果を追えるようにした。現在は分業のメリットを感じている」 「The Model は The Goal を参考にしているとのことなので、ソフトウェアエンジニアの人も使える知見があるかも知れませんね」と言われました。
そのとき「あれ？」ってなりました。自分の記憶だとThe Goalは、生産プロセス全体をチェーンのようにつなげ、ボトルネックを発見し、 その改善に注力することでスループットを上げることを目的とする方法論だったからです。 なので、聞いた方法は The Goalの目的を達成するための方法論とは思えませんでした。 むしろ全員でボトルネックの業務をやる(もちろん仕組み・ツールで解決するまでは)方が、The Goalの目的に適うと思ったのです。 ネットで記事を漁ってみても分業に関する記事ばかり目に入るので、僕の理解に不安を覚えました。
インサイドセールスが自身のKPIを追い求めて熱量が低い顧客までフィールドセールスに渡す。フィールドセールスが無茶な獲得をした結果、カスタマーサクセスの対応コストが増加する。 全体最適化の仕組みを設けない分業は、このような問題を引き起こすことはよく知られてると思います。 そのため、The Goalを参考にした書籍が、主なメッセージに分業を置くとはどうしても思えませんでした。
違和感を感じて自分も書籍を読んだところ、なるほどーってなりました。
僕はThe Modelの最大の目的を「営業のプロセスを明確なステージに分割し、マーケティングのようにファネル分析を利用してボトルネックを特定・解決する」と読み取りました。 しかし、書籍の多くの部分で、分業による達成手法が重点的に説明されているので、「分業ってこんな良いことあるんだー」って情報を持ち帰った人が多いのだろうなと思いました。
同じようなことは、ソフトウェアエンジニアの「ドメイン駆動開発」でも経験しました。 あるベンチャー企業のビジネス職の方から、開発が大きく遅延してるので相談に乗って欲しいと言われ、ソフトウェアエンジニアの方にお話を聞いたときのことです。 「このプロジェクトはDDDで作るのが良いと思うので、こういう設計で開発します」と言われ見せられたのが、 ユビキタス言語やドメインモデルではなく、大量のService、Entity、Value Object、Domainなどのクラス群と、 「こういうときは Service ディレクトリにコードを置く。」などの大量のルールでした。 彼らが開発していたシステムはフロントもバックエンドもNext.js のみで作られており、 オブジェクトを加工せずに表示するのみのシンプルなシステムでした。 そこまで複雑なビジネスロジックでもなく、ドメインエキスパートと認識の共有もしないなかで、 DDDの戦術的設計が必要な理由がちょっと思いつきませんでした。
双方のケースを見て、なんでこんな不幸なことが発生したのかと考え、僕なりに出した仮説が双方HOWに囚われていた、ということです。 前者の営業マネージャーの方のケースだと、最近マネージャーになられたとのことなので、「マネージャーらしい仕事をしよう」と考え、組織的な管理方法というHOWに囚われたのかも知れません。 後者のエンジニアの方のケースだと、我々エンジニアの多くは技術力というHOWを対価にお金を貰っているお仕事なので、どうしてもHOWにとらわれがちなのだと思います。
自分もアジャイルに出会い、広めようとしたときに「守破離だ！」と言って同じミスをしました。 なので新しい手法を取り入れようとするときは、こういう問題に陥ってないかは意識したいなーって思った次第です。
