３月中旬の三陸津波のツイート記録

やはり三陸は無防備だったかもなと思ったりもする。明治２９年、昭和８年、そしてチリ地震の昭和３５年にも津波を経験。明治のは最大３８Ｍの津波で２万２千人が無くなった。「これより下に家を建ててはならぬ」といったその時の碑がたくさんあるのだが、時を経てそこには家が密集していたのだ。


実際私の生地でもあり、親戚もいる彼の地を幾度となく訪れたのだが、それは静かで良い場所。生まれた町ではないが、陸前高田の海沿いに泊まり松原のビーチを家族で楽しんだことがある。家人は湘南の海で育ったのだが、目じゃないくらい美しいと申すくらいの浜でありました。過去の失敗を生かせなかったのが悔やまれる。

陸前高田のビーチに行く手前に高さ３Ｍくらいの堤防が海にそって長く築かれていました。湘南ではこんなものは見たことがない。驚き説明を読んで理解。ああここも過去に被害を受けたのだと。大げさだと思われたその堤防も今はすっかり流されてしまったことだろう。あの夏の日がまぶしすぎる思い出に。

何度も彼の地を訪れたが、毎回思うのは「三陸は陸の孤島だ」ということだった。新幹線まではスムーズなのだが、そこから今回の被災地に出ようと思うと、車であれ鉄道であれ３時間くらいは山越え谷越え　優にかかる。途中が山だから自然災害でもあればすぐにライフラインは切れるなあと実感するはず


新幹線降りて、３時間かけて到着。ゆっくりした時間の中に自然に恵まれた町。リアス式海岸を臨む町並みの直ぐ後には、もう山がいくつもこちらを見下ろしている。主要な産業は漁業だという。ならば海のそばに集住せざるを得ない。

ＶBAも構造化プログラミング

Excelrです。

今回はプログラミングの初歩の話。でも非常に大事です。
基本と言いながら、守られていないことも多いです。

構造化プログラミングと言う考え方をご存知でしょうか。

だんだん肥大していったモジュールなんかは守られていないことがあります。

構造化プログラミングとは、プログラムを処理構造から考え機能を分割することです。
下の図のように機能毎に「箱」に描くやりかた。
「箱」は上下に階層を持ち、上の「箱」が下の「箱」をcallします。
上の「箱」は制御の役割、下の「箱」は処理という役割りを持ちます。
階層構造を図式化したものは「モジュール構成図」と言います。


大きな仕組みのプログラムではこうした処理の部品化が必要になります。
こうすることで分かりやすくなり、各部分でのテストを別々に行うことで全体のテストを
軽減することができます。


VBAでも同じです。コントロールするMAINプローシージャーから
各機能別のSUBプロシージャーを呼び出す形をつくるように心がける
ことはメンテナンス時の省力化にも繫がりますよ。
　　　　　　　　   　モジュール構成図

EXCEL/VBAだって標準化したい

Excelrです。

いろいろな企業におじゃまするにつけ、本当にEXCELって頼られている
アプリケーションだなと感じるのですが、ちょっと頼りすぎじゃないか？
と思うこともあります。
簡単に作れて、プログラミングもできちゃうから分からないではないですが。
軽い気持ちで作り始めたエクセルシートにいろいろ機能を追加してるうちに
何だかわからなくなってる。他の人が見たら何だかわからない。
いや、作った本人でさえ時々わからなくなってる。

こんな事よくありませんか。

まず、だいたいＶBAだと標準化が成されていませんね。
簡易言語だからということなのか、馬鹿にしてやりませんね。
動けばいいんだって感じかな。
各人思い思いのやりかたで作っていきます。
企業ではだいたいの標準化をやっておかないと品質がバラバラに
なってしまいます。

仕様書作成ルールやプログラミング方法、ネーミングルールなどは最低
決めて周知しておくべきです。

予算がなくてEXCELで何とかしようとする場合だって、その分しっかり標準化
するくらいの努力はしておくべきなのです。

ＥＸＣＥＬシステム維持、保守のために２

前回に引き続きシステム維持、保守のためのお話

大掛かりなシステムになるほど維持、保守は大変ですが
ＥＸＣＥＬ/ＶＢＡでシステムやツール作る場合だって実は大変です。

どんなシステムも基本はあまり変わらないということです。

追加、変更する可能性は同じようにありますからね。

新規で作るときには、追加、変更があることを前提に
臨んで欲しいものです。

で、今回は仕様書について。

長く使うものであればあるほど仕様書を作るべきです。
それも、がっちり人数かけてレヴューして下さい。
仕様書の品質は非常に大事でこれの良し悪しが後に修正
があった時には作業全体を大きく左右するのですから。

当たり前を当たり前に、が重要です。

システムの担当者が変わる時でも、仕様書がない、出来が悪いとなると
引き継げません。又メンテする必要はあるけれどプログラムソースしか
ないなんて状況はつらすぎますし、あらゆる面で危険すぎます。

それから保管ですね。サーバーやパソコンだけでなく、できれば紙ベースでも
取っておいたほうが良いですね。ファイリングもちゃんとして欲しい。
やはり、紙は大事です。

メガ銀行みたいなところは社会的な責任も重いせいか流石に
キッチリしていました。
でも、時間もお金もあまりかけられない企業はなかなか
完全にはいかない現実。

でもそこは差のつくところ。きっちりやるべきでしょう。

手をこまねいていると、システムが返って手のかかる負の資産になってしまうからです。
時間の浪費、人員不足、デグレード、実質的な損失につながる危険性は
前にも述べたとおりです。

人の手をかけないようにするのがしすてむ
少なくとも技術者はいつも念頭においておくべきだなと思っています。

EXCEL/VBAシステム維持、保守のために１

こんにちはＥＸＣＥＬｒです。

今はＶＢＡや他の知識を武器に効率アップをコンサルしている私ですが
そもそも、汎用系、ユニックス系のＳＥでした。
その後、いろいろな言語やシステムも見てきましたが、
基本はそんなにかわらないなあと言うのがホントのところ。

で今日は、システム開発特に保守の基本についてです。
諸般の事情もあるでしょうが、一番念頭においておきたいことは


・維持保守しやすくするためには、機能を肥大化させないこと


これです。これにつきます。どのシステム、言語でもまったく当てはまります。

特に重要なシステム、プログラムはただでさえ変更、
追加が多いのでごちゃつきがち。
そうだとしても、一点に機能を集中させないような配慮が設計に
求められます。

ＥＸＣＥＬ・ＶＢＡプログラミングでもぜんぜん例外ではありません。
集中させないで機能を分割することが重要です。

①目的別にブックを分ける。
②機能毎にシートを分ける。
③プロシージャーを極力分割する。

最低守りたいところです。

地震、津波、原発事故、相撲八百長。終わりにしなければいけないこと。今論理的な思考を始めるべき

前回、原発事故に学ぶEXCEL・VBAの開発で古いシステムは部分的に
手直しせずに作りかえるべきと書きました。

古いやり方を捨てきれずに「なあなあ」でやるとろくな事がないとも。
全く変えたほうが良い。

今回の被災や事故で言うと

地震、津波で被災した地域の再建：

少なくとも前あったところに同じような家は立てずに高台に集合住宅
でも建てるのが最良。もしくは住まないか、ライフスタイルを変えて生活すべき。　

原発：

古いタイプとは言え、津波の想定やもしもの時の準備、大きな事故になったとき
の対応の準備が省庁や政治家にまるでない。これは科学技術に酔い、
十分な危機管理をしようとしなかった事へのツケ。
又、３重、４重の備えが必要である。事故が起きたときのシミュレーションを
徹底的にやる必要あり。

その前に原発がなくなっていくかもしれませんが。

しかし、事の大小はあれ、個人、学校、企業の中で思い当たる
似たようなことはあると思われます。

日本は戦後、何もないところから発展してきた経緯があり、なんでも世界一だ
みたいな酔いがずっとありました。
確かに、資本が流れ込み戦前からあった技術、国民の気質が上手くマッチして
経済大国になったのですが科学技術にうぬぼれて、トラブル時の想定は非常に
甘い傾向にあると思います。

論理的な思考があれば、重要なことから決めていける筈ですが、
根付いていないなあと悲しくなります。

いや実は論理的な思考のもとに鋭い提言はされていても、
企業や政治の強い力にかき消されてしまえば同じです。

これ→石橋克彦氏の２００８年の提言。読んでみて下さい。

アメリカの原発はテロを想定しているそうで、トラブルに対応するための
組織が相当の人数でいるそうです。それも９．１１のおかげかもしれないのですが
日本も３．１１のおかげで徹底できるでしょうか。

合理的な思考をもってことにあたるべきなのは、システム構築においても
何ら変わることはありません。
トラブルをどのくらい想定して設計しているのか、最良の機器やソフト、
ロジックを選んでいるのか。
もし、トラブったときにはどういう体制で、どうするべきなのか。
人間がやることにそれほど差は無いのかもしれません。

原発事故に学ぶEXCEL・VBAの開発

EXCEL・VBAによるシステム構築、プログラミングにも共通したリスクがあります。

企業が長年システム開発を続けて行くと、必ずキーとなるシステムあるいは
プログラムと言うものが結果的に出てきます。
どのシステム、プログラムだって重要なのですが、とりわけ重要なのが

①他の多くのシステムに影響を与えるもの
②特にその企業の稼動に即直結するもの

などです。

鉄道で言えばターミナル駅。事故が起きると全てが止まる。

こういった一番重要なところに限って、変更や追加処理で手を加える
機会が多くなるんです。

結果、肥大化していく傾向にあります。

肥大化し、複雑になったプログラムは多大なリスクを持ってます。

メンテナンスに時間がかかる、修正ミスがおきやすくなる、トラブルが増える、
トラブルの結果損失を被る、社会に迷惑がかかる。
と言うことで再度言います。

設計思想が古いとわかったら、作り直したほうが早い。</font>
部分的な対処をするのではなく。

そうは言っても、今回の東京電力を見てもわかるようにお金のかかることに
企業（いや人間は？）は腰が重いです。

で、結局致命的なトラブルが起きてからでないと、行動しないです。

簡易言語であるEXCEL・VBAでさえもこういう傾向にありますね。
割と簡単につくれるからと安易にシステム構築、プログラミングしますが、
結局肥大化して身動き取れなくなったEXCEL・VBAシステムをお持ちの
事業所がたくさん。

そして、その対応として仕事をいただける私は良いのですが、
どちらかというとそれは作り直したほうが良いんじゃない？という案件が
多いのが正直なところ。作業も実は複雑で面倒です。

結局、リーダーの決断が必要なんですね。その決断を企業に積極的に
勧めて行きたいものです。

災害対策もExcel開発も情報処理

２０１１年３月１１日。この日は忘れられない日になってしまいました。
私はまさに今回被災した地域で生まれ、親戚も相当数います。
亡くなった人はいなくて、良かった。

でもあえて言うと、やはり準備が足らなかったかもなとも思ったり。

過去のデータを考慮することや最悪の状況を想定して仕事や生活する。
これは長年やってきたシステム開発にもあてはまるなあ。

情報の管理、処理が今回ほど大事だと思ったことはないですし、
日本の場合は、まだまだ遅れていると感じました。

で、異論は承知で今回の失敗を書くと

①あの地域は明治２９年、昭和８年にも大津波を経験しているのです。
明治のは最大で３８Ｍの大津波、２２０００人の死者を出してます。
そしてそのとき以来「ここより下に家を建てるな」と書かれた塚がかなり立ってる。
しかし、それを無視して多くの人家、建物が海のそばに建てたのは過去の失敗を生かしていない。

工学院大学教授、東京大学名誉教授の畑村洋太郎先生失敗から学ぶ態度は
技術屋としては本当に参考にしています。

②原発は過去の津波の高さ、強さを考慮しなかったと言うことになる。

③三陸は陸の孤島と言われるくらい、山地が内陸の都市と海沿いの町を隔てています。
新幹線の駅を降りてから、車で３時間はかかるような場所でライフラインが寸断されたら
大変です。今回そうなりました。
ですから、ちょっとした発電、衛星電話、パソコンを各地域が装備していないことが失敗。

情報通信は大きな役割を果していましたね。
一番はグーグル。被災者の氏名を書き出した表を写真で集めてアップしたり、
被災者情報を書き込めるサイトを立ち上げていましたが、これには実際に私自身
親戚の安否確認で助けられました。

でもGoogleって一企業ですよ、それもアメリカの。国は表彰しないといけないくらい。

結局。すべて「スピードが命」だということですね。　

情報処理は全ての仕事を助けると主張している当ブログですが、

おおげさでも何でもないですわ

あらためて思い知らされますね。