Kentaro Kuribayashi's blog

Software Engineering, Management, Books, and Daily Journal.

組織パターンを実践する

先日(10/30)「ジム・コプリエン (James O. Coplien) : Advanced Scrum - 組織パターンでScrumを微調整する "Scrum Fine-Tuning using Organizational Patterns」という研修 + ワークショップに参加しました。先日刊行された『組織パターン (Object Oriented SELECTION)』に基づき、著者のコープ氏自らによる解説を聞ける貴重な機会でした。

研修について

コープさんについては、『組織パターン (Object Oriented SELECTION)』その他の本などの活動により、非常な敬意を抱いているのですが、今回、これまた尊敬する角谷さんに機会を与えていただき参加することができて、とてもよかったです。コープ氏、角谷さんをはじめとするコーチ陣のみなさま、ありがとうございました。

研修の内容はというと、コープ氏の話と、ともすれば哲学的・抽象的な内容になりがちなそれを補足する、『組織パターン』翻訳の和智さんによる説明を導きに、ところどころワークをいれて知識の定着を図るというもので、本を読んでなんとなく理解していたことが、実際の適用によって使いものになりそうな感じが得られて、とてもよかったです。

組織パターンをどう伝えるか

ただ、一点問題があるとすれば、という感じで角谷さんに相談したりもしたのですが、それは、パターンというものがひとに説明しづらいものなのではないかということ。僕はもともとそういう分野に興味があるので本を読んだだけでも「ふむふむ」という感じだけど、じゃあいきなり明日から仕事場で「パターンが云々」といっても通じないでしょう。かといって、みんなで『組織パターン』を読むのも現実的ではない。

そこでどうするか。今回の研修でやったように、自分たちが日頃やっている仕事の中から、みんなでパターンを見出していく。そういう実践によって、自ずとパターンというものを体感してもらうというのがよいのではないかと思いました。以下、その実践の記録。

組織パターンの実践

ワークショップでは、その場にいるひとたちがばらばらの出自をもっている関係上、それぞれのひとびとが困っていることをもちよって、組織パターンを適用してみるということをしました。それはそれでよいのですが、職場内で行う場合は、実際の仕事のやりかた・プロジェクトに対して適用することができます。

また、パターンとは、誰か第三者が御託宣のようにのべ伝えるものではなく、自分たちが見出していくものです。それは、スプリントレトロスペクティブ(ふりかえり)においてKPTを見出していく作業に似ています。

最近、自社のあるチームで、僕が技術面でのスクラムマスターのような感じでかかわっていたプロジェクトが、かなりいい感じで成功裏に終わったということがあったので、そのプロジェクトで行ったよいプラクティスを、パターンとして抽出し、次回以降、全員が参照・使用できるようなものにするために、ふりかえりの特別編を行って、パターンの抽出を実践してみました。

パターン抽出のやりかた

あんまり時間をとってもいられないので、1時間のタイムボックスを切りました。その上で、以下のような感じですすめます。

00〜05 プロジェクトの紹介

  • プロジェクトについてPOから簡単に紹介してもらう
  • いつものKPTとはちょっと違うふりかえりをします
  • 今回のプロジェクトから一般的に利用可能ないい面を見出し、次回以降、チームの知識として使えるようにする

05〜20 タイムラインに「困ったこと」をマッピング

  • プロジェクト期間中に困ったことを、時系列にマッピング
  • それに対する解決・やったことはまだ書かない

20〜45は「困ったこと」に「やったこと」をマッピング

  • 「困ったこと」にたいして、どう解決したかをふせんに書いてはる
  • ふせんは、現在形で書く
    • 「〜をやった」ではなく「〜をやる」
    • あとでパターン化するため

45〜50 「やったこと」を模造紙に張替え、並べ替え

  • まずは適当にはる
  • つながりをみいだす
  • 順番をつけてみる
  • 線をひく

50〜55 パターンの説明

  • パターンについて説明(これをプロジェクトパターンと呼ぶ)
  • UIパタンや、ソフトウェアのデザインパタンと同様
  • プロジェクトのあるある集
  • これを充実させることで、強いチームに

55〜60 今回やったことの説明。名前付けをすることへの導入

  • 「問題」や状況についてドキュメンテーションするとよい
  • 名前重要なので、名前を考える
  • みんなで議論して共有する

こうして作成された

  • 時系列の「困ったこと」リスト
  • その困ったことにたいして「やったこと」のリスト

を抽出した模様が以下の写真。

今回のプロジェクトに限らず、問題になることはどのプロジェクトでもわりと共通。そうであれば、問題に対して、どういう状況があって、どういうふうにしたらいい感じになったかというのを書き出していく、そのことでより一般的なパターンが抽出される。困ったことをあげていくと、「あー、あるある」というようなことが多い。一方で、今回のプロジェクトは実際にそれらの困り事を解決することでいい感じにフィニッシュできたので、単に「あるある」で済ませず、実践的な解決のパターンも見いだせた。それが以下。

実際やってみると1時間ではとても足りなくて、そのあとに張り出したパターンについて名前をつけてみたり、追加したり、みんなでわいわいやっていた。むしろ、あとの時間の方が盛り上がったw

実践してみて

今回のプロジェクトにこのチームのすべてが集約されているわけではないのだから、これを機会にチーム内の他のプロジェクトに対しても同様のふりかえりを行うことで、より多くのパターンを見出していけるはず。それらについて継続的に議論・共有することで、さらに強いチームを作れると思う。

『組織パターン』というとちょっと難しいけれども、スクラムにおけるふりかえりの一変種のような感じでとりいれていくと、自然に始められるだろう。

組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)