プロジェクトはなあなあで始めない

プロジェクトに限らず、イベントでもなんでもそうですが、形式的であったり、お堅い雰囲気が嫌いで、なんとなくなあなあで始めることがあります。

いわゆる「けじめがない」「メリハリがない」と言う状態です。

これによって抱えるリスクには、次のようなものがあります。

　・気持ち（意識）が切り替わらない
　・必要な情報が共有できない
　・甘えが抜けない
　・楽観的になり、リスクに対して周到な用意を行わない

日本は「受け手」が読み取ることに重きを置く国です。一方的に「受け手に負担をかける」国と言ってもいいかもしれません。

「空気を読め」という言葉があるのがその最たる例です。

空気が読めるスキルが高くないと、その集団や仕事になかなか馴染めません。しかし、現実的には、常に空気が読める人材、社員と言うのは決して多くありません。多少読めても、100%読めると言うことはあり得ません。

プロジェクト活動と言うのは、1人では決してできないもので、常に複数人で活動し、また規模が大きくなればなるほど、参加メンバが連携・連動しなければならなくなります。

例えるなら

ムカデ競争と同じです。

　・同じ時間軸内
　・同じ目的・目標（ゴール）を目指し
　・足並み（スケジュール）が揃う

ことで前に進めるし、揃わないと転倒してしまうようになっています。

ムカデ競争では、１人が踏み出す足の案内や掛け声をかけることで、メンバは一丸となって前に進むことができます。同じように、プロジェクトにおいても、チームメンバに対して、意図した通り、目的に沿ってチーム一丸となって作業を進めてもらうためには、やはり、この「掛け声」と同じ役割を担う人がいて、実際に号令をかけなければなりません。

その第一声が、キックオフとなるわけです。

常にチームメンバに"空気を読むこと"を要求していると、プロジェクトは自ずと破綻します。ですから、プロジェクトの発足時は絶対になあなあで始めないようにしましょう。

こういうと、よく

　「最初からすべての仕様が決まっていることなんてないから
　　カッチリ決めて進めることはできない」

という言い訳を使う人がよく出てきます。
言い訳としては間違っていても、「仕様が確定していない」というのは厳然たる事実なのでしょう。では、なぜ"言い訳として間違っている"のかというと、

　「事実がそうである以上、
　　その事実に対して適切な方法を用いて
　　正しいプロジェクトの進め方を行えばいい」

だけで、その進め方がカッチリ決まってさえいれば、仕様が発足の時点で決まってようが決まってなかろうが関係が無いということを理解していないために、誤ったプロジェクトマネジメントをしてしまっている点です。

そもそも、仕様が100%決まっていないなんてのは当たり前のことで、プロジェクト活動のほぼ100%がそうなっているはずです。決まっていないことを前提で始めるのがプロジェクトだと言っても過言ではありません。

だからこそ、「言い訳」にする価値も無いのです。

では、そんな仕様が100%確定していないプロジェクトを、多くのマネージャーはどんなマネジメントで進めようとしているか？というと

　『100%決まっていること前提のスケジュール』

でマネジメントを進めようとしているから失敗するのです。

たとえば、

　①仕様の決まっている部分と決まっていない部分の境界線

を明確にしていますか？
決まっている部分は言い訳する必要もなく、決まった通りに進めればいいだけのはずです。仮に途中で変更を加えられても、それは着手前の見積スコープ外の作業になりますから、金銭的な調整はともかく、スケジュール的な調整はお客さまとの間でも容易に行うことが可能でしょう。

ここで調整が難航するのは、多くの場合、①を明確にしていないせいです。

他にも

　②仕様の決まっていない部分は「いつまでに」決めるか

を明確にしていますか？
ただなんとなくという理由で期限を切っても無意味です。仮にその通りの日程で仕様が決まっても、上手く進行はできないでしょう。

　「何を」
　「いつまでに」

が決まると同時に、スムーズに作業の着手ができないと結局遅延するだけです。期限にあわせて

　「誰が」
　「どうやって」

の準備もできていなければ絵に描いた餅です。「５日までに仕様を決める」と決まっていて、その通りに仕様が決まったとしても、実際に着手できる担当者の着手している業務でバグが大量発生し、その修正対応のため、８日からしか着手できない…というのでは、仕様を決める期限は８日でもよかったはずです。

こうした自分たちの問題で遅延させることが無いようにするためには、とかく『プロセス品質』の向上が行われなければなりません。

要するに、バグを作りこまない（作りこむ量を低減させる）活動が必要です。プロセスとしてのフレームワークを構築せず、すべてを属人的に丸投げしてしまえば、個々人のスキルセットに依存して、品質は劣化する可能性が出てきます。

そうなれば、計画的なマネジメントなんて夢のまた夢です。

　・最初から仕様が100%確定することは絶対に無い
　・仕様確定箇所に対する不良発生頻度を抑える仕組みがない限り
　　マネジメントは常に絵に描いた餅となるリスクを抱えることになる

このことを大前提として、プロジェクト発足時点でしっかりと準備できるようにしておきましょう。マネジメント経験のある人なら技術的には何も難しいことはないはずです（面倒なだけで）。