« August 2006 | Main | October 2006 »

September 27, 2006

続:バグという言葉について

前回の続編です。

jspやapacheなどのエラーメッセージって、いかにもシステムトラブルだ~って画面でどきっとしますよね。たしかにあの画面を見ればユーザが「バグった~」と大騒ぎするのもわかる気がします。

そこで私はエラー画面をもっとユーザフレンドリーにすることをお勧めします。たとえばエラー画面を4コマ漫画にしてどう対応すればいいか教えてくれるとか。

ただ残念なことにそういった本質的ではない部分にはなかなか工数や予算をかけられない事情もあるんですよね。そういった遊び心を取り入れられるような楽しいシステム開発を行いたいものです。

| | Comments (0) | TrackBack (0)

September 26, 2006

バグという言葉について

ユーザはシステム不具合に遭遇すると気軽に「バグった!」という言葉を連発するが、システム開発に関わる我々からするとバグという言葉を聞くと心臓に悪いのでやめてほしいと心から願っている。そもそもバグという言葉にはプログラムの不具合という程度の意味しかない。しかし世の中を見渡してみると、バグという言葉はどうも広い意味で使われすぎているように思う。そこで今回はバグという言葉について考えてみたい。

【バグという単語の一般化はファミコン時代から?】
バグという言葉が大衆化したのはファミコン時代からではないかと思う。ファミコンで気軽に遊ぶ子供達が、動作不具合を見つけるや「バグだ。バグった」の大騒ぎ。ファミコンの場合システムトラブルの原因にはプログラムの不具合の他にカセットの差し方が悪い、ほこりがたまりすぎてショートした、熱暴走等々様々な要因があったが、子供達はそれらをひっくるめて全て「バグった」という言葉で片付けてしまった。ここからバグという言葉に対する誤用の一般化が始まったのではないかと思う。

【これはバグなのか】
社内でシステムを使ってもらっていると、たまに「これはバグですか?」という問い合わせが来ることがある。調べてみると、元々要件定義になかったので実装していなかった機能についてだったり、ユーザに使い方を誤解されていたりといった場合が多い。これらは明確にバグではない。何故なら仕様通りでありプログラムの不具合ではないからだ。

【今後のバグという言葉について】
ユーザにとって、自分自身が想定しない境遇に陥った場合それらはすべて「バグ」と片付けてしまうことが多い。ユーザにとってシステムは一つのブラックボックスであって、自分の思い通りに動かなければ原因がどんなことであれ「バグった」状態である。

しかし我々はユーザに対して「これはバグだ」「これはバグではない」という説明をしたところで全く効果はないだろう。何故なら、ユーザにとっての関心ごとはシステムが正常に動いているか動いていないかであって、これまではそれを「バグった」という一言で説明できていた。我々がバグという言葉の正確な定義を教えたとしても、ユーザがそのような便利な言葉を簡単に手放すとは思えない。そう考えると今後も「バグ」や「バグった」という言葉はシステム不具合と同義語で使われ続け、消えてなくなることはないだろう。残念なことである。

| | Comments (2) | TrackBack (0)

September 22, 2006

評価されるための仕事術

どんなに頑張っても評価されない人がいます。逆に普段あまり仕事をしていないように見えてもちゃっかり評価されている人もいます。この違いは何でしょうか。そこで今回は評価されるための仕事術について考えてみたいと思います。

【まずは評価制度をよく知ろう】
皆さんの評価は所属する会社の評価制度によって決定されます。その評価制度はどのような性質のものか考えたことがありますでしょうか。例えば

・給与の元となる原資が少ないため、従業員の給与を低く抑える性質。
・勝ち組と負け組を区別し、勝ち組には手厚く、負け組には薄く給与を支払う性質。
・一応評価制度という名前になっているが実質的には年功序列。

などなど傾向があると思います。給与を低く抑えるための評価制度なのだとしたらそもそもその会社にいてもダメ出しされるだけで評価など期待できないかもしれません。

また「他人を蹴落としながら個人プレーで高い業績を上げた」場合、プラス評価でしょうか、それともマイナス評価でしょうか。この場合は評価制度によって評価が全く正反対になるパターンですね。


【どうしたらプラス評価になるのか知ろう】
プラス評価されたいのであれば、どうやったらプラス評価に繋がるのか理解することが必要です。

「毎日日常業務を一生懸命やっているのに一向に評価されない」と悩んでいる人をよく見かけます。日常業務の場合、やって当然で評価に値しないとする評価制度が多いようです。

一般論として、社会人としての常識をわきまえチームワークを重視しながら、日常業務も当然普通にこなし、その上で何か特別なことを成し遂げた場合プラス評価につながります。どんな事例が特別なことなのかは自分が評価者の立場だった場合にどんなことを特別なこととして評価するかを考えれば自ずと答えが出るかと思います。


【評価制度は全体のバランスが重視される】
評価制度で最も重要なことは全体のバランスです。頑張っている人全員を評価したいのはやまやまなところだと思いますが、システムとしての評価制度として考えた場合、評価分布を山なりカーブを描くようにしないとバランスが悪いです。そう考えると、自分が何を成し遂げたかということも重要ですが、組織全体として自分が評価分布の中のどこに置くと整合性が取れるか、言い方を変えると合理的な説明ができるか、と言った観点で最終評価が決定されます。よって評価されたい場合は最終評価決定者が高評価を合理的に説明できるような成果を出す必要があります。


【まとめ】
評価されるためには、組織全体のバランスとして今自分はどのポジションにいるのか意識しながら、日常業務以外のことで、どのようなことを行うとプラス評価につながるか考え、そしてもちろんそのことに対して成果を出すことが必要になります。くれぐれも無計画のまま日常業務を頑張ったことで自己評価で高得点をつけても評価されないなんてことにならないように気をつけましょう。

Yahoo!ホスティング

| | Comments (0) | TrackBack (0)

September 19, 2006

IT業界の平均年収

IT業界の平均年収が出ていましたので1枚の画像にまとめてみました。

Salary

ここの画像を編集させていただきました。

| | Comments (2) | TrackBack (0)

September 14, 2006

現実的でバランスの良い冗長化について考える

今月分の@IT連載記事が掲載されました。タイトルは「現実的でバランスの良い冗長化について考える」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/07/01.html

| | Comments (0) | TrackBack (0)

September 13, 2006

ブレードサーバは仮想化の実現に向かっている

ブレードサーバの特徴と聞くと「省スペース」だとか「配線が少なくて済む」だとかその程度の認識の方も多いでしょう。実際その程度のコンセプトで製品開発をしているメーカーも多いですが、ブレードサーバの向かっている先はもっと壮大なものです。そこで今回はブレードサーバの向かっている先について記してみます。

【その1: 高密度化】
まずは高密度化です。何のために高密度するかというと1ラックに搭載できるサーバ台数を増やすためである。ただし高密度化しすぎると発熱の問題や消費電力の問題があるので1ラックに目一杯ブレードサーバを搭載できるわけではないので今後は発熱量と消費電力問題の解消が真剣に図られることだろう。

【その2: 可用性向上】
次に可用性向上です。ブレードを冗長部品と考えると理解しやすいと思います。複数枚のブレードを刺しておき壊れたら切り離す、というわかりやすい仕組みです。次にサーバ管理上配線トラブルが多いですが、ブレードサーバは配線が最小限に済むのでメンテナンスが多いシステムでは結果的に可用性が上がります。また共用部分をシャーシに搭載しますので複数台のサーバを購入するより部品数が減るということもあります。

【その3: 仮想化】
しかしブレードサーバの究極の姿は、仮想化の実現です。

仮想化とは、CPU、メモリ、ストレージなどのハードウェアリソース等をソフトウェアで仮想的に論理的に分割して使う仕組みです。仮想化は汎用機(メインフレーム)で一般的に使われている思想で、IAサーバは数年~数十年遅れで汎用機の思想を追いかけていることになります。仮想化の最大限のメリットは耐障害性とリソースの効率利用です。ハードウェアを多重に冗長化することによる耐障害性と、ハードウェアリソースをシェアすることによるリソースの効率利用の両方が図れるわけですね。

この説明でぴんとこないかたはOSを思い浮かべてください。複数のタスクやスレッドを1台のPCで同時に動かすことができるのはOSがハードウェアリソースを管理しているからです。仮想化では複数のタスクやスレッドだけではなく、複数のハードウェアリソースも管理するようになります。

| | Comments (0) | TrackBack (0)

September 11, 2006

デフラグの有効性について考える

デフラグが好きな方は多いと思います。真っ赤なグラフが次第に青に変わっていく姿は精神的に心地よいものがあります。しかし最近「デフラグって実はあまり効果がないのではないか?」という説をよく聞くようになりました。そこで今回はデフラグの有効性について考えてみることにしました。

さて、デフラグの有効性を考える上でポイントは3点ありそうです。

【ポイント1:デフラグでパフォーマンスは向上するのか?】
断片化したデータを連続的に再配置するのがデフラグの役目です。デフラグ実施後に最も効果を発揮するのはシーケンシャルな(連続した)データにアクセスする場合です。それに対してランダムアクセスの場合、特に小さいサイズのファイルを対象としたランダムアクセスの場合はデフラグ効果があまりありません。また年々OSやHDDのバッファサイズが増えていて、HDDへの物理的なアクセス速度がバッファで吸収されていく傾向にあります。

以上を総合すると、アクセスしようとするデータ中に明らかにシーケンシャルなデータが多い場合はデフラグによるパフォーマンス向上が見込めますが、そうでない場合はデフラグを行っても大してパフォーマンスが上がらないという結論になりそうです。

【ポイント2:デフラグはHDDの寿命を縮めるのか?】
この議題に対しては、「寿命を縮める派」と「むしろ寿命が延びる派」が存在するようです。まずは両者の言い分を聞いてみましょう。「寿命を縮める派」の主張としては、デフラグはそれ自体HDDアクセスなので、デフラグばかりやっていると当然HDDの寿命が縮まるという意見。それに大して「むしろ寿命が延びる派」の主張としては、常にHDDが断片化された状態だとヘッドがあちこちに動きまわる状態なので、デフラグを行ったほうがヘッドの無駄な動きが減りHDDの寿命が延びるという意見です。

それぞれの主張を見てみると双方それなりに筋が通っているので、場合によりけりという結論になりそうです。デフラグを行う頻度や断片化されている程度によると思います。

【ポイント3:デフラグの失敗でデータが失われることがあるのか?】
各々のデフラグツールのアルゴリズムや実装についてまで知る術がないので断言はできませんが、デフラグ中にマシンが異常終了したり停電が起こった場合、データが失われる可能性はたしかに否定できないです。よってデフラグの失敗でデータが失われることはたしかにありそうだという結論になりそうです。

【結論】
既に記したようにシーケンシャルなデータを連続的にREADするような特殊な状況においてはデフラグはものすごい有効だと思います。しかし一般論として個人的な結論を述べるとすると、デフラグには多くの時間がかかること、デフラグの失敗でデータが失われるリスクがあること、及び劇的にパフォーマンス向上が見込めないことを考えると、一般的な期待値よりもデフラグの有効性は低いのではないかと思いました。

※追記:デフラグネタを出すと、必ず「Linuxなどのようにデフラグが必要ないファイルシステムに比べたらWindowsのファイルシステムは不完全だ」という意見が出ますが、いいかげん聞き飽きましたので自分から書いちゃいます。なぜLinuxなどのファイルシステムではデフラグが必要にならないかご興味がある人はネット上のどこかに書いてありますから探してみてください。

| | Comments (1) | TrackBack (0)

September 10, 2006

IT技術者と肩こり

PCに向かっていることが多いIT技術者にとって、肩こりは職業病の一つだと言えます。かくいう私も肩こりに大変苦しんでいて、いろいろ調べました。そこで今回は私が知っている範囲で肩こりについて記してみます。ただし言うまでもなく私は医療系の専門家ではありませんのでその点はご注意ください。

PS: 余談。実は高校生のときは薬学部志望でした。そのとき受かっていたら(ふっ、落ちたのさ・・・)今はIT技術者ではなく薬剤師になっていたことでしょう。ところで昨日たまたま横浜そごうの本屋で薬学系の専門書を開いてみたら内容が鬼のように難しくてびっくりしました。薬学の道に進まなくて正解だったのかもしれません(苦笑)。薬学部といえば受験会場が女性ばかりだったのが印象深いです。ほんと余談でした。

【肩こりの種類】
肩こりの原因にはいろいろあるようです。一番わかりやすいのは血行不良なのですが、それ以外にも内臓系の病気などいろいろあるそうです。今回さすがに全ての肩こりの原因を追っているときりがないので、今回は血行不良による肩こりに限定したいと思います。

【血行不良の原因】
血行不良の原因は

1.姿勢が悪い
2. 運動不足
3. 食生活で油ものが多い
4. 湯船に浸かることが少ない

が主なものだと思います。

1については、とても重い人間の頭を首でうまく支えることができず、首が肩をひっぱることでその部分の血行が悪くなります。

2については、運動しないことで血流が悪い、筋肉が退化することで首や肩が頭を支えきれなくなる、こりかけている部分の筋肉をいつまでも使わないのでいつまでもほぐされない、という3つが考えられます。

3については、油は血中のコレステロールを増やし、血流を悪くします。

4については、湯船に浸かると血流が活発化されますが(運動するのと同じ効果)、シャワーだけだとそんなに活発化しません。


【肩こりの解決方法】
根本的な解決には血行不良の原因に記したことと反対のことをやればいいわけですね。それ以外の方法はまずないと思います。

応急処置という意味で思いつくのは以下の通りです。

1. 足裏マッサージ・マッサージをする。(女性客の多い癒し系リフレクソロジーでは駄目。個人的には台湾式のハードなものがお勧め)

2. 首周りのマッサージをする。(http://plaza.rakuten.co.jp/yuhdisensei/diary/200508280000/)

3. はり・きゅうをする。(実はまだやったことないです。どなたか体験談please)

4. 目の疲れを取る。(知人から聞いた方法をコピペですが、ガーゼかハンカチをぬらして湿らせて両目の上におくので、長方形に折って冷凍庫へ三本。他に湿らせたものを3本。冷えた1本目を寝て目をつぶった上において冷やしてその間に、電子レンジで1本を1分温める。3分ぐらい目を冷やしたら、2分ぶん冷めた温かいほうと交代。それを三セット。)

| | Comments (0) | TrackBack (0)

September 08, 2006

Notesの基礎概念

Notesは古いアーキテクチャーで現在主流の3階層モデルとは概念がずいぶん異なります。そこで今回はNotesの基礎概念を図解してみたいと思います。ではご覧ください。


※3階層モデルでは1システムにDBが一つですが、Notesではメールユーザや機能毎にDBを用意します。


※NotesDB内にはデータ(文書)だけでなくプログラム(設計)も保持します。また閲覧/編集などの権限が入ったプロパティ(属性)も保持します。


※設計を更新したら、マスターDBに反映後、関連DBにコピーします。(例えば掲示板のロジックを変更する場合など)

| | Comments (1) | TrackBack (0)

September 03, 2006

情報過多時代の情報管理

最近はありとあらゆる情報がネット上に公開される時代になったことで、取り急ぎ必要な情報はネット上で探してきて済ませてしまうという人も多いかと思います。しかし情報をネットに依存しすぎると情報におぼれる危険性があります。そこで今回は情報過多時代の情報管理というテーマを記してみたいと思います。

【情報を溜める時代】
価値ある情報がネットにたくさん公開されるようになってから、一人一人が目に触れる情報が以前とは比べ物にならないくらい多くなってきています。いわゆる情報過多時代ですね。情報過多時代に対応するために、最近では情報にタグ付けすることで有用と思われる情報を溜めておくことで個人情報データベースを作っておき、いざというときに必要な情報を引き出す情報管理手法が流行しています。この方法は全部の情報に目を通すことができない情報過多時代には一見合理的な方法に見えます。

【情報過多時代は情報破滅を招く】
しかし個人情報データベースのメンテナンスには大変な手間がかかります。個人情報データベースを常に価値あるものにするためには日々多くの情報源に触れ日々新しい情報を追加する必要があります。一度個人情報データベースを作り始めると少しでも価値がありそうだと直感的に思った情報を次々と溜め込むようになります。一度この習慣がついてしまうと日々ますます情報を探すようになり、近いうちに情報破滅を招きます。

【価値ある情報はその場で理解し、あとは捨てる】
価値ある情報をとりあえずブックマークしておいてあとで読もう、と思うことは多いですが、実際はそういう情報はほとんど読まれません。であるならば、その情報を見て読む価値がある瞬間によく読んで理解までしてしまうことです。またその場で読めない情報は潔く捨てる勇気も必要です。この習慣をつけないといつまでも情報集めだけに時間が取られ、肝心の情報を理解する行為がまったくできなくなることでしょう。

| | Comments (1) | TrackBack (0)

« August 2006 | Main | October 2006 »