これなに？

自分 (@takahashino1) は開発現場から経営を支えたいという話を説明しています
良いものづくりが好循環を生む理由を解説してます
良いものづくりに何が必要かを説明しています

組織の分断と悪循環

みなさんは普段どんな職種の人と関わりますか？
あなたがもし開発者であれば、同じ開発者だけということがあるかもしれません。
Scrumを採用していれば、プロダクトオーナーと関わることがありそうです。
どんな職種であるにせよ、自分の職種を中心とした人と、関わることが多いでしょう。

さて、ここで少し質問なのですが、あなたが開発した（関わった）プロダクトは、どこへ行くのでしょうか？

「当然、顧客の元だ。」

そう仰る方が多いと多いと思います。当然、間違っていません。
最終的に顧客に使ってもらうことで、開発した意味が生まれます。
でも、本当に直ちに顧客の元へ行くのでしょうか？

1つのプロダクトには、開発者、デザイナー、品質保証、プロダクトオーナー、マーケット担当、セールス担当、カスタマーサポート、経営層など数多くの職種の人が関わっています。
「顧客の改善要望を元に、開発されたから大丈夫だ。」
と言って、他の職種の人を無視してリリースしたらどういう事が起こるのでしょう？

「こんな機能があるとは知らなかった」
「これだけの機能にそんなにコストを掛けていたの？」
「その時間でこっちの機能を改善してほしかった」
「実はその機能はあんまり重要じゃないんだ」

彼らは、その職種のプロフェッショナルです。当然、見えている景色が違います。
自分の得意な領域に、全くその領域を知らない人が発言してきた内容が、的外れである可能性が極めて高いように、自分も相手の得意な領域を見ることは、極めて難しいです。

上記の例では、開発が他の職種を無視してリリースした場合でしたが、これは他の職種でも当てはまります。
例えば、セールスが顧客の求めに応じて、機能改善を約束したらどうでしょうか？
そこは、開発的に極めて時間のかかる部分であるかもしれません。開発したところで、1年程度で陳腐化するかもしれません。

このように、職種の分断（コミュニケーションロス）が、プロダクト開発の生産性を下げてしまい、生産性が下がると、プロダクト開発による改善の効果が薄く、その間も改善要望が積み重なり、やることが山積みとなり、どんどんと悪循環に陥っていきます。

良いものづくりから好循環が生まれる

世の中には、開発完了したものをすぐにリリースして顧客の元へ届けていても、生産性が高いものづくりをしている組織があります。
いくつかケースがありますが、いずれにせよ、生産性の高い、良いものづくりをしていると、好循環が起こります。

顧客の求めていた機能なので、セールスも売りやすくなり、
潜在顧客数の多い部分なので、マーケティング担当が喜んで数字を弾き、
貢献利益が多い部分なので、プロダクトオーナーが喜び、
長期的な維持が可能な仕組みなので、開発が自信を持って使ってもらえる。
そんなプロダクト開発が行えます。
このようなプロダクト開発はとても楽しくて、やりがいがあるものでしょう。

すぐにリリースして生産性が高いケース

小規模な組織の場合
- 小規模な組織では複数の職種を兼務することが多く、コミュニケーションロスが起こりづらいです
高度な仕組み化を行っている場合
- プロダクトバックログが適切に管理されており、バックログに様々な職種の人の意見が集約されている

理想と現実のはざま

生産性が高い、良いものづくりをしたい。という人は多いと思います。
ですが、現実はなかなかに厳しいです。

最初は良かったけど、顧客が増えるにつれ、改善要望が多くなり、要求も複雑になり、開発に時間がかかる。そのうちにサーバーのリソースが逼迫して緊急対応に追われる。という経験をした人は、多いのではないでしょうか？

また、良いものを作るには、多くの人が必要です。
多くの人が組織に入ると、役割分担と分業化が進み、得意な分野で効率化を進めます。
ある分野の効率化が、他の分野からは敬遠されることも、起こり始めます。

このように、良かれと思って行動したはずが、プロダクト全体で見ると生産性を低下させることが、まま発生します。

「じゃあ規模化しなければいいじゃない」

そうですね。素晴らしいです。それも一つの答えです。
規模化しないということは、他の企業が真似しやすいビジネスモデルになるので、なかなかに事業の維持が難しいかもですが...

よくある解決法は、標準化です。
業務プロセスや開発プロセスを標準化することで、なぜ作るのか？どのように作るのか？をステークホルダー全員が理解できるようにします。
例えばBPMN図に業務プロセスを起こして、それを元にPRD（プロダクト要求書）を書いてバックログを起票する...というように、開発プロセスを標準化することがあると思います。

ただ、標準化には罠があります。
軋轢の発生と、改善活動の不足です。

「今までのほうが、意見が通りやすかった」
「逆に、面倒になった」

これらの意見は正しいです。このようなことを言う人を、攻撃するような標準化の仕掛け人は、悪い意味のコンサルです。
標準化は、長期的な改善活動とセットにすることで、大きな成果を出します。
「今までのほうが良かった」ということは、その標準化には、改善の余地があるということです。
なぜなら、標準化の目的は、生産性の向上だからです。
標準化して逆に生産性が低下しては、意味がありません。

この時、古のトヨタ生産方式におけるQC改善サークルのように、多様なステークホルダーが参加する改善サークルを立ち上げることは、一つの手に思います。
つまり、多様な職種の人が、継続的に、標準化プロセスを作っていくことが重要なのです。
多様な職種の人が関わることで、透明化された仕組みの上に、様々な意見が集約され、意味のあるバックログが作られるようになります。

Tips.トヨタ生産方式

Scrumの源流となったトヨタ生産方式ですが、製造業の現場では、トヨタに倣ってトヨタ生産方式を次々に導入したといいます。
ですが、生産性が上がるはずなのに、逆に生産性が下がってしまった。という事例が多いと聞きます。
これは、それぞれの組織が抱えている問題や文化が異なり、形だけの導入に終わってしまっているためと考えられます。

開発現場から経営を支えたい

真の意味で、強い会社や組織を作るために必要なことは、良いものづくりをし続けることだと思います。
良いものづくりには、プロダクトに関わる全ての職種の人が関わり、透明で継続的に改善されている開発プロセスが存在し、生産性の高い状態が維持され続けています。

これをやるためには、一人くらい、全部の職種に通じた人が居ると良さそうに思いませんか？
開発ができ、デザインができ、品質保証ができ、マーケティングが行え、セールスが行え、経営が行える。決してスーパーマンである必要はないので、全部を極める必要はないです。全部の職種と会話できれば良いのです。
小規模な組織であれば、それは社長やCEO、COOの役割であるかもしれません。

ここでようやく自分が、言いたかったことが言えるのですが、

自分の開発現場で希望する職種は、 すべて です。

自分はやっぱりものづくりが大好きで、ものづくりを楽しむには、良いものづくりをしないといけないと考えています。
であるなら、すべての職種と会話するCEOのような役割で開発現場に入り、開発現場から経営を支えることが、一番ではないかと、そう考えたのでした。

蛇足ですが、それが本来の意味での、スクラムマスターなのかも？とも思いました。

参考文献