Outlook Expressのメール最適化

お客様から「Outlook Expressの最適化が自動的に動くんだけど、とても時間がかかった挙句にエラーがでる」というものでした。
出ているエラーは「Outlook Express またはほかのアプリケーションがこのフォルダを使用しています。」だそうです。

何か常駐しているのかな？　と思って、msconfigでサービスとスタートアップを全て無効にして再起動をしてみましたが、結果は同じです。
と、いうことは Outlook Expressの内部的な問題ということと思われます。

ネットで調べてみると、dbxファイルのサイズに関する内容が多く書かれていましたので、サイズをチェックしてみると1.3GBにもなってました。
お客様に確認すると、一度も削除をしたことが無いそうです。
１年以上前のメールを削除してもいいということをお客様に確認したので、削除をしたあとに最適化をすると、、問題なく最適化できました！！！　dbxファイルのサイズは600MBになってました。

もう１つエラーのでるフォルダがあったので、そのdbxのサイズを見ると800MB強です。
これも削除をすることで300MBになりました。

おそらく、最適化後の容量が800MB近くになると問題があるように思いますが、エラーメッセージの内容からは推測が難しいエラーですね。。

Windows Server 2008 Foundation

小企業、零細企業において、サーバーというものはとても高価なものに思えてしまう。
モニタ付のデスクトップパソコンが６万前後で購入できるのに対して、サーバーではOS自体が１０数万円もするからだ。
Windows Home Serverも悪くは無いが、ベースがWindows Small Business Server 2003なので、最新のハードには合わないケースも増えてきており、多くのコア数とメモリを持ったハードを使いこなすことができない。
そんな中、数日前にマイクロソフトから「Windows Server 2008 Foundation」というOSが発表されました。

従業員数15名以下の中小企業を対象とした低価格サーバOSで、OEMベンダーのハードウェアにプリインストールまたはバンドルの形でのみ提供されるそうだ。

制限としては、
・物理ソケット数が１つまで
・最大メモリが８ＧＢまで
・Hyper-Vが使えない
などの点があるが、小企業においては十分だと思う。
もちろんWindows Server 2008ベースなので、安定度も文句なしで、データベースソフトもインストールできる。

DELLからは、OS込みで５万円で販売するという話もあり、デスクトップパソコンを買う程度でサーバーを導入できてしまうのです。
ActiveDirectoryを使用しない場合、CAL制限も無いのでファイルサーバー、プリントサーバー、データベースサーバーとしては十分使えそうです。

運用開始後の手間を考えると、Linuxに十分対抗できると思います。

オラクルのサン買収

個人的には驚きのニュースが入ってきました。
『オラクルが74億ドルでサンを買収』
オラクルはご存じのとおり、世界的なデータベース「Oracle」をの会社です。それが、サンを買収したことによりMySQLも手に入れてしまいました。

MySQLはインターネット上のサーバー世界ではかなりのシェアをもっており、大規模なシステムも稼働しています。
同じことをオラクルデータベースで実現するとなると、ものすごくライセンス費用がかかるので、ネット上でのシステム構築では選択支としては有力なデータベースです。

でも、オラクル社にものになった今後、このまま無料でいくかどうかが微妙ですね。。
たとえ少しずつでも、使用のライセンス費用をとるとなれば多大な利益がでると思われます。
しかし、逆に独占禁止法に触れるという問題もありますので、そう極端なことはならないと思いますが、MySQLでいくかの判断はちょっと考えてしまうかもしれません。

 
大きな視点に切り替えて見つめてみると、 オラクルはここ数年はデータベースというよりもWEBやビジネスツールとしての展開（もちろんオラクルデータベースが基本にあるが）をしてきている。　言ってみればマイクロソフトのような総合的な会社として伸びてきている。
サンもハードはもちろん、Javaをもち、openofficeやVirtualBoxなどまでとクライアント側に必要なものを沢山もっていることから、この買収によってマイクロソフトと並ぶ大きな勢力になることは間違いないでしょうね。

今後の動きに要注意ですね！

SQLの中の全角文字について

最近の開発言語では、全角文字の変数を使えるようになってきた。
たとえば Visual Studioでは特に問題なく使えていますが、あまり使わないほうがよさそうです。
SQLでも同じで、項目名に全角が使えたりしますが、使えない文字もあるので注意が必要です。

一番の問題としては、コンパイラであればその機種でコンパイルして動作を確認すれば環境が変わっても動作するのですが、
プログラム中のSQLの場合は環境が変わると、データベースとのリンクを行うアダプタープログラム側の解釈の仕方によってはエラーになる場合があるのです。

ちょうど、今日、お客様のところでだけ発生するエラーがありました。でも私のPCから動かすと問題なく処理できます。
違う点はOSのバージョンとデータベースに接続するアダプターのバージョンでした。
色々とチェックして行き着いた点は、SQL中のselect文で「 MAKER_NAME as メーカー名」という部分でした。
これを「 MAKER_NAME as MAKER名」とすると問題なく動作します。

結局、アダプタープログラムのバージョンがお客様の方が古かった為に、「ー」の文字が記号というような認識でSQLとしてうまく処理ができなかったようです。

環境が変わることによりプログラムが動作しなくなるということはとても不安が残ります。
ですので、SQLはできるだけ全角は使わないようにしましょう。

Microsoft ACCESSのお仕事

Microsoft ACCESS 2007での簡単なお仕事の依頼がありました。
既にACCESS2003も販売されていないのでACCESS2007になったようですが、以前と画面が大きく違うので、使用説明やアプリ作成については再度勉強しなおさないといけないようです。

意外に驚いたのが、拡張子が mdb とか mde じゃないんですね。。今は、accdb とか accde になっているようです。
どういう点が違うかは以下のサイトに記載されています。
http://office.microsoft.com/ja-jp/access/HA100678311041.aspx

読んでみると以下の点が気になる変更点です。（他にもありますよ）

１.１つのフォールドに複数の値を持つことができる
　（ルックアップフィールド）

２.ファイルをデータベースに格納することができる
　（添付ファイル データ型）

この１については、今までのＤＢの概念が少し変わりそうな気がしますね。
また２については、情報蓄積するのにとても便利な機能といえますね。
※ただしデータファイルが巨大化しそうですが。。

画面だけじゃなく、中身も進化していたんですね。

どうやら今までの概念でアプリを作ると、新しい機能のメリットを受けられないように思います。
ここらで、きちんと勉強しなおそうと思います。

関連ページは以下にあります。
http://office.microsoft.com/ja-jp/access/FX100487571041.aspx

コンピュータにさせるべき仕事

いろいろとシステムの提案をしていて気をつけていることがあります。
それは『コンピュータにさせるべき仕事』をシステム化することです。

お客様からのヒアリングでは、「これをやってほしい」という要望を聞くのですが、わたくしはそれに付随する一連の作業（仕事）も含めてヒアリングします。
なぜ、そのような作業をやっているのか？　その手順でやるのはなぜか？　何時までにやらなければならないのか？

こういうヒアリングをしていると、だんだんとお客様も「なぜこのやり方なんだろう？」と思われることも多いようです。
実際のところ、今までの慣習や、引き継いだ手順をそのまま運用しているケースが多いのです。

ヒアリングの目標は、『わたくしがその仕事を代わりにできるか？』というレベルです。
お客様の仕事を理解し、わたくしのＩＴ知識とを融合させて要件定義書（提案書）を提出するのです。

その中には、たとえお客様の要望があっても、あえてＩＴシステム化しないという提案になる場合があります。
たとえばこういう内容です。
１.年に数回しか発生しない特別処理で、手作業でもそれほど手間がかからないもの。
２.状況により判断が難しく、判断ロジックが曖昧なもの。
３.ハードトラブルやインフラトラブルなどの場合の処理。
４.最終決定処理。
これらをＩＴシステム化することはもちろんできます。
しかし、ＩＴシステム化するのには費用対効果が低すぎるのです。
２４時間ノンストップであったり、人の命を預かるような場合は別かもしれませんが、ほとんどの会社のシステムはそこまで厳密ではありません。
システムを複雑化することにより、システムトラブルが増えるのでその抑止効果もあるのです。

では、ＩＴシステム化しないでどうするのかというと、これらの想定事態が発生したときの運用手順書を作成してもらうのです。
作成してもらうと言っても「作成しておいてくださいね」というのではなく、想定事態を私が説明し、こういう場合にはどういう手順で処理しましょうか？というように順番に聞いて
WORD文書に書き留めてゆき、最終的に運用マニュアルに付け加えするのです。
運用マニュアルはお客様に文書ファイルごとお渡しするので、後日変化した場合にはお客様で修正して頂くようにしています。

こういうお客様全体の仕事をコーディネートすることがわたくしの仕事だと思っています。

EXCELでのシステム構築

お客様からEXCELに関する質問をよくされます。
簡単な操作面ぐらいだといいのですが、VBAやマクロでコテコテに作られたシステムの改造に関する相談や、動きがおかしいから見てほしいというのもあります。

ゆっくり見てゆけば分からないことはないのですが、作りながら増殖していったようなアプリの場合は解析するだけで数日かかってしまいそうです。
そんな場合は「見てみましょうか？」なんてことを言うと大変なことになってしまいます。。
EXCELの関数やシートにさせる処理、マクロにする処理、VBAで記述する処理が複雑に混ざり合い、時にはWindows APIまで使っている・・。
『誰がつくったんだ！？プロ？』と驚くようなものもあります。

このような規模の大きくなったEXCELシステムに共通して言えることは、『これをメンテできる人がいなくなったら使えなくなってしまう』ということです。
データとプログラムの分離がうまくできていない為、プロでさえ解析に時間がかかるようなものを、作った本人以外がメンテナンスするというのは超危険なのです。
実際に会社としては必要のない人間だけど、社内システムを沢山作って他の人が触れないために辞めさせることができないという相談もよく受けます。

社員が作ればタダでできるという気持ちから得意な社員につくらせたようですが、今では仕事ではなく常に作ったソフトの改造やバグ取りに多大な時間と工数をかけているそうです。
その間も給料は払っているということなので、実際に会社が払った経費はとても高額になっています。
仮にこの人に給料を２５万支払っているとしましょう。　会社は社会保険などを含めて年間約３５０万以上ものお金をかけていることになります。
これだけの額ならば、５年リースで１５００万円程度のシステムを導入できてしまうのです。

こうならない為に注意する点があります。それは、数年先まで見据えたシステムの構想を練るということです。
とりあえずできるところからシステム化するのではなく、全体と最終目標を見据えたシステム化を少しずつ段階を踏んで構築するという方法です。
こうすることで目標を見失わず、全体にかけることができる費用とメリットが見えるようになるのです。

その結果、EXCELで構築してもよいかどうかは自然と見えてくると思います。
 

PowerEdge T605 メモリ増設

T605をRAM8GBで購入したのですが、開発で早く動作させたい仮想ゲストＯＳにはＣＰＵとメモリ割り当てを増やしたいと思ったことからメモリが足りないと思うようになってきました。。
そこでメモリ増設を行おうとしたのですが、どのメモリが問題なく動作するかの人柱情報が殆ど皆無なので、わたくしが人柱になることにしました。

現在のメモリは、「HYMP125P72CP8」というものが入っていました。
http://www.satech.com/hymp125p72cp8-y5.html

これから見ると、PC2-5300 667MHz (DDR2-667) 240 pin CL 5 1.8V ECC Registered 256Mx72 ということだったので、比較的安く買えるトラセンドで検索してみました。
まだ４ＧＢモジュールは高価ですし、とりあえず人柱だということもあって、２ＧＢモジュールにしました。
TS256MQR72V6U というものが上記スペックにぴったりだったので、３６００円で買えるみたいです。
これを２枚購入してみました。
純正でDELLで購入する場合は、２枚で約２万１千円なので、約３分の１程度です。

さっそく届きましたので先ほど挿入すると、難なく起動し８ＧＢから１２ＧＢになったのを確認しました。
また Server Administratorで、エラーも出ていないことを確認。

ということで、このメモリＯＫです！！
※仮想サーバーは大容量メモリにするので、やはりRegistered ECCが良いと思います。市場価格はノーマルとほぼ同じようです。

１つ嬉しいことがあります。　メモリを増設すると、なぜかファン２の回転数が下がり静かになりました。
原因は不明ですが、当初の８ＧＢメモリの構成だと２０００回転ぐらいだったのが１３００〜１５００回転程度です。この違いは騒音としてはかなり差がありますね。

続きを読む

階層型データモデル

弊社は長い期間に渡って、ＲＤＢＭＳでのアプリケーションを構築しています。
ＲＤＢＭＳではリレーショナルデータモデルで構成されていて、各データを表というものに整理し、それぞれの表の関係を定義する表現方法を行います。
レコードというものに情報を詰め込み、集合としてデータを扱う場合には使いやすいモデルです。

最近のＲＤＢＭＳではほとんどがリレーショナルデータモデルなので、関連する書籍も、情報を正規化して格納し、関連づけてＳＱＬで抽出するということを中心に説明しているようです。
このように整理された事務処理系には使いやすく、更新も簡潔でよいのですが、実際の現場の情報としては表現しにくい点もあります。
たとえば社員情報に所属部署情報を格納する場合ですが、兼任する場合などはどうなるでしょう。リレーショナルデータベースとしての推奨では、社員情報を複数持つか、部署と社員情報を連携させるテーブルを追加して関連づけるということになると思います。
こういう兼任のようなケースがある場合と無い場合では、設計やコーディング量が大きく変化しますので、最初にきちんとヒアリングしておかないと後で大変になります。

でも、実際の現場ではこのようなケースは普通にあります。
パソコンの部品でも同じです。１つのパソコンを作る上でいろいろな部品が必要になりますが、それぞれの部品を構成する部品が何段階にも階層的に存在します。
また、下の階層に行くと、他の部品や製品にも使われるものが多くあります。
このように、データを階層的に再帰的に（何階層とは決められない）見てゆくような場合や、複数のところで同じ部品を使う場合があるので、通常のリレーショナルデータモデルで表現すると、処理しにくいものになってしまいます。

ここで、昔にあった階層型データモデルという概念が活躍するのです。
しかし、階層型データベースに切り替えるということではありません。あくまでもリレーショナルデータベースで、階層型データモデルの格納を行い、再帰検索を行うのです。
ＳＱＬでの再帰検索は、SQL99に組み込まれ、オラクルはVer8の時代から、 SQL Serverは2005から可能になりました。

分かりやすいサイトがありますので、ここの「再帰SQL」を参考にしてみてください。
きっと、今まで生産管理や原価管理などで悩んでいたことがうそのように楽になりますよ。
http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_1b.html

 
こういうことが出来ない場合は、全データを読み取ってアプリ側で計算を作りこむことになっていましたが、こういうことができるのであれば、データとプログラムの分離がますます進んでバグも削減可能です。
SQLって本当に奥が深いですね！！

Windows Home Server で Oracle10gExpress構築の注意

Windows Home Server(以降WHSと呼ぶ) で Oracle10gExpress(以降OracleXEと呼ぶ)を動かす場合に、うまくクライアントから接続できない場合には、以下の点を変更してみましょう。

WHSでは、Windows Server 2003 Small Business Editionが実体なので、コントロールパネルの中にファイアーウォールの設定があります。
まず、これを無効にして接続可能か確認しましょう。

これでも繋がらない場合は、ちょっと別問題なのでここでは割愛します。
ファイアーウォールを有効にした時にだけ繋がらない場合は、例外設定で 1521 のポートを許可してあげるのですが、実はこれだけではいけません。
Oracle(XEだけではない) は、デフォルトでは 1521 ポートで、クライアントからの接続要求を待ちます。
デフォルトの設定では、クライアントからの接続要求があったら、新しいポートを開き、以降、そのポートを使用して通信を行います。
そのため、ファイアウォールで 1521 ポートを空けていても、新しいポートの要求はハネられてしまうため、接続できないことになるのです。
新しいポートはランダムで 1024から65000 の間を使い特定できないので、これらのポートをすべて許可するというわけにもいきません。

ですので、新しいポートに切り替えをさせない設定が必要になります。
この設定方法ですが、レジストリをいじります。（レジストリは間違って修正すると、Windowsが起動しなくなる可能性がありますので、自信と責任能力の無い方はやめておきましょう）

regedit コマンドでレジストリエディタを起動。
次に、「HKEY_LOCAL_MACHINE」の「SOFTWARE」の「ORACLE」の「KEY_XE」のところを開き、「新規」で「文字列」を選択。
値の名前に「USE_SHARED_SOCKET」、値のデータに「TRUE」を設定してから再起動をすると、1521ポートのみで通信をしてくれるようになります！！

尚、この方法は Windowsにインストールするオラクルで、OracleXEでなくても使えます。
間にファイアーウォールなどポート制限を含む場合に有効です。

とっても安い高性能サーバー

当社が深くお付き合いしているDELLで、今ものすごく安いキャンペーンをやっていました。
というのも、先日当社が購入したものよりも安そうです。
期日、台数限定だそうなので、高性能なサーバーを安く導入したい場合はお勧めです。
お勧めするのは、タワーサーバーのT605モデルです。
CPUはクアッドコアなので処理速度も問題ありませんし、CPUを２つまで（この値段で）増設できますし、何かと故障の多い電源も冗長化（２つ）にできます。
データベースサーバーや仮想サーバーを始めたい人は、ぜひ今の機会に検討してはどうでしょう。 
以下のリンクから、 「今週のキャンペーン」または「タワーサーバ」で「PowerEdge T605」を選択します。
どうです！？　安くて高性能なサーバーです！！
リンク→ Dell™ PowerEdge T605
今なら本体送料も無料のようです！

Brute Force Attack（不正アクセス攻撃）を受けてた・・

６日から７日の夕方にかけて、vyattaのルータに /var/log/message に5696件ものログインエラーログが蓄積されていました。。

Apr  7 01:54:05 vyatta sshd[22938]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=helios.equostech.com  user=root
Apr  7 01:54:09 vyatta sshd[22940]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=helios.equostech.com  user=root
Apr  7 01:54:12 vyatta sshd[22942]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=helios.equostech.com  user=root
Apr  7 01:54:17 vyatta sshd[22944]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=helios.equostech.com  user=root

Apr  7 18:32:36 vyatta sshd[25719]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=static-217-133-71-145.clienti.tiscali.it  user=root
Apr  7 18:32:41 vyatta sshd[25721]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=static-217-133-71-145.clienti.tiscali.it  user=root
Apr  7 18:32:46 vyatta sshd[25723]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=static-217-133-71-145.clienti.tiscali.it  user=root

Brute Forceとは「力ずくで、強引に」という意味で、文字どおり力ずくで暗号を解読して、パスワードを取得する攻撃手段のことを指す。
あらゆる文字の組み合わせで総当たりを試み、暗号の解読のためには考えられるすべての暗号鍵をリストアップして暗号文の切れ端を復号化できるか試みるという効率は悪いが長く放置しておくと認証されるかもしれないという危険をもっています。

最初の方はインドあたりからで、最後の方はイタリアやアメリカなどからも攻撃をされているようです。
こういうログが見えない（見ない）人は、知らぬが仏というぐらいルータというものが危険にさらされているものです。

放っておくと、制御を奪われて他のサーバーを攻撃する踏み台にされてしまうこともあります。
/etc/ssh/sshd_config で PermitRootLogin no としているのでログインはできないのだが、気持ち悪いものです。

また、VC5から可能になったWEB設定のついても、普段は不要なので delete service https [Enter] commit[Enter] save[Enter] としておきました。
先日、Vyattaルータを設置したばかりでまだ検知ツールを導入していなかったので、ちょっと焦ってしまいましたが、このように怪しいログについては早期に検知して、然るべき対応をとる必要があります。
とりあえずは、パスワードを十分に長く安全なものにし、辞書ツール（パスワードがいっぱいつまったもの）をかましても時間は十分に稼げるものにしておく必要がありますね。

サーバーの実力

サーバーを導入するときには安定や安全面、可用性、導入費用、運用費用などを検討しますが、そもそもどれくらいの実力があるのかも知りたいものです。
 
しかしメーカーのサイトには、何かと比較した資料というのはあまりなく、あっても１つ前のサーバーよりも数十パーセント高速などという表記が多いので、今回導入したものを実際にデスクトップと比較してみました。
 
デスクトップ用PCは、Windows Vista Business で RAM2GB、HDD320GB、CPU E6600です。
 
またサーバーは、DELL PowerEdge T605 で Windows Server 2008 Enterprise X64、RAM8GB、HDDは PERC6i で 1GBHDD×4のRAID10、Opteron 2378×2CPUです。
 
結果は、画像をみてください。

圧倒的にサーバーではHDDアクセスやCPUが高速です。。
特にRAID10では文句なしの速度が出ています。　RAID5やRAID6でもｙかったのかもしれませんが、耐障害性と消費電力削減を考慮して、WD10EACSを４つでRAID10としました。
１台あたり7400円前後だったので、４つでも３万円弱で買えます。

サーバー側のグラフィック関連の値がおかしいのは、リモートデスクトップで計測してたりしたのが原因です。

※サーバーの測定時には、ゲストOSを３つ動作中でした。

サーバーのリモート管理の重要性

当社はお客様にDELLサーバーをお勧めすることが多くあります。
DELL PowerEdgeシリーズでは、ある程度のシリーズからリモート管理ができるタイプになっていて、LAN接続された他のPCからハードウェアの管理をすることができるのです。
具体的には、BMC管理ユーティリティーというものが搭載された機種になりますが、これを使えばたとえ電源が入っていなくてもネットワーク経由でそのマシンのエラー状況の確認をしたり、電源のオンやオフ、イベントログの収集、センサーへのアクセスができます。

サーバーにハード的な異常が少しでも見つかると、サーバー前面のLCDが青色から黄色に変わります。こういうときにはリモートでどういう異常が発生したかを詳細にチェックし、メーカーにどの部品がおかしいからどう直せというような詳細な修理指示を出すことができます。
もし、こういう機能が無いと、現場に行ってdiagnosticsを起動してチェックし、それからメーカーへ修理指示をださないといけなくなります。
お客様の業務がその間停止してしまうのは避けないといけませんので、とても有効な機能です。

実際にはBMC管理ユーティリティーのIPMISHコマンドというものがあり、コマンドを入力することで色々な情報を取得します。
例えばファンや温度異常であれば、早急に終了させる必要があるので、シャットダウンをかけたり、計画的な停電があるのでリモートから電源をオフにし、電源復旧後にスイッチをONにするというようなことができるのです。

サーバーなんてどれでも同じということではなく、問題発生時に如何にすばやく客様の業務を復旧することができるかということを含めたサービスを提供してゆこうと思います。
※ちなみに、BMCに関してはDELLだけでなく、HPやIBMなどのサーバーにも搭載されている機種がありますので購入時にはチェックしてみてくださいね！

Vyatta VC5のGUI設定

昨年の夏以降、自社のルータはVyattaで構築しています。
昨年の4月に公開された VC4のバージョンではすべてCLI（コマンド入力）方式での設定でしたが、今回公開されたVC5のバージョンでは、初期設定はCLIですが、基本設定が終わってしまえば、ウェブからGUIで設定ができます。

CLIの場合は、TABキーを押したりしてどういうコマンドが使えるかを確認しながら半分手探りのような設定をした記憶がありますが、GUIの場合は必要なものが階層的に設定できるようになっているので、なかなか分かりやすくで良いですね。
また設定が少しでもある階層は上位階層まで太字で表示される点も慣れるとチェックもし易いです。
この設定は、set service httpsというコマンドをセットしてcommitするだけで使えます。
（もちろんsaveは忘れずに！）

 
ただ、個人的な意見ですが、いきなりの初心者はCLIの方がいいように思います。
何を設定したかの記録が残しやすいのと、実際に入力することで覚えるという（体で覚えるというやつ）ことができるからです。　慣れてきたころにGUIデビュー（普通は反対？）がお勧めです。
 
過去にVC4のバージョンをインストールしている人は、rootになって full-upgrade -k というコマンドを実行するだけでVC5にアップグレード可能なので、（自己責任で）試してくださいね（笑）

自分でルータの設定ぐらいはできるという人なら、下記のリンクのPDFに目を通せば（英語ですが）ある程度は使えるようになりますよ。
http://www.vyatta.com/downloads/documentation/VC5.0.2/Vyatta_QuickStart_VC5_v03.pdf

 

お客様の言葉

今日お客様のところで打ち合わせをしているときに、『なぜ幾つもの業者の中から当社を選択してくれたのですか』と聞いてみました。
このお客様はパッケージを含め、MicrosoftACCESS製のオーダー販売管理など多くの業者に自社システムの構築を依頼されており、パッケージやACCESS製のシステムでは大幅に安い見積もりと聞いていましたので、前からどうしても聞きたかったのです。

返ってきた回答は、大きく２点ありました。
少し表現の言葉は違いますが、１つは『処理速度の性能』で、もう１つは『お客様に対する熱意』ということでした。

他社は安いけれども、システム提案などがきちんとした資料が提出されず、ほとんどが口頭説明だったようです。
また、これから発展をしようとしている企業様に、末永く安定した処理速度を提供できるという点での説明まできちんとしたのも当社だけだそうです。

私は約１５年間は超大手のシステム開発会社で働いていたので、当然つくる（というより最低限に近い）資料を提出し、当然のようにお客さまの判断材料となる情報をきちんと説明したというだけです。
他社のやり方は知りませんが、安価でシステム開発をしているソフトハウスでは、きちんと提案書などを作成したりしないで、ほとんどが口頭説明だったそうです。

当社にとって一番うれしいことは、『最初にシステムを導入して頂くこと』以上に、お客様がこのシステムを通して効率化や攻めの営業をして頂き、『更なる発展をして大きく成長してくれること』です。
そして次のご提案もさせて頂けると考えております。
最初だけでなく、長くお付き合いすればするほど味のでるようなお付き合いを今後も心がけて実践していこうと思います。

J-Saasの販売管理と弊社のココナッツ販売管理との比較

■J-Saasの販売管理がサービスを開始しました。
そこで当社との比較をしてみたいと思います。

2009年4月1日現在、J-Saasにおける販売管理では、クリアワークス社様の製品があります。
仕組みはインターネットで提供していて、帳票はPDF形式またはCSV形式で取得ができるようになっています。
初期費用は 10,500円、訪問指導は 157,500円（３時間×３回）となっていて、販売管理だけを使用する場合には基本月額の3,150円（２ユーザまで）とヘルプサポートへの登録の3,150円（なくてもよい）が、必要になります。

５年間使った場合の費用は、10,500円＋157,500円＋（3,150円＋3,150円）×１２ヵ月×５年で、546,000円だけで済んでしまいます。
５人が同時に使用できるようにした場合は、ユーザ追加が１名あたり3,150円なので、３ユーザ分の追加が必要となり、毎月3,150円×３ユーザで、9,450円が追加となります。
9,450円×１２ヵ月×５年で567,000円が追加で必要になるので、合計で 1,113,000円 となります。

市販のソフトを購入しても、５ユーザともなるとサーバー機を導入したりする必要もあり、２００万円近くなりますので、そう考えるととても安く導入ができそうです。
 
■しかし、よく考えてみましょう。

最初に出した２ユーザでの運用レベルならば、市販ソフトならばサポートもつけて３０万円もあれば導入ができます。ということは、大量ユーザで使用し、サーバー機などが必要なレスポンスを求める場合でないと、逆に割高になってしまいます。

 
■弊社のココナッツ販売管理の場合

J-Saas版に比較し、弊社の導入費用０円プランのココナッツ販売管理システムは以下の点が優れています。
・インストール台数制限なし（同時使用も５台可能）
・カスタマイズが可能（基本範囲内なら月額費用内で対応）
・月額費用はすべてコミで下記(税抜)のみ。
　　１年目　　：28,000円
　　２年目　　：24,000円
　　３年目　　：19,000円
　　４年目　　：15,000円
　　５年目　　：10,000円
　　６年目以降： 8,000円
　※運用保守を含みます。
・サーバーをレンタルするのでレスポンスが高速、しかも故障時はすべて弊社が修理
・リモートメンテナンス付き
・データの遠隔バックアップサービス付き
・ドットプリンタ出力にも対応
・殆どの帳票はＰＤＦファイルとして保存が可能で、EXCELへの出力も標準対応
・メニューや機能毎の細かな使用権限、操作ログなどが記録可能
・御客様からの問い合わせ履歴確認機能
・レンタルなので途中解約も可能
・インターネットが使えない状況でもシステムは稼働可能

 

このように弊社のシステムは導入がとてもし易いのが特徴です。
弊社システムで一番メリットのあるのは卸売業や小売業の中小企業様です。この業種は得意先や商品点数も多く、納品書枚数も種類も多かったりしますので、パッケージ系の製品に運用を合わせるというのはなかなか難しいようで、途中で断念して相談に来られる方が非常に多いのです。
断念を決意するまでに調査にかけた社員の残業代などを考えるととてももったいなく思います。

 
■結論として

弊社はJ-Saasを否定している訳ではありませんが、あまりお勧めしない理由は以下にあります。
・J-Saasでは市販ソフトと同じでカスタマイズができない。
　※当初は導入できても、運用していくうちにあれこれと要望も出てきます。あとで追加や変更が安価でできるという点も重視した方がよいと思います。
・ブラウザで動作するタイプなので、素早い入力への対応ができない。
　※短時間に大量の伝票を発行するような会社ではまず使用できません。

 

従って、J-Saasが良いかどうかは会社の運用形態に大きくかかわってくるのです。
ソフトの仕様に会社の運用を合わせることができるかという点が非常に重要になってきます。
自社にとって使いやすく価値のあるシステムをどう導入する必要があるでしょう。

弊社は、２０年の経験から生まれた弊社の豊富な経験で、販売管理だけでなく、御社の専属ＩＴコンサルタントとしても活躍いたします！

不況のときの地固め

３月末で決算の会社も多いと思います。
昨日（2009年3月末）の東京株式市場の日経平均株価は、8,109円となり少しは回復してきているようですが、
１年前は12,500円前後、２年前は17,000円前後もありました。
昨年からの値下がり率は３５．３％となり、１年間で東証１部上場企業の株式時価総額が１３７兆円も減りました。

気の遠くなる額です。。

政府では補正予算の成立の意気込みを見せており大変期待しているのですが、上げ足をとろうとするニュース番組がこぞっていろいろと批判をはじめているようです。
高い出演料をもらえるからといって無責任な批判ばかりをしているコメンテーターも多く非常に残念に感じます。
そんな時間があるなら大手企業のことだけでなく中小企業の実態をもっと取材して、何が本当に必要なのかという報道などをしてほしいものです。そういう声こそが本当にみんなが知りたいことで、国を動かしてゆくことだと思います。

森田健作が大差をつけて知事になったことにもあるように、政治や思想ではなく正しい目をもって動いてくれているリーダーがもっと必要なのでしょう。
 

今こそ自社の強みを活かした発展ができるように地固めをする時期だと思います。
弊社はそういう中小企業を精一杯支援し発展して頂けるよう努めてまいります。

お客様の専属のＩＴコンサルタントとしてお気軽にご相談ください。

システム構築は保守での運用を前提に構築する

システムを構築する時に、生産性をあげる手法や、新しい手法を用いることがよくありますが、わたくしは一番に保守のし易さを考えて構築します。
一般的にシステムでは多くの機能があり、それぞれにモジュール化して別々に構築します。
それらを組み合わせて最終的な１つのシステムとするのですが、構築中および運用開始後にも各モジュールの修正作業は発生するので、変更点及び変更内容に影響をうけるモジュールや機能を洗い出してすべて再テストとなります。
この再テストが一番大変なのです。

できれば一度テストを完了したものは、できるだけ手を入れたくありません。
こういう場合に如何にすれば再テストを削減できるかということが重要です。これは単に手を抜いているのではなく、お客様にもバグ発生などのリスクを減らすメリットのあることです。

これを実現できれば保守の工数削減は十分に可能になります。

私が行っている方法としては、
『基本設計を完全に行い、プログラム設計時に機能分解とインターフェースを固める』という方法です。

機能１つ１つを独立させることにより、他とのインターフェースを決めてから構築する為、機能的な変更があってもインターフェースの変更などが発生せず、機能の閉じられた中だけでテストを完結することができます。
よく、構築しながらインターフェースを決めるという方がいますが、最後（完成後）にもう一度プログラムを効率よく作成しなおすぐらいの費用と期間の余裕があればいいですが、最終的には工数も期間もオーバーしてゆくことが多いようです。

また骨組を変えるなら大胆に行うということもあります。
骨組を変えるのに、変にフラグを追加して対応するなどの方法をとると、１年２年と経過していゆくうちにそういうイレギュラーな点が見落とされてしまい、その後に修正を加えるときに過大な手間がかかってしまいます。
骨組はシンプルにするということは守った方がよさそうです。

その他、実行モジュールを１つの巨大なＥＸＥやＤＬＬにしないということも重要です。
これはたとえ文言修正などの小さな修正であっても、再コンパイルによりモジュールすべてが置き換わるときの影響範囲を少なくする為です。文言などを格納するのを小さなＤＬＬや外部ファイルにもつことによって、メインのプログラムを変更しないで対応が可能になります。

次に、保守性を高めることで逆に不具合を出さないということです。
システムを構築する中でログを取得する場合がよくあります。最近のＨＤＤは容量が大きいので問題はないという見方もありますが、ログファイルが大きくなるとシステムに大きな負担を与えます。
まず１つのファイルが巨大になることによるファイルアクセスの負担。　ファイルが増えることによるディスクアクセスの負担。
そしてディスクフルによるシステム停止などのリスク。

必ず容量設計を行い、当初確保した領域の６０％を超えない運用や削除や別媒体への移動などの運用が必須です。
私の場合は６０％を超えた場合は設計自体を見直しし、何らかの次の手をうつようにします。
これはコード設計と同じで、たとえば１０００件で十分に足りるという要件でコードを３桁で設計した場合などに、数年の運用で６００件を超えた場合などは桁を増やす必要があるというものです。
昔は設計時にはバイト数を少しでも減らすようにコードには固定長の文字型を使う場合が多かったのですが、最近はデータベースでいろいろな型が使えるようになってきたので、数値型を使うケースが非常に増えてきました。
数値型で有効桁が８桁程度あれば、すべてコードは数値型というような設計もアリだと思います。
ただ、向かないのはNULL値が必要な場合です。　値が無いというNULL値も格納できますが、その場合は数値としての特性ではなくなった使い方が必要になるのでコーディング量が増える場合があるからです。

また日付型はあまりお勧めしません。　これは比較時に日付型に変換するなどのオーバーヘッドやコーディング量が増えるからで、わたくしの場合は日付と時刻をそれぞれ別の項目にして数値型で格納しています。

最後に、重要な点があります。　それはデータベースのフィールドにNOT NULL属性やDEFAULT属性などを効果的につけることです。
入力系のプログラムを構築すると気がつくと思いますが、入力時のチェックは大変厳しくします。
これは、おかしなデータがデータベースに入らないようにということですが、データベースは何もその画面からだけ情報が更新されるわけではなく、他の処理やバッチ処理、移行作業や保守作業などでも入力・変更されるものです。
この時に予期しないデータが入った為にシステムが異常な動作をしたという報告は意外に多いのです。

移行だけを担当しているような人は、どんな情報でもデータベースに入れればよいという考えの方もいますので、NOT NULL制約などは大変嫌がりますが、最終的に本番を迎えたあとはこれのおかげでどれだけ工数が減るかを実感すれば、つけるべきところにはつけるようにしましょう。
私は基本的に区分項目、数値型の項目には基本的にNOT NULLを付けます。　こうすることでコーディング時に、NULLかもしれないという不安がなくコーディングできます！

ある意味これもコーディング規約と同じと思います。

各社それぞれ持論があると思いますが、目的はお客様のリスク軽減のためです！！
それが自社の為にでもなるなら最高ですね！