« March 2005 | Main | May 2005 »

April 29, 2005

ネットワークエンジニアに必須の資質

ネットワークエンジニアの採用面接は苦手な仕事の一つです。設計と構築にそれなりのセンスが要求されるネットワークエンジニアをどうやって見極めればいいのか百発百中の方法論が自分の中でまだ確立されていないことがその要員です。そこで今回はネットワークエンジニアに必須の資質を考えてみて、今後自身の採用面接に生かしてみたいと思います。

【大前提】
まずネットワーク構築というものはどういうものか。大前提としてカットオーバー時から完璧でないといけないという性質があります。他のシステムではバグが出れば直せばいいわけですが(もちろん限度はありますけどね)、ネットワークはある種全てのITインフラの根幹なので、曖昧性は許されずとにかく完璧でないといけません。

ただその要求度の高さから普通の会社ではある程度難易度の高いネットワーク構築プロジェクトにはなかなか携わらせてもらえないという現実があります。面接に来られる方で非常に多いのはこれまで所属していた会社ではL2スイッチまでは扱わせてもらえたけどL3以上は絶対に触らせてもらえなかったというようなパターンです。ましてや機器冗長化やBGP、大規模ルーティング等の難易度の高いネットワーク構築に携わったことがある人は本当に少ないのが現実です。


【ネットワークエンジニアに必須の資質】
それを踏まえてネットワークエンジニアに必須の資質を考えてみたいのですが、僕は次の要素を挙げます。

 ①マニュアルをきちんと熟読する習慣がついていること。
 ②ネットワークの動きを理解する際、パケットの立場になって考えることができること。
 ③曖昧な理解で行動することが嫌なこと。

①については過去ログでも触れましたがエンジニアとしては必須です。ろくにマニュアルも読まずにL2スイッチを家庭用HUBと同じ要領で適当にいじる人って意外と多そうですが個人的にはそんな人がエンジニアと名乗ることはとても許せません。

②については例えばNICが2枚刺さっているサーバにそれぞれDefault Gatewayを設定した場合どういう挙動が想定されるかだったり、HUBでコリジョンが起こったら内部の仕組みとしてどうなるかだったりそういったことまで考えが及ぶかということです。表面的な結果だけでなく原理についてまで理解しようとする人であればかなり応用力が高い人であると言えそうです。

③については日に日に高機能化するネットワーク機器で機能的によくわからない部分があることが気持ち悪いと思うか、まぁいいかと思うかの違いです。


【ネットワークエンジニアをどのように面接すればよいか】
ということで最後に面接についてです。「ネットワークエンジニアに必須の資質」を見ていただければわかる通り、僕自身は資格の有無や経験の有無はあまり気にしてません。過去ログネットワークのプロと呼ばれるためにはでは皆さんから「実機経験のないネットワークエンジニアをプロと呼ぶことは納得できない」という類のコメントを何件かいただきましたが、僕は実機経験の有無よりも原理原則をきちんと押さえているかいないかというところが物事の本質だと思っています(もちろん一部の天才を除けばその域に達するために実機経験は欠かせないものだとは思いますけど)。

というわけでネットワークエンジニアに必須の資質が応募者にあるかどうかを見極めるのは本当に難しいんですよねえ。皆さんだったらどうしますか?

| | Comments (2) | TrackBack (0)

April 28, 2005

何故この人は気が利かないのか

何をやるにしても全然応用が利かない人がいます。もうちょっと気を利かせてくれてもいいのに、と思うこともありますが、そういう人には期待するだけ無駄だと思わせる何かがあります。そこで今回はその何かについて考えてみたいと思います。

【法則1:モノ作り経験のない人は気が利かない】
モノ作りというのは自分自身の想像力を働かせながら行う知的作業であるとも言えます。モノ作りの経験がある方はよくわかると思いますが大抵想定していなかったところで問題が発生します。私はそういった部分の対処を繰り返していくことが注意力を向上させ最終的に気が利く人になっていくのだと思います。

→最近このモノ作りをしたことのあるという人がものすごく減っていると思うのですが困った現象です。教育問題の本質はこういうところにあるのかも。


【法則2:結果に興味のない人は気が利かない】
近年競争社会の弊害がいたるところで叫ばれますが、私はある程度の競争社会はむしろ人間の健全な育成につながると思っています。その理由の大きなところでは物事にはかならず結果が伴うということが体感されるからです。結果を意識することのできる人は必然的に途中プロセスにも関心を持ちます。かなり極端な意見ですが、競争社会を経験せずに育った人には結果にあまり関心を持っていない人が多いのではないかと思っております。

→高卒・専門学校卒の人と比べて大卒がこのあたり強いのは、当然ポテンシャルの問題もあるかもしれませんが、それと共に受験戦争を体験したことにより必然的に結果主義を身につけたことが大きいと私は思っています。

| | Comments (4) | TrackBack (2)

April 22, 2005

多国籍間SI構築の難しさ

現在私は某SI構築のプロジェクトマネージャーを担当している。某といいつつずばり書いてしまうと韓国本社で開発して使っている業務支援システムを日本向けにローカライズしてもらうという内容である。

このプロジェクトが現在難しい局面を迎えている。これはシステム開発一般的な問題に加え、多国籍間のコミュニケーションの難しさに原因が由来する。

【システム開発一般的な問題】
まず第一に利用部署のキーパーソンが非常に多忙でなかなか要件定義がまとまらないという状況である。実は要件定義が曖昧なまま開発に突入し、プロトタイプが完成してきてからキーパーソンの方にチェックをいただいたところ全然駄目ということになり現在要件定義から差し戻しという事態となった。(もっというとプロジェクトのメンバー全員、最近までその方がキーパーソンだということに気づかず、皆毎回参加している利用部署からの担当者がキーパーソンだと思い込んでいた・・・)

→キーパーソンの人が要件定義の責任者であるべきである。


【多国籍間のコミュニケーションの難しさ】
システム開発のプロセスはどの国も似かよったものであると考えると大変なしっぺ返しにあう。少なくとも日本と韓国では細かい部分でかなり異なる。要件定義において日本ではある程度IT部門が関わるが、韓国では利用部署の中である程度要件定義してしまうようである。議論の段階では日本では議論を行うプロセスに大変時間をかけるが韓国ではトップの間である程度決めてしまいトップダウン式にgoを出すことが多いようである。それから日本は自分の意見を述べるとき周りの雰囲気を見ながら発言するが、韓国はかなりストレートである。

それに加えて今回の場合、韓国側の担当者がほとんど日本語を話せないため、日本側は日本側で、韓国側は韓国側で議論を進めてしまい、意見すり合わせの段階で全然意見がかみ合わない状況となった。意見がかみ合わないだけでなく意見の言い方が日本側は遠まわしで韓国は直接的という部分で険悪となったりもした。

→相互理解がないとコミュニケーションが成り立たない。


【まとめ】

プロジェクトは人が行うものであり、人選というものがものすごく大切だと感じている。キーパーソンがきちんと意見を言うことと、国際的なプロジェクトの場合はある程度国際的な感覚を持つ人が中心人物でないとプロジェクト自体が崩壊するはめになるかもしれない。でもこれは結局プロマネとしての自分の責任であったりもする。はぁ。

| | Comments (2) | TrackBack (0)

April 20, 2005

第1回技術者交流会の報告

昨日は20名ほどの皆さんにお集まりいただきましてありがとうございます。皆さん無事に帰れましたでしょうか。今後も今回の反省を活かしながらほそぼそと(?!)続けていきたいと思いますので引き続きご参加よろしくお願い致します。

さて、当日の報告です。思いつく限り箇条書きで書いてみます。

・全員遅刻もなく(G社のKさん除く( ̄ー ̄)ニヤリ)時間通り集まっていただけました。
・1次会はスペイン料理(でしたっけ)のお店で、結構美味しかったです。
・出席者は男性ばかりでしたね。(今後の課題?)
・全員煙草を吸わないのにとても驚きました。
・運用系の方が多くて開発系の方は少なかったです。
・技術者の集まりということで心配していましたが、皆さん結構よく話していただいてよかったです。
・ぷりん友の会会長(というか大学時代の先輩)に参加いただけました。
・PCやサーバはやっぱりどの会社でもDELLなんですね。(安いですもんね)
・皆さんいろいろなLinux使われてますね。
・一部商談が成立したようでおめでとうございます。
・技術者交流会に期待することを皆さんにお聞きしたのですが、技術者は横のつながりを作りにくいのでこの場でそれを期待するといったものだったり、システム運用上の裏話をいろいろな人と共有したいといったものだったりが多かったですね。
・1次会は22:30頃まで続きました。

・2次会は例によってベルギービール屋です。8名にご参加いただけました。
・生ハム美味しかったですね。
・ベルギービール相変わらず美味しいですね。飲みすぎちゃいました。
・どの技術者交流会もそうなんですが、2次会以降のほうが本当の意味での技術者交流会という気がします。技術的な話しをたくさんできました。(1次会って人が多いのでどうしても名刺交換と世間話しで終わってしまうんですよね・・・)
・2次会は24:00頃まで続きました。

・交流会参加者のみが入れるメーリングリストができました。そのMLに入りたい人は・・・次回交流会にご期待ください(でよいですかね?>ML管理者Tさん)。


最後に。お手伝いいただいたTさんとIさん、改めまして本当にありがとうございました。m(._.)m ペコッ

| | Comments (2) | TrackBack (0)

April 11, 2005

Linuxで表示言語を変えたいときは

完全覚え書きです。Linuxで表示言語を変えたいときは

/etc/sysconfig/i18n

を書き換えます。

LANG="ja_JP.eucJP"

LANG="en_US.UTF-8"

とするとメッセージが日本語から英語に変わります。日本語だと文字化けするので嫌という人にお勧めです。(?!)

| | Comments (1) | TrackBack (0)

April 10, 2005

LAN内にループがあるとどうなるか

記事を移転しました。

| | Comments (0) | TrackBack (0)

April 08, 2005

ポートフィルタリング設定後DNSが引けなくなった場合

DNSはUDP53番ポートを使うということを知っている人は多いです。しかし「ポートフィルタリング時UDP53番ポートさえ開ければよい」と思っているとしたら間違いです。関連ドキュメントをよく読んでみると「受けはUDP53番だが、戻りはUDP1023番以降を使う」と書いてあります。ファイアウォールを使うと戻りの部分はファイアウォールが勝手にやってくれるので意外とこのことを知らない人も多いのではないでしょうか。


PS: こういうことがあるので、くどいですがドキュメントというのはしっかり読み込まないといけないです。ドキュメントを読まない人はこういうことに全然気づかないと思います。

| | Comments (0) | TrackBack (0)

April 06, 2005

技術者には2タイプ存在する

経験則ですが、どうやら技術者には2タイプ存在しそうです。活躍がイマイチだと感じる技術者がいたらひょっとしたら自身のタイプを勘違いしているのかもしれません。

【開発者型】
勝手に開発者型と命名してますが、要するに1つのテーマにずっと集中して取り組むことができる人のことです。このタイプの人がシステム管理職に配属されると仕事が次々に降ってきて全然集中できずイライラしてしまいます。

【システム管理者型】
システム管理者型は広く浅くいろいろな仕事を同時にこなすことができる人のことです。このタイプの人が開発職に配属されると開発途中で飽きてきてしまい仕事が苦痛に感じるようになります。


採用面接のときにこの基準と照らし合わせて見てみると面白いと思います。ちなみに僕は完全なシステム管理型です。開発ってできなくはないですが飽きてきちゃうんですよねえ。特に目に見えない例外処理あたりを作り始めるとすぐに妥協したくなってきてしまいます。これが僕が開発をやらなくなった大きな理由ですね。

| | Comments (5) | TrackBack (4)

« March 2005 | Main | May 2005 »