[#aj12] コマンドコントロールではなく、メンバーを守るでもなく、協調へ!
Agile Japan 2012 では、発表準備もあってあまり発表を聞けなかったのですが、印象に残るセッションが“「アジャイルのあるとき、ないとき」 ~アジャイルは関西ビジネスをどう変えられたのか?そしてこれからどこに向かうのか?~”です。
関西ながらのコテコテのテーマですが、内容は充実していました。最も印象的だった議論は、「ある時と感じたのはいつですか?」というものでした。そこで出た言葉を並べると
「アジャイルには2つあり、アジャイル・プラクティスとアジャイル・マインドだ」
「やっぱり考えるようになった時、自主的に振り返りをするようになった。」
これがアジャイルなのでしょうね。プラクティスそのものよりも、マインドが大切で、メンバーが自律的に行動する組織になることが、アジャイルなのでしょう。そして驚いたのが、この発言です。
「プロジェクトファシリテーションのきっかけは、土屋さん!」
これはちょっと解説が必要ですね。XPJUG関西の2代目代表をされた土屋さんが、XPのテストの考え方を開発と関係のない部門に適用された話を聞いて、平鍋さんがプロジェクト・ファシリテーションを始められたそうです。ファシリテーションの視点は一般化にあったのですね。
アジャイルがマインドであるなら、それは開発だけでなく様々な場面で利用可能なものです。実際、従来型の開発においても応用可能だと思っています。しかし、そんな思いを打ち砕く一言が、、
「カンバンをお客様と見ることで、問題と、お客さんを含めた私達の関係に持ち込む!」
この一言には、参りました。私はアジャイル開発でなくても、アジャイル・マインドが実現できると思っていました。リーダーやマネージャがコマンド・コントロール しようとせず、チームを守ることで自律的な組織というのは、実現できると思っていました。
しかし、アジャイルではチームを守る必要がなかったのです。仕様変更やお客様の無理難題からチームを守って、開発に集中でき、自律的に行動できる環境を作ることだと思っていましした。これはファシリテーションにつながるとても大切な考え方だと思っています。しかし、お客様と同じ方向を向くことがアジャイルだったのですね。
また、前の記事に関わるコメントもありました。
「なんのためにAgileするのか?」
やっぱり、これが本質なのでしょうね。現場に問題があり、それを解決するために新しい技術やプロセスを導入することがポイントなのでしょうね。
それに反して、組織の運営をハンコ中心に運営する
「ハンコ駆動開発(HDD)」
では、ビジネススピードがアがrわけがありませんし、Redmineを導入しても
「Redmineがハンコになっている!」
という状況では、未処理のトレーとRedmineの両方を見なければいけない分だけ、不便になるだけです。
アジャイルはすでにブームを過ぎて、本格的な普及期に入ってきたと思います。そしてアジャイルに関しても、より本質的な議論が始まって来たという印象を受けました。今後の本格的な発展に期待しています。
« [#TiDD] チケット駆動開発もAgileもより本質の議論に #aj12 | トップページ | [#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 - »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
« [#TiDD] チケット駆動開発もAgileもより本質の議論に #aj12 | トップページ | [#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 - »
コメント