全世界のファンのみなさまこんにちは
30年前のBUG発症、ふなです。

本日はクリスマスイブ、確か23時頃がカップルのラブラブピークだったと思います。
いや、そんなことはどうでもいいんだよ。

昨日会社であるツール利用者が、お昼過ぎにやってきた。
「あのー、いつも使えるツールが今日使えないんですけど、、、」

まあ俺のところには正体不明のツールの修正依頼が良く来る。
それでも修正の希望があるから引き取ってみてみるわけだけどね。

いろいろ調べるんだけど、作者は10年前に退社済み。誰も手入れしてない。
まず、Version表示にBUGがあり
最新のVersionを示していないことが判明した。
モノはAccessのツール。DBのテーブルに格納されているべき
最新のバージョンデータが表示されていない。

まあいいや、そこは放置して、VisualBASICのVBAを読んでみる。
うーん、何がしたいツールなんだ??

と聞くと、DBがほかにあり、そのDBに対するクライアント的な
ツールであることが判明。

うんうん、で、ソースを読んでいると、エラーになれば
エラーを表示している仕組みが備わっているのに
実行してもエラーは出ない。
うむ、じゃあ正常動作か、、、

しょうがないので、頭から追ってみることにした。
Init、、まあ初期化か、うむ問題はなさそう
GetData、、その遠隔地のDBとの接続か、データが取得できないのかな?
holiday、、祝日判定、ん??これは、、、

そういえば、前日に奥さんとの会話を思い出した。
「明日は30年ぶりに平日の12/23 なんだって」
tanjoubi

まさか!と思ってソースコードを見ると、、、
1989年から 12/23 は天皇誕生日 というロジックを発見!

「わかった!!」と急に叫ぶ俺(笑)

「30年前に仕込まれたBUGですね!」
BUG

祝日判定ロジックが古いままでした。
今までは天皇誕生日じゃなくなってもそこが祝日になったのです。
例えば昭和天皇は植物の研究をしていたので、みどりの日になりました。
平成天皇はなまずの研究をしていたので、なまずの日になれば良かったのです。
いや、魚の日かな、、、

ってなことで、IF文追加して、一応動くようになった。
追加if

社内SNSにも投稿して情報共有。
来年の2月以降も動くように修正。
しかし、令和が終わると再発する仕様だ(笑)
まあその頃には会社辞めているし、このツールも使っていないだろう(笑)
そして、再び時限爆弾BUGがセットされる。
NEWBUG


ここで、ちょっとプログラムかじったことがある人なら
違和感を覚えるだろう。
IF year >= 1989 Then
IF year <= 2018 Then
shukujitu = "天皇誕生日"
End if
End if

こんなもっさりした書き方。になっている。
いや、そこは IF 文に条件追加の and でしょ?
と思った方も多いと思う。

IF (year <= 2018) and (year >= 1989) Then
shukujitu = "天皇誕生日"
End if

これでいいじゃないか、と。
そうしなかったのは理由があるのだ。

実はこのツールは私が作ったものではない、
10年以上前に在籍していた人が作ったものだ。
その人がもし補修するなら、こうやるだろうな、という設計の「哲学」みたいな
ものを反映する必要がある。

ツールの補修方法はいろいろあるんだけど
まずドキュメントがない場合がほとんどなので、
ソースから設計した人の哲学のようなものを読み取る必要がある。
このツールの場合、他のソースコードにも IF 文で and を使った文はなかったのだ。
かならず、 IF の入れ子になっている。

そういう設計思想をくみ取り、反映することで、ソースのバランスというか
違和感なく、修正することが出来る。

例えが下手で申し訳ないんだけど
例えば、ゴッホの絵を修復するとする。その絵の具に現在でしか使用されていない
絵の具を使うのは不自然になる。必ず当時使われていたあろう絵の具と手法を
用いて修復しなければならない。
どっかのフレスコ画のような「独自の技術のコード」を書いては
いけないのである。
images

案外これを知らない人が酷いコードでとりあえず動くものを作ったりする。
それでは可読性が下がり、次回以降の修復が困難になったりするのです。

そうです。プログラムの修正は美術品の修復作業に似ているのですね。
同じモデルだと思います。

で、社内SNSに情報共有しておきました。
実はこれ、社内での大きな問題提起をしたつもりなんですよ。

入り口は「本日限定のBUGのお話」とかで、本日エラーが出たりしていたら
祝日判定ロジックを疑ってね、という小さいことなんですが、、、
実は超大きい問題を抱えているんですよ。
ヤフーファイナンスがそのいい例なんですけど、、、
20191223-00000070-it_nlab-000-1-view

最近この会社がシステム障害でサービス停止した、とかいうシステム障害の
原因はXXXでした。みなさんも品質向上を意識してください、という
ビデオ研修を行ったばっかりなんですよね。

で、そこにビデオ研修のアンケートを書くんですけど、、、
私は「コスト削減によって低下した品質は研修では上がらない、コストをあげることによってしか
品質は上がらない。また次回の大規模障害後の研修ビデオでお会いしましょう!」
みたいな感想を書いておいた。

案の定、こんな不具合出たわけ。
これが表しているのは、、
まず、高単価、高技術の人がプロジェクトに配置されると
こういう便利なツールを作って省力化される。
ある程度まで省力化されると、この高単価、高技術の人のやることが無くなってくる。
仕事は「手順」だけ覚えている低単価、低技術の人がやればいいので。
すると高単価、高技術の人を必要なし、と切ってしまう。
その後、メンテナンスや、突発的なことが出来ずにサービス断までいってしまうのだ。
これが、世の中で起こっている大規模障害の原因。

コスト削減すると品質も下がるというのが良くわかるわけで
もし、このツールの作成者が今でもいたら、すぐに改修出来るし
前もってわかることも多い。
が、中身を知らないでツールやプログラムを利用している人は
何が起こるか事前に予想するのは難しい。
動かなくなってから、あわてるというパターンだ。

なんだけど、こんなことをそういう啓蒙研修ビデオを見るたび
アンケートで高技術、高単価の人間を入れないと
これからも大規模障害、サービス断は起こるよ、と書き続けている。
それでも入れないのは、きっと経営判断だ、と思うわけです。
yahoo ファイナンスも同じ構図だろうな。

もっとわかりやすくいえば、すき屋の深夜ワンオペ問題。
強盗に入られて取られる金額より、人件費削減した方が金額が大きいから
そのままにしておく、これは経営判断だと思うわけです。
その後、マスゴミに叩かれたら来客数が減ったのであわてて深夜2人にした。
結局そんなところだろうと思います。

トップは「品質は大事だ、お客様を大事に」と言っているけど
そろばん弾くと、品質は2の次で、お客を集めて売り上げが伸びれば
大規模障害出したとしても利益になる、と判断すれば
そのままのモデルでいくことになる。

利益は少しでいいから、コストをかけてでも品質を上げろ!という
判断にはならなかったのだろう。
だから、どの会社のどのシステムもこれからも必ず大規模障害は起きると
断言できる。

特にスタートアップしたてのシステムは高技術、高単価の技術者で
作り上げるから品質は担保されている。
そこから実際のシステムの運用に入ると、低技術、低単価の人に
置き変えられ、システムの品質は徐々に落ちてくる。
そして、ある日、大規模障害になる、という図式だ。
ハインリッヒの法則で1つの大規模障害の裏に29個の障害があり
300のヒヤリハットがある。

これをどうやって母数を少なくしていくのか、が大規模障害を起こさないコツである。
理解していないTOPが多いのかな?

じゃあまた!

ちなみに2000年のどあめ、は私が書いた2000年問題の本、もう絶版だけどね。