アジャイルな開発を始めたばかりの時、最初に乗り越えるもの

はじまり

アジャイルな開発を始めたばかりの時、最初に乗り越えるもの

@ryuzeeさんが仰る様に、今までのアジャイルではない開発のやり方からアジャイルな開発に変えると、今までの開発のやり方よりアジャイルな開発のやり方の方が作れる物の量が減ります。

例えば、『アジャイルな開発を始めたばかりの時、最初に乗り越えるもの』をいつものやり方として、左から右へ『ア・ジ・ャ・イ・ル…』と書いていくのと、昔の日本の様に右から左へ『アジャイル…』と書いていくのでは日頃書き慣れていない右から左へ書いていく方が書くのが遅くなると思います。

この理由は単純で、慣れ親しんだやり方と慣れ親しんでいないやり方では経験による作業の熟練度に差があるので、出来る量が減ってしまうのです。

何が違うのか?

では何故私の開発チームは増えたかと言うと、アジャイルなやり方にする際に以下に気をつけているからです。

  • 一気に変えない
  • チームみんなが納得
  • ピエロ

一気に変えない

「Scrum or XP を全部導入しないと意味がない!」とか「混乱期が長期化するからアンチ・パターンだ!」といった様に、一気に変えないことに対して、反対意見もあると思いますが、私はやり方を一気に変えない様にしています。

ウォーターフォール開発だと最後の最後でユーザにリリース(納品)するので、要求仕様と実装の乖離が最後の最後で一気に爆発(検出)し、乖離を修正するのが時間的に厳しい場合がありますが、アジャイルな開発だとスモールリリース(1週間〜4週間で納品)するので、要求仕様と実装の乖離が早期に小さく(リリースした1週間から4週間で開発しただけの量)爆発(検出)するので、乖離を修正するのが比較的容易なのが特徴です。

これと同じ様に開発のやり方も一気に変えて大きな爆発(混乱)を起こすのではなく、少しずつ変えるスモールリリース(適用)をして、小さな爆発を起こす様にしています。

混乱期が長期化するのではないか?と危惧されるかもしれませんが、今までの多くのチームでやった限りでは、混乱期が長期化することはありませんでした。

これは次にあげる『チームみんなが納得』にも関連しているかもしれませんが、少しずつ変えることは今まで自分たちが作れる物の量を制約している要素を取り外しているという風にチームの面々が感じていた為と、人間には適応力があるので、少しの変化なのでその変化にすぐに適応した為です。

チームみんなが納得

チームみんなに説明して、適用してみたけどうまくいかなかったという話をよく聞きます。これは皆さん自分の身に置き換えて考えてみれば当然のことです。

納得したことに対しては自発的に動きますが、説得されただけでは自発的に動かない場合があります。それは自分から他人を『説得』したとしても、相手が『納得』しているとは限らないからです。

『説得』とは相手に得となることを説くこと、つまり、相手が得する自分の考えを相手に理解させようとする働きかけです。
『納得』とは説かれた相手が自分に得となることを理解すること、つまり、自分が得するという相手の考えを理解することです。

『納得』したことに対しては自発的に、そしてモチベーションも高い状態で動いてくれます。高いモチベーションで開発することによって、やり方を変えても出来る量が減らない*1のです。

ピエロ

あなたの会社や部署がアジャイルな開発に全員賛同していない限り、チームの外からの妨害、所謂外乱は必ず発生します。これはアジャイルな開発をしているチームの状態*2が良い場合でさえも*3起こります。

その外乱にチームも巻き込むのではなく、全て自分が矢面に立って、自分のところで止める様にしています。周囲の人に色々言われても、チームに戻ったら、いつもと変わらぬ顔で普通に作業をします。

「チームも巻き込んで、外乱もチームで解決させる方が良い!」といった様に、外乱を持ち込まないことに対して、反対意見もあると思いますが、私は持ち込まない様にしています。理由はやり方を変えたこと以外の出来る量が減る要素を減らしたいということと、外乱によってチームのモチベーションが元に戻らない程落ちることを防ぐ為です。

チームの成熟度が低い状態ではなかなか外乱について解決しようというモチベーションも能力も足りません。人の口に戸は立てられないので、外乱についてもいつかはチームに知れ渡ります。チームに知れ渡った時には、チームは成熟度も高まっているので、チームでそれに対して解決してもらうのはそれからでも遅くはありません。

外乱以外にチームに対しても別のピエロになる様にしています。それはチームにある不安を解消する為にチームに対して見本を見せるということです。

例えば、朝会*4の時、「問題点はありませんか?*5」がそうです。
「問題点はありませんか?」もしくは「気になる点があるとすれば、それは何ですか?」と聞くだけだとなかなか問題を話してくれません。
それは伝えた問題点が調査の結果、問題点ではなかった場合(= 指摘が誤っていた)、注意されたり、怒られたりするのではないか?という不安があるからです。

そういう時、気になる点を自分で調べておいて、それが問題ないこと確認し、それを朝会の場で聞きます。
朝会後、チームの人が調べてくれて、大抵、次の朝会の前までに問題ないことを教えてくれます。
教えてくれた時にその人に「調査してくれて、ありがとうございます。チームで共有したいので次の朝会で同じことを言ってもらえますか?」とお願いをします。
そして、次の朝会で問題ない旨の連絡があるとすぐに「そこ気になってたんだよね。あぁ〜良かった良かった*6」と言うと、チームの不安が消えるので、次の朝会(もしくは次の人)から問題点や気になる点を朝会の場でどんどん教えてくれる様になります。

こうすることで、不安というチームの面々が無意識に抱えている制約要素を外し、出来る量が減らない様にするのです。

スゴイの?

これは誰でも出来ることです。
これは特別な能力がなくては出来ないものではありません。
でもほんの少しだけ努力は必要です。

もし、いいね!と思ったら、明日から皆さんの現場で試してみてください。

*1:減る量より増える量の方が多い

*2:進捗や品質やコスト等々

*3:つまり、悪い場合はより多く

*4:デイリー・スタンドアップ・ミーティング、デイリー・スクラム

*5:私は「気になる点があるとすれば、それは何ですか?」と聞く様にしています

*6:あんまりわざとらしくならない様に