DoorKeeper
http://devlove.doorkeeper.jp/events/9353
以下の書籍をターゲットとした勉強会なのです。
 | アジャイルソフトウェア要求 (Object Oriented SELECTION) (2014/02/11) Dean Leffingwell 商品詳細を見る |
場所は品川のオージス総研さんです。
参加者は30名くらいでしょうか。
この本の存在自体は以前から知っていたものの、今回このイベントが告知されるまでSAFeの本だと知りませんでした。。。
SAFeの日本語サイトはこちら～ http://www.scaledagileframework.com/jp/
ちなみに昨今、エンタープライズや大規模をターゲットとしたアジャイルの本が出始めてきたように感じてます。
去年のDAD本然り。（ただDADは大規模をターゲットとしているわけでは無いと思いますが）
そんな弊社も規模が大きなSIerで、私自身、自社にアジャイルを推進する立場にあったりするのです。
んで、なんかSAFeってのがあるらしいで～、くらいの知識しか無かったので、このイベントはチャンス！と思ったのでした。
まぁ自分の立場は置いといて、単なる好奇心によるところが大きかったり。
■ 講演
講師は監訳者の藤井 拓さんです。当日のスライドはこちら。
ちなみに、事前にA4両面印刷の説明資料も配布されました。
オモテ面はSAFeのBig Pictureです。
裏面は書籍の構成を説明した資料になっていて、講演の後半で使いました。
この配布は親切設計で良いですね～
以下、講演中にメモした内容を復習を兼ねてダラダラ書き起こしてみる。
■ 書籍について
- SAFe (Scaled Agile Framework)の本。SAFe 1.0の解説書になっている。
- SAFeは、チームレベルのアジャイル開発を大規模開発にスケールアップするためのフレームワークである。
■ チームを超えたものの必要性 （P.5）
- 現段階では、アジャイル開発は７人±２人くらいのチーム向けの、小規模開発向けのイメージになっている。
- ただ、本当にアジャイル開発が企業の競争の武器になるには、チームだけじゃなく中間管理やPMOなどと連携しないといけない。
- それが日本とアメリカの差なんじゃないか。
- 欧米はアジャイル開発が企業全体の競争力となる道具になっている。
- 規模も大規模もあり中規模もあり。AmazonとかSalesforceとかの事例も言われている。
- 今は金融システムにもアジャイル開発を展開しようとしている。
- 欧米ではキャズム理論でいうアーリーアダプターやアーリーマジョリティを超えつつある。
- 日本も早くキャッチアップしていかないといけない。
■ 知識創造企業：知識創造のコンテキスト （P.6）
- 戦略と実現性の兼ね合いを取る中間管理職（リーダー）の存在が大事である。
- SAFeは、知識創造のコンテキストを形成することを助け、アジャイル企業への転換を支援する。
- ここを理解することが大事。
■ Scaled Agile Framework (SAFe) とは （P.7）
- ３層構造となっている。
- 一番上の層： ポートフォリオ（戦略とか企画とか）
- 真ん中の層：、プログラム（複数チームを束ねて開発する体制とか）
- 一番下の層： チーム（スクラムチームとか）
- ここで言う「プログラム」とは「大規模プロジェクト」のこと。
- ３層が一丸となってプロダクトを作っていくのがSAFeである。
■ Scaled Agile Frameworkの起源 （P.8）
- SAFeにはいくつかの源流がある。
- まず「反復的でインクリメンタルな開発」があって、その下に「アジャイル開発」がある。
- 同じ方向性を向いてプロダクトを作っていくということで「リーン思考」を取り入れている。
- リーンとアジャイルを融合した「プロダクト開発フロー」がある。
- これらからSAFeが構成されている。
■ フレームワークの考案者： Dean Leffingwell （P.9）
- 彼が面白いのは、いろんな側面を持っている点にある。
- 著者： 要求管理の方法論とかツールの創業者である。
- コーチ： アジャイルコーチとか要求開発のエキスパートでもある。
- 役員： Rational社に買収されて、上級副社長になって、そのあと独立して自分の会社を興した。
- ３つの側面をもっているのが面白い。
■ 知識創造のコンテキストとScaled Agile Framework (SAFe) （P.11）
- SAFeの構成要素
- 要求プラクティス
- リーン （後継者の育成）
- プロダクト開発フロー （どうやって効率的に作るか）
- スクラムとXP
■ リーン思考が必要な手段を提供する （P.12～P.15）
- トヨタウェイをベースに、価値をできるだけ早く届ける。
- その２本柱が「改善」と「人々に対する敬意」である。
- 真ん中に「プロダクト開発フロー」がある。
- これはややこしい。。。
- 基となる概念は、TPSとか、待ち行列理論とか、軍の用兵術がある。
- 顧客から注文を受けてからお金を頂くまでの所要時間に注目し、無駄を省きましょう。 by 大野耐一
- 価値の納品までの過程のサイクルタイムを短くする。
■ プロダクト開発フロー： 待ち行列とバラツキ （P.16）
- 基本となるのは「リトルの法則」である。
- 単純にいうと、待ち時間を減らすためには、「行列の長さを減らす」か「スループットを上げる」か。
- でもそんなに単純ではない。
- 例えば待ち行列が要求だったり設計だったりした場合、それらはバラバラにやってくる。
- 例えば稼働率が変わるとスループットが変わる。このように、バラツキの要因がたくさんある。
■ プロダクト開発フロー： 経済的効果を考える （P.17）
- 待ち行列は「製造」と「ソフトウェア開発」で異なる。
- 製造： FIFOで、到着した順に処理する。
- ソフトウェア開発： 製造と違い、待ち行列の順番を変えられる。それにより価値を早く高めて経済的な成果を上げられる。
- TOCとか制約理論は製造よりの考え方で、通信系の待ち行列の考え方とはちょっと違う。
■ より速くお金を生む （P.18）
- 「遅延のコスト」という概念がある。
- プロダクトの価値は、市場に投入された時点の価値が最大で、時間とともに下がる。
- プロダクトの投入の速さによって価値が変わる。
- 「遅延のコスト」が発生するプロダクトは、早くリリースすることが大事。
- プロダクト開発論の考え方が、SAFeの思想とプロセスのバックボーンになっている。
■ ポートフォリオレベル： 投資テーマ （P.20）
- 投資テーマ、投資額の決定
- どの分野にどのくらい投資するか、１年とかの期間で予算を割り当てしていく。
- 予算が決まったら、作るものを決める。
■ ポートフォリオレベル： エピック （P.21）
- ビジネスエピック
- 新しいプロダクトに関する取り組み
- アーキテクチャエピック
- プロダクトには直結しないが、プロダクトを作るために内部的に役立つもの
■ ポートフォリオレベル： ポートフォリオカンバンシステム （P.22）
- 何を作るかのアイデアを集め、バックログに追加して優先順位づけをして絞り込み、開発する。
- ここでカンバンを使う。
■ ポートフォリオレベルの例 （P.23）
- 投資テーマとして「インテリジェント家電」があるとする。
- そのビジネスエピックの候補として以下が挙がった。
- お掃除ロボット
- インテリジェント冷蔵庫
- インテリジェント調理器
- そこから、価値が高いものから選ぶ。
- 費用対効果を審査して、OKが出れば「ビジネスエピック」になる。
- 選ばれたものがポートフォリオバックログ（開発候補）になる。
■ プログラムレベル： 開発 （P.24）
- 開発すると決まったものを作るのがプログラムレベル。
- プロダクトオーナーじゃなくて「プロダクト管理者」が登場する。
- ここで言う「プログラム」とは、大規模開発のことを指す。
■ プログラムレベル： ビジョンとフィーチャー （P.25）
- 「エピック」を構成する機能を分解したものが「フィーチャー」である。
- 「ビジョン」はそのシステムを開発する意義（競合他社との差異など）を説明するドキュメントである。
■ アジャイルリリース列車（ART） （P.26）
- ビジョンやフィーチャーが決まると、アジャイルリリース列車を編成して開発を進める。
- ARTは５～１２のチーム ５０～１００名からなる組織。
- 人数的にも期間的にも、スクラムをスケールアップしている。
- ８～１２週ごとに開発したものを統合し、出荷可能なインクリメント（PSI）を評価して開発を進めていく。
- スクラムのチームを自然にスケールアップしたものがアジャイルリリース列車である。
- スクラムと対比するとわかりやすい。
■ 確実に納品するために同期する （P.27）
- すべてのチームが同じ周期で開発する。
- 各チームが作ったものを統合する専任として「システムチーム」がいる。
- PSIの前の最後にHIPスプリントというのがある。ここで品質安定化をする。
- PSIを使って、動くソフトウェアを評価して、次の計画を立てていく。
■ プログラムレベルの例 （P.28）
- まず「ビジネスエピック」を設定する。
- ビジネスエピックを「フィーチャー」として分解し、フィーチャー毎に担当するチームが編成される。
- チーム毎にスプリントでフィーチャーを開発していく。
- 最後にPSIのタイミングで、最低限の機能を達成できているか進捗状況を評価していく。
- フィーチャーを貯めているのが「プログラムバックログ」である。
- プログラムを実行することで、分野ごとにアジャイルリリース列車が並行で走っていく。
- それで軌道修正をかけながらプロダクトを開発していく。
■ アジャイルチーム （P.30）
- 「フィーチャー」は「ストーリー」に分解され、「チームバックログ」に積まれる。
- ストーリーは２週間以内に開発できる粒度となる。
■ コード品質 （P.31）
- 全体の品質を保証するために技術的なプラクティスを使っていく。XPのプラクティスが多い。
- アーキテクチャを初期の段階である程度は作りましょう、という点をSAFeは強調している。
■ ベクトル合わせ （P.32）
- エピックを決めて、フィーチャーに分解して、バックログに積んで、ストーリーになって、開発して、といった作業の詳細は、上の立場の人が全部決めるのではない。
- チームが一丸となって、お互いに責任分担しながらベクトル合わせて進めていく必要がある。
■ 土台： リーダーシップ （P.33）
- 中間管理職はリーダーシップ、部下の問題解決能力を育成していくことが重要である。
■ Q&A その１
講演の途中で、質疑応答の時間が取られました。
- Q1.
- Big Pictureの真ん中の層（プログラム層）で舵を取る人はプロダクトマネジメントに該当すると思うが、プロジェクトマネジメントは一番下の層にいるのか？
- A1.
- SAFeにプロジェクトマネージャ（PM）という役割はない。
- プロダクトリリース列車の横にいる「リリース列車エンジニア」が、スーパーエンジニアスクラムエンジニアに相当する。
- ファシリテートしたり相談役になったりと、スクラムマスターをスケールアップしたものに該当する。
- プロダクトオーナーは、SAFeでは「技術も分かり、詳細を決めていく人」を指す。
- 逆にプロダクト管理者は、ビジネスニーズを重視する人。技術はあんまりわからなくても良い。
- Q2.
- 「リリース列車エンジニア」の隣に「UX専門家」がいるが、これにについて教えてほしい。
- A2.
- これは共有リソースの役割がある。
- UX専門家は、「専門チームとして集中させるべき」という考え方と「各チームに配置すべき」という２つの考え方がある。
- どちらの考え方にも利点と欠点がある。
- ただ、まず中央で決めて、UX専門化はチームに参画しながら作業したほうがいい。
- UXデザインを先行して検討・実施し、概念レベルで考えてから実装するようにすることで、手戻りの無駄を減らすべき。
- トライ＆エラーでやるよりも、UXを安定化させてから実装にかかる方が良いのでは。
- Q3.
- 機能ごとにチームを分けると、機能要求がたくさん発生するチームと、そうでないチームが出るのでは。
- そうなると開発規模とかは各チームで一律にならないと思うが、その辺はどうなのか？
- A3.
- まず、各チームの人数は「７人±２人」で揃える。
- そこで、厳格に２週間毎に作ったものを統合していくのがSAFeの考え方である。
- PSIで各チームが作ったものを統合し、大きいレベルの機能が動くものを作り、評価に耐えるようにする。
- PSIは組み合わせテストのようなイメージ。残った細かいバグ対応とかをPSIで実施する。
- 「システムチーム」が２週間毎に各チームの成果物を吸い上げて統合し、簡単なテストをして各チームに評価を返す。
- このサイクルを進めていく。
■ 書籍の構成について
Q&Aの次は、配布資料の裏面に書いてあった、書籍の構成に関する説明です。
マインドマップで表現されています。あと、藤井さんの手書き説明もちらっとありました。
- 書籍は４部構成となっている。
- 第Ⅰ部 「概要」
- プロダクト開発フローの７つのテーマは説明が省略されてて、かなり読みづらいかも。
- SAFeの概要として「３つレベル」が紹介されているが、ここもDeanの前の書籍の内容を知ってることが前提となっていて、やや説明が不親切かもしれない。
- 第Ⅱ部 「チームのためのアジャイル要素」
- 「プロダクトオーナーの役割」の章がある。POは技術とビジネスを分けて考えたほうがいいんじゃないか。一人が両方を担うのは難しい。
- 第Ⅲ部 「プログラムのためのアジャイル要求」
- 「優先順位付け」の章があるが、フィーチャーの優先順位付けはPJの成功に大きく影響するので重要である。
- プロダクト開発フローの考え方を取り入れている。
- どういう人をプロダクト管理者として育成すべきか、みたいな事例の話もある。
- リリース開発列車のコンセプトの話とかもある。
- ユースケースの章はアリスター・コーバーンがかなりコメントしてくださった。
- 第Ⅳ部 「ポートフォリオのためのアジャイル要求」
- アーキテクトとチームはどう関わるべきかといった話がある。
- アーキテクトが全部決めるんじゃなく、チームと互いに決めるべき、という話とか。
- モデリングをちゃんとしましょう、という話とか。
- ドメインモデリングとかアーキテクチャモデリングの話とか。
- アーキテクチャレベルまで再構成しないといけなくなった場合、プロダクトを提供できる状態のままアーキテクチャを変えるためにはどういうやりかたがあるか、みたいな話もある。
■ Q&A その２
最後に、再度質疑応答の時間が取られました。
- Q4.
- SAFeのバージョンが、書籍は1.0で、日本語版サイトは2.1で、本家最新は2.5で、すべて異なっている。
- バージョン差異のギャップはあるか？
- A4.
- バージョン1と2.1で大きく変わった点として、バリューストリームの考えが2.0で入った点がある。Big Pictureの図の左上あたり。
- 旧バージョンでガバナンスが強すぎたところは、改訂が入ったりしている。
- すべてをカンバンシステムに通すのではないようにしたり、「テーマ」から「エピック」を飛ばして「フィーチャー」に行くパスとかも最新版では許している。
- ポートフォリオレベルもけっこう変わっている。
- バージョン2.5は、DevOpsという言葉も入ってきている。
- バージョンアップの情報を順に追えるような日本語の情報は公開されていない。。。
- Q5.
- アジャイルに詳しくない人に「エピック」と「フィーチャー」の違いをどう説明すれば良いか？
- A5.
- 「エピック」は、システムそのものを表す。例えば「インテリジェント掃除機」みたいに。
- 「フィーチャー」は、プロダクトが持つ機能を表す。例えば「自動でお掃除をする」みたいに。
- 「フィーチャー」はPSIというサイクルで実現できる粒度に切り分けられる。
- 「アーキテクチャエピック」は、MS Officeの各製品間で共通で利用する機能とかを表す。「クラウド連携機能」みたいに。
- Q6
- SAFeでここだけ押さえておけ、的なものはあるか？
- A6.
- SAFeで難しいのは一番上の層のポートフォリオレベル。
- というのも、企業毎にの戦略の練り方とかが異なるので、そこを白紙に戻してやるのは難しい。
- 更に、企画と開発が別会社とかもある。なので、会社間を超えるのは難しい。
- なので、真ん中の「プログラム」の層のアジャイルリリース列車が基本的な部分じゃないかな、と思う。
- アジャイルをスケールアップする本を何冊か読んだが、チーム間の連携を具体的に述べてるのがSAFeの特徴かな、と思う。
- Q7.
- SAFeはオープンか？
- A7.
- SAFeはPublicなので、Webサイトを見れば明日から使える。SAFeのコンテンツ自体は無償。
- ただ、SAFeのトレーニングとかはビジネスになっている。
- Q8.
- SAFeの構成要素にScrumやXPやリーンなどがあるが、既存のプラクティスありき過ぎでは？
- A8.
- 新しいものを組織に導入するには２パターンある。
- １つは、自分でゼロからフレームワークを考えて強い組織を目指すパターン。
- もう１つは、既存のプラクティスなどを利用して早く教育して上に持っていくパターン。
- ２つのパターンは、どっちもどっちである。
- 後者の典型は「学校教育」。学校教育は既存のカリキュラムで一律教育するが、それでも天才は出るので、天才が出るのは前者、というわけでもない。
- ビジネスはコストなどを考慮しなければいけないので、なんぜもゼロから、と行かない面がある。
■ 最後に、藤井さんが思う「SAFeの良いトコ」
- 「経営者」はアジャイルが企業を元気にしていくれるという期待感を持ちつつ、「開発者」はアジャイルをやりたいという気持ちを持っている。
- でも、「経営者」と「開発者」の間にいる中間管理職の層は、アジャイルに危険性を感じ、危機感を持っている。
- SAFeはそこにハマる。
- 中間層向けに説明している本なので、説得材料として使ってもらえればいいと思う。
★感想：
SAFeについて一夜で学べる、とてもよい機会になりました。
しかも書籍を３割引きで現地販売していて、つい買ってしまった！３割引きはデカいですよ。
んでも、やっぱこれだけ分厚いとね。。。
「アジャイルソフトウェア要求」の読書会とかないかなぁ。この分厚いの、一人で読むのはつらぽよ。。。 （チラッ #devlove
— makopi23 (@makopi23) 2014, 3月 25・・・な～んて呟いていたら
@makopi23 講演スライドは公開したいと考えています。また、4月下旬から読書会開催したいと考えています。
— 藤井 拓 (Taku FUJII) (@TakuFujii) 2014, 3月 25読書会もやるそうな。イヤッホーー！
ってことで購入した書籍を読むモチベーションも上がります。
SAFeは人によって意見も分かれるところも多々あると思うのですが、まず私は中身をきちんと知るところから。。。
イベント関係者の皆様、ありがとうございました～
