認定スクラムプロダクトオーナー研修の感想

認定スクラムプロダクトオーナー研修に参加してきたので感想をメモ。
ラフなメモ。

【1】実は最近は、アジャイルという言葉にずっと違和感を感じていた。
理由は2つある。

1つ目は、アジャイルなソフトウェア開発で実践して経験してます、とアピールしたいならば、実践経験はもちろん、スクラムの認定研修を受けて認定資格を持っておく必要性がある風潮に何となく違和感があったから。

以前なら、XP本を読んで自分なりに解釈していろいろ試してました、FDDやScrumの本や勉強会で刺激を受けて自分なりにいろいろ試しました、みたいな話が多かったように思う。
周囲に実践者が少ないし成功談も少ないので、自分たちで試行錯誤するしかなく、自分自身や自分たちのチームを実験して、自分たちの個別の経験を積めばよかった。
その頃はアジャイルの牧歌的な時代だった。

しかし、アジャイルコーチというプロのアジャイル開発のコンサルタントの職業が一般的になり、彼らがチームを指導してチームが運用に軌道に乗せて、どんどんアジャイルなチームを増やしている。
それは良いことなのだが、プロのアジャイルコーチがいない所で、自分たちでアジャイル開発を試行錯誤して上手くいきました、と言われても、それは本当にアジャイルなの？と言われる。
アジャイルもどきであって、真正のアジャイルではないでしょ、みたいな感じに思われる。
ウォータースクラムフォールではないのか？、それはスクラムのルールを改変しすぎているね、君の思い込みではないかね、とか。

実際に見た案件では、顧客に超高速開発ツールを使ってすぐにデモして見せてます、アジャイルにやってます、と言っていた場面を見たが、単に顧客と机を並べてオンサイトでWF型開発しているだけじゃないの、アジャイルでもなんでも無いでしょと。

超高速開発でアジャイル開発を実現する話に違和感がある: プログラマの思索

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

ちょうど、キリスト教が生まれた後、いろんな宗教家が自分たちこそがキリストの真の後継者なのだ、と200年も論争して、三位一体説のキリスト教に収れんされた歴史を連想する。
現代は、アジャイル開発の数多くの流派が生まれて論争された後、スクラムに収れんされていく時代なのかな、と思っている。

捏造された聖書の感想: プログラマの思索

2つ目は、最近のアジャイル開発のニュースが、ソフトウェアのプロセスやソフトウェア工学の観点よりも、DXに向いた組織を作りましょう、組織文化をもっとアジャイルに変えましょう、という組織論の論点に偏っているように感じたから。
もちろん、アジャイルな組織文化は重要だ。
一番流行しているバズワード「心理的安全性」が浸透したチームや組織であれば、アジャイルなソフトウェア開発も事業もやりやすいだろう。

しかし、経営層や組織構造を変えないまま、組織文化をボトムアップで変えようとするのは至難の業だ。
既存事業や既存組織が残ったままになりがちなので、結局、社内に出島を作り、そこでアジャイル開発を成功させて、少しずつ社内に展開していこう、みたいなやり方に落ち着く。

チャンドラーの言葉「組織は戦略に従う」、コンウェイの法則「ソフトウェアは組織に従う」の経験則に従えば、組織文化を規定する組織構造、さらには経営戦略から抜本的に変える必要があると思う。
つまり、ソフトウェア開発を事業の根本に据えて、ソフトウェア開発の事業の向いた組織構造を作るのが一番手っ取り早いと思う。
「大規模スクラム Large-Scale Scrum(LeSS)」でも、「組織構造が組織文化を規定する」と書かれていて、そうだよねと納得した。

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説: プログラマの思索

スクラムは境界を生み出す: プログラマの思索

More Effective Agileは良い本だ: プログラマの思索

だから、組織論の話、特に組織文化の話に持ち込んでも、真の解決にはならないと思っている。
「組織文化は社長が作り出すものだ。社長がもっと汗をかけ！」と以前、中小企業診断士の先生が言われていたのを思い出す。

文化は組織構造に従う: プログラマの思索

諸問題を組織論に持っていくのは目的を手段化していないか: プログラマの思索

【2】とはいえ、実際に認定スクラムプロダクトオーナー研修に参加してみたら、すごく楽しかった。
スクラムマスター研修は以前受けているので内容は大体分かっているけれど、新たな知見もあったし、ゲーム感覚で経験できるのは楽しかった。
アジャイル開発は、こういうゲーム感覚で進められるように整備されている点が上手いな、といつも思う。

プロダクトオーナーが関わるプロセスでは、
Release Goal→Contract→Vision→Personas→User Story→Release Planning→Product Backlog
のループになる。

【3】興味深かったことはいくつかある。

1つ目は、ReleasePlanningでのユーザーストーリーの優先順位付けだ。
ユーザストーリーには、サイズという見積もり情報をフィボナッチ数で見積もる。
S、M、L、XLのカテゴリに3つの数値が分類されるので、フィボナッチ数は1～12番目まで使われる。

さらに、ユーザーストーリーにVlaueという顧客から見た価値、定量化された数値を設定する。
ここでも、S、M、L、XLのカテゴリでフィボナッチ数が使われる。

ここから、ユーザストーリーの優先度＝Value/Sizeを計算して定める。
優先度の大小で、ユーザストーリーはプロダクトバックログに一列に並ぶことになる。

興味深い点は、実際に自分たちで優先度を定めてみると、実は1以上の優先度が少なくて、殆どが1未満の小数点の端数になったことだ。
つまり、優先度の高いストーリーはすぐに決まるが、大半のユーザーストーリーは1未満の優先度なので、あまり大きな差が出ない。
すなわち、価値の高いユーザーストーリーを作ることは非常に難しいことを意味している。

この事象は僕らのチームのユーザーストーリーの作り方が悪かったのかもしれない。
価値あるユーザーストーリーをたくさん作れなかったのだから。

【4】2つ目は、狩野モデルでユーザーストーリーを分類したとき、プロダクトオーナーの観点では意味合いが異なる点だった。
狩野モデルでは、4象限のマトリクスに分類されて、当たり前品質、一元的品質、魅力的品質で分類される。

狩野モデル | UX TIMES

狩野モデルから探る品質のあり方とは | SHIFT ASIA -ソフトウェア品質保証のプロフェッショナル-

プロダクトオーナーの観点では、当たり前品質は最低限の品質を担保する機能を指し、魅力的品質では顧客を驚かせたりワクワクさせるような機能、つまりValueを指すらしい。
そして、一元的品質のある第1象限はできるだけ避けるらしい。

僕にはこういう発想はなかった。
なぜなら、QC検定試験のようないわゆる品質保証の話で出てくる狩野モデルでは、品質と顧客満足度の関係を製品のプロダクトライフサイクルの観点で移り変わるものである、品質は時代によって変化することの方が重要視されていて、こういう発想の説明は聞かなかったから。

【5】3つ目は、ジョー先生から、テスラの事例がやたらと多く話されていたこと。

電気自動車メーカーのテスラの凄さは、中島聡さんのメルマガなどで聞いているが、やはり生の声はとても参考になる。
ジョー先生はテスラにもコンサルで関わっていて、生産ラインというものはなく、メーカーの全てのプロセスは、スクラムチームで形成されている、とのこと。
イメージとしては、車体を作るチーム、タイヤを作るチーム、自動運転のソフトウェアを作るチームなど、部品や機能ごとにチームがあるし、コーヒーチーム、カスタマーサポートチームのような全てのチームを支援するような部署もスクラムチームになっているらしい。

僕は、製造業がソフトウェア企業と異なる点は、規格品を大量生産できるプロセスを整備することであり、そのために生産ラインのような標準的なプロセスや組織が必要と思っていたが、ジョー先生に質問したら、テスラではそんなものはありません、みたいなことを言われた。
テスラの中にあるチームは、細胞組織（セル）のようなもので、それらが必要なものをやり取りして、最終的な製品を作るのです、と。
そういう説明を受けたが、僕はどうしてもその内容を理解できなかった。
メーカーのプロセスを全てスクラムで実現してしまうとしても、どんな点に注意して、スクラムチームを構成すべきなのか、どんなハードルがあるのか、まだイメージできなかった。
たぶん、日本の製造業のイメージが強すぎて、最先端のアジャイル製造業の話を目の前の事実として理解できなかったからだろうと思う。
品質が安定した規格品を大量生産するには、安定した標準ラインよりもアジャイルなチームの方が本当に向いているのか？と。
ジョー先生からは、アジャイル製造業のコミュニティがあるから、ぜひ聞いてみてね、みたいなことも言われたので、聞いてみたいと思う。

【6】4つ目は、プロダクトオーナーは必ずスクラムチームに1人は存在するように、大規模スクラムを実践すべきである、という話があった。
スクラムチームはたくさんあっても、プロダクトオーナーが1人だけに限定される話は、過去の話です。
チーフプロダクトオーナーは作らないのが今のやり方です。
チーフプロダクトオーナーが仕切るのは古いやり方です。
今の大規模スクラムでは、スクラムチームに必ずプロダクトオーナーは1人いる、と。
そして、プロダクトオーナーが定期的に集まって、そこでプロダクトバックログにあるユーザーストーリーを調整します、みたいな話をされていた。
そのミーティングがスクラムオブスクラムですね、昔とは違います、と。
たぶん、大規模スクラムのLess、SAFeの話と比較されているのだろうと思った。

【7】他にも色々興味深い経験ができた。
認定スクラムプロダクトオーナー研修を受けて感じたことは、自分が当初感じていた2つの違和感はまだ残るが、スクラムは本当に上手く作られているな、と改めて感じる。

スクラムの認定資格を持っていないとアジャイルなソフトウェア開発をやっているとは言いにくい風潮も、実際に研修を受けていて、なるほどそういう意味があるのか、と気づくと、その価値に納得する。
また、アジャイルな開発をやるには組織論が重要だ、という話も、スクラムに触れてみると、実際にチームメンバーにはかなりの自由度が任されていて、その専門性を活かせる環境にあるので、自然にそういう文化を受け継ぐし、今の日本のIT業界における多重下請け構造とは違った世界だから、やっぱりスクラムの組織の方がいいよ、みたいな感想を持ってしまう。

まだ経験できた内容は全て言語化できていないので、書き出してみたいと思う。