趣味・プログラミング｜社長の部屋｜有限会社イシバシ設備

プログラミングとの出会い

私がプログラミングを本格的に学び始めたのは20代、大学生の頃でした。

大学でプログラミングを学び、その後はコンピュータシステム会社へ就職しました。そこで約4年間、実際のシステム開発に携わりながら、学校で学ぶプログラミングとはまた違った、実務としての技術や考え方を身につけていきました。

その後、実家の稼業を継ぐことになり、私はプログラマーから電気・水道・空調などを扱う設備工へと職業を変えました。

一見すると、それまで学んできたコンピュータの世界とはまったく違う仕事へ移ったように見えるかもしれません。しかし、プログラミングとの付き合いがそこで終わることはありませんでした。

「自分たちの仕事に本当に必要なシステムなら、自分で作ればいい」

20年以上育ててきた、自社の工事管理システム

そうして作り始めたのが、現在も自社で使用している工事管理システムです。

最初から現在のようなものが完成していたわけではありません。実際の仕事で使いながら、「ここにこの情報があれば便利だ」「この操作は自動化できる」「この情報と、この情報を結び付けたい」「もっと簡単に過去の工事を探せないだろうか」と、必要になるたびに機能を加え、作り直し、また使ってみる。

そうした改良を20年以上繰り返してきました。現在では、自社の工事情報を管理するうえで、なくてはならないシステムになっています。

大学で学んだこと、そしてコンピュータシステム会社で実務として経験したことが、 20年以上たった現在の仕事に大いに生きています。

私が好きなのは「アルゴリズム」を考えること

プログラミングというと、画面いっぱいに難しい文字や記号を書いている姿を想像されるかもしれません。もちろん、それもプログラミングの一部です。

しかし私が特に面白いと思うのは、その前段階にある アルゴリズムを考えることです。

アルゴリズムというと難しく聞こえますが、簡単に言えば 「目的を実現するために、どのような順序で考え、どのような条件で判断するか」 ということです。

ここでは、あえてBASIC風に書きます

実際のシステム開発では、C++やC#などのC系言語を使うことがあります。

ただ、このページではプログラムそのものよりも、その裏側にある「考え方」を見ていただきたいと思っています。そこで、プログラミングをしたことのない方にも読みやすいように、実際のソースコードをそのまま掲載するのではなく、 あえてBASIC風の簡単な表現に置き換えて紹介します。

※以下のコードは実際に運用しているソースコードそのものではなく、アルゴリズムを分かりやすく説明するために簡略化したものです。

何年先でも使える予定表を考える

自社の工事管理システムには予定表があります。見た目は普通のカレンダーですが、毎年カレンダーを作り直すような仕組みにはしていません。

年と月を指定すれば、その月が何曜日から始まるのか、何日まであるのか、うるう年なのかなどを判断し、必要になった時点でその月の予定表を生成します。

例えば12月から翌年1月へ移動する考え方は、非常に簡単に表せば次のようになります。

Month = Month + 1

IF Month = 13 THEN
    Month = 1
    Year = Year + 1
END IF

12月の次は13月ではないので、月を1月へ戻し、年を一つ進める。プログラムは、こうした小さな判断をいくつも積み重ねて動いています。

「変更されたか」をどうやって知るのか

例えば4月の予定表を開き、予定を書き加えたあと、「翌月」を押して5月へ移動するとします。何も変更していなければ、そのまま5月へ移動すればよい。しかし4月の予定を書き換えていれば、その内容を保存するかどうか確認する必要があります。

そこで、予定表を最初に表示した時点の状態を BeforeTable という領域へコピーして覚えておきます。

FOR D = 1 TO 31
    BeforeTable$(D) = Schedule$(D)
NEXT D

これは言ってみれば、 予定表を開いた瞬間に一枚写真を撮っておくようなものです。

その後、予定を追加・削除・変更し、別の月へ移動しようとしたときに、現在の予定表と最初に保存した BeforeTable を比較します。

Changed = 0

FOR D = 1 TO 31

    IF Schedule$(D) <> BeforeTable$(D) THEN
        Changed = 1
        EXIT FOR
    END IF

NEXT D

一つでも違うところが見つかれば、「最初に表示したときから内容が変わっている」と判断できます。

IF Changed = 1 THEN
    PRINT "予定表が変更されています。"
    PRINT "保存しますか？"
END IF

予定表を読み込む

最初の状態を BeforeTable に保存

予定を入力・変更

別の月へ移動しようとする

現在の状態と BeforeTable を比較

変更あり → 保存確認
変更なし → そのまま移動

では、未来の祝日はどうするのか

曜日やうるう年は計算できます。しかし、日本の祝日は将来も永久に同じとは限りません。法改正によって祝日が変わったり、特定の年だけ特例が設けられたりすることもあります。

そこで私は、 未来の暦をすべて自分のプログラムの中へ固定してしまわない という考え方を取り入れています。

現在のWindowsは、インターネットを通じた更新などによって、システムが持つ情報や機能も時代に合わせて変化していきます。私のプログラムでは、Windowsが提供する機能や情報を参照しながら、祝日などを判断する仕組みを利用しています。

考え方だけをBASIC風に表すなら、例えば次のようなイメージです。

Holiday = WindowsCalendar(Year, Month, Day)

IF Holiday = 1 THEN
    CALL DisplayAsHoliday
END IF

つまり、プログラムを作った時点で知っている未来を、そのままずっと表示し続ける予定表ではありません。その時点でWindowsが持っている情報や機能を利用することで、 時代に応じて、予定表そのものも変化し得るようにしています。

ある意味では、この予定表の寿命もWindows次第です。しかし私は、それを欠点とは考えていません。

将来の社会制度を今のプログラムへ無理に固定するより、外側の世界が変化したとき、自分のプログラムもその変化を受け入れられるようにしておく。長く使うシステムには、そういう考え方も必要だと思っています。

この予定表を一言で表すなら

過去は保存して比較する。
未来は固定せず、その時の情報から判断する。

BeforeTable は、過去の状態を覚えて現在と比較するための仕組み。一方、未来の暦については現在の時点ですべてを決めつけず、その時の外部情報を使って判断する。

最初から格好のよい言葉を考えて作ったわけではありません。「どうすれば使いやすいか」「どうすれば間違いを防げるか」「どうすれば長く使えるか」と改良を続けた結果、自然とこのような考え方になっていきました。

プログラミングと設備工事

プログラマーと設備工。まったく違う仕事のように見えます。ところが、両方を経験してみると、意外と共通するところがあります。

設備工事でも、「まず何を確認するか」「次に何をするか」「この条件ならどちらを選ぶか」「通常と違う場合にはどうするか」「問題が起きたら、どこまで戻って原因を探すか」と順序立てて考えます。

これはプログラムでいう処理の順序、条件分岐、例外処理、デバッグなどの考え方と、どこか似ています。

20代の頃、大学でプログラミングを学び、コンピュータシステム会社で仕事をしていた私は、それが20年以上後、設備工事会社の仕事を支える技術になるとは考えていませんでした。

職業はプログラマーから設備工へ変わりました。しかし、そこで身につけた 「物事を整理し、条件を考え、仕組みにする」 という考え方は、今でも私の仕事の中に生きています。

そして仕事の合間に、「ここはもう少し便利にできないだろうか」と自社の工事管理システムを触り始める。気がつけば時間が過ぎていることもあります。

そういう意味では、やはり今でもプログラミングは、私の趣味の一つなのだと思います。