恐怖！タスクオーバーラン
タイトルの後ろに「男」とかつけると途端に胡散臭くなるな。
初手から何を言ってるか俺は。年齢層限られるし。
さてさて、いつの間にやら無職モンから再就職果たしまして早９ヶ月が経過しました。月日が経つってのはえれぇ早いもんでして。しかしながら現在の雇用契約がいつまで続くか、の部分に関しては早くも暗雲が立ち込めてる部分があったりしますから微妙なもんです。早過ぎるぞ＞俺。
ただね。ちょいと今回事情が違うのは、自分が辞めるより先に周りが壊れるんじゃねぇのか？という気がしててしょうがないんですな。
なにせ皆が皆忙し過ぎます。昼夜関係なし土日関係なし、１ヶ月で３日しか休んでません後は全部仕事してます、そんな人すらいたりしますから。個体差こそあれ人間の体って意外と丈夫にできてるんだなぁと感心なんかもしちゃったりなんかして。
そうじゃなくって。
こんな生活してたんじゃその内死人が出るぞ、ということでさすがに最近「なぜこうなっちゃったのか？」なんてことも雑談交じりに議論したりしてるのですが。
プロジェクト、と言いますと大抵の場合はどこぞのユーザ企業に常駐してモノ作って・・・というのを想定するのですが。中には中小零細のソフト会社で、自社の机に座って一人でモノ作る・・・ということもあったりする訳です。それこそ人月換算で２人月とか0.5人月とかの小規模なものを細々と作って生計を立てると。今回取り上げるのはこの後者の方です。イコール私の職場ということになるのですが。わはははは。
それはさておき。
この２つ、単に規模だけの問題かと思いきや、意外にも仕事のやり方としては大きな違いが存在します。それは「専任か兼任か」の考え方。
自分の見聞き限り、規模が大きいところではやはり専任＝そのプロジェクトにつきっきりということが多いようです。無論そうでない場合もありますが、やはりこれをやると通常作業者が潰れますので「できるならやらない方がいい」位の考えはマネジメント層とかにも案外認知されていたりします。
ですが小規模の場合これが逆になるみたいで。要は「仕事抱えてナンボ」と。規模小さい分稼ぎ少ないんだから数こなせ。そんな論理が働くからなんでしょうか、ポンポンと作業を入れてくる。まぁ中には組織の規模は大きくなおかつ「仕事抱えてナンボ」の価値観、なところも結構な頻度で存在するようですが・・・ご愁傷様です。過労死には気を付けて。
で、この辺で意識の隔離が生じてるのが現在の泥沼に繋がってるのかな、てのが私なりの勝手な妄想なんですな。ちなみに言いますとこの件に関しては経営サイドに噛み付き済です。えぇピープルウェア信者ですから（p.178を見れ）。でも返ってきた返事は「うちはそうゆう方針だから。複数こなせる人をうちは評価します」とつれないもんでした。「じゃあ評価されなくていいので複数回すな」と返した自分は我ながら鬼だと思いますが。開き直るなそんなことで。
まぁただ問題は既に自分一人でなんとか解決できるレベルではないと思うんですな。という訳でここはひとつ冷静に現状を確認してみようかと。
まずお互いはこうゆう認識をもってると思うんです。
振られた人：
「仕事終わってないのに次の仕事振るなタコが！どれもこれもできる訳がねぇだろちったぁ考えろボケ！」振る人：
「プロジェクト間の日程調整はこっちでやってんだろうがロクデナシ！ できねぇのはテメェが馬鹿だからだろうが恥を知れ能無し！」
これのどこが冷静やねんという説もありますが。
まぁホンネはこんなところだろうと思ってます。受ける側が「こなせなくて当たり前」と思ってることを、出す側は「こなせて当たり前」と考えてる。このズレが原因なんですよね、おそらく。
私自身は「相手のキャパを理解せず振るほうが悪い」と個人的に思ってはいると思うんですけど、その一方で「なんで向こうがこなせないのか理解できない」という側面も確かにあると思うんですな。要はなぜ受け側がパンクするのかの説明ができてないと。
じゃあちょっとやってみますかね。双方の考え方の違い。
おそらく仕事振る側は、ひとつのプロジェクトに対する作業量に対して、無意識のうちにこんなグラフを思い浮かべると思います。
フリーハンドで30秒で書きました（笑）。横軸が時間の経過。縦軸が想定している作業量です。キックオフからリリースまでの作業量は大、その後保守作業に入るに従いゆるやかな下降線を描く。その後ゼロになることもないけど作業量が膨大になることもありゃしないだろう。つまり、
こんな感じでプロジェクトを重ねれば爆発するようなことはなかろう。こうゆう考えをするはずなんですな。確かにこれはこれで当たってる側面もありますし、おおざっぱに把握するのであればこれでも充分なんですけど。
実はこの図、振られる側からすれば壊滅的に間違ってます。とある前提が抜けてます。はいそれじゃ問題。その前提とは何でしょう？
ってこうやって行数稼ぐのヤメロよ＞俺。
正解は「タスクは重ねられません」ということ。２つのグラフで重複している部分ってのが抜け落ちてしまうんですね。で、さらに言うなら時間と作業量の２軸だけではこの限界ってのはまったく考慮されておりません。
という訳でちょいと書き方を変えてみましょうか。降られる側から見た作業に対する考え方。
ちょっと書き方を変えてみて。縦軸を１列１週間、横軸を日（７日分）として、タスクそのものはそこに置かれるブロックとして表現してみました。まぁリリース前には休出とかもありえるからこのあたりが妥当かなと。ちょうどテトリスで下から埋めていくイメージで見ればいいんでないかと。
これだけを見るなら縦横の基準こそ変化しつつも、図としては上の線グラフとそう違いは無いということにお気づきかと思います。でもこの図に２つ３つとタスクを積み重ねていきますと、ショッキングな数字が出てきます。
はーいそこ目を背けないー。見なかったフリしないー。
これが現実でーす。
プロジェクトひとつひとつで見れば適性値であっても、これが重なることでこんなもんあっちゅー間に突破しちまうんですな。
でさらに現実突き出しますが、泣こうがわめこうが怒り狂おうが包丁片手に脅そうが、１週間は７日です。絶対に８日９日にはなりません。
これ見ると２箇所ばかしその臨界点も突破してるのがありますよね？
これを個人的にバッファオーバーランに倣って「タスクオーバーラン」と呼んでます。あくまで勝手に言ってるだけですのでどこにも許可は取ってません。当たり前だ＞俺。
これがプロジェクト重ねれば重ねただけ、頻発するってこともここまで言えばよーくお分かりですよね？
うちの職場に関して言えば「重ねて当然」を繰り返してきた結果が今の惨状ですわ。そりゃ人潰れるっつーねん・・・。
・・・・・・え？反論がある？言われっぱなしで黙ってられるか？んじゃどーぞ。
はぁ。だったらそれをこうさせる、このように整えるのが作業者の責務だということですか。あ、図も書き直した？どれどれご拝見。
はぁ。なるほどねぇ。実際にもいそうですな、こうやれと堂々と主張する御仁が。
いっぺん死んでこい馬鹿。
つーかそんなことできるヤツなんざ世界探したっていねーよ阿呆。そんなことできんのは全知全能かつ予知能力取得済みの神だけじゃ。
こっからいつも通りの言い分になるけどね。事前にすべての工程を算出するなんて１００％不可能なんだから。必ず誤差が出る。どこかで想定しなかったパターンがひょいと顔を出す。だからこそのソフトウェア開発な訳でしょ？それでもこれを吸収して（品質的にも人間的にも）妥当なラインを模索していきましょうってのをやっていかなきゃならんわけでしょ？
これとまったく同じことをデマルコたんが主張してますわ。きつきつのところに業務押し込めたところで、すべての業務が遅れるのがオチだっつーの。それこそテトリスと同じだって。はじめから落ちてくるコマがわかってんなら誰も苦労せんわ。
さらに言えばプロジェクトひとつでさえも予測不能なタスクが降ってかかってくる訳なんですから。複数になればどうなるよ？条件悪くなる一方で共倒れだぜ？
・・・双方の主張並べるつもりがいつの間にか開発側の一方的な主張になっちまいましたが。まぁいいかいつものことだし。こらこら。
でも実際問題として、１週間を８日９日にするなんざ天地がひっくりかえったって無理だってのは幼稚園児にもわかることですので。その前提の中でどうやって対処していかなきゃいけないか、というのは全員が考えていかなきゃいけない訳で。
もちろん手法は既にありますわな。XPの開発ゲームなんかはまさにそうですわね。決めるのは１イテレーションの詳細スケジュールのみ。次のイテレーションのスケジュールはそれが完了してから改めて考える、のサイクルでまわしていくやりかた。
デマルコ提唱（でいいのか？）のプロジェクト単位の優先順位付け＆最優先順位への人的コスト最大投入も十分に機能するでしょう。
あとは手前味噌かもしれんけど、上の積木積み立て方式でスケジュール管理してみるのも手かもしれんよ？これでは現状しか把握できないという説もあるけど、それでも少なくとも日単位の線表よかはわかりやすいよーな気がしないでもない。
まぁどれ取るかはお任せしますけど（最後の最後で責任放棄（笑））。残業休出でバカみたいに命削って体力勝負ってのはいい加減ヤメにしよーぜ本当に。それでなくてももう既に取り返しつかない位にデカい時間をドブに捨てちまってんだからさ。
♪よーく考えよー。時間は大事だよー。
お粗末。