AgileJapan2009岡島さんセッションのレポート

Agile

AgileJapan2009のクロージングセッションとして行われた、岡島さんのセッションのレポートです。

岡島さんが最近まとめられた、「ソフトウェア開発を成功させるチームビルディング 5人のチームを上手に導く現場リーダーの技術」をタイトルにしたセッションですが、本で詳しく紹介しているチーム・ビルディングのプラクティスなどは、あえて深く言及せず、AgileJapanのテーマである「人」にフォーカスした話でした。朝からのお話とのリンクも強く、このセッション単独でも、現在のソフトウェア開発現場の問題に対する強いメッセージを含んでいて、とてもストーリー性のある展開。
非常に盛りだくさんだったAgileJapanですが、岡島さんのお話は、一日を締めくくるクロージングセッションとして、自分の頭の整理といういみでも、すごくはまりました。

さらに、個人的には、日経コンピュータ・フォーラムでの岡島さんのお話、「ソフトウェア開発を成功させるチームビルディング 5人のチームを上手に導く現場リーダーの技術」のレビュー、そして、このAgileJapanのセッションと、その進化の過程にご一緒させてもらっているという、恵まれたお仕事をさせてもらっていただけに、チームビルディングについての考えを、さらに深めるきっかけになりました。


以下、お話の内容のメモです。

「かます」のお話

かますは、非常に獰猛な魚で有名であるが、面白い実験がある。
「かます」を入れた水槽の中に、透明の壁を設置する。「透明の壁」で隔てられた水槽の、かますのいない方に、えさのシラスを入れる。
すると、カマスは何度も透明の壁にぶつかっていく。中には、瀕死の怪我をするかますもいる。
最初は、何度も透明の壁にアタックするが、ついにはあきらめる。
そのような状態になれば、「透明の壁」を取り払っても、かますはシラスを食べようとしない。餓死するカマスが出ることもあるらしい。
　
ソフトウェア開発においても、過去の痛い経験やうまくいかなかった経験から、各メンバーが勝手に、「透明の壁」を作っていないだろうか。

岡島さんは、ソフトウェア開発のあらゆる場面において、この「透明の壁」について考察していく。

透明の壁

  • マネージャの、Agile開発チームに対する誤解
    • 組織を考えない。
    • 経営的視点が無い
    • コードを書くことがすべて
  • マネージャに対する、開発メンバーの誤解
    • ルールでがんじがらめ
    • 人を軽視
  • マネージャの成功モデル（ドラッカー）を読み解くと、
    • 組織的成功と技術的成功は、本質的にゴールが一緒。分離していることが失敗の要因である。
    • さらに、労働の力学（生き生きと仕事をすること）も、バランスしていなければ、うまくまわらない。
    • ゴールの共有とバランスが重要。

マネージャ，開発チームは、成功モデルの本質が同じであることを知り、歩み寄ることが必要。

マネージャ，開発メンバーの疑問
  • 【Q】お互い、成功モデルを持っているとは思えない。
      • →ちゃんと成功について話したことがある？
何故、歩み寄れないのか
    • 実は、開発者はマネージャに依存している。
    • 実は、マネージャは開発者に権限を渡したくない。
      • →「透明の壁」を双方に築いてしまっている。

開発者とマネージャのWin-Win

  • 開発チームは主体性を発揮することで、マネージャに価値を提供せよ。
  • マネージャは、開発チームに権限と責任を委譲せよ。
永和システムの例

自分たち（開発チーム）は、アジャイルを売りとした開発をしたい。まずは、合宿でビジネス計画を作る。
マネージャ（経営者）側は、合宿の予算を出すことに合意。ビジネスの計画を出させて、それの妥当性と遂行を確認する。

  • →これは、実際に行われ、３〜４年のビジネス計画を立てて遂行され、一定の成果を得られている。
主体性の発揮

ケント・ベックの"Socialchange starts with YOU."をはじめ、主体性の発揮が成功の鍵であることは、あらゆる文献から読み取れる。

マネージャ，開発メンバーの疑問
  • 【Q】そんなに主体性のある人、うちにはいません！
      • →だから育てるんです！
  • 【Q】教育コストなんて出ないです。
      • →自分たちで、チームの仕事を通じて育てるんです。チームと人は、一緒に育つ。

チームの本質

  • 「チーム」の定義

メンバーが、各自のスキルを発揮して、同じ目的のために共同活動を行っている。ただの人の集まりは、チームといえない。
（メアリー・ポッペンディーク）

  • チームは最終状態ではなく、プロセスである。魔法の瞬間頼りのブレイクスルーは期待するな。
  • じわじわと、改善の過程を共有しながら進む「ウーズスルー」であるべき。

チームビルディングの実際

  • チームビルディングで、様々なプラクティスに取り組む上で心がけておくべきこと
    • 主体的にやる
    • 現場でどう取り組むかを考える
プラクティス
  • 朝会
    • メンバーの主体性を引き出すための仕組みを用意する。
      • 聞き役に徹する
      • 司会の持ち回り
  • ふりかえり
    • 良い兆候を捕まえる。
    • たとえば、「ダラダラしてきた仕事がつまらない」という意見。
    • マネージャにとっては、ネガティブな意見に見えそうだが、実は、メンバーが遠慮なくシグナルを出してくれるようになるための、すごく良い兆候である。（岡島さんは、こういう遠慮ない意見がでたら、「キター！」と思うそうです。）
  • タスクかんばん
    • サッカーピッチ型など、カスタマイズしてみる。
    • そのまま使っても続かない。自分たちで考えて使うことが大切。
役割に対する期待感を見える化する
  • キャラクタマップ
  • パーソナルナラティブ
    • 人事的評価とはリンクさせてはいけない。評価に結びつくと思わせてはいけない。
    • その通りにしかやらない人には使わない。

ポイント

  • 開発チームと、マネージャの成功モデルの共有
      • →話し合ってますか？
  • 「自分たちでやる」という姿勢がリーダーシップを生む
  • チームビルディングを通じて、主体性は育まれる

再び、「カマス」のお話

冒頭ではなした、「かます」のお話。
透明の壁を取っ払っても餌をとる気の無くなった、「弱ったカマス」を復活させる方法がある。
それは、新しいカマスを入れること。
新しいカマスは、壁の存在なんてしらないので、遠慮なく餌を食べる。
すると、弱ったカマスも、次第に餌を食べ始める。

弱ったチームにも、「新しいカマス」は効果的。
それは、まったく新しい人をチームに入れるのではなくて、自分のチームの新人や、先進的な人などを、育てることで登場するのである。

あたらしいカマスはどこにいるのか？

　「きっとほら、あなたのチームに！」