アジャイルムーブメントの影響もあり、アジャイル開発を最近はじめた。またははじめようとしている方も多いと思います。私は2003年に社会人になり、第一次アジャイルブーム？か何かでXPを知り、少しだけ学んだ世代なのですが、去年の1月からアジャイル開発を勉強・実践するようになりました。
そんな中、アジャイルコーチを仕事としている方を間近で見たり、新人研修にアジャイル開発の手法を取り入れたり、実際に自分のチームで実践したりする経験を得ることができました。今年は、まったく自分に関係ないチームのプロジェクトリーダー/マネージャをしながら、アジャイルコーチのような役割を果たしているところなのですが、そこでのコーチング時にふと疑問が浮かびました。
「自分の成果はなんなのだろう？」
その疑問について、Twitterでいろいろと教えてくださった方からのアドバイスや、関連する情報から、謎を解く鍵を探してみました。
短期的な成果
先週、「アジャイルコーチの短期的な成果例を知りたい 長期はおいておいて」とつぶやいたところ、尊敬するアジャイルコーチたちからいろいろとアドバイスをいただきました。以下、Togetterにまとめてみました。
Togetter：アジャイルコーチによるアジャイル開発の成果と効果測定とは？
タイムライン上でのやりとりになるため、時系列ではなく会話の内容別に並べています。この一連のやりとりの中で、話題になった内容を整理してみます。
まず、疑問は「アジャイルコーチの成果やそれを測定するポイントを知りたい」になります。成果を知るためには、KPIのような測定値が必要になってくるとおもいます。測定値は、定性的なものだけですと成果に深みが出ないため、定量的/定性的のどちらも測定したいと思っています。
そう思ったきっかけは、私がコーチ（立場的にはマネージャで野良コーチしている）として入っているチームで、私はアジャイル開発を推進してきました。そして、そのプロジェクトもひとまずの終りが近づき、開発についても、残すはメンバーのアクションが中心になってきました。
プロジェクトが終わると抜けてしまう自分には、その今後加速していくであろう変化や改善を、現場で確認することができません。そう考えたときに、自分の部署にもどって報告するときに、私は何を報告すればいいのだろうか？とふと思ったのです。
Togetterにまとめていて、いろいろなケースがあることに気がつきました。コーチの立場としては、
- コーチするチームが、自社の組織であり、コーチと同じ組織の場合
- コーチするチームが、自社の組織であり、コーチとは別の組織の場合（これが私）
- コーチするチームが、他社であり仕事として受けている場合
などが考えられ、コーチの背景としては、
- 自社がアジャイル開発を導入したいと考えていて、その一環としてのコーチ
- アジャイル開発を試してみたい野良コーチ（これが私））
が考えられます。私の場合は「プロジェクトの成功」が成果として期待され、内訳としては「無事にリリースされること」が中心。あわよくば「リリースされたモノが新しい価値を生み出すこと」になります。
Togetterにもどります。@ryuzeeさんから期待する効果は何か？という質問をいただきましたが、確かに、導入前に効果について導入される側と成果や評価軸について話すのは大切だと思いました。@haradakiroさんのお話ですと
コンサルやっていて最初の仕事は、期待軸とその評価方法についての合意形成なことが多いですね。解決策をコンサルが提示できるわけではないので。たたき台は出しますが。
@essence_sさんの場合はさらに
導入の目的と評価軸とゴールを設定して、導入自体をプロジェクトとして1枚もののプロジェクト定義をおこしてます。導入自体の要求分析をやるわけです
と「導入自体をプロジェクトにする」そうです。これは素敵なアイデアのように感じます。ここで出てくる合意形成・評価軸・ゴールをどう組み立てていくのかを聞いてみたいです。きっと、この期待軸は
- 開発チームへの期待
- ビジネスサイドへの期待
- リリースされるソフトウェアに対する期待
のように、それぞれの場所や成果物に対しての期待があるのではないかとおもいます。ここで開発だけに焦点を絞ってしまうと「開発に閉じたアジャイル」になってしまい、価値にたどりつけない可能性がありますね。
@kkdさんのように定性的な成果として「事前・事後アンケートを使う」こともできますし、@kawagutiさんのように「短期で定量は難しいのでバックログを共有」することや、安定したベロシティを見せることで、開発状況が順調度が見える化されます。これは評価に使えそうです。ただ、「スクラムチェックリストへの適用度」ですと、「アジャイルをしているかどうか」のチェックに見えるため、ビジネスサイドの理解が難しいように感じます。
@nawotoさんは最後にこう話しました。
価値観は伝えるものじゃないと思ってます。また、成果が何を指しているか分からなくなってるのですが、僕は困っている事ややりたい事を手伝うだけなので、切り離して考えています。
これについては、「成果が何を指しているか」ではなく、コーチとして「何を成果にするのか？」を聞きたいです。ここがはっきり見えると、アジャイル開発の導入もスムーズになりそうです。コーチを雇う側としては、「お手伝いをします」ではなく「◯◯を成果として頑張ります」とかを聞きたいはず。もちろん、最終的に現場が頑張る部分が大きいのでしょうが、報酬を受け取るのであれば、なにかしらの「約束」は必要だと思うのです。
また、アジャイルマニフェストには優先すべきとする価値が書かれています。開発について考えると、結局このマニフェストに戻ってくる事が多いのですが、その価値が生み出す成果が短期的には非常に見えにくいのが「アジャイル」が「うさんくさく」なる理由なのではないかと思います。価値だけじゃ響かない。
去年、Agile 2010 Conferenceに参加したときに気がついたのですが、セッションのスピーカーは、アジャイルコーチやコンサルタントをしている人が多く、彼らはコーチ先の業績UPなどを成果として、自分のキャリアを築いていました。中には「株価」を成果として話す方もいました。
一方、日本を見てみると、コーチを職業としている（お金を稼いでいる）方は、（自分が知らないだけかもしれませんが）まだそれほど多くないのではないでしょうか？そもそも、ソフトウェア開発会社やWebサービス会社がスクラムマスターを招聘して業務改善したりする文化もあまりないのかなぁと思います。
私はコーチ業もビジネスだと思っています。いい仕事をした人がよい評価をされてほしいですし、もし、現場でチーム一丸で改善に取り組むチームが成果の定義や評価で困らないようにしたいし、もっと増えてほしい。やりやすい環境を作ればいろいろ良くなるのかなぁなんて。
なんかまだもやもやしており、聞きたいことがいっぱいなので、また、いろいろ考えてみようと思います。これがみえてくるとアジャイル開発の導入もわかりやすくなる気がします。
最近、「How do you measure team performance?」というディスカッションがLinkedinで活発に議論されているので、この記事の続きで調べてみようと思います。また、アジャイルコンサルでご活躍される@sandayuuさんのアジャイルコンサル資料もヒントになりそうなので、もう一度読んでみます。何かのヒントになるかもしれません。
旅と子育てとアジャイルコーチのブログ「世界」 