プロジェクトマネジメント（チーム編成編）
他所の記事を自分用に編集した、備忘録です。
-----------------------------------
はじめに
-----------------------------------
さっそくですが、皆さんはご存知でしょうか。
「50％以上のITプロジェクトが失敗しており、その失敗の85%は人的問題や管理が要因」であるという事を。
近年は情報システムの導入や活用などの仕事が急増しています。
ITに詳しくない人が、ある日突然IT関係のプロジェクトにアサインされることも少なくありません。
プロジェクトを成功させるためには、その目的や実現に向き合いプロセスを設計し、成果物を得るための段取りをすることが大切です。
しかし、プロジェクトの進め方を体系的に学ぶ機会があまりなく、見よう見まねで進めることが多いのが実情です。
今回はプロジェクトがなぜ難しいのか、うまく進められるプロジェクトチームはどのようなものかを考察していきます。
-----------------------------------
問題の認識
-----------------------------------
■プロジェクトチームが破綻する理由
プロジェクトを進めていくためには、メンバー同士の協力体制を築く必要があります。
そのためにまず、リーダーやマネージャーは、「プロジェクトとはそもそも失敗するようにできている」ということを認識すべきです。
以下のとおり。
＜１．あらかじめゴールを設定するのが難しい＞
ルーティンワークの様に何度も繰り返して経験のある事柄であれば、「いつまでに、どの程度の成果を出すと良いか」という目安を持つことができます。
しかし、未経験の取り組みにおいては、それがそもそも実現可能なのか、あるいは適切な目標設定なのか、論理的に導くことは極めて難しいのです。
例えば、初めてマイホームを建てることになった場合、どんな成功条件を設定するでしょうか？
立地、内装、間取り、採光、これからの家族計画……
さまざまな要素が複雑に関連する問題です。
ぼんやりと思い浮かべる事はできても「具体的にこうなったら成功だ」という基準をあらかじめ設定することは難しいものです。
必ず、想定していなかった事柄によりギャップが発生します。
ビジネスにおけるプロジェクトも同じです。
新しいツールを導入する、新商品を開発・販売する、コスト削減をする、採用プロジェクト……
どんな領域であれ、それが「まだやったことのない仕事」であるならば、それは新規のプロジェクトなのです。
＜２．実行した施策が、意図と反する結果をもたらしてしまう＞
プロジェクトで未知の対象に働きかける場合、「やろうとしたこと」と「実際に起きたこと」の間に、ギャップが発生しやすいものです。
「コブラ効果」という言葉があります。
その昔、植民地時代のインドで、英国人の知事が「安全のため、街からコブラを駆除する」という政策を実行したそうです。
「コブラを駆除したら、報酬を出す」と告知したところ、何が起きたと思いますか？
現地の住民は、コブラを駆除して届け出たのではなく、コブラを養殖して届けでしたのです。
あわてて法律を撤回したら、住民は増やしたコブラを街に放ってしまいました。
コブラを減らそうとしたら、逆にコブラが増えてしまった、というわけです。
皆さんが取り組むプロジェクトにおいても、似たような事例が起きてはいないでしょうか？
「モチベーションアップさせようと決起集会を開いたが、人が集まらなかった……」
「信頼回復のため徹夜をしたが、疲れからミスが増えてしまい逆に信頼を失った……」
などなど。
＜３.プロジェクト途中で発生した「想定外」が、その後のプロジェクトにおける制約になる＞
プロジェクトを進める中で「想定外」な事態が発生することで、多くの場合、資金や時間などの大切なリソースが減少してしまいます。
プロジェクトの「想定外」で使ってしまったお金や時間は、二度と帰ってきません。
想定外の支出やタスクを出してしまった場合、これが新たな制約条件（負荷）として、チームにのしかかってきます。
-----------------------------------
問題点のまとめと、解決の方向性
-----------------------------------
このように未知なるプロジェクトには、「そもそものゴール設定が難しい」「実現過程の予想が外れやすい」「次々発生する想定外が新たな制約条件を生み出す」という性質があります。
これらの点が、「プロジェクトとはそもそも失敗するようにできている」理由であり、チームの破綻をもたらす原因です。
そんな、プロジェクトが思ったとおりにいかない中で大切となるのが、いかにチームを破綻させず、良いチームワークを生み出すかです。
漫画『スラムダンク』に「諦めたらそこで試合終了」という名言がありますが、プロジェクトも同じことが言えます。
たとえプロジェクト自体が思ったように進まなくても、メンバーの士気が高く諦めていないかぎりは、勝負ができる状態だと言えます。
以下に従来型のプロマネの欠陥と、それを解消するためのプロジェクトチームでの認識共有をご紹介します。
■成果物とスコープから逆算する従来型プロマネは、「未知」に対処しきれない
一般的に、プロジェクトを遂行するにあたっては、「成果物」と「スコープ（作業範囲）」を明確にして、そこから逆算するのが定石です。
やろうとしていることが、ある程度経験のあるもの（ルーチンワーク）であれば上手くいくでしょう。
定石は正しい考え方なのですが、冒頭でも述べたように「50％以上のITプロジェクトが失敗」という事から分かるように万能ではないのです。
なぜなら未知の度合いが高いものごとにおいては、「そもそもその成果物で十分なのか」が判断しづらいからです。
つまり、「なにが分からないかが、分からない」状態なのです。
■縦割り・計画順守型マネジメントは、抜け漏れや食い違いが起きやすい
「何が分からないかが、分からない」プロジェクトで、分からないなりに成果物を定めて、メンバーに割り振ったとします。
そこでなにが起きるのでしょうか？
もちろん、メンバー各人は「割り振られた仕事をとにかくこなす」でしょう。
しかしそれらの成果を単純に足し合わせても、抜け漏れや食い違いが発生してしまいます。
そのようなギャップはメンバーに強いストレスを感じさせ、トラブルや遅延の原因となります。
ひどい場合は、「自分の担当はきっちりやっている」「悪いのはマネジメントだ、コミットを達成していないメンバーだ」という責任の押し付け合いにつながってしまいます。
■プロジェクトで大切なのは、メンバー同士の認識共有
刻々と状況が変化する、未知の度合いが高いプロジェクトで大切なのは、「予定通りに進めること」「コミットした内容を達成すること」ではありません。
必要なのは以下の点を考えることです。
・もともとやりたかったことは何か
・実際に進めたらどこにギャップが発生したか
・ギャップに対処するために、今後どうするか
関わる人数が多い大規模プロジェクトの場合、その立場や動機によって、姿勢やスタンスもバラバラです。
だからこそ、意味のある共同作業を進めるために、この点について共通認識を作るのがとても大切になります。
----------------------------------------------------------------------
メンバー同士が助け合う「プロジェクトチーム」の作り方
----------------------------------------------------------------------
最後に、これからのプロマネが意識すべき、次世代型プロジェクトチームの考え方をご紹介します。
■「自立分散型」の考え方
心理的安全性、ホラクラシー、アジャイル、ティール、リーン……
近年注目の手法に共通する考え方があります。
・最初に全体像を描いて、その通りに実行しようとしても、難しいことが多い
・上下関係のもと、命令して遂行させるマネジメントは、オワコン。創造性が失われ、効率を損なう。
・仮説立案・実行・効果測定のサイクルを高速化することで精度を高めるのが有効（着手前に長々と議論することを避ける。）
・最前線で動くメンバーの裁量を拡大しよう（ポリシーや価値観は、必ず揃えるのが前提。）
量産品や再現性の高いサービスを横展開するビジネスでは、従来型のトップダウン方式マネジメントの方が効率が高い事もあります。
しかし、未知の課題に対処する模索的なビジネスにおいては、上記のような全く別のアプローチが有効となります。
■「相互理解」「部分から全体へ」「仕組で担保」の条件を揃えたプロジェクトチームが強い
模索的なビジネスとは「同じことの繰り返し」ではなく、「毎回いつも新しい」仕事です。
そこでは確実に成果を出すためのマニュアルを作るのは困難でしょう。
しかし正解がないからといって、不安に思う必要はありません。
以下のポイントに気をつけることで、変化に強いプロジェクトチームを作れます。
・相互理解：「上から下に命令する」ではなく「互いに違いを理解しともに正解を探す」
・部分から全体へ：「青写真通りに全体を一気に作ろうとする」ではなく「一つひとつの部分やプロセスを正しくマネジメントし積み上げる」
・仕組みで担保：「権限をもった人がコントロールする」ではなく「価値基準や意思決定プロセスによって間違いを防ぐ」
■これからは「多くの人の知恵を集める」プロジェクトチームの時代
これからは「統制」するプロジェクトチームから「多くの人の知恵を集める」プロジェクトチームの時代が来きます。
マイホームのたとえ話でもご紹介したとおり、「なにがわからないかがわからない」プロジェクトにおいては、正解は存在しません。
それはルーチンワークと比べると、間違いなく難しいことですが、「正解が存在しない」なら「正解を提示する必要もない」のです。
もちろん、自分の独力で実行しなければいけない、なんてことはありません。
代わりに正解へ限りなく近づこうとする努力が必要です。
いかに、プロジェクトに集まったメンバーの長所や意欲を引き出し、コラボレーションを生み出すのか。
これからは「統制」ではなく「多くの人の知恵を集める」プロジェクトチームが成功の鍵を握るでしょう。