百論簇出：（第158回目）『IT時代の知的生産の方法（その6）』
（前回）
○プロのプログラマー向けのプログラム開発論
ここで私のITエンジニアとしてのキャリアについて触れたい。
私は過去（1984年から2000年の間）には、かなりの規模（C言語で30万行程度のソースコード）のシステムを幾つも製作した経験がある。それも単にプロジェクトマネジャーという、プログラマーの尻を叩く工程管理だけをしていたのではなく、自分自身でも何万行のプログラミングし（ソースコードを書き）、テストし、最終段階では、客先でのインストール（これを現地調整、略して『現調』という）で地獄のトラブルシューティングをこなしてきた。また現調の合間には、納期が迫っている書類作りに追われていた。仕事時間はそれこそ『セブン・イレブン』であった。月の残業時間も相当あったとおもうが、正確には覚えていない。というのは管理職であったため、残業代が付かなかったのできちんと計算しなかったからだ。
プロジェクトの詳細に立ち入るのは避けるが、概略をいうと、事務処理ではなく、製造現場で稼働している機械類・センサー類から上がってくるデータや他のコンピュータからのデータに基づいて処理し、指令を送るという『リアルタイム処理』のシステムであった。この類のシステムの恐ろしい点は、プログラムのちょっとした不具合（通常『バグ』という）でも、工場の大きな機械が止まったり、思わぬ方向に動くので、作業員が慌てて非常ボタンを押すと、工場全体に『ウヮ―ン、ウヮ―ン』とサイレンが鳴り響くことだ。そうすると、色々な所から人が集まってきて、大騒ぎになる。
それだけでなく、非常ボタンが押されることで、コンピュータ上のデータと現物（例：タイヤ、パレットなど）の情報に狂いが生じるので、コンピュータを初期処理してデータをクリアーし、現物は全て取り除かなければならない。コンピュータ上の処理は大したことはないのだが、現物は、時には何人もの作業員に頭をさげて手伝ってもらわないと処理できない。私が作ったシステムでは、現物は大きいもので、数トンの鉄の紙巻ロールや 20Kg近い自動車のタイヤから、小さいもので数キロのパレットがあった。一つ二つではなく数十個の現物を処理するのは一仕事だ。
プログラム上では、ちょっとしたケアレスミスでも現場では大事（おおごと）になるのだ。それで、プログラム製作やバグ取りは常に緊張の連続だ。多少大げさにいえば、命綱を持たずにグランドキャニオンに張ったロープを歩いて行くようなものだ。万全と思ってもいつ何時、突風が待ち構えているかもしれない。最初のプロジェクトで現場でのトラブルシューティングにさんざん悩まされたので、 2回目以降のプロジェクトでは、システムのシミュレーターを作成した。つまり、現場の機械類、センサー類から発生するデータを想定してそのような情報を発生させるプログラムを別途作るのだ。そして、そのプログラムから出されたデータを本物のデータとみなして本体のプログラムをコンピュータ上で動かして、トラブルシューティングをするのだ。これによって非常ボタンを押される回数は格段に減ったがそれでも、何度か『ウヮ―ン、ウヮ―ン』で心臓が飛び出る思いをしなければいけなかった。
このような緊張を強いるプロジェクトを長いプロジェクトでは丸々 2年間、短いものでも1年間もしていると、終盤は流石に疲れが出てくる。特に、地獄の現調の現場に数ヶ月もいるとその内に胃がちくちく痛くなる。流石に胃から黄色い汁が上ってくるということはなかったものの、プロジェクト終了後の健康診断では決まって軽傷の胃炎と診断された。しかし元来、のう天気な性格なので、プロジェクトが終わって数ヶ月経つとけろりとし、胃は元通りに戻っていた。
【出典】 Huge Collection of Programming Cartoons
後日、こういった過酷な『リアルタイム処理』プロジェクトを離れて『事務処理』プロジェクトに移った時は、それこそ天国にでも来たのかと思った。事務処理のプログラムでは、バグがあっても、画面上で表示出なかっただけ、あるいは表示位置がずれただけ、の軽い症状ばかりだ。プログラムをちょこちょこっと直して再度走らせれば完了、と至って簡単だ。しかし、この時に思ったのは、事務処理のようなプログラムだけしか作っていないプログラマーは決して大成しないだろうなあ、ということだった。『リアルタイム処理』と比べると、緊張感が天と地の差がある上に、システムの動きを自分で『体感』することがないからだ。
『システムの動きを体感する』とはどういうことか？
プログラムは最終的にコンピュータのCPUで処理される。その時、CPUだけでなく、メモリー、ハードウェア、通信（これらの機器をコンピュータ用語で『資源』と称する）など様々なインターフェースが関連してくる。同じ処理をするのでも、プログラムの書き方次第で、資源の利用状態が大幅に異なる。資源を上手に使いこなせないと、ユーザーの観点から言えば、処理が遅い、途中で通信が落ちる、などのトラブルが発生する。
現在のコンピュータは私がシステム開発していた20年前と比べると格段に高速化しているはずなのに、それでもちょっとした処理に多大の時間がかかっているケースがままある。これは、一つにはOS（オペレーティング・システム）が肥大化したため、プログラムではなくコンピュータシステム自身が遅くなっていることが挙げられる。しかし、大抵のアプリケーションソフトウェアの製作者たちが、自分達の書いたプログラムが一体どのように動いているかを知らないのがトラブルの主原因だと私は思う。それはあたかもサッカー選手全員が目隠しをしてサッカーをしているようなものだ。ボールが体に当たって始めてボールの位置が分かって蹴ることができるが、それ以外の時には、ボールが一体どこにいるのか皆目、見当がつかない。これではまともなサッカーにならないことは容易に想像できる。それと同じく、自分の書いたプログラムによってコンピュータ資源が刻一刻とどのように使われているのかを想像できないようであれば、まともなプログラマーとは言えない。
ソフトウェア業界から足を洗って、すでに十数年になるので、現在の業界の詳しい様子は知らないが、たまにウェブなどでシステムトラブルの記事（航空会社の発券システム、通信会社のサービス中断、など）を読んだり自分が被害者として経験するにつけ、ソフトウェア技術者もしっかりとハードウェア（資源）の事を勉強して『システムの動きを体感する』できるようになるべきだと痛感する。
今回は、本論から外れて専門のコンピュータ技術者育成論になったが、次回は本題に戻って、プログラムの素人がオフィスワークの能率向上のためのプログラム技術を修得するための環境づくりについて述べたい。
（続く。。。）
○プロのプログラマー向けのプログラム開発論
ここで私のITエンジニアとしてのキャリアについて触れたい。
私は過去（1984年から2000年の間）には、かなりの規模（C言語で30万行程度のソースコード）のシステムを幾つも製作した経験がある。それも単にプロジェクトマネジャーという、プログラマーの尻を叩く工程管理だけをしていたのではなく、自分自身でも何万行のプログラミングし（ソースコードを書き）、テストし、最終段階では、客先でのインストール（これを現地調整、略して『現調』という）で地獄のトラブルシューティングをこなしてきた。また現調の合間には、納期が迫っている書類作りに追われていた。仕事時間はそれこそ『セブン・イレブン』であった。月の残業時間も相当あったとおもうが、正確には覚えていない。というのは管理職であったため、残業代が付かなかったのできちんと計算しなかったからだ。
プロジェクトの詳細に立ち入るのは避けるが、概略をいうと、事務処理ではなく、製造現場で稼働している機械類・センサー類から上がってくるデータや他のコンピュータからのデータに基づいて処理し、指令を送るという『リアルタイム処理』のシステムであった。この類のシステムの恐ろしい点は、プログラムのちょっとした不具合（通常『バグ』という）でも、工場の大きな機械が止まったり、思わぬ方向に動くので、作業員が慌てて非常ボタンを押すと、工場全体に『ウヮ―ン、ウヮ―ン』とサイレンが鳴り響くことだ。そうすると、色々な所から人が集まってきて、大騒ぎになる。
それだけでなく、非常ボタンが押されることで、コンピュータ上のデータと現物（例：タイヤ、パレットなど）の情報に狂いが生じるので、コンピュータを初期処理してデータをクリアーし、現物は全て取り除かなければならない。コンピュータ上の処理は大したことはないのだが、現物は、時には何人もの作業員に頭をさげて手伝ってもらわないと処理できない。私が作ったシステムでは、現物は大きいもので、数トンの鉄の紙巻ロールや 20Kg近い自動車のタイヤから、小さいもので数キロのパレットがあった。一つ二つではなく数十個の現物を処理するのは一仕事だ。
プログラム上では、ちょっとしたケアレスミスでも現場では大事（おおごと）になるのだ。それで、プログラム製作やバグ取りは常に緊張の連続だ。多少大げさにいえば、命綱を持たずにグランドキャニオンに張ったロープを歩いて行くようなものだ。万全と思ってもいつ何時、突風が待ち構えているかもしれない。最初のプロジェクトで現場でのトラブルシューティングにさんざん悩まされたので、 2回目以降のプロジェクトでは、システムのシミュレーターを作成した。つまり、現場の機械類、センサー類から発生するデータを想定してそのような情報を発生させるプログラムを別途作るのだ。そして、そのプログラムから出されたデータを本物のデータとみなして本体のプログラムをコンピュータ上で動かして、トラブルシューティングをするのだ。これによって非常ボタンを押される回数は格段に減ったがそれでも、何度か『ウヮ―ン、ウヮ―ン』で心臓が飛び出る思いをしなければいけなかった。
このような緊張を強いるプロジェクトを長いプロジェクトでは丸々 2年間、短いものでも1年間もしていると、終盤は流石に疲れが出てくる。特に、地獄の現調の現場に数ヶ月もいるとその内に胃がちくちく痛くなる。流石に胃から黄色い汁が上ってくるということはなかったものの、プロジェクト終了後の健康診断では決まって軽傷の胃炎と診断された。しかし元来、のう天気な性格なので、プロジェクトが終わって数ヶ月経つとけろりとし、胃は元通りに戻っていた。
【出典】 Huge Collection of Programming Cartoons
後日、こういった過酷な『リアルタイム処理』プロジェクトを離れて『事務処理』プロジェクトに移った時は、それこそ天国にでも来たのかと思った。事務処理のプログラムでは、バグがあっても、画面上で表示出なかっただけ、あるいは表示位置がずれただけ、の軽い症状ばかりだ。プログラムをちょこちょこっと直して再度走らせれば完了、と至って簡単だ。しかし、この時に思ったのは、事務処理のようなプログラムだけしか作っていないプログラマーは決して大成しないだろうなあ、ということだった。『リアルタイム処理』と比べると、緊張感が天と地の差がある上に、システムの動きを自分で『体感』することがないからだ。
『システムの動きを体感する』とはどういうことか？
プログラムは最終的にコンピュータのCPUで処理される。その時、CPUだけでなく、メモリー、ハードウェア、通信（これらの機器をコンピュータ用語で『資源』と称する）など様々なインターフェースが関連してくる。同じ処理をするのでも、プログラムの書き方次第で、資源の利用状態が大幅に異なる。資源を上手に使いこなせないと、ユーザーの観点から言えば、処理が遅い、途中で通信が落ちる、などのトラブルが発生する。
現在のコンピュータは私がシステム開発していた20年前と比べると格段に高速化しているはずなのに、それでもちょっとした処理に多大の時間がかかっているケースがままある。これは、一つにはOS（オペレーティング・システム）が肥大化したため、プログラムではなくコンピュータシステム自身が遅くなっていることが挙げられる。しかし、大抵のアプリケーションソフトウェアの製作者たちが、自分達の書いたプログラムが一体どのように動いているかを知らないのがトラブルの主原因だと私は思う。それはあたかもサッカー選手全員が目隠しをしてサッカーをしているようなものだ。ボールが体に当たって始めてボールの位置が分かって蹴ることができるが、それ以外の時には、ボールが一体どこにいるのか皆目、見当がつかない。これではまともなサッカーにならないことは容易に想像できる。それと同じく、自分の書いたプログラムによってコンピュータ資源が刻一刻とどのように使われているのかを想像できないようであれば、まともなプログラマーとは言えない。
ソフトウェア業界から足を洗って、すでに十数年になるので、現在の業界の詳しい様子は知らないが、たまにウェブなどでシステムトラブルの記事（航空会社の発券システム、通信会社のサービス中断、など）を読んだり自分が被害者として経験するにつけ、ソフトウェア技術者もしっかりとハードウェア（資源）の事を勉強して『システムの動きを体感する』できるようになるべきだと痛感する。
今回は、本論から外れて専門のコンピュータ技術者育成論になったが、次回は本題に戻って、プログラムの素人がオフィスワークの能率向上のためのプログラム技術を修得するための環境づくりについて述べたい。
（続く。。。）
