カラダで感じた！アジャイルマニフェスト
こないだの土曜日に「カラダで感じろ！アジャイルマニフェスト」というワークショップイベントに行ってきました。
10月13日 カラダで感じろ！アジャイルマニフェスト(大阪府)
半日でアジャイルに関連するワークショップを４つも体験するというイベントで、やってみたいと思っていたワークショップがあったので参加しました。
講師陣（スクラム道関西）の皆さん、楽しい機会を提供いただきありがとうございました。
１チーム４〜５名の４チームでした。参加者全体で２０名くらいですね。
チームリーダーやプロジェクトリーダー的な役割を担っている人が多かったのかなあと思います。年齢的にも、話しぶり的にも。
ワークショップのネタバレ注意
ワークショップを実際にやってみたい人はその内容は検索せず、先入観なしでやってみたほうがいいと思います。貴重な体験をとっておきたい人は以下のワークショップを調べないことをおすすめします。
ということも考慮して、ワークショップの中身はぼやかして書きます。
１．マシュマロチャレンジ
これ、一回やりたかったんですよね。
なかなか道具を集めるのも手間なのでやらずじまいでしたが、やっとできました。
実際にやってみたら、思っていた以上に難しかったです。
変な先入観、決め付けをしない。あーだこーだ考えるよりも、とりあえず作ってみる。
空中戦をやめる。イメージを固める。何度も Try&Error する。
分かってはいるけれど、頭でっかちになってしまう。
その結果、時間がなくなったり、不測の事態が起こって計画が破綻する。
このワークショップは得るものも多く、楽しいので、何度もやりたいですね。
２．トランプゲーム
開発者数名とPO（プロダクトオーナー）１名に分かれます。
POとして参加しましたが、開発者と会話がない改善前の１回目の孤独感は半端なかったですね。
POが考えを伝えずに要求のみを伝えます。
そういう状況に置かれて開発者はどう思うか、リリースされたプロダクトはどうなるか。
ということだったのですが、うちのチームはなぜか強運の人たちばかりで、初回は散々なプロダクトができあがるはずが高評価なリリースができてしまいました。
結果だけ見るとよい成果でしたが、それに至るまでのプロセスは思い返すと綱渡りでした。
２回目、検討した改善案を適用した後はさらに高評価なリリースができ、それに至るプロセスも安心感のある、信頼のおけるものでした。
顧客を巻き込む重要性と開発者間のコミュニケーションの重要性を認識できました。
３．スペックデベロッパー
ドキュメントだけで仕様を伝える困難さと無駄さがおもしろいように痛感できました。
納期直前であっても仕様追加してしまうし、仕様追加を求めてしまうこの感覚はなんだったんでしょうか。実際の開発ならありえない感覚です、これは。
仕様を書く側も、それをもとに開発する側も、よりプロダクトを作ろうという同じ方向を向いているのであれば、納期直前の仕様変更というのはありえないことではなく、正統な選択になりうるということを感じました。
いかに現状があるべき姿から乖離しているかということがわかりました。
よいプロダクトを作ろうという意識はなく、早く終わらせる・予算内に終わらせることだけを考えてしまっていますね。
仕様変更が頻発するのはさすがに嫌ですが、仕様変更を快く受け付けられる仕組みと姿勢は持っておきたいです。
４．プランニングポーカー
プランニングポーカーは実際にもやっているので、おさらいでした。
プランニングポーカーをやると、見積りどうこうよりも、そのまえに前提条件の共有ができてないというのをいつも感じます。
タスクを洗い出すにも、タスクを見積もるにせよ。各人が想定していることがまったく異なっているのをまず是正できないと無茶苦茶になりますね。
数回見積りをやっていく中で「そもそも…」と前提条件の違いに気づくことが多いですね。
あと、私個人の傾向として、多めに見積もることが多いということがわかりました。
不測の事態が起こりそうだ、悩みそうだ、課題が多そうだというリスクや外的要因を考慮する傾向にあります。
懇親会
色々な社外勉強会に行くようになりましたが、今回はじめて懇親会に行きました。
人見知りなので、行くことを決断するまでかなりハードルは高かったです。
まあ、以前なら絶対に行くことはありえなかったので、ネガティブな習性は改善されてきているのかもしれませんね。
懇親会ではワークショップをした後なので話題に事欠かなかったで、沈黙なく助かりました。
講師の @masahirotaguchi さんが近くにいらっしゃったので、色々と話が聞けてよかったです。質問もできました。
自分のコンテキストに置き換えて考える
開発はそのコンテキストに大きく依存するので、これが正解というものはない。
アジャイルを考える上ではよく言われることです。
自分の職場をどうやって改善するか、どうやって展開していくかを考えなければなりません。
今回のワークショップの中で次のような問いかけがありました。
・ワークショップで改善できたようなことをどうして実際の開発ではできないのか。
・ワークショップで明らかにおかしいと思ったことと同じことを実際の開発ではやっていないか。
この問いかけには正直、言葉を失いました。
確かに明らかにおかしいことを受容し、改善する努力を後回することばかりです。
上司の理解がない。顧客を巻き込めない。社内標準に逆らえない。
いろいろな制約がありますが、それを言い訳にしていてはいつまでたっても変わらない。
思っている以上に、もっともっと現状分析や改善に向けての検討が必要です。変えるためには。
できたらいいなで終わらせないために、自分たちなりの答えを考え続けなければならないですね。
アジャイルマニフェスト
アジャイルマニフェストは本当によくできています。
この４文で端的に、明確にアジャイルの姿勢を表現できていると思います。
プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を
ワークショップを通して、しみじみとアジャイルマニフェストの意味することを感じることができました。同時に、この姿勢を貫く難しさも。
アジャイルソフトウェア開発宣言
プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を ...
