« 2007年8月24日

2007年8月25日の投稿

2007年8月28日 »

まだまだ暑い日が続きますので恐い話を集めました。
ITの見えてはいけない明日が見えるかもしれません。
(すべてフィクションと思われる噂話です)

1.発生しないはずの例外が……

私はあるプロジェクトでプログラマをしていました。
そのシステムは会計系のシステムだったのですが「念には念を入れて」
の方針により、あり得ない例外処理を多く作り込む必要がありました。

開発期間も長期化し、メンバーの疲労はピークに達していました。
私もそのうちの1人でした。集中力を欠いていたのかもしれません。
普段ならそんな事はしなかったと思います。
通るはずのない分岐処理に

 MessageBox.Show("微妙な処理すんな(゚Д゚)ゴルァ!")

と書いてしまったのです。
ええ。リリースから7ヵ月後のある日、お客様のお偉い様の端末で
(゚Д゚)ゴルァ!したそうです。
その後私はお客様からと上司から思いっきり(゚Д゚)ゴルァ!されました。

これは恐いですね。メッセージに出してしまうのは問題外ですが、
ソースのコメント部分には自由な意見が書き込まれることもありますね。
見られると困るようなコメントを書いたことがある人は多いのではないでしょうか?

2.スーパーハッカーの攻撃が……

私は友人と2人でチャットをしていました。
その時、チャットルームに怪しい男が入って来たのです。
 〓〓〓怪さんが入室しました!〓〓〓
 私「こんにちわ」
 友「おはつでーす>怪さん」
 怪「気持ちわりーな。馴れ合ってんじゃねーよ!」
私は荒らしだと思って無視しようとしました。
しかし友人が挑発に乗ってしまったのです。
 友「おいおい。ネチケット守れよ」
 怪「オレはハッカーだ。文句言う奴はPC壊すぞ」
 友「やってみろよ」
 怪「じゃ、IPアドレスを言ってみろ」
ここで私は友人を止めようとしたのですが、
そうする暇も無いうちに友人は答えてしまったのです。
 友「219.xxx.xxx.xxxだよ。」
 怪「ばいばーい♪」
 〓〓〓友さんが退室しました!〓〓〓
私は嘘だと思いました。IPアドレスを教えただけでチャットから退室させるなんて。
 怪「今頃はPCから煙吹いてるぜ。」
 怪「お前のIPアドレスも教えろよ>私」
この人は本物だと思いました。本能でそう感じたのです。
ヘタに逃げようとしたら、余計に逆上するかもしれません。
私はPCにあまり詳しくないのですが、やっとの思いで
自分のPCのIPアドレスというのを調べてこう言いました。
 私「わかりました。正直に言うので許してください。」
 私「私のIPアドレスは127.0.0.1です。」
 怪「ばいばーい♪」
 〓〓〓怪さんが退室しました!〓〓〓
私は見逃してもらったのだと思いました。正直に言ったので許してくれたのでしょう。
私は友が復帰するかもしれないと思い、5分ほど待つことにしました。
 〓〓〓怪さんが入室しました!〓〓〓
 怪「攻撃ツールのOKボタンを押した瞬間にPCが煙を吹いちまったぜ。」
 怪「運が良いやつだ。オレはオーバークロックとかやってるからPCが熱いんだ。」
 怪「サブのマシンがいかれちまったから
メインマシンを出してきたぜ。」
 怪「メインマシンはもっとすごいぞ。コンピュータ名だけでお前を叩ける。」
 怪「さ、コンピュータ名を言ってみろ。」
私は今度こそダメだと思いました。しかし抵抗しないほうが良いと思ったので、
自分のコンピュータ名を何とか調べて答えました。
 私「localhostです。」
 怪「ばいばーい♪」
 〓〓〓怪さんが退室しました!〓〓〓
それ以来、この男には会っていません。



これは有名なアメリカンジョークですね。
全然恐くありませんが、怪談調に改変してみました。

3.まじめに仕事をしたはずが……

私は侵入テストのテスターをしていました。
これでも脆弱性を発見するスキルには自信があるんですよ。
その日もある会社のwebサーバに対してインターネット経由で
不正侵入をできるかどうかの検査を行うところでした。
「なんだよ。いきなりtelnetのポートが開いてるぞ」
「rootでpasswordって入れたらログインできるってテストってレベルじゃねーぞ」
「こんなんでうちの会社にわざわざ金払って検査しろってどんだけー」
自分はwebサーバのコンテンツディレクトリに
侵入した証拠となるHTMLファイルを置きました。
そしてお客様に電話をしました。

私「もしもしー。あっと言う間に侵入できましたよ。」
客「えっ本当ですか?」
私「トップページのHTMLを変えたんで見てみてくださいよ」
客「……いえ。変わってませんが」
私「えっ?書き換えましたけど」
客「どうやってですか?」
私「telnetで入りましたが」
客「telnetは動いていないはずですが」
そこで私は端末を見つめました。
私「お客様のアドレスってxxxxxxxx.co.jpですよね」
客「ええ。xxxxxxxx.co.jpですが」
そこで1つの事実に気付いたのです。
やっちまった



侵入テストを行うときに侵入先を間違えるととんでもないことになります。
ここではco.jpと間違えてgo.jpを指定してますね。一歩間違うとテロ認定の恐れも……。
同じような事例で、サーバ室でサーバを取り違えるという噂も聞きました。
サーバ室は入退室管理がばっちりであるため、それぞれのサーバラックには鍵をかけておらず、
また、端末もログインしっぱなしだったために事故が起きてしまったとか。

4.押したはずのないキーが……

[root@xxxxx]#
[root@xxxxx]#rm -rf /
ガリガリガリガリガリガリガリガリ
アッー。BSと間違えてEnterを……。



この間違いはあまりにもダメージ(精神的ダメージ含む)が大きいです。
そのせいか、はてなにこんなページがありました。くれぐれもご注意ください。
もし経常的にあるディレクトリをrm -rf #### するようなコマンドを使う必要があるなら
シェルを作っておくと良いと思います。

5.真夏の赤いセーター

新人のオペレータがサーバルーム勤務になった。
あまりに寒いので、真っ赤なセーターを着た。
静電気でサーバを壊し、真っ赤なパトランプが回った。



静電気は電子機器の大敵です。
サーバルームでは湿度が下がりすぎると静電気による事故のリスクが高まるため、
加湿器を設置して湿度をコントロールするところもあります。
ちなみにJISのT8103には静電気を防止する服と靴の規格が定められています。
わざわざT8103の合格品を制服に採用して運用しているセンターに
アクリルのセーターなど着ていったら裸にされた上で
冷風の送風口に縛り付けられるかもしれません。

6.恐怖のドキュメントフッター

ある日、お客様との打ち合わせに向けて資料を作成していた。
正直なところ、取れても取れなくても良い仕事だと思っていた。
他のお客様に使った資料の再利用でちゃちゃっと仕上げる。
印刷した資料を持ち、お客様との打ち合わせに挑んだ。
元々は全身全霊を込めて作った資料だ。
使いまわしがばれないように細心の注意で修正したし大丈夫だろう。

客「君さ、うちの会社のこと舐めてるでしょ」
私「(絶句)」

何が起きたのかわからなかった。
お客様は難しい顔でドキュメントを見ている。
何故だ。社名はすべて入れ替えたはず。
ん?フッターにファイルの保存先が。

  C:\docs\後回し\本気度低め\受注確度低め\株式会社A様\提案書.doc



自分のPC内のフォルダ命名ルールは個人の自由ですが、
うっかり印刷してしまうととんでもないですね。

7.タバコ部屋の生霊……

その昔、プログラム仕様書は肉筆で作られていた。
アルファベットの1文字1文字を
テンプレート定規を使用して丁寧につづっていく。
ある若手社員が100ページ以上に及ぶ仕様書を作成した。
完成したので上司に見せに行く。

上司はタバコ部屋にいた。
一通り目を通し、「ま、こんなもんかな」とつぶやくと
タバコの火消しバケツの水の中に仕様書をドボーン。
「もっかい新人研修からやり直して来い」

肉筆の仕様書は、原本を失ったら修正できない。すべて書き直しとなった。
その時にバケツから絨毯にこぼれた水の跡が、
今も苦しむ人の顔の形の染みになっていると言う。



今なら電子ファイル修正してプリンタのアイコンをクリックで終わりですが、
肉筆で作成したものを捨てられるダメージはいかほどか。
手書き仕様書が用いられる時代のコンピュータ処理と言えば、
CPU利用時間による課金が全盛だったと聞きます。
無駄が多いプログラムはお金も無駄にしてしまうため、厳しく断罪されたのでしょう。
そういえば、CPU課金のシステムで無限ループを起こしたら、というのも恐い話ですね。

8.破壊される磁気記憶

私の会社では記憶媒体のすべてにQRコードを貼りつけて管理しています。

ある日、お客様からフロッピーディスクで大切なデータを受領しました。
しばらく色々な端末でそのデータを読み込むうち、
受領したフロッピーを失くしてしまいました。
重要なデータであったため複写は取っていません。
引き出しや机の下などを探しましたが見つかりません。
顔面が真っ青になりました。
重要データの紛失と、磁気媒体管理の不始末。
始末書を書かなくてはならないかもしれません。

しばらくして、会社の共有ホワイトボードに
落し物コーナーがあった事を思い出しました。
祈るような気持ちでそこに行きました。
そしてホワイトボードに貼り付けられたフロッピーディスクを見つけ、
胸を撫で下ろしました。

そしてその後に気付いたのです。
ホワイトボードにフロッピーディスク?
そうです。
マグネットで止められていたのです。



そういえば5インチのフロッピーってセットしてからロックレバーを操作してましたね。
フロッピーが磁気で壊れてしまうということすら忘れていました。

9.山小屋で遭難……

あるSEが4人で登山中に遭難しました。
山小屋は真っ暗で寒いです。
朝まで眠らないための方法を考えることにしました。
男達は4隅に立ち、最初に1人がどちらかの角まで歩いていきます。
そこの角にいた人にタッチをしたら、その男は次の角に立つ男をタッチする、
と言う方法で朝まで運動するか?ということになりました。
 SE1「タッチメソッドはスーパークラスの『男』に持たせよう」
 SE2「いや、普通に考えてimplementsだろう」
 SE3「concreteなのかabstractなのか、それが問題だ」
 SE4「いや、そもそもこれ5人じゃないとできない……」
 SE1「SE4よ。それは仕様なのだ。仕様どおりに設計することが重要だ。」
 SE2「そうだそうだ。おい。誰かGOF本持ってるか?」
 SE3「当たり前だ。どこへ行くにもこいつは手放さんよ」
夜が明けるまで議論は続きましたとさ。



ちょっと笑えないですね。確かに長い打ち合わせってあります。
ちなみに元ネタは4人で山小屋に泊まり、
4隅を使って眠らないようにゲームをするという有名な話です。

 

しかし恐い話を聞くとなんで涼しく感じるんでしょうか。
rm -rf / というコマンドを間違って打ってしまうという恐い話がありましたが、
実際に間違いそうになるだけで背筋がヒヤリとします。
もし、これぞという恐い話をお持ちの方がおられましたら
コメント欄で教えていただけると幸いです。

yohei

私はシステムアナリストの試験に合格はしましたが、
普段の業務でシステム化計画の立案などの
最上流工程にあたる仕事はしていません。
割合でいうと7ppbくらいだと思います。

プロマネやアプリケーションエンジニアの試験では
普段の業務で学んだ知識を役立てることができましたが、
ANの試験ではそのように行きませんでした。

それでは何が役に立ったかと言うと、私は大学で
マーケティングを専攻していたため、その時に学んだことが
もっとも役に立ったと言えます。

午後1試験では、長い問題文から企業の課題と目標を探し出します。
問題文を読んでいくと、課題はたくさん見つかります。
全体を通して「この企業はこの方向性に進むべきだ」という目標を
見つけることができると、課題の中でも解決すべきものがはっきりします。
システムを導入すれば効率化が図られると思われる部分について、
その部分の効率化は他の部分よりも優先度が高いのか?
という視点から問題を眺めると良いでしょう。

午後2試験では、自分がシステム化戦略や計画の立案を行った経験を
論文にして述べます。必ずしも経験していることを書く必要はありません。
もし経験が厳密に判定されるのであれば、職務経歴書の提出などが
求められても良いはずです。それがないということは、
「自分ならこうする(こうした)」という論文を書いて出せば良いのだと思います。

さて、システムアナリストがシステム化計画の立案を行うとして、
何が重要になってくるでしょうか。

私は一番に現状の調査・分析を行うことが重要だと思います。
競合他社の様子、代替市場の様子、新規参入企業の様子、
お客様の様子、部品供給元も様子、政治、経済、環境など
様々な視点から自社の置かれる環境を分析します。

また、過去数年に渡ってどのような変化があり、
この先どのように変化していくかを眺望します。
そしてその企業がどのような未来を描くべきかを判断します。

もし経営戦略が確たるものであり、それに沿ったシステム化だけを
計画するのであれば、調査・分析の作業量は減少します。
しかしEAという言葉のあるとおり、システム抜きで企業の未来を
描くことができないという企業・業界も少なくありません。
そういった場合は経営戦略の立案フェーズからANが参画します。

そして将来像が見えてきたら、それを実現するためのシステム像を考えます。
昨今ではフルスクラッチの開発が減り、優秀なパッケージソフトウェアが
数多く登場しています。また、SaaSのようにサービスだけを受けるという
形態もあります。企業の描く将来像に即したシステム化を考える必要があります。

こうしてどのようなシステムを作っていくかが決まっていきますが、
そのうちに予算と期間も決定されていきます。
最初から予算と期間をガチガチに固めると、その枠内で何とかしようという
思いから発想の自由度が低くなります。予算内の計画はもちろん作成しますが、
別に予算越えの案も作成してみて意思決定者の決済を仰ぐ形も良いと思います。

このようにして作成したシステム化計画は、経営者の意思決定により
実現するか否かが決められます。修正が入ることもあるでしょうし、
やーめた、となることもあるでしょう。
ここで重要なのは、ANはそのシステム化計画が有効であることを説明する責任を負うということです。

たとえば10億円かかるシステムがあるとします。
一般的な減価償却期間として5年を想定すると、
1年あたり2億円です。一般に、社員を養うのに給料の3倍かかると言いますので、
一人の社員を養うのに2000万円かかるとすると、10人を5年間養うことができる金額です。
基幹系システムを構築するとして、現行システムがボトルネックになって
仕事がはかどらないような現状があれば、10億でもそれ以上でも払って
ボトルネックを取り除くという計画もあり得ます。

一方で、社内の間接業務を削減するという場合、削減される業務の量が
コストに見合ったものであるかどうかが重要になります。
ひょっとしたら人間を新しく10人雇って人力で対処したほうが良いかもしれません。
確かに人間を採用すれば退職金の引き当てや社会保険など
様々な経費が発生します。一方でシステムは稼働させ続けても
勝手に成長することがありません。システム部門の人間が
スキルアップすることはありますが、勝手に処理性能が上がることはありません。
しかし人間は成長します。人間の事務処理性能は上昇します。
このようにして考えると、何でもシステム化すればよいとは言い切れません。
システム化の費用を人件費に回したとしても、
断然システム化したほうがコスト的にお得だとか、
コスト的には負けるが財務的にメリットがあるということを
経営者向けにアピールする必要があります。

その結果として、経営者側はシステム化する気でノリノリでも、
ANとして「システム化は不要」という決断を下す場面もあるでしょう。
これはプロマネやアプリケーションエンジニアでは考えられない場面です。
「このプロジェクト、最後まで持ちません」ですとか、
「このモジュール、動きません」ということはあり得ません。
プロジェクトは完遂、モジュールは完成以外に目標が無いからです。
一方、システム化についてはシステムを作ることが目的でなく、
企業があるべき姿に近づくことが目標です。
ですのでシステム化が適当でないという場合は
「やっぱ作るのやめましょう」と言って周囲を沈静化しなくてはなりません。
それもANの仕事のひとつです。

実際にANの試験で「システム化が不適当だと思われたのでやりませんでした」
などと書いたらまず不合格になると思われます。
しかし論文の中で、「システム化しないということも視野に入れ、
システム化した場合と比較したところ○○という点で有利だった」
ということを書くと深みが出ます。世の中、システム化の松竹梅の案だけではありません。

システム化をやらないほうが儲かる、
フルスクラッチ+商用アプリケーション勢ぞろいで作ろう、
LAMP構成にオープンソースのフレームワークで作ろう、
ERPにできるだけ手を加えずに作ろう、
SaaSでやろう、
自社のシステム部門でEUCしよう、
などの様々な選択肢がある中、なぜその計画が正当であるか、
それを経営者相手にプレゼンする気持ちで挑むのがANの論文だと思います。

私のゼミでは教官を相手にして10分ほど「自分がこの会社ならこの時こうした」
というスタイルで発表がありました。誰が指名されるのかわからないため、
課題が変わるたびに準備して挑む必要がありました。
10分の発表のあとには他のゼミ生や教官から20分ほどに渡り
ツッコミが入ります。ブランディングについて熱く語っても、
「資金調達はどうする?」という突っ込みや「既存の○○というブランドの
ラインナップとどのように棲み分けるのか?」などという質問が来ることがありました。
これに慣れると、自分で事前に質問を想定しながら批判的に作戦を練るようになります。
結果として、完成する発表内容も良くなりますし、突っ込みにも動揺しなくなります。

ANの論文で回答するときは、読む側が心の中で突っ込みを入れそうなところについては
フォローしながら論述すると良いと思います。
「この計画の課題は○○であったが、経営者の判断を仰いだところ
システム化のメリットのほうが大きいとの結論に達した」などです。
論文の最後には総括をするところがありますので、
「当初課題とされた○○については、計画中で対策を固めることができたため
表面化することなくシステム開発を終えることができた」というような感じでしょうか。

以上、システムアナリストとして働いたことのないシステムアナリストからの
助言ですので、ものすごい斜め上な感じのところもあるかと思いますが、
ご参考にしていただけると幸いです。

(関連エントリ)

yohei

« 2007年8月24日

2007年8月25日の投稿

2007年8月28日 »

» このブログのTOP

» オルタナティブ・ブログTOP



プロフィール

山口 陽平

山口 陽平

国内SIerに勤務。現在の担当業務は資金決済法対応を中心とした資金移動業者や前払式支払手段発行者向けの態勢整備コンサルティング。松坂世代。

詳しいプロフィール

Special

- PR -
カレンダー
2013年5月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
yohei
Special オルタナトーク

仕事が嫌になった時、どう立ち直ったのですか?

カテゴリー
エンタープライズ・ピックアップ

news094.gif 顧客に“ワォ!”という体験を提供――ザッポスに学ぶ企業文化の確立
単に商品を届けるだけでなく、サービスを通じて“ワォ!”という驚きの体験を届けることを目指している。ザッポスのWebサイトには、顧客からの感謝と賞賛があふれており、きわめて高い顧客満足を実現している。(12/17)

news094.gif ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
上司や先輩の背中を見て、仕事を学べ――。このように言う人がいるが、実際どのようにして学べばいいのだろうか。よく分からない人に、3つの事例を紹介しよう。(12/11)

news094.gif 悩んだときの、自己啓発書の触れ方
「自己啓発書は説教臭いから嫌い」という人もいるだろう。でも読めば元気になる本もあるので、一方的に否定するのはもったいない。今回は、悩んだときの自己啓発書の読み方を紹介しよう。(12/5)

news094.gif 考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
自社製品と競合製品を比べた場合、自社製品が選ばれるのは価格や機能が主ではない。いかに顧客の価値を向上させることができるかが重要なポイントになる。(11/21)

news094.gif なんて素敵にフェイスブック
夏から秋にかけて行った「誠 ビジネスショートショート大賞」。吉岡編集長賞を受賞した作品が、山口陽平(応募時ペンネーム:修治)さんの「なんて素敵にフェイスブック」です。平安時代、塀に文章を書くことで交流していた貴族。「塀(へい)に嘯(うそぶ)く」ところから、それを「フェイスブック」と呼んだとか。(11/16)

news094.gif 部下を叱る2つのポイント
叱るのは難しい。上司だって人間だ、言いづらいことを言うのには勇気がいるもの。役割だと割り切り、叱ってはみたものの、部下がむっとしたら自分も嫌な気分になる。そんな時に気をつけたいポイントが2つある。(11/14)

news094.gif 第6回 幸せの創造こそ、ビジネスの使命
会社は何のために存在するのでしょうか。私の考えはシンプルです。人間のすべての営みは、幸せになるためのものです――。2012年11月発売予定の斉藤徹氏の新著「BE ソーシャル!」から、「はじめに」および、第1章「そして世界は透明になった」を6回に分けてお送りする。(11/8)

オルタナティブ・ブログは、専門スタッフにより、企画・構成されています。入力頂いた内容は、アイティメディアの他、オルタナティブ・ブログ、及び本記事執筆会社に提供されます。


サイトマップ | 利用規約 | プライバシーポリシー | 広告案内 | お問い合わせ