2008/02/24

プレイングマネージャ

「部下と張り合うようでは上司失格」(NBonline/後半を読むには無料会員登録必要)。本インタビューはソフトウェア開発のロールについて語ったのではありませんが、大変興味深く感じました。

プレイングマネージャ(本記事では、「プロデューサー兼マネジャー」と書かれています)は、トム・デマルコの『ゆとりの法則』でも述べられていたとおり、非常に難しい立場だと思います。

ソフトウェア開発の分野で頑張っている方々は、元もと、自らソフトウェアを書くことが好きな人が多い為、適性が考慮されることなく、この役割が押し付けられた場合、ややもすると、
プレーヤーとマネジャーのどちらの役割を疎かにするかというと、後者の方が多い。
という傾向になってしまいがちで、チーム全体が不幸になってしまいます。

一方、この状況を回避する目的でプレイヤを専任管理者と定義した場合、または専任管理者を外部から据えた場合、その方の「嗅覚」によっては、
管理職がプレーヤーとしての役割をあきらめた場合、ビジネスの感覚が失われます。
との指摘通りになってしまいます。ソフトウェア開発は比較的進歩の早い分野ですので、この点がより致命傷になりかねません。

少なくともソフトウェア開発の分野に於いては、「管理者」と呼ばれる「自身以外の人材を有効活用する立場にいる方」には、2種類の帽子をかぶった方々が必要だと、私は考えています。

一人は技術指導者の立場でチーム育成を行う方で、所謂「棟梁」のような方でしょう。このあたり『ソフトウェア職人気質』で定義するところの「マスター」的な位置の方かもしれません。

一方で、プロダクトやチームを横断的に見る方も必要で、こちらは一般的な定義での管理者に近いのかな、と思います。何らかの方法で完成物に関する定義をする方は、この立場に居る方でしょう。

この両者は、「MSF」に於いては、前者を「プログラムマネージャ」(のロールの一部)として、また後者を「プロダクトマネージャ」として分離しています。

この視点で、Developper's Summit2008での参加セッションをを振り返ってみると、平鍋さんが「海外におけるアジャイルの現在」で語った「ソフトウェア開発に必要な学習する組織のリーダー」は、一人の人間としてこの両方の帽子をかぶることが求められますし、また「TPSのChief Engineerこそ、その人だ」と定義していたのだと思います。

また、「David Intersimoneと日本のRubyのコミュニティが、オープンソースの現在と未来について語る会」での話では、まつもとさんを頂点とするプログラムマネージャ群は成立しているので、今後はプロダクトマネージャが必要となる、という話だと捉えることが出来るでしょうか。

何れにしても、このようなロールを一人で新規に負うのは多くの努力が必要であり、
そもそもプレーヤーからマネジャーになること自体が簡単なことではないのに、ましてやプレーヤーであり続けることも求められる。管理職が円滑にマネジャーの仕事をこなせるようになるように、企業はできる限りのサポートをしなければなりません。

という通り、組織全体でサポートすることが必要なのだな、と切に思います。

ちなみに、現在Googleの人材募集ページを眺めると「リード エンジニア/アーキテクト」を募集しているのですが、その業務内容は、
  • 実際の開発業務の中心となると同時に、リーダーとして、少人数で構成されるプロジェクトの進捗管理や、調整作業を行う
  • プロダクトマネージャーなどと連携をとり、優れたサービスを開発する
  • プロジェクトにおいてコンサルタント的な役割を果たし、コードレビュー、デザインレビュー、技術講演や社内教育などを通じてチームメンバーの指導にあたる
と説明されてあり、プロダクトマネージャとプログラムマネージャの役目が明確に分離されていて、流石だな、と思うのでした。
広告

0 件のコメント:

コメントを投稿