algonote

There's More Than One Way To Do It

日本のWeb開発にスクラムは本来不要かもしれない

専任のスクラムマスターは必要か

前口上

最近スクラムの源流である論文『The New New Product Development Game』を読みました。概ね日本企業を良い開発手法を採用している企業として、米国企業はどうやったら日本企業のようなよい企業になれるかを論じたものです。スクラムガイドのスクラムも影響を受けているようです。

スクラムはアジャイル開発の中では採用件数が多い手法ではありますが、専任のスクラムマスターは置いていないという企業もままあり、どういう時にスクラムガイドのスクラムが有用で、専任のスクラムマスターを置くことの合理性が高いのか整理してみます。

The New New Product Development Gameの概要

さてこの論文、いくつかの企業の製品を例に比較しています。製品は

  • 富士ゼロックスの中規模コピー機
  • キヤノンの家庭用コピー機
  • ホンダの乗用車
  • NECのパソコン
  • キヤノンの一眼レフ
  • キヤノンのレンズシャッターカメラ

で、それらの開発手法を分析しています。分類すると各工程が独立しているウォーターフォール的タイプA、隣接工程がオーバーラップするタイプB、全工程が影響し合うアジャイル的タイプCになるようです。

リードしている企業は以下の特徴を持つとされています。

  • 不安定性の内在
  • 自己組織チーム
  • 開発フェーズのオーバーラップ
  • マルチ学習
  • わずかなコントロール
  • 組織的学習の伝達

概ねボトムアップの強さ、強いトップダウンがなくても改善のサイクルを回せていることを日本的企業良さとしているようです。

日本企業はスクラムがやりたかったことを元からできている

こうしてみると、日本企業の少なくともトップ企業では元々スクラムの要素は元からできていた言えます。

スクラムガイドのスクラムは米国企業に日本企業的開発手法を取り入れるためのマニュアルとも捉えられて、日本企業は何もする必要がない可能性もあるわけです。

シリコンバレーだとエンジニアは1〜2年で転職してしまうとも聞きます。アメリカは移民にも積極的で人も多様ですね。文化的コンテキストの共有が困難で専任の調整役がいる合理性があるわけです。

一方、伝統的日本企業はほぼ全員日本人で終身雇用です。もっと言うならほとんど男性だけだったかもしれません。同僚は長年一緒に働いた見知った顔。専任の調整役がいなくてもよしなにやってくれることも多いでしょう。多様性のないチームほど専任のスクラムマスターは不要です

日本企業に必要なのはマネージャーレベルの底上げ

一方で今後も日本が同じ手法が使えるかは疑問が残ります。OpenWorkの統計によると、直近10年間で残業時間は月46時間から24時間に減っています。働き方改革の影響ですね。

日本企業はマネージャーがプレーヤーの能力にフリーライドしていた部分がもあったとも言えて、管理者が方向性を少し失敗しても残業ありきでプレーヤーが勝手にカバーしてくれていたからです。今後も人手不足がより進んでくるとそういったマネージャーの能力のなさが今までよりどんどん可視化されていきます。

今強いものをより強くしてももちろん良いのですが、スクラムは暴論を言えばプレーヤーもっと頑張れのフレームワークであり、日本ではもうできている可能性はあります。むしろ逆側のフレームワーク、管理者研修だったり、サラリーマン社長をどう創業社長に近づけるかだったり、米国のいいところを日本企業にどう取り入れらるかを考える方が大事かもしれません。

メンバーの従業員エンゲージメントを管理職の人事評価に使っている企業もありますね。

開発チーム内の職種が多くないとスクラムマスターは不要

他にも専任のスクラムマスターが必要かの視点はあって、例えば開発チーム内のコミュニケーションパスが多いかは一つの指標です。

ソシャゲ全盛期の方がスクラムスクラム言っていたと思うんですよね。それはある種当たり前のことで、本質的にゲーム開発はWebサービス開発と比べてアセットヘビー。プログラミングが必ずしも花形でなくグラフィックや音声も必要で、当然開発内でのコミュニケーションパスが増えます。専任の調整役を置く蓋然性があるわけです。

一方toB SaaSなんかだと導入役のカスタマーサクセスが事業構造上必要と言われており、コミュニケーションパスがソシャゲと比べると開発内から外に移転したトポロジーです。開発内の調整需要は相対的に低いですね。逆に間に入るPMは忙しいになりやすく、複数PMの企業もちらほらみます。

スクラムに限らずIT企業というざっくりとしたカテゴリーわけだと事業構造を捉えることは困難で、Webサービス開発、ゲーム開発、システムインテグレーションはそれぞれ必要な要素が変わってくるので、異なる業態のチームトポロジーはあまり参考にならないことも多いです。

モジュール化が簡単な領域ほどスクラムマスターは不要

IT企業にはもう一つ専任のスクラムマスターの必要性が低い要因があって、それはプログラミングがチームスポーツの中では比較的個人競技だからです。

The New New Product Development Gameに出てくる企業はメーカーなんですよね。それこそ自動車の部品点数はとにかくたくさんあり、相互に作用していることも多いです。機械設計は物理空間に存在がある関係で疎結合しにくいです。ワイヤレスイヤホンの音質向上のためにモジュールをよくしたら重量が目標をオーバーしてしまったりそういうことが起きやすいです。

IT企業でも決して連携が不要なわけではないのですが、プログラマーの生産性が人によって何倍も違うと言う話の根源に何があるかと言えば野球のピッチャー的存在というか個人性の高い部分だと思うんですよね。

以前資本集約的ビジネスと労働集約的ビジネスの違いについて書いたのですが、労働集約的ビジネスの中にもチーム性の高いものと個人性の高いものがあり、メーカーがカメラを作るよりはプログラミングというのは(ちゃんと設計すれば)モジュール間が密結合になるのを避けられます。

DXコンサルの仕事はいずれなくなるのでスクラムマスターは不要

最後にDXコンサルトとしてのスクラムマスターについても書いてきます。スクラムマスターがスクラムというDX手法の伝導者なら教えを布教し終わったら不要になるのではという意見です。実際そうだと思います。

専任のスクラムマスターがスタートアップの実ロール名で言えば何かと言えばCOOだと思うんですよね。PMでもなければテックリードでもない人なので。ボードメンバーが厚い会社の方が投資家目線だと投資したい会社ではあるのでCOOが不要かというとそうではないのですが、ストックオプションの付与率なんかをみてもCFOやCTOなんかと比べるとCOOは貰えていないことが多いです。

技術もわからずプロダクトの方向性も示せない人がいて助かるか?と言えば必要な場合もあると思います。ただ全てではないです。

エンジニアをざっくり分けると技術が好きな人とプロダクト開発の好きな人に分けられると思っているのですが、任意の領域Aについて最初にそれを開発できるのが誰かといえば技術が好きな人のことの方が多いです。機械学習ブームの時に社会人より学生Kagglerの方が強い瞬間もありましたし、ブロックチェーン起業家が若いという話もあります。

Googleの例なんかをみてもギークな若者技術者+大人で会社を成立させる例はあるのですが、スクラムマスターはこの大人を成立させるためのある種方便の可能性もあります。ただ、時間が経ってギークな若者技術者がキャリアを積んでくると確率的にマネジメントができる人も出てきます。時間が経つにつれてCOO、スクラムマスターはいなくても成立するようになるわけです。

CEOの代わりが務まるCOOならウェルカムですが、COO的キャリアは何ができるのかよくわからない人になってしまう可能性もあると思って、上手く立ち振る舞わないとキャリア上不利になることもある認識です。

まとめ

ダイバーシティーの低い日本企業で、プログラミング自体が比較的花形の業態で、ぽっと出の技術がメインではないWeb開発企業ではスクラム、とりわけ専任のスクラムマスターは不要かもしれません。

スクラムガイドでもスクラムマスターは概念と書いてはあるのですが、これだけスクラムマスターは兼業でやっているという企業が多いのを見ると、もっと上手く必要なチームトポロジーを説明したモデルを発明したいものです。