  |
PGは、まず見積もりを依頼されます。この時ほとんどの場合、要求仕様書が無いか、あっても伝聞で情報が欠落もしくはエラーを起こしています。残念ながらエラー訂正機構は装備されていません。CRC、せめてパリティでも入っていればちょっとは違うかもしれません。期待出来ませんが。
ここでプロジェクトマネージャー（又は管理者・経営者等。以後PMと称する）から「最速でやった場合」「割り込みが入らない場合」「君がやった場合」or「部署内で最高ランクのPGがやった場合」「仕様変更が無い場合」という条件が付きます。
底辺PG諸君。ここでこの言葉を額面通りに受け取ってはいけません。
「【最速で】3ヶ月かかります」
と答えたらPMは【普通に】3ヶ月の工程を工程表に書き、見積書に3人月分の金額を書きます。そしてこれは後述する危険と隣り合わせとなります。
この危険を経験したPGは大抵リスクを込みで【黙って】見積もりを伝えます。
しかしPMはお見通しです。「高い」「そんなに時間がかかるわけが無い」と言い、受け付けません。何故なら実はPMの頭の中では既に「3ヶ月」なのです。PMは追い込むために見積もりの詳細を聞いてきます。
ここで素直に「リスク込み」と答えてはいけません。既にPMは前述の前提条件を述べているからです。無下に却下されます。
戦いたいPGかつPMが同じ会社であれば「後学のためにPMの詳細見積もりをお聞かせ下さい」と聞いてみるのも良いでしょう。ただし確実に印象悪化は避けられません。PMが発注元の場合は禁句です。まずキレます。そのまま発注されない事もあるでしょう。発注されなかった事を喜びましょう。
なぜキレるか。それは簡単です。「明確で論理的な理由が無いから」です。理由が無い上に実は既に予算が決まっており、それを超える事は許されません。予算を超えた見積もりはPMがさらに上層部・経営陣から怒られる事を意味するからです。理由が無いから理由をPGに考えさせているのです。PMが仕事をした気にさせるのも底辺PGの役目です。
予算を超えた見積もりはあり得ませんので、答えは「がんばります」しか残りません。しかしPMはそれすらもPGの口から言わせたいのです。でもよく考えて下さい。あなたの脳はオーバークロック出来ますか？
底辺PGが出来る事は、PMやユーザーが分からないように期間と予算を加算するくらいです。
一応、市場原理が働くため、安い方がいいに決まっています。金払いのいいユーザーや元請けってのはあんまり無いです。そして金払いの悪い所ほど後々してやられますので、最初の予算の付け方でどういう所かが大体予測出来ます。
そんなわけで、予算と期間に品質と内容は関わりがありません。もちろん企業の使命として、安くて良い品を、安くても利益を、は追求してしかるべきなのですが、日本の場合質と金額が比例するのは極一部。IT業では基本的に、安くて良い品を出来るだけ高速に、がモットーです。受注しなければ会社がやっていけないのは分かりますが、「安さ」だけしか売り物に出来ない会社は、IT会社として失格でしょう。
かくして、短納期低予算のプロジェクトが組まれるわけです。そのPMの理論からすると、高速バスで東京から新大阪へ行く方が、新幹線のぞみの指定席グリーン車で行くより高く、書留速達の郵便より普通郵便の方が値段が高い、という事になりますが。質、時間、価格の何がIT業と違うんでしょうか。
実のところ発注や作業開始は遅れている事が多く、納期に間に合わせるには発注前に作業を開始せざるを得ない場合が8割ほどです。実はここにも罠が仕掛けられています。
作業に取りかかろうとようやく出てきた仕様書を見ると、見積もり時の時と変わっていたり、追加されていたり、未だに仕様が無い場合がほとんどです。
「こんなものをこんな期間で出来やしない！」と憤慨してはいけません。なぜなら
という答えが返ってくるだけです。PMが見積もらない理由がここです。PMに見積もりを聞いてはいけない理由がここです。これは後々まで効いてきますので注意が必要です。「前提条件と違う」と反論するのは無駄です。PMはそれは忘れています。そもそも考えて発言していないので口が勝手に脊髄反射で言った事であり脳は関知していないのかもしれません。PMにとって最重要な事は「PG自身が言った事」です。そう、工程表にも議事録にも「3ヶ月」という数字のみが記載され、いわゆる「リスク」は何処にも書かれて残っていません。
PMやユーザーは絶対にリスクや前提条件を書き残しません。それがこの業界の伝統ある慣習だからです。
ここで言った言わないの不毛な戦いをしてもいいのですが、確実に査定は最低です。もしプロジェクトから外されたらそれは喜びましょう。
管理者や経営陣等からは「やる前に出来ない言うな。やってから言え」と怒られます。残念ながらこれも真に受けてはいけません。
設計、構築など作業をしている間もどんどん仕様変更・追加は流れ込みます。
PMは工程進捗を把握しているのでは無く、PGが【自ら】工程表や報告書に纏めます。遅延していれば遅延の理由も書き、挽回策があればそれも書きます。しかしPG個人が取れる挽回策などたかがしれています。と言うよりそれが分かっていれば遅延などしません。他の策は既に実行済みなので、挽回策には「残業・休日出勤」くらいしか書く事が残りません。しかしこれは現実にこれしか書く必要がありません。なぜならPMはこれ以外の挽回策は理解不能だからです。
仮に報告をしても「早すぎる。もっとやってみてから」「がんばれ」という答えが返ってくる事でしょう。
遅れを放置するPMもいますが、許容範囲はPMにもよりますがある程度遅れが見えてくるとPMから追求がやってくるようになります。
「なぜこんなになるまで報告しなかった」
そう、報告出来る時期というのは非常に限られています。多分プロジェクト工程（今の例なら3ヶ月）の中の30分くらいです。それより早いと相手にされず、それよりも遅いと怒られます。報告時期を見誤らないのもPG業の技です。
実装が難しかったり、無理難題は多々あり、その上工程が遅延しているので、相談をしに行きます。しかし、それは無駄です。
「自分で考えろ」
「やってから言ってるんじゃねぇ。やる前に言え」
他似たような答えしか返ってきません。非常に非生産的です。理不尽です。時間の無駄と考え報告・相談に行かないPGも多いとか。非生産的ですが、一応相談はしておきましょう。ただし時間は取られないように。
同僚やチーム員に相談してもいいのですが、昨今のプロジェクトは人員がスタンドアロンで動いています。したがって、隣の人やチーム員がが何をやっているのか知らない事が非常に多く、相談出来ない事も多いのです。PGにメンタル病が多いのは実は理由がここにあると自分は思っています。孤立感が半端無いのです。まぁ、元を追えば、そいういうチームを組む事、教育訓練しない事など、実は管理者・経営者が「カイゼン」や「効率向上」を題目に目の前の超短期的コスト削減だけを考えている結果なので、PGとしては何も出来る事はありません。管理者・経営者は中長期について考える必要が無いからです。なぜなら「その頃には自分は満額の退職金を貰って定年退職済み」だから。
実のところ単独の仕事をしていればいい、と言う事はあり得ません。同じプロジェクトの中からも割り込みや、他のプロジェクト・部からも割り込みは多々入ります。
始めに言ったじゃん。どうにかして。というのは無駄です。覚えてないし、「会社員なら当たり前だ」という答えが返ってくるだけです。「15分だけ」「ちょっとだけ」が頻発しますが、塵も積もればなんとやら、です。ちなみにこの件は査定・人事評価には全く影響がありません。
相談すれば「午前中はこの仕事、午後はこの仕事、定時後はこの仕事をすれば並列同時が可能だ」とあたかも新発見超名案を出したかのように返されるのが落ちです。そう、1日が24時間しかない事は忘れ去られ、PGが人間である事は忘れ去られ、思考の分断は効率を激しく低下させる事を知らないのです。
ここで断る勇気を持つのが大事ですが、職場内の雰囲気は格段に悪化します。評価は「人でなし」「自分勝手」「自分本位」「冷たい」。これらの視線に耐えられるのなら断りましょう。こちらからすれば「自分の時間を奪う方がよっぽど人でなしだ」と言い返したい気分です。
テスト工程も始まり、遅延が激しくなる上に、バグが発見されさらに遅延という状況が始まります。
ソフトウェアである以上、バグが無いプログラムなんてのはあり得ないのでバグを出す事自体は不可避です。
ところがPMは激しく怒り出します。バグの発見はPMに一報が行きPMが怒られるからです。
底辺PGはバグを出す毎にこっぴどく怒られます。中には仕様変更の事実がPGまで伝わっていないのにバグ扱いされる事も多々あります。
バグを出すと修正、テスト、再発防止策の考案などの厄介事が増えます。
再発防止策は通常「どうやったら自動的にそうならないか」を考えますが、あまりに根幹すぎるので、底辺PGの身分では権限が無く、出来る事が限られます。そしてPMが理解出来る策を考えねばなりません。結果「テストを増やす」「チェックシートを作る」とかになりがちです。しまいには「チェックシートのチェックシートを作る」などという意味不明の現象に陥ったプロジェクトを何度も見ています。
厳しく、それは厳しく怒られる上に、チームの前でさらし者にされる事、人格を否定される事も多々あるので、PGはバグを出さないように、見つけても出来るだけ極秘裏に解決しようとします。
「恐怖駆動型開発」
というもので、日本の場合ほとんどがこの開発手法をとられていると聞きます。この開発手法は書籍になっておらず、書籍としてよく売られているのはアジャイルな開発手法の本が多いです。知識として持っているのはいいと思いますが、役に立たないと思いますねぇ、恐怖駆動型開発の前には。まわりの人間も恐怖に巻き込まれないようにするため、どんどんスタンドアロン化が加速します。
その上、バグを隠すようになり、バグが出るようなテストを避けるようになるため、短期的に収束しているようにみえます。だから効果絶大と見るようです。リリースしてからが楽しみですね。
PMが空想から覚め、もう救いようが無くなった事が事実と認識出来るようになった時、ようやく、2度目の相談・報告時期が訪れます。ただし、PMの第1声は「どうしたらいい？」です。そんな事が分かっているのなら実行済みなので、黙っているしかありません。
するとPMは「何人入れれば良い？」と聞いてきます。意味が分かりません。IT業を労働集約型産業と勘違いしているのが未だに存在している事に驚きです。頭脳集約型の形態に人を入れて解決しようとはどういう脳をしているのか。一度解剖してみたいものです。多分、高校を受験する中学3年生の受験者が100人集まれば旧帝大の入試に合格すると考えているのでしょう。もしくは1Km走というのは1000人が一斉に1m踏み出せば1Km走った事と同じ記録である、と考えているのでしょう。
脳を電通で直結出来れば若干違うかもしれませんが、IT業の1＋1は2では無く、良くて1.5。ましてやこれで増えていくのは3～4人までが限界でそれ以上は人を入れても上がらないどころか、マイナスになる事が常。
PGなら他のプロジェクト、他の部、他の会社に信頼出来るエース級のPGを何人か知っているかと思います。なのでついPMに「エース級を3人」等と提案しがちです。しかしこれは叶わぬ望みです。その提案に対する答えは「そんな事出来るわけないだろ」です。そりゃそうです。予算が無いのだから。
自分の仕事があるのに、何故かこの後から来た人員を纏めるようPMから指示が出ます。PMが指示出来ないからです。破綻は間近です。いや、既に破綻しています。
プログラムが出来上がっていく以上、バグをつぶす速度以上の割合でバグを注入していく事になります。
「混乱しているプロジェクトに人を入れれば、なお混乱するだけ」
という有名な文を実感する事でしょう。なお、実感するのはPGだけであり、PMは実感出来ません。
この辺で思わぬ事態が発覚します。実は発注が遅れていた事です。
発注日以前にドキュメントがあっては監査にひっかかるため、今まで作ったドキュメントを作り直しをしなければならないという、まさに想定外の事態です。ほとんどのドキュメントには作った日付や判子が押されているはずです。それを全部作り直しするのです。納期は間際です。これも納期までに間に合わさねばなりません。
PM（重ねて書くが、プロジェクトマネージャだけでなく管理者や経営者も含む）が発狂し始めます。宛先は底辺PGです。
中には「お前を精神的に追い詰めるしか手がねーんだよ」とストレートに言ってくれるPMもいたりしますが、あまり出会った事は無いですね。
あの手この手で精神的圧迫を始めます。圧迫すれば脳がオーバークロックして作業が進むと考えているからです。残念な事に、脳の別の部位がオーバークロックしてショートしてしまいます。
こういうプロジェクトを経験し、運がいいのか実力なのか、生き残った人達がSEとなり、いずれPMとなっていきます。
不思議な事に日本では、PGが成長してSEに、SEが成長してPMに、とクラスチェンジするものだと考えられている会社が多のですが。
自分としては、座標軸のX,Y,Z軸の様にPG軸とSE軸とPM軸と全く異なるベクトルだと考えています。X軸の先にY軸Z軸があるわけでは無い、と。もちろん、軸に沿っているだけでは無く、他の軸のベクトルも併せ持つのもよいエンジニアでしょうし、ベクトルの方向を伸ばし続けるのもよいエンジニアでしょう。
ところが、クラスチェンジするものだと管理者・経営者は思っているから、給与体系もPG＜SE＜PMとなっていたりします。この時代錯誤的階級社会はどうにかならないものでしょうか。
自分はPMを否定しているわけではありません。いいPMの元でいい仕事をしたい、と思っているだけです。今までに何度かそういう良い経験をした事はあります。それは成功経験としてモチベーションを保つために必要な事なのです。
PG至上主義でもありません。分業形態として、SEやPMは必要不可欠だと思っています。ただ、PGを粗末に扱っておきながら高品質の製品を要求する風習・慣習が納得出来ないだけなのです。
29
