世間ではアジャイルがダメだとかダメじゃないといった話題が盛り上がっていたようだ。個人的には、アジャイルがダメかどうかは知らないけれども貴様のプロジェクトがダメなんじゃね?と思ったのだけれども、その思考は水に流すことにする。ところで話題の記事を読んで、アジャイルコーチというものについて考えたのでそれについて書く。勢いで書いているのでいつもより乱文で。
- アジャイルがダメだと思う7つの理由 - arclamp
- アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
- アジャイルがダメなようでダメじゃないちょっとだけダメだと思う7つの理由 - Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。
アジャイルコーチとは何か
適当にまとめてみるとこんな感じといった印象。
- アジャイル開発に関する専門家である
- チームを支援する。チームを改善する
- 雇用期間はプロジェクト期間に連動しない
- 途中で去ることができる
- 製品コードを書くこともある(もちろんテストも)
- 触媒のようなもの
と、ここまで書いてふと考える。「技術コンサルタント」とは何が違うのだろうか。一見すると何も変わりがないように見える。しかし、おそらく以下の点が違うのだろうと予想している。
- 技術コンサルタントは『プロダクト』に責任を持つ
- アジャイルコーチは、『チーム』に責任を持つ
だとするとアジャイルコーチは素晴らしい商売なのではないか。
批判されにくい
以前にこんな事を書いたことがある。
アジャイル手法は他の手法に比べて、プロセスやツールよりも個人と相互作用を重視する。ということは、アジャイル手法を導入したプロジェクトがたとえ失敗したとしても、原因が(手法ではなく)個人と相互作用となってしまう。よって、うまくいかなかったプロジェクトも「アジャイル手法で失敗した」というよりも「メンバーが適応できなかった」と論じられてしまう可能性が高い。アジャイル手法は真正面から批判されにくい手法とも言えるのではないか。
アジャイル手法によって生産性が上がりプロジェクトは成功するか?(いいえ) - 勘と経験と読経
- 技術コンサルタントは、プロダクトの失敗の批判を受けやすい
- アジャイルコーチは、チームの失敗の批判を受けにくい
とすると、アジャイルコーチは素敵な商売なのではないかと思う(こんな事を書いたらとても怒られそうだけど)
プロジェクト・ビジネスにロックインされない
わたしにとってのアジャイル開発の気に食わない点は、プロジェクトやビジネスにロックインされてしまうことである。
でも、完璧じゃない。大抵の場合は要員を固定化するという前提が付くのです。ロールベースでないとノウハウが人に貯まり、どんどん引き離せなくなる。そして、同じ事を繰り返すメンバーはモチベーションが下がり、いつか辞めることになるのだ。
アジャイルがダメだと思う7つの理由 - arclamp
SI屋の良いところの一つは定期的に現場を転戦できるという点だと考えている(出来ない人もいるけれど)。基本的にはプロジェクト制なので、ひとつのプロジェクトが終わったらメンバーは解散して次のプロジェクトに向かう。しかし、アジャイルチームではこういったことは難しいのではないかと考えている(あくまで推測)。ただ、アジャイルチームのメンバーと違って、コーチはこの制約を受けないだろう。これはコーチ(をやる人)の大きなメリットではないだろうか。
いろいろ書いてみたけれども、コーチだろうとコンサルタントだろうと、外部戦力を活用するというのは重要だと思う。何よりも「最高の情報伝達手段はヒト」である。知識と経験値を持った外部戦力によって、プロジェクトが良くなるのであれば何だってよいだろう。
しかし、プロジェクトに責任を持って推進するのは彼らではなくてわれわれである。そこを考え違ってしまうと、大きなトラブルになるのは間違いないだろう。

- 作者: G.M.ワインバーグ,木村泉,ジェラルド・M・ワインバーグ
- 出版社/メーカー: 共立出版
- 発売日: 1990/12
- メディア: 単行本
- 購入: 21人 クリック: 197回
- この商品を含むブログ (89件) を見る

アジャイルと規律 ?ソフトウエア開発を成功させる2つの鍵のバランス?
- 作者: バリー・ベーム,リチャード・ターナー,ウルシステムズ株式会社,河野正幸,原幹,越智典子
- 出版社/メーカー: 日経BP社
- 発売日: 2004/08/05
- メディア: 単行本
- 購入: 9人 クリック: 112回
- この商品を含むブログ (77件) を見る