サマータイム対応を0円でやるたった一つの方法
それは、実施日の10年前に告知すること。そうすれば、0円は言いすぎだとしても現実的なコストで問題なく対応できるよ。
自分にとってこれは、「明日から電卓の＋キーで引き算をして−キーで足し算をすることに決めた」みたいな話に聞こえる。
誰がうれしいのかちっともわからないけど、「明日から」というところを「10年後から」にしてもらえば、何の困難もない。+と-のキートップの刻印を逆にすればいいだけで、電卓の設計には何の変更もいらない。キーの配置を変えてはいけないと言われたなら、中の配線を二箇所変えるだけ。「電卓の+キーと-キーを逆にすることは不可能である」なんて言う人は誰もいないと思う。
しかし、「明日から」と言われたら、今、あちこちにある電卓はどうするの？
付箋紙をキートップのサイズに切り抜いて、日本全国の家庭やオフィスで、明日の朝一番にそれを貼りつけて、「+」「-」という字を手書きすればいいだろうか。でも、文具店や100円ショップの店頭にあるものはどうする？開封して同じことをして、またパッケージに入れる？そんなもの売り物にならないよね。では、今店頭や倉庫にある電卓は全部廃棄して、新しいのと入れ替えるか。急遽増産したとして、それが行き渡るまでは、電卓が品不足になって値段が高騰するよね。
つまり、流通の途中にある電卓を修正するっていうことは、とても難しい。
電卓だったら半年くらいかな、流通の途中にある製品に手を入れないでいいようなプランになれば、それほど難しいことではないし、お金もそんなにかからない。
今ある工場の生産計画に合わせて、「次の製品から+-逆のキートップで製造してね」と言っておいて、それが十分に行き渡ってから、切り替える。そうすれば、「店頭で全店員総出で電卓を箱から出して、キートップにシールを貼り、また箱に詰めて陳列棚に並べる」なんて、変な作業は発生しない。
それでね、この話で重要なことは、電卓の基盤とか筐体を設計している人が「そんな変更は簡単です、すぐできます」と言っても信じてはいけない、ということだ。むしろ、文具店や100円ショップの店長みたいな人に聞くべきだ。
これは、電卓の専門家でなくてもよくわかる話だし、説明するのも簡単だ。電卓の在庫の山を見せて、その在庫の山の前で、電卓を箱から出してキートップにシールを貼って、また梱包する、そういう一連の作業を見せて、「明日までに、この山を全部消化しなきゃならんのです。社員総出で徹夜でやってますが、とても間に合いません」と言えばいい。
まあでも、ソフトでも同じです。
残業計算でも電車の運行管理でも航空管制システムでも電波時計でもビデオレコーダーでもなんでもいいけど「次の製品からサマータイムするのに、どれくらい余分にかかる？」と聞いてみたら、99%は「別に、次の製品サイクルから対応するなら大した問題じゃないよ」って言うだろう。まあ、さすがにコンピュータで、1%くらいはそれでも何やら難しいこと言って、「無理だ無理だ」って言うかもしれない。でも、それは残りの99%の人がちょっと手を貸してやればいい。なんたって国の威信をかけた大事な問題なんだから、それくらいしたっていいだろう。「次の製品から」とハッキリ言えば、文句を言う人はごく少数だ。
でも、仕掛り中の製品、流通在庫について、同じことをしてくれと言うと、みんな顔色が悪くなる「それはちょっと...」次の言葉が出て来ない。
彼らは、「在庫の山の前で、電卓を箱から出してキートップにシールを貼って、また梱包する、来年までに、この山を全部消化しなきゃならんのです。社員総出で徹夜でやってますが、とても間に合いません」みたいな泣き言を言っている自分を想像しているのですが、その状況がうまくイメージできんのです。
ソフトはリードタイムが滅茶苦茶長い。特に、タイムゾーンのようなOSのレベルの変更だと、基本的には、OSの新バージョンのリードタイムと配布の期間を別に見て、それが完了してからアプリケーションのリードタイムが来る。常に5年から10年の在庫をかかえて商売してるようなもんです。
私が、コンピュータシステムのサマータイム対応を巡る二つの楽観論で通信の問題を中心にとりあげたのは、通信がからむとさらにリードタイムが長くなるからです。つまり、通信というのは、複数の組織がそれぞれのコンピュータで通信することが多くて、その場合、組織同士のマウンティングみたいなことが終わらないと、エンジニアは作業できない。犬が唸りながら睨みあうみたいに、どっちが偉いのか決めてからでないと、通信の仕様を決めるのがどっちか決まらない。
通信の仕様を決めるのは簡単だけど、通信の仕様をどっちが決めるのか決めるのは大変で、私が「リードタイム」と言う時問題にしてるのは通信の仕様を決める時間ではなくて、通信の仕様をどっちが決めるのか決める時間、つまり、マウンティングの時間です。
普通、システム開発はマウンティングが終わってから始まる。そしてマウンティングの結果がひっくり返ることはほとんどない。普通の開発の見積りには、そういう時間は入れない。
でも、サマータイム対応は、マウンティングからやり直すことになって、これは長くなりそうだな、というのが、上記のエントリの話です。
ちょっと違う言い方をすると、コンピュータっていうのは、変動費を固定費に変えるものです。
給料計算をして給与明細を書くのが、社員一人につき30分かかるとします。これを手作業でやってると、このコストは、社員の人数に比例するので変動費です。
コンピュータでやると、プログラムを書くのに、たとえば1000万円かかる。しかし、プログラムを書いてしまえば、社員が1000人でも10万人でもコストはほとんどかからない。固定費です。
もし、そのプログラムに間違いがあって、印刷した給与明細を一枚ずつ修正しなきゃならんとしたら、固定費になったはずのコストが、また変動費に戻る。その時には、社員が1000人と1万人で大きな違いが出る。
そして、今の話の中で固定費と言っているプログラム開発の中にも同じ構造があります。
1000本のプログラムを書くとして、そのプログラムの中に共通の、たとえばタイムゾーン対応があったとして、これを共通の部品にして誰か一人が書けば固定費です。その部品を使うプログラムが1000本あっても10万本あっても費用が変動することはありません。
しかし、その共通の部品が出荷されてから、それを修正しようとすると、1000人のプログラマが、全員、自分のプログラムがその部品の新しいバージョンと動くかテストしなくてはいけない。そして、その1000人が、それぞれ、修正版を客先のコンピュータにインストールしなくてはいけない。これは変動費です。
ソフトの設計、製造、テスト、配布といったサイクルの中には、この「変動費になることを固定費にしてコストを圧縮する」という構造が何重にも入れ子になっています。普通に見えている費用は、圧縮された固定費の費用です。
しかし、サマータイム対応のような想定外のことを後から入れようとすると、いろいろなところで固定費として圧縮されたコストが、変動費としてあらわれてきます。
こういう、ソフトの製品サイクル、その中にあるマウンティングとか変動費を固定費におさえる仕組みというのは、狭義のプログラミングとは別の話で、しかも、業界ごとにかなり事情が違います。
たとえば、私の今の職場では、昨日言われたことを、今日の朝のミーティングで「今日これこれをデプロイ(本番稼動)します」なんていうことが日常茶飯事です。テストは自動化されているし、自動化テストで動作確認できないところは、別のルートがあって別のルートで承認されます。
でも、20年前には、私は、ダムの制御システムを開発していて、これは、ダムのゲートを開きすぎると下流の水位が急激に上がって危険になるという、そういうゲートをコンピュータであけしめするものなので、ありとあらゆる確認を何重にもやります。ここでは、小さな仕様変更でも、基本的に二年後の次のバージョンに回していました。
ただ、どちらも、(狭義の)流通在庫の期間の範囲なら、通常運用で変更できることは同じで、それより短いサイクルで変更を要請されると、かなりアタフタして、他の作業を止めて社員総出でみたいな状況になるのも同じです。
そういうサイクルをひっくりかえすなんてことは、非常事態でなければありえない。
まあ、宇宙からサマータイム星人が攻めてきて、「来年までにサマータイムになってない国は全員滅ぼす」とか言ったならやりますよ。みんな文句も言わずにがんばってやると思う。
そうでない限り、固定費として不可視化されているコストが変動費として爆発して、それを処理するためにマウンティングからやり直す未来しか見えない。
