スクラムにおける既存職種のあり方について考えてみた(中編)
はじめに
前編では書籍「エクストリームプログラミング」(以下「XP本」)を元に、スクラムにおける開発者、プロダクトオーナー、そして経営幹部と人事について述べてきました。
中編では、XP本におけるプロジェクトマネージャーの記述を通して、プロジェクトマネージャーの今後について述べていきたいと思います。
プロジェクトマネージャーはXPとは無関係?
XP本ではプロジェクトマネージャーは次のように説明されています。プロジェクトマネージャーにファシリテーターとしての役割を期待しています。
XPチームのプロジェクトマネージャーは、チーム内のコミュニケーションを円滑にしたり、顧客、サプライヤー、その他のチーム外の組織とのコミュニケーションを調整したりする。
しかしXP本で挙げられている他の職種は全て「やるべきことが増える」あるいは「やるべきことが変わる」のに対し、プロジェクトマネージャーは「やるべきことが減る」唯一の職種で、しかもXPの価値、原則、プラクティスが1つも含まれていません。
しかしXP本では、プロジェクトマネージャーには大切な役割が求められていることを示唆した記述があります。
チームの「門番」になる
XP本の別の箇所(15.3 組織の規模)に次のような記述があります。組織が求める情報を適切に翻訳する役割がプロジェクトマネージャーに求められています。
大きな月例会議で規定のフォーマットのスライドが求められているのであれば、XPプロジェクトマネージャーがきちんとそれを用意する。プロジェクトマネージャーは、組織が受け入れられる形で情報を提示するのである。
しかしそれを実現するには、プロジェクトマネージャーがXPの価値を理解して、チームには「字義＝体裁」でなく、「精神＝本質」に向き合ってもらう必要があります。
そのプロジェクトマネージャーは、毎週金曜日にXPチームのところにやって来て、チームメンバーにその週にやったことを聞くようにした。そして、情報を四半期計画の書式に記入した。その結果、そのチームの計画には組織のなかで最も正確な見積りが含まれていることが、四半期の終わりのレビューで認められた。
チームのなかにウソをつこうとする人はいなかった。すべてが正々堂々と行われた。チームで何が起きているかをすべてのマネジメント層が把握していた。このチームは、正しい書式によって組織が期待する字義を満たし、責任のある時間の使い方によって四半期計画の精神を満たしたのである。
ちなみにここで「門番」という言葉を選んだのは、「組織パターン」という本に書かれている、外部とのやりとりをコントロールするパターンの名称が「門番」だからです。
プロジェクトメンバーのうち、魅力的な性格を備えた人気者を一人、門番のロールに立てよう。プロジェクトの外部から来る最先端の情報や二次的な情報は、その人物がプロジェクトのメンバーに伝える。その際、プロジェクトに関係する用語に「翻訳」するのだ。門番はプロジェクトの情報を関連する部外者に「漏らす」こともあるかもしれない。
透明性を確保する
プロジェクトマネージャーは「門番」として働く一方、透明性を確保することも求められています。求められているのはあくまで言葉の翻訳であって、チームの中を不透明にしてはいけません。
壁に貼ったカードは、透明性の実践だ。それぞれのチームメンバーのインプットを大切にして、リスペクトするものである。
プロジェクトマネージャーには、チーム外の組織が期待する形式にストーリーを翻訳する仕事がある。彼らに壁の読み方を教えてもいい。隠すものは何もない。誰もが閲覧できて、誰もが利用できる。それこそが、最も有益なソフトウェア開発につながる人間関係を反映した計画だ。
先に書いた「門番」「透明性の確保」の2つの記述をみる限り、プロジェクトマネージャーの役割と、スクラムマスターの役割は似ているように見えます。では、プロジェクトマネージャーがスクラムマスターに向いていると結論づけていいでしょうか？
スクラムマスターは従来の役割とは異なる
スクラムマスターの役割について研究した「A Study of the Scrum Master’s Role」という論文があります。この論文では、スクラムマスターの活動について次の図のように分類しています。ファシリテーションの他に、Impediment removal(障害・妨害の除去)の役割がスクラムマスターの主な役割とされています。分類としては妥当でしょう。
なお、理想的なスクラムのロールがnone(なし)と分類されているうち、Travellingは分散したチームのコミュニケーションを促進するための移動で、Project managementはウォーターフォール開発におけるプロジェクトマネジメントと同じです。
この論文では、プロジェクトマネージャーがスクラムマスターになると、プロジェクトマネージャーを兼任してしまい、緊張と利益相反をもたらし、チーム全体のパフォーマンスに悪影響を与える可能性があると述べています。
We found nine activities that are performed by Scrum Masters. In addition, we found that Scrum Masters also perform other roles, most importantly as Project Managers. This latter situation results in tension and conflict of interest that could have a negative impact on the performance of the team as a whole.
These results point to the need to re-assess the role of Project Managers in organizations that adopt Scrum as a development approach. We hypothesize that it might be better for Project Managers to become Product Owners, as aspects of this latter role are more consistent with the traditional responsibilities of a Project Manager.
このようになってしまう理由は何でしょうか？それはスクラムマスターの役割を適切に理解していないからだと考えられます。スクラムマスターはしばしば「何もせずに見守ること」が必要です。しかし人は「何もしないこと」に耐えられません。その結果として従来の職種の役割をこなそうとしてしまいます。
この論文はプロジェクトマネージャーについて述べたものですが、これは他の職種でも言えるでしょう。むしろスクラムマスターには適切な教育が必要なことを示した論文とも言えます。
プロジェクトマネージャーという「職種」を解体する
XP本の記述を見る限り、プロジェクトマネージャーは一見、アジャイル開発での居場所がないように見えます。しかし本当にプロジェクトマネージャーはいらないのでしょうか。
自分は「職種」としてのプロジェクトマネージャーはだんだん不要になっていくと考えています。「プロジェクト思考」よりも「プロダクト思考」が求められるのも理由ですが、一番大きな理由はプロジェクトマネージャーという職種に欠陥があったからです。
これまでのプロジェクトマネージャーはCEOがCFO、CTOも兼務するような、過度な責任を負わされていました。優しかった人がプロジェクトマネージャーになった結果、冷たく、常に険しい表情をする人に変わってしまったこともあります。このような人を見ると、プロジェクトマネージャーになりたくない人が増えているのは当然だと思います。
一方でスクラムでは、プロダクトオーナー、スクラムマスター、開発者の3つの明確な責任に分かれています(スクラムガイドではこの3つは「役割」ではなく「責任」です)。このように1人の中で責任を調整するよりは、複数人の間で責任を調整する方がより自然なのではないでしょうか。XP本の記述も、プロジェクトマネージャーは不要になったのではなく、プロジェクトマネージャーの役割が解体され、他の役割に移動したと考える方が自然です。
プロジェクトマネージャーという「職種」は解体されますが、これまで培ってきたスキルは活かせます。マネジメントは不要ではありません。エンジニアがマネージャーになるケースはむしろ増えています。チームの「自己管理」を実現するためには、個人に自己管理のスキルが必要です。ドキュメントも、計画も、スケジュール管理も、タスク管理も、不要になったわけではありません。
アジャイル開発に対する理解は人一倍必要ですが、スキルを見ればどんな職種にもなれる、それがプロジェクトマネージャーとも言えます。従来のプロジェクトマネージャーの役割に固執せず、自分の強みを生かせる職種を選ぶのがプロジェクトマネージャーの今後だと自分は考えます。
おわりに
この記事では、アジャイル開発におけるプロジェクトマネージャーの役割について考察してきました。後編では、最後に残ったスクラムマスターの役割について考察します。