100人以上で3時間で14億
ATM不正引き出しの話ですが…
まず100人だとして一人頭1400万。リスク見合いなのかというのは大変気になります。1400万をコンビニATMで引き出すのはかなり大変で、大抵の場合一回あたりの引き出し上限額が決まっているので（セブンは忘れたけどイーネットだと20万。セブンは30万だった気もする）、何回にも分けてやらなければならず、本当はカード側で一日の上限金額が決まっているはずなんだけどそれはどうなんだろう海外カードだったりするんだろうし。200人としても700万、20回以上引き出すのは大変。当然ですが、1店舗のATMにそこまで入っている可能性はあんまり無いのでセブン-イレブン回らなければならない。3時間でこれを実現するのは正当な引き出しであっても困難な気がするのですよね。
相当綿密に計画されたのであろうとは思いますが…
コードが設計を可視化するというのは幻想だと思う。
オブジェクト指向の問題点 - ビスケットのあれこれ
オブジェクト指向がUMLとある意味セットだったのはそういうことなんだと思うんだよね。
だから、それは言語や言語の設計思想の問題というよりはツールの問題だと思う。
ビジュアルプログラミング言語にしたって、バックグラウンドに控えている実装に対してある程度の制約をつけた上でそれを隠蔽しているインタフェースに過ぎないんじゃないかな。
だから、UML的なものからコードの自動生成に繋がるようなツールの整備があったとして、それがオブジェクト指向言語の素晴らしさを示すわけではなくて、単にツールの実装を可能にするレベルで抽象化できていた結果でしか無いと思うし、逆にそういうのがないと色んな物が可視化されないということがプログラミング言語としての欠点の本質であるということも全然言えないよね。
「堅牢」と「壊れない」は違うからね
製造業で実際にPC-9801が稼働している現場の立場からすれば、単に設備投資の..
PC-9801持っていた身からするとそりゃまあ部品の精度とかそういう意味では当時としてもかなりのお値段がした国産マシンである以上こだわりはあると思うんだけど、そもそもの記事からして部品がもうすぐ枯渇することは明らかなのにそれに対する有効な手を打ててないって時点でそもそも「単に設備投資の余力が無いという問題ではない」という評価には賛同できない。設備の更新を無駄金と言い切っている時点でそのラインには将来性がないし、とはいえ、もっとも将来性のないラインを死ぬ（＝需要がなくなる or PC-9801の交換部品が尽きる）まで稼働させるという判断が経営上成り立つんであれば別に問題がない話ではある。だから、この話は一般論とは出来ない。
死ぬまで逃げ切るか、または、設備更新する、という選択肢がある場合にどちらを選ぶかはそれこそ経営の問題であるとは思うけど、生産が終了している装置に依存しているラインのリスクというのはきちんと評価すべきだろうし、設備投資の余力があってこの手のニュースが出てきたタイミングであれば何が何でもやるべきって向きもいて良いと思うわけで。
ソースにコメントを書くのはなぜか
優れた設計、優れたプログラムであればあるほど、コメントは不要である、というのが真理の一つだと思う。もっとも、「優れた」の中にも「複雑なハックを駆使してとにかく高速化」とかそのたぐいの物はあって、そういうものにコメントがないのはパズルや入試問題を解かされているような不毛があるので仕事という面であれば避けたいものではある。
であるならば、コメントを書くのはどういう場合なのか。
至極簡単な理由は、優れたプログラマーなどそんなにいない、というまた別の真理によるものだ。コードにコメントを書かないことを目指すべきであることと、実際にコメントが不要なコードが書けることはイコールではない。業務プログラマーの世界であれば尚更である。そこで目指されているのは完璧なクオリティーのコードを書くことではなく、QCDが計画の範囲内に収まることであるから…
ただ、不要なコメントもたくさんある。特に処理そのものの説明をコメントにしているのは流石にどうかと思う。書くべきなのはその処理の仕方を採択した理由であったり、処理そのものの話であってもコードや仕様書からさくっと読み取れない仕掛けの部分（これは大抵の場合設計がクソなんであるが、プログラムをする段に至って設計のクソさは怨嗟の対象であっても今更直せねーよという場合も多いわけで）。
あと、設計書のどの部分に相対するかのガイド的なコメントはプログラマー的には本来不要であるが、メンテフェーズにおいてクソみたいなスキルしかない要員がそれでも職責を果たそうと努力する際の指針としては大変重要なものになりうる。
つまり、一生自分（やその同程度の人員）でメンテナンスが可能なものについてはおおよそコメントが必要な事態は発生しない。ということは、そうではない仕事において、コメントを一切不要とする判断はメンテナンス性を損なっている仕事であると「見なされる場合がある」わけだ。もちろん、正しい保証が仕組みから担保できないコメントを100%信じる必要がある現場はクソだと思うが。
もう一つコメントが重要なのは、どういう理由かはさておき、妥協したことが可視化されている場合だ。この記事は以下の引用部分をヒントに書かれているが、これがいわゆる仕事ってやつだ（悲しい。
さて、いまを遡ること10年ほど前。
【プログラミング】退職した先輩が書き残していったコメントがひどすぎる・・・ - 私の戦闘力は５３万マイクロです
会社の先輩が一身上の都合で会社を退職していき、僕は先輩が担当していたシステムを引き継ぐことになりました。
で、そのシステムの改修をすることになったのでソースコードを見てみたら、システムの肝に近い部分にこんなコメントがあったんですよ。
// その場しのぎの処理。仕方がない。
ほんとこういうの書いておいてくれないと困る。書いてあった上で、見たことにするのか見なかったことにするのかを判断したいものだ。
SIerの未来について若い皆さんに期待すること
今どきSIerという半ば時代遅れの会社に新入社員として入った皆さんは、期待も不安もあることと思います。
元々いわゆる「受託開発」というシステム開発手法はシステム開発としては王道で、なんとしてもIT化を達成したいお客さんと二人三脚で頑張ってきたものです。しかし時代は代わりITシステムというのはわざわざ作って競争力を上げるものではなく、業務の前提として普通にそこにあるものになっています。システム開発の仕事もシステムというよりはサービスを作っていくものにシフトしています。
そんな中、受託開発の仕事が残っている意味、そしてお客さんがSIerを選択する意味というのは非常に重たいです。
IT業界はシステムのレイヤー毎の分業が進んでいるという実態があります。クラウド基盤がそこにあり、フレームワークがそこにあり、より実現したいことそのものだけにフォーカスした仕事が出来る環境が整ってきています。
ところが、業務システムは単にITサービスを活用すれば実現できるものではありません。業務要件の適正化、投資の有効性、対顧サービスの確実な提供、問題発生時の対処など「システムを作ること」以外の部分をきっちりと考えなければならないのです。
業界全体で見ても、業務システムのあるべきアーキテクチャを考えるということを志したエンジニアというのはごく一部のように見えます。SIerで仕事をしているととにかく「人を使う」ことが仕事になっていきがちですが、実のところエンジニアとしての楽しみの殆どはアーキテクチャを考えている時ですし、ものを実際に作るというのは業務システムを作るという仕事においてはごく一部の作業に過ぎません。
もっとも、顧客が求める対象もシステムからサービスに変化している最中です。システムの開発手法も変わっていきますし、SIerという形態も次第に変革をし始めているところです。
これからこの仕事がどうなっていくかを決めるのは10年後、20年後のあなた達です。僕のシステム開発という仕事における楽しみや志はおおよそ前述のとおりですが、どんな形でも、とにかくどういうエンジニアに成りたいかという志を持った仕事をすることを大事に仕事というものを考えて欲しいです。
セゾン情報がシステム開発費用１５０億返還とか草しか生えないｗｗｗ
セゾン情報システムズといえばまあ我々からすると「大した機能もないくせにどこにでも入っているせいで使わざるを得ないHULFTでチャリンチャリンとビジネスやっている呪われた会社」ではあるんですが、一応クレディセゾンのメインSIerとして活動しているみたいなんですな。
そもそもクレディセゾンとUCカードのシステム統合の案件はIBMがやってたんだけどなー。
で、この話には裏が有るかもしれないんだけど、旧村上ファンドの人が設立したエフィシモってファンド（まあいわゆるハゲタカ系）がセゾン情報の株３割位持ってるのね。まあよろしくない状態。なので、トラブルを理由に会社の資産をグループ会社に移転しちまおうとかいうアレだったりするかもしれないししないかもしれないんだけど、そのアレだったりしたら道義的にはどうなのってのもあるしね。あえて第三者の判断を持ってきたのもアレかね。
だからと言ってクレディセゾンのシステム統合が上手くいく話じゃないんだけどね。
最近のIBMさん
なんかこうさ、BluemixにしてもWatsonにしても「俺らは大口顧客とプラットホームだけやるから中小の顧客はあなた方でどうぞどうぞでもプラットホームには誘導しろよそこで稼ぐから」みたいな感じになっているんだよなあ。
ようはソフトウェア基盤サービスで稼ぐよってね。
BP側から見ると、IBMがIBMプライム案件でやっているからクソ高い基盤にも説得力があるし、エンジニアの単価も保証されるわけだ。IBMプラットホーム縛りで案件紹介されても顧客の予算のかなりの部分はプラットホーム使用料に消えるんであればエンジニアの部分は足元見られる可能性もあるし、やってられるかこんなんみたいになりかねない（まだわからないけど）。
でもぶっちゃけWatsonくらいしか今のところ優位性を持っているプラットホームないし、プライム顧客渡しちゃったらプラットホーム毎乗り換えられちゃったりしてなんて思ったりもするんだけどな。
