「アジャイルがダメだと思う7つの理由」について議論する会を大阪でしてきた
こちらに参加してきましたー。
この会は、3年半前に id:arclamp さんが書かれた以下のブログがきっかけで、
さらに 2016年5月18日に東京で、 「アジャイルがダメだと思う7つの理由」について議論する会 というのが盛大に開かれたのを Kawabata Mitsuyoshi (@agilekawabata) | Twitter さんが大阪でも議論しようよということで、開催していただけました。
参加した内容のメモとか所感を書きます。
鈴木さんのセッション
アジャイルダメセブンについて
アジャイルダメセブンの内容について、改めてお話をいただきました。
- 全体スケジュールにコミットできない
- アーキテクチャ上の無駄が生じる
- コーチってなんだよ
- 変化ヲ抱擁スルために固定化している
- 実証主義的な説明に過ぎない
- 手段が目的になっている
- アジリティはアジャイルだけのものではない
こちらはブログの内容を改めてご紹介いただきました。
3年半以上経って…
さらに、このブログ記事を書いてから3年以上経ってみて、のお話をいただきました。
ざっとメモは以下。
アジャイル、クラウド、DevOps => Microservices
結局はケースバイケース
エンプラによくあるケース
フロントシステムだけど、基幹システムと連携
- WF的にするほーがうまくいく。
業務プロセスの変更が頻繁だと効率が下がる
ITだけで業務が完結しない。 業務プロセスとの擦り合わせが重要。
業務プロセスとの擦り合わせって、今後も常につきまとう。
アーキテクチャは進化した
アジャイルを機能させるためのMSA
変更の影響が他のサービスに影響しない
モノリシックは、サブシステムの変更に5日と、影響範囲のテストに1ヶ月、リリースするための検証に1ヶ月みたいになる。
システムを停止せずに切り替えが出来る
瞬間的に2つのバージョンのシステムが稼動している状態で、ルーティングを切り替えることで、新しいバージョンになる。
日本の大企業が持っているシステムは、実は100システムぐらい余裕で持ってる。
2005年ぐらいのベンチャーは、既にシステムが古くなっているので、議論が大事
アジャイルは開発だけのものじゃない
モノを届けるのは、手段
アジャイル開発プロセスの定義
定期的であること
企業はそもそも定期的。
年1回見直しているはず。
その定期にITの結果を載せていくだけ。
4月にリリースとかってサイクルあるからそこに成果を持っていくだけ。
改善であること
やっぱりダメでした。でもこうしていきたいです。っていうカルチャーを持つ。
合意形成であること
参加者全員で状況を共有し、優先順位を決める。
そのうえで、進めていくのに、WF的なやり方をしていったりするのもあり。
WF型開発に慣れたエンタープライズ案件への提案
アジャイルダメセブンと、3年半経っての話の後、かるく質疑応答してから、最近、WF型開発に慣れた企業さんに アジャイルとハイブリッドな提案をされる機会が多いとのことで、そのあたりの概要をご紹介いただきました。
グループディスカッション
鈴木さんのセッションでテンションを上げていただき、色々と議論の種をいただきましたので、その勢いのまま、7つのテーマに分かれてグループディスカッションに突入しました。
以下は、私が参加させていただいたグループディスカッションの内容と所感です。
1.全体スケジュールにコミットできない
一回目のディスカッションは、こちらに参加しました。
このテーマに一回目で集った人数が一番多かったです。
おそらく、全体スケジュールにコミットした良い経験って皆さん、無いのかななんて…。
ディスカッションをするときは、ロープレ的に、「コミットできない派」と「コミットできる派」に分かれて議論しました。
アジャイルで出来る訳ないじゃん派が、いやいや出来るよ派に対して、できない理由を述べては、できる理由で返すっていうとても大人?な議論が展開されました。
私は、できる派に属して、できないのってこうだよねに対して、こうしたら出来るんじゃね?とか、それってそもそもできないんじゃね?とか、あーだこーだとディスカッションしました。
1時間ほどディスカッションしたのですが、最後の結論としては、
- 全体スケジュールにコミットするのは、アジャイル以外の手法ですと、大量のバッファを積むことで帳尻を合わせていることが多い。
- アジャイルの場合、このバッファを計画に含めず、変わりに、チームの成長によって予定していたスコープ以上の成果を出すことを計画している。
- アジャイルで全体スケジュールにコミットするには、この成長をどうやってスケジュールに組込み、見える化し、ステークホルダーに全体スケジュールとして承認を得て、コミットしていくのか、が重要。
- で、これらが実践できれば、コミットできるかも?
みたいな感じで結論としてみた。
まあ、もちろん、場合によりけりだよね。
3.コーチってなんだよ
二回目のグループディスカッションは、このテーマに参加しました。
これまた、「コーチいらないんじゃね派」と「コーチいるよ派」に分かれて議論しました。
私は、「コーチいるよ派」に所属し、いらねーよ派のいらない理由に対して、「こうこうこうゆー理由で要りますですげふぅ」って返しをひたすら繰り返していく議論となりました。
結論としては、
- コーチって、ティーチャー、トレーナー、コンサル、社内外といった色々なロールと混在されがちだよね
- また、フェーズによってコーチの要るタイミングってあるよね。逆に間違ったフェーズでコーチを雇うと危険な香りがするよね。
- フェーズを試守破離(教科書を読んで、「試」行し、弟子入りして、「守破離」すると表現していました)とするなら、試 => 守のタイミングでコーチ呼ぶのが危険かも。
- 社外コーチであるならば、社内の人間ではなく、社外である特性を活かし、人を育てて会社に貢献する成果を残すといった動機が最もあてはまるかなーと個人的に思いました。
全体所感
このような機会を設けていただき、参加させていただき、感謝申し上げます。 ありがとうございました!!
とっっっても楽しかったです!!
アジャイルがダメかどうかは、ゲンバ次第だと思いますし、ひいては発注されるサイドも巻き込んで色々と条件を整えてこそ、力を発揮できるんだと改めて思いました。
何を重視し、何を成すか、そのための手段としてのアジャイルであり、思考停止に陥いらず、積極的に議論し採用を検討し続けることが、より良い人生につながるんだろうなーって思います。
以上です。
あと…
id:arclamp さんがつい先日出版されたこちらをポチりました。
また、感想を投稿させていただければと思います。
Cloud First Architecture 設計ガイド
- 作者: 鈴木雄介
- 出版社/メーカー: 日経BP社
- 発売日: 2016/08/25
- メディア: 単行本
- この商品を含むブログを見る
