僕が新卒で入った会社は、大手金融のシステム子会社だった。
職種はシステムエンジニアだったのだけど、
大学は法学部で、プログラミング経験はまったくなかった
（まあそこは同期もほとんどみんながそうで、
むしろ情報系の人の方が少なかったのだが）。
というわけで、新人研修で初めてプログラムを組んだわけである。
ところがなかなかピンとこないところがあった。
プログラムを組んだ経験がある人なら分かると思うが、組み方はいろいろある。
たとえば、ただ仕様書に書かれてある通りにベタ打ちで組む方法もあれば、
よく出てくる処理を抜き出して、
その処理が出てくるごとに呼び出すようにする方法もある。
一見、同じように動いているプログラムでも、その中身はいろいろ違いがある。
だから、「この仕様書に対してどのような組み方が良いのか」
という疑問が常にあり、自分が作ったプログラムなのに、
それがベストなものなのかどうか自信を持てない気持ち悪さがあった。
そもそも、どういう方針でプログラムを組むべきなのか。
ところが、みんなそのことに悩んでいるように見えないのである。
会社は大阪に本社のある、金融のシステム子会社だったのだが、
大阪人は短期志向が強いようだし、金融の親会社からの出向者が
主要なポストの大半を占めるその会社は体育会系の社風が強く、
「ごちゃごちゃ言わんとさっさと手を動かせ」という感じで、
抽象度の高い質問は許されない雰囲気があった。
年中、部長の怒鳴り声が響いているような職場だったからね。
それでも一年もたつとそれなりに経験も積んでくる。
そこで上司との面談の機会があったので、訊いてみることにした。
「僕が今まで見ていると、見ているだけで気持ち良くなるような
何度も見返したくなるようなプログラムもあれば、
それとは逆に、見ているだけでイライラして腹が立つプログラムもあります。
どうしてこのような違いが生まれてくるのでしょうか。
また僕はおそらく、見ていて気持ち良くなるようなプログラムの方を
作るべきだと思うのですが、この考えは合っているでしょうか。
そしてそもそも、「いいプログラム」とはどういうもので、
どういう方針に基づいて組むべきなのでしょうか」。
多少青臭くはあるが、新人のときであれば許される質問だと思う。
しかし、上司からは明確な回答はなかった。
だから、「こういうことでしょうか」、「ああいうことでしょうか」と
僕から質問を重ねたが、「これも大事やなあ」、「あれも大事やなあ」と
やはり回答はない。
おそらく質問の意味は分かるが、上司本人の考えはなかったのだろう。
そんな2年目の最初にチームを異動になった。
だから、そのチームの上司との最初の面談時に同じ質問をしてみたところ、
「質問の意味が分からない」と怒ってきた。
おそらく本当に意味が分からなかったのだろう。
真面目な質問をしているのに怒られてはたまらない。
「この質問をうちの会社の誰にしても、おそらく誰からも
まともな回答は返ってこないな」とあきらめて、自分の力だけで調べることにした。
そうやって自分で本を買ったり専門誌を購読したりなどした末に、
3,4年目ぐらいに、自分なりの結論に達した。
「現代のソフトウェアに優先的に求められるのは『保守性』ではないだろうか」。
「保守性」とは、つまりメンテナンスのしやすさのことであり、
もっというと、「後から誰が見ても分かりやすい」ことが重要になる。
システムは開発すればそれで終わりではなく、要件が変われば変更も必要になる。
たとえば消費税が8%から10%になれば、システムもあわせて変更しなければらない。
だから、プログラムの変更が必要な箇所を探し出して、変更して、確認のテストをする。
そのときのことを考えて、「後から誰が見ても」どこを変更すればよいか分かりやすく、
変更箇所は少なくてすみ、確認のテストもしやすいようにプログラムを組んでおくのがよい。
そしてそれが、「保守性」の優れたプログラムとなる。
システムもプログラムも、属人化してはいけない。
では「処理効率性」など他の要素もあるのに、どうして特に「保守性」が重要なのか。
現代は昔に比べてハードウェアの性能が格段に進歩しており、
処理速度も記憶容量も全く比べ物にならないほど改良されている。
だから、プログラムの組み方によって変わる処理速度や記憶容量など
あるかないか分からないぐらい小さなものなので、まったく気にしなくてよい。
たった数値2桁のデータ量さえ節約しようとしていたために起きた2000年問題なんて、
今では隔世の感があるね。
ではこのようにハードウェアが安価になった今、何を気にすべきなのか。
それはこれまでの自分の経験を踏まえて、人手のかかる部分、つまり人件費ではないかと考えた。
たとえば消費税が8%から10%に変わったために、プログラムの変更が必要なったとき、
あるプログラムでは10か所の修正、10か所のテストが必要で、作業時間は3時間かかるのに、
あるプログラムでは消費税の計算を1つの処理にまとめ、必要に応じてその処理を呼び出すように
組んだので、1か所の修正、1か所のテストで、作業時間は1時間ですむとする。
この場合、明らかに後者のプログラムの方が保守性に優れており、
そういう基本方針を持ってプログラムを作っていくのがベストではないか。
作業時間が減れば、すなわち人件費を節約できるからね。
これが僕が入社3,4年目でたどり着いた結論だった。
しかしそう思うと、あの上司たちは何だったのだろうかと首をひねってしまう。
システムの開発・保守の仕事をして20年近くたっていながら、
新人に「いいプログラムとはどんなものでしょうか」と質問されて、
何一つ回答することができず、ひどい人に至っては質問の意味さえ理解できない。
またそのことを恥じる様子もない。
そんな人が管理職になって、普段は好き放題に人にダメ出しをしているのである。
彼らはプログラムを作る仕事をしていながら、「いいプログラムとは何か」について
自分なりの考えを持っていない、もしくはそもそも考えようともしていない。
考えなくても平気だということは、つまりはその分野に関する感性が鈍感なのだろう。
そのような人たちにまともな人事評価などできるのだろうか。
まるで味音痴の人に料理を、または音痴の人に音楽の評価をさせるようなものではないか。
まあその会社は金融のシステム子会社だったからか、
技術に敬意を払うどころか小ばかにするような雰囲気があった。
何度もシステム障害を繰り返しているみずほ銀行もシステム部門は地位が低いらしいのだが、
ひょっとしたら金融業界はどの会社もそういったところがあるのかもしれない。
どちらにしても、その中身は外見ほどには立派ではない。
僕は今経理の仕事をしていて、毎日のように会計クラウドに仕訳を入力しているが、
実は仕訳も、「後から誰が見ても分かりやすい」ことがかなり重要になる。
僕が前任者から引き継いでから仕訳の仕方をだいぶ変えたのだが、
手前みそになることを許してもらえば、それまでよりずっとお金の流れが分かりやすく、
税理士事務所の人にも評価してもらえている。
そしてそういう仕訳は、やはり見ているだけで気持ち良くなる。
分かりやすくするためにいろんな工夫をしているからね。
だから仕事に疲れたときなど、時々仕訳を見直しては、ひとりで悦に浸っている。