アジャイルコーチというロールについて

エンジニアの学ぶべきことの深度は日々増加していて専門性も高くなり、そのために協調して働くスキルが必要になってきていると思います。

付け加えて言うなら、深くなってるんだから潜るのには勇気がいります。
誰もが教科書やコードを読んで、教えてもらうことなく技術を使いこなせるとは限りません。
たとえ技術力や意思力でヘタレだったとしても、そういった未知の領域に潜っていく勇気を与えてくれるのがスクラムやらXPであると思います。
スクラムやXPが生産性にすぐに直接影響を与えることが大きいとは自分は思っていません。継続的にやってこそ効果が出ると思います。

スクラムやXPの具体的な内容についてはここでは言及しませんのであしからず。

ただわかっているのは、やみくもにそういったプロセス改善のフレームワークを用い、プロジェクトがうまくいかないこともあると思います。
根本的な原因は、そのフレームワークそのものにあるのではなく、プロダクトの品質をキーにしたマネジメントをしていないということだったりします。
あるいは人同士の相互作用でプロダクトができるのを無視して、信頼関係の醸成やコミュニケーション(特に意思決定のルール)を軽視していたりすることだったりもします。
原因はともかく、うまくいっていないという現実の課題に踏み込まないまま、プロセス改善のフレームワーク(の上辺だけ)を適用しようとすることだけに注力しようとするのは自分は非常に危険だと思っています。

(そんな状態が続くとエンジニアのフレームワークに対する嫌悪感がたまり、悪のオーラ力がたまってハイパー化します。あるいは、エンジニアのソウルジェムが濁っていき、魔女化します。)

上手くいかないときはアジャイルコーチに頼ってみよう

そこで出てくるのがアジャイルのコーチです。
僕の知っているアジャイルコーチの最初に言った一言は「スクラムの教科書的な答えが知りたいですか？開発をうまく回したいんですか？」という内容です。
スクラムを単純に教えてくれる先生ではありません。

現場の課題に踏み込み、信頼して任せるということ

よく言われることだと思いますが、(良くないOJTのように)放任するというのと、信頼して任せるのは違います。

最初の段階では、アジャイルコーチはチームに問題があるかどうかを観察し、その課題に対してチームがちゃんと踏み込めるようにお膳立て(ファシリテーション)します。
具体的には、振り返り(retrospective)の効率的なやり方としてタイムボックスを提案してみたり、ときには簡単なワークショップもその場でやったりもします。
僕たちのチームの最初の課題として、KPTのproblemが浅く、tryの理由づけとして機能が弱かったというのがありました。
それを解決するのになぜなぜ形式でチームに問題の掘り下げをさせ、ボトルネックになっていることは何かということを追求させました。
やってるのはあくまでもお膳立てですが、ちゃんと現場の課題に踏み込みます。

コーチはそうした観察とデウスエクスマキナのような(だとちょっと言い過ぎかもしれませんが)交通整理を繰り返して、ある程度になった時点でチームを信頼して任せてくれたと思います。
決して教科書読ませてワークショップやって良かったねして、あとは自分でやれという感じではないです。

(新入社員の初年度研修などはそういうふうにせざるを得ない事情もあると思いますが・・・)

アジャイルコーチ、何となく良さそう！

アジャイルコーチとして、ファシリテーションの技術だけでなく、アジャイルに限定しない問題解決のプラクティスの引き出しが重要になると思います。

あくまで個人として感じたことですが、いいコーチはチームの困ってることを助け、自信を着けさせてくれると思います。
皆さんがアジャイルコーチというロールについて知らなかったのでしたら、「何となく良さそう」と思ってもらえるとうれしいです。