新人エンジニアが人月を理解するまで（前編）：90年代初頭の開発現場

今さら「人月相場」を私が語るのもどうかと思う。これは日経ビジネスを始め、著名なメディアが昔から取り上げてきた話題だ。著名なものでは1975年にフレッド・ブルックスが出版した「人月の神話」が、今でも通用する。それだけ、システム開発の難しさが根深いということだろう。個人的には、若いときに読んだトム・デマルコとティモシー・リスターによる「ピープルウェア」が印象に残っている。これもまた、現代でも通用する素晴らしい作品だ。若手エンジニアには、ぜひ読んでほしい。

しかし、私が体験したことを記録することも、後世に伝えることでもしかしたら何かの役に立つのかもしれない。

Z-80アセンブラとの出会い

私がIT業界に入ったのは、Z-80アセンブラの仕事が最初だった。このときは、社長と私の二人だけの小さな会社だった。私はアルバイトで、仕事もプログラミングだけだった。

中学生のとき、レポート用紙に書いたプログラムを、コード表を見ながらハンドアセンブルして、MONコマンドで打ち込んでは、暴走した。そんな経験しか持たない私に「マクロアセンブラ」は衝撃的だった。アセンブラなのに変数名が使える。自分でラベルを管理しなくていい。それが、職業プログラミングの世界だと知った。

結局、この仕事はぽしゃって、バイト代も一部しかもらえなかった。山間部に設置する通信用アンテナ設備の制御プログラムだったが、プロジェクトが白紙になり、元請けから切られたようだった。あの時の社長の表情が忘れられない。アルバイトは1か月で終わった。

UNIXワークステーションの世界へ

その1年後、大学の休学中に中小企業のシステム開発会社でアルバイトとして採用された。アルバイト情報誌には、その会社のオフィスが都内数か所にわたっており、住んでいたところからも近い場所が書いてあったので応募した。この真実を、私はのちのち理解することになる。

会社で担当を任されたのは、とある電機メーカーが開発する大規模システムの機能の一つだった。開発環境はUNIXワークステーション、C言語に独自のUIシステム。

アルバイトを通して、この会社で身に着けたことは社会人としてのマナーやIT業界の慣習だった。まだ学生だった私は本当に何も知らなかった。メディアは私の世代を「新人類」と呼んでいた。それくらい一般常識が通じないと嘆かれた世代だった。今では「バブル世代」と呼ばれて、下の世代から冷ややかな目で見られている。そんな世代が還暦になり、ゆとりだのＺだと言ってるんだから、何様だと思ってしまう。

電話を取ったら「お世話になっております」と言うことすら知らなかった。「なんで知らない人にお世話になってますっていうんですか？」と先輩に質問し、言えるようになるまで一週間ほどかかった。数年後、自分が会社を経営して人を雇うようになった時、若手に同じ質問をされた。

手探りの開発環境

仕事を始めて1カ月もすると、社内の様子や仕事のことが少しずつ分かってきた。最初に戸惑ったのが「人月」という単位だった。これを理解するには、まず仕事の分類を知る必要があった。

• 仕事は大きく派遣と受託に分かれていた
• 派遣の仕事は勘定系、受託の案件は制御系と呼ばれていた
• 勘定系はCOBOLもしくはPL/I、制御系はC言語だった
• 勘定系は汎用機、制御系はワークステーションでの作業だった

アルバイト情報誌に書いてあった勤務先は、オフィスではなく派遣先だったのだ。事務所は1か所しかない。私は受託開発だったので、事務所に出勤していた。

これまで私は主にパソコンとポケコンでプログラミングしていた。たまに大学の端末で汎用機を使っていたが、それもFORTRANがメインだ。それが仕事ではワークステーションでC言語、しかもあこがれのUNIXだった。

この案件は先輩エンジニアのT氏が一人で担当していた。それを手伝うのが私の仕事だった。しかしT氏は頑なにワークステーションを拒み、自分のPCで作業していた。MS-DOS+MS-CとUNIX+Cでは互換性がほとんどないのに、仕事になるんかいな、と不思議に思ったものだ。

その理由はシンプルだった。T氏はUNIXを使ったことがなかったので、使いたくなかったのだ。なんせ、ワークステーションのマニュアルを積み上げると2m近くになった。T氏はそのマニュアルを指さして、私に全部読めと言った。私はうずたかく積まれたマニュアルと格闘しながら開発環境を整える。shellもviも初めて使う。Makefileが動くまで2日かかった。T氏はMIFESを使っていた。当時のMS-DOS向け人気テキストエディタだ。T氏は最後までPCのエディタでプログラムを書いて、フロッピーでワークステーションに移していた。そのたびに文字コードを変換していたかな…なんせPCはShift-JIS、ワークステーションはEUCと、まったく異なる日本語文字コードを使っていたためだった。

私の仕事は渡された機能設計書通りにプログラムを作成し、デバッグすることだった。本来は機能設計書から詳細設計書を作成し、それをコーディングするのだと後で知った。詳細設計書の正体はフローチャートだった。

納品前に、私はソースプログラムからフローチャートを手書きで起こすことになった。発注主である電機メーカーから、フローチャート専用定規をもらったことを思い出す。プログラムからフローチャートを起こすなんて逆順の作業は、不毛と思われるだろう。会社でもそんな反応だった。それでも、私はこの作業が嫌いではなかった。自分が書いたプログラムを改めて見つめなおすことにより、数々の発見もあったからだ。

この経験は、後に思わぬ展開をもたらした。この作業がなければ、私がコードからフローチャートを生成するツールを開発することはなかったかもしれない。これによって詳細設計の生産性が飛躍的に向上したのだ。

（後編へ続く）