コラム


2009年11月26日

お客様から頂いた名言

システムエンジニアとして、お客様とお話しする機会は非常に多いが、その中でお客様から教えていただくことも多い。システムエンジニアとしては当たり前のように行っていることが、世間一般では非常識であることは次の名言から勉強になる。

1.仕事を投げるのではなく、依頼する
仕事をプログラマーに依頼するとき、「これを投げておきました」という言い方を良くする。自分から見て、仕事の上流の人はお客様なので、依頼事項に対しては従うが、逆に下流の人に対しては、あたかも自分が偉いような錯覚を起こしてしまうので、このような発言が出る。下流の人の仕事がしっかりされていなければ、上流の自分が最終的に困ると認識すべきである。

2.メールは記録には残るが、記憶には残らない
仕事の依頼をメールでやり取りすることは多いが、その内容は依頼先にとって、実は記憶に残らず、見過ごしてしまうことが多い。そんなときに、メールの送信履歴を証憑として、仕事をしていないことを非難することは間違いである。急ぎの仕事であればなおさら、メールを送信した後に口頭や電話で一言伝えることが重要である。(お願いの気持ちだけ伝えるだけでも依頼先にとっては仕事の受け取り方が変わるものである)

ということを頭に入れていても、忙しいときにはついつい忘れがちとなる。
自分の備忘録としてもこの内容は定期的に見返したいものである。

2009年10月28日

ITPro Expo 2009

に行ってきました。
展示の内容は大したものはあまりありませんでしたが、フォーラムの内容がとても有意義でした。私が今日のテーマとして受講したのがサーバーの仮想化でした。

仮想化万歳が続いて、睡眠学習することになると思っていたら、仮想化のメリットと現実を知ることができて、良い意味で期待を裏切ってくれました。

○仮想化にまつわる用語
・マイグレーション(migration) システムを新しいプラットフォームに移行すること。仮想化では、メンテナンスや障害時において、仮想サーバーを別の物理サーバーに移動することを指す。
・スケールアウト(scale out) サーバーの台数を増やして、パフォーマンスを向上すること。サーバーの性能向上をすることはスケールアップという。
・プロビジョニング(provisioning) 必要な時に必要な分だけシステムにリソースを割り当てること。オーバープロビジョニングは、システムが高負荷時でも最適にサービスができるように余剰にリソースが割り当てられている状態のこと。


○一般的に言われているサーバーの仮想化のメリット
1.集約できるので、サーバーリソースをより効率的に利用でき、ランニングコストを抑えられます。
2.マイグレーションにより、物理ハードが故障しても別サーバーに無停止で移動できます。それによって稼働率を飛躍的に向上できます。
3.システムを構築するたびにサーバーを購入しなくて済むようになるので、安価にシステム構築ができます。
4.P2Vという機能を使って既存システムを仮想化することで、Windows NT4.0で動いているレガシーシステムも利用できるようになります。


しかし、メリットが成功に結び付くには現実は避けて通れない。


○メリットに対する現実
1.ランニングコストを抑えられるのは、主に電気代だが、データセンターにてサーバーを置いている場合には、電気代は定額であることが多く、仮想化するためにブレードサーバーなどを購入する費用だけがかかることになる。また、集約を進めていくと通信用のネットワーク以外にも死活監視するためのネットワークや仮想マシン上の差分をバックアップするためのネットワークなどどんどんLANケーブルが増えてしまって、LANケーブルでラックが倒れそうになることも現実として起こっているらしい。また、LANケーブルが張り巡らされて放熱も悪くなって、結果的に電気代がかかってしまうこともあり得る。

さらに、監視する方法が抽象化されるので、保守要員のスキルなども向上させる必要があり、ランニングコストは変わらないかむしろ高くなる可能性がある。

2.集約はできるが、集約した結果ハイパーバイザの停止は、仮想化システムすべての停止を意味する。また、仮想化サーバーに対して接続されるディスクドライブは、物理的に1つ(ディスクが1つということではない)だったりするので、物理ディスクのメンテナンスを行うときには、そのディスクにつながる仮想化マシンを一度停止しなければならない。(停止しなくてもできるはずだが、基幹システムなどにおいては、計画停止しているのが一般的だそうだ)

「仮想化は今後当たり前になるが、あえて仮想化しないという選択肢をとれるようにする必要がある。」(日本仮想化技術研究所 宮原さん)

また、仮想化はまだまだ始まったばかりの技術。仮想化特有の問題が起こることがあり、長期的に利用した時に何が起こるか分からない。また、パフォーマンスを見れば、仮想マシンとして動かすと物理サーバー上で稼働するよりも、パフォーマンスは10%以上低くなる。最も顕著なのが、I/Oアクセスだそうだ。ユニアデックス 高橋さんのお話によると、DMAコントローラーはCPUとハードディスクの速度差によってCPUが占有されることを防ぐために導入されたにもかかわらず、ソフトウエアでエミュレーションした結果、DMAコントローラーの処理がCPUで行われることとなり、ボトルネックになってしまっているとの指摘だった。今後は、Intel VTなどのように仮想マシンからエミュレーションされたDMAコントローラーを介さなくてもアクセスできるように改善されているので、もう少しすれば仮想化のデメリットも少なくなるのではないかという内容だった。

3.仮想化が最も有効に働くのは、スケールアウトする時だ。ただ、重要なことは、仮想マシンがデータとなっており、それを保持するためには、ハードディスクをあらかじめ大規模にしておかなければならないということだ。仮想マシン1台のオーバープロビジョニングが、数十台集まると、それこそ膨大なストレージの無駄が生まれてしまう。それを防ぐために、日立製作所であったりユニアデックスはストレージ仮想化という技術でもって解決しようとしている。

4.P2Vは仮想化の中でも最もリスクの高い内容であると日立製作所 高衣良さんやユニアデックス 高橋さんはお話しされていた。原因は、Hyper-Vを例にとれば、仮想マシンにするためにWindows PEを起動させて既存サーバーをバックアップする必要があるが、サーバー自体にWindows PEを動かすためのドライバが必要であったりするからだ。また、もし仮想化に成功したとしても、まれにサポートが終息しているOSの不具合によってブルースクリーンが起こってしまったりすることがあり、長らくレガシーシステムに頼らざるを得ないミッションクリティカルなシステムを仮想化することはそもそも危険なことであるということをベンダーは認識しなければならない。


「なぜ仮想化なのか?をよく考える必要がある。仮想化はゴールではない。」(日本仮想化技術研究所 宮原さん)

ところで、仮想化のもたらす劇的な変化訪れようとしていることを、先日Windows 2008 R2を発表しているマイクロソフトが教えてくれた。

社内の物理サーバーに乗っている仮想マシンを一時的に利用したいが、どの物理サーバーもリソースが不足しているとき、IIJのクラウドに申し込んでサーバーを確保し、ライブマイグレーションを使って仮想サーバーを移動させて稼働させるというものだ。実際にデモンストレーションを行っていたが、数分でライブマイグレーションが完了していた。

この前提にあるのは、IIJのサーバーとVPNで接続されており、同一ネットワーク上にある前提がもちろん必要だろうと思われるが、プロビジョニングにより、自動的にサーバーの稼動する物理サーバーが変わるようになれば、今動いているこのシステムは社内にあるのか、データセンターにあるのか、はたまた海外にあるのかそんなことすら意識しなくて済むようになる。自動化がすすめば、ビジネス規模に応じて契約を進めていけばいいので、コストを最適化できる。

ユーザーから見れば夢のような技術だが、保守ベンダだから見れば、こんな面倒な話はない。物理サーバーの位置が変わるとネットワーク遅延が発生する(海外に移動してしまうと数msの遅延が数百msの遅延になってしまう。たいした違いではないかもしれないが100倍遅くなることは事実なのだ)ことで、アプリが動かないとかそんなトラブルに悩まされるようになりそうだ。

仮想化、仮想化、仮想化。。。Webサーバーが耐障害性と性能向上を目的に台数が増えた結果、ネットワーク機器を仮想化して冗長化しなければならなくなり、さらに耐障害性の向上とスケールアウトを進めた結果、物理サーバーすら仮想化の対象となった。あまりに物事が抽象的になった結果、本質が見えにくくなってしまっている。仮想化という時代をまのあたりにしていくエンジニアは、私を含めてその内容自体を理解することが難しくなりつつあるが、仮想化が当たり前で育つエンジニアは、それが理解できるのだろう。しかし、今後仮想化特有の不可解な現象に行き着いたときに本質がわかっていなければ、解決が難しいだろう。これは、きっとDBアクセスにおけるO/Rマッピングのようなものに近いのかもしれない??

今後は、アプリケーションエンジニアも仮想化技術とネットワーク技術を身につけていかなければ、立ちいかなくなると個人的には考える。(そんなのはネットワークエンジニアの仕事だろうという声が聞こえそうだが。。。)

2008年6月 1日

"ギスギス"する職場、その背後にある見えない問題とは

ドキッとするような記事だ。

以下引用

皆とにかく忙しく、常に忙しい、忙しいと口にする
メールでのやりとりが主で、対話をしない
やって当たり前で、感謝がない
協力して仕事をしない風土があり、他の人が何をしているのか分からない
上司の話に部下が反応しない
結果だけを求められる
それぞれが重複して行っている業務や作業がある
極端に業務負荷が高い人がいる
八つ当たりをする上司がいる
提案した人に負荷がかかる

よくある話が、最後の「提案すると損をする」というケースだ。提案することがマイナスになるような職場はもう末期に近い段階だ。もし自分の職場がそういう雰囲気ならば、パワーがいるが自分からどんどん提案をし続けて空気を変えるか、職場を変えるしかない。

2008年1月20日

オープンソースからの転身

最近Mixiの開発者ブログを見てやっぱりオープンソースは楽しそうだなぁと思っている今日この頃。

社会人始めて以来、今の会社にはいるまでずっとオープンソースで開発された製品でもって開発したりしてきたわけで、時にはドキュメントがないことにいらだったりしつつもそれを調べるのもまた楽しかったわけで。

今の会社はベンダーの製品でもって開発しているわけだからつねに制約というものと戦っている。オープンソースで身につけた知識を持って内部構造を調べることはできてもそれに手を入れることはできない。

ベンダーから見ればリリースしている製品に勝手に手を入れられたら保証できないというのはもっともな話。ベンダーが保証した製品でもって顧客に展開しているからこそ顧客と保守契約が結べることもまた理解している。だけど製品のちょっとした使いにくさが自分のスキルでもって直してあげられればもっといいんだけどなぁ。。。

オープンソースが僕に与えてくれた刺激はとても大きいみたいだ。

2007年5月19日

内部統制になぜITの利用が必要なのか?

来年からJ-SOX法による運用がスタートするけれども、J-SOX法の本になっているCOSOのモデルになぜITの利用が含まれているのだろうか?

SIerからみればなんでもIT利用してもらった方が儲かるわけだから歓迎すべきだけど、理由を分かってないともちろんどこに重点を置いてシステムを提案すべきかが分からなくなってしまう。

内部統制の重要なキーは会社の規定に基づいて正しく運用されていることを証明できること。そのためには、たとえば承認しなければならない人がきちんと承認していること(承認者でない人が承認できないこと)を証明しなければならない。

アナログ運用だとその確からしさを継続的に保証することができないのでそこでシステム運用が必要になる。システムでそれが保証できるのであれば、バグが残っていたりシステム改修をしない限りはその確からしさが継続的に保証される。

だからこそITの利用でもってその証明にかかる負担を少しでも減らすべきだといっているわけだ。

もちろんシステム化するからこそ、管理者というものが存在することになり、管理者による改竄は発生することになる。それこそログは別サーバーで管理し、そのサーバーが全く別の管理者で管理され、改竄されてないことを証明しなければならないが、その管理者同士が結託すればそれもできなくなる。

根底にある難しさはやはり運用している人間自身にあると言える。オチは結局そういうことです。

2007年5月 7日

言語を正規化する

正規とは・・・
規則などではっきりきまっていること。また、その規定。(大辞林第2版より)

システム化(プログラミング)するということは今まで手作業でやっていた作業を正規化してコンピュータに仕事をさせるための作業だ。ロボットの目指すところは人間の正規化であるわけだけど、その中で言語の正規化も必要になってくる。言語の正規化は身近なところではコンピュータの日本語変換システムが該当すると思う。

さて日本語変換システムは、単純な漢字変換(といったら怒られる。日本語の変換システムはおそらく他の言語に比べればもっとも難しい可能性があるから。)を経て、予測する世界に入ってきた。

それは、携帯電話などの小型ディバイスの発達に伴って、少ないキーの入力回数でもって日本語入力をする必要が出てきたからだ。あ、便利だと思う人もいれば、この機能が表現を制約しかねない非常に危険なツールだと思う人もいるだろう。

僕は一番最初に出版社に短いながら勤務していた。そこで国語編集部につとめていた先輩に日本語変換システム開発に必要な辞書のデータベースの提供をもとめてきた有名なコンピュータメーカとの打ち合わせに同席してもらったんですが、その会議のあとにぼやいた一言が印象的だった。”言語は生きているのにそれをひとくくりの変換システムに押し込めてしまうなんて。。。”

たしかに言語は生きている。新しい単語もできてくれば新しい言葉の使い方も生まれてくる。僕は詳しくは分からないが、これが正しくて、これが間違っているということはなくて、僕たちが今まさに話している言葉が正しいわけで、それを正規化してしまうということは、その表現の自由が奪われてしまうというわけだ。つまり、新しい日本語が生まれにくくなる。

もちろん誤った日本語の使い方だから制約してしまっても問題ないという考え方もあるだろう。でも誤用がそのまま辞書に載るようになることも長い歴史の中では多いわけだ。だから言葉は難しいのかもしれない。

話はそれてしまったが、システム化するときにエンジニアはこのようなことに注意しなければならない。一つの向きから見てこれは便利だと思ったことをシステム化する事はとても得意だ。この発想がなければエンジニアの仕事は楽しくないはず。ただ、反対向きから見て本当に便利なのかについても考えてもいいだろう。

そんなことは作ってから評価される段階において評論家にでも任せればいいと思うかもしれないが、作りっぱなしのシステムではなく使われるシステム作りを目指して僕たちはいろんな畑の人たちと積極的に話をして、価値観を共有して一つの物事を様々なアプローチから考えることができるようにならなければならないと思う。

今自分がやらなければならないことが手元になくて焦っていることがよくある。何かをやらなければ周りにおいてかれてしまうという恐怖心だ。または、こんなことをやっていて何の役に立つのだろうという疑問。

与えられた仕事をして時間に余裕ができるからそんなことを考える暇ができるのかもしれない。もし余裕ができたら恐怖心を捨てて話をしに行こうと思う。

2007年3月20日

データセンターのあれこれ

前の会社でデータセンターの選定作業を行ってから早2年、いろんなデータセンターを見て回ったり、今の会社になってからは作業をしたりすることが多いが、実際にデータセンターを選ばなければならなくなったとしたら選ぶポイントはどこにあるのだろうか?

営業トークにごまかされると後々移転せざるを得ないケースもあるので、このドキュメントが何らか役に立てば嬉しい。

まず立地条件。通常はリモートメンテナンスで何とかなる訳なので、言ってしまえばデータセンターの位置はどこでもよいと言うことになる。ただし、致命的な問題が発生しないということはないので、必ず駆けつけできる範囲であることが最低条件。

次に、電源の問題。基本的にこの問題は当たり前だからこそ気づかない部分だ。1ラックあたり何Aまで追加できるのかをチェック。

そして、サポート内容のひとつであるリモートハンド作業。万一リセットを必要とすることがあれば、センターの人にやってもらうしかないが、そのセンターは担当が24時間いるかどうかを確認しておくべき。この部分をすりあわせなかったために痛い思いをしたことがある。ただ24時間常駐していても、対応には10分程度かかるため、ミッションクリティカルなマシンには必ずDRAC(Dell Remote Access Controller)のようなものを入れておくべきだ。

当たり前と思っていることが当たり前でないことはよくあることだ。

最後に空きスペースの問題。今後増設を検討している場合には思い切ってスペースを借りておいた方が無難。何らかによって急にサーバーを増設することになっても対応できないではすまされない。

2007年2月15日

ドリコム内藤社長が描く、“ニンテンドーDS的”Web 2.0提案とは?

ブログサービスで有名なドリコムの社長の記事について。

http://japan.cnet.com/interview/media/story/0,2000055959,20341666,00.htm

僕が非常に共感したのは、”儲ける仕組みをきちんと加味すれば、コストを抑えて高収益率のビジネスを効率的に展開することができます。しかし、現状は儲けの仕組みを全く考えずに展開するWeb 2.0サービスが多いため、「Web 2.0は儲からない」という話になるわけです。”というフレーズ。

ビジネスの上でこのことは当たり前といえば当たり前なんだろうけれども、マッシュアップがベースであれば、おのずとお金がユーザーから取れないというものが生まれてしまう。広告収入だけで頼るのもなんら収益モデルとしては工夫がないだろうし。

ユーザーに使えるサービスを提供し、収益モデルをしっかりと組み立てられる。こんな当たり前のことが、求められているのが今の現状なのだ。

2007年2月 3日

負債30億円 「PC-SUCCESS」破産申し立て

http://www.itmedia.co.jp/news/articles/0702/01/news032.html
http://gigazine.net/index.php?/news/comments/20070131_pc_success/

PCサクセスが破産を申し立てることになってしまった。一時期は配送が遅いなど問題が多かったが、最近は改善されていたのに。。。

一方で激安販売を行っているECカレントを運営するストリームはマザーズに上場する。
マネックス証券のBB考察はアグレッシブとなっており、同じ経営手法で成長した会社の明暗が分かれた格好だ。

2007年1月19日

RFC

Request For Commentに関して。今まで触れたことのあるRFCを紹介していきます。

RFC791
IPに関するRFC。

RFC793
TCPに関するRFC。

RFC822(Obsoletes:STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES)
メールに関するRFC。RFC2822に移行されている。

RFC959
FTPに関するRFC。

RFC2396
URI(Uniform Resource Identifiers)に関するRFC。マルチバイトを含むURIは文法違反。

RFC2616
HTTPに関するRFC。

2006年12月17日

IT職場を3Kから3Tへ変える

IT職場の未来はこのままでは将来も明るくないかもしれない。

日経コンピュータの10月16日号に掲載されていた日本情報システム・ユーザー協会の細川さんの記事。

昔は3Kといえば、「きつい」、「汚い」、「危険」だったがITにおいても3Kとして「きつい」、「給料が安い」、「帰宅が遅い」が当てはまるんじゃないかと。学生が情報産業を選ばないことは今後IT業界の更なる人材不足を招くことになり、結果的に情報社会を支えていくことは難しいかもしれないというものだ。
そこで要件仕様を早期に決定する(要件仕様をつめる能力を高める)ことにより、3Kを3T(「楽しい」、「高い報酬」、「たまには定時に帰れる」)に変えられるのではないか?

確かに赤字プロジェクトが発生する原因は文章の中で指摘されているように「仕様の決定の遅れ」、「要件分析作業の不十分」があると思う。仕事を進める上でこれらに注意して仕事を進めていくことで3Tは得られるのかもしれない。

2006年12月11日

分散と集中の歴史

何事においても歴史を知ることは今後を予想する上で非常に重要であることは間違いなさそうだ。
コンピュータの歴史においても同じことが言える。コンピュータの歴史は半世紀程度しかないけれども常に分散と集中を繰り返しつづけているといえるだろう。

ホストコンピュータによる集中時代
マシンが非常に高価だったため、クライアント機はホストコンピュータにつながった端末であり、その端末時代には処理する機能は存在しなかった。(ホストコンピュータにログインして、そこで処理を行うので、画面への出力とキーボードの入力のみを処理)
そして時間単位で課金されていた。とはいっても僕はこの時代にマシンを利用していたわけではないので、詳しいことは良くわからない。

クライアントマシンによる分散の時代
マシンの単価が下がってくると、あえてサーバーで処理する必要もなくなり、より応答速度が速いローカルで処理するようになってきた。この流れは、サーバーの乱立を招く結果となる。

シンクライアントによる集中の時代
サーバーの乱立に伴う管理費用の増加とクライアントマシンにデータがあることによって発生する情報漏えいの2つの観点から、マシンを集約することになる。集約できるようになった大きな背景として、ネットワークの高速化が上げられる。

とくれば次は分散かもしれないが、分散の対象はおそらくマシンではなくネットワークになるだろうと予想する。

2006年12月 6日

インストールとデプロイ

インストールとデプロイ(実は今までデプロイという言葉を使ったことがなく、今日はじめて聞いた)は同じようで微妙に違うみたいだ。

デプロイ
インストール(ソフトウエア)

技術の安売りをすること勿れ

インフラ系を中心に価格破壊が起きて久しいが、その結果多くのユーザーは安くなったことのありがたさは忘れ、いつもと同じように当たり前のように使い続けている。

ネットワークインフラにおいては、ブロードバンド化によって提供コストは確実に安くなっている一方で、運用ならびに保守にかかるコストはさほど低くすることは出来ていない。

不幸なことに、動画配信やIP電話の普及に伴い、ますますバックボーンは増強せざるを得ない状況になっている。おそらくコスト削減は行き着くところまで行き着いたようにも思える。

ネットワークインフラ保守のコストは以前から、(ほとんど誰も意識していないが)利用者全員がコストを負担しあうことによって成り立ってきた。しかしながら、一部では、大容量のコンテンツを配信しているようなコンテンツプロバイダーも目立つようになってきた。

プロバイダーは利用者から回線増強にかかるお金を取ることは難しくなってきているので、コンテンツプロバイダーからお金を請求せざるを得なくなっているが、コンテンツプロバイダーはそれに対して応じようという気配は見られない。

こうなってくるとプロバイダーは淘汰されるしかなくなってくる。以前から資金力が無いプロバイダーは次々と吸収されてきたが、それが今後はもっと加速化されるだろう。

エンドユーザーのためにと始まった価格破壊は、最終的に特定プロバイダーの寡占状態に陥って、不幸が始まるかもしれない。

安売りすることによって他に収益源が確保できる見通しがあれば問題ないが、ただ価格破壊をすることは誰にでも出来る。

技術の安売りをするときにはよくよく考えたほうが良いかもしれない。

2006年11月21日

Wikipediaの暗い影

今日Wikipeidaを編集しようとしたら広域ブロックというものでブロックされていることに気づきました。どうも加入しているISPの一部のホストが大量にスパム行為を行ったらしいです。

巻き添えを食っているISPはウチだけでないようで、Yahoo! BB (220.0.0.0/10)やinfowebの一部(58.0.0.0/16)も含まれているようです。でもサブネットが10ビットってかなりのホストを制限しすぎているような気がしますが。。。。

WikipediaではISPに対策をとってもらうまでの間、制限を解除したりはしないとのことで、このような制限が広がれば広がるほどWikipediaへの活発な議論が行われなくなるのは残念なことだと思います。根本の問題はスパム行為なわけですが、これを問題にしてしまうと埒があかないので・・・

2006年11月19日

情報を制限することのメリットとデメリット

リーダーがメンバーに情報をあえて伝えない場合のメリットとデメリットを整理してみる。

・良い情報を制限する場合
(メリット)特になし

(デメリット)メンバーに少なからず不信感を与える

・悪い情報を制限する場合
(メリット)メンバーの士気を下げずにすむ

(デメリット)情報に期限が含まれている場合、後で現場で火を噴く可能性が高い。

知らなくても良い情報があることは確かであり、太古の昔から情報を握っている人間が必ず物事を有利に進められることは既知の事実であるが、情報を公開しない場合にはメンバーに少なからず不信感を与えることは必死である。

2006年11月 8日

エンジニアの生きる道

エンジニア(プログラマー/S.E.)として付加価値をつけていくにはどうしたらよいのだろうか?僕が今考えているのは、

・徹底的に特定の言語に固執してスペシャリストになる。

・言語(や開発手法)を幅広く学習して、課題に対して適切な解決策を提案できるスペシャリストになる。
のいずれかではないだろうか?

言語はツールであるから、日本人はブームに弱いので一時的には需要が変化したとしても、その言語で作られたシステムは存在し続ける以上保守が必要であるから、スペシャリストであり続ける限り仕事はこなせるだろう。

また、後者の場合においては、コミュニケーションスキルが必須になるだろう。提案するためにはその内容を適切に把握する必要があり、必要に応じてその情報を引き出しを開けて説明できなければならない。

どちらにしてもエンジニアである以上は勉強をし続けなければならないのは間違いのないことだろう。まぁ、これはどんな職種であってもさほど変わることではないのだろうけれども。

2006年10月27日

見える化

J-SOXの流れを受けて、「見える化」という変な日本語が流行しそうな勢いだ。Y2K問題に続いてシステム業界全体で大きな変革の波が起こりそうなJ-SOXソリューションに対するSIの取り組みはどこも必死だ。

そもそも見える化は業務フローを明確化するという重要な取り組みにもかかわらず、多くの場合にはドキュメントが残っていないなど作業担当者に依存する俗人化といわれる要素が企業内に多いことが問題となっている。

俗人化してしまうと、ビジネス上の一番のリスクは従業員ということになってしまい、企業にとって健全とは到底いがたい。そこを俗人化しないようにするための方法が、見える化なのだろうと思う。

しかし一方で見える化は、J-SOX法の名のもとで監査法人対策というところに置き換わってしまっているケースも多い。この行き着く先は、メンテナンスされないドキュメントの山。これを整えるために数億円というお金を使う企業は間違いなく行き詰まると思う。

2006年10月 9日

自分たちの労働条件を獲得する難しさ

プログラマやSEなど実務業務に当たるエンジニアは会社の決められた待遇の中で業務を行っている。僕の場合には、前職が労働組合があった関係もあって、労働条件はかなりよいほうだと感じていたが、転職してからというもの、会社が大きくなるにつれて労働条件が悪化していることが目に見えてわかった。

資本主義において、会社は最大利潤を追求する組織。経営者の確固たる従業員への思いやりの理念がなければ当然労働条件は悪化するものである。それは、純利益を最大化するためには、売り上げを上げることよりも、支出を減らすことのほうが簡単だ(少なくとも選択肢がある)からだ。

働きやすい環境を確保ならびに維持することは、生産性を最大化するための必要最低条件であり、従業員はこの努力を忘れてはいけない。経営者は実務作業をしているわけではないから、働きやすい環境というものが何なのかは現場にいなければよくわからないはずだ。

会社を大きくする上では、従業員を多くとっていかなければならない。現場の人間が誇りを持って新しい人を招きいれられるように労働環境の確保は行わなければならない。

しかし一方で従業員の立場は弱いものである。自分たちの思いを経営者に伝えるためには相当のポストになければならない。自分たちの思いを言葉に表さなくても経営者に伝えられればなんと良いことだろうか??

ところで、日本の法律には労働組合法というものが存在する。従業員は特定の職種以外であれば労働組合を結成し、経営者にその思いを伝えることができる手段が用意されている。

前職では当たり前のように労働組合と会社は話し合いの場を持っていた。労働組合は足の引っ張り合いになる可能性もないわけではないが、少なからず労働条件という題目において経営者と従業員が話をするためのツールであることは間違いないのだ。

2006年10月 5日

J-SOX法とエンジニア不足の行き着く先

日本版SOX法(2006年6月7日制定の金融商品取引法)だが、ITの利用という項目が含まれている以上は、J-SOX対応は、管理や経理部門だけの話ではなく、システム部門の準備も行わなければならないことになる。いまは、エンジニアが本当に不足している。募集をしても応募すらほとんどこないという悲惨な状態である。こんな状態は半年前に想像もできただろうか??

J-SOXに対応するためには、文書化などさまざまな部分でいままで以上の業務(おそらく本来であれば作業手順をはじめとする文書化という作業は当たり前に行われなければならないが、Web業界においては仕様書がないとか作業手順書がないなんてことは珍しくない)を強いられることになる。ただでさえ、人員が不足している現在において、文書化までの作業を正しく行うことができるのだろうか?行き着く先は今かつて無いデスマーチの連続なのだろうか?2008年4月から恐ろしいJ-SOX法が施行されることとなる。

2006年8月21日

WebサービスとSLA

・宅配物を紛失した時には損害賠償が上限があるものの決められている。
・購入した電化製品が1年以内に故障したら無償修理する。

このような品質保証をネットワーク業界ではSLA(Service Level Agreement:サービスレベル保証)と呼んでいるが、Webサービスを見てみると、免責条項はあるもののSLAに該当するような品質保証をしているケースはほとんど見受けられない。

Webサービスを行っている会社がSLAを締結できない理由は、
・Webサービスの多くは無償で提供されている
(今回の話題では、有償サービスを前提としているので、これは除いて考える)
・サービス提供元の会社の資本力が小さくて金銭的な補償を含めた保証ができない
・Webサービスの不具合はすぐに改善することができる(なので不完全なアプリケーションが出やすい)
・何かといえばβ版という言葉が流行している
・品質管理の認識が他業種に比べて低い
からだろうと思う。

SLAを締結することは、サービスを明確にすることになるわけなのだが、締結する会社はかなり厳しい条件になることは承知の上で締結することでそれをアピールポイント(差別化)に変えることができる。提供する価格が多少高くなろうとも、顧客の安心感を買うことができるので、結果的に顧客はおのずと集まる。

と考える。ハードウエアにおいては、稼働率の考え方が定着しているもののWebアプリケーションを含んだ全体的な稼働率という部分での定着はまだまだ薄いような気もする。

稼働率が出せなければ、1日間あたり何秒間システムが完全に稼動しなければ補償しますとか、レスポンスタイム何秒を超過したら補償します(これはネットワークという性質上難しいが・・・)といったようなことができないわけで、ここから始めることがSLA締結への取り組みの第一歩なのだろうと思う。

SLAが締結できないような会社は、おのずと仕事がなくなるといった感じの流れができてくるようであれば、Webアプリケーションもよりよい品質を保つことができるようになるのかもしれない。

とはいうものの、自分が開発を担当しているコンテンツでSLAを提供するなんて話になれば、間違いなく難しいか、会社がつぶれてしまう。

理想と現実はつねに乖離しているものなのですね。