ども。
昨日、檜山の海岸線を車で走行中、猛吹雪のため道の駅でビバークを余儀なくされた担当ちゅんです。

情報システム部門で仕事をしていると、各セクションから「システム」のインストール作業をお願いされることが頻繁にあります。
特定の業務で使用する各種システムですが、多くは「Microsoft Access」ベースで動くデータベースで、システムのインストール手順の中にはランタイム版のインストールが含まれていたりします。

そんなシステムですが、本日はとある部署からSOS。話を聞くと「インストールをしてみたら、"なんだかかんだか"っていうメッセージが出てエラーになる」とのこと。

皆さん、想像してみてください。全く見たことも聞いたこともないシステムで「なんだかかんだか」ってメッセージが出るのです。これだけを頼りにトラブルを解消しなければならない状況におかれるのです。

はい、絶望です。

せめて「○○という文字が出ています」と言われれば、原因の探りようもあるのですが「なんだかかんだか」ではさすがにお手上げ。「申し訳ありませんが、PCをご持参ください」としか対処のしようがないのです。

こんな風に書くと「ひどいな～」と思うでしょうけど、この仕事では「なんだかかんだか」は比較的多いですし、職員の立場からすれば、十分に理解できる状況でもあります。
例えば「OSを起動しようとしたら、画面にガーって何かが出たんです！」とか。こちらにしてみれば、その「何か」を知りたいのですが、とにかく驚いてしまい、冷静に画面など見られないことと推察できます。なので、手がかりとなる「起動時のエラー」という部分で判断して、問題を解決できるかどうかが、情報担当者の手腕にかかっているといえるのです。

悪天候の中、あえなく「診察」が必要となってしまいました。

（投稿者：ちゅん）

ここ数日の大雪で、しっかりと例年並の積雪となってしまいました。大雪だった昨年に追いつきそうな勢いです。こんな状態ですので、車での移動も何時もどおりに行きません。余裕を持って安全運手を心がけたいものです。

さて、こんな冬はTV会議がお勧めです。導入以来、定例会議での利用も始まっている、例のTV会議システムですが、これはやっぱ冬だべさ！先日も、とある会議が公民館と熊石総合支所間で、TV会議システムを利用して開催されました。実はこの会議、冬場は交通事情を考慮して、メンバーが一同に介してではなく、八雲側と熊石側とて別々に開催されていました。しかしTV会議システムを利用すると、両会場間での意見交流や意思の疎通が図られます。実際に使った感想も「少し慣れたら問題なく使えますね。冬場はこれで十分です。」と、好評でした。イイですね！

夏場だって往復2時間弱の時間が、かなりMOTTAINAIと思うのは私だけでしょうか？
以上、着実に利用が増えてきているTV会議システムなのでした。

公民館と熊石総合支所間でのTV会議風景・・・TV少し高すぎじゃない？

（投稿者：９２）

ども。
「いつもブログ見てますが、もしかして[ちゅん]さんですか？」と声をかけられた担当ちゅんです。

今ではすっかり身近な存在になったWebメール。ご利用されている方も多いのではないでしょうか。
私も、プライベートではプロバイダのメールアカウントを捨て、携帯電話のキャリアメールを捨て、ついにGmail(Googleの無料Webメールサービス)一本にしてしまいました。

ちなみに、登録してある連絡先を眺めてみると、私の友人にはYahoo!メールを使っている人が圧倒的に多いようです。話の中でも「職場ではなくてYahoo!の方を教えて」なんて会話があるくらいです。いまやYahoo!メールがWebメールの代名詞となりつつあるように思います。
ですが、結局はどのサービスを使っても所詮はメールですから大差はありません。気に入ったもの、使いやすいと感じるものを使えばいいんですよね。

そんなWebメールですが、Microsoftのウェブメール「Outlook.com」が、2月19日から正式にサービスを開始したことを、ニュース記事で知りました。Microsoftといえばこれまで「hotmail」や「live」でおなじみでしたが、今後は「outlook.com」に統一されるようです。今ならまだ好きなアドレスが取れるかもしれませんね（私はこっそり取りました。運用予定はありませんが…。）

近頃はもうすっかり「クラウド」がブームなんですが、Webメールはまさにクラウドです。インターネット回線さえあれば、PCであろうがタブレットであろうが、はたまたスマホであろうが関係なくメールを見て、返事を書くこともできます。ウェブ上にあるので事故などトラブルにも強いなど、良いことだらけです。
一方、我が職場はといえば、メールは相変わらずローカルメールなんですが、これをどうにかクラウド化できないものかと、昨年の夏くらいから少しずつ検討を始めています。一番のネックはストレージ（保存）容量です。多い職員だと、ローカルに3GBとかって人がいますからね。クラウド上にそれだけの容量を確保するとなると、一体いくら費用がかかることやら。

システムをクラウド化するには、まずは仕事の仕方そのものを見直す必要があるように思っています。

Windows 8 チックな見た目の Outlook.com。ネットでは使いやすいと好評のようです。

とある所で、HUBの話になりました。有線でネットワークを組む時に、ケーブルを複数に枝分けするためにHUBという装置を使います。読み方は「はぶ」で「ふぶ」「ふび」とは言いません。文字で表記する場合も「はぶ」「ハブ」「羽生」とは書かず「HUB」と書きます。名前の由来は「車輪の中心」から来ているらしいです。そういえば自転車や車とかで「ハブ」って言いますよね。

このHUBを取り巻く用語に「L2スイッチ」「L3スイッチ」や「インテリジェント・スイッチ」とか色々と出てきます。それって何のこと？このHUBの話で盛り上がりました。

最近、普通にHUBと呼んで当たり前に使っているのは「レイヤー2スイッチング・ハブ」の事だったりします。では、純粋なHUBって何？・・・今では売られていません。これは業界用語で言う俗称「バ○HUB」の事で、正式には「ダムハブ」「リピータハブ」と言いますが、見たことありますか？例えば、このHUBを中心に5台のパソコンを繋ぎ、1番PCと5番PC間で通信をしようとします。1番PCから5番PCへだけ信号が流れれば十分なのですが、2～5番までの全てPCへ5番宛の信号を送るのが「バ○HUB」なのです。2～4番までのPC達は、信号をシッカリと受け取ってから、自分宛では無い事を確認し破棄します。このように無駄な作業が、PC側で発生します。おバ○ですよね～。昔？我が家で初めてネットワークを組んだ時（10BASE-Tの時代）L2スイッチなど高価で買えませんでした。当然バ○HUBを愛用してました。そもそもISAのNICが高かったですが！

そこで、HUBに繋がっているPC側NICのMACアドレスを、ポートと対応させてHUBが自動で覚える仕組みが生まれました。これが「MACアドレステーブル」と言うやつで、賢く必要なPCにしか信号を送りません。不要なブロードキャストを出さないので、通信効率も上がるのです。素晴らしい！この機能があるHUBをレイヤー2スイッチング・ハブと呼びます。でも今はこれが標準、当たり前の世界なのです。PC店で普通に売られているHUBは、全てレイヤー2スイッチング・ハブだと言うことです。今後はHUBのことを知ったかで「L2スイッチ」と呼びましょう！何かカッコ良いでしょ？！

ちなみに、L3スイッチを簡単に説明すると、L2に更にルータ機能を足したHUBとになります。（省略しすぎの声あり）興味のある方は、適当にググッて下さいませませ。（最近、マニアックな記事が多いとの声もあり？）

何故か持ってるバ○HUB、いや貴重なリピータHUB・・・でも外観では分かり難い？

（投稿者：９２）

ども。
先週末、またひとつ年を取った担当ちゅんです。

ネット上に興味深い記事を見つけました。

1980年代には「COBOLは衰退するので、ほかのプログラミング言語に移行しなければならない」などと言われた。しかし、銀行、保険会社、製造業、小売チェーン、医療機関といった大企業のミッションクリティカルなシステムは依然として大昔にCOBOLで書かれたコードによって運営されている。多くの企業はこれらのシステムを何度も入れ替えようとしたが、システムが全体が巨大で複雑な上、重要なビジネス・プロセスに統合されていること、また問題なく動いていることからこうした取り組みの多くは失敗した。

ITWORLDの記事によると、こうしたCOBOLで書かれたシステムを支えてきた団塊世代プログラマの引退が近づいているという

スラッシュドット・ジャパン デベロッパーより引用

「COBOL」というのは、事務処理用に開発されたプログラミング言語。当町の基幹系（税・戸籍などの主要業務）では別なシステムで運用してきていますが、まあ、似たようなものです。また、同業者どおしで話をしていて「うちは未だにCOBOLで自主電算」なんてのも耳にしたことがあります。これに対しては、別の文献で次のように紹介されていました。

自治体における情報化に関する組織体制は、情報化の歴史とともに変化してきた。
当初、大量の定型業務の処理を行うために大型コンピュータを導入した大規模な自治体では電算課という主管部署を設け、主にコンピュータの運用や保守が業務を行った。自治体の中には電算課内の職員が自らCOBOLでプログラムを作成し、情報システムを開発した事例もあり、税、給与等の各主管課と共同でプロジェクトチーム等を作成する場合もあった。もちろん、当初は電算処理を外部に委託している自治体が多かったため、電算課のような情報化担当部署を設置する事例は少なかったが、コンピュータの自己導入が増えたことによって、設置する自治体も徐々に増えていった。

自治体ITガバナンス実践編 第4章より引用

さて、引用ばかりでずいぶんと文字数を稼いでしまいましたが、ここからが本題です。
当町でも、次年度以降、いわゆる「基幹系システム」の更新に向けた業務が本格化していく予定です。長年使い続けてきた汎用コンピュータベースのシステムから、最新の「自治体クラウド」に対応するシステムへと大転換を図っていきます。

それで、最初に引用した記事では「組織の中にCOBOLを扱える人がいなくなることが問題だ」とされていますが、実は問題はそこだけではないような気がしています。と思って読んでいたのですが、同記事のコメント欄に、同じように考えている方の秀逸な投稿がありましたので、またまた引用します。

本当に必要なのは、COBOLを扱える人じゃなくて、
COBOLで書かれた業務を把握している人なのであります。

業務を把握している人がいなくなる前に何とかしてください……

まさに、これだと思っています。当町のシステムも、長年、担当者が変わりながらも徐々にノウハウを蓄積して今に至るという「職員が流した汗の結晶」のようなもの。これを、新しいシステムに移行しようとすると、まずは技術的な部分よりも前に、そもそもどんな業務があって、システム上ではどんな処理がされているのか、というところの把握が絶対に重要なんです。でも、大昔にカスタマイズされた部分などは、もはや誰も知らないもの＝ブラックボックス化してしまっています…。

ずいぶんと長々書きましたが、要するに「どこの世界にも同じようなことで悩んでいるSEはいるなあ」と、そういうことでございます。ITにも考古学者が必要な時代がきっと来ますね。

何十年も基幹系を支えてきたCOBOLは、ある意味ではすごい言語です。

（投稿者：ちゅん）