Agile Japan 2015

Agile Japan 2015 C-1b

(写真提供:筆者)

スクラムを初めて誰もが夢を見る「楽しい開発、楽しい会社」。椎葉さんと絹川さんのお話は、そんな夢を持つ人の希望になるお話でした。

カオスな現場を作る失敗への恐怖

椎葉さんが楽天大阪支社へ中途入社した際の開発現場は、ビジネスの成長スピードに追いつけない、カオスな現場だったそうです。椎葉さんが、カオスな現場を生み出す原因を追求し、最終的に「失敗しないため」ということを見出します。ビジネスとしては当然は失敗したくない。しかしながら、そうしようとするために結果的に現場には、エンジニアであれば、このような現場での開発が楽しいと感じづらいのは想像しやすいものでした。
エンジニアとしての経験が少ないマネージャーや事業側が一旦力を持ち始めてしまうと、「管理しやすくするために、そして、失敗しないために」ということから、このような厳しい体制に陥ってしまいやすいのではないかと想像しました。

そして、椎葉さんは、自分自身がエンジニアとして自分が働きたいチームづくりのために、スクラムを導入します。

  • タイムボックスを設けて、失敗のリスクを最小にする
  • 期待値をあえて高く設定することで、チームメンバーの成長を促す
  • 責任範囲を明確に定義せず、メンバーが持っている課題意識を共有し、オーナーシップを育てる

カオスな現場は、失敗を許容し改善していくことが前提のスクラムとくらべて、真逆の状態にあるように見えます。そこから、働きたいと思える現場になり、実際にエンジニアとして業務を行えるまでに、数年かかったそうです。

課の課題を考えるチーム

椎葉さんは、スクラムをチームに導入し、エンジニアにとって楽しい開発現場を作るお話。そして、絹川さんのお話は、それを横に展開するだけでなく、組織としての課題を解決するために組織全体でスクラムを組むというお話でした。

一番の重要な点は、マネージャーは基本的に一人で課題を抱えやすいところ。基本的に、現場はチームで活動することが前提になっていることに対し、それを管理するマネージャーは基本一人であるため、その構造がマネージャーに対する負荷を産んでいるようです。
そういった状況で、課長である絹川さんは、その1つしたのマネージャー達と一緒に課の課題を考えるチームを作ります。それぞれのマネージャーの声が聞こえるようになると、メンバーの状況や育成方針など、それまで一人で悩んでいたことが無くなっていきます。そして、その後、その成功体験を課全体に広げています。
参加者の規模が数十名と大きいため、それまでのチームと同じようなペースではなく、2ヶ月という単位でサイクルを回しており、その中で、

  • なんでもいいので課に関する課題を出し
  • それらを分類して
  • 担当にアサインする
  • 次の回で、経過報告。出来ないときは出来なかった理由を正直に共有する

ということを行っているそうです。

このように大規模なスクラムは、一見、基本に反するように見えます。ですが、組織としての変化スピードを考え、スプリント期間を長くしたことで、緩やかに大きなチームが形成していったのだと思いました。

Agile Japan 2015 C-1b

おわりに

今回のお話だけですと、大成功しているかのように見えます。ですが、スクラムをチームへ導入し、目標とした環境になるまで数年かかり、そして、組織へ導入する過程で恐らく多くの課題に直面したのだと思います。
それでも「楽しい開発」は得たいし、組織としての課題は解決したい。その成功を生み出したのは、何よりもお二人のように継続して情熱を持っていたことにあるのかもしれません。

チームの視点はわかるものの、マネージャーの視点として語られる絹川さんの話は、大規模なチームでのスクラムの実践とも見えますし、その成功例でもあるのではないでしょうか。

今、私も、チームが上手く回るようになってから、組織がどうなったらもっとよくなるんだろうか、ということを考えるようになりました。その際に、これまで見たことの無い課題が目の前にあることに気づくようになり、嫌気が指すことがあります。
このセッションで語られた事実は、そんな自分にとって「あぁいう風になりたい」と思える成功ケースとして心に残りました。

スクラムにとっての成功というのは、何かを達成しての成功ではないように思います。自分たち自身が、そして自分たちが変えたい何か(プロダクトや組織)が改善されているのを自分たちで実感できている時が、スクラムとして成功なんではないでしょうか。もし、そうであれば、このお二人の活動は素晴らしい成功例というように見えます。


もっと知りたい!Agile Japan

Agile Japanとは

レポートコーナー