こくちーず
http://kokucheese.com/event/index/109869/
以下の書籍をターゲットとした勉強会なのです。
 | ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド (Object Oriented SELECTION) (2013/06/22) Scott W. Ambler、Mark Lines 他 商品詳細を見る |
DAD本に関するセッションを聴講するのは、これが３回目です。
初回はDevsumiで江木さん、次はDevloveで岡さんと藤井さん、そして今回の中佐藤さん。
ウチの会社も某・巨大SIerで、アジャイルを推進する立場にある私にとってDADの考え方には大変興味があります。
あと、DevloveのDAD本読書会にも参加してますが、この日も読書会の方が数名参加されてました。
顔見知りもチラホラと。
こーゆうイベントや勉強会でDADがもっと広がるといいですね～
というわけで、当日メモした内容を復習用にダラダラと書き起こしてみる。↓
■あしたの反復のために、その１
～ タイムボクシングのおさらい ～
講演者：津田義史さん（Microsoft IPX Team）
この日の講演スライドは公開されていないようですが、先日のXP祭りのスライドが参考になりそう。
トヨタのかんばんに学ぶバックログ管理術
http://www.slideshare.net/YoshifumiTsuda/ss-26194950
あと、津田さんの以下の著書も参考になります。
 | 実践 反復型ソフトウェア開発 (2012/12/01) 津田 義史 商品詳細を見る |
■タイムボックスとは
・タイムボックスとは、開発プロジェクトの期間を表す箱で、入り口と出口が付いている。
・作業とか機能とか修正するバグとか、時間を使うものはすべて箱に詰める。
・箱に詰めることを「タイムボクシング」と言う。
■作業が箱に入らない場合どうするか？
１．無理やり押し込む
２．箱を大きいものに取り替える
３．全部入れることを諦める
・正解は３。
・１は、残業とか休出とか作業の品質を落としたりとか、酷い品質で出来上がった挙句、チームが疲弊する。
・２は、結局箱が足らなくなる。いつまで立っても終わらなくなる。
・３は、本当に必要な作業から詰める。
・本当に必要な作業を詰めていく事で、苦痛を和らげる（mitigation）ことができる。
・不要なものを追い出すことでリーズナブルな値段で開発できるようになる。
■トレードオフ
１．品質
２．納期
３．範囲
・それぞれトレードオフだが、３を調整しましょう。
・タイムボックスの適切な長さは、入れたい作業の大きさによる。
・そうはいっても、大きすぎる箱は使いに行くい。その場合は、箱の中に箱を入れて入れ子にする。
・箱から溢れたものは次の箱に入れるのがタイムボックスの戦略。
■スコープボックスとは
・スコープ固定でスケジュールを動かすこと。フィーチャーボックスとも言う。
・これはデスマになりやすい。
■バックログとは
・残作業のこと。
・タイムボックスの入り口でバックログを作成し、タイムボックスの出口までに全部やる。
・「全部やる」とすると、タイムボックスとスコープボックスで何が違うか？
→ 計画の立て直し方が違う。
・スコープボックスは、スケジュールを延ばす。
・タイムボックスは、作業の範囲を減らす。入らないものは先送りする。これを「パントする」と言う。
・作業をパント（延期）することで、次のタイムボックスの中にいる誰かにキャッチしてもらうことを期待する。
・バックログはタイムボックスの「計画」である。無理な計画は立て直す。溢れそうな作業は早めにパントする。
・ポイントは、「早め」にパントすること。タイムボックスの出口で「できませんでした」はNG。
■ソフトウェア開発における在庫とは
・ソフトウェア開発に置ける在庫とは、スプリントバックログのこと。
①スプリントバックログ：このスプリントでやる作業
②プロダクトバックログ：次以降のスプリントでやる作業
・「バックログ」はスクラムの専門用語ではない。「バックログ」を辞書で引くと、以下のように書いてある。
１．残作業
２．在庫
３．着陸できない滞空中の未処理分
・飛行機は、着陸できない場合は上空で旋回する。
■バーンダウンチャート
（出展： トヨタのかんばんに学ぶバックログ管理術 P.55）
・グライドパス：理想的な滑空経路を表す。直線。
・フライトパス：実際の飛行経路。ジグザグ。
■在庫とは
・工場の在庫とは、出荷してない部品のこと。
・ソフトウェアの在庫とは、バックログの中にあってまだ完了していないもの。
■不良在庫とは
・工場だと、「出荷できずに抱え込んでいる在庫」のこと。
・ソフトウェア開発だと、スプリントの出口までに完了できる見込みがないもの。
・ソフトウェア開発の不良在庫を減らすには、バグ報告表やタスクかんばんの枚数を減らせばよい。
・では、どうやるのか？
→ パントする。これが今日のオチ。
■適切な在庫量を維持する
・適切な在庫量は、グライドパスが目安を教えてくれる。
・グライドパスとフライとパスが乖離していると安全に着陸できない。
■在庫のまとめ
・在庫(backlog)を計画的に完成(done)して出荷(deliver)する。
・在庫量を適切に保ちましょう。
■タイムボックスの本質
・パントの是非について。「パントって問題の先送りでしょ」って思う人がいるのでは。でも、そうじゃない。
・先送りしてはいけない問題と、先送りすべき問題がある。時間は有限である。
・そもそも前提として、パントしなくて済むように実現可能な計画を立てることが大切。
・もし溢れそうになったら
１．無理やり詰め込む。
→ 残業をして見込みがあるなら、残業するオプションがある。
２．箱を大きいものに取り替える。
→ これは止めるべき。ズルズルいくと、優先度を見失っていつまでも終わらなくなる。
３．全部入れることを諦める。
→ これが「パントする」ということ。
・建てた計画が無理と分かったら、作業の「品質、納期、範囲」のどれかを諦める必要がある。
・ここで諦めるのは「範囲」である。今やるべきことと、今やるべきでないものを正しく分けること。
・正しく２つにわけることで、納期を守り、箱をいっぱいにして、すべての箱で全力疾走しましょう。
■パントのまとめ
・現実的な計画を維持する。
・アジャイルも計画駆動である。無理と分かった計画は、「計画」ではない。
・優先度の低い作業をパントして計画を立て直す。
・設定したゴールにalignするように優先度を判断する。
・何度もパントしなければならないような状況なら、何かが間違っている。
・「パント」と言うと、ちょっとカッコイイ！「先送りする」というと、ネガティブな感じになる。
■DAD のエッセンス
講演者：中佐藤麻記子さん
2013/12/11 スライド追記
Dad紹介@豆ナイト from 隆之 豊島
■DADについて
・IBMのRationalの仕事をしたのが、DADに巻き込まれたキッカケ。
・DADは原著よりも少し薄くなっている。これは珍しい。
・DADの話は本の中に全部入っている。今日はエッセンスを拾って話す。
・先日のDevloveで岡さんがDADの講演されていたが、以外なエッセンスの引っ張り出し方をしていた。
・翻訳者でさえ人により何をポイントとして語るかが違う。今日は中佐藤さんが感じたエッセンスを話す。
■特徴１： エンタープライズアジャイル ≠ 大規模アジャイル
・「エンタープライズ」って何よ？となると、大体想像されるのが、「大規模システム」。
・DADは大規模システムだけじゃない。小さいシステムも含まれる。
・ここで言う「エンタープライズ」とは、「普通の企業システム」を指す。
・エンタープライズアジャイル ＝ 普通の企業システムのアジャイル
・「継続的デリバリー」はWebアプリのゲーム開発とかのイメージがあり、一般企業システム開発のエンジニアにとっては「ウチとちょっと分野が違う」と思う人がいる。DADは、こういう人のためのもの。
・DADは「普通のアジャイル＋α」がある。企業システムが対象である。
■特徴２： 現実直視
(1)
・DADの前書きの１行目に「プロセス戦争は終わった、そしてアジャイルは勝利を収めた」と書いてある。
・前書きにあるように、「やっぱアジャイルは効果を出しているよね」というのが実際。
(2)
・スクラムだって、スプリントを始める前に準備作業したり、移行作業もしてるよね。
・なら、「はっきりとそう言おうや！」
・DADはその結果としてフェーズ分けをしている。「方向付け」、「構築」、「移行」の各フェーズ。
・フェーズ分けは非常に難しい。「それってウォータースクラムフォールじゃね？」と誤解されかねない。
・これを如何に伝えるかが重要。まず本の読み方として、「ケーススタディ」を読んでください。
・ケーススタディを読むと、一番手っ取り早く、そのフェーズで何をするかが分かる。
・移行フェーズが、ウォータースクラムフォールの「フォール」じゃないことがよく分かる。
■特徴３： ゴール指向
・それぞれのフェーズにゴールが決まっている。
・「この成果物を作ったら終わり」とかじゃなく「このゴールを満たせれば終わり」としている。
・例えば方向付けフェーズのゴールの１つに「ビジョンを特定」と書かれているが、そのやり方は本に書いていない。
・DADは抽象的に書いてある。抽象度を１つ上げている。
・「このゴールを満たしなさい」という徹底的なゴール指向。
・では「ビジョンを特定」をどうやるか？結論は「自分たちで選びましょう」。
・DADは、その選択肢がたくさん書いてある。
７つのプロセス
６０のプラクティス
３７の戦略比較表
１９５の戦略
（岡さんが数えてくださった！）
・DAD本にはこれだけ載っている。ここから好きなの選んで！という方針で書かれている。
・これを聞いて「なーんだ」と思われるかもしれない。でも、DAD本の21章にはこう書いている
「あなたが直面している固有の状況に、最も効果的にアジャイルを適用する方法について、あなた方に正確に伝えられるような本を我々が書くことができると仮定するのは、おこがましいことだろう」
・DAD本の翻訳者の半分はIBMの社員。私も、IBMの方からの一言が今でも支えになっている。by 中佐藤氏
・その一言とは「Think」
・これが一番大事な言葉。DAD本は21章の文章にもあるように、「自分で考えていただきたい」と行っている。
・その考える方向付けをするのがDAD本の役割である。
■お気に入りポイント１： 「時々、妙に細かい」
・例えば15章の「日時調整ミーティング」には、以下のように書いてある。
"「私は、今日はほぼ終日ミーティングです」という発言だと、「あっそう」で終わる。
そうじゃなく、チームに対し、自分が今日何をするかを具体的に話すこと。
例えば「今日はDBAと30分ミーティングをして、～して、さらには～して～します」と言ったほうがよい。
そうすると、チームとの情報のやりとりが発生する。"
ここまで書いてあって、妙に細かいｗ
■お気に入りポイント２： 「時々、妙に嫌味ったらしい」
・本の帯に「初期に詳細に要件定義された要求は、詳細に定義された憶測にすぎない」と書かれている。
・時々、妙に嫌味ったらしいｗ
■お気に入りポイント３： 「そう、それ！」
・8章に「本当の価値は作成されたモデルではなく、モデリングという作業そのものにあることを認識すること、これを重要な思想として採用すべきだ」と書いてある。
・要するに、作ったユースケースに意味があるというよりも、ユースケースという道具を使って、チームで議論して認識が一致することが重要である、と言っている。
・「アジャイルな見積りと計画づくり」という書籍でも、「計画が重要なのではなく、計画づくりが重要なんだ」と言っている。
・できたもの「そのもの」じゃなくて、「それを使ってチームで合意がとれること」が重要である。
DAD本には「そう、それ！」と思えるようなことが書いてある。
■（自称）アジャイラー（アジャイリスト）へ
(1) 先人の多くの知恵の上に、アジャイルが存在していることを認めましょう
・CMMIやRUP（Rational Unified Process）/UP（Unified Process）も、ちゃんと使えばガチガチなものではない。
・非難する人は、使い方を間違えただけ。
・RUP/UPは反復なんだけど、重いということでアジャイラーから目の敵にされる。
→ とんでもない。アジャイルを知っている人ほど、軽く使えるはず。使えない「人」が問題なんだ。
・アジャイルサムライの「インセプションデッキ」の中身は、RUPの「開発構想書」というドキュメントそのもの。
(2) ほとんどの開発（企業内システム）では、「その他の利害関係者」が重要であることを認めましょう
・反対派が目につく。アジャイルはロールをあまり決めていない。
・でも既存システムとかは、「その他の利害関係者」がすごく重要。
・DADのターゲットはエンタープライズであり、既存のシステムとの関わりの中でシステムを立ち上げなくちゃいけない。
・いろんな制約や人の中でどうやるかをDADはターゲットにしている。
(3) 設計手法抜きにアジャイルは語れないことを認めましょう
・スクラムというフレームワークは、作業の回し方のみ定義していて、設計手法の話はしてない。
・でも、設計手法の話は必要である。「設計せずにモノ作ればいいんだろ」は誤解である。
・設計しないと、とてもスプリントなんか回らない。ちゃんと設計手法ありきのアジャイルをやりましょう。
■アジャイル（実質）否定派へ
(1) そろそろ言い訳をやめませんか
①契約
②品質管理
③人
・よく言われるのが、「自立性がある人がいないとダメなんだよね」
・でも、それって本当か？自立性が無い人と思い込んでプロジェクトを作っていないか？
④日本固有の環境
・一番大嫌いな理由。言い訳以外の何者でもない。アジャイルの手法はWFでも取り入れることはできる。
・「ウチの会社・業界は特殊だから」という言い訳。
・そもそも、すべての会社はすべてユニーク。
・その中でいかに改善できるかを考えるのにアジャイルを検討すべき。
(2) そろそろ現実を見ませんか
・本当に、一括請負でスコープ調整はしていませんか？
・本当に、最初に要件定義、設計したとおりに最後まで作っていますか
・本当に、プロセス・テンプレートがあれば誰にでも作れますか？
・アジャイルの標準プロセスを作りたい、とよくおっしゃる。
・会社で標準を作って、「これを使え」と言えば誰でもいけるか、というと無理。
・そうじゃなく、教育と両輪で考える。教育を先行させる必要がある。
・優先順位を間違えている会社が多い。テンプレートを作れば誰でもいけるか、というとそうじゃない。
・ウォーターフォール以上に、アジャイルは教育に力を注ぐべき。
■パネルディスカッション：「アジャイル開発の行方」
・モデレータ：羽生田さん
・パネリスト：津田さん、中佐藤さん、山田さん、藤井さん
■書名の「ディシプリン」ってなんなの？
・翻訳チームが一番揉めたのが「Decipline」の翻訳。翻訳者が11人もいると、用語集を作るので揉めるｗ
・用語を決定する基本は、売れている本に合わせる。例えば「アジャイルサムライ」とか。
・文化的な背景から思い浮かべるイメージは実際と異なる。
・「規律」と聞くと、上からやらされるイメージになってしまう。
・翻訳者で「丸々２時間、ディシプリンについて語る会を開こう！」
→ でも、その会に監修の藤井さんが来なかった。。。
・結果的にディシプリンは「規律」と訳すことになった。
・津田さんの著書「実践 反復型ソフトウェア開発」では、「ディシプリン」は「職種」という意味で使っている。
→ それは職種によって従う規律があるから。
・「ディシプリン」という意味には「体系化された知識」という意味がある。
・アジャイルはほっとくと気ままにやられるイメージがあるので、整理して体系化するという理由で「ディシプリン」とした。
・DADは「お行儀の良いアジャイル」。ディシプリンに絡んで、「作法（さほう）」という言葉を使うことがある。
■DAD本の使い方
・方向付けの章は、ゴール指向とかが纏まっている。あれをチェックリストがわりとかで使える。
・必要な部分を選んで、お試しスクラムの中でやったりしている。
・「方向付けフェーズ」が一番大事で、あの表が一番つかえるなぁ、というのが実感。
・始めてアジャイルをやる企業さんは「で、最初に何したらいいの？」とよく言われる。
→ DADはそのリファレンスに役立つ。コンサルのネタ本として使える。
・開発チームのメンバなら「アジャイルサムライ」とかを読めばいいと思うが、DAD本が今までのアジャイル本と違うのは、ステークホルダーが敵対していたりとか、どこから手をつけてどう進めるのがベストに近いのか、とかのヒントを与えてくれる点である。
・DAD本はアジャイルのコンサルや、経営者の説得をする人の役に立つ。今までのアジャイル本とは系譜が違う。
・DAD本は、アジャイルの環境をアジャイルと関係のない人を含めてエコシステムとして記述しようとしている点が新しいとこかな、と思う。
■エンタープライズと大規模開発について
・XP祭り2013の著者パネルディスカッションでも書いたが、「エンタープライズアジャイル＝大規模開発」を想像してほしくない。
・DADは大規模アジャイルをやる手法ではない。
・DADは「Scaled Agile Framework(SAFe)」とは別物である。
・Developers Summit 2013 Summerで「エンタープライズとDevOps」というパネルディスカッションがあったが、エンタープライズの定義を誰も説明しなかったｗ
・大規模の前にディシプリンのステージがある。
・大規模でもアジャイルはできると思っている。できないのは、アーキテクチャとかちゃんとしてないだけ。
・エンタープライズアジャイルはしがらみ。そこはシステムの規模の大小じゃない。
・リーンスタートアップのように、１から新規開発というのはほぼ無い。
・周りの人的環境がまったく違うのはエンタープライズの論点。
・自分たちが置かれた他社との関係性について、DAD本は表にたくさん書いてある。
・それをユーザと見て、どれを採用するかを決めていけばよい。
・タイムボックスを大規模プロジェクトに導入する時に「タイムボックスで同じ期間を繰り返す」というのは本質ではない。
・いつものスプリントは４週間だけど、今回６週間でやろう、というのもある。
・規模が大きくなればなるほど、出口を共有するのは不可能。その場合はサブチームでタイムボックスを切ってもよい。
・大きなタイムボックスの出口をメンバーで共有するのが大事。
■DADを現実ラインに落とすには
■Question
・DAD本は分厚い。現場で危惧しているのは、DADと別物ができてしまうのでは？という点。
・このくらいで十分だよ、とか現実ラインに落とすのが大事だが、どんなふうに落としていこうと思われるか？
■Answer
・これは一概に言えない。一つの会社でもプロジェクトによって違う。
・アジャイルのアンチパターンでさえ、あるチームには有効だったりする。
・３人ペアプロとかうまくいった事例とか、朝会を毎日１時間やる上手いミーティングを見たことある。
・ここで絶対忘れていけないのは「コンテキスト」という言葉。「何が優先か」というとコンテキスト。
・３人ペアプロとか１時間朝会がなぜ上手くいったのか、の「なぜ」を考えることが重要である。
■品質保証(QA)のエンジニアさんへのお願い
・プロセスを標準化して品質を上げようとする考え方を、少し違う方向に向けていくべき、と考えている。
・というのも、あるQAエンジニアから「DADの区切りを標準化したいんです」という相談がきたことがあった。
・その時は「一概には無理です」と回答した。
・その人に何を薦めたかというと、「スクラムをやってるチームを実際に見に行ってください」という点。
・現場によって求められているものが違うので、現場を見て、もう一度、線引きを考えてみてほしい。
■チームのルール
・プロジェクトの規模が大きくなればなるほど、ルールを厳密にする必要がある。
・プロジェクトが小さくても、守るべきルールはある。例え小さくても守るべき。
・まずは絶対に守ってもらえるルールから入る。
・開発の段階でもルールは変わる。
・プロジェクトが進むに連れて、ガイダンスをチームに出してやっていく。
・そうすると、上手くいかなかったルールを外すこととかができるようになる。
■お客さんから指標を求められたらどうするか？
・お客さんは決められないので、こちらから指標は出すようにしている。
・品質保証部門のエンジニアは、手順を決めてガイドを出すことが仕事だと思っている。
・本たくさん読むくらいなら手を出しなさい。そこから理解が深まっていく。
・何をもって自分たちのものが成熟するのかを考えること。
・プラクティスを足すにも、足すとどうなるのかをきちんと考えること。
■アジャイルと契約
・アジャイル開発をやるから契約をこうします、とお客さんに言えたら、それはラッキー。
・でもRFPに「アジャイル開発を一括請負で」と書いてあれば、それは受け入れるしかない。
・じゃあどうするかを考える。
・でも、今までウォーターフォールでスコープ調整ってしてないか？というと、実際はやってるでしょ。
・それをやりやすくしましょう、と言っているのがアジャイル。
・契約は開発チームからはどうしようもないところで決まる。
・アジャイルでやる時に、結果的に契約がどうこうだから上手くいかなかった、というのは経験がない。
・消去方法でいったら準委任契約が良い。
・でも、結局は契約とか品質とか、互いにどうやればいいか、という点に尽きちゃう。
・アジャイルだからどうこうじゃない。
・ウォーターフォールのプロジェクトは失敗に慣れているから、言い訳がつくだけ。
・でもアジャイル開発は慣れてないから、契約で失敗するとdisられる。
・何のためにお金を使うのか、という根本が考えられていないから、契約の話に行ってしまう。
・契約を口にだすのはウォーターフォールでも出来ないんだ。
■アジャイルの普及について
・「アジャイル、アジャイル」、もうウルサイ！
・そうじゃなく、アジャイルが当たり前になってほしい。
・アジャイルがあたりまえになるのは、オブジェクト指向があたりまえになるより圧倒的に早い。
・アジャイルは「合理性の追求」という言葉が一番しっくりくる。
・そういうマインドがない限り技術のトレンドに確実に置いてかれる。
2013/12/11追記
ブログを書いた後、Youtubeに動画が上がっているのを知ったので貼り付けておく。
★感想：
皆さんのお話を聞いてて、「なるほど、やっぱそうだよね～」と思うことが何度かあって、大変参考になりました。
中佐藤さんの「そう、それ！」みたいな感じｗ
あと、翻訳者の江木さん、岡さん、中佐藤さん、藤井さん、それぞれポイントに挙げている点が異なるのも面白いですね。
こーゆう生の声を、複数人の翻訳者から聞けるというのは大変貴重です。
いろいろ気付かされて、反省するハメになりました。大変ありがたい。
関係者の皆様、ありがとうございました。
