プレイングマネージャ(本記事では、「プロデューサー兼マネジャー」と書かれています)は、トム・デマルコの『ゆとりの法則』でも述べられていたとおり、非常に難しい立場だと思います。
ソフトウェア開発の分野で頑張っている方々は、元もと、自らソフトウェアを書くことが好きな人が多い為、適性が考慮されることなく、この役割が押し付けられた場合、ややもすると、
プレーヤーとマネジャーのどちらの役割を疎かにするかというと、後者の方が多い。という傾向になってしまいがちで、チーム全体が不幸になってしまいます。
一方、この状況を回避する目的でプレイヤを専任管理者と定義した場合、または専任管理者を外部から据えた場合、その方の「嗅覚」によっては、
管理職がプレーヤーとしての役割をあきらめた場合、ビジネスの感覚が失われます。との指摘通りになってしまいます。ソフトウェア開発は比較的進歩の早い分野ですので、この点がより致命傷になりかねません。
少なくともソフトウェア開発の分野に於いては、「管理者」と呼ばれる「自身以外の人材を有効活用する立場にいる方」には、2種類の帽子をかぶった方々が必要だと、私は考えています。
一人は技術指導者の立場でチーム育成を行う方で、所謂「棟梁」のような方でしょう。このあたり『ソフトウェア職人気質』で定義するところの「マスター」的な位置の方かもしれません。
一方で、プロダクトやチームを横断的に見る方も必要で、こちらは一般的な定義での管理者に近いのかな、と思います。何らかの方法で完成物に関する定義をする方は、この立場に居る方でしょう。
この両者は、「MSF」に於いては、前者を「プログラムマネージャ」(のロールの一部)として、また後者を「プロダクトマネージャ」として分離しています。
この視点で、Developper's Summit2008での参加セッションをを振り返ってみると、平鍋さんが「海外におけるアジャイルの現在」で語った「ソフトウェア開発に必要な学習する組織のリーダー」は、一人の人間としてこの両方の帽子をかぶることが求められますし、また「TPSのChief Engineerこそ、その人だ」と定義していたのだと思います。
また、「David Intersimoneと日本のRubyのコミュニティが、オープンソースの現在と未来について語る会」での話では、まつもとさんを頂点とするプログラムマネージャ群は成立しているので、今後はプロダクトマネージャが必要となる、という話だと捉えることが出来るでしょうか。
何れにしても、このようなロールを一人で新規に負うのは多くの努力が必要であり、
そもそもプレーヤーからマネジャーになること自体が簡単なことではないのに、ましてやプレーヤーであり続けることも求められる。管理職が円滑にマネジャーの仕事をこなせるようになるように、企業はできる限りのサポートをしなければなりません。
という通り、組織全体でサポートすることが必要なのだな、と切に思います。
ちなみに、現在Googleの人材募集ページを眺めると「リード エンジニア/アーキテクト」を募集しているのですが、その業務内容は、
と説明されてあり、プロダクトマネージャとプログラムマネージャの役目が明確に分離されていて、流石だな、と思うのでした。
- 実際の開発業務の中心となると同時に、リーダーとして、少人数で構成されるプロジェクトの進捗管理や、調整作業を行う
- プロダクトマネージャーなどと連携をとり、優れたサービスを開発する
- プロジェクトにおいてコンサルタント的な役割を果たし、コードレビュー、デザインレビュー、技術講演や社内教育などを通じてチームメンバーの指導にあたる
0 件のコメント:
コメントを投稿