読者です 読者をやめる 読者になる 読者になる

HOW TO GO

〜昨日の今日とは一味二味違うBlog〜

「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加してきました。#devlove

2013.7.16 「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加しました。

http://devlove.doorkeeper.jp/events/4659

その名の通り、
ディシプリンド・アジャイル・デリバリー 〜エンタープライズアジャイル実践ガイド」に関する勉強会です。

ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド (Object Oriented SELECTION)

ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド (Object Oriented SELECTION)

  • 作者: Scott W. Ambler,Mark Lines,藤井智弘,熱海英樹,天野武彦,江木典之,岡大勝,大澤浩二,中佐藤麻記子,永田渉,西山泰男,三宅和之,和田洋
  • 出版社/メーカー: 翔泳社
  • 発売日: 2013/06/22
  • メディア: 大型本
  • この商品を含むブログ (6件) を見る

講師は翻訳チームの一員である岡 大勝さん。監修の藤井 智弘さんもいました。

岡さんの話

DAD本(「ダッド」と読むことにさっき決まったらしい(笑))の構成や狙いなど、ご自身の解釈を交えたお話でした。
以下メモ。

エンタープライズアジャイルを定着させる

DAD本はIT業界に蓄積された「知」をうまく使い、エンタープライズの開発をもっとよくするためのもの。
エンタープライズ」はこんな感じだそうです。

  • ある程度規模が大きく何かしらの"しがらみ"がある
  • 例えば、連携するシステムが多かったり、既存の運用の制約があったり
  • 例えば、ステークホルダーが多かったり、規約やルールがあるような
  • スタートアップのように独立して作れるようなものじゃないイメージ

アジャイルの現実とエンタープライズとのギャップ

  • アジャイルには負の側面もある。
  • ウォーター・スクラム・フォール(ウォーター・スクラム:準備が遅くいつまでたっても始まらない、スクラム・フォール:いつまでもリリースしない)となってしまっていたり
  • アジャイルだからと言ってガバナンス・組織から目を逸らしてしまったり
  • 流儀の固執し古いものをハナから否定してしまったりしている。
  • これはすべてベンダーの怠慢。プロセスの無理強いだったり、リスクからの逃避。
  • それもあってか、アジャイルエンタープライズは(特に日本では)ちょっと離れたモノとなっている。
  • ギャップがあるとリスクやコストが掛かる。
  • アジャイルエンタープライズの中心に持っていくのがDADの思想。ギャップを無くしたい。

BxUP:Big xx Up Front にならない

「Big xx Up Front : 最初にしっかりxxをする」にならないように、というお話です。
これ今日一番印象に残りました。
最初にしっかり設計する、最初にしっかり要件定義する、など、xxには様々なものが入ります。
これがアジャイルではダメ。

  • 「最初にしっかり」という行動様式は成果物駆動となってしまう
  • 成果物駆動になると、早い段階から完璧なもの作ろうとしてしまい、時間が掛かってしまう
  • ムダなものを多く作ってしまうことになりがち
  • アジャイルJIT:Just In Time
  • 必要な時に必要なことをする。詳細な設計が必要な機能、ワークフローの分析が必要な要求、そうじゃないものもある。

DADの3つのフェーズ

  • DADで核となっているのはScrumだが、開発の前に「方向付けフェーズ」があり、開発後に「移行フェーズ」がある。
  • これはScrumでは定義されてないが、みんな実践している必要不可欠なもの。

確かにエンタープライズでは企画段階や移行のことは大事です。

ダイアログ

4人でグループを作ってのダイアログ(対話)です。
我々のグループでは、

  • 受託開発してるとBxUPになりがち
  • アジャイルの価値をマネージャーや顧客に説明できないことがある
  • 特に品質や生産性の話になるとうまく説明できない
  • アジャイルでの契約ってどうやってんの?

という話などが出ました。
「BxUPになりがち」ってのは本当に共感してしまいます。僕のチームでは振り返りで「認識の齟齬があった→ドキュメントをもっと書こう」といった意見が頻繁に出ます。
認識齟齬→ドキュメント必要となるのは完全に脊髄反射です(笑)本当に必要なものかどうかを考えてみるのが大事ですよね。

質問タイム(受託でアジャイルはどうなのか?)

「顧客を巻き込むには何が大事ですか?」という質問がありました。
岡さん、藤井さんとも「受託でアジャイルは難しいんじゃないか」(7/17 訂正)「受託で顧客を巻き込む必要はないんじゃないか」*1との意見です。身も蓋もないですよ(笑)

  • アジャイルは予算を上手に使う開発手法であり
  • 顧客はそこまで考えていない。単純にキャッシュアウトが減ればいいと思っている。
  • 顧客側が真剣に考えていない場合は、巻き込むとは土台無理な話であり、アジャイルと言っても響かない
  • 顧客側からアクションがでるようにSIerは顧客を啓蒙すべき

非常に示唆に富んだお話…。ちょっと目の前が暗くなりました。あ、明日から頑張ります。

そういえば、チームがBxUPにならない工夫や取り組みはあるか?と質問したかったのですが、時間がなくて出来ませんでした。残念。

感想とか

DADは僕がなんとなくイメージしているエンタープライズアジャイルの姿と同じように思えました。
まずは書籍を読み込み、自分だったらどういうプラクティスやツールを組み合わせたプロセスにするか、をシミュレーションしてみると楽しそうです。自分の積み上げた知識や経験が整理できそう。

自分の引き出しが増えそうな良い勉強会でした。

最後に、DADと関連してるよ、と以下の本をお勧めして頂きました。(この本であってるかな…?)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

追記(7/17)

スライドが公開されてました。

*1:受託でアジャイルは十分可能であり、それをするためのDADとのことです。誤解を招く記述でした。すみません…。