『組織パターン』プロジェクトマネジメントのためのパターン言語を代わりに読む
はじめに
今回は『組織パターン』第II部から「4.1 プロジェクトマネージャーのためのパターン言語」を代わりに読みます。第II部でパターンの羅列に入ることで、「パターン言語についての概説を読み進めた第I部の興奮がどうか冷めませんように」と祈りながら読みましたが、杞憂でした。第II部もめちゃくちゃ面白い、よかったー! まずは、めちゃくちゃ面白いという以外の「4.1 プロジェクトマネージャーのためのパターン言語」を読み終わった気づきをシェアします。
組織パターン (Object Oriented SELECTION)
- 作者:James O. Coplien,Neil B.Harrison,ジェームス・コプリエン,ニール・ハリソン
- 出版社/メーカー: 翔泳社
- 発売日: 2013/08/06
- メディア: 大型本
- 第I部の感想はこちら
全体的な気づき
- 邦題は『組織パターン』ですが、原題『Organaizational Petterns of Agile Development』とある通り一般的な組織論ではなく、"アジャイルソフトウェア開発のための"組織パターンであること(そのため、私自身が無自覚に経験したパターンも多い)
- 「プロジェクトマネージメントのためのパターン言語」という意味は「どうやってプロジェクトマネージャーがプロジェクトマネージメントをするか」ではないこと。
- 「どうやってプロジェクトマネージメントするか」が主題であり、開発者がプロセスの主役で、プロジェクトマネージャーは開発者を下支えすることが役割であること。
- 本書がスクラムの源流の一つということ
- ※参考 「プロジェクトマネージャーのためのパターン言語」のつながり
最大の制約
さて、前項で本書は「アジャイルソフトウェア開発のための」組織パターンと書きましたが、単なるソフトウェア開発ではなく「アジャイル」がついているのは、本書の背景、さらに私たちの世界を取り巻く最大の制約(フォース)にあるためと思います。それは以下です。
もしスケジュールを緩くしすぎると、開発者は安心するだろうが、マーケットの機会を失ってしまうだろう。だからといって、スケジュールがあまりにきつすぎても、開発者は疲弊してしまい、やはりマーケットの機会を失ってしまうだろう。さらに、スケジュールがきつすぎると、プロアクトの品質が下がってしまう。(p. 40)
私なりに言い換えると、「開発者が疲弊しないように、高品質なプロダクトを、マーケットの機会を失わずにリリースするにはどうすれば良いか？」という制約を念頭におくと、本章のパターンは非常に読みときやすいと感じました。
私なりの要約
というわけで「開発者が疲弊しないように、高品質なプロダクトを、マーケットの機会を失わずにリリースするにはどうすれば良いか？」という制約の下、本章のパターンの構造を乱暴ですが私なりに簡単にまとめてみます。
マーケットの機会を失わないためには、プロダクトを速く開発する必要がある
→ そのために開発者向けのスケジュールを若干厳しくしたり、プロトタイプを作る必要がある
→ 速く開発するためには開発者がプロセスをコントロールするのが一番効率的だ
→ それでも開発スケジュールは遅れる。けれどいちいちリスケしてたら効率的じゃないためリスケは一度にする
→ さらに開発には問題がつきものだ。新人も入るだろう。問題や新人に対応するチームと実プロジェクトを推進するチームに分けるなども工夫のひとつだ。
印象に残ったパターン
さてここからは印象に残ったパターンについて感想を書いていきます。
4.1.1. 信頼で結ばれた共同体
さて、各パターンが機能するために最初になくてはならないいわばスペシャルなパターン、それが「信頼で結ばれた共同体」です。
...いったん組織ができあがると、各メンバーの人間関係がチームの効率に多大な影響を与える。よい影響であることもあれば、悪い影響であることもある。
チーム内の人間が互いに信頼しあうことが欠かせない。そうでなければ、何かをやりとげることは難しいだろう。
これは今年の5月に転職した私にもよーく身に覚えがあります。今は解消したのですが、コンサルタントという職種への一般的な理解もなかったということもあり、はじめの内は同僚や上司と働くのがとても苦しかったです。ちょっとした言動にも敏感に反応し、「あの人は自分を嫌っているのだろうか」と週末まで悶々と悩んだり。今思えば、相手の背後にあるロジックや信念の構造がわからなかったため、信頼が成りたっていなかったと感じます。
なので、信頼がないと疑心暗鬼のため余計な仕事を増やしてしまい効率的ではないというのもありますが、単純に働けなるくらいとてもつらいんですよね。だからこのパターンがあらゆるパターンが成りたつ前提というのはとても納得できます。
閑話休題。
では、「信頼で結ばれた共同体」は具体的に一体どうやって構築するものなのでしょうか？ 著者は言います、「信頼していることを明示的に表現する行為をしよう。たとえばマネージャーは、組織が目標を達成するために自分たちが手助けをしているのだということを、極端なくらいはっきりと示さねばならない」。ここで面白いのは、とりわけ上位層に明示的に相手への信頼を表現せよ、と伝えていることです。
そして部下を信頼しそれを表現することが、従来型のコマンド&コントロール型マネージャーにはどれだけ難しいことか! ということは他社支援をしていて痛感するところです。なのでこちらのパターンは前提ではあるのですが、実際は徐々に適用していくのが現実的かと思いました。組織パターンを適用するためには従来型のマネージャーはマインドセットを変える必要をこのパターンは示唆しているようにも読めました。
4.1.4 名前付きの安定した基盤
ソフトウェアを頻繁に統合して、基盤が陳腐化しないようにしなければならない。ただし、頻繁に統合しすぎて、機能がどのようなものかという共通理解や、育ちつつあるソフトウェアの基盤に対する信頼を損ねてはならない。
それゆえ：
システムのインターフェース(アーキテクチャ)を週に一度は安定させよう。安定したシステムには名前を付けよう。そうすることで、そのバージョンの機能に関する共通理解を開発者たちが指を指して確認できるようになる。
最初に本書を「一般的な組織論ではなく、"アジャイルソフトウェア開発のための"組織パターンである」と先述しましたが、このパターンは典型的です。
先に引用した文章に続けて「その名前に凝る必要はない。たとえば、単純に連番であってもよい。ただし、その名前は覚えやすく、ソフトウェアの正しいバージョンを簡単に指差すことができて、それぞれを簡単に区別できなければならない」とありますが、この文章は若干矛盾しているように私は見えます。著者を責めたい訳ではありません。むずかしいんですよね。連番は覚えづらいし、コードネームは頻繁な変更で崩壊しがちですし...個人的にはあまりうまくいった記憶がありません......
4.1.15 開発エピソード
あらゆる開発に対してグループの活動としてアプローチしよう。全員がそこに取り組んでいるかのようにするのだ。その活動がいわゆるエピソード(物語)の通常の流れに従うようにしよう。意思決定というクライマックスに向けてエネルギーが集められ、そして、発散するのだ。
最初に「本書がスクラムの源流の一つ」と述べましたが、たとえばこのパターンは典型的で、スクラムのスプリントゴールを設定する起源なのではないかと感じました。個人的な経験からも「あらゆる開発に対してグループの活動としてアプローチしよう。全員がそこに取り組んでいるかのよう」になっているチームはフロー状態に入り、生産性が高いだけではなくとても楽しいです。それには物語と、チーム全員で物語を推進している感覚を共有することが欠かせません。
4.1.17 開発者がプロセスをコントロールする
他のあらゆる文化と同様、開発文化もプロジェクトの方向性とコミュニケーションの焦点を認識することで恩恵を受けられる。(中略)なぜなら、開発者たちはエンドユーザーから見える成果物を直接作り出すのであり、プロダクトの説明責任を果たすうえで最善の地位にいるからだ。プロダクト開発において、開発者ほど多くを費やし、また多くのフェーズに関わるロールは他にはない。そして、コントロールができなければ、説明責任を果たせないのだ。
(中略)それゆえ：
開発者がプロセスに関する情報の焦点にしよう。組織はマーケットに従う(5.1.9)の精神に従い、所定のフィーチャーを作るプロセスのハブとして開発者というロールを位置づけよう。
「開発者がプロセスをコントロールする」というと従来型のマネージメントに慣れている方にはぎょっとするかもしれません。ですが本章を読み進め、「高品質なプロダクトを、マーケットの機会を失わずにリリースするにはどうすれば良いか？」という制約に応えるには、直接成果物を作る開発者が情報のハブとなることがとても効率的なのだと納得できるのではないでしょうか。
もちろん権限と責任はセットです。
著者が「そして、コントロールできなければ、説明責任を果たせないのだ」と責任を強調しているのを看過してはいけないと思います。
おわりに
今回は『組織パターン』第II部から「4.1 プロジェクトマネージャーのためのパターン言語」を代わりに読みました。私が読んで特に面白いと思ったところだけを抜き出し高速で駆け抜けるという『グッドフェローズ』スタイルで書いてるためどれだけ本書の面白さを伝えられているか不安ですが、もし本書に興味が出てきたならば、原書にあたってみることを是非オススメします!
今回は「日本語版への賛辞」からアジャイルコーチの高江洲睦氏の賛辞で締めくくります。私が拙い文章で今回書きたいと思ったことがすでにシンプルな言葉で書き尽くされているからです。
最後までお読みいただき、ありがとうございました!
当然なのですが、すでに現場で見たことがあるようなものが多いはずです。そして、そこからさらに組織をより良くするためのヒントも散りばめられています。ただし、適用前に6章はしっかり読んでください。それから、なによりも一番大事なのは「信頼で結ばれた共同体」です。これなしでは始まりません。
ーー高江洲睦 アジャイルコーチ/プログラマー
