新人エンジニアが人月を理解するまで～90年代初頭のシステム開発現場～（前編） • AQZ Tech Chronicles

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

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

新人エンジニアとシステム開発の世界

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

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

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

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

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

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

この真実を、私はのちのち理解することになる。

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

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

そんな世代が還暦になり、ゆとりだのＺだと言ってるんだから、何様だと思ってしまう(笑)

90年代初頭の開発現場

社会人としての学び

会社でかかってきた電話を取るように言われたが、社会人としての電話対応なんて知るはずもない。「電話を取ったら『お世話になっております。』というんだよ」と先輩社員に教えられて、「なんで知らない人にお世話になってますっていうんですか？」と先輩に質問した。とにかく、そういうものだと言われて納得できず、「お世話になっております。」と言えるようになるまで、一週間ほどかかった。

数年後、自分が会社を経営して人を雇うようになった時、若手に同じ質問をされたことは、今でも覚えている。

この会社では社員と全く同じ仕事を担当したので、電話だけでなく、対面での挨拶や報告も学んだ。会社は何も教えてくれないので、客先で私は失敗の連続であった。怒られたり、あきれられたり、指導されたり。結果的に、私は仕事だけはできたので、新人類ということで許してもらったようなものだ。このように技術以外のことも多くを短期間に習得できたことは、私のとって財産であった。

仕事の分類と人月という単位

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

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

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

開発環境との出会い

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

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

unixとMS-DOS

その理由はシンプルだった。T氏はunixを使ったことが無かったので、使いたくなかったのだ。なんせ、ワークステーションのマニュアルを積み上げると2m近くになった。それを読むのが面倒だったのだ。T氏はそのマニュアルを指さして、私に全部読めと言った。私はうずたかく積まれたマニュアルと格闘しながら開発環境を整える。 shellもviも始めて使う。Makefileが動くまで2日かかった。

そういや、T氏はMIFESを使っていたな。当時の日本でMS-DOS向けの人気テキストエディタの一つだった。今でもWindows版が販売されている。思うに、T氏はviを覚えるのが面倒だったのだろう。 T氏は最後までPCのエディタでプログラムを書いて、フロッピーでワークステーションに移していた気がする。そのたびに文字コードを変換していたかな…？なんせPCはShift-JIS、ワークステーションはEUCと、まったく異なる日本語文字コードを使っていたためだった。

開発業務

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

納品前に、私はソースプログラムからフローチャートを手書きで起こすことになった。発注主である電機メーカーから、フローチャート専用定規をもらったことを思い出す。便利だったなあ。

プログラムからフローチャートを起こすなんて逆順の作業は、不毛と思われるだろう。会社でもそんな反応だった。それでも、私はこの作業が嫌いではなかった。自分が書いたプログラムを改めて見つめなおすことにより、数々の発見もあったからだ。バグも見つけて焦った気もする…かな…人間は忘れる動物であると誰かが言っていた。

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

（続く）