給与明細やボーナス支給明細を見るたびにはげしいふまんを感じる。社会問題ネタ、目次へ
入社３年目のボーナスとかわらんではないか、話が違う！という奴である。
経営陣にもいろいろと言い訳があるかもしれないが、それにしてはフォローがない。つまりこういうことだ。従来、管理職はやることを指示すればよかった。言われたほうもそれに従えば問題はなかった。多少無理なことを言われても、そのうち給与も上がる。だから管理者はすべきことを分割して命令する能力があれば、管理能力（うまくやらせる能力）なんぞなくてもよかったのだ。給与（と昇進）がそれに報いてくれるシステムだったから、個々人の管理能力をあてにしたのでそうそう問題はなかったのだ。
ついでに言うと、個々人は現在の仕事と、将来の見込みを秤にかけて仕事にまい進することによって、仕事の能力と仕事の管理能力（うまくこなす能力）を身に着けてきたわけである。
ところが、こういう世の中になってくると、個々人は、給与以上の仕事はやらなくなる。さらには管理能力を身に着けているがゆえに、自分の仕事をきちんと市場価値で測ることができる。従ってそれ以上の仕事はやらなくなる。残念ながら資本主義の世界ではこれに抗する力はない。従って、管理者は資本主義の枠外でやる気を出させるために何かしなければならないだろうというのである。これが上で言う「フォロー」という奴だ。
これがないとすると、情報漏洩対策として情報漏洩防止の教育をやっても、情報漏洩防止手当てでも支給しない限り効果はないだろうなあと思っている。秘密を守ることができるというのは今や市場価値のある能力である。情報漏洩で思い出したけど、あれなんとかならない？情報管理対象の媒体として「個々人の記憶」を入れるというあれ。どっかの業界団体が作ったガイドラインにあるらしいんだけど、少なくとも作った本人は退職時にロボトミー手術でも受けるつもりなのかねえ（注、性格にはロボトミーではないですが、イメージとして）。なお、私はこれを解決する手段として「日本には忘年会という伝統的行事がある。これを拡充して毎日退社前に会社の金で宴会を開くようにすれば個々人の記憶をある程度消せるのではなかろうか」などと冗談を言ってみた。でも、冗談に聞こえなかった。
そのうち「クイズ係」という職種ができるかもしれん。退室する人間にクイズを出して答えられたら退室を許可するというもの。これも冗談じゃないぞ。申込書に書かれた住所氏名を記憶して、便所から携帯電話でメールすることによって情報を持ち出したという例もあるらしい。これを防ぐには、退室時にクイズを出して短期記憶をリセットするという対策も有効だろう。閑話休題。かくして給与が管理者の仕事をフォローしてくれなくなった以上、別のもので動機付けをしなければならないのは当たり前なんだなあ。まあそれは以前アマチュア意識の浸透で書いたことだけど、今読み返してみるとまだまだ甘かった。
カエサルだって、ナポレオンだって兵士一人一人を激励して歩いたんだから企業のトップもそうしてくれないと、と単純にフォローすればいいのではと思っていたが、よく考えると今のトップは給与がフォローしてくれていたことをやらなくても済んだ人たちなのだった。フォローするなんて考えてこともないに違いない。というわけで運動はもっと下からやらんといけない。そこで参考になるものがる。プロジェクトＸである。正確に言うとプロジェクトＸのタイトルである。プロジェクトＸ自体は、プロジェクトが破綻したか、そもそもプロジェクトのないところで現場のたたき上げががんばって成功したという「アンチ=プロジェクト」の見本であるが、タイトルは名コピー目白押しである。「改札係の人件費を下げろ」が本音だったとしても「通勤ラッシュを退治せよ〜世界初 自動改札機誕生〜」とするから人が動くのだ。実際には土地が足りないから何とかしろ、でも「妻に贈るダイニングキッチン〜勝負は一坪・住宅革命の秘密〜」というと燃えるのである。
このような言い換えの技術が今後重要になるだろう。結構日本人、この辺にだまされるから。
この手のやり方は結局はごまかしだから倫理的にまずいと思っていたのだが、よく考えると皆さんだまされたがっているのかもしれない。給料安いし、仕事もつまらない、でもやらなきゃならないなら、むしろ気持ちよくだましてくれることを願っているのではなかろうか。最近プロジェクト管理ばやりと言うことで私もプロジェクト管理講習に行ったのだが、「どういうメンバーを選ぶか」と問われたところで「やる気がなくても能力のある奴」と当たり前のように言った。能力のない奴はどうしようもないが、やる気なら出させようがあるからというのがその理由。常識では逆らしい。ということは、従来から私は結構人をだまくらかしてきたのかもしれない。
ということで「プロジェクト成功のためには、気持ちよく人をだましましょう」で終われればめでたしめでたしなんだが、プロジェクト管理講習を受けているうちに激しい違和感を感じたのも事実。プロジェクト管理が流行しており、特にシステム開発の分野ではそうなんだろうけど、システム開発にプロジェクト管理の技法をすんなりとは持ち込めないのではなかろうか。というのは「システム開発はプロジェクトではない」から。正確には、システム開発の大部分はプロジェクトの定義から逸脱しているから。
というところで「プロジェクトマネジメント知識体系ガイド（2000年版）」を引っ張り出してくる。プロジェクトを定義して《独自の製品やサービスを創造するために実施される有期的な業務である》としている。単に「人によって実施される」「限られた資源によって制約される」「計画され、実行され、コントロールされる」だけでは定常業務と変わらない。
確かに新しいシステムを構築するのはプロジェクトかもしれない。しかしご存知のとおり、システムのライフサイクル全体でかかる費用のうち、５分の４はメンテナンスにかかる。つまりコストベースで言えばシステム開発がプロジェクトと言えるのは、わずかその５分の１である。シェリンクラップのソフトであれば新しいバージョンを出すのがプロジェクトかもしれない。しかし圧倒的多数を占めるインハウスのシステムは延々と続くメンテナンスを、常設組織により定常業務としてこなしていくだろう、普通は。プロジェクトＸの最終回は、多分「メイキング・オブ・プロジェクトＸ」になり、そこで「テレビ番組を作る」というプロジェクトは終了する。（もちろん番組一本一本を作ること自体がプロジェクトである。）ここにおいてメンテナンスフェーズはまったく別物で、たとえばビデオを保存したり、DVDを発売したり、再放送をしたり、と定常業務になる。そしてこいつらは定常業務であるとともに定型業務である。つまりマニュアル化できる。
ところが開発システムのメンテナンスは定常業務であるが定型業務ではない。かといってプロジェクトでもない。組織的、形式的には定常業務だが、定型的でないという点でプロジェクトっぽいのだ。これは実に扱いにくい。プロジェクトではないが、プロジェクトの定義を半分だけ（「独自の」という点）満たしている。
ここで止まってしまっては書くほうも読むほうもフラストレーションがたまる一方なので、じゃあどこまで妥協すればメンテナンスもプロジェクトと見てよいかだけは考えてみよう。メンテナンスをするのはプロジェクトチームではなく、常設の組織というのは仕方ない。ステークホルダーがいつも一緒というのも仕方ない。この辺が違わないといけないとはプロジェクト管理の教科書には書いていない。
多分次の二つだろう。一つは、プロジェクトチームがプロジェクトを実行中に、ほかのプロジェクトを与えられること。（メンテナンスの必要性は、同時に１つづつやってくるとは限らない。でも別の案件が途中で入ってくることを前提にプロジェクトの計画は作れない。）もう一つは、ステークホルダーが各案件を独立なものとみて交渉に乗ってくれること。ただし、プロジェクトＸのタイトル流にヒューマニズムに訴えて仕事をさせるためにはこれらに加えて次のことが必須である。「プロジェクトが終われば、あとは思い出になるとメンバーが信じてくれていること。」別によい思い出にならなくてもよい。明確なピリオドが打てず、今後延々と付き合い続けると分かっていれば、よほどの画期的なことでない限り（本当に通勤ラッシュを退治するのでない限り）、中々だまされてはくれないものだ。勝負は一坪！の後にすぐ0.8坪のダイニングキッチンを作れとか、電子レンジを置くスペースを捻出しろ！とか言われることが分かっていれば、少なくとも「その分給料上げろ！」とは言われそうである。