勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

チームを上から引っ張るか、下から押し上げるか

http://medt00lz.s59.xrea.com/wp/archives/1299の記事を読んで考えたこと。ソフトウェア開発プロジェクトチームを引っ張るには、ここで書かれている「いい敵」を作って下から押し上げる方法と、上から引っ張る方法の二通りがあると思っている。どちらの方法を使うかの選択を間違えると、たぶんチームは混乱して前に進めなくなる。上から引っ張る方法はエレガントだけれども、通用する局面は少ないような気がする。

プロジェクトチームを「下から押し上げる」

チームワークとは、チームが「共通の敵を持つこと」で生み出される。「チームをまとめるためには敵を探そう」が、リーダーが身につけるべき方法論でもある。
「敵」という存在は、対立や排除の対象であって、概念を共有した上で、それを「敵」と名指しすることで、チームには「何をやらないのか」、「誰に嫌われるのか」が共有される。
http://medt00lz.s59.xrea.com/wp/archives/1299

1989年に公開された映画「メジャーリーグ」という、どん底の野球チーム(クリーブランド・インディアンズ)が勝ち上がっていく話を思い出す。この映画の中で、インディアンズのメンバーはリーグ優勝を目指すというよりは、いけすかない女オーナーの鼻を明かすことを目標にする(ちなみに、目標の見える化という観点で非常に興味深いツールが登場するのだけれども、興味があったら映画を見てみる事をお勧めする)。

わかりやすい「敵」を見つけるのは少し難しい。けれど「敵」さえ見つければチームを「下から押し上げる」事ができる。適切なサイズの「敵」によってメンバーの行動だけではなくて士気を上げることもできる。映画「メジャーリーグ」では試合の対戦相手ではなく、身近なムカつく女オーナー(とバリバリシール)がちょうど良い「敵」だったのではないだろうか。

  • ソフトウェア開発なら「スケジュール」や「品質」がいちばんわかりやすい「敵」になる。コストは「敵」としては使いにくい(ストックオプションやプレミアムボーナスがあれば別だけど)
  • ライバルのプロジェクトを勝手に設定するのはよくやる手。「やつらより先に○○を終わらせる!」とか、「あいつらには品質で勝つ」とか。
    • ライバルの情報をしっかりと収集して「あいつらはこんな事があったらしい。さらにうまい手を考えて見返そうぜ」とハッパをかけるなども出来る。
  • 良し悪しはあるけれど顧客を「敵」にすることもできる。と言っても敵対するのではなく「俺達が本当のシステム開発を見せてやる」とか「使いやすさで度肝を抜いてやる」など。

プロジェクトチームを「上から引っ張る」

新規のサービスを構築するようなソフトウェア開発であれば、「上から引っ張る」方式が使えることがある。プロジェクトのビジョンとゴールを明確にして、チームメンバーがその目標に向かっていくようにする。例えばアジャイルサムライではインセプションデッキというツールで、プロジェクトのビジョンとゴールを明確にする方法が紹介されている。

ソフトウェア開発は独特の営みであるといっていい。デザイン、構築、アート、そして科学。こうした要素がひとまとまりになっている。チームは日々数えきれないほどの決断を下し、さまざまな取捨選択を行う。プロジェクト固有の状況や全体像をきちんと把握しておかないと、適切な情報をもとにしてバランスのとれた取捨選択をしていくなんて、とてもじゃないが無理だ。インセプションデッキの前半は、プロジェクトの背後にある「なぜ」をあきらかにするための5つの質問と課題から構成されている。その内容は次の通りだ。

  • 我われはなぜここにいるのか?
  • エレベーターピッチを作る
  • パッケージデザインをする
  • やらないことリストを作る
  • 「ご近所さん」を探せ

アジャイルサムライ−達人開発者への道−

生みの苦しみはあると思うけれども、良い目標を設定して「上から引っ張る」ことがで実現できるとその後のマネジメントは非常に楽になる。でも「上から引っ張る」前提でプロジェクトをスタートして牽引に失敗すると悲惨な気がする。

  • そもそも全てのプロジェクトに明確なビジョンやゴールがあるとは限らない。
    • さまざまな会社が「皆がついてくるビジョン」を作れずに苦しんでいる。プロジェクトだって同じではないだろうか。
  • ビジョンやゴールがあったとしても、プロジェクトメンバーがついてくるとは限らない。
    • 共感できるかどうかが肝心で、良いビジョンであっても共感・同意できなければ皆がついてこないだろう。
    • ソフトウェア開発にありがちな受発注の関係や多重構造があったりすると、ハードルはぐっと上がる。
  • ちなみにアジャイルサムライでは、「我々がなぜここにいるのか」すら説明できない場合はプロジェクトを中止しろと示唆している。うーん、それはどうなんだ・・・。

あきらめ時も肝心だと思う。状況に応じて「下から押し上げる」方法に切り替えるつもりでいたほうがいいのではないだろうか。「上から引っ張る」にこだわりすぎるのも上手くないと思う。