« June 2005 | Main | August 2005 »

July 26, 2005

人の話しを素直に聞けることが重要

最近よく思うのですが、人の話を素直に聞けることって本当に重要です。皆さん次のどちらがよいと思いますか?

 A: 「そのやり方ってこう変えたほうがいいんじゃない?」 → 「いや、俺的にこれが一番やりやすいのでその必要ないかな。」
 B: 「そのやり方ってこう変えたほうがいいんじゃない?」 → 「う~ん、そうは思わないけど一度試してみようかな。」

私だったら断然Bですね。Aの人は確固とした自分の世界がありひょっとしてその世界はそれなりに優れているのかもしれませんが、人の意見を即座に否定しているのでそれ以上の成長はありません。それに対してBは自分の世界はありつつも相手の言うことに真理があるかもしれないと、他人の意見を受け入れています。

信念を持つことは重要ですが、他人の意見や忠告を素直に聞ける度量がないと人としての成長が期待できないだけでなく、周りから孤立することにもつながります。意外とこういうタイプの人って多いんじゃないですか?

| | Comments (3) | TrackBack (0)

July 23, 2005

パレートの法則を用いたマネジメント

パレートの法則、別名80:20の法則を用いたマネジメントはとても強力です。やろうと思っていた仕事のうち重要度の高い上位20%さえ達成すれば全体の80%が達成されるということになります。この法則はシステム管理にしても開発にしても、もしくは営業や間接部門の仕事においても概ね当てはまると思います。

【パレートの法則をどのように活用するか】
まずはやるべき仕事を全部リストアップしていきます。次に仕事毎に重要度をつけていきます。そうしたら重要度順にソートし、上位20%をやるべき仕事として残し、あとは捨ててしまうもしくは時間が余ったら行うようにしておきます。あとは選別した仕事をこなすだけです。仕事量が1/5になるので余裕を持って仕事ができるはずです。

【私のパレートの法則活用事例】
というわけで私もこのパレートの法則を徹底活用しています。どのように活用しているか。

まず自分の仕事の場合、前日にToDoリストを整理し翌日やる仕事上位20%を決めてしまい、翌日はその仕事をひたすらこなすだけです。最近では決めた仕事を午前中に全て終えてしまうことも多いです。

次に部下の仕事マネージメントの場合。まず定期的な会合を持ちます。そこでは部下のやりたいことをヒアリングし優先順位をつけ、優先順位の高い上位20%の仕事に対してだけスケジュール設定します(残り80%の仕事については次回会合のときまで取っておきます)。こうしておくと普段はたまに部下の仕事の進捗状況をチェックする程度でプロジェクトはほぼ問題なく達成されます。

| | Comments (0) | TrackBack (0)

July 20, 2005

MTRGの代わりにcactiを使おう

ネットワーク監視をする際MTRGをよく使いますが、MRTGはとても扱いにくいです。そこでいろいろ探したところ、cacti(カクチと読むらしい。サボテンという意味らしい)というツールを発見しました。cactiの何がよいか。

 ・機器やインタフェースの追加・変更がWEBインタフェースから行える (←これものすごく嬉しい!)
 ・過去のグラフを参照できる
 ・ベンダ特有のMIBも簡単に使える
 ・ユーザ管理ができる
 ・グラフを分類して管理できる

これを使ってしまうともうMRTGに戻れません。是非使ってみてください。また他によいツールがありましたらどなたか教えてください。

【参考文献】
http://cacti.loaded.jp/

| | Comments (4) | TrackBack (3)

July 19, 2005

DB通信の危険性

開発者やDBAの方は普段何気なくDBにSQL文を発行してデータを取得していることが多いと思いますが、これは大変危険な行為です。そこで今回はDB通信の暗号化について記してみたいと思います。

【何が危険か】
社内にいる社員の人がデータセンターにあるDBに対して気軽にSQL文してデータを取得することの何が危険なのでしょうか。他にもあるかもしれませんが私が知る限り一番危険なのはSQL文と取得データがインターネット上を平文で流れることです。このことを気にしない、もしくは知らなかった人も多いのでは?

【施策】
おすすめする方法は次の3つです。1つだけでもいいですし、いくつか組み合わせてもよいです。

 ・VPN回線経由でSQL文発行&データ取得。
 ・踏み台サーバにSSHで接続し、そのマシン上でSQL文発行&データ取得。
 ・DB通信を暗号化することができるソリューションが導入されたクライアント&DBサーバでSQL文発行&データ取得。

【終わりに】
これだけ個人情報保護が叫ばれている中、DB通信の危険性が世の中であまり知られていないことを最近知りショックでした。皆さんどうぞお気をつけください。

| | Comments (0) | TrackBack (1)

July 15, 2005

巨大プロジェクトはやりがいを感じる、の罠

私は今でこそベンチャー企業でこじんまりとした(というか身の丈に合った)システム構築に関わっていますが、大企業に所属した頃はそれこそ数多くの巨大プロジェクトを目の当たりにしたり一部に参加させていただいたりしてきました。その当時プロジェクトマネージャーという仕事は責任が重くて辛そうだなあと思った記憶があります。そこで今回は「巨大プロジェクトはやりがいを感じる」の罠というテーマで記してみたいと思います。

【やりがいと満足度はほとんどの場合一致しない】
さて、当時私は巨大プロジェクトに関わるということはとてもやりがいがあると思っていました。いや実際今でもやりがいがあると思います。

ただこれまでいろいろなプロジェクトに参加してきて最近思うのは、やりがいと満足度はほとんどの場合一致しないということです。やりがいがある状況というのはおそらく責任が重い状態だと思います。そして満足度というのはプロジェクトを無事完了させたという充実感とそれに見合う報酬や周りからの評価だと思います。しかし現実問題、やりがいの部分ではかなり重い責任を負わされ、満足度の部分では充実感より疲労感、たいして上がらない報酬や周りからの評価という状況に陥ってしまうことがほとんどだと思います。

【巨大プロジェクトが大変な理由】
最近のプロジェクトは概して複雑化・納期短縮化・費用削減化の傾向にあります。昔のシステムは割と簡単・ゆったりとした納期・十分な予算が組まれていたのとはえらい違いです。昔のように余裕がある時代では勉強しながらトライ&エラーを繰り返しながらゆったり確実にプロジェクト進行が行えたのですが、最近のプロジェクトは概して余裕がありません。

人は人それぞれ処理能力のキャパシティが異なり、キャパシティの小さい人もいれば大きい人もいます。最近の巨大プロジェクトが大変な理由は、比較的キャパシティが大きい人にとってもキャパシティオーバーなことが多いように思います。ましてやキャパシティの小さい人にとっては言わずもがなです。

【身の丈にあったプロジェクト選択を】
以前私はこのblogの中で、どんなプロジェクトに関わるかがとても重要と書きましたが、大切なことは身の丈にあったプロジェクトに関わるということです。自分のキャパシティを超えたプロジェクトに関わってしまうと燃え尽きるだけで終わるかプロジェクト失敗という結果に終わります。

【過去参考log】
http://nosa.cocolog-nifty.com/sanonosa/2004/12/post_8.html
http://nosa.cocolog-nifty.com/sanonosa/2004/12/post_3.html

| | Comments (1) | TrackBack (0)

July 14, 2005

心がけ

どんな仕事にも当てはまりますが、

 ・他人の悪口を言う人
 ・感謝の気持ちを持たない人

は絶対に駄目です。

世の中本当の悪人は5%程度で残りの95%は善人という話しがあります。また人は感謝や信頼を感じるとその人に親しみを感じるという話しもあります。そう考えると悪口を慎み他人に感謝の気持ちを持つことは周りまわって自分の人生を豊かにするはずです。技術力の有無はそういった人としての基本があった上でしか生かされないです。


もし採用面接で上記に当てはまる人だったら落すべき。部下や友達だったら更生させるべき。上司だったら例え給料や待遇が下がろうと軽蔑し無視すべきで、それができなければ転職を考えるべき(実力さえあれば転職は容易です。実力がなければ職業選択の自由はありません。耐えましょう)です。

| | Comments (0) | TrackBack (0)

July 06, 2005

中古ストレージ機器は実用に耐えうるか

シリーズ完結編として中古ストレージ機器編です。

【ストレージに求められるもの】
中古ストレージ機器といってもいろいろありますが、ここでは定価数百万円以上のエンタープライズNASやSANあたりを対象にしましょうか。ストレージを選ぶときに重要なのは

 1. パフォーマンス
 2. データ保全の信頼性
 3. データメンテナンスの容易さ(バックアップが取りやすいとか)

になるかと思います。1はハードウェアの設計、2はハートウェア設計&ソフトウェア機能&HDDの信頼性、3はソフトウェア機能になるかと思います。


【中古ストレージ機器は買ってもよい?】
結論から言うと絶対NGですね。ハードウェア設計とソフトウェア機能は中古品でも同じですが、一番肝心なHDDの信頼性があてになりません。新品だと数千万円するNetAppが中古だと数十万円から売っているのを見るとつい購入してみたくなるのですが、HDDがいつ壊れるかわからなく、かつサポートによる無償HDD交換も期待できない点、中古ストレージ機器を購入するのは危険すぎます。

ちなみにエンタープライズストレージでよく使われるファイバーチャネルHDDは定価で1本50万円近くします。つまり中古品を買ってしまうとHDDが1本壊れる度に交換すると数十万円飛んでいくことになります。エンタープライズストレージ機器は新品で購入するに限ります。

| | Comments (0) | TrackBack (1)

July 05, 2005

中古ネットワーク機器は実用に耐えうるか

引き続いて中古ネットワーク機器編です。

【中古L2スイッチは買ってもよい?】
私の経験では中古L2スイッチであってもはあまり故障しません(ただし昔のSummitは例外。電源ユニットが良く壊れる)。ただ中古スイッチは時代的に100Mbps以下のものが多いです。最近普及しだしてきている新品ギガビットスイッチがかなり安くなってきていますから、あえて中古でL2スイッチを買う理由はなさそうです。

【中古L3スイッチは買ってもよい?】
私の経験では中古L3スイッチはハードウェア的な故障で使えなくなった経験は少ないのですが、ファームウェア的な問題で使わなくなった経験はたびたびあります。信頼性のおけないファームウェアのバージョンだったのでバージョンアップしようとしても正規に購入したわけではないのでバージョンアップできず、本番系に投入できなかったというものです。まあ使えるお金の限られるベンチャー立ち上げ初期時に簡単なルーティング程度で使うのであればあまり問題にならないかもしれません。

【中古L4スイッチは買ってもよい?】
L4スイッチといってもここではロードバランサーとしておきましょうか。単純なラウンドロビン程度を行うのであれば中古で十分かもしれません。中古であってもそんなに壊れません。ただしL4スイッチはファームウェアにバグが多いです。正規で購入しないと最新ファームウェアを入手できませんので複雑な使い方、例えば二重化だったりDSR等をするのは全くお勧めしません。

【まとめ】
ネットワーク機器は中古サーバ機と比べたら故障率は低いと思います。しかし最新ファームウェアが入手できない点ちょっと怖いところもあります。そのあたりの割りきりができるのであれば中古というのもよい選択かもしれません。

| | Comments (0) | TrackBack (0)

July 04, 2005

中古サーバ機は実用に耐えうるか

久々の技術ネタですね。小さい会社では中古サーバを購入する機会がよくあるかと思います。が、中古サーバって本当に大丈夫なの?って思いますよね。そこで経験則に基づく個人的な意見を述べてみたいと思います。

【よく壊れるパーツ】
私の経験的に中古品を買ってよく壊れるパーツはHDDと何故かonboard NICです。

中古サーバを買ったとしてもHDDはサーバ用の新品を買ったほうがよいです。間違っても個人用IDE HDDなんて買わないでください。サーバ用途だとすぐに壊れます。onboard NICが壊れるということはすなわちマザーボード交換を意味します。こうなったら修理代金が高いのでサーバ自体を廃棄するハメになるでしょう。

あと意外と盲点なのはバッテリー電池は中古品はすぐにイカれます。市販の電池が使える機種ならよいですが、そうでないと意外と高くつくかもしれません。あとラックマウントキットも中古品はイカれているものが多いような印象です。

【中古サーバは買ってもよい?】
個人的には×です。購入時の金額は安くても壊れたら修理代が高いですからね。最近の新品サーバは安いので新品を買ったほうがよいと思います。

| | Comments (1) | TrackBack (0)

July 03, 2005

よい技術書の見つけ方

記事を移転しました。

| | Comments (2) | TrackBack (0)

« June 2005 | Main | August 2005 »