プロジェクト・マネジメントにおいて、一番大切なことを伝えます。
つまり、複数人のチームでなんらかの成果物を作り上げる、世の中にアウトプットしていくときに、そのチームをリードしていくために最も大事なことを紹介します。
このブログでは、ホームページ、Webサイト、スマホアプリなどを成果物としてイメージしていますが、他の業種やプロダクト、領域や分野にも使える内容です。
サッカー型、ジャズバンド型、オーケストラ型の組織
ドラッカーが知識社会の組織の形態として「オーケストラ型」などを発信して以降、ジャズバンド型、サッカー型なども、従来型組織とは異なる新しい組織の形として、いろいろなところで語られるようになりました。
これらの議論に共通していること、つまり、結局何を言おうとしているかというと、
- 各メンバーが自律的に動く
- 各メンバーの専門やスキルが異なる
- 各メンバーの役割が流動的（変化する）
このような組織をどうリードしていくか、どのようにマネジメントすると最高のアウトプットが出るのか、という議論だと考えています。
IT業界、ネットの制作・開発現場では、他の業界に先がけていち早くこの状態になっていました。
ネットの制作・開発現場での具体例
実際、ネットの世界で20年仕事をしてきて、一番多かったメンバー構成はこんな感じです。
- ディレクター
- デザイナー
- プログラマー
先頭に「Web」をつけてもだいたい同じです。
- Webディレクタ
- Webデザイナ
- Webプログラマ
プログラマ、デザイナにそれぞれ１～２名、トータルで5人前後のプロジェクトチームを組めたなら、相当大きな規模のWebサイト・Webサービスをつくることが可能です。
20年の間にいわゆる「クラウド」が登場して、部分的に超早く、人件費以外の部分が劇的に安く実現できるようになったものの、この人数と規模感はあまり変わっていない気がします。
「Webデザイナ」は、どんな見た目にするかを四六時中考えています。
どんな色にしてどんな形に配置すればわかりやすいか、使いやすいか、そのときどきでの最高を実現するのがその役割です。よって、その仕事には「感性」をフル動員します。
一方、「Webプログラマ」はロジックが中心です。
プログラムはロジックを組み立てないと書けません。また、プログラム言語やコンピュータシステムの概略から細かいところまで把握して、効率よく・安定して動くように、プログラムを組み立てます。
スキル、役割のまったく異なるヒトの集まり、協同
スキル・役割がまったく異なるヒトたちが協同して仕事をするシーンを、もう少しイメージしてみます。
前述の例でいうと、たとえば「Webデザイナ」はその成果物、デザインしたデータを「Webプログラマ」に手渡してシステムの中に組み込んでもらうことが多いです。
よって、成果物のデータを介してコミュニケーションするわけですが、「Webデザイナ」が何をどう考えてこれを作り出したのかは、「Webプログラマ」は考える必要があまりありません。ヒトによって意識レベルは大きく異なるものの、「Webデザイナ」の仕事や考えていることをあまり理解しなくても、「Webプログラマ」の仕事・役割は完結し、実際に一定以上の品質を出すことができます。
ディレクタ、あるいは、プロジェクト・マネージャーであっても事情は同じで、「Webデザイナ」や「Webプログラマ」が何を考えてどのように仕事をしているのかは、通常あまりよくわかりません。成果物・アウトプットされたデータやシステムをチェックして評価するスキルさえあれば、一定以上の品質が出せます。
つまり、「お互いが、自分ができないことをやってもらう」という関係にあります。
このあたりが、ジャズバンドやオーケストラに例えられる所以（ゆえん）です。
ドラマーはギターを弾けませんし、バイオリニストはオーボエを吹く能力がありません。能力的に両方できるヒトもいますが、少なくとも同時に行うことはできません。
分業すると、メンバーの仕事をすべて把握することができない
このような状況では、普通に仕事をするだけだと、メンバーの仕事をすべて把握することができません。
そもそもは分業することにメリットがあります。分業することにより、仕事の品質が上がり、しかも早くできるようになります。
実際に、「Webデザイナ」と「Webプログラマ」を両方こなせるヒトはたまにいますが、一方は感性フル動員、一方はロジックの世界にひたることになるので、両方を統合して一人でできる人は非常に希少な存在で、私自身もあまり会ったことがありません。
両立は非常に困難なので、マネジメントの観点から言うと、分業してチームで仕事を行う体制をつくること自体が、ひとつのイノベーションではありました。
しかし、分業することにより、普通にしていたらお互いの仕事を理解できなくなります。
普通にしていたら、お互いの仕事の内容を理解しなくても、仕事が進んでいきます。
お互いの仕事がうまくいっている間は、これで済むかもしれませんが、実際の仕事・プロジェクトは山あり谷ありで、いろいろなトラブルを乗り越えながら進むほうが普通です。そうすると、お互いを理解できないことがプロジェクトのネックになってきます。
逆に言うと、チームメンバーの理解が「プロジェクト・マネジメント」の中心である、と言えます。
マネージャーがメンバーを、あるいは、メンバーがメンバーを十分に理解していれば、仕事がうまく早く進んで、アウトプットの品質が上がることは、経験的にも明らかです。
把握できない部分をマネジメントするには？
マネジメントする立場から見ると、たとえば、メンバーの仕事をたとえば5割ぐらい把握することができるなら、あとの5割はメンバーに任せることになるわけです。
その把握できない5割の部分の、仕事の品質はどうマネジメントすればよいのでしょうか。
成果物・アウトプットのチェックだけでは、たいていの場合十分ではありません。一時的なチェックだけでは見えてこない部分が、実際にはたくさんあることが経験上明らかです。
マネージャーが把握できない5割の部分の仕事の品質は、結局、メンバー自身のやる気・モチベーションに依存します。
もっとかっこいいもの、もっと速く動くもの、もっと効率よくする、もっと使いやすくする、というひと押しのところが、実はメンバーそれぞれのやる気やモチベーションの高さにかかっています。
やる気・モチベーションのモトは？
メンバーのやる気、モチベーションの高さは、なぜ生まれるのでしょうか。
このテーマは、これだけでも一冊の本が書けるぐらいのボリュームがありますが、あえて一言でまとめてしまうと、
ヒトは、自分を理解してくれるもののために働く・がんばる。
いわれてみれば当たり前の法則です。
逆の立場から言うと、プロジェクト・マネージャーがメンバーの仕事を十分理解していれば、メンバーそれぞれがどうしてほしいのか、マネージャーがすぐわかるようになります。
自分を理解してくれて、働きやすく、動きやすくしてくれるマネージャーがいれば、そのマネージャーのためにがんばろう、という気力がわいてくるのが自然です。
そして、お互いの理解度が高まる→モチベーションが高まる、という善の循環がまわることで、いいものがより早く、つまり、生産性が高まることになるわけです。
まとめ
チームメンバーの理解が「プロジェクト・マネジメント」の中心である、ということをお伝えしました。
お役に立てば幸いです。
コメント