スクラム、要求開発、リーンをめぐる冒険

A Wild Scrum, Requirement Development and Lean Chase

オープンセミナー2010＠岡山 （#OSO2010）

すくすくスクラム瀬戸内 / 要求開発アライアンス@tetsu_m （てつ。）

May 15, 2010

n 1988-1999　（株）野村総合研究所（1990-1994 Nomura Research Institute Deutschland GmbH）

n 1999-現在　　某ユーザ系企業の情報システム子会社勤務

n Scrum Alliance 認定スクラムマスターn すくすくスクラム瀬戸内n 要求開発アライアンス

n To-Be Architecture WGn 要求開発ファシリテーションWGn 要求開発アライアンス西日本

n EM WEST編集部

n 　　@tetsu_m

自己紹介

今日のお話

もう少しn ちょっと前まで、アジャイル開発と言えばXP

n それが今や、スクラム！？

n いやいや、もうスクラムは古い…のか！？

n 欧米ではみんなリーンだのカンバンだのと…

n そんな中で「要求開発」は？

このあたりの話題について現時点で私がどのように理解しているかなど

日頃つらつらと考えていることをだらだらと話します。

ところで告知文からの抜粋

オープンセミナーはオープンソースとインターネットをテーマにした無料セミナーです。

しまった…！

こういうのとか期待していた方ごめんなさい

↑これは@Ryuzeeさんのオープンソースカンファレンス2010 Tokyo/Springでの素晴らしい講演資料

今日のメッセージ

　「貴様が何を信じていようがかまわん。キリストだろうがマホメットだろうがイワシの頭だろうが、勝手に信じるがいい。もし本当に自分の頭で考え抜いたすえに、それを信じているのならな」

ところでスクラムって何？

• Product owner• ScrumMaster• Team

Roles • Sprint planning• Sprint review• Sprint retrospective•Daily scrum meeting

Ceremonies

• Product backlog• Sprint backlog• Burndown charts

Artifacts

Scrumはアジャイル開発のフレームワーク

AgileやScrumへの誤解は数々あれど…

Scrumは、意外と「空気を読め」と言っている？

"これらの変更が文化的に受け入れがたく、スクラムマスターは現状を黙認しなければならないこともあります。スクラムは「可能性の技術」です。牧羊犬が死んだら使い物になりません。"『スクラム入門 -- アジャイルプロジェクトマネジメント』（p.38）　　　Ken Schwaber 著　日経BPソフトプレス

出典： 平鍋健児「Agile から Lean への旅 -- UK Lean Conference を終えて」 （An Agile Way : ITmedia オルタナティブ・ブログ）

http://blogs.itmedia.co.jp/hiranabe/2009/10/agile-lean----u.html

アジャイルは、「ビジネスとソフトウェア工学の間のコネクタ」

ビジネス

ソーシャル工学

ソフトウェア工学

じゃあ、リーンは？

出典： 平鍋健児「Agile から Lean への旅 -- UK Lean Conference を終えて」 （An Agile Way : ITmedia オルタナティブ・ブログ）

http://blogs.itmedia.co.jp/hiranabe/2009/10/agile-lean----u.html

リーンは、コンセプトを開発を通じてキャッシュにするまでの流れ

を作っていく企業ワイドの活動

※組織のタイプによっての違いはある　- Product OrganizationとIT Organization　- ITのユーザ企業とSIer/ソフトハウス

スコープの比較

スクラムは、さらなる進化を遂げるのか？

Scrum#

で、要求開発の出番は？

リーンで大切なこと

Minimum Marketable Feature

Time to Market

Lean Portfolio Management→ 要求開発の出番

Using Product Portfolio Management to Improve the Efficiency of Teams

出典：”Using Product Portfolio Management to Improve the Efficiency of Teams”Written by Alan ShallowayMonday, 12 April 2010 14:14http://www.agilejournal.com/articles/columns/column-articles/2804-using-product-portfolio-management-to-improve-the-efficiency-of-teams

Fast - Flexible - Flow

Using Product Portfolio Management to Improve the Efficiency of Teams

出典：”Using Product Portfolio Management to Improve the Efficiency of Teams”Written by Alan ShallowayMonday, 12 April 2010 14:14http://www.agilejournal.com/articles/columns/column-articles/2804-using-product-portfolio-management-to-improve-the-efficiency-of-teams

ソフトウェア開発のバリューストリームの概念図

そしてようやく、「要求開発宣言」

私たちは、企業でのITシステム開発を通じて、「要求」に関して以下のことを学んだ。• 情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。

• 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。

• 情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。

• ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。

• 要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。• 「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。

私たちはこれらの気づきから、「要求開発」という新しい知的活動分野を創造し、それをみずから実践してい く。その過程で獲得したナレッジをOpenthology（オープンソロジー）として体系化し、かつ、クリエイティブコモンズの下に公開・共有すること で、同様の課題を持っている人々と、コミュニティ活動を通じて分かち合うことを決意する。

2004年12月23日　すずかけ台合宿にて

情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。

「要求開発宣言」①

情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。

「要求開発宣言」②

情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。

「要求開発宣言」③

ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。

「要求開発宣言」④

要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。

「要求開発宣言」⑤

「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。

「要求開発宣言」⑥

要求開発が扱う領域

要求開発目的・手段の連鎖による追跡可能性

（“WhatとHowの連鎖”、 “Howからの突き上げ”）

参加協調による継続的改善プロセス

要求開発の本質（私見）

要求開発の３つの”T”

Transparency（透明性）Traceability（追跡可能性）Triage（トリアージ）

要求開発のコタツモデル

出典：　http://www.openthology.org/rd01.html

ほら、似てるでしょ？

まとめると、どういうこと？

これは

こういうところでのフレームワークで

こっちの方向に広がりつつあって

スコープの比較するとこんな感じだけど

要求開発目的・手段の連鎖による追跡可能性

（“WhatとHowの連鎖”、 “Howからの突き上げ”）

参加協調による継続的改善プロセス

その上流部分では”日本発”のこんなのもあり、

要求開発目的・手段の連鎖による追跡可能性

（“WhatとHowの連鎖”、 “Howからの突き上げ”）

参加協調による継続的改善プロセス

こうやって並べてみると似てるね♪

大事なことなのでもう一度！

これは

こういうところでのフレームワークで

こっちの方向に広がりつつあって

スコープの比較するとこんな感じだけど

要求開発目的・手段の連鎖による追跡可能性

（“WhatとHowの連鎖”、 “Howからの突き上げ”）

参加協調による継続的改善プロセス

その上流部分では”日本発”のこんなのもあり、

要求開発目的・手段の連鎖による追跡可能性

（“WhatとHowの連鎖”、 “Howからの突き上げ”）

参加協調による継続的改善プロセス

こうやって並べてみると似てるね♪

このあとどうなる？

要求開発にたりないもの？（仮説）

n 戦略マップ、要求分析ツリーなどは、要求開発の上流でのとても強力なツール

n ただし、Lean Portfolio Managementに使うには、Time to Marketの考え方、スピードや時間の価値の概念が弱い

n LeanのPerspectiveと組み合わせて使える形への進化が必要？　→　要求開発#

あれっ？

今日はScrumの話をあまりしていない気が…

というわけで最後にもう一度

Scrumって何？という話を

Scrum is ...

Scrum is a framework for surfacing organizational dysfunction.

スクラムは組織の機能不全を明るみに出すためのフレームワークである。

"Scrum doesn't do anything" (Tobias Mayer)http://agileanarchy.wordpress.com/2009/10/11/scrum-doesnt-do-anything/

Scrum is ...Scrum is a way of thinking about how we do our work, it is an state of mind, a journey, an exploration of self and environment.

スクラムは仕事のやり方についての考え方であり、心の状態であり、旅路であり、自分自身や環境の探究である。

"The People's Scrum" (Tobias Mayer)http://agileanarchy.wordpress.com/2009/12/06/the-peoples-scrum/

こう考えるとまた、見える景色が違ってくる

今日のまとめ

　「何かにとらわれて生きることは容易だ。だが、それは自分の目で世界を見る責任を放棄することだ。自分自身であることを放棄することだ」

続きは、下記のコミュニティで！

「すくすくスクラム瀬戸内」

「要求開発アライアンス西日本」

岡山を中心に勉強会やってます！http://groups.google.co.jp/group/Scrum_SETOUCHI

大阪を中心に勉強会やってます！http://groups.google.co.jp/group/reda_west