デスマーチの作り方 -ある程度の規模の組織には、情報を送り出す強力な心臓が必要-

デスマーチの作られる原因にはいろいろあるとは思うけど、一つには規模や性格の異なる案件で、これまで自分達が成功してきたやり方で押し通そうとすることがあるんじゃないかと思った。
2桁単位の開発人員でのプロジェクト、顔を合わせるだけで情報が交換できるようなプロジェクトでは、チームリーダーが週1回ミーティングして意識合わせするだけでよかったかもしれない。
でもこれまでそんな開発ばかりやってきたところが、いきなり3桁人員の開発プロジェクトを引き受けて、これまでどおりのやり方でやろうとしても、うまくいくはずがない。
プロジェクトの血液とも言える新鮮な情報はあちこちで行き渡らなくなり、規模が大きいだけにリーダーの数も多いので、定例のリーダー会議とやらは際限もなく続いて時間を無駄にするばかり。
プロジェクトの性質が異なるならばそれに合った形で情報共有のためのシステムなりスキームを改めないといけないのは言うまでもないのだが、改善しなければと思っても、既に週にいくつものマイルストーンの嵐に追われ、結果何に手を付けられるでもなく地獄のままの日々が続く。

それでも、まだ問題があるのだと気付いているのならばまだよい。
小さなベンチャー会社等、大きな仕事をはじめてやるところは、みなそんな危機にさらされるのだろうが、一番のトップから下っ端までみな現場を見て危機感を共有できるだけに、一丸となって状況改善に対処できるから、成長していくのだろう。
上下の別がしっかりしてる大会社なんかの方が問題の根は深い。
プロジェクトの下の下の階層の、1サブチームの現場の危機的問題など、いかにそのチームのミッションがプロジェクト全体に関わる事であろうと、プロジェクトトップの人間は認識もしていない。
職場近くの飲み屋でより上の人達なんかと一杯引っ掛けた後、職場に戻って、毎日終電近くまで仕事しているプロジェクトメンバーに対して「お前ら！もう遅いぞ、体にも障るし帰れ！」とか絡んでくるのが、プロマネとしてメンバーとコミュニケーションを取り心を遣ってやることだと思い込んでる。
プロマネだったら、今この火を吹いている状況に対して、なにかできる事があるだろうに。

一例を挙げると、プロジェクトにとって大切な要素であるところの見積もり。
今、うちのプロジェクトでは、これまでも何度か助けてもらい、成功してきた関連会社のシステム見積もりのプロ達を呼び寄せて、見積もり作業を丸投げ？してやってもらってる。
彼らは武器とも言える魔法のExcelファイルを持っていて、見積もりに必要な機材の数、構成、載せるソフトウェアの数、その他もろもろをマトリクスに入力すると、たちどころに全体の見積額を表示してくれる。
ところが。
多分2桁単位の開発人員でのプロジェクトでならうまく機能したであろうそのツールが、今回の案件では全く通用しない。
それもそのはず、サーバや端末の数が2桁、載せるソフトも2桁、といった具合ならまだマトリクスもメンテできただろうが、サーバや端末の数が3桁、ソフトにいたっては3桁も後半に入るようなマトリクスを、誰が「正しい」と確信を持ってメンテナンスできるのか。
ましてや日々、構成に関する要求が朝令暮改されるような状況で。
ウイルスソフトやOfficeソフトのように、全ての機器に入ると判っているソフトですら、いちいち全機器に対してマトリクスを埋めなければならない状況。
ましてや、単純にソフトと機器のマトリクスといっても、CPUライセンス、数台に１つでいいフローティングライセンス、数ライセンスパックでの一括ライセンス、果ては2台目、2CPU目から価格の変わるライセンス等等、複雑怪奇なライセンス体系は、マトリクスに少数を入れるなどイレギュラーな記載をするしかないのだが、それがあまりにも多すぎて、この小数の値の根拠がなんだったかなど後で全くわからなくなる。
まる1日半かけてプロジェクト全体のリーダを代わる代わる呼び出して、プロジェクタで見積もりマトリクスの精査をお願いし、その場でリアルタイムに直していく、というような事すらやってさえ、次の日には間違っているところが発覚すると言う、そういう状況。
もう、正しいシステム構成がどうなっているのか等、誰も判らない状態。

これまでやってきた方法が通用しないと判ったのであれば、そこで新しく内部システムを立ち上げるべきだったのだ。
別に呼び寄せられた見積もりのプロ達は悪くない。
彼らはその神様の見積もりツールを持っていたがためにこれまでプロとして活動してこれたのだし、それがうまくいかないとなれば新しいシステムを作る力は彼らにはないのだから。
必要なのは、彼らから見積もり作業のエッセンスを聞き取り、専用のより効率的なツールを即座に作り上げる、内部システム部隊だったのではないかと思う。

同じような経験は他にもあって、私も昔、この仕事に着任したばかりの頃、配下のメンバーと情報共有を行うために、個人PC上でWikiを立ち上げた事がある。
ところが、うまく機能しない。
Wikiといっても単純においておくためだけでは駄目で、業務が判らないことだらけだから、その業務での成果物を出すのに最適な結果を出せるようカスタマイズしてやらないといけないわけだけど、ところが業務が次々新しいことが発覚してこれまでのやり方が通用しなくなるものだから、日々業務とは別にWikiの改造に明け暮れるようになってしまい、結果最終的には追っつかなくなりやめてしまった。
これも、専門の遊撃的な内部システム部隊がいれば、日々変わる情報要求の要件に対しても、追随してシステムを更改していけたんじゃないかと思う。

組織やプロジェクトも、生物と一緒だろう。活性化するのに必要な血液（体液）は、この場合は情報であったり、効率性であったり。
小さい規模であれば、単細胞生物と一緒。特に特別な器官を持たなくても、体液は全体に回っていく。
ところが大きな規模になると、多細胞生物と一緒で、単にただ「ある」だけでは全体に栄養は行き渡らない。栄養の行き渡らないところが発生し、そこから組織は壊死していく。
必然的に心臓と言うような、体中に栄養を行き渡らせるための器官が必要になるが、これが内部システム構築を考える部隊ということになるんじゃないかと思う。
プロジェクトそのものを扱うわけではないので、無駄に見えるかもしれないが、単に火を吹いているからといって闇雲に前線に人を送っても、3桁×3桁のイレギュラーなマトリクスをメンテナンスするのが、一人でできる仕事ではないがかといって数つぎ込んでどうなる問題でもないのも確かだ。
それならば一旦俯瞰して、プロジェクト全体の血液循環をよくするために、遊撃的な内部システム構築部隊を整備する事こそ必要ではないのかと思う。