2012年 CSPO研修（東京）を振り返る - ITエンジニアとして生きる

2012 10/18 ~10/19でCSPO研修に参加してきました。
http://jp.agilergo.com/23

講師はJeff Patton、User Centered Design（ユーザ中心設計）やDesign Thinking（デザイン思考）で著名な方です。

http://www.agileproductdesign.com/jeff_patton.html
http://www.scrumalliance.org/profiles/9978-jeff-patton

研修受講者は全部で30名でした。
SIやサービス系、ゲーム業界と色んな方がいらっしゃいましたが、Product Owner（という顧客寄りな）研修ということもあり、実際に顧客を相手とするマネージャークラスの方が多かったように思います。
一回だけ席替えをして、以下のようなチームに分けられて座りました。

以降は研修中のセクションや印象に残った言葉を元に私なりに考察した結果をレポートしたいと思います。

Collaborative Modeling Workshop（Card Modeling）

一番初めに実施したワークショップです。

とても単純なもので、ある質問に対する回答をポストイットに記述してチーム内で共有、ディスカッションしてそれらをグルーピングするというものです。
ポストイットは大きさが限られていますので、シンプルかつ要点をおさえて書かなくてはなりません。

この手のワークショップはよくありますが、改めて考えてみるとこの手法はScrumのTime-boxに似ているなと思いました。
一定の枠を設けることによって、ムダな情報を省いて本当に価値のあることだけを選別しようとする行動を引き出す、という部分です。
（Time-boxの場合は固定の時間枠を設けることによって「この期間内にやれることは限られるので、価値のあることに集中しよう。」というようなマインドを生み出したりします。）

Jeffはこういったカード（ポストイット含む）に描くこと全般を「Card Modeling」と呼んでおり、本研修は基本的にCard Modelingで進んでいきました。（Jeffは大体いつもこの方法で研修を進めるそうです。）
Jeffが手元の白いカタ紙（約10cm×20cm）に絵や言葉を書き出し、それをスクリーンに写すという形式です。
この進め方、めちゃくちゃ効果的でした☆
実際、他の参加者の方とも「あの進め方、良かったですよね！！」とテンション高めで想いを共有したくらいです。

どういうところが効果的だったかというと、最終的には結構な情報量になるそのカードも、真っ白なところから1つ1つ要素を描き足していくので、最終的に出来上がったカードが不思議としっくりくるんです。
これをはじめから完成した（描かれた）カードや図をPPTとかで見せられても、多分しっくりこなかったと思います。

たとえば次の図ですが･･･

初めて見る方にとっては何のこっちゃ分からないと思います。
でも私は真っ白なところから1つ1つ描いていったので、この図がとてもしっくりくるし、この図にJeffの大きな想いが詰まっていることも感じられます。

身をもってCard Modelingの効果を体験出来たのは貴重でした。

ウォーターフォールとアジャイルの歴史

ウォーターフォールとアジャイルの歴史について説明がありました。

ウォーターフォールはWinstone Royce氏の論文「Managing the Development of Large Software Systems」を元にして誕生しました。
Royce氏は論文の中で、「要件 =＞設計 =＞コーディング =＞テスト」というフェーズに分割することの重要性を語っており、それを元にして米国防総省が開発標準として策定したものがウォーターフォールになります。
Royce氏は論文の中で、フェーズ毎にフィードバックすることや繰り返し開発することの重要性も合わせて言及していたのですが、それがウォーターフォールに取り入れられることはありませんでした。（※1）

Managing the Development of Large Software Systemsより

次にScrumの変遷について。
1986年に竹内弘高氏と野中郁次郎氏の論文「The New New Product Development Game」が発表されました。
その中でお二人はプロジェクトには大きく3つのタイプが存在する、と言及しています。

The New New Product Development Gameより

TypeAは従来型で、各フェーズが分断されています。ウォーターフォールが理想としている形式でしょうか。

TypeBは一部隣り合うフェーズがオーバーラップしています。設計しながらコーディングしたり、コーディングしながらテストしたりなイメージですね。

TypeCは各フェーズがそれぞれオーバーラップしています。テスト結果をアーキテクチャへフィードバックし、それを受けてアーキテクチャが変更され、そしてアーキテクチャから要件へもフィードバックが発生する、というような感じだと思います。（※2）

本論文（のTypeC）を元に、ジェフ・サザーランド（Jeff Sutherland）とケン・シュエイバー（Ken Schwaber）によってScrumが策定されたわけですが・・・そこには触れず

「The New New Product Development Game」とあるけど「Game」の中で大事な要素って何でしょう？

というワークショップが突如始まりました。
まぁ色々出たんですが、結論としては

win or lose（勝ち負け）
strategy（戦略）
statics（戦術）

の3つが大事ですよね、ってことで落ち着きました。

そして最後にアジャイルについて。
1990年代頃から「Light Weight Development」というキーワードの元、様々な開発手法が生み出されました。
XP、DSDM、Crystal、FDD･･･などです。これらはもちろん開発手法の中身は違うのですが、「Light Weight Development」という1つのキーワードでつながっています。
そして2000年ごろ、これらを総称する呼び方として「Agile」という言葉が生まれました。
Agileはちょうど、これらの開発手法を囲む傘のようなものである、と言われます。

※1
少し補足すると、ウォーターフォールは1980年代に米国防総省がDOD-STD-2167として策定したことにより始まります。その際に元とされたのがWinstone Royce氏の論文「Managing the Development of Large Software Systems」になります。
Royce氏は論文の中でシステム要件（System Requirements）=＞ソフトウェア要件（Software Requirements）=＞分析（Analysis）=＞プログラム設計（Program Design）・・・というフェーズを重ねていくことの重要性を言及する一方、要件やプログラム設計の見直しが発生したり、分析が正確にやりきれない等のリスクについても言及しています。
また、このリスクを回避するための5項目を述べており

PROGRAM DESIGN COMES FIRST（はじめにプログラム設計をする）
DOCUMENT THE DESIGN（設計を文書化する）
DO IT TWICE.（2回実施する）
PLAN, CONTROL AND MONITOR TESTING（テストを計画し、コントロールし、監視する）
INVOLVE THE CUSTOMER（顧客を巻き込む）

ということも合わせて言及しています。
しかし、「DO IT TWICE（2回実施する）」というRoyce氏の意向やフィードバックループの思想がウォーターフォールに取り入れられることはありませんでした。
そしてRoyce氏の示したリスク通り、2167標準（ウォーターフォール）は失敗を重ねます。
さらに残念なことに、米国防総省という世界的に有名な機関が開発標準を策定したということで、諸外国が真似をし、同様に失敗を重ねました。
あまりにも失敗を重ねていたため2167標準を改善しなくてはならなくなり、2167A標準が新たに策定されたのですが・・・
2167A標準はIID（incremental and iterative development）手法に適したものでしたが、１ステップでビックバン的にソフトウェアを構築するというアプローチは残されました。（そこが１番の問題であったハズなのに･･･。）
結果的に2167Aに変わって1994年12月にMIL-STD-498が策定されました。本標準では進化型の要求／設計について推奨したり、インクリメンタルなビルドについて述べられていたりします。
Royce氏は当初からウォーターフォールのように1ステップのビックバンアプローチではなく、インクリメンタルな進化型の開発を推奨していたわけです。

※2
ちなみに、TypeAはフェーズがリレーしていく様から「relay race approach」と、TypeBはその形が刺身のつまに似ていることから「Sashimi Approach」と、TypeCはそれぞれがごった煮状態であることから「Rugby Approach」と呼ばれました。

Product Ownership Team

Scrumでは
「POは必ず一人でなければならない」
と定義されています。（※1）

しかし、Jeffはこれとは全く異なった見解を示しました。（※2）
POは正しいプロダクトを策定することとROI（投資対効果）に責任を持ちますが、その責務を果たすためには大きく3つの要素が必要であるとしており、またそれぞれの要素には適任者がいると示しています。

Valuable（価値がある）：Product Manager、Business Leaderが適任
Usable（利用できる）：UXが適任
Feasible（実現できる）：Developerが適任

Jeffは一人で全ての要素を満たす必要はなく、それぞれの要素（能力）を持ったメンバーでチームを組めば良いと示してくれました。
それぞれの人材を集め、チームを組むことによって、より良いProductを生み出すことができるということです。
そしてそのチームを「Product Ownership Team」と呼びました。

※1
下記、Scrum AllianceからDLできる「スクラム入門」の6ページに記述があります。
http://www.scrumalliance.org/resources/1835
⇒「Download Now」

※2
正確には、実はそんなに異なってはいません。
これは懇親会の時に聞いたんですが、Jeffは

Product Ownership Teamの中でリーダーは一人であるべき

と言っていました。
つまり、この一人がScrumの定義するPOに当たるということだと理解しています。
私が以前参加させて頂いたCSM研修では

Scrum is not method. It does not tell you what to do, nor how.
（スクラムは方法（手法）ではない。やるべきことや、やり方を教えるものでもない）

ということをよく言われていました。
これはScrum自体が問題を解決するわけではなく、Scrumというフレームワークを通して自分で問題を解決するというようなイメージになるということです。
Jeffはまさにこの言葉通り、Scrumというフレームワークを自分なりにテーラリングし、Product Ownership Teamという体系化された構成を生み出したのだと感じました。
その思想に触れられることがどれだけ貴重でありがたいことか･･･とても嬉しく思います。

Opportunity BacklogとProduct Discovery

Product Ownership Teamの初めの仕事は「Opportunity Backlog（※1）」を作成／検証し、その結果を元にProduct Backlogを作成することになります。
Opportunity Backlogは「Product Backlogの候補」に当たり、「Product Discovery」というプロセスを通してProduct Backlogへ遷移していくものであると理解しました。

Product BacklogはProductを生み出すためのItem、Opportunity BacklogはMVP（Minimum Viable Product：実用最小限の製品）を生み出すためのItemになります。
そしてMVPを通して以下3点を検証するプロセスがProduct Discoveryとなります。

ユーザーは何を買ってくれるのか？（Valuable）
ユーザーに使ってもらえるのか？（Usable）
自分たちに作れるのか？（Feasible）

Opportunity Backlog／Product Discoveryの話では「もうそれってLean Startupじゃない？」というくらいLean Startupのエッセンスが取り入れられていました。
Lean Startupでは肝となる仮説を検証するためMVPをつくり出しますが、ScrumでもまずはそのMVPを生成／検証するプロセスが必要であるだろう、ということです。
ここには「いきなりProduct Backlogなんて作成できないですよね？」という意味が込められていると思います。

ここでも新たな気付きを頂きました。
確かにProduct Backlogを作成するときはかなり悩みます。それがどんなビジネス価値を生み、どれだけ妥当なのか。
結局仮説を元に考え出すわけですから、Lean Startupのアプローチで仮説を検証した後にProduct Backlogへ入るというのはとても自然なことだと感じました。

※1
Opportunity Backlogは直訳すると「機会のバックログ」となります。
この「機会」というのは「エンドユーザとの機会（エンドユーザとの出会い）」という意味合いなのではないかな？と思っています。
前述した通り、Opportunity Backlog／Product DiscoveryにはLean Startupのエッセンスがふんだんに取り入れられていますが、Lean Startupでは

顧客が誰か分からなければ自分たちが作るものは分からない

という思想があります。
つまり、まずは顧客が誰であるのかを見つけなければ始まらないということです。
こういったことを踏まえてJeffは「Opportunity」という単語を持ってきたのではないか？と私個人は考えています。

OutputとOutcome

これは研修中に3回くらい繰り返し描かれた絵です。

Nowというのは「現状」、Laterというのは「リリース後」を指しています。
Outputというのは、あくまでもどういった製品を「生産する（デリバリーする）」かということで、製品の生成しか指していません。
Outcomeというのは文字通り「成果」のことで、デリバリーした製品が顧客にどのような価値を生んだか、ということを指します。

つまり、どれだけ頑張って良いOutputを生んだとしても（と思っていても）、Outcomeを生み出せていないのであればそれは顧客にとって何の価値もないということ。
つまりOutcomeを意識して開発に臨むべし、ということです。

Minimize Output, Maximize Outcome!!
（最小限のOutputで最大限の成果を！！）

Change the World

Jeffが研修中、私たちに問いかけました。

Software Developerの仕事は何ですか？

その答えがコレ、Change the Worldでした。

意味はそのまま、世界を変えること。
Output（生産）とOutcome（成果）の違いは前述した通りですが、Software Developerの仕事はOutputではなくOutcomeへコミットすることだということを表しているのがこの言葉です。
つまり、我々の仕事はどのような製品を顧客へ提供するか（Output）ではなく、製品を提供してエンドユーザの世界を変えること（Outcome）であるというのがJeffの主張していたことだと思います。

このことについても完全に同意で、SI業界の中に生きているとまさにOutputしか考えていない企業や、Outputすら考えていない（SES契約等でその場所に居るだけでお金が入る）エンジニアが多々いると思います。
こういう企業やエンジニアはこの理論に則って考えると全くDeveloperとしての仕事をしていないわけですね。
本業の「Outcomeを生み出す、最大化する」ということを一切行っていないわけですから、そんな企業やエンジニアには全く価値が無いわけです。

自分もOutcomeを生み出せる存在でありたいと、改めて思い直させてくれる言葉であったと思います。

最後に

研修を通して学んだことは

ユーザー（使う側）の立場に立って考える、それを突き詰める

というとてもシンプルなことであったと思います。
Jeffはそれを突き詰めるための手段をたくさん示してくれました。

これからもこのマインドを大事にしながら、業務に望んでいければと思います。

Change the World！！