早いものでプログラミングを生業として、今年で３５年になります.
昭和、平成、そして令和の３つの時代をソフトウェアエンジニアとして生きてきました(笑)
現在の令和の世の中では当たり前となってるネットも昭和、そして平成の初期には存在してません. そういえばネットがなくてどうやって仕事していたか、という回顧録です.
けっしてためになる情報ではありません(笑)
4月29日の昭和の日(って知ってました?)にちなんで昭和の時代の話をしたいと思います.
Table of Contents
令和の世の仕事
ご存じの通り現在、仕事するうえでネットワークは欠かせません.
例えば、
- ミーティングや情報共有はMicrosoft Teamsで.
- 仕様書や設計書は共有サーバーに格納.
- ソースは git で管理、共有.
- バグやタスクはチケットベースのグループウェアで管理.
- 勤怠管理や年休はウェブベースのシステムで届け出.
と言う感じでネットは空気のような存在. ネットが無いと何もできないです…
ただ、ネットワーク技術革新とネットワークインフラの拡充で上のような仕事も在宅でこなせるのは、コロナ禍の中での不幸中の幸いです.
昭和、平成初期の世の中では?
当然この頃にはネットおろかPCもあったかどうか怪しいものです.
そんな世の中で仕事はどうやってたんでしょうか？
設計は?
紙と鉛筆で設計、設計書はキングファイルに閉じて保管.
重いキングファイルを何冊も持って客先でレビューなんてこともやりました.
フローチャートも手書き、入社してすぐにこういうの買いました.
一人一台のPCが使えるようになってから、一太郎でドキュメントを印字して紙で客先に納品してました. とにかく「紙」が主体の時代でした.
ですので、机の上はこれに近いものがありました(笑)
プログラミング
さすがに私の時代にはパンチカードを使ってプログラム入力することはなかったです.
プログラミングはPCを使いましたが, WindowsやLinuxなどはあるはずもなく, 最初に使ったPCのOSは CP/M でした. 8bit CPU PCのOSです.
入社して最初に買った技術書がこれ. 「懐かしい」と思った方、いらっしゃいますね(笑)
その当時, 某S〇NYさん(伏字になってないw)のマイクロコンピューターを使ってたので, 開発環境も某S〇NYさんから借用してました.
ディスプレイとデバッグに使う ICE (in-circuit emulator) が一体化してて、デザインもとてもおしゃれなマシンでした. さすが S〇NYさん.
もちろん OS は CP/M で, フロッピー・ディスクを使ってOSを立ち上げます.
アセンブラでプログラムを書いてました. 一人で書いてましたが、一人で全部を見通せるくらいの規模でした、平和な時代です.
画面が小さかったのでコード全体を見渡すためにソースをラインプリンタを使ってLP用紙とか連続帳票と言われる紙に印字してました.
書いたプログラムは個人でフロッピーディスクに格納して管理. . バージョン管理もバックアップも個人まかせ. 今考える恐ろしいですねー.
その後、MS-DOS が動作するPCを使うようになりました. ただ仕事のやりかたは特に変わらず、ソースコードの管理は個人まかせ.
なぜならPCにネットワークというものに一切つながってませんでしたから.
デバッグ
プログラムの規模がもう少し大きくなって外のソフトウェア・ハウスさんといっしょに開発するようになったときの話.
リリースされたソフトにバグがあったとき、手書きのバグ票にバグの内容、発生条件などを埋めて、ソフトハウスさんにFAXで送ってやりとりしてました. 書いたバグ票は先のキングファイルに綴じて管理します.
ソフトハウスさん側ではFAXで送ったバグ票に解析結果を書いてこれまたFAXで送り返してきます. それを最新のバグ状態として先に綴じた古いバグ票を破棄して更新します.
そうやって何度もFAXで送り、送られたバグ票は、しまいには何が書いてあるのかわからない状態となります(笑)
では、ネットが無い時代にバグを直したプログラムをどうやって配布してたのか？
当時開発してたのは組み込み機器用のプログラムでした. ソースコードをビルドした後は, EPROM (Erasable Programmable Read Only Memory) に焼いて機器に装着します.
最初はそのEPROMを物理的に郵送して配布します.
そのEPROMを使ってテストを行い、そこで見つかったバグの修正はパッチ情報を作って、パッチのダンプデータを印字してFAXで送ります.
パッチ情報とは何か？
- バグの原因となった箇所の直前をJUMP命令で既存のプログラム領域の外に一度追い出す.
- 追い出した先で正しい動きをするプログラムを書く.
- その後、バグの原因となった箇所の直後にJUMP命令で戻るようにする.
という変更を行い、元のEPROMの内容を16進数で表示したダンプリストと、上のような対応で修正したプログラムのダンプリストを比較し、その差分をパッチ情報として印字してFAXで送ります.
そのパッチ情報を受け取った側は,
- EPROM ライターでEPROMの中身を読みだし
- EPROMライター上でFAXのパッチ情報に従ってデータを書き換え
- 書き換えたデータを別のEPROMに書き込み
という手順でバグ修正したプログラムを入手します.
当然これで修正できるのは小規模なバグに限られます. パッチで修正できないときはどうするか？
物理的にEPROMを受け取りにソフトハウスさんに出向きます.
それに対して文句を言う人もおらず、のどかな平和な時代でした.
調べものはどうしてた？
Googleなどもちろん当時存在してません. 仕事上わからないことがあったとき,どうするか？
本しかありません.
その中でも技術雑誌は貴重な情報源でした.
当時の雑誌は未だにときたま参考にしていて本棚に鎮座してます.
当時参考にしてた雑誌をいくつか紹介します.
インターフェース
ハードウェア、ハードウェア・ソフトウェア境界、情報理論や通信プロトコルを含むソフトウェア技術など守備範囲が広く、そして結構硬派な記事に惚れこんで長い間定期購読していました.
この雑誌から学んだことは数多し…ホント感謝しております.
一番楽しみにしてたのは祐安重夫のコラム、「いきあたりばったり読書日記」ですね. このコラムのファンは多いと聞いてます.
Cマガジン (ソフトバンク)
特定のプログラミング言語の雑誌が出るなんて当時驚いて即座に定期購読しました.
私はC言語をこの雑誌で学びました. この雑誌に足を向けて眠れません(笑) ホントにお世話になりました.
創刊号にはデニス・リッチー先生のインタビューが載ってます.
Unix Magazine (アスキー)
この雑誌にもホントにお世話になりました. いまだに参考にさせてもらっている記事があるので、処分したくてもできないんです.
今の Linux のプログラミング、特にネットワークプログラミングはこの雑誌で学んだと言っても過言じゃありません.
記事を書いてるのがメーカーやソフトハウスのエンジニア、大学の先生だったりいろんな方がいらっしゃて, 本題に入る前の「まくら」がとても面白いんです.
とくに坂下秀さんの「ワークステーションのおと」とか坂本文さんの「UNIXへの招待」など毎号楽しみに読んでました.
その他いろいろ
定期購読はしてないけど特定の情報が欲しくて書店で買ったり、バックナンバー取り寄せたものもありました.
Computer Today(サイエンス社), bit (共立出版) もその中のひとつです. これらはちょっとアカデミックな内容を取り扱ってました.
bit の電子復刻復刻プロジェクトが開始されたそうで、こちらも楽しみです.
C JOURNAL ビレッジセンター出版. 米国 The C Users Journal, TECH Specialist 提携雑誌で海外の情報を得る貴重な雑誌でした.
とにかく情報は本、雑誌しかなかった時代. 技術出版の業界が元気だった(過去形で書くのは辛い…)時代でした.
勤怠管理、届け出など
もちろん紙ベース.
勤怠管理も紙で、勤務時間の計算も紙に書いて就業時間から始業時間を引いて残業時間を手計算でやってましたが、これがまた計算ミスが多くて…
そのうちMS-DOS上で残業時間を計算する awk スクリプトを書いて計算するようにしました.
当然のことながら, 年末調整の書類、休暇の届もすべて手書き.
再び令和の時代のことを考える
以上、昭和、平成初期の頃と比較するとネットワークインフラの拡充とコンピューターの性能向上で作業効率がくらべものにならない程向上しました…が、
それと同時に仕事のスピードもめちゃめちゃ速くなり、一人あたりが書くコードの量も爆発的に大きくなりました.
ITの進化で仕事が楽になったか？という疑問は世の中よく言われることです.
ただ、これが無かったら在宅勤務など今のコロナ禍の対策が出来なかったのは事実です.
世の中が便利になったらなっただけ自分の仕事の内容も変わっていくのは致し方ないことでしょうね.
そして、今になってあのプロジェクトのことを思い出す
先の話は1980年代後半から2000年代初頭の話になります.
1990年代中頃ではまだインターネットを使えてた人は大学や企業の研究者に限られていて、名刺にメイルアドレスがあるのがたいそう羨ましかった、と記憶しております.
そんな時代よりもっと前, 1984年に産業構造審議会から
「１９９０年には６０万人のソフトウェア開発技術者が不足する」
という報告書が提出されました. これがあの Σプロジェクト (シグマプロジェクト) の始まりです.
通産省のお役人はSRAの岸田孝一さんに声をかけます. 通産省の要望から岸田さんは当時こう考えたそうです.
「研究者同士、開発者同士の横の交流や、切磋琢磨し合える環境ができれば、日本のソフトウェア技術は、より発展するはずだ。そういった、草の根運動の手助けになるようなプロジェクトが、できないだろうか?」
水天工房-Σ(シグマ)計画
とてもワクワクするようなアイデア. これが1984年当時に考えられてたことというのが大変な驚きです.
おそらく岸田さんはBerkeley Software Distributionや1983年にスタートしたGNUプロジェクトなどから上のような考えに至ったのではないかと想像します.
これも私の勝手な想像ですが、
- フラットな組織構成で
- BSD系のUnixが稼働するWorkStationが多数接続される分散ネットワークをもって
- ソースコードなどの成果を共有しながら
- 日本中のエンジニアが互いに切磋琢磨し向上していく
という景色を思い描いていたのでは？と思ってます.
ところが、その結果はどうだったか?
Σプロジェクトが始まると
- System V系Unixが稼働するメインフレームを東京の計算機センターに設置
- メインフレームのハードメーカーとメインフレーマーを頂点としたヒエラルキーを構成し
- 彼らが提供したソフトウェア部品を下々のプログラマがそれを使って効率よくプログラムを構築する.
というような岸田さんが思いとは全く違う方向に通産省とメインフレームメーカーが勝手に進んでいってしまい、岸田さんは途中でプロジェクトから離れてしまいました.
その後の結果はご存じの通りです.
ここやこちらで詳しく述べられていますので、ここでは特に詳しく書きません.
5年間で250億円の国費が使われたそうです. 金額からいえば、今のオリンピックで散財している国費の額と比べれば小さいものです.
ただ、このプロジェクトがあの当時に当初の考え通りに進んでいれば、日本のソフトウェアの全世界に対するプレゼンスはずいぶん違うものになっていたのでは？と想像に難くありません.
1980年代当時の着目点は素晴らしかった.
ただ,失った金額よりも日本のソフトウェア技術や文化が向上する可能性があったのに…
そういう機会を失ったことが一番残念なところです.
日本の技術力の低下が叫ばれてる昨今、この話を思い出し思わず書いてみました.
