神々のアジャイルと下々のアジャイル #agile2012ja

Agile Conference Retrospectiveというイベントでお話させていただく機会がありました。今年ダラスで開催されたAgile 2012 Conferenceを、参加した仲間とふりかえりながら、見てきたことや感じたことを参加者と一緒に考えていくイベントです。

Agile2012が日本の開発現場にもたらすものとは何か

XP祭りでは例年参加報告が行われていのですが、今回のイベントは進行がふわふわしないように、参加者を前に集めてテーマについて語り合う「恋のから騒ぎ」形式になりました。

イベント後、@papandaとも少し話したんですが、パネル形式でも伝えるのが難しい部分がありました。正直、参加者の皆さんの期待に答えられたかは疑問ですが、少しでも楽しんでいただけたなら幸いです。時間の関係でいくつかお話できないネタがあったのですが、それ以外のところで思ったことをまとめておきます。

また、このエントリーのネタについては一緒に参加した@uedayoも書いてます。上田さんとはコンテキストが似ているので考え方も似てくるんですよね。

2012-10-19 「神々と下々とアジャイル」 Agile Conference Retrospective

アナログツール VS デジタルツール

実際にツールを社内展開してわかったのは、展開と教育はセットでやらないと効果的ではないことです。ツール提供会社の人からお話を聞く機会がたまにあるんですが、「ツールを売った後」のことをあまり考えていないなぁという印象です。

これがきっと「ツールを入れればうまくいく」という誤解を招くのではないかと思います。実際に使いこなせなくてツール自体がネックになる場合もあるわけで、ツール導入を推進される方には、その後のサポートもしっかり考えて欲しい。そういう人が社内に入ればいいんですが。

また、松元さんがおっしゃっていた「ツールには何らかの思想があるからそれを考えるといい」というコメントはたしかにそのとおりだと思います。日本の文化なのかわかりませんが、自分たちのプロセスをツールに合わせるのが苦手と感じることが多々あります。

具体的に言うと「いや、うちは特別だから」という意見。わざわざ考慮されていることを学ばずに、独自カスタマイズして無理に自分のプロセスに合わせようとしたり。そのプロセス自体を変える発想がないのかな？

ユーザ側にいるエンジニアと、ユーザ側にいないエンジニア

Publickeyの新野さんがコメントされていたんですが、

海外だとユーザ企業にエンジニアが多く所属し、日本だとSIと呼ばれる企業に属するエンジニアが多い。この統計から考えると、階層社会とも言える現在の業界が変わりにくい理由の一つなのではないか？

というような内容だったと思います（違っていたらごめんなさい）。

たしかに、多数派が「アジャイルになりにくい体質」だと、全体としてそういう傾向になるのは当然です。これを聞いた思ったんですが、この「変わりにくい状態」の中で、多数派の考えがスタンダードと定着してしまい、「これが正しいんだ」と若者までが思ってしまうのも、変わりにくい理由なのかもしれません。

これは実際に経験していることなのですが、新入社員ですら多数派のやり方、具体的な例を挙げると「ウォーターフォール」のような開発を自然にします。フェーズでわけ、それぞれに時間をかける。利用する手段が偏りすぎているように思えます。

そして、この偏りにより、課題改善を考えないエンジニアが多いんじゃないかと危惧しています。「なぜそれをやっているの？」に答えられないけど、みんなやっているからそれをやる。これも日本の文化といえばそこまでですが、「現状のやり方をきちんとしていればうまくいく」といった考え方はリスクがありすぎる。イベント後に@yattomさんともそういうお話をしました。

そういうふう考えを持った人に、アジャイル開発の良さを伝えるのはとても難しく、マインドセットを変化させるのに非常に時間がかかるものです。こういう人材が世の中に多くいるのであれば、Nickがいうように日本はまだイノベーターにしかリーチしていない状態かもしれない。すなわち、海外が10年かけてたどりついた「キャズムを超えたアジャイル」にたどり着くまで、これから10年かかるかもしれません。

Enterprise Agile

「組織文化」「組織改革」といったキーワードへの興味は大きいと思っています。今回のイベントの資料とりまとめを担当していたのですが、Enterprise Agileに時間をかけたのは「アジャイルを企業ではじめるのが難しい」という意見を周りでも多く聞くため、少しでも現場で悩んでいる方のヒントになればと思ったからです。

お名前を伺うのを失念していたのですが、「どうやって効果を数値化するかで悩んでいる」と質問してくださった方がいらっしゃいました。私もいくつか回答させていただいたのですが、これは「これです！」といったものが私自身も見つかっていません。だから、

リリースするまでの時間を計測する（リードタイムの短縮や安定化）
リリースする回数を指標にする（フィードバックを反映する回数の見える化）
DONEできたリリースできるストーリーの予想と実績を元にした成功率（コミット力の見える化）
タスクの状態を週単位で積み上げたチャート（TODO、Doing、DONEそれぞれの付箋の数を数えて傾向を考える）

といった取り組みを、やったりやめたりしながら作り上げている状態です。上田さんのコメントにあった「プロジェクトごとに考える。全体で考えるとふわっとした指標になってしまうから」に近いです。これらはAgile Tour Osakaで普段使っている指標をご紹介する予定なので、興味のある方はぜひご参加ください。

もう一つの回答は「じゃぁ、今の生産性出してください」と言い返す方法。「虎を捕まえて欲しければ屏風から虎を出せ」という一休さんメソッドですが、これをやると大抵の場合、敵が増えるのでTPOを選ぶ必要があります。

私の場合、敵を作りたくて言っているわけではなく「生産性の見える化なんて無理」というふうに思っているからです。「出せ」っていう言葉が考えるのを放棄しているみたいであまり好きではないです。一緒に考えましょうよ。