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

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


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

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

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


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

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

Excelrです。

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

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

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

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


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


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

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

Excelrです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

原発：

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

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

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

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

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

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

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

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

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