| « 2007年8月24日 | 2007年8月25日の投稿 |
2007年8月28日 » |
まだまだ暑い日が続きますので恐い話を集めました。
ITの見えてはいけない明日が見えるかもしれません。
(すべてフィクションと思われる噂話です)
1.発生しないはずの例外が……
|
私はあるプロジェクトでプログラマをしていました。 |
これは恐いですね。メッセージに出してしまうのは問題外ですが、
ソースのコメント部分には自由な意見が書き込まれることもありますね。
見られると困るようなコメントを書いたことがある人は多いのではないでしょうか?
2.スーパーハッカーの攻撃が……
|
私は友人と2人でチャットをしていました。 |
これは有名なアメリカンジョークですね。
全然恐くありませんが、怪談調に改変してみました。
3.まじめに仕事をしたはずが……
|
私は侵入テストのテスターをしていました。 |
侵入テストを行うときに侵入先を間違えるととんでもないことになります。
ここではco.jpと間違えてgo.jpを指定してますね。一歩間違うとテロ認定の恐れも……。
同じような事例で、サーバ室でサーバを取り違えるという噂も聞きました。
サーバ室は入退室管理がばっちりであるため、それぞれのサーバラックには鍵をかけておらず、
また、端末もログインしっぱなしだったために事故が起きてしまったとか。
4.押したはずのないキーが……
|
[root@xxxxx]# |
この間違いはあまりにもダメージ(精神的ダメージ含む)が大きいです。
そのせいか、はてなにこんなページがありました。くれぐれもご注意ください。
もし経常的にあるディレクトリをrm -rf #### するようなコマンドを使う必要があるなら
シェルを作っておくと良いと思います。
5.真夏の赤いセーター
|
新人のオペレータがサーバルーム勤務になった。 |
静電気は電子機器の大敵です。
サーバルームでは湿度が下がりすぎると静電気による事故のリスクが高まるため、
加湿器を設置して湿度をコントロールするところもあります。
ちなみにJISのT8103には静電気を防止する服と靴の規格が定められています。
わざわざT8103の合格品を制服に採用して運用しているセンターに
アクリルのセーターなど着ていったら裸にされた上で
冷風の送風口に縛り付けられるかもしれません。
6.恐怖のドキュメントフッター
|
ある日、お客様との打ち合わせに向けて資料を作成していた。 |
自分のPC内のフォルダ命名ルールは個人の自由ですが、
うっかり印刷してしまうととんでもないですね。
7.タバコ部屋の生霊……
|
その昔、プログラム仕様書は肉筆で作られていた。 |
今なら電子ファイル修正してプリンタのアイコンをクリックで終わりですが、
肉筆で作成したものを捨てられるダメージはいかほどか。
手書き仕様書が用いられる時代のコンピュータ処理と言えば、
CPU利用時間による課金が全盛だったと聞きます。
無駄が多いプログラムはお金も無駄にしてしまうため、厳しく断罪されたのでしょう。
そういえば、CPU課金のシステムで無限ループを起こしたら、というのも恐い話ですね。
8.破壊される磁気記憶
|
私の会社では記憶媒体のすべてにQRコードを貼りつけて管理しています。 |
そういえば5インチのフロッピーってセットしてからロックレバーを操作してましたね。
フロッピーが磁気で壊れてしまうということすら忘れていました。
9.山小屋で遭難……
|
あるSEが4人で登山中に遭難しました。 |
ちょっと笑えないですね。確かに長い打ち合わせってあります。
ちなみに元ネタは4人で山小屋に泊まり、
4隅を使って眠らないようにゲームをするという有名な話です。
しかし恐い話を聞くとなんで涼しく感じるんでしょうか。
rm -rf / というコマンドを間違って打ってしまうという恐い話がありましたが、
実際に間違いそうになるだけで背筋がヒヤリとします。
もし、これぞという恐い話をお持ちの方がおられましたら
コメント欄で教えていただけると幸いです。
私はシステムアナリストの試験に合格はしましたが、
普段の業務でシステム化計画の立案などの
最上流工程にあたる仕事はしていません。
割合でいうと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の論文で回答するときは、読む側が心の中で突っ込みを入れそうなところについては
フォローしながら論述すると良いと思います。
「この計画の課題は○○であったが、経営者の判断を仰いだところ
システム化のメリットのほうが大きいとの結論に達した」などです。
論文の最後には総括をするところがありますので、
「当初課題とされた○○については、計画中で対策を固めることができたため
表面化することなくシステム開発を終えることができた」というような感じでしょうか。
以上、システムアナリストとして働いたことのないシステムアナリストからの
助言ですので、ものすごい斜め上な感じのところもあるかと思いますが、
ご参考にしていただけると幸いです。
(関連エントリ)
| « 2007年8月24日 | 2007年8月25日の投稿 |
2007年8月28日 » |

顧客に“ワォ!”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命