2010年05月12日

社内の状況をよく観察することも大事

最近、別の会社の友人が、いつ電話しても忙しそう(というか大変そう)です。
全く余裕がないというか、電話でもわかる追いつめられた状況が伝わってきます。

まぁ、友人なので愚痴をこぼして辛さを出しているだけかもしれませんが、これは会社にとっては重大なマイナス要素です。

仕事を依頼する側からすると、追いつめられている状況に置かれた人には仕事は出したくないという思いがあるものです。
個人的な担当者が外に対して「自分は大変だ」という状況が見えているということは、仕事が一部の担当者に偏っていることを示します。
こういう状況は、担当者が自信過剰になっている場合がほとんどです。
「自分しかできない」、「他の人の尻ふきをしないといけない」、「このぐらいやらないと利益がでない」などという気持ちでいっぱいなのです。

で、こういう状況が長く続くとどうなるか。。
半数ぐらいのひとが会社を辞めたり、体を壊したりする状況をたくさんみてきました。

こういう状況で、会社のトップや上司はその担当者をどう評価するでしょう?

「あいつが勝手に自分で自分の仕事を増やしている」とか「もっと利益率を上げてくれれば。。」
という声もよく聞きます。
このように私のところには、トップから相談を受けることもあります。

本人に会うと大抵の場合、「超まじめ」、「知識より経験」、「頑固者」、「現場主義」という方が多いです。
気をつけないといけないのは、こういう人には部下をつけてはいけないということです。

というのはこういう思考回路の人は基本的に職人気質で、自分が最高で自分が誰からも頼られるということに重点を置いています。
お客様に対してもとても評判もよく、やらなくてもよい仕事までやっても苦にならないのです。
別の角度から言うと、お金より名誉ということです。
「いい仕事をすればお金はあとから付いてくる」
ということで今まであまり不自由をしたことがないのです。

こういう人が中間管理職になった場合、まず発生するのが利益意識の欠如です。
自分にどのくらい経費がかかっていて、どれくらい稼がないといけないとか、部下の経費はいくらだとかを意識させようと上司はさせます。
すると、今までやっていた経験を生かすことができないし、お客様に対してもうまく話しができなくなり、変なところで遠慮したり、会社に言わずに自分が個人的に何とかするという方法で逃げてしまいがちです。
なぜなら彼らは、途中からの交渉ができないからです。
こうなると、会社に対しては「うまく順調に行っている」と報告していても、実は電話で聞いている口約束が山ほどある場合も少なくありません。

担当者が過労で入院した場合などは、大抵こういう口約束が多く「○○さんがこれならすぐにやっときます」って言ってたというような話とか、「このぐらいは無料でやります」と言っていたということもよく聞きます。
そうして一旦その口約束が期日を過ぎて後手に回ると、弱みを握られたようにお客様のほうが強くなって次から次へ仕事が増えてゆくということになりかねないのです。

少しでも心当たりがある会社では、まず体制を考えましょう。
「年齢がこのぐらいなら管理はできる」などではなく、職人は職人の鏡になるものであって、会社の経営者にはなれないのです。

部下とぶっちゃけ話ができる環境を作り、「なぜできないのか」を部下に考えさせるのではなく、「こういう仕事だからできると思っている」ということをきちんと部下に説明しましょう。
当たり前と思っていることがとても苦痛な部下もいます。
使い捨てではない人材であればあるほど、その人がどういう仕事のスタイルでいけば幸せなのかを考えていく必要があるでしょう。

また、全く別の角度から見ると、こういう職人の人は社員ではなく「別の会社」を作らせることも1つの作戦です。
この場合、交渉という面や利益などについては全て自分の采配でできるようになります。
事実上は子会社のような位置づけであっても、独立採算で「自分が社長」になることはとても意味があります。
よくこういう話をすると「彼には社長は無理」と言い切る方も多くいるようですが、そういう方ほど部下のことを理解していない人が多いようです。
会社がどうなれば成功か?という物差しはそれぞれ違います。
数人の会社で、給料が少なめでも社員が幸せであればよいという方もいれば、毎年10%以上の成長がないと意味がないという方まで様々です。

力は十分あるのに、うまく能力が生かせてあげることができないと考えている方はこういう極端な方法も考えるとよいと思います。
posted by ミーズシステム株式会社 目面 秀信 at 08:47| Comment(0) | TrackBack(0) | SEとして

2010年01月07日

PCが続々と入荷

今週にかけて、ノートPCやデスクトップパソコン、サーバー機器や周辺機器が続々と入荷されてくる。
1月に納品する予定が数件重なったので、年末に発注したものが届きだした。
 
機器は新しいものがやはりカッコいいですね。
 
今設定しているノートPCは、ユーザの要望で Windows 7 の機器を設定していますが、最近のceleronは思ったより遅く感じませんね。 OSも Vistaはかなり不評でしたが、Windows XP に比べるとWindows7は使いやすさでは不便にも思いません。
 
デスクトップで特定業務にしか使わないPCはまだXPで買いたいというユーザも多いようです。
XPでよいならパソコンは3年間の保証をみっちりつけてもオフィス込で8万円でおつりがくるものもあります。
でも、特定業務以外にも使用するならWindows7がいいでしょうね。
 
とにかく届いたら真っ先にする作業が Windows Update、次に Diskの分割作業(C、Dに分けてシステムドライブの劣化や不具合を減らす)を行います。
それからウィルスソフトを稼働させて全スキャン。
再起動してデフラグを実行。
そしてこの時点でバックアップを取得しておきます。
 
こういった地道な作業を繰り返しながら、1つ1つお客様に環境に合わせて基本の状態をセットしていくのです。
この間、お客様毎のPCの付属品などが混ざらないように作業を進めていきます。
複数台同じPCをご購入のお客様は、付属品などで普段使わないものを箱に整理しておいたりして、とりあえず保管しておくものと、手元に置いておくもの、捨ててもよいものをまとめておきます。
こうした内容でも現場であわてないコツですね。
 
そしてこれらがある程度片付いたら、今度はサーバー関連の設定になります。
サーバーは普通のPCと同じようですが、気をつけるところがかなり違います。
サーバーは24時間稼働なので、まず停止しないこと。
次に停止したとしても、その時間を最短にして復旧すること。 また、データが幾重にもバックアップされていて、万が一の時にでもデータ消失や漏えいをしないようにすることが必要です。
 
こういう技術は弊社独自のノウハウがあるのであまり公開はできませんが、限られた予算の中でも、必要な処置はすべて行っておくというのが基本です。
「安いサーバーだかたデータが壊れても仕方がない」というのは通用しません。
安いサーバーだからこそ、壊れやすいので、データが壊れるというようなことが無いように十分な対策が必要なのです。
 
UPSの接続テスト、データベースの稼働テストを含め、サーバーはこの後、納品まで弊社で連続稼働運転の試験を行います。 この時点で何か問題があれば、納期を変更してでも対応し、絶対に問題が起きない確認をとってから納品をするのです。
 
サーバーもWindows Server 2008になってからとても楽になりました。
以前は安くするために Linuxを入れたりしましたが、そうすると安くはなっても管理はしにくいので、最終的にはお客様によいものを提供できているとはいえません。
ですがWindows Server OSも安くなってきましたし、安定もLinuxと変わらないかそれ以上だと思えるケースも増えてきました。
このWindows Server 2008は、本当に最強ではないかと思います。
外部からのリモートメンテナンスも、単独でできる機能をもっていますし、セキュリティー的にも十分です。
OSも64Bit版なので大容量メモリも扱えます。
 
以前にサーバーを置き換えたユーザ様は、サーバーのリプレースだけで処理速度が、十数分だったものが数秒になりましたということも聞いています。
ただサーバーだけの置き換えで、ここまで早くなるとは私も驚きです。
恐らく、ディスクアクセスの高速化、メモリの高速化、CPUの高速化の相乗効果なのでしょうね。
 
今月後半からは次々と納品が始まります。
運動不足なので重いものをもってぎっくり腰にならないようきをつけないとね。。(歳が歳だし。。)
 
あ、書き忘れましたが、弊社では今、パソコン買い換えキャンペーンをやっています。
何かをいうと、現在お使いのPCを下取りするというものです。
無名メーカーとか自作のPCはちょっと難しいですが、メーカー製品であれば、少しでも下取りをさせて頂いています。
最近はパソコンを捨てるのにも費用がかかりますので、お客様にはとても喜んで頂いています。
 
Windows 98や2000を使っていて、そろそろ買い換えたいという方も是非連絡くださいね!
posted by ミーズシステム株式会社 目面 秀信 at 19:42| Comment(0) | TrackBack(0) | SEとして

2010年01月03日

話すスキルと聞くスキル

今日は、沖縄のデザイナーNさんが私の自宅に遊びに来てくれました。
Nさんは普段は沖縄で仕事をしているので、連絡はいつもは電話かSkypeです。
それでもこちらが半分、あるいは3割ほど説明するとあとは色々なことを考えて自分のベストだと思う意見を言ってくれる方なのでとても話が通じやすいのです。

私が感じるのは、Nさんはデザイナーという仕事を通して『まだ形になっていない相手のもやもやとしたイメージを少しずつ明確に、それも客観的に絵に描いていくことができる人』だということです。
別の言い方で言うと、相手が気付いていない潜在的部分にある考えやニーズを聞き出すことができる人なのです。
こういうことが自然にできるようになるには、相当のスキルと経験が必要だと思います。


ビジネスにおいても、最終的には人と人とのつながりです。
そのためにはそれなりのコミュニケーション能力は絶対に身につける必要があります。
サラリーマンになって最初に学ぶビジネスマナーでは、挨拶や名刺の受け渡しなどを覚えますが、これらは最低限であっていわばルールのようなものです。
コミュニケーションとしてはその応用が必要となってきます。

SEやプログラマにとって、相手から情報を得ること、自分の考えを説明することは必須であり、こういうスキルは一般の人よりも高くなければならないと思います。
よく「人と会話ができない人はプログラマにしかなれない」というような言葉を耳にします。
私は少し違う意見をもっています。
私なら「人と会話ができない人はプログラマにはなれず、コーダーにしかなれない」と言います。

人と会話ができない人が果たしてプログラマとしてまともな仕事ができるでしょうか?
私はまず、ビジネスには使えない人だと思います。
もしそういう人でも「プログラマとしては十分できる」と思っている人は、恐らく自己中心的で、趣味の世界から抜け出しきれないのだと思います。
自分に自信のある方ほどこの傾向が強く、「資格なんてなくても仕事上では十分」と言って勉強を怠ったり、中途半端なプログラムを沢山つくっては飽きてまた別のことをしているなんてことが多いように思います。


話は戻って、Nさんとはとても話が通じやすく思います。
が、私もここ1年ぐらいはお客様から「目面さんは今まであったどんなSEよりも話が早い」と言ってくれます。
ただ単に嬉しいなぁと思うだけでなく、それは一体どういうことなのかを深く掘り下げてみた結果、分かってきたことがあります。
それは、私もNさんも『目的や結果(成果)が出るまでの全ての工程が見えている』ということです。
目的が見えていて、いつどういう情報が必要で、それまでにどんな課題や、クリアしなくてはならない問題があるかという情報が全て経験として頭の中にインプットされているということです。
プロジェクトを起こすときに、マスタースケジュールを作成し、次に業務フローやWBSなどでやるべき仕事を洗い出していき、設計、開発、試験、運用と進めていく内容が全て把握できているからなのです。


一人だけで仕事をずっと進めてきた人の場合は、スケジュールを作成しなかったり、WBSも一切考えずに適当に進める人も多いようです。
よく聞く理由には「規模が小さいから」とか「仕様がよく変化するから」といってたりしますが、こういうことを何度繰り返しても、きちんと話をできるようにならないと思います。
それは『思いつき』で仕事をしているからです。
ビジネスにおいては、PDCAサイクルを意識することでその製品やプロジェクトの精度や内容が向上します。
PDCAは、Plan(計画)、Do(実行)、Check(評価)、Act(改善)と言うように、Planがいい加減だと結果としてCheckができません。
仕様書が無いのにテストをしているのと同じです。結果としてDoのみとなってしまい、次の改善ができないのです。


話すスキルや聞くスキルの内容とPDCAと関係が無いように感じるかもしれませんが、PDCAを実践できない人に会話ができない人が多いというように感じているからです。

PDCAはなぜか日本では新入社員には教えていないことが多いようです。また、中堅社員にも教育していないことも多いようで、これらの知識が現場の仕事で勝手に知識として盗んで身につけるものと考えているようです。
その為、自己流のやり方が増えてしまい、中堅社員が大変苦労することになります。

管理職の仕事は売上や予算、実績、利益という分野においてPDCAそのものなのです。
PDCAを当たり前のように身につけていないと、管理職にはなれないのです。
そしてPDCAを実践するには、それらの内容を部下やメンバーと充分に共有し、目的を失わないよう何度も会話しながら実行して結果を出し、評価をしてそれらの問題点を共有し、改善に向けてみんなで力を合わせてゆく。

人と一緒に仕事をするということは、たとえそれが部下のように目下であっても、きちんと理解させなければなりません。
もしかしたら、部下がそのやり方を気に入らず、不満をもったまま仕事をしているかもしれないとうまくいきません。それなりに納得させる必要があります。
逆に部下の不満が一体何なのかも含め上司は聞きとる必要もあり、部下もそういう機会があればうまく伝える必要がでてきます。
押さえつけするだけではなく、色々な意見を聞きとる意味での会議をちゃんと運営することも大事です。
話す方もただ「イヤ」だけではなく、なぜ嫌なのかを説明する必要もでてきます。
このように、目的を同じにしたメンバーは、上下関係は無く、役割上の体制で動くことになります。年齢や役割の上下関係による言葉づかいなどは論外として、人と会話をすることがとても大事なのです。


こういう会話ができるチームは、必ずそれなりの成果を上げることができます。
また、ほとんどのメンバーが「またこのチームで仕事をしたい」と感じます。

これがうまくいっていないプロジェクトがある場合、以下の点を注意してみるとよいと思います。
・管理者がPDCAを実践しているか?
・PDCAの目的をメンバー全員に共有し、理解してもらっているか?
・メンバー全員がプロジェクトの最終目的、現時点の目的を理解し、実践できているか?
・いいたい事が言える環境、それを全員が聞いて理解・フォローができる環境があるか?


逆にこういう人がいるときは何らかの改善が必要という点もあげておきます。
・自分の思っていることをうまく伝えられないという人がいる。
・自分は説明したつもりでも相手に伝えられないという人がいる。
・相手の話を聞くのが下手という人がいる。
・話の途中で話題を変えてしまう人がいる。
・相手の話の腰を折る人がいる。
・思いつきで毎回言っている事がコロコロ変わる人がいる。
・自分の立場を守る為に嘘や不利益な話をする人がいる。
・結局何が言いたいかわからない人がいる。
・すぐに怒鳴る人がいる。
・暴言や圧力をかける言葉で相手をだまらせようとする人がいる。


こういうことを気をつけている会社は、訪問してもとても気持ちがいいです。
逆に、実践できていない会社は、入ればすぐに分かります。 若い人に悪影響を与えないよう、できるSE、できるプログラマが実践できていない場合は、早急に対策をするべきだと思います。

今までこれで大丈夫だから、これからもこのままでいいというのではなく、より良く会社を、チームを良くしていく為のコミュニケーション力を高めていきましょう!
posted by ミーズシステム株式会社 目面 秀信 at 17:57| Comment(0) | TrackBack(0) | SEとして

2009年09月25日

データ移行アプリは難しい

システム構築という仕事をしている中で、データ移行という仕事が一番難しく思う。
 
お客様のシステムの大幅変更や、以前使用していたアプリや、別アプリからのデータ取り込みなどを行う場合に行う作業なのだが、以前のシステムが長い年月運用していればするほど大変になる。
 
まず、データ件数。
 
 数十件や数百件程度なら、まだ手作業でも可能だが、数千件になるとミスなども考慮するとなんらかのアプリを作らないとかなり厳しくなる。
もちろん、アプリを作成したという時点で、試験項目の作成から試験、デバッグなどをすべて行っていかないとけないので、かなり面倒になる。
こういう場合、ツールというレベルでとどめておくようにする。
これは正式リリースをするものではなく、あくまでツールなので試験関連の作業は少なくてすむのだ。
なんだかへんな感じだけど、社内で使うツールとリリースされるアプリとでは天と地、シンデレラとトンデレラ、食べると食べられるぐらい差があるものです。
 
次に、データ内容。
 
以前のアプリがオーダーメイドで、何回もアップデートを繰り返ししている場合、そのシステムの中に蓄積されているデータの内容や格納方式が、バージョンによって違っていたりする。
この場合、アプリで単純に変換するわけにはいかない場合がある。
たとえば、途中で項目を追加した場合、それ以前のデータにはその項目はセットされていなかったりする。
バージョンアップ時に何らかの値(それなりに正しいもの)がセットされていれば問題ないのだが、なぜか追加されている項目が NULL を許すような設計になっていたりする。
 
それから、DB設計レベルの差。
 
これはかなりきつい。 以前のシステムを構築した人が、DB設計というものをいい加減にやってしまった場合や、知識だけで実践を考慮しない人だった場合。
たとえばデータパフォーマンスを考えない無謀な正規化だったり、まったく正規化されていないようなものまで。。
優れた設計者の場合、新しいシステムになっても、ほとんどDB設計は変わらないものです。
 
最後に、文字コードの問題。
 
古いシステムで機種依存文字や外字を使っている場合があります。
ややこしいのは昔のVBやそれ以前のシステムで構築された、Shift-JIS形式のデータ。
最近のアプリは極力unicodeを意識して構築します。
日本語でややこしいのは半角カナ。
Shift-JISなら半角カナは1バイトですが、Unicodeにすると1文字で3バイトになります。
可変長の項目は、バイト数換算で3倍のエリアを確保し、固定長の場合はそのままのバイト数を確保するのがよく用いる方法です。
固定長ではインデックスなどを張ったりするのに効率もいいので、コードなどは固定長にします。
しかし、なぜか固定長のコードを格納するエリアにも半角カナが入力できるシステムがよくあります。
この場合、固定長でも3倍のエリアを確保することになり、インデックス面では効率がよくありません。
 
私はこのような場合はコード体系自体を変換できないかの検討を行います。
あまりにも運用上の影響が大きい場合は断念しますが、新しいシステムではたいていの場合はコードも参照検索機能がついているので、コードに意味を持たせる必要がないのです。
 
このようにデータ移行は大変気を遣います。
 
でも、データ移行アプリを作るメリットもあります。
それは何度も実行できること。 
エラーや確認したい項目があればログに出すことで一括して確認ができること。 
お客様の旧システムをぎりぎりまで使用できることで、余裕ができること。
などです。 
 
新規は楽なんだけどなぁ〜っていつも思いますが、お客様の喜ぶ顔が見たいので今日も頑張ってます!!
 
posted by ミーズシステム株式会社 目面 秀信 at 08:23| Comment(0) | TrackBack(0) | SEとして

2009年09月23日

ネットワーク再構築

お客様においてネットワークが不安定になっている現象を相談されて現地に見に行きました。
 
ワンフロアにPCが9台、ネットワーク接続機器が5台という環境です。
PCは古いもの(NEC PC98)から最近のものまであるようで、1000BASE-T、100BASE-T、10BASE-Tの混在環境です。
 
人が増えてくるとなかなかシステムの画面が表示されなかったり、印字が遅かったりするそうです。
あと、たまにネットワークエラーも発生することがあるとも聞きました。
 
HUBを調べてみますと、5ポートの100/10BASE-T用のものが4つありました。
メーカーはバラバラで、安価なものから アライドのものまで・・(どんなLANやねん!)
 
何度かPCの配置換えをしたということでHUBとPCの配線を調査しますと、カテゴリ5とカテゴリ5eの混在で、かなりいい加減なネットワーク構築をされているようです。
「刺せばつながります」ということを聞いて配線したみたいですね。。
 
弊社からの提案は、HUBを8ポートのギガビット対応のもの×3台にし、サーバーとHUB、HUBとHUB間のLANケーブルをカテゴリ6にし、カテゴリ5規格(5eは残す)のケーブルは、除外するようにします。
また、各PCからサーバーへのアクセスはHUB経由を2つ以内 にし、PCが1000BASE-T規格であればサーバーとはギガビットで通信できる環境にします。
 
こうしておくことで、もしネットワーク障害が発生しても、その場所を特定したり、影響を最小限に抑えることができます。
 
接続機器が10台程度になったら、一度図に書いてみることをお勧めします!
posted by ミーズシステム株式会社 目面 秀信 at 09:47| Comment(0) | TrackBack(0) | SEとして

2009年09月05日

下請けの立場と仲介業者のレベル

大手から受託の開発の仕事を頂くことがあるのですが、この場合、お客様<-->仲介業者<-->弊社という構図になります。
この場合、弊社の立場としては、仲介業者の社員として動くか、仲介業者からの依頼の受託開発ということになります。
決して、お客様に直接弊社の名前を出すことはありません。

こういうケースは仕事を持ってきてくれるのでありがたいのですが、仲介業者がいい加減だと大変なことになります。
よくあるのは、仲介業者がシステム設計を行い、その仕様書でシステム構築する場合です。
仲介業者の優れたSEがおこなうのであればよいのですが、適当にその場その場で話をしているだけのレベルで仕様書が出てきた場合はかなり厳しいものになります。
A4用紙に2枚ほどのメモが仕様書になり、「明日の朝までに見積もりちょーだい」って言われることが多いのです。

こういうレベルでも設計を自分でやったからアプリ製造費用だけの見積もりをしてくれという人も意外と多いので、かなりこちらの見積もり作業は大変になります。
少ない情報からいろいろなことを想像し、リスクとなる分を少し上乗せしたり、ここまで対応すればいくらかかるとかなど複数の案を作成したりすると、1日はあっという間に過ぎてしまいます。

想像がつくと思いますが、こんなレベルでこちらからの金額に利益率を加算して客先に提出しているような場合が多いので、お客様に納入した後に修正してほしいという依頼が山ほど発生する場合があるのです。
最近は後から仕様書外の依頼が発生しないように、見積もり時点で制限事項などを明確に記述するようにしたのですが、それでも修正してくれないと困るという言い方もされます。
あまり1つ1つに費用がかかると言うと、次から仕事が来なくなってしまうことも不安なので難しいところです。

一番いいのは、仕様書のレベルや営業担当者のレベルにより、リスク分を上乗せしておくという方法です。

必ず仕様変更は発生するものとして考えるしかなさそうです。
でも、上乗せをうまく見積もりの明細に分散させないといけない・・これも気を遣いますね。。

 

で、2年ほど前に請けた仕事で仲介業者側の設計者が退職したことでとん挫したままになっていた案件があり、弊社は仕様書待ちになっているのですが、別の担当者が当初の設計と全然違う仕様書を作成してきたことで、DB設計からやり直しになるという最悪の事態に巻き込まれてしまいました。
が、まともにこんな要求はのめませんので、仲介業者の設計者と代表者に説明をし、わたくしが代わりにお客様に対して再設計とアプリの完成をすることを提案しました。
さすがに設計作業などが入るので無償とは言えないので交渉しましたが、破格でも現状よりマシと思い引き受けました。

お客様との打合せが4回、提案・再設計資料ページ数延べ約120ページ分の資料で説明することで、ごちゃごちゃの設計をシンプルにすることができ、当初のDB設計を有効に活用することで8月末に納品を完了しました。
1年以上とん挫していた内容でお客様ともめているレベルのものが、わたくしが設計に入ったことで設計、打合せ、製造、納品までを約2カ月で終了した実績を見て、仲介業者の代表者も理解してくれたらしく、今後の案件については客先打合せには同行させてもらえるようになりました。
ちょっとしんどかったですが、よい成果をあげられたと思います。

でも一番うれしかったのは、そのお客様から「途中から入って頂いたおかげで無事に稼働することができました。ありがとうございました。」という言葉が聞けたことです。
こういう笑顔をこれからも増やしていきたいですね。
posted by ミーズシステム株式会社 目面 秀信 at 10:21| Comment(0) | TrackBack(0) | SEとして

2009年07月10日

必要なのはお客様の業務に入り込むこと

昨日は、いつもお取引をしている会社のお客様へ2回目の訪問をしてきました。
このお客様は弊社とのお付き合いはないのですが、訪問する理由には以下のような経緯があります。
・別のソフト設計会社はすでに廃業している。
・このソフトはまだ完納していなかった。
・別のソフト設計会社から引き継いだ会社の設計者が色々と打合せをしていたが、1年経過してもシステムが正常稼働していない。

このままではかなりまずいということで、色々と相談をうけ、「とにかく一刻も早くシステムを早く正常稼働できるようにしてほしい。」ということでした。

こういう「火消し」という仕事は私は昔からよく依頼をうけます。
あまり嬉しい仕事でもありませんし、もちろん費用もほとんど出ないしリスクはあるという、はっきり言って迷惑なものです。
しかし、弊社とお取引している会社が困っていることなので、可能な限りお手伝いをするようにしています。

変な言い方ですが、こういう依頼では面白い発見もあります。それは、
・当初の設計者がどのように考えていたかが見えてくる。
・どういう経緯でつまづいたかがみえてくる。それが設計なのか運用なのか。
ということです。

自分の案件ではないもので、失敗プロジェクトを具体的に把握することができるというのは、設計者にとってはとても勉強になるからです。


今回の依頼の原因を追及すると、いくつかの問題が見えてきます。それは、
・当初提案内容と、開発していた内容が違っている
・課題が担当者間でのみ共有されているが、対会社としての共有がされていない
・基本設計をやらないまま、できるところから開発をすすめている
という点でした。

提案内容と開発内容が違うということですが、提案内容は営業マンが作成したものであり、お客様の業務などを確認していない「絵に描いた餅」状態だった為、現場に配属された設計者は、最初から「こんなのでは運用できない」ということで独自のシステムフローを考えて進めようとしていた。
この詳細は現場担当者と口頭レベルで共有していたが、文書としてのこらず、お互いの会社の責任者レベルまでも報告がなかった。
次に、基本設計をやらずに開発した点ですが、別システムとの連携を含んでいたのですが、別システムの動作がよくわからない為に、わかっているところから開発していき、あとで何とかなるだろうということで進めていた。

この結果、別の要因でこのソフト設計会社は廃業し、そこに依頼していた会社が代わりに引き継いだのですが、途中まで稼働している内容をみると、当初設計を全然概念が違うことに驚き、無理やり元にもどそうと色々といじっているうちに、どうにもならなくなってしまったようです。


ということで、前回にお客様の代表者と担当者と話をする時間を作ってもらいました。
また、失礼な話をお客様にするかもしれないが、それについても了承をしてもらいました。

お客様にまず会って話をした内容は
 ・このソフトは何ができるシステムとして依頼をしたのか
 ・現状をどこまで把握しているか
を確認しました。

やはり、代表者と担当者の把握内容は全く違っていて、誰も正確な状況は把握できていません。
その上、代表者も当初に依頼した内容と違う機能を求めているということに驚きました。

でも原因は明確です。
このプロジェクトにおいて、
・何が目的なのか
・今の業務がどのようになるのか(現状と導入後)
・何ができるようになるのか、何ができないのか
・運用でのルール
が明確ではないのです。

よーくみると設計担当者の書いた資料には色々なことがぎっしり書かれています。
でも相手側には伝わっていないのです。

ということは、資料を作成したり設計をしたとしても、相手側に正しく説明できていないということです。
例をあげてみると、法律のような言葉を並べているだけで、具体化した説明をしていないので、打合せをしても相手側もわからないので
資料がこれだけ沢山出てくるならば、ちゃんとやってもらっているという安心感で理解をしていないということでした。
確かに私が読んでもわかりにくいですし、よーく理解してみると矛盾も沢山ありました。
でも今さら「誰のせいだ」などと言っても何も変わりません。

ということで1週間後に再度、責任者と担当者と業務運用者を集めてもらうように依頼し、昨日お話をしてきました。
私が作成した資料は以下の内容で23ページ。
・目的
・大まかなシステムの流れ図
・1つ1つの業務がどのようになるかを1業務1頁に集約した図解の資料
・各業務での予想される運用課題と対処案
・守るべき運用ルール
です。
約4時間、この資料について1つ1つお客様とお話をして、お客様で確認していただく課題、弊社で持ち帰る課題などを明確にして、まら来週に報告会を開きます。


さすがに疲れましたが、お客様はこういう資料できちんとお客様がわかる説明をしたことを大変喜んでいただき、私に対して「本当にありがとうございます。今後も期待しています。きちんと運用できるよう頑張りますのでよろしくお願いします。」と言ってくださいました。

いつも通りのことをしているだけなのですが、やはりこう言ってもらえるとうれしいものです。


でも、こういう当たり前のことができないソフト会社のSEや、丸投げのコンサル会社も多くあります。
こういう会社に限って、一人前の大企業並みの費用を要求してきます。
もっとお客様の業務に入り込み、ITをどう活かすかだけでなく、業務をどううまく運用するかまでをやってもらいたいですね。

posted by ミーズシステム株式会社 目面 秀信 at 09:56| Comment(0) | TrackBack(0) | SEとして

2009年06月06日

焦ってSaaSにする必要はない

最近、なんでもかんでもSaaSやASPにサービスを移行してゆくケースが多いようです。でも、「なぜ、SaaSなのか?」と聞いてみると、「とても優れている上に安い」などのように、ある一部の事例で自分の会社でもそうなると思われていることが多いようです。

私は約20年、お客様の現場向けに業務アプリを提供しており、一部では Saas提供をしたことがありますが、向いている現場と不向きな現場がありました。

向いている現場というと、まずはインターネットが光ケーブルなどで十分な速度が出る環境があり、入力や表示内容が少量の場合です。

不向きなのは、高速に入力を行うような用途であったり、複写用ドットプリンタで伝票発行をしたり、ファンクションキーやテンキーだけで入力をしたい場合。
それに表示内容が多かったり、エクセルなどにファイルを抽出したい場合、ユーザ数が2〜10ぐらいまでの場合です。

私のお客様は、卸問屋や製造会社が多いので、基本的に情報量が多いことと、万が一インターネットが不通の場合に伝票発行ができないということが許されないので、やはり SaaSは不便です。

では、SaaSがなぜ騒がれているのでしょうか。 それは、インストールしなくても使え、毎月の使用料という形で安定した収益を得られるという提供側のメリットが大きいからです。
WEB系ソフトでは、サーバーを増やしたり増強したりするだけでユーザ数を増やすことができますし、データが一元管理されているので、問合せやトラブルも少なくなります。 メーカーは、某NT○○のような大手の企業にサーバー設置や料金回収を依頼することで、管理も楽に顧客を増やすことができます。
また、流通に流れないのでパッケージを作成することもなく利益率が高いのです。

要は、「提供する側のメリットが大きいので、少し安くしておきますよ!」というものです。

しかし、永く使う場合は逆に高くなったり、少し変更してほしいという要求にはこたえられないので、本当に良いかどうかは疑問です。

営業マンやセールスなどに、安いからとか便利だからということで勧められている場合は、本当に自社でも有益なのかということを判断しないといけません。
昨年、SaaSを導入してみたけど、”結局使いものにならない”ということで弊社に依頼のあった企業もいくつかありますが、事前に説明がなかったようです。 恐らく、新しい市場ということで、お客様の業務も知らずにただ販売しているという ”にわかSE” のような方が多いのではないでしょうか。

posted by ミーズシステム株式会社 目面 秀信 at 06:19| Comment(0) | TrackBack(1) | SEとして

2009年06月05日

価格が安いPCを買うということ

パソコンやサーバーなどの機器の価格が年々安くなってきました。
 
お客様に提案していても、「もっと安いのが新聞に載ってたよ」とか「近所の大手量販店で安売りをしていた」など、確かに安いPCの広告がたくさんあります。
 
しかし、”動けばいい”というレベルのものがほとんどのように思います。
 
というのは、これら安い価格のものは、”故障しない” とか ”壊れない” 場合には安いからです。
 
今まで数百台のPCを保守してきましたが、安いPCで5年間で何事もないのはほんの一握りで、3年目あたりから問題が発生してくる場合が多いです。
問題個所は様々ですが、マザーボード系や電源系トラブルが多いように思います。
これは恐らく、能力に対してさせる仕事が大きすぎるのが原因で、ほとんどは熱対策だと思います。
 
また、安いPCでは修理が持ち込み1年間などの場合が多く、修理するためには数週間の間使えないということもあり、ちょっとした故障(CD-ROMやキーボード)では修理もしないケースが多いようです。
そういう点、ビジネス用PCではオンサイト保守がついていることが多く、最初から3年のオンサイトがついているような機種では、メーカーもよい部品を使っているようで故障率も激減します。
 
オンサイト保守をつけると、少し価格はあがりますが、1万円から高くても2万円までです。
最終的にお客様のビジネスを守ることができるので、わたくしはこの保守なしでは提案は一切しません。 
それでも安いPCがいいという場合は、自分で購入していただくようにしています。
 
しかしこの場合は、故障の箇所にもよりますが、修理期間中にはPCが減ることと、2年目以降の修理には、1回数万円(2万から7万程度)の費用がかかってしまうのです。
 
 
また、変な言い方ですが、安いPCで良いユーザもいます。 CPUが高速でメモリが多くあるPCがほとんど無用なユーザです。
ちょっとオフィスソフトを使うのと、ほとんどがネットとメールしか使わないという場合です。
こういうときは部品の良いシリーズで、CPUランクを下げ、メモリを少なくするという方法にして価格を安くするのです。 決して基本性能が悪いPCは選びません。 こうすることにより安いけども安定した運用が可能になります。
posted by ミーズシステム株式会社 目面 秀信 at 06:26| Comment(0) | TrackBack(0) | SEとして

2009年05月29日

TV買い替えという節約

液晶TV買い替えでの節約という考えで、面白い記事をみました。

 

大型ブラウン管TVを今でも使っているという方は多い(私がそうです)ですが、液晶TVに買い替えをすることで、大きく節約ができるということです。

通常、いくらエコだとしても電気代の差は微々たるものです。それでTVを買い換えするのに20万したとしたら(42型液晶TVの最近の価格)、元をとるだけでも何年、いや何十年もかかるではないか!? と思います。

でも、電気代以外にも節約ができるのです。 

それは、、

30型クラスのブラウン管TVの大きさに理由があります。このサイズになると、TV台もそこそこ大きなものになります。

これを同等サイズの液晶TVに変えると、面積にして約0.4〜0.5平方メートルの節約を行うことが可能なのです。

もし、あなたのマンションが3000万円で約75平方メートルの居住床面積とした場合、TV設置の面積削減効果は全体の150分の1になり、約20万円の節約になるというものでした。

こういう計算だとTV購入金額がタダになるというようなおどろく計算です!!

よーく考えてみると、微妙な選択ですが、もし迷っている場合には自宅での設置スペースの費用という面で検討してみてはどうでしょうか。。

posted by ミーズシステム株式会社 目面 秀信 at 08:25| Comment(0) | TrackBack(0) | SEとして

2009年04月16日

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

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

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

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

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

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

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

こういうお客様全体の仕事をコーディネートすることがわたくしの仕事だと思っています。
posted by ミーズシステム株式会社 目面 秀信 at 09:08| Comment(0) | TrackBack(0) | SEとして

2009年04月14日

EXCELでのシステム構築

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

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

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

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

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

その結果、EXCELで構築してもよいかどうかは自然と見えてくると思います。
 
posted by ミーズシステム株式会社 目面 秀信 at 17:54| Comment(0) | TrackBack(0) | SEとして

2009年03月26日

設計工程の大切さ

ある程度プログラムに自信のある人は、設計書を作成しないでシステムを構築するタイプの方が多いようです。 『仕様書を書いてもどうせ変更になるから後で作成する』ということをいう人が要注意です。
 
住宅などを建てるときでも同じですが、構造の設計や基本的な機能の設計があいまいだと、必ずどこかにしわ寄せがきてしまいます。
また、ある程度完成してから不整合な点が見つかった場合など、フラグなどを用いた危険なコーディングをして「完成したら見直そう」などと思いながら闇に葬ってしまうケースも多いのではないかと思います。
 
私はほぼパッケージに近い案件であっても、必ずその案件ごとに設計書を作成します。
もちろんコピーして修正という作業が中心です。
帳票設計、画面設計、DB設計とここまでできればプログラムは80%は完成したも同然です。
あとは一気にコーディングに入り、テストをこなしてゆきます。
 
もし途中で仕様が変更になる場合も、必ず設計書を修正してから変更履歴を残します。
 
手間がかかるように思いがちですが、設計書を後で作成した方が効率がよいなんてことはまずありません。
要は、必要な設計は手を抜いてはいけないということです。
プログラマ経験しかない人は、必要な設計書を書いた経験があまりないから、ややこしいものを大量に作成しないといけないと勘違いしているのです。
 
やるべきことは昔から、アウトプットを固め、そこから画面や機能を設計し、DB設計に入ります。
帳票設計、画面設計、DB設計が確定すれば本当に80%は完了なのです。
 
また、設計書がないとテストができません。 ということは、設計書を作成しない人は、テキトーにテストを行っているということになります。
 
かっこいい設計書が書けなくても、
・何を出力することができるか
・どういう風に入力(運用)させるか
・どういう形式でDBに格納するか
ということが、人に伝えられるものであればよいのです。
 
もし、これを読んでいるあなたがソフトウェア開発会社に仕事を依頼することがあれば、設計書を見せてもらうことをお勧めします。(設計書を納品してもらうのは費用がいるので、見せてもらうだけがよいでしょう)
その設計書が、わかりやすくまとめられている会社なら品質は安心できると思います。
逆に「プログラムがそのまま仕様書」などと言われたら要注意ですね。
posted by ミーズシステム株式会社 目面 秀信 at 00:22| Comment(0) | TrackBack(0) | SEとして

2009年03月07日

バックアップと暗号化

私がメインに作成している販売管理は、基本的にはサーバーというものがあって(クライアントと同じPCにセットすることもありますが)、複数台のPCから処理ができますが、やはり万が一の場合を考慮して、サーバー内だけでなくクライアントにもデータのバックアップができるようにしています。

この場合、このバックアップファイルを持ち出しされてしまうと、結局すべてのデータが外部で見えてしまいます。

こういうことを考慮して、バックアップしたファイルは暗号化して保存するようにしています。
(それ以外に圧縮なども行います)

しかし、暗号の2010年問題にあるように、今の進歩でいくと甘い暗号化では解読されてしまいます。
そこで、現在広く使われているAESを使うことにしました。
理由は、.NET Frameworkでサポートされていて、速度も速くて強いということからです。
ちょっと難を言えば、AEC(Rijndael)は、.Net Framework 3.0以降で対応ということですね。。 
この時点で、Windows 2000は対象外です。(Win2Kは.NET FW2.0まで)


しかし、これも数年後かには変えないといけないでしょうね。
posted by ミーズシステム株式会社 目面 秀信 at 13:44| Comment(0) | TrackBack(0) | SEとして

2009年02月24日

確かにチェックが甘い気がする

アメリカでの調査で、退職社員の6割が社外秘情報を持ち出ししているそうだ。
 

私も何度か会社を変わっていますが、確かに機密情報に細かく言われる普段と違って、退職時には一切のチェックもなかったですね。

逆に会社で処分する資料が多い方がうるさく言われたような気がします。

かといってやめた会社の情報を活用するようなことは一切ないので、ほとんど何もかも後輩などにあげたりしてきましたね。。

アメリカは似たような業種へ変わるということが多いようなので、おそらく持って帰ることがプラスになるんでしょうね。。 あーこわいこわい。


内部犯行にはやっぱり弱いのが現状でしょうね。

posted by ミーズシステム株式会社 目面 秀信 at 13:20| Comment(0) | TrackBack(0) | SEとして

2009年02月11日

無線LANと非同期通信

もうすぐ本番が始まるユーザ様に、半年前に実験的に無線LANを置かせてもらいました。

実験目的としては、同期通信を行うC/Sシステムが安定して動作するかというものでした。

無線LANの中ではかなり電波の強い、IEEE802.11nでしたが、結果はたまにネットワークに接続できなくなることが発生するという現象があり、何度かリトライを行うとつながるという現象があり、使用には不安が
のこりました。

おそらく原因は以下のように推測されます。
1.お客様の会社が住宅密集地であること。
2.お客様の会社が木造で、外からの干渉を受けやすいこと。

以前に私の事務所でも発生しましたが、ある頃から無線LANがつながりにくくなって、無線LANのアクセスポイント一覧をツールで検索すると、20個近いアクセスポイントがあり、802.11nという強い電波のもつ近所の機器の方と干渉してエラーになっていたというものでした。

このように、本来は問題がない機器なのですが、周囲の環境でうまく動作しない場合がありました。

提案する場合には十分に気をつけましょう!

ちなみにこういう通信について、非同期通信をサポートしている(http通信みたいに)ものは、こういう場合も
リトライ回数を増やすなどをすれば運用は可能だと思います。
しかし、データベースなどにセッションを貼って独自のプロトコルで通信するような場合は、一度セッション
が切れるといけないので、ソフトウェアに工夫が必要になってきます。
posted by ミーズシステム株式会社 目面 秀信 at 08:16| Comment(0) | TrackBack(0) | SEとして

2009年01月19日

リーダーの責任と権限と報酬

中堅クラスの会社になると、プロジェクト単位でリーダーとマネージャーが割り当てられるようになります。

小企業でも同じようにしている会社も多くあります。
しかし、ここで社内で上司が占める割合が大きい場合にはマネージャーは課長など管理職が行い、係長クラスまでの比較的若い層がリーダーとなる場合が多いものです。

マネージャーが今までにリーダーを経験し、マネージャー自体が部下を育ててゆこうと考えているケースでは結構いい関係が築けているのですが、マネージャークラスが自分の立場を守ることに必至になっている場合、リーダークラスをうまく利用しようという関係になっている場合が多いようです。

いろんな会社に派遣で入ったとき、それに以前に勤めていた会社もそうですが、マネージャークラスは、下のものがどうあがいてもかなわない絶対的な権力をもっていました。

素敵なマネージャーもいるのですが、本当にすばらしい人はもっと上の部長クラスになってしまうので、課長クラスは昔から居残り組のような『出世もしない万年課長』のような人が多かったです。

こうなるとややこしいのが、リーダーの持っている権限になってきます。

リーダーはそのメンバーをまとめ、プロジェクトを進行させる役割をもちます。
しかし、費用にかかわる権限はほぼゼロに等しいので、マネージャーに相談します。
しかしマネージャーはリーダーに任せた時点で、今年の自分の仕事はほぼ終わっているという考えでいるので、追加の費用が必要だったり、納期が遅れて回収が遅れることを極端に嫌いますし、そもそも常にプロジェクトの状況を把握していないので、部長にも説明できません。
その上、リーダーとまともに話をすると勝てないので話をしたがらないという場合もあります。

実質こうなるとリーダーは持っている権限をうまく使うことができず、ただプロジェクトを進行させるだけの駒
となってうごくだけになります。

しかし優れたリーダーであればあるほど、リーダー独自の判断でこれを乗り越えようとがんばってしまいます。
そして結果としてプロジェクトは何とかできてしまうので、マネージャーも「あれでよかった」と思ってしま
います。

一番まずいのは、こういう都合のよいリーダーを、そのマネージャーが放さないこと。

なぜかというと、権力というもので抑え込めば、あとは勝手にやってくれるから。

私の場合も上司はどんなことがあっても私を下において権限と報酬をほとんどくれずに働かせました。
他の上司に変わりたいという希望も、事前にあれこれと手を打たれていて、まともなかけ合いができないのです。


あとで分かった話ですが、上司は自分が下をまとめる能力が少ないのに上司になってしまったことで、そうするしか生き残れなかったようです。

私が退職する意向を伝えて確定したあと、数か月で上司も退職(転職)していたようです。


このようにどうしようもない人間関係になってしまい、それに縛られて本来の自分を活かせる仕事ができなくなる場合があります。

こういう場合は、自分の周りの人間関係を図で書いてみて人に説明するプレゼン資料を作ってみるとよくわかります。
(あ、名前は仮名にしたほうがよいです。。)

うまく行かない場合は、ほとんどがお互いの利害関係が影響しているものです。


本来であれば、プロジェクトを通して、それぞれが自分のもっている権限をどう活かせるかを真剣に検討し、相手になっとくさせ、自分の責任の下で指揮する。
その責任を全うさせた上で、その対価となる報酬を受取れるのだと思います。

部下を使うとき、および一緒に協力して仕事をするような場合は、最初にお互いの権限と責任、報酬などを明確にしておく必要がありますね。
posted by ミーズシステム株式会社 目面 秀信 at 09:29| Comment(0) | TrackBack(0) | SEとして

2009年01月10日

仕事を任せるという責任

仕事ができる部下がいる場合に、よく上司で「お前に任せるから頑張ってくれ」というような場合がある。

これは確かにすごくうれしいことなのだが、スーパー勘違いをしている上司が結構いる。

それは、失敗したときによくわかる。

「なんでこんなことになっているんだ?」
「お前のことを信じて任せたのに、なんてことだ」

こういう言葉がでてきたら要注意。
これらの言葉には失望と不信感がつまっている。
もちろん、今後はいい仕事はさせてもらえることはないと思う。

だいたいこういう上司は、他人に任せたといって成功した事実を自分の成功として自慢げに話しをし、失敗したのは部下のせいにして、あいつのせいで大変な目にあったという言い方をする。
事前に部下から報告書に問題があることを書かれていてもそれを問題と読み取る力がなかったりすることも原因。
ひどい人だと、元々自分が苦手な仕事なので、自分よりもうまくやってくれそうな部下に仕事を任せるというようなこともあります。
もちろん報告書なんて提出しても目を通すこともない。
こうなれば、うまくいくかどうかなんて運次第というようないい加減なものです。


本来、人に仕事を任せるということは、失敗しても自分が全て責任を負うという覚悟で行うものです。
だから自分が絶対にできることで、間違った方向にはいかないようにきちんと道筋をたてた上でやっておくのが当然のことです。

実際には、任せた部下がかえったあとでも、その状況が手に取るようにわかるように、報告書のチェックをしたり周りの人からヒアリングをしたりして、本人からアラートが上がりそうであれば、事前に手を考えて報告が来るのをまつというようにしたりします。
部下本人が一人で頑張ってやっていると思いこんでいても実は上司の手の上で走り回っているだけというような感じです。

これはでは忙しくなるばかりではないかと思う人は、まだ修行が足りません。。
なぜなら、なぜ部下に仕事を頼むかということを理解できていないからです。

自分の手が足りないから部下に頼むというのは事実ですが、本質的には、なぜ手が足りないかということにあります。
それは自分が部下がやること以外の仕事もたくさんもっているからです。
このまま放置すると、仕事が回らなくなってきます。
だから、部下に自分の仕事をやってもらえるようにするのですが、それは自分の仕事がステップアップする為に時間をつくる1つの手段なのです。

部下と同じ仕事をやっているのであれば、いつか部下から煙たい存在になりますが、部下の1つ上の仕事に常にチャレンジしている上司はいつまでも素敵なのです。

何年たっても同じことをしているという方は一度自分の仕事の仕方を考え直した方がよいかもしれません。
そうしないと、部下はいつまでも自分が一人前にはなることができないから、自然と会社を辞めてゆくのです。

また自分がいつ病気やけがで倒れても部下が支えてくれるかということもあります。
惜しまず、自分のやっていることを部下に権限移譲してゆき、自分がもっと上の立場になるような仕組みを作るようにしましょう。

そう考えれば、最初に書いたような、部下をダメにするような言葉は口からでないはずです。

任せるということが大事な仕事であるということ。
そして、任せるにはその責任をすべてとるということ。
これを考えれば、報告書や進捗などがどれだけ大事かが理解できると思う。


こういう報告書や進捗管理を行っていない会社では、部下が突然悲鳴をあげて、プロジェクト炎上という事態
になる場合が多い。
私はこういうプロジェクトを何度も火消しとして回された経験がありますが、ほとんどこういうケースで共通しているのが、プロジェクトマネージャーがプログラムの内部を触ったりするような超ベテランの場合です。

彼らは「自分がなんとかできる」という自信をもっているということと、自分がやらなければほかにはだれもできないから報告も上げられないし、あげても上司から頑張れとしか言ってもらえないからだ。

そしてこういう人が自分のやった責任の重さに耐えられずに会社を辞めたり、病気になったりして大赤字を出す。
という具合だ。

これは企業にとってとても痛い。

こうならないよう、他人に任せた場合では、必ず定量的な報告と、その報告が本当に正しいかを見極め、然るべき対応を早めにとる決断力が必要と思う。
posted by ミーズシステム株式会社 目面 秀信 at 19:25| Comment(0) | TrackBack(0) | SEとして

2008年12月31日

O/R マッピング

先日、O/R マッピング を激しく主張する人と議論を交わしました。

O/Rマッピングとは、簡単に言うと、プログラムとデータベースの間にあるSQLを無くしてしまおうというものです。

よく聞く言葉が「SQLでプログラミング」というぐらいです。

しかし、私はこう思います。
「O/Rマッピングはまだ赤ん坊レベルの技術」

これが盛んに話題に上るようになったのは約5年ほど前でした。
大手の会社でこれを使いたいということで採用したプロジェクトを何件も見てきています。

しかし、どれも仮稼動後まもなくユーザからNGがでました。
理由は「遅くて使い物にならない」ということです。
本番用データを入れたとたんに遅くてクレームになったのです。

理由は明確で、O/Rマッピングにしたからです。
でも、これからが大変です。
O/Rマッピングでは自動的にSQLを作成します。
だから原因がわかったとしても対応ができません。。。
で、どうするかというと・・・

本番までの2週間で遅い部分を「ネイティブなSQLに修正した」のです。。
この間はまさしく生き地獄。。帰れないどころかまともに眠れません。。


O/Rマッピングを真剣にやろうと叫んでいる人の多くは、大量のデータを扱ったテストをしていないのではないかと思います。
数百万件のテーブルをリレーションして回答を返すような処理の場合では、やはり時間はかかるものです。

私の経験上、ユーザインターフェースでSQLなどの問い合わせで回答が得られる時間は、長くて2秒以内と考えます。
ネイティブで1秒ぐらいかかる場合、下手なSQLを書くと数分は回答が返ってこない場合もあります。

O/Rマッピングの場合、なかなかナイスなSQLを生成するかもしれないですが、そうでない場合は手直しができないのです。

だから、現時点ではO/Rマッピングは使うべきではないでしょう。

また、O/Rマッピングというものは、SQLを苦手とする人たちには過度な期待を与えてしまっているという事実もあります。
そのため、「SQLは覚えなくてもいい」という逃げ道を作ってしまい、勉強する機会を奪ってしまっているようです。

これはとても残念でした。


昔、私はdBASEというRDBMSの言語で業務プログラムを作成していましたが、そこからOracleのSQLに切り替えたときに、雷をうけたぐらいの激しいカルチャーショックを受けました。

確かにとっつきにくい感じはありましたが、思い切ってオラクルマスターの試験を受けることにしました。
プログラムが十分に作成できる人であれば、勉強すれば1週間もあればシルバー(今はブロンズ)はとれると思います。
あと、SEレベルの人であれば、暗記力があればゴールドもとれると思います。

ここまでで約3週間程度でしたが、今までの経験で培ったSQLレベルがなぜこう記述するのかというレベルまで理解できました。

このときから、プログラムの中でSQLを使うことやストアドプロシージャを使うことへの抵抗がなくなりました。

他の言語を経験されている方も同じだと思います。



この感動は、SQLを毛嫌いしている人に是非伝えてあげたいです。
O/Rマッピングを覚えるくらいなら, SQL や RDBMS を勉強した方がよっぽど良いし、自分の為にもなります。

何故ならば、通常のアプリケーションの負荷のほとんどは, データベース部分にあるからです。
負荷のことを考慮せずに作成されたアプリケーションは、規模が大きくなると応答がどんどん重くなってきます。

やっと手を離れたと思ったときから、パフォーマンス改善で四苦八苦することを考えれば、SQLを勉強する2、3週間はあっという間です。

頑張ってきちんとした知識を身につけておきたいものです。
posted by ミーズシステム株式会社 目面 秀信 at 22:11| Comment(0) | TrackBack(0) | SEとして

2008年12月26日

お客様サポート

私のお客様の中には、今日(26日)で仕事納めのところもあれば、31日の午後まで大忙しのお客様も結構多くあります。
なので、いつも外向けには一般に合わせていますが、実サポート業務は31日の昼過ぎまでやっています。

と言っても常にトラブルや問合せがるわけでもないので、大掃除をしながら(手伝いながら?)ということになりそうですが。。

しかし、いつも思うのですが、土日に私たちがゆっくり遊んでいられるのは、いろいろな人のおかげだと。
そういうお客様を支えるのが弊社の存在価値なので、携帯だけはいつもすぐにとれるようにしています。

こういう時の電話は嫌なタイミングもありますが、そういう時ほど超特急で対応をします。
休み明けとか後回しということはできるだけしないようにしています。
そうすることにより、自分も気持ちが楽ですし、お客様も喜んでくれるんです。

メールも同じで、基本的にあとに回すことであっても、必ずその旨を伝える内容を返信するようにしています。
(どうしても見れない場合を除いて30分以内に返信することを心がけています)

実際に自分がメールを投げかけても返事の返ってこない人が多いのですが(とくにこの業界)、そういう対応を見るといつも思うのが、「お客様にもこういう対応をしているんだろうな」ということです。

私は当たり前だと思うのですが。。
posted by ミーズシステム株式会社 目面 秀信 at 19:10| Comment(0) | TrackBack(0) | SEとして