アーカイブ 7月, 2008

製造・生産(production)と開発(development)

システム開発現場の活気を取戻そう(中)ウォーターフォールからの脱却 ビジネス-次世代IT産業論考(浜口友一):IT-PLUS
http://it.nikkei.co.jp/business/column/hamaguchi_it.aspx?n=MMIT2z000025072008

そしてよく考えてみると、ソフトウエアは製造工場で同じ形の製品を繰り返し大量生産するようなものとは違い、製品設計それ自体が生産物であり、2つと同じものを作ることはない。果たして、このような工場型の方式が向いているのかどうかという疑問もわいてくる。

だって、「生産」と「開発」は違うもん。

よく引き合いに出される自動車で言えば、工場でやっている「生産」というのは「同じものをたくさん製造する」ことでしょう。
「同じもの」つまり「製品」のコンセプトを決め、設計に落としていくことは、「開発」というのではないでしょうか?

そういう意味では、OSやパッケージベンダは自動車会社の「開発」に近い工程が回せているのかもしれません。コンセプトを決めるのは自分たちですからね。で「製造」はCD-ROMとライセンス文書のコピー。

SIというのは、顧客にコンセプトを決めてもらって「開発」に入るんだから、自動車産業のしかも「製造」をまねっこできないのは自明なんじゃないのか?
自動車の「開発」がどのように進められているのかは、参考になるかもしれませんが。

開発生産性が低い方が収入が多いって変だよね – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080723/1216790705

実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。

「開発の生産性」と言われると、ちょっと違和感を覚えてしまうのはこのせいだったか。

コメントを書く

はじめてのAmazon

「インターネットでお買い物」するのが初めてだった人(=私の母親)を観察してみた記録です。
まとめると「メタファーに混乱」といったところでしょうか。

なぜ、Amazonで買い物をするのか

私の母から電話があり、Amazonでの買い物を手伝うことになりました。

電話の内容は、以下のとおり。
・欲しい本があるのだが、近所の書店では見つからなかった
・取り寄せも長い時間がかかるらしい
・母の会社の同僚に訊ねたところ、「アマゾンというインターネットの本屋ならあるかも」と言われた
・でも、インターネットで買い物したことがないから手伝って

そのまま電話でのリモートコントロールで、買い物チャレンジです。

レベル

母のITに関するスペックは
・パソコン歴20年(会社では仕事でずっと使っている Mac → PC98 → Windows)
・メールソフトやネット接続の設定は自分ではできない
・パソコンからメールを送ることもなく、Webブラウジングもほとんどしない(1ヶ月に1回程度)

仕事などで書類作ったり、社内のシステムを使うのには苦労がないけど、インターネットのことになるとさっぱり…ということです。

あと、やりとりの途中で通販もめったに利用していないことに気がつきました。

いざ、買い物…

電話する前にYahoo!を経由して、Amazonのトップページにはたどりついていたらしい。
だけど、ここからどうやって目的の本にたどりつけばよいのか検討つかず、途方に暮れて電話してきたとのこと。

Amazon
http://www.amazon.co.jp/

本屋だって聞いていたのに、このトップページでは何をしていいのか、わからないだろうなぁ。
広告がドーン、本の情報なんかほとんど載っていない。

[説明したこと]
目的の本の場所にたどりつくことが必要で、そのためには「検索」をすればよい。

[手順]
1) テキストボックスに本のタイトルを入力し、「Go」をクリック
2) 検索結果の中に目的の本があるか確認し、その文字をクリック
→ 目的の本のページにたどりつく

しかし、手順2)でとまどう。
「マウスを近づけたら、下線が引かれる本のタイトルをクリックすればいい」という、(私としては)暗黙の事項が通用していないことに気がついた。

Yahoo!から検索してAmazonまでこれたということは、最初から下線が引いてあればリンクとして認識できるということだろうか?
もっとサンプルが欲しいなあ。

買い物カゴに入れる

目的の本のページにたどりつきました。

[説明したこと]
本を「ショッピングカート」に入れて、「レジ」で支払いをします。

[手順]
1) 画面右側「ショッピングカートに入れる」をクリック
2) 画面右側「レジに進む」をクリック

手順1)で「『こちらからも買えますよ』ってあるけど、何?」と訊かれました。
私「古本でいいならそっちで買ってもいいよ」
母「新品がいいから、ショッピングカートに入れればいいのね?」

レジに進む際の関連商品の表示は、慣れてくると便利なのですが、初めての人には混乱のもとのようです。
私「ポテトにドリンクはいかがでしょうか? と言われるようなもんだ」
と説明を試みましたが、納得してくれただろうか。

ユーザ登録→支払い

レジに到達して、メールアドレスと配送先の登録です。

[説明したこと]
本を届けるのに住所・氏名が必要。通販と同じ。
注文受付などの連絡にはメールを使う。

[手順]
1) 「初めて利用する」に黒丸がついていることを確認する
2) 「メールアドレス」を入力して、「サインイン」をクリック
→ 画面が変わる
3) 氏名・住所などを入力する ※ 半角・全角に注意すること
4) 「この住所は、お客様の請求書送付先ですか?」「はい」に黒丸がついていることを確認して、「次へ進む」をクリック
→ 画面が変わる
5) 「通常配送」に黒丸がついていることを確認してクリック
→ 画面が変わる
6) 支払い方法を選ぶ。クレジットならば必要事項を入力する ※ 半角・全角に注意すること
7) 「次へ進む」をクリック
→ 画面が変わる
8) 内容を確認して、「注文確定」する。メールが届くはず。

画面の上の方に、下のようなプログレスバーがついているんだけど、当然見ていなかったです。
教えると、この順番でいろいろと選択や記入をしていけばよいのだとわかってくれた様子ではありました。

こちらでのはまりポイントは、4ヶ所。

その1、「サインイン」というのが理解されなかった。
現実世界の買い物で「サインイン」はしないですね。
説明はとりあえずあきらめました。

その2、「次へ進む」のに非常に慎重。
「前に戻る」ボタンがないんですよね…
「ほんとにこれでいいの?」と何度言われたことか。
画面のなかで何をすればいいのか、初めての人にはわかりにくい。

その3、1画面につめこみすぎ。
支払い方法を選ぶページが特にひどい印象です。
1. 支払い方法の選択
2. ギフトがどうとか選択
3. 繰り返し利用時のアカウント登録
以上、3つを同じ画面でつめこんでます。
混乱を避けるため、2.と3.は無視して先に進みました。

その4、手続の順番です。
現実世界の買い物では、
・支払い→配送手続
の順番になりますが、Amazonではこれが逆です。
通販だと注文票に注文した商品と配送先も書きますが、「ショッピングカート」とか「レジ」とかの比喩をしているから、かえってリアル店舗をイメージして混乱を招くのではないでしょうか。

文字入力時の半角・全角ではまらずにすんだのは、パソコン歴約20年が活きた結果だと思います。

電話をとってから注文確定まで約30分。しんどかったです。


電話から3日後、本は無事届いたようです。
連絡を受け、こちらもほっとしました。
母は余程ほしい本がない限り、Amazonを利用することはないように思います。
(どうせ利用するときには、電話が鳴るんだろうな)

じゃあ、自分だったらどういう画面や遷移の設計にするだろう?
1週間くらい、考えてみます。


試しに、Amazonおまかせリンクをはりつけてみました。
<!–
amazon_ad_tag = “atauky1978-22″; amazon_ad_width = “300″; amazon_ad_height = “250″; amazon_ad_link_target = “new”; amazon_ad_price = “retail”; amazon_ad_discount = “remove”;//–>

コメントを書く

狩衣と中世の温暖期

夏の京都

先週、2泊3日で京都へ旅行に行ってきました。
3日ともおしめりなく、猛暑日ばかりでした。暑さに殺される感覚です。
クーラーもない時代、夏は鴨川周辺に亡骸がごろごろしてたんじゃないかと、ろくでもない想像をしてしまいます。

京都の暑さの中にいると、寝殿造りが高床式である意味がよくわかります。
夏をいかに涼しく過ごすかが問題なんですね。冬は十二単とか厚着しておけばいいし。
知識としてはありましたが、体験してみると非常に合理的であると実感します。

2日目には、「風俗博物館」を訪ねました。

風俗博物館~よみがえる源氏物語の世界~
http://www.iz2.or.jp/

平安時代の衣装を着られる体験展示があり、男性は狩衣を着ることができました。
実際着てみると、想像していたより動きやすく、風が良く通り涼しいです。
下半身も風通しがよいので、ジーパンをはくより、ずっと涼しい。

狩衣はもともと普段着でしたが、平安末期、院の出入りは直衣でなく、狩衣でもOKになったようです。
平安時代のクールビズといったところでしょうか。


狩衣 – Wikipedia
http://ja.wikipedia.org/wiki/%E7%8B%A9%E8%A1%A3


中世の温暖期

平安末期の京都は、「中世の温暖期」と時期が重なるので、自然と狩衣を公の場で着る習慣もできたのかもしれませんね。

「中世の温暖期」の存在については、有無それぞれの説があるようですが、当時の気温の記録が存在しないのがつらいところです。状況証拠しかありませんから。現在でも、地表付近の気温が網羅的にわかっているわけでもないようですし、過去の平均気温推移だって、19世紀以前はほぼ推測でしょう。


中世の温暖期 – Wikipedia
http://ja.wikipedia.org/wiki/%E4%B8%AD%E4%B8%96%E3%81%AE%E6%B8%A9%E6%9A%96%E6%9C%9F

7/29 2:00現在では、記述が「中世の温暖期はなかった」ほうに依っているようです。
でも、

屋久杉を使って1100年前の太陽活動の復元に成功 – プレスリリース – 東京大学 大学院理学系研究科・理学部
http://www.s.u-tokyo.ac.jp/press/press-2008-14.html

なんて研究もあるみたいです。

中世の温暖期 – Wikipedia
http://ja.wikipedia.org/wiki/%E4%B8%AD%E4%B8%96%E3%81%AE%E6%B8%A9%E6%9A%96%E6%9C%9F

また、現在明らかになっている証拠からは、これらの時期に世界的に寒冷もしくは温暖であったという同時性が認められない。よって、”小氷期”、”中世の温暖期”という言葉は過去の世紀で起きた、半球規模もしくは地球規模の平均的な気温変化の傾向を示す場合に限定されるべきではないかと述べられている。

とは必ずしも言えないのではないかなぁ。
ただし、

屋久杉を使って1100年前の太陽活動の復元に成功 – プレスリリース – 東京大学 大学院理学系研究科・理学部
http://www.s.u-tokyo.ac.jp/press/press-2008-14.html

現代における太陽活動度はある程度活発なレベルに分類されるが約1100年前の中世初期ほどではないこともわかりました。

だそうなので、現在の進んでいるという温暖化を太陽活動の活発化のせいばかりにはできなさそうです。

コメントを書く

音頭

盆踊りの季節だ。子どもといっしょに行ってきた。

近所の盆踊りでかかっていたのは…
・大東京音頭
・炭坑節
・アラレちゃん音頭
・ドラえもん音頭
といったところ。

昔は「21世紀音頭」とか踊っていたけど、もう21世紀になったから用済みなのだろう。
大阪万博の1970年に発売されている曲で、歌詞はこんな。結構テンポの早い曲です。

これから31年経~てば この世は二十一世紀
その時二人はどうしているの やっぱり愛しているかしら

※シャーララ シャーララ シャーララララララ シャーラララララララー
 二十一世紀の夜明けはちーかーいー

これから31年経ぁ~って この世はどうなっているの
火星に金星 遠くの星に 旅行に出かけているかしら
(※繰り返し)

これから31年経~てば 宇宙も変わっているでしょう
誰でもみんなが幸せになり 平和に暮らしているかしら
(※繰り返し)

あれからー、僕たちはぁー…という気分にさせられる歌詞です。

しかしながら、なんで「アラレちゃん音頭」と「ドラえもん音頭」なのだろうか。
20年前となんら変わらない。

「ポケモン音頭」(あるらしい)や「プリキュア音頭」(ないらしい)ではだめなのだろうか。
「おジャ魔女どれみ音頭」(あるらしい)、「ケロロ音頭」(あるらしい)でもよさそうな気がするのだが。
「アンパンマン音頭」(ある)もあるのになぁ。

いまだにLPレコードで曲をかけているっぽいのがポイントなんだろうなぁ。
CDプレーヤーくらい買おうよ…

コメントを書く

フィレンツェ式 VS ヴェネツィア式

フローチャート関連の議論のあと、システムエンジニアってなんだろうと考えていて、ふと思い出した塩野七生氏の文。
分業についてです。

ルネッサンスが花開いたフィレンツェはこんな感じ。

『ルネサンスとは何であったのか』(文庫版 P.87)

また、当時の工房が、美を追求することならば何でも引き受けるというシステムであったのも、フィレンツェ人の気質に合っていたのだと思う。絵画や彫刻にかぎらず、祭りに使われる旗から御婦人方の衣装や宝飾品、机上の置物から大建造物と、図面を引いたりデザインを考えたり金銀や銅を溶解したりと、あらゆる種類の仕事が工房では行なわれていたのです。その仕事の進め方も、専門ごとに分れていたのではない。見習い期間中はとくに、必要となればどこにも手助けに行かされる。絵具の調合をしていたと思ったら、金属を溶く火の前でふいごを手にしているという具合です。
(中略)
そして、何でもやれねばならなかった工房という学校で学んだ後に独立し、それ以後は得意な分野で才能の花を咲かせるのが、フィレンツェの芸術家の生涯のコースだった。

一方、ヴェネツィアは
『ルネサンスとは何であったのか』(文庫版 P.88)

画家は絵だけに、建築家は建築だけに専念していたヴェネツィア人とは大きな違いですね
(中略)
ヴェネツィアでは、効率性を重視したから専門化したのではなく、ヴェネツィア派の絵画の台頭が、フィレンツェ派の成功の後を追って成されたという事情によると思います。専門化とは、相当な成果があがった後ではじめて効果を発揮できるシステムだから。

今まさに、システム開発にとっての「専門」の定義が変わるときなんでしょう。
「ホスト」でのシステム開発で大きな成果をあげてしまった反動なのかもしれません。
分業体制とか、作りかたとか、ホストの名残りであることが多いですからね。

ホストでの開発も最初はフィレンツェ式で、みんななんでもやっていたんじゃないかなぁ。

もう一度、フィレンツェのような渾然一体に戻ってみる時期なのかもしれません。そうすればソースコードを書けないような人は淘汰されていくんでしょう。

私自身は思考も指向も、「フィレンツェ式渾然一体型」なんだと思います。
だいたい、専門職と言われるのが好きではありません。なんだよ基盤の専門職って。
製品買って組みあわせるのが基盤か?
システム作るのにやれることはなんでもやるんじゃないの?
データ設計とか担当外だからって口出しちゃだめなの?

やばい、愚痴になってきた。

コメントを書く

メンテナンスをするのに必要な文書ってなんだろう

SIerにおいて、システムをメンテナンスしていくのに必要なドキュメントとはなんだろう。

プログラミングファースト開発の必要性 – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080721/1216607451

仕様が固まった後に作成するドキュメントは、プログラムと一対一になるようなドキュメントではない。そんなのはプログラムを見ればすむ話だから。メンテナンスする人が必要になるドキュメントを書く。メンテナンスする人にとってはドキュメントは必要ですよ。全部ソース読めはきつい。

まず、対内部 & 対顧客として
このシステムはなにをするためのものか
がわからないと引き継ぎ困難です。
『概要設計』と呼ばれるレベルのものでしょうか。
・機能リストのようなもの
・(他システムとの接続があれば)接続関係図

があるとメンテナンスが容易になります。
(どのシステムに影響があるかわからないと、事前の影響確認とかしてもらえない)

そう考えると、対外的には
・外部システムとの接続仕様(I/F仕様)
は残しておく必要があるかな。外部システムの担当が他社であれば、接続仕様がないと話にならないかもしれません。
Web画面で済むならこれも不要かも。

あと自社内担当分であれば
・内部の機能配置
・プロセス間通信(機能の間でのデータのやりとり)が発生するならその経路
・機能とソースの関連性
を図示しておけば、いじったときの影響を判断することが可能。
テスト年中まわしていれば気付くだろうしね。

障害発生時の動きを示した文書は、エラーメッセージがしっかりしていれば不要。
ただ、H/W障害発生時や停止したときの復旧方法など示した文書、再構築手順は必要か。

コード仕様書などは、「1=会社員」とか「2=公務員」などという内容にしなければ不要そうだ。
(ダイレクトに「会社員」「公務員」とかエントリーしちゃだめなの? こちらのほうが直感的ではあるんだけど)
現状、ホストのデータの持ちかたをひきずったシステムをどうすればいいのか…
外部から飛んでくるデータもこんなんだしなぁ。

コメントを書く

フローチャートではかれるのは「段取り」の力だけ

フローチャートの議論で、フローチャートなんて、研修や新人を教育するときにしか見たことないです。

参考URL

フローチャートとFizzBuzz問題 – novtan別館
http://d.hatena.ne.jp/NOV1975/20080719/p2

言語なんて何でも一緒(でない場合もある) – ぼくが真実を口にするとほとんど全世界を凍らせる
http://d.hatena.ne.jp/goodbye_bluemonday/20080720/p1

フローチャートの呪い – カレーなる辛口Javaな転職日記
http://d.hatena.ne.jp/JavaBlack/20080719/p1

システムエンジニア不要説 – masayangの日記(ピスト通勤他
http://d.hatena.ne.jp/masayang/20080719/1216511611


COBOLで処理するバッチ系の処理であれば多少、役にたつかな…と思いますが。
フローチャートでわかるのは、ちゃんと段取りを踏んでいるかどうかだけです。

・ファイルオープンする前にマッチング処理開始、データどこから読むんだよ…とか
・おいおいそれじゃ、マッチング元のレコード上書きされているじゃないか
などという事態を未然に防ぐことができます。

もちろんできる人は、こんなばかばかしいことしないと思いますが、経験のない新人なんてこんなレベルなんです。

たとえば、会議の調整をするのに、参加者のスケジュールの空き状況確認しないで
「会議室○○番が空いていたので、×月×日13:00からでお願いします」
などと、いきなり言ってきたら、アホかと。私はその日出張で終日オフィスにおりませぬ。

少なくとも、

1) 必須の出席者を確認
2) 出席者の共通の空き時間を確認
3) 出席者のスケジュールを抑える
4) 会議室の空き状況確認
5) 会議室を抑える
6) メールなどで開催を連絡

ってな段取りを踏むでしょう。
でも、こういう段取りを踏むことができない人もいるんです。
ファイルを開かずにデータを読もうとしたりするんです。

システムエンジニア不要説 – masayangの日記(ピスト通勤他
http://d.hatena.ne.jp/masayang/20080719/1216511611

もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。

ズボンとパンツを履いているのか?と確認するためのツールがフローチャートです。
でも、そういう確認をしなくてはならないレベルの人がいるのも事実です。

※ 「こんなん採用してくるんじゃねー!」という話は置いといて…

こういうところから積みあげていかないと、「コードを書けないシステムエンジニア」を量産するばかりになってしまうことにはならないでしょうか?


10分で作るRailsアプリ アプリケーション編 – masuidrive
http://masuidrive.jp/rails/rails_app.html

しかしながら、フローなんかよりデータレイアウト(DBでのデータの持ちかたとか)を考えないといけないとかな…と考えたりします。

・全レコードをunloadするのが一日の始まりです
・1レコード、何カラムあるんですか?
・E-R図なんてものはないよな…正規化なんて言葉も知らないんだろうな
・なんとか区分やめてください。if分岐が、テスト工数が…
・テーブルレイアウト変わるから移行が大変面倒です。

これはフローの問題ではないよなぁ?

コメントを書く

意識していれば泥になりづらい業界

下記2エントリを見て、腑に落ちました。
十年一日のやりかたでいるところに一石を投じることができれば、泥にならずに済むかもしれませんね。自発的な苦労がついてきますが。

泥カンと未来サミットとIT業界の現実 – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080717/1216274298

10年泥が嫌ならITお勧めだよ – 雑種路線でいこう
http://d.hatena.ne.jp/mkusunok/20080717/it


2002年、新卒で入社したとき配属されたプロジェクトでの話です。
IT土方の頂点SIerの迷惑な新人として、社会デビューです。

プロジェクトの概要は以下のとおり。
(新人のときに見えたものなので、全体はまるで見えていないですが)


[全体]
・ホストで動いていた企業内の基幹(企業内会計)システム(旧)を、オープン系(新)に移行して、維持管理削減を目指す
・情報系のシステムを刷新(というかほぼ新規構築)
・移行期間中の基幹系システムの出力は新旧比較

[新・基幹系(筆者所属チーム)]
・新側のシステム開発
・開発言語はCOBOL
・新の本番サーバはUNIXだが、個々のプログラムの開発環境はWindowsのPC上で構築(Unix, WindowsそれぞれをサポートしているCOBOLコンパイラ製品を使用する)

[基幹系移行チーム(プロジェクト途中から筆者所属チーム)]
・旧→新への移行のためのプログラム/フロー/時間割作成
・移行データの洗い替え/検証


私が担当になったのは、移行データの洗い替え/検証の作業でした。

それまでは、指示にしたがって、Unix開発機のセットアップや本番で動く担当プログラムの開発に従事していたのですが、生産性は協力会社のばりばりCOBOLerには劣るし、ただの一作業者っていう感じで一生懸命、詳細設計して、コーディングして、単体テストしてました。

10年泥が嫌ならITお勧めだよ – 雑種路線でいこう
http://d.hatena.ne.jp/mkusunok/20080717/it

結局10年以上の経験を持つ先輩がいる職場って10年泥なんだよ。経験を積んだ先輩と生産性を比較され、出来が悪いんだから下積みやって追いつけ、となる。

移行データ関連の作業は最初、Unixの本番機とホストでやっていたのですが、プロジェクトでの環境の割り当て優先順位がどうにも低く、検証作業が予定通り進みません。
たくさんの端末で動かして、移行データ関連作業もはやくすませるのに、単体プログラム開発のとき使っていたWindowsのPCを使ってできないか? と上司に相談を受けました。

「UnixのシェルをWindowsのバッチで動かすようにすればいいんですよね? シェルが不足しているところも、現行システムJCLを見て、プログラム含めて同じようなものを作ればいいんですよね?」
「それができる人がいないんだ。やってみる?」
「とりあえずやってみます」

当時の私は、MS-DOS時代から*.batは触ってきているので問題なし。大学の学生用計算機環境はUNIXでしたので、*.shも読み書きできました。JCLは業界入ってからこのプロジェクトで見たのがはじめてでしたが、「だいたい、シェルみたいなものなんですね」と理解して、それほど困ることはありませんでした。

Job Control Language – Wikipedia
http://ja.wikipedia.org/wiki/Job_Control_Language

ただ、「それができる人がいないんだ。」という上司の言葉が信じられずにいたので、周囲の人々の知識なりを探ってみました。

ホストをメンテしてきたお客様のシステム部門では、Unixをわかる人がいない。
Unixのシェルについて詳しいとされていたチームメンバーは、「Windowsの*.batがわからない」とか言う。仕事の契約とか責任分界点のせいで、やるわけにはいかないのかと思っていたのだが、どうやら本当にUnixのシェルのことしかわからないらしい。
で、JCLが読めて、Unixのシェルがそこそこ読み書きできて、Windowsの*.batについてわかる人が私しかいなかった。

つまり、チームのなかではいちばん業界キャリアの浅い私が、オープン系のシステムの知識をいちばん(浅く広くの観点では)持っていて、作業の効率化に貢献できた…ということです。
サンプルテストデータ作るのに、Perlや秀丸マクロ使って生成しているだけで驚かれたことに、驚いていました。
(2002年当時は、SIerの現場ではそれほど浸透してになかったんでしょうか?)

この仕事をこなしてから、プロジェクトでの居心地が格段によくなりました。
本当に小さな小さな世界ですが「JCLとUnixシェルとWindowsバッチがわかる専門家」扱いです。んで、「専門家」とされている部分で、質問されたとき答えられないといけないから、より必死に勉強する、と。
また、仕事の量は減ったものの、今までは仮眠時間に割り当てられていた会議で、無責任に発言ができないので、精神的にしんどくなりました。

泥カンと未来サミットとIT業界の現実 – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080717/1216274298

「新しいことに挑戦して道を切り開かなければいけない」

ってことですね。レベルはぜんぜん違いますけど。
これをやらないと、10年下の後輩にも、お客さまの期待にも負けちゃいます。

以上、自分の体験から、10年先輩のやりかたよりも新人のやりかたの方が生産性が高いなんてことがありうるこの業界、開発フェーズについては、泥になりづらいのではないでしょうか。

※ SIerの対顧客窓口(営業とかプロマネも含め)については、どちらかというと「泥」でいくしかない世界だと思っています。もうすこし、考えてみたいとは思います。

コメントを書く

侵入された新生銀行

どこからつっこめばよいのか…

新生銀システム改竄のインド人を逮捕 「正社員になれないのは人種差別」と腹いせで – MSN産経ニュース
http://sankei.jp.msn.com/affairs/crime/080716/crm0807161151017-n1.htm

 採用を断られた腹いせに新生銀行の社員用ウェブサイトを改竄(かいざん)したなどとして、警視庁ハイテク犯罪対策総合センターと原宿署は不正アクセス禁止法違反などの疑いで、インド国籍で東京都江戸川区清新町、元派遣社員、アビナッシュ・シャルマ容疑者(32)を逮捕した。

 調べでは、シャルマ容疑者は今年2月18日から3月11日までの間、以前、新生銀に派遣社員として務めていたときに入手していたIDとパスワードを使い、67回にわたって新生銀の内部ネットワークに不正にアクセス。

 4回かけて約2600件のファイルを削除するなど社員用ウェブサイトを改竄した上、自分の犯行が発覚していないか確認するため、63回にわたって同社幹部のメールをのぞき見た疑い。

 シャルマ容疑者は平成16年に、インドにある新生銀子会社から派遣され、約3年間、新生銀でシステムエンジニアとして勤務。「自分のレベルを上げたい」と19年10月に退社して別の金融機関に転職したが、今年2月ごろ、人員削減のため辞職勧告を受けた。そこで、再就職仲介会社を通じて新生銀に正社員採用を申し込んだが断られた。

 「日本人じゃないから採用されず、人種差別を受けた」と思いこんで犯行に及んだという。

 シャルマ容疑者の犯行により、新生銀の内部システムは約15時間停止。社員用ソフトが使えなくなるなどの被害が出た。顧客の情報流出や金銭的被害はないという。

まず、
・退職した社員がどうやって内部ネットワークに侵入したのか
かなぁ。

勘定系などお金のデータがあるネットワークは、それなりに分離されているはずで、パスワード変更の運用もしているはずです。さもなきゃ金融庁との勝負でボロ負けしてしまう。

以下、想像で語ります。

今回は情報系と呼ばれる、勘定系(基幹系)のデータを集計・加工して社員が使えるようにするシステムが被害に遭っているのでしょう。
このへんのシステムだと、VPN経由でシステム担当者がメンテできるようになっていても、それほど違和感はないように思います。

足がついたのも、外部と内部を接続するVPNの受けサーバの履歴だったりするんじゃないかなぁ。
で、あわててアカウント消したりなんかして。

相対的に重要度が低いと思われている情報系のシステムは、パスワード管理なんかもけっこういい加減だったりするのかもしれませんね。人の出入りが激しいと、共用のユーザIDとちっとも変更されないパスワードで運用されていることも充分ありえます。


・派遣社員は信用できない論

今回は外からの侵入によりやられていますが、内部で”正社員”の管理者が悪意をもって、「rm -rf /」的行為をすると同じことが発生します。結局、管理人を信用しないときのコストと信用したときのリスクをどう考えるかの問題です。
「派遣社員を信じるなんて」という人は、正社員が同じことをやったらなんて言うのだろう。
だとしたら、正社員も疑ってかかるべきなんじゃない?


・日本人じゃないから正社員になれない

システム担当者だと日本人も正社員として雇ってもらえるのかどうか。

コメントを書く

攻殻機動隊2.0を観てきた

今日の仕事は新宿で終わることになっていたので、またとない機会、映画館に寄って観てきました。

前バージョン(でいいのか)は劇場で観たわけではなく、ビデオで観ただけです。
私が原作に出あったのが1997年で、映画はとっくに(1995年)公開されていました。

お客さんは男女比率が7:3くらい。
想像していたより女性が多かったです。

前バージョンとの違いを感じた点を中心に書いてみます。

家のビデオと、映画館の音響設備の違いかもしれませんが、素子ってサイボーグなんだな…と感じる音が作られていたように思います。ずしっとした質感です。
特に素子がダイビングをした後の船上での音は、素子とバトーの重量を感じました。
そう、フローターが故障したら浮上できない…

人形使いの声が、家弓家正→榊原良子に変更になりました。
前バージョンでは、9課のシーン、素子との対話のシーン、それぞれで神のご託宣といった趣きの響きでした。空間でふわふわ浮いている感じ、天から降ってくる感じ。
今回の榊原さんの声は実体としてそこにある感じでした。ソリッドな感じ、今にも触れることができそうな距離感。

あとラストシーンのコドモトコの坂本真綾の声も撮り直しましたか?
13年の時の流れを最も感じました。

自分

プログラム収録、素子役の田中敦子インタビューより。

オリジナル版はもう13年前になりますが、当時は台本を読んでもさっぱり意味がわからなかったんです。「ネットは広大だわ」というセリフも全くイメージができなくて。現代社会ではあたりまえになった携帯電話のメールさえなかった時代ですから

人形使いのセリフがいちいち実感をもって迫ってくるのも、この映画が描く世界観が現実に表われているからかもしれません。
原作を読んだ1997年当時、インターネットに接続したこともなく、パソコン通信すらやったことはありませんでした。携帯電話ですらなく、DDIポケットのPHSを持っていた程度です。
それがいまや、パソコンは高速回線を通じてインターネットとつながり、自分より若い世代では携帯電話からネットに接続するのもすっかり一般的なことになりました。
そう「ネットは広大」という台詞が実感を持って聞けるようになってしまいました。

あと、ゴミ収集車を追跡するシーンで、ほぼ生身の自分を9課に入れた理由を問うたトグサに対する素子の回答で自分が所属する組織に思いをはせてしまったこと。「人と為りては童のことを捨てたり」でなぜだか涙がこぼれてしまったこと。
学生→社会人、10代→30代に属性が変わったこの11年の私自身の変化の表れでしょう。

コメントを書く

古い投稿 »