しばらく出張しておりまして、ＢＬＯＧ更新が滞っておりました。申し訳ありません。
今回の出張は、とあるシステムの納品・現地設定・運用のご指導でした。システムをご利用になる方々が100名を超えるようなシステムですから、納品・現地設定と運用のご指導で丸々1週間かかります。さすがに私一人では無理なので、社員と分担しながら。
　

ご指導の際に、ご担当者が入れ替わり立ち代り、こちらとしては何度も同じ事を繰り返す様になり、結構疲れます。
しかし、熱心に聞いていただけるのは本当にありがたいことです。ＳＥ冥利に尽きます。
　

そういえば、弊社では操作マニュアルというものを作ったことがありません。
理由は3つ。

①メニューや画面レイアウト、注釈を工夫して、マニュアルなしでも理解できるようなシステム設計を心がけている。
　技術者として当然のことです。逆にマニュアルがあると、つい操作画面側で手を抜いてしまいそうになります。

②マニュアル作成は結構手間がかかるので、結局はお客様のご負担する金額に跳ね返ってしまう。
　マニュアルにかける費用をプログラムに当てたほうが余程生産的です。

③がんばって作っても、ほとんど見てもらえない。
　自分も家電製品や携帯電話のマニュアルなんて見たことないです。

じゃあ何で運用指導に1週間もかけるのか？ってよく言われます。
それは、
弊社の考える運用指導は、『システムの操作説明』がメインではなく、『業務改善指導』がメインだからです。
これは個人差が大きくて、なかなかマニュアル化できないんです。どうしても相手のお顔を拝見しながら対話しないと難しいんですね。

　 　 　

コンピュータのハード・ソフトに関わらず、トラブル対応をしていると、修理すべきかしないべきか、調査すべきかしないべきか悩む場面に直面することがあります。

本日もそんな一例に。
　

動作実績のあるプログラムが何故か正常に動かない。
現象から問題を絞り込もうとしても現象がまちまち。
トラップをかけて引数をダンプしても異常なしなのに。
10分程度調査した後、別の切り口で考えました。

問題なく動作しているケースと動作しないケースの違いは、OSのバージョンとそれに伴う各種モジュールのバージョンの差。問題が発生したサーバーだけが他に比べて古いことがはっきりしています。現象論で原因はほぼ特定できています。
　

対処方法は2つ。

①プログラムを書き換えて、旧OSでも動作するようにする。
②OSをバージョンアップする。

メリット・デメリットを比較し、担当プログラマとも相談し、
30分に限定し①をトライする。
それでも目処が立たなければ②にする。
という結論を出しました。
結局、30分では目処がたたず、②に。

　

となれば後は簡単。
営業的交渉と、スケジュール調整。
再インストールに必要な情報の収集とバックアップ等。

正攻法で修理することだけが正解ではなく、早急に結論を出してクライアントに不安感を与えないということもプロとしては大事な判断基準となります。

今回はそんな一例でした。

　 　 　

クライアントの業務改選の仕事をしていると、よくあるケースなのですが、お客様の社内に賛成派と反対派が出てきて話が進まなくなったり、こじれたりと言うことが多々あります。会社のことを思えばこその意見もあれば、ご自分の立場が大事だったり、自分の仕事を増やしたり変えたくないという方もいらっしゃいます。

個人的には、ご自分の保身の為に反対している方々のお気持ちも分からないでもない。会社の将来に反すると分かっていても個人やご家庭の都合を通したがる人達を裁く権利など、私にはありませんから。だから、聞かぬ振りをしたい。
クライアント、弊社、協力会社、さらにはクライアントのお客様全てがハッピーになる改善だとしても、実はクライアントの社内にはほんの少しだけどアンハッピーになってしまう個人もいらっしゃるんですね。

しかしながら、会社と会社の契約でお金をいただいて改善提案を請け負った以上、ビジネスなんです。個人的な感情は切り捨てなければなりません。
プロである以上、決して同情の表情や態度すら見せてはならないといつも自分に言い聞かせていますが、なかなか辛い仕事です。

言い訳させていただくならば、
長い目で見れば、業務改善せず何年間も放置すれば、ゆくゆくは会社の売上や利益が減少し続けたり、場合によっては市場から淘汰されてしまう、経営が成り立たなくなるという最悪の結末を迎える可能性があるわけです。
それと、多くの経営者にとって、業務改善＝リストラ　ではなく、最後の手段としてのリストラを実行しなくていいように、あるいは手の空いた人材をより生産的な業務にシフトさせることが目的なんです。

クライアントより先に私が精神的にくたばるわけには行きませんから、このポリシーは常に肝に銘じています。

後日、『あの時は反対したけど、今になるとやっていただいて良かったよ。』なんてお言葉をいただくと、本当に救われます。

　 　 　

足掛け7ヶ月にわたって提案・実施してきた、クライアントへの業務改善のゴールが見えてきました。
我々も開発で大変なことはよくあるのですが、コンサルティングを主とした、これほど長期に渡る案件は珍しく、精神的に疲れました。
お客様のご担当者も、日常の本業とは別に、社内の意見調整や、マスタ作成等の作業で相当にご苦労されたはずです。最後には、皆カリカリして社長を怒りとばす場面も・・・(笑)

不謹慎な発言かもしれませんが、クライアントと苦労を共にさせていただくと、友情に似た感情がお互いに芽生えてきます。ビジネスとして以上に、戦友としてお互いの労をねぎらう気持ちになってくるんですね。

さて、今回の仕事もあと2週間で完了！本稼動の日が楽しみです。

　 　 　

夜半からすさまじい雷雨。
生まれて初めてこれほど激しい雷音を聞きました。ピカッとしてからすぐに『ぐおおぉぉーーーん！』。おそらくすぐ近くに落ちたのでは・・・

弊社の入居しているビルは、電線もない(地下埋設)ですし、回線も光ケーブル、電源周りには雷対策用ブレーカーとUPS(無停電電源装置)をつけていますが、やはり気持ち悪いです。

なす術もなく2時間が経過、ひたすら雷雨が通り過ぎるのを待ちました。

個人的には雷は全く恐ろしくないのですが、サーバーのことを考えるとホントにヒヤヒヤします。
雷と聞くと反射的に『ビクッ』としてしまうのは職業病みたいなもんですかね？

　 　 　

今回はFedoraCore5でバーチャルドメインサーバーの構築に初挑戦。

namedの設定ファイルをひたすら作る・書く。ひとつのドメイン用のファイルが出来れば、後はコピーして文字列変換でOK。

httpd.confにVirtualHost設定を記述し、完成。

やってみれば意外とあっさり片付きました。

　 　 　

クライアントからよくあるお問い合わせ。

ブログや基幹業務のWEBアプリ入力中に、ブラウザのリセットボタンを押してしまったり、画面を閉じてしまったり、登録ボタンを押すのとは違う操作をしてしまい、入力途中の情報が消えてしまったのでなんとかならないか？というお問合せをよくいただきます。
残念ながら、登録前の情報が画面から消えてしまったものはどうしようもありません。ブラウザに依存するWEBアプリケーションである以上、プログラムで防ぐことも事実上困難です。

長文を入力する際には、メモ帳などのエディタに入力しておき、（もちろんこまめに保存しながら）文章を打ち終わってからコピーペーストするようにお願いしています。

こうすると、落ち着いて文章を作成できるので誤字・脱字も防ぎやすくなりますよ。

是非お試しください。