CSPO 認定スクラムプロダクトオーナーを受けてきた
先日２日間で、CSPO Certified Scrum Product Ownerを受けてきた。
このコースはホンマ凄い。何が凄いっていろいろあるけど
・全てボランティアベース／コミュニティベースで運用されている
・スクラムの父、ジェフ・サザーランドさんとガブリエル・ベネフィールドさんがやってくる！
・CSPOのコースが初めて日本で行われる！
・最終日に、スクラムの父「ジェフ・サザーランド」日本のアジャイルの父「平鍋健児」
スクラムのアイデアの元「野中郁次郎」さんのスリーショットと歴史的ディスカッション
なんて夢のようなラインナップが実現したんだけど、参加者がこれまた凄い。
@emersonmillsや、@essense_sや、@ryuzee @miholovesq @kawaguchi @nobiinu_and そして原田さんといった現在のスクラムを牽引する中心メンバー。そして同期メンバー（笑）@kkd @amapyon といったメンバーに加え紹介できない程いろんな凄系の人々が来ていた。樽本さんも来ていたのにはびっくり。
こんな人々とディスカッションするだけでも価値があるわ。
といったとんでもなくスペシャルな講座でした。
私個人としても、アジャイルの考え方の中で最も開拓すべき部分は「プロダクトオーナー」もしくは「ユーザ」という役割だと思っています。プロダクトオーナーやユーザというのは「ストーリを出して優先順位つけてね！」という役割ですが、本当に大変で、プロジェクト企画や予算取りから、利害関係者調整、業務改革、全体マネジメントまで、死ぬほど役割があるはずなのです。これは本当に大変ですが、特に日本では今までその具体的なやり方については部分的にしか伝わっていませんでした。
今まで私はシステム企画等を「要求開発」の手法で何回も体験してきましたので、その手法や、大手SI企業で鍛えられたプロジェクトマネジメントそして、企業改革の支援をしたときの、上位折衝力等でカバーしてきました。
今回、スクラムの父から、その手法や考え方が聞けると思うと、そこがとっても気になっている私としては参加するしかありませんでした。
まず運営がコミュニティ中心というのが本当に凄いと思います。みんなボランティアでこんな大物がやってきて、企業でも開催がままならない歴史的セッションが開催されました。@emersonmillsさんがいっていましたが、企業じゃなくて、コミュニティベースだから、参加者のモチベーションが違う。だから企業開催ではあり得ない素晴らしい会になったと言っていました。これは本当にそうだと思います。コミュニティの力は本当に凄い。そして素晴らしい。自分ももっと、もっとコミュニティに貢献しないといけないなぁと思いました。
今回の中身の詳細については、認定コースなので詳しくは書きませんが、コミュニティへの貢献の意味も含めて、今回の素晴らしいCSPOのメソッドと要求開発の比較とそのコメントをここに書いてみたいと思います。
ちなみに今回のこの記事はCSPOや要求開発について、いろいろ言いたい訳ではありません。この分野は本当にまだまだ未開拓だと思うのです。だからこそ、みんなでこれから知恵を出し合って考えて行、隙間がいっぱいあるところだと思います。
そういう隙間を埋める１ピースになれば幸いです。
下記の表は、今回のCSPOと要求開発のカバー範囲について整理したものです。私も英語が得意ではありませんので理解が間違っているかもしれませんが、そのときはご指摘ください。
CSPOと要求開発の比較
1. 開始点
まず最初に「開始点」についての比較です。これは、システム企画をゼロから開始するときに、最初に何から手をつけるかというのは何もなければ途方にくれてしまいます。だから、最初に１枚もののプロジェクトの定義を書いてみると、凄く基本的な事なのに、何も考えられていないとかいうことに気づいたり、１枚で見渡せるので、意識共有がしやすくなるという特徴もあるものです。要求開発でもありましたが、CSPOについては、より「アジャイル」な感覚を持っていると感じました。特に１枚提案書に「エレベータピッチ」が入っているのは「アジャイル」感があり、なおかつ本質的だと感じました。
2.ステークホルダ分析
CSPOメソッドは利用者のステークホルダ中心の分析スタイルです（これは後ほどのペルソナにも関わってきます）一方要求開発は、いわゆる基幹システム等をイメージされているので、ステークホルダ分析に関しては要求開発がよりリッチなイメージです。
3. ステークホルダ巻き込み
CSPOではここは範囲外です。要求開発では、コタツモデルや、マネジメント系のコミュニケーション計画、手前味噌ですがパワーストラクチャ等の巻き込みツールがあります。ここは上手く噛み合わせると良さそうです。
4. 利用者ロール分析
利用者目線からの分析と優先順位づけを行うような技術で、これも後のペルソナにつながります。要求開発ではこの観点はありません。
5. ペルソナ
CSPOはUXやUCDの影響をうけており、ペルソナシナリオ法が採用されていました。要求開発では個々のメンバや企業が取り入れる動きはありますが、Openthology1.0の段階では導入されていません。今後注目の分野ですね。
6. 戦略／価値分析
CSPOは非常にシンプルなスタイルで、価値要素の優先順位づけを行い、ゴール設定で成功の定量化を行います。ところが、この「価値要素」は「戦略」だったりプロジェクトの「目的」だったりしますが、この整理はフラットに考えると非常に整理が難しい部分です。
なぜなら、「戦略」や「目的」はn:nの関係にある階層構造だからです。例えば、企業の最も上位の戦略が
「利益の拡大」でありその下に「コスト削減」「売上向上」があり、「売上向上」には「客単価の増加」があり、「客単価の増加」の為に「xx企業のM&A」とか、「営業マンの事務工数削減」等の戦略があり、その戦略は「コスト削減」にも影響したりします。
これではわかりにくいと思いますが、つまりはとっても複雑な構造なものなのです。だから、１次元でこれを考えると、粒度感がまとまりがつきにくくなるため、これだけは、「目的ー手段」の連鎖のフォーマットで整理するのをおすすめします。具体的には「要求分析ツリー」「目的構造図」「BSC戦略マップ」等で、もっと簡易的なその他のフォーマットでも全く問題ありませんが、ここは開拓の余地有りと思いました。
7.ゴール
このゴールの価値も定量化しますが、定量的なゴールを決める時は非常に難しく、これは上記の戦略／価値分析で導かれたプロジェクトのゴールとひもづいている必要があります。この関連も若干CSPOの考えでは薄いと感じました。現在では要求開発のアプローチの方がよりロジカルに抽出できるのでおすすめです。 ここも今後はよりアジャイルに改善されるといいかもしれませんね。
8. フューチャーの優先順位づけ
ここはとても面白かったです。ユーザーストーリマッピングもこの後でフューチャーされており、とても面白く感じました。アジャイル系のPOやファシリテーション技術の「割り切り」はとても素晴らしい！
CSPOでは対象外になっていました（解説は無しでした）私も例えば上記の方法でストーリを出した場合業務要求がでてくるはずのなので、システム作りだけじゃなくて業務改革もしないとあかんと思うのですが、、、と質問してみましたが、別口で考えているようでした。
ですので、ここは、要求開発なりなんなりの方法でフォローする必要がありそうです。また、現状の業務を分析したり、抜け漏れ確認等をドメインモデルで行うなどの技術も結構便利ですのでおすすめです。（当日も原田さんチームはドメインモデル書いて抜け漏れを発見していました）
10. 見積り／リリースプラン
ここに関しては、要求開発には特に定義がなく、おなじみのストーリポイント／プランニングポーカー法が中心で特に良いのはユーザーストーリマッピングを活用しているところでした。ユーザーストーリマッピングの手法は@kkdが以前に紹介していましたが、アジャイルに要求を整理し、全体像を得るにはよさそうです。
＃ストーリ量にもよるかもしれませんが
私はアジャイルプロジェクトでもリリース計画は重要だと思っています。（これも私の体験したドメインはそうだったということだけかもしれません）それがないと、マネジメント側からもチーム側からも、見通しがたたないし、全体像が見えないからです。セルフコントロールもとてもしにくくなります。
だから、それらのリリース計画を「見える化」する方法が必要です。バックログでもリリース計画は表現されていますが、細かすぎますし、特に上位マネジメントに報告する際には適切な粒度とは言いがたいでしょう。
ユーザストーリマッピングがあればチームレベルで簡単に整理でき、見える化できるのが良さそうです。
＃そこからのさらなる上位マネジメントへの報告はそこの情報を元にさまらないといけないとは思いますが。
11. その他
その他の観点では、「スコープマネジメント」「役割分担／体制」「要員計画」等は議論されていませんでしたが結構企画やプロジェクト運営においては特に重要なポイントだと思います。
アジャイルで「スコープマネジメント」は変に思われるかもしれませんが、とっても大きなレベルでの「範囲」です。（ストーリを出すと言っても、「生産管理システム」を作っているのに急に「注文システム」のストーリがでてきたらむちゃくちゃになりますし、連係システムは何？とかはおさえておくと良いでしょう）
それは「ビジネスユースケース」等の業務範囲で表したり、パワーポイントで個別の図を書いたりプロジェクト企画レベルでは実施します。また、ハードウェアやネットワーク、ファシリティの調整等は無いのでマネジメントでカバーするようにしないといけないでしょう。おそらく、CSPOとかでは、そんなこと言わんでもわかってるよね。ということと思います。もしくは、スクラムはセルフマネジメントだからチームがやるべきなのかもしれません。その場合そういうことを整理し、折衝するスキルが必要になるでしょう。
最後に
いろいろ書きましたが、今回のCSPOの講座は本当に価値のあり、内容も濃厚で、しかもシンプルで「できる」感覚を持てる素晴らしいものでした。紙ヒコーキを用いたスプリント体験も本当にいい運営方法だったと思います。
こういう手法が整理されてでてきてとても嬉しく思います。要求開発もそうですが、まだまだこの分野はUX, UCD含めてまだ決定打はしばらくないですから、みんなで知恵を出し合って、現場で役立つ方法を考えて行けたらいいですね。
ジェフ・サザーランドさん、ガブリエル・ベネフィールドさん。本当にありがとうございました。文句無しのExcellent講座でした。ホンマに満足しましたし、火がつきました。
そして200枚を越えるスライドを用意して本当にやってしまった@kawaguchiさん原田さん@ryuzeeさんは本当に凄すぎる。ありがたすぎる。日本の宝です。そして日本にスクラムを伝来し黒船になってくれている@emersonmillsさんには懇親会でも限りない勇気と元気をもらいました。
最高の会をありがとうございました！次はソルトレーク行くぞ！英語がんばるぞ！
