アジャイル開発の議論。アナログツールとデジタルツール、エンタープライズアジャイルについて

米国ダラスで今年8月に行われたアジャイル開発のイベント「Agile2012」には、日本からも多数の参加者がありました。そのAgile2012に参加したアジャイル活動家の方々が集まった座談会「Agile Conference Retrospective」が開催されました。

座談会ではAgile2012を振り返りつつ、日本でのアジャイル開発の現状や今後についての議論が繰り広げられました。

この記事では、その議論のなかからツールについての議論、およびエンタープライズアジャイルについての議論のポイントを紹介しましょう。

アナログツールとデジタルツール、どっちがいい？

安井氏　私はアナログのツールが大好きで、ホワイトボードと付箋とマーカーがあればだいたい幸せです。こうしたアナログツールのいいところは、簡単に用意できてシンプルに始められること。ボードに顔写真を貼りつけたり、いろんな工夫ができて、お仕着せではなくチームごとに最適な運用ができます。

松元氏　いまは開発の仕事ではありませんが、仕事は全部アナログツールで管理していて、問題なくやっています。アナログツールの利点は、試す、変える、俯瞰するというところだと思っていて、例えば今、仕事をどんな風に管理したいのか自分で理解したり、管理の仕方に問題がないか、そういうのを周りの人と一緒に作っていくときにアナログツールはいいなあと思っています。

デジタルツールを全面否定するつもりはなくて、あれはあれで何らかの思想を反映して作られていると思うので、そういう思想と合えばいいけれど、合わないとどうなんだろう、と思います。

Muldoon氏　安井さんが指摘したように、最初にはじめるならアナログツールが最適だと思います。ただエンタープライズでスケールさせるにはデジタルツールの方が向いているし、拠点が分散しているチームでもデジタルツールの方がいいでしょう。ただ私はツールベンダの人間なので、私の言っていることは信用しない方がいいですけれど（笑）。

松元氏　ちょっと見にくいですが、これがホワイトボードや付箋を使って仕事を管理している例で、いちばん下のホワイトボードの例は、各列が2列でワンセットになっていて、いまやらなければいけない仕事、終わった仕事などを示しています。

仕事の改善という面では、「もっとこうした方がいい」「こんなドキュメントが出てきたので貼ってみよう」とか、だんだん自分たちに合ったやり方を話し合いながら管理の仕方を直していって、うまく行く方法を作れる。ちなみに60人くらいのプロジェクトですが、全部このホワイトボードで管理できました。

市谷氏　アナログツールは分かりやすいし始めやすいと思いますが、面倒くさい気がします。例えばベロシティを計算するのには、デジタルツールならぱっとできますが、アナログツールは自分で計算しなければなりません。

安井氏　最近見た事例では、ベロシティを計算するためにタスクの数字を数え上げて計算するのは大変だということで、1枚ずつのタスクを同じくらいの大きさにして、その枚数を数えようと、面倒くさくならないようにプロセスを変えていました。

松元氏　僕の会社でも全部アナログツールで管理をしたチームがあって、そこでもほとんど同じことをしていました。

Muldoon氏　アナログツールだとベロシティの計算が大変だというのはいい指摘ですね。デジタルツールは自動的に計算してくれますから。

市谷氏　ただデジタルツールの導入は金銭的なコストや習熟にかかる時間などがありますよね。

Muldoon氏　デジタルツールはたしかに習熟に時間がかかったりするけれど、そもそもアジャイル開発の習熟には時間がかかるものだから、初日からメリットがあるとは期待できません。アジャイル開発はジャーニー（長い道のり）でつねに学ばなければならないものですし、デジタルツールを学ぶこともそこには含まれます。

デジタルツールは使う人みんなが慣れれば、ベロシティを数えるといった手間が自動化されるので仕事に集中できるようになります。ただ、ホワイトボードは初めてアジャイル開発を経験したり学んでいくにはいいツールだと思いますよ。

エンタープライズアジャイル。トップダウンかボトムアップか？

市谷氏　Agile 2012でも「エンタープライズアジャイル」の話題は多くありました。アジャイル開発へのアプローチには、現場からボトムアップでアジャイルな組織にするという切り口と、トップダウンの号令でやる切り口の両方があるのかなと。

伊藤氏　「アジャイル開発手法」とよく言われますが、この言葉ゆえにアジャイル開発は「開発」だけの話だと思われていないかと。アジャイル開発は、テクニカルプラクティスだけでなくマインドセットを含んだもので、開発だけではありません。開発手法だと思われるがゆえに、本当に改善しなければいけないところに関係ないと思われていないでしょうか。

安井氏　アジャイル開発って、大体チームから始めると思うんですね。で、チームでやってうまくいったら広げてみるか、ということで。でもそうやって広げていくと、どこかで何らかの壁に当たるんですね。その壁に当たる理由って、アジャイル開発が開発手法（だけのもの）だと思っているからだと思います。

でもアジャイル開発がうまくいくには、顧客から要求がでてこなければいけないし、フィードバックをもらって反映するには予算が柔軟でなければいけないのだけれど、でも開発手法のことだと思われているからそこで止まってしまう。

上司が覚悟していればそうした壁を越えられるこえられるし、それが部長くらいだと社長や事業部が違う人とも話ができてうまくいっているように見える。

客A　本質的にはそう思うが、それをすりあわせるには開発者がビジネスサイドに説明するなりしないと、その壁は越えられないかなと思っている。

客B　上司と意識が合っているかどうか。下々のエンジニアが改善活動を頑張っていても、上司から見ると何遊んでるんだと思われてしまうことはよくあると思います。上司と意識がずれた状態では、下の人たちがモチベーションを持ち続けることはできませんよね。上司の協力は必要で、結局それがどこに行き着くかというと評価制度かなと。

Muldoon氏　2006年のオーストラリアの会社の話をしましょう。その会社は最初小さなオフィスでスクラムなどをボトムアップで、「Do Agile」として始めました。朝会、スタンドアップミーティング、スプリントなどを実践し、そこから「Be Agile」なるまで2年かかりました。

ある2万8000人の従業員が働く銀行ではアジャイル開発を導入し、数年かかって経理、人事、マーケティングなどにまで「Be Agile」が広がっています。

客C　「Do Agile」と「Be Agile」とは？

Muldoon氏　「Be Agile」はマインドセットのことで、今していることが何のためなのか理解し、もっとうまくいく方法を考えて改善し続けるのが「Be Agile」。「Do Agile」は、アジャイル開発のプラクティスを実践すること。その銀行ではCEOの理解があって、アジャイル開発がうまくいっていると評価されて全社的に広がっていきました。

藤原氏　私は楽天で働いていて、トップダウンで理解もありますが、ボトムアップでアジャイル開発をやっています。でもトップの理解はやはり怖いところがあって、アジャイル開発だから、ということをどう見られているか、とか、さっきのニックさんの話でいえば定着するのに2年かかるとすれば、それだけ上司に待ってもらえるのかどうかとか。

周囲を、上司を変えることはできるか？

市谷氏　マインドセットを変えるとして、どうやってそれを始めればいいんですかね？

安井氏　人の考え方を変えることはできなくて、自分から変える。あとはそれが広がるといいな、と、思うわけですが、影響というのはいつの間にか伝染するものだと思います。

伊藤氏　人を変えるのではなく、変わりたいと思わせろ、という言い方をよくしますが、以前チーム間で殴り合いをしそうなくらいのところがあって、そこでまず、お互いの言い分をソーシャルメディアで見えるようにしましょうということをしました。意見を言っていい、という雰囲気を作って、そこから少しずつ意見が交わされるようになって、5日目にはお互いの言い分が理解できるようになりました。

ほとんどのケンカの原因はコミュニケーションミスだったりして、ツールなどをうまく使って考えを共有できるようにすれば変わっていくのではないか、というのが私の体験談です。

市谷氏　（会場に向かって）これで会社に戻って、アジャイル開発への一歩が踏み出せそうですか？

客D　上司は成果を目に見える形で求めるので、アジャイル開発をやるのはいいけれど、何がいいのか数値化して見せなければなりません。それをどう見せればいいのか、知恵があれば教えてほしいです。

松元氏　僕のいる会社だと、サービスの開発をするか、2年ぐらい作ったやつをどかっとリリースする、ということをしています。サービスの方はテストしやすいので、その結果をだしています。2年かかるプロジェクトになると、2年くらいで20億円くらいの規模でものすごいリスクをとっているわけです。そのとき上司はなにが気になるかというと、プロジェクトがうまくいっているかどうか。

そうすると、バーンダウンチャートなどをみせる。全部でこれだけやらなくちゃいけなくて、ここまでできていて、残り時間はこれしかありませんと。そういう話ができれば、ちゃんと対応してくれます。

上司は成果を求めるというより、なんとかうまくやってほしい、と思っているのではないかと思います。

市谷氏　成果を見せるというより、現状をきちんと見せるツールとして使うと。

伊藤氏　数字で報告するのではなくて、ものを見せるのがいいのではないかと思います。具体的にはスクラムならスプリントレビューでステークホルダーにデモをみせる。それは立派な指標や成果になるのではないでしょうか。

市谷氏　楽天はアジャイル開発をやっていると思いますが、そのへんどうやっているのでしょう？

藤原　生産性をあげるべき、という話になると、じゃあいまの生産性を出してくれれば僕も対応します、というふうに切って捨てています。

それよりベロシティ、タスクをこなす数がこういう風に速くなります、この人数だとこれがマックスです、といった説明をします。でもいちばんいいのは、楽しそうとか雰囲気がいいとかリリース回数が多い、といったことが評価されることだと思うので、おすすめはリリース回数をKPIにすることです。

そこで問題がおおければリリーストラブルが多い、ということだと思うので、じゃあトラブル回数を計測しましょう、といったことにしますね。