ソフトウェア技術者にとって、心の健康を維持することは仕事に関係する技術を習得するのに劣らず大切なことである（これは別にソフトウェア技術者に限った話ではないが）。

　ソフトウェア技術者は、厳しい仕事に携わっているためか精神的に落ち込む機会が多い。厳しい仕事ならソフトウェア開発以外の分野でもいくらもあろう。しかし特にソフトウェア開発という仕事は孤独な作業の連続であり、個人が一人で重い責任をしょい込まざるをえない状況に追い込まれやすい職種なのである。デバッグがうまく進まないからと言って、上司や同僚に助けを求めてもたいして役には立たない。担当外の人にとっては、いきなりコードの詳細を見せられても容易には状況が掴めないから助力のしようがないのである。プログラムに虫を作り込んだのが自分であれば、それを解決できるのも自分以外にはいないと覚悟しなければならない。

　プロジェクト全体のスケジュールの遅れが、自分の担当部分の遅れに起因している場合は、そのプレッシャーは相当なものであろう。責任感の強い技術者であればある程こたえるものである。また、優秀で期待されている技術者であればある程、仕事量は増え厳しい納期に追われて徹夜、臨出が多くなる。いわゆる「時短」とは無縁な職場になり勝ちである。
　しかし悩みの真の原因は、プログラムの虫を発見できないことにあるのではなく、通常は上司、同僚など職場での人間関係が原因であることの方が意外に多い。特に内向的な性格の技術者は、こういった仕事上の悩みから来るストレスを何らかの方法で発散する術を身に付けていないと心の健康を維持するのは難しい。

　最も良い方法はプログラミングという作業に楽しみを見い出し、仕事と趣味を一致させてしまうことである。しかし誰でもがプログラミングに楽しみを見い出せるとは限らない。不幸にして精神的にまいってしまった場合には、一人で悩みを抱え込まずにできるだけ早く上司や同僚・友人など信頼のおける人に相談してみることである（そのためにも普段から信頼のおける友人を作っておく必要があろう）。そういった人に話しを聞いてもらえば、根本的な解決には至らないとしても、かなりのストレス解消になるものである。それにはまず、本人の側からの何らかの意思表示をすることが必要であろう。職場の仲間もそのシグナルを見落とさないようにしなければならない。私自身、このシグナルを見落として何度も苦い思いを経験している。

　ソフトウェア技術者として長生きしたければ、日頃から各種の健康法を心掛け、ストレスの発散に努めることが重要である。単にお酒を飲んで憂さを晴らすだけでは、生理学的にいって真のストレス解消にはなっていないそうである。それよりも休日は時間を作って運動や趣味に打ち込むのがよい。特に運動による効果はてきめんである。しかし実際に経験しないとこの効果の程は信じられないものらしい。いくら悩んでいる当人に運動を勧めても無駄であろう。遅すぎるのである。普段から運動をする習慣を身に付けている人は、肉体的な健康だけでなく心の健康にも問題が少ないようである。

　運動や趣味をやりたくても「忙しいから時間がない」と言う人がいるが、時間は無理をしてでも自分で作り出すものである。仕事以外のことに時間を割く才覚があるかどうか、これが心の健康を維持できるかどうかの鍵になるといってもよいであろう。

　プログラミングの世界でも「健康法」と「長生き」は重要なテーマである。健康で長生きしなければならないのは、技術者ばかりではない。我々が日々作っているプログラムそのものも、長生きしてもらわなければ困る。それにはプログラムを長生きさせるための健康法が、人間の場合と同じように存在するはずである。たとえば、次のようなものである。

（１）汎用の共通言語を使う
　主として機械語でプログラムを記述していた時代には、プログラムの寿命はそのハードウェアの寿命と運命をともにするしかなかった。しかし、高水準の汎用言語を記述言語として利用する時代になるとソフトウェアという財産を機種が変わっても受け継いでいくことが可能となった。ソフトウェアを長生きさせられる可能性が出てきたのである。たとえば、プログラムを共通言語のＣ言語で記述しておけば、Ｃの使える機種ならそのままの形でプログラムが使えるという訳である。共通言語の選択に当たっては、できるだけ汎用の言語で将来とも使われ続ける可能性の高いものを選ぶことが大切である。

（２）機種依存部への対応
　しかし、共通言語が使えるという機種にプログラムを持っていって実際に動かしてみると、事はそれ程簡単ではないことに直ぐ気が付くはずである。同じ言語が通じると思って新しい世界にやってきたのに、案に相違して共通言語が通じない。以前から普通に使っていた言葉に誤った表現が含まれていたり、あるいは方言として機種に依存する表現やライブラリが使われていたりするために意思を通じることができないのである。

　機種依存の書き方をしていると長生きできないことが分かってきた。しかし、これは「たばこ」みたいなもので、一度馴染んでしまうと容易にはやめられないものらしい。もしやめられないとするなら、機種依存あるいはコンパイラ依存の記述をどのように切り分けて記述しておくかが重要なポイントになる。将来、生き延びるために移植という手術が必要になった場合には、これをやっておくと簡単な外科手術程度ですむからである。

　依存部の切り分けは、Ｃ/Ｃ++言語のプログラムなら

　　　　　#ifdef … 　　　または　　　#ifndef …
　　　　　　…　　　　　　　　　　　　　…
　　　　　#endif　　　　　　　　　　　#endif

などを利用して行うのが普通である。しかし、これを多用し過ぎるとプログラムが #ifdef … #endif のお化けとなり、プログラムの美しさが失われるという欠点がある。利用も程々にすべきであろう。

　一番良い方法は、機種依存の部分をラップに包み込んでカプセル化して利用することである。オブジェクト指向ではこれをラッパー（wrapper）クラスと呼んでいる。これをインライン展開する機能と合わせて利用するとよい。特にファイル入出力関係のライブラリは、特定のコンパイラに依存しやすいので関連する関数群をひとまとめにしてラッパークラスにしたり、繰り返し呼び出すことによって処理が進められる構造のイテレータ（iterator）クラスにして用いるとよい。これらのクラスをインライン関数の機能と組み合わせて実装することにより、異機種間の移植で問題になる部分を隔離することが可能となる。その結果、以後の移植作業を容易にすることができる。

（３）コーディング規約を作る
　プログラムを長生きさせるためには、あらかじめコーディング規約を作っておいてそれに則ってプログラミングする習慣にするとよい。特に多人数でチームを組んでプログラム開発を行う場合には重要である。普段の些細な努力の積み重ねが、いつか長生きの重要なポイントになる可能性があるからである。
　プロジェクトごとにこのような試みは行われているが、あまり公開された例は少ない。良い規約ならもっと公開して多くの人に取り入れて実践してもらう方向へもっていくべきであろう。

　ここでは、関数と変数の名前付けの規則（命名法）について、マイクロソフト社が最初に Windows システムを開発した際に用いたものを紹介することにしよう（これが良い方法であるとは思わないが）。

●関数に名前を付ける場合は、動詞の次に名詞が来るような名前付けにし、動詞と名詞の先頭文字はそれぞれ大文字にする。
●変数に名前を付ける場合は、変数名の先頭にデータ型を示す略称を埋め込む。
　具体的には、変数名の先頭に小文字の型略称（以下の表参照）を付加し、名前の本体の最初の文字は大文字とする。

　率直に言って、この型略称を前置する方法には賛否があり広く受け入れられているという訳ではない。たいして得るところはないが、ウィンドウ関係の関数ライブラリ群（ＡＰＩ）の利用者は、この命名法を知っていないと不便を感じることがあるかもしれない。長いものには巻かれろということであろうか。

　 変数に前置する型略称の一覧

型略称	デ　ー　タ　型
b	ブーリアン（１バイト）
c	文字（１バイト）
dw	long unsigned の整数
f	16ビットのビットフィールド
h	ハンドル
l	long の整数
lp	long のポインタ
n	short の整数
p	short のポインタ
pt	画面座標値を持つ long 整数
w	short unsigned の整数
sz	空文字で終る文字列へのポインタ
lpsz	空文字で終る文字列への long のポインタ
rgb	ＲＧＢ カラー値を持つ long の整数

　ところで人間の世界では、幸いにも長生きする人達が増え、高齢化が進んでいる。お年寄りが安心して生活できる社会を築くには、若い人たちに、より高い割合での負担が求められ、その結果お年寄りをいかにして支えるかが重大な社会問題になりつつある。

　ソフトウェアの世界でも「高齢化ソフトウェア」というのがありうるのではないだろうか。さしずめ共通言語のＣＯＢＯＬで記述された膨大なソフトウェア財産は、今や高齢化ソフトウェアと呼べるものになりつつあるように思えてならない。これら過去の財産を如何にしてサポートしていったら良いのか。「別のものに取り替えたら」などと言おうものなら不見識であると非難されるのが目に見えている。しかし、無視しては商売にならないし‥‥。
　お互い健康には気を付けて、何時までも若く元気でありたいものである。■

［］