説明が面倒臭いんで、今の忙しさを「デスマ」ってことにしてるんだけど、正確にはこれはデスマなんかじゃない。

私が考えるデスマとは、

工程が破綻した結果、
着地点がわからなくなったもの

を言うのだ。「破綻」というのは本当に破綻で、納期を踏み抜いたという程度のものは破綻とは言わない。それは単なる「遅延」であって破綻じゃない。

じゃあ、「破綻」したとはどんな状態かと言えば、「起きなくていい、起きてはいけない工程の逆流が起きた状態」だ。たとえば、遅延の結果、全く新しい火消しプロジェクトを起こす結果になったとか、「どうせ遅れてるんだから」と仕様が増えてまた設計が始まるとか、そんなものだ。

前者のわかりやすい例で言えば、稼動日に完全に切り換えられるという前提でプロジェクトが始まったのに、稼動日が守れなくなった。そのために、旧システムと新システムの平行稼動をする羽目になり、日時でデータ移行させたり、更新を反映させるオンラインを追加したりが必要になって、その設計が始まったとかいうようなこと。本物のデスマを経験したことがある人なら、身に覚えがあるんじゃないかと思う。

後者の例で言えば、たいていは顧客の担当者が優しい人で、開発工数が越えた分を補填してくれるということになって、「単にカットオーバーが遅れるのもマズいんで、仕様が増えたということにしましょう」とか口実を作ってくれると起きる。後から、しかもスケジュールがタイトになっているところに仕様が追加されるのだから、ますます遅延に拍車がかかるし、既に出来ている部分に仕様変更が発生してしまう。仕様追加はお互いに良い言い訳になってくれるのだけどそれが死亡フラグだ。ますますプロジェクトが迷走し遅延に拍車がかかる。当初の登場人物に悪人がいないところ、むしろ善人ばかりだというところが、よけい悲惨さを増す。これもデスマの時の営業やチーフクラスの経験者なら身に覚えがあるんじゃないかと思う。

開発中にチマチマと仕様追加されたのは遅延の原因になるし、その言い訳にもなるけれど、それ自体はデスマの原因にはならない。たいていは小手先の変更であって、再設計が必要ではないからだ。運命の分かれ目は工程の逆流にある。アジャイル開発であっても、他モジュールに影響を与えるようになったらマズい。

この他に当初の仕様にトンデモが含まれていて、稼動が近付いた時にそれが表面化して再設計とか、様々な理由でコードの品質が期待した程ではなかったため、上流差し戻しが起きたとか、そういった類もある。

例は他にもいろいろあるけれど、共通するのは

遅延しながら、遅延以上の問題が起きる

ということだ。だから、プロジェクトが単に遅延しているだけなら、それは時間がなくなって大変になったというだけで、デスマにはなってない。プロジェクトの着地点が変更されてないんだから、頑張って一歩づつ歩んで行けば、必ず終わる。まぁ時間や資金がそれを許さないことは往々としてあるので、デスマじゃないから失敗じゃないと言えばそうではないが。

で、今回私の経験してるのは、今のところ単なる作業遅延だ。私が気合を入れて書けば4日で片付くことに(実際片付いた)、3ヶ月かけても出来なかった奴が逃亡したせいで、その分の仕事がどっと来ただけのこと。

この世界、出来る奴と出来ない奴の生産性の違いは桁がいくつも違うという類の論調をよく聞く。「高度なプログラム」の場合、それは正しい。あるいはトンチを利かせればとっとと片付く類のこともある。たとえば、「Cコンパイラが必要」みたいなプロジェクトの時、コンパイラを作らなきゃいけないなら、凡ジニアなら100年かかっても無理だろうし、作れる奴なら数ヶ月の仕事だし、作った経験のある奴ならほとんどコピペで3日くらいで出来るかも知れない。トンチの利く奴ならライセンス的に問題のないものをパクって来て半日で終わるかも知れない。文字通り桁がいくつも違う。

ところが、システム開発にありがちの「顧客の業務にベタベタに依存したデータ項目をデータベースにつっこんだり表示したり」みたいなものになると、そういった差はつきにくい。キーを打つのが速いとか、手抜きツールの類があるとかでいくらか違いは出るけれど、せいぜい数倍の違いでしかない。「○○なら高速で開発出来る」の類はよく聞くけれど、それは単純にコードを書くのに必要な時間が節約出来るだけであって、設計や項目名を決める時間が節約出来るわけじゃない。

今回の仕事はこっちの「差がつきにくい」に属するものだ。実際「4日」の間の一番大きかった作業は「元々の設計書にあったローマ字の項目名が気に入らないから英辞郎引いてた」とか、「紙芝居」として作られたHTMLを自前テンプレートに書き換える作業とか、そんなことがほとんどだ。面倒臭いけど誰であってもコツコツとやって行かなきゃいけないから、生産性の差はつきにくい。

「ローマ字」は、確かに読めればすぐわかっていいんだけど、そもそも読みにくい上に、表記がゆらぎやすくそれは「流儀」ということになってしまうのが面倒臭いから嫌いだ。英語の方が白黒はっきりしてくれていい。「桁」を「digit」と決めようが「order」と決めようが、どっちに決めたかだけの問題でしかないけれど、「disit」と綴れば間違いだ。ローマ字な項目名な文化だと「施設」を「sisetu」と綴るのも「shisetu」と綴るのも「shisetsu」と綴るのも、流儀の違いでしかないからいろいろ面倒臭い。多少意味がアレでも「facilities」ってことに決めちゃえば、一度覚えれば済む。

面倒臭いから「3ヶ月」の間の作業は全部否定して、1行のコードも使わないことにした。「チェックした」と称する設計書も無視した。なぜなら、コードを数ファイルのぞいて

ダメだこりゃ

という結論に達したのと、「逃亡」されてしまったのだから、著作権関係の契約をまるでしてなかったんで、後で面倒なことになることを避けたかったのだ。「僕が苦労したからすぐに出来たんです」とか言われてもシャクだしね。

「引きつぎ資料です」と称してメールで送られて来たファイルは、展開すらしてない。こちとら素人じゃないんだから、コードを数ファイル見たら、読むべきものは全くないってことくらいわかるさ。目を通す時間がもったいないって。

んで、全工程が3ヶ月くらいしかないところを、泣く泣く1ヶ月納期を延ばしてもらって片付けることにした。工期が短くて大変なことは大変なんだけど、作業濃度を高くすりゃ解決可能なんで、実はどうってことはない。

この仕事、「3ヶ月」あればtwitterで馬鹿なことを書きながらでも楽勝で書けてたよなーとか思うんだよね。でも本人ノイローゼになって精神科に逃げ込むくらいテンパってたらしいよ。まぁ、XMLでタグがバランスしてないと読み込めないとかって、テンパってる時に何度もやられるとイラっとするけど、余裕のある時ならたいして気にもならんよね。

PS.

当事者に近しい人でない限り、具体的にどの出来事のことかわからないように書いてたんだが。「この辺を書いちゃいけないな」と思って伏せた部分を「反論」してる人達が書いてちゃいけないと思うんだな。コメントに書いてるように、そこの部分はネットに書く気はないし。

これは単なる「個人的状況(怒り)」と「デスマとは」ってことを書いているに過ぎなくって、誰かを責めるために書いてるわけじゃない。注意深くその辺は避けたつもりなんだけど。部下のことだとも、外注の話だとも言ってないのは、そのため。

PS2.

↑のような観点から、いくつかのコメントとそれに対する私のコメントを非表示にしておきました。件のコメントに書かれたことを「私宛のメール」で送られるのは構わないし、そこに非難の類が含まれるとかってのは構わないんだけど、「私があえて書かないでおいたこと」を公開の場に書かれてしまうのは、当事者にとって好ましいとは思わないので。

いや、それでも公開しとけと言うのであれば、元に戻しますが。