不思議のプロジェクトのアリス ～終わりなき戦い～

職場

» 2009/09/09

　アリスは不思議の国に迷い込んだが、わたしは不思議のプロジェクトに迷い込んだ。

　ここには時計をもったウサギの代わりに、ストップウオッチを持ってメンバーの尻を蹴り上げる禿げたセイウチが君臨しており、イカレた帽子屋の代わりに、混沌のカオスと化したソースコードの沼を管理する青鬼と赤鬼が闊歩していた。

　チェシャ猫は？ ……猫の皮を被った偽善者たちは山ほどいるじゃないか。

　そう、ここは夢の世界？ いや……夢であって欲しいと、何度もただただ天を仰いで祈った。

～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※

「今から、バグだらけのプログラムを、なんとか出荷できる状態にする方法を教える」

　プロジェクト主任は自信満々に言った……。

　今から20年ほど前、わたしはある制御システムの中枢を担当する部署に配属されたばかりの新人だった。

　大学生の時に、ソフトの「ソ」の字くらいはアマチュアの「ア」の字くらいのレベルでかじったことはあった。

　しかし、そこは企業！ 大学生の卒業論文程度のもので、チマチマ作っていたプログラムとはサイズも性能も大違い（当たり前ですけど）。

　当時としては最新鋭（？）のミニコンが隣の部屋の中央監視室に設置され、それにつながるダム端末がずらりとフロア内に配置されていた。ある意味、壮観では……あった。

　期待に胸を膨らませて、社会人デビュー……のはずだったんだけど、“なんか……違う”。

　当時、わたしが所属する課のフロアには20人くらいのSE、プログラマが詰めていた。

　課を治める課長と係長の数人が、部屋の窓側の席に時代物の置物よろしく座っている。

　プロジェクトに編入させられて数日した時のこと、わたしを含む新入社員たちは、部屋の一番隅の通路脇にある会議卓に集合させられ、プロジェクトの先輩たちとともに、プロジェクト主任の訓示（？）を聞かされた。

「今から、バグだらけのプログラムを、なんとか出荷できる状態にする方法を教える」

　何度、聞き直しても、へんな文章だ。

　わたしも学生時代に多少はプログラミングを経験していた。

　そして、プログラムのバグが研究データをねじまげ、意味不明な結果を招くことも知っていた。

　“なんとか出荷できる状態”って？ どうするの？

　すでに出荷時期は迫ってきている。でも、ほとんどプログラムはできておらず、できている部分もバグだらけで使い物にならない。

　あとがない納期。人員は増やせない（配属された新人以外は）。品質は最悪。

　そんな状態で、

　「なんとか出荷できる状態」

が簡単ではないことは、よ～く分かっている。

　でも、人間は極限状態になると、いとも簡単に迷信や虚言を信じてしまうのである。

　今がそんな状態にあった。

　主任曰く、「人間には、やらなきゃならない時ってもんがある」。

　まあ、その言葉の意味も分からなくはないですけど……。

　主任は語りはじめた。

●方法その1：

　「休まず働け」

　つまり、飯を食う、用を足す、寝る、以外の時間は“働け”ってことである。

　我々は当時、“新人類”なんて呼ばれていたから、寝なくても仕事できるだろう、って思われていたのかも。

　また、“贅沢は敵”らしい。

　風呂に入るなんていうのも贅沢。風呂に入るなぞ上級管理職の方々に許された特権以外の何物でもない。事実、我々新人は全員独身寮に住んでいる。我々が帰宅できる（そう、幸運にも）時間帯には風呂なんて運営されていないのだった。

　睡眠も極力削られた。

　事実上、ないと言ってもよい。

　寝て良いのは、プログラムのコンパイル（ソースコードから中間コードに変換する作業）やリンク（中間コードを実行モジュールに変換する作業）の時間くらいだった。

　せめてもの救いは、コンパイルやリンクの時間が、現在に比べて異常に長いことだった。コンパイルとリンクで数時間（大体3～6時間かな）は必要だった。

　現在であれば、睡眠不足がどれほど作業効率を落とすか、なんて論文が簡単に手に入る。っていうかWebで閲覧できる。

　しかし、当時はWebなんてものはなかったし、コンピュータ関連の書籍もテクニカルなものが多く（っていうか、そういうのを買ってくる）、品質や作業環境に関する書籍はなかった（っていうか、買ってこない）。

　なので、結局プロジェクト主任の主観が、我がプロジェクト世界を牛耳ることになる。

　まあ、不思議のプロジェクト（世界）に紛れ込んでしまったってことだろう。

　ここではすべてが異常。

　世間の常識は非常識。

　すべては悪魔のスケジュール次第ってことだ。

　わたしが得た教訓：「半死半生っていう状態は……存在する」

●方法その2：

　「頭は使うな、身体を動かせ、気合を入れろ！」

　考えたって仕方ない、身体で（それも気合を入れて）プログラムを作れってことらしい。

　頭を使う奴は文句ばっかり言って使いにくい。頭はいらないから体力がある奴がほしい、ってことだったんだと思う。

　事実、わたしたちよりも後から採用される新人たちは皆、体育会系ばかり。体力だけはふんだんにありました（最初だけはね）。

　わたしは初めて、プログラミングが肉体労働だと知った（実際には違うけど、当時はそうだった）。脳みそが筋肉になるのではないかと思うほどの、そんなハードワーク。睡眠時間が極端に減っているので、「考えよう」って思っても無理なところはあった。メンバーは皆、酩酊に近い状態で仕事をすることを強制されていた。

　そして、“気合”である。

　うだうだ作業をしていると、管理者たちから“たるんでる！ 顔を洗って来い！”って叱咤されたものだ。

　一瞬その時は気合が入っても、もともと完全放電状態の蓄電池である。そんな充電などすぐに放電されてしまって、わたしの身体に留まらなかった。

　わたしが得た教訓：「脳みそを筋肉に変えることはできない」

●方法その3：

　「バグは絶対に作るな！」

　これは方法っていうよりも指示であった。

　できればバグなんて作りたくないよ。当時の考えでは、バグのないソフトウェアを作ることが可能だったらしい。そう……プロジェクトの建前としては。

　仕事をする中で、一番辛いのはこれだったかもしれない。バグを作りこむと、あらゆる罵詈雑言を浴びせられた。上司は直接言ってくる。先輩は言葉を変えて遠まわしに言ってくる。同僚は聞こえないように影で言う。「お前、脳みそ腐っているのか！」なんて言われたなあ（頭を使ってないから、もしかしたら、本当に腐っていたのかも）。

　「数時間が無駄になった。この責任はどう取ってくれる？」

　管理者に責任を取れって言われても、どうすればいいんでしょうねぇ？ クビにしてくれますか？

　「なんでバグを作るんだ？ え！？」

って詰め寄られても、すいません、って言うしかないじゃないですか。今の言葉で言えば“パワハラ”ですかね。あー、当時はそんなの普通でしたから。

　わたしが得た教訓：「バグはわたしが作ってるんじゃない。もう1人の“わたし”が作るんです」

●方法その4：

　「仕様書を書いたり直したりする暇があったら、コードを書け！」

　わたしのプロジェクトには、外部から雇われて一緒に作業をしてくれるスーパーな協力会社の方がたくさんいました。

　彼らはソフトウェアをよく知りつくしていて、ドキュメントなしにはプログラムは書けない（物理的にではなく、プロジェクト運営において）ってことを知っていました。

　しかし、悲しいことに、彼らは雇われ人だったのです。

　わたしのプロジェクトのプロジェクト主任は、そんな進言をまったく聞かず、逆に進言をしてくれた人を叱咤して黙らせる始末。そうして、いい加減な仕様書をベースに、どんどんと乖離していくソースコードの山々。悲しい赤鬼と青鬼は、それらを管理していくのでした。

　今も「俺たちはアジャイル開発をしているから、ドキュメントなんて書かないよぉ～」っていう勘違い野郎はたくさんいます。

　「ドキュメントを書かない」＝「アジャイル開発」ではありません。

　ドキュメントを書いても使わない、使われないから、段々とドキュメントを書くことの意味が薄れていっているように思います。

　わたしが得た教訓：「ドキュメントとソースは犬猿の仲」

●方法その5：

　「コードを書いたら、テストで直せ」

　ある意味、プリミティブな表現であり、間違いではない。

　しかし、テストのレベル移行が極端であり、単体テストや結合テストをする時間がないので、皆、一気にシステムテストに突入していた。

　方法その3が達成されていれば、そもそもソースにバグはないはずなので、ユーザー視点のシステムテストのみでOK～♪ なはずだ。

　テストチームなんてカッコいいチームはいるはずもなく、開発者がそのままシステムテストを行う。そしてもちろん、テスト炎上～。

　そこにはありとあらゆる欠陥が詰め込めるだけ詰め込まれているのだから、そのすべてが一体となった巨大な障害として噴出していた。

　インターフェイスの欠陥は致命的だった。ドキュメントがないので、ソースからインターフェイスをチェックする。あちこちで食い違う。その場で直す。するとまったく別のところでまた食い違う。そしてそこも直す……。

　よく悲惨なソースコードを“スパゲッティ状態”のソースコードっていう表現をしてますが、そんなものはまだ甘いな。

　こいつは、そんなもんじゃない。スパゲッティをミキサーに入れて攪拌（かくはん）したようなもんだから、もう、ジュースですね。“解く”なんてことは無理！

　完璧に破壊されてしまったコードは、どう直しても破壊されてしまっているので、やはり動作しません。

　完全に動作しないのはまだましです。“ある程度動く”から、たちが悪いのです。

　そこで担当者はどうするか、ですけど。

　そう、その部分をそっくり捨てて、また作ってしまうんですね。

　でも、そのほうが早かったですね。最終的には。これも後から分かるんですけど。

　「テストしてから“作る”」って表現がいいでしょう。

　あ！ いま流行のテスト駆動ではないですよ、念のため。

　わたしが得た教訓：「動作しないコードは捨てるに限る」

●方法その6：

　「神風は吹く」

　ここまで来ると、方法でも何でもないです。ただ、“奇跡が起きるのを待て”ってことらしい。

　信じていれば、誰か（人間でなくてもOK）が助けてくれるようです(笑）。

　要は“希望を捨てるな”ってことなんですけど。希望を破壊しまくっている本人から言われると滑稽以外の何物でもないです。

　寝ている間に魔法の小人がたくさん湧いてきて、動作する完璧なソースコードとモジュール、それから非の打ち所のない完璧なドキュメントを書いてくれる夢を、何度となく見た（願望が出るもんですね）。それか、一寸法師が鬼の中に入って、プログラムのバグを退治してくれる、とか。

　どれもこれも非現実的であったけど、プロジェクト主任は「信じればできる」が信条だった。それはそれで素晴らしい信条ですけど、悲しく響きます。

　プロジェクトのメンバーが何人も戦線離脱している状況にあって、プロジェクト主任だけは元気だった。

　もしかして悪魔と契約していたか、プロジェクトの他のメンバーの生気を吸い取っていたのかもしれない。

　わたしが得た教訓：「神様の巡回経路に入っていない場所も、ある」

～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※

　いかがですか？ 皆さん。

　こんなプロジェクト、ありそうですね。

　戦いはまだまだ続く～。