うちの会社のプロジェクト管理でダメなところ

覚書というか、まあ、忘れないうちに書いておこうと思う。

プロジェクトの管理指標が経営指標

まずは仕事を取ってくる所。

期の予算を達成できるかどうかがすべてな運営方法になっている。抱える人員でこなせる仕事のキャパシティに関係なく、売上を達成させるのに十分な仕事を無計画に取ってくる。このため、全員で遅くまでだらだらと残業するはめになる。

だらだら作業してても終わらないので、最終的に仕事ができるやつが頑張ってなんとか収めることになる。こういうむちゃくちゃを押し通しているから後継が育たない。脱落していった人に対して「あいつは結局この仕事は無理だった」という理由に帰結してしまう。

また、現場がいくらこの工程は無理だと言っても、「だって売上が足りないからしょうがない」の一声で一蹴される。経営指標至上主義。設計・製造側の意見はまったく重視されない。俺が決めた納期まで間に合えばOK、間に合わなきゃ殺す。という単純明快な発想。

作業ボリュームは「なんとな~く」のどんぶり勘定でほぼ独断で決めるので、実際の作業量よりも多い金額で決着がついたら「俺の交渉力すげえ」で終わり、実際の作業量よりも少ない金額で決着がついたら「うるせえ、この金額で出来るはずだ。お前がおかしい」で終わり。何にも根拠なんて無い。

プロジェクトの立ち上がりがぐだぐだ

次は仕事を取ってきてから。

発想が小学生の夏休みの宿題レベル。まあ、まだ急がなくていいよ。と、プロジェクトの立ち上がり段階でのスピード感がゼロ。まだ大丈夫。の名のもとに、プロジェクト立ち上げ近辺で当然やっておくべき仕事、つまり、作業ボリュームの詳細な見積り、必要なスキル、人員の確保、開発環境の準備、プロジェクトスコープの策定、おおまかな仕様の策定、というものが疎かにされる。

仕様を策定してるメンバーの中に技術を知ってる人が居ないため、作業ボリュームを大きく増してしまうような仕様も平気で飲んでしまう。基本的に客の言うとおりハイハイと仕様を決めていくので、むちゃくちゃな上流設計・仕様になっている場合が多い。

なぜこのようになってしまっているかというと、上流設計はベテランがやる(キリッ)という考えで居るからだ。若いうちはコードをせこせこ打って、経験を積んだら上流設計をするもんだと思い込んでいる。

さらに、そのベテランも大昔の技術しか知らず、最近の技術を勉強するのも嫌いな、ただの「俺偉い」と思ってるオッサンなので、結局は前述のようにいい加減な仕様を策定するなど、ベテランとしての役割をしない。

突然の作業開始

実際にコーディングやドキュメント作成を担当する人員に話が伝わるのはプロジェクトが開始して数ヶ月たってから。ある日突然に告げられる。

この段になって、上流設計がそもそも実現できなかったり、多大な労力を要する仕様だったりということが、詳細設計開始、もしくは、もうすぐコーディングという時点で初めて判明する。

その時点で上流設計の見直しを主張しても時すでにお寿司、いくら酢飯って言っても、こりゃちょっと酸っぱすぎないか、腐ってんじゃねえか、って頃合いだ。

オッサンは年功序列でポストを与えられただけなので交渉力もクソもない、ただ単純に客が言うことを繰り返し言うだけ、いまさら客に逆らって仕様見なおしさせてくださいとは恐ろしくて言えないのだ。

果たしてプロジェクトはデスマーチへの階段を登っていく。

プロジェクトの経過

上流仕様を決めた自称ベテランも老害だが、製造を担当する人間も質が悪く、見るに耐えないコードを良く出してくる。オブジェクト指向言語でオブジェクト指向的な設計思想にもとづいて実装することが出来る人間など殆どいないに等しい。

こういう集まりなので、UMLとかユニットテストとか、近代的な設計開発手法を理解できる人も皆無に等しい。未だにブロックチャートを書かせる人種だ。結局、ここでも仕様の欠陥というのはキャッチされることがない。

見積もどんぶり勘定だが進捗もどんぶり勘定で、客観的な進捗の報告がない。本人が申告する「n割完了」という信頼性皆無の値だけである。こういうことが相まって、そもそもプロジェクトの遅れが目に見えにくい。

土壇場で人員増強

プロジェクトも納期が近くなると、夏休みの最後、小学生が必死に宿題を終わらせるがごとく、全員が夜遅くまで残業し始める。

ちょっと話が脇道にそれてしまうが、私が小学生の頃、こういうことがあった。

「これは何だ。K。」しーんと静まる教室で、同級生のK君が怒られている。先生の手には妙にしわくちゃになった夏休みのドリル。

「どうしてドリルを糊で貼り付けたんだ」先生は言う。そう、K君はあまりにも夏休みのドリルをやるのが嫌で、なんと、夏休みのドリルのページを貼りあわせ、その中間ページを「なかったこと」にしようとしたのだ。

しかし、使った糊がアラビックヤマトみたいな、水分を多量に含むタイプのものであったため、その水分によりページはふにゃふにゃにふやけ、誰が見ても絶対にバレる陳腐な隠蔽工作と化していた。というか、どんなに綺麗に貼り付けたとしても紙の厚みや硬さでわかってしまうだろう。人間の指の感覚というはかなり繊細だ。

「ね・・・姉ちゃんがやったんです!!」K君は言った。これもあからさまに嘘だと分かる隠蔽工作であった。なにが面白くて姉ちゃんはアラビックヤマトで弟のドリルのページを貼りあわせねばならぬのか。一体何の得があるのか。皆目検討付かない。アラビックヤマトを貼り付けたら好きな男子から告白されるなどのジンクスが流行っていたのだろうか。いや、どう考えてもありえない。

姉ちゃんが弟のドリルのページをアラビックヤマトで貼り付ける合理的な理由が無いということそれ自体が、K君が嘘を付いている事実を補強する材料なのである。大人にもバレるのは当然として、同年代の同級生からみてもあからさまに嘘だと分かるその良い訳たるや、本当に情けないと思った。まさかヤマト株式会社の社員も、隠蔽工作に自社製品が使われるとは思わなかっただろう。はっきりと私は不愉快である。

かくして私は、面倒くさいことを後回しにするからダメなのだな。面倒くさいことを面倒臭がらずに先回りしてやるのが良いのだな、と学習した。そして私はちょっと大人になったのだと思う。

しかしとても残念なのが、大人になってもアラビックヤマトでドリルを接着するかのような行いをしている人が少なからずいることである。

一体どういうことかというと、プロジェクト末期の人員増強がその一例であろう。はっきり言って、これほどの愚策はない。「人月の神話」、「デスマーチ(なぜプロジェクトは混乱するのか)」、その他どんな本を読んでもプロジェクト末期での人員増強は愚策であると述べている。なぜか。

これが「お魚の形をした容器に醤油をいれて弁当に添える」とかいう作業であれば、人員増強も有効であろう。しかし多くのシステム開発は単純作業ではない。数多のビジネスルールが存在し、それに基づいた数多の仕様がある。明文化されているものもあれば、暗黙的な仕様もあろう。それらすべてを短期間に全員に周知させるのは不可能だ。

さらに、人間のコミニュケーションというのは、人間の数nに対して二乗のオーダーで複雑さが増していく。すると伝わらない仕様、ミスリーディング、そういったものも指数関数的に増えていく。

だから、プロジェクト末期で人員を増強しても、事態は収束するどころか混乱を増すばかりなのだ。だから、これは愚策である。アラビックヤマトでドリルを接着するのと同じである。

じゃあなんでそういう愚策をするかというと、プロジェクトを管理している側がアホだからである。きっと夏休みの宿題も放置するタイプだったのであろう。つまり、システム開発作業が単純に人月、人日という単位に還元でき、それのみによって管理できると信じて疑わず、さらに、そうすることで失敗した経験があっても、それを次回に生かすことが出来ないということである。

数多の本でダメだよ、と言ってることをやる。そもそも本を読まないから知らない。以前失敗したことを学習せず、同じことでまた失敗する。そして成長しない。こういう人のことを、普通、アホという。そう、アホなのである。

プロジェクトが終わったら飲み会

いや、別に飲み会が悪いわけじゃない。あー、終わった。よかったよかった。とりあえず一杯やって、家帰って寝よ。という、その姿勢があかん。

先に述べたとおり、プロジェクトの失敗を次に活かすということをしない。というか、できない。何故ならば、プロジェクトに関するパラメータを一切収集してないからだ。ステップ数すら計測しない。正確には計測するが、計測して「こんなもんか」と思ったらそれで終わる。あとは何もしない。DB化するということすらしない。

そもそもデータが無いのでデータを元に次回の見積に反映させるとか、過去のデータと比較して今のプロジェクトが良いとか悪いとかそういう評価も出来ない。出来ないからやらない。やらないから、プロジェクトが終わったら酒を飲んでクソして寝る。

そうして出来上がったのが、年食ってプライドだけ高くなった使えないオッサンであって、そういう人から学ぶことなど殆ど無いので、後継も育たない。これはいかん。絶対いかん。維管束。

改善案

まずは教科書通りやってみたらどうですかね。

最近は、プロジェクトのパラメータ(エラー発生率、修正までにかかった時間、未修正エラー数、システムの規模(複雑さ)など)が手間を掛けずに収集できるツールが沢山あるので、こういうのを導入すればそんなに苦にはならんでしょう。また、工程管理もエクセルを使うんじゃなくて、ちゃんとMS ProjectとかRationalとかを買いましょう。

それができたら、今のプロジェクトが、うまいこと進んでるか、全然ダメなのか、判断できるようになります。判断できれば、早いうちから問題を把握することが出来るでしょう。面倒臭がらなければ、問題に対処したり、作業を前倒しして余裕を確保しようと頑張ったりして負荷平準化しようとすることもできるでしょう。

最終的にプロジェクトが失敗した時も、教科書通り対処しましょう。すなわち、プロジェクトが失敗した時に取れる策は、機能を落とすか、リリースを延期するか、そもそも中止するか、しかありません。

そしたら怒る客がほとんどでしょう。でも頑張って粘り強く交渉すべきです。そういう経験をしないと交渉力というのは身につきません。交渉力は年功序列でついてくるものではありません。苦労して身につくものです。そうして苦労すれば、次回からもっとうまく立ち回りができるようになるでしょう。

経営指標至上主義も同様で、頭ごなしに「予算はこれだっ!」ババーン!と通達があって、「出来るわけねーだろ、アホ」という旨をうまく言えるくらいの交渉力が無いというのも、前述のような経験が無いからこそじゃないすかね。どう?

まあ色々書いたが、そもそも、失敗を糧にして次回に生かすという人間にとって最も基本的なプロセスが欠如している人たちにとってこういうことが出来るとは思えない。教科書道理やる、って書いたけど、そもそも教科書にすら書いていないような基本的なことが出来ない人たちなんだしね。