現場の声を開放しよう！未来のパターンとプロジェクトランゲージ
DevLOVE Advent Calendarの18日目の記事です。
非常にレベルの高い記事の後ということもあり、緊張している。 このところ、勉強会も研究会もほとんどご無沙汰である。 参加したい勉強会やイベントが多いだけに身を切られる思いだ。
実は、DevLOVE Advent Calendarの記事として、事前に現場の定義と書籍の選び方についてブログ記事を書いていたのだが、どうも緊張してしまって、この記事を書いてしまった。時間が許せば、そちらの記事もお楽しみください。
私自身、ソフトウェアやIT、ビジネスの現場の中で探求しながら、さまよい歩いているとき、中埜さんや羽生田さんが取り組んでいるパターンの先進性と器の大きさに触れ、自分ながら研究や実践を続けてきた。たとえば、参加のまちづくり演習の開催や、パターンの国際会議AsianPLoP 2011でもプログラム委員長として関わる機会を得た。去年・今年と大量のパターンを記述する機会に恵まれた。また今後も、パターンに関連したイベントやプロジェクトも計画しているので、楽しみにして欲しい。
今回は、現場の声を記述し、未来をデザインするための技術として、パターンとプロジェクトランゲージについて簡単に解説する。
現場ごとの文脈や問題を認識しよう
IPA アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイドがクリエイティブコモンズライセンスで公開されており誰でも使える。
このレポートを読むと、現場ごとに全く異なったプラクティスを用いている。たとえば、インシデント（トラブル）が発生したときの重大さをラーメンの具の量で表現する素敵なプラクティスが紹介されている[p.116 楽しい工夫]。東京では「ぜんぶのせ」とか「ましまし」とか具沢山のラーメンがある。しかしながら、ラーメンの本場、博多で紹介したところ、こんなコメントが…
ラーメンの具が増える＝バグが積まれるというイメージが沸かない…。
そもそもラーメンにそんなに具はのってない！ #博多だもん
— くろねこまいける (@kuronekomichael) November 15, 2013そうか！博多では、たくさんの具がイメージされないので、このラーメンのプラクティスは成立しないとは！うーん、おもしろすぎ♪
そのほかでも、ふりかえりプラクティスを読むと「その内容や効果は事例によってバラつきがあり、チームにとって不可欠になっている場合もあれば、あまり定着しないという場合もあった。」と紹介されている。そして、手法や実施タイミングまで、現場ごとに違っているのが、良く見て取れる。それ以外のプラクティスも、現場ごとに全く異なっている。
つまり、代表的なパターンが共有されているが、現場ごとの文脈や問題がある、ということだ。
プロジェクトランゲージ
パターンランゲージは、エキスパートや先駆者による何度も成功している体験をまとめている。そのため、代表的なパタンが語られる傾向にあり、自らの現場に適合しないことが多い。
具体的なプロジェクトの実現という特別な目的を持つパタンランゲージであるプロジェクトランゲージがある。プロジェクトランゲージは、まさしく自分たちの現場での声をまとめ、未来のパターンを作りながら、自分たちの物語やシナリオを紡ぎ、デザインする。プロジェクトランゲージの目的は、エキスパートの成功体験をシェアすることではなく、自分たちの言語を生み出し、自分たちの対象物をデザインすることだ。
未来のパターンを作ろう
パターンというと、過去や現在の成功体験を文字にしたものと捉えがちだが、文脈や問題、期待する結果（夢やビジョン）などからパターンを作ることはできる。たとえば、
- 入ってきた新人に、主体性がなく、言われたことしかしない。
- 異なるチーム間の関係が悪い／コミュニケーションが不自由
などの問題があれば、それぞれの固有の制約や文脈を洗い出した上で、解決策案を作ることができる。
- リスクの少ないプロジェクトを任せ、成長を見守る（獅子の子落とし）
- 複数チームからのメンバーをシャッフルしてふりかえり [pp.23-24 IPA アジャイル型開発におけるプラクティス活用リファレンスガイド]
このように現場ごと、その時期ごとの問題をパターン集として作ることができる。
シナリオや物語を語ろう
パターンを単語として扱うことができる。そのパターン辞書は、このようなものがある。
そのパターンを単語として、シナリオや物語を書いてデザインしよう。そこで描かれたビジョンと、現場をつなげるロードマップをデザインすることになる。たとえば、IPA リファレンスガイドを用いた物語の例だ 「アジャイルプラクティス・パターンをつくるワークショップ」セッション資料より
昨日は初回リリースが無事に終わり、今はふりかえりをしている。最初、スパイク・ソリューションで技術的なリスク事項を確認し、シンプルデザインを心がけたので見通しは良かった。共通の部屋で、チーム全体がひとつになって開発を行った。チームは、ファシリテータ（スクラムマスター）と開発をした。プロダクトオーナーは、様々な調整に走り回りなかなか仕様が決まらなかったことが課題であった。 昨日のリリースに対して障害の報告があがってきた。バグ時の再現テストですぐに確認できたので、継続的インテグレーションを用いてリリースを行った。リファクタリングのタイミングについては意見が割れている。 今後の体制は、顧客プロキシを実現しつつ、組織構造のバウンダリをゆるめながら進むことで、合意を得られた。このプロジェクトは、TOC-CCPMと組み合わせるなど組織にあわせたアジャイルスタイルが実現できている。ただ楽しい工夫をもくろんでいることは内緒である。
参考資料
- 「アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイド
- パタンの書き方
- パターンライティングワークショップ Agile Japan 2013
- ソフトウェアパターン−時を超えるソフトウェアの道−:4.これからの みんなのことば，みんなのかたち−パターンランゲージからプロジェクトランゲージへ
- パタンランゲージからプロジェクトランゲージへ (AsianPLoP 2011)
- From Pattern Language to Project Language (PLoP 2013) こちらで、Patterns for the future （フューチャーパターン）、つまり未来のパターンとして紹介した。
次に向けて
パターンの形式を使って自分たちの現場に耳を傾け、自分たちの声で未来を語る。なんてワクワクするんだろうか。プロジェクトランゲージは、製品やサービスのデザインに向いているが、今回は現場の声を開放するためのパターンとプロジェクトランゲージを簡単に紹介した。ぜひ使ってほしい。
次は、いとじゅんさん！よろしくお願いします！
