ITベンチャーと言っても私が知っている数社とそこで聞いた話ですが、
聞いていいなーと思った話は結構実践してきましたので、まあ、内容についてあーだこーだといえるぐらいは知っています。

実は運用面で意外とITではなく、ローテクを使って大量の情報を素早く判断しているのです。

ただし、ここで言っている大量の情報とは、言い換えると、「文字」や「数値」に表せきれないような情報と言ってもいいかもしれません。

ここでは、その一部をちょっと紹介したいと思います。

1:障害を「音」と「光」で知らせる。

具体的には、パトランプと、サイレンで知らせます。
これでの効果は、多くの人に直感的に通知できることと、雰囲気を経験的に提供できる点です。

誰でも仕事中に、サイレンが鳴れば「うるさいなー!」とわかります。
従って、たとえほかの仕事途中であっても周りの人の依頼を断って、障害に対応できます。
また、関連部署の巻き込みも根回しなしにできます。というか、勝手に集まってきます。

そして、最近「静かだなー」、とか、逆に「うるさいなー」が関係ない人にもわかるので、様々な情報が経験となって伝わるのです。
たとえば、「そろそろハードウェアも買い換え時期かな-」とか、「監視に予算をつぎ込んだ方がいいなー」とか、とか。

このような、職人だけが関知できる経験的勘所も、「音」と「光」にしてあげる事でなんとなく伝わる事が多々あります。

で、このようなノウハウ、実は結構使われている気がします。
USBで接続するこのようなツールも売られているので、一定の需要はあるのでしょう。

2:感情で品質を管理する。

現在のシステム管理では非常にスピードも速く、そして、要件もすぐに変わっていきます。
ただし、問題がいざ発生すると、「テストは十分なのか?」などの議論が巻き起こり、重厚な「テスト仕様書・報告書」ができあがることがあります。

でも、そもそも自分たちで感知できなかった問題なので、他にこの「テスト仕様書・報告書」を承認する人が必要になります。
しかし、これを承認できるような技術者なんてほとんどいません。
従って、ここでできたルールは、ほとんど形骸化し、そしてまた、何もない状態に戻っていきます。
そして、あり得ない障害が多々ある状態に戻ってしまうのです。

そこで感情の登場です。
ここで「テストレポート書」を作りますが、詳細な仕様書や結果は一切求めません。
ただし「私は正しく動くことに自信があります。」と言う項目を設け、その欄にサインしてもらうのです。
(決して、保証を求めてはいけません。求めるのは根拠が無かろうが、「自信」だけです。保証を求めたら決して同意しません。)

そもそも、要求もめちゃくちゃ、動きだって詳細は決まっていないのだから、詳細を求める方が間違っています。
でも、エンジニアというのは基本的に正直者ですから、結構うまくいきます。
そして、自信があるといった以上、責任も持ってくれるのです。

これで、おおかた双方が求める物は満たせているはずです。

自信がないと言ってきたら、上位技術者をつけるなり、結果を用意することでOKとすればいいのです。
これで、ほとんどわかりきった事に対する情報については、細かい情報を求めず、込み入って問題になりそうな事だけが、文書化されていきます。

しかも、組織レベルが上がれば、上がるほど、文書化は必要がなくなってくるのです。

と、2つを紹介しました。
たまーに、これ以外も紹介していければと思います。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2010年6月
« 5月   7月 »
 123456
78910111213
14151617181920
21222324252627
282930  

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ