品質の定量的評価について
もうね、客先常駐をとにかく悪と認定したいポジショントークなだけとしか見えないけどね。
これね。
【悲報】客先常駐システム開発で今もステップ数によるバグ検出数基準が使用されていることが判明 - 株式会社アクシア
ブコメとかでも何度も書いているけどさ、客先常駐がことさら悪いわけでもない。一括で受注して持ち帰り開発だったとしても、自社の製品開発だったとしても、同じ問題は起きる。クソなプロジェクトはクソなプロジェクトが引き起こす問題なんだよ（当たり前）。
客先常駐が往々にしてクソなのは、客がクソな上にその客と長く付き合わざるを得なくなるから相対的なクソ度が上がるってだけだし、逆に言うとクソじゃない、素晴らしい客先で常駐の仕事をやれるのであればそれはSIerとしては喜ばしいことなんだよ。
持ち帰り開発なんてフロアコスト自己負担だからな！100人月で見積もりだして80人月でやります！儲かります！みたいな話だったら目的を吐き違えているしね。真に有能なSIerは客先常駐をしながら、人月で見積をしながら、投入人数が見積もりの人月を割っていても容認されるのだよ。
で、品質評価の話ね。品質評価ってのは定量的な評価も定性的な評価もやる必要がある。定量的な評価ってのはソフトウェア工学的な観点からある程度指標が作られる（定量的な評価を嫌がる人のうち結構な割合がこういうソフトウェア工学的な考え方を軽視していて、感覚で仕事をしている気がしてならない）。もちろん、それは「指標」にすぎないから、そのプロジェクトの特性を説明していないし、要員のレベルも説明していない。大規模になればなるほど平均的に指標に近づくことが多いんだけど、そういう指標ってわりかし人間の能力を低く見積もっているから、相対的に低い能力が混在しがちな大規模プロジェクトにおいては案外よく状況を洗い出してくれる。
つまり、そういうことなんだよ。
当然だけど、定量評価ってのはそれ以上でもそれ以下でもない。基準値以上にバグが出ないと捏造してでもバグを出せ、みたいな話はもちろん伝説ではない。某ベンダーとか某ベンダーとかは批判されているとおり、管理ぐらいしかできない人を使って下請けにまるっとやらせるクソプロジェクトを組成したりするからね（とは言え、そのプロジェクトがクソになるのがその下請けにスキルが足りないことに起因していることはままある）。でも、その数字通りにならなかったのはなぜか、ということは考える必要はある。（特にウォーターフォールにおける）プロジェクトの品質管理というのは工程ごとにやるべきことを許容されるリスクの範囲に収めて実行できたか、ということに尽きるわけだから、そこがはっきりしていない場合に疑ってかかるべきなのは当然だ。クソなのは、はっきりとした理由付けで問題あるなしの結論を出すのではなく、単に数が足りないからだめだってなっちゃうことね。然るべき理由があるのにそれを評価できないというのはPMOがクソなわけだ。ただ、数字を軽視すべきではない。
この話が難しいのは、こういう管理の結果、数字が合わないと先に進めないみたいな認識が蔓延した結果、数字合わせに終止することがあるってところ。これはプロジェクトの進め方がまずくて、問題に正直に向き合えないパターン。遅れることが許されない、みたいな空気が蔓延すると捏造は日常茶飯事になる。
じゃあ、数字の管理しなければ品質が上がるの？そんなわけないよね。炎上プロジェクトの最大の問題は、正確な情報収集に基づき、正しく判断を下すことができないことだ。その判断をするための重大な指標としての基準をトップレベルできっちり決められないのであれば、プロジェクトなんてろくな結果を産まない。なので、
プログラミングを行わない元請け企業であるSI企業は、プログラムレベルの試験などには介入せずに、もっと上位の結合試験等のフェーズだけ行えば良いと思います。プログラムの試験のバグ検出数のような基準を作るのであれば、実際にプログラムを実装している企業が現場の実情に合わせて基準を作るべきです。
なんていうのは寝言にすぎないと思う。SI企業が実情に合わせた基準を作り、結果を評価できないというのがおかしなことであって、実装する企業にクオリティコントロールを丸投げするプロジェクトなんて事故ったら死人が出るからね。
Oracleのライセンスコスト問題となぜOracleなのか
またかよ的な話です。日本の企業がOracleを使っている場合の理由の大半は（と言うといいすぎだろうけど）、「よくわからないからOracle」だと思っています。現場からどんなに非難を浴びようが、Oracleです。わからないから。わからないというのを解決するためには金を払うしかないんですよ。逆に言うと、Oracleのライセンスが高くてもわかるようになるくらいだったらその程度の金は払ってもペイするわけですね。ということはつまり、限度を超えると「あれ、わかったほうが安くね？」となる可能性がかなりあります。もっとも、分かった上でOracleを選択するというケースもあるのでその場合わかるコストが高く付く場合もあります。いや、Oracleを使うからわかんなくてよいという理屈はおかしい。なぜなら、仮にOracleに払う金額が妥当であったとしても、Oracleを使ってシステムを構築するベンダーがトンチンカンなことを言ってもOracleを知らないユーザー側は丸め込まれるしか選択肢がありません（丸め込まれた、という言い訳をできる余地込で）。
Oracleが高いという問題はOracleをわかる人を雇うより安いのかという問題が常について回るわけです。Oracleじゃないものを使って問題が起きたときに誰がどう責任を取るのか。難しい話ではない一方で、めんどくさい話ではあります。
「高い」が最大の問題になったときに、でかい会社がOracleを捨てるという選択肢を取り始めたら日本におけるOracleの利用の波が大きく変わるのではないかと思ったり思わなかったりします。なおDB2。
みずほ銀行システム刷新の再延期に思う大規模システムの難しさ
出ましたね。
みずほ銀行、勘定系システムの統合・刷新で2度目の延期を検討 | 日経 xTECH（クロステック）
実際のところ、3.11のあとのアレがなかったらこんなに急いで「全部やります」って計画じゃなかったはずなので延長したから「老朽化」したシステムを云々ということはそれほど大きな問題じゃないんだけど、計画しているコストが大分変わっては来ますね。何しろ巨大なシステムですから、お役御免になる予定だった時期がずれるだけで保守工数がその分全部伸びるわけで、今回は何しろ全部やる予定なのでその全部が全部伸びる上にテストに従事している「新しい方の全部」の人たちの工数も伸びた分必要になるわけですからね。
よく、どこかが遅れている結果スケジュールを進捗させるがそのどこか以外は順調なはずだから面積を変えずにスケジュールだけを伸ばす（月あたりの人数を減らす）という戦略を取ることが有りますが、そもそもこういう場合はそのどこかのせいで整合性を取る試験が実施できない、というパターンだった場合は安易に人を削ると現場が崩壊したりしますし、まあ調整が難しいんだろうなあ。
特に下流側のシステムは上流のデータが全部揃わないと結局のところちゃんと出来ているのかわからない（し、上流もその下流のデータがちゃんとあっていることがわからないと本当にちゃんと出来ているのか自分たちではわからないこともある）ので、一部のサブプロジェクトの問題が全体の品質に波及したりとかそういうことを考えるとこの判断は正しいというか当然と言うか、そもそも金融庁が「障害起こしたらコロス」とプレッシャーをかけている中で延期の判断って大変だと思うんだけどそれが判断できないとしたらお前ら自分たちのリスクも見積もれないのに客の与信判断とかできんのかよって話になるのでまあ今回は頑張ったんじゃないかなとは思います。
投資の問題はあるけど、今回に関しては絶対に事故れないはずなので慎重にやってほしいと思うんですよね。ここで事故ると業界が崩壊するから（崩壊しちまえよと思う反面、事故度が高すぎて波及効果がヤバイので勘弁して欲しい）。
「処罰」が物事を好転させることってあんまないのでは？
医者とか管制塔とかで事件が起きた時に必ず言われるのが「当事者を処罰することは改善につながらない」って話なんだけど、IT業界も例外じゃないのでは？
というか、大企業病としてシステムをダメにしている一つの大きな要素は「失敗したらキャリアが死ぬ」にあるんじゃないかと思うけど。
「官公庁のシステム開発については、プロジェクトに携わる民間の技術者の勤務時間を1日8時間とする。それを超える残業は一切認めない」。こんな法律を作ってみてはどうか。発注者として最低最悪の官公庁のシステム開発と、安倍政権の掲げる長時間労働の是正など働き方改革を両立させる方法は、これしかないと思うぞ。いや、本当に。
公共のシステム開発で“デスマ”、官僚も処罰すれば全てうまく行く | 日経 xTECH（クロステック）
なんかタイトルでいう処罰はこの残業禁止を破ったら、らしいんだけど、まあ正直技術者側の実感からすると、残業は事の本質とは基本的に関係ないので残業禁止はありがたいとしても、それで発注者側のクオリティが変わるかというとまあ変わらんと思う。ロジックとしては残業を禁止するとシステムを完成させるためにはまともな要件定義をやってまともな設計をやってまともな開発をしなければどうやったって間に合わないし予算も膨らむから真面目にやるようになる、ということなんだろうけど、まー無理でしょ。高度なレベルの専門家を適切な値段で雇い、高度な専門家教育をきちんとやってITという仕事が医者や官僚に比肩するくらい、誰でもできるものではないという状態に持って行かないとね。「高くてもいいから優秀な人材を」っていうことをきちんとやれば発注規模がデカイだけでエンジニアを一山いくらだと思っている巨大案件（複数）から優秀な人材がどんどん流出してくんじゃないの？ま、優秀な人材を判断するためには優秀な人材が必要なんだけどね。
名寄せって難しいのよね
同姓同名同生年月日くらいだったら「便宜上」同一人物として扱っているシステムは結構多いと思うよ。
事故の経緯に関し、銀行側の説明をまとめると、次のようになります。
寝屋川支店では、死者の親族からの要請を受けて、死者の銀行口座を閉じた。この際、三井住友銀行の全国の顧客の口座一覧の中で、死者と同姓同名、同じ生年月日の人物を、住所を確認せずに閉じた。
http://21432839.at.webry.info/201601/article_4.html
その人がどの支店に属する人かが重要であった時代ならともかく、今銀行にとってリテールのお客さんの住所は富裕層ならともかくそうじゃなければそれほど大きな意味合いを持っていないことも多いでしょう。
銀行についてはペイオフの絡みでずい分昔に名寄せのシステムは整えたんですが、実際のところ、システム的な名寄せを全て信じて何かをすることは難しいので名寄せされた人はことが起きた時にある程度人力で確認をすることが前提なんじゃないかと思います。住所ってよく変わる上に変わったことが通知されないことが結構ありますから、住所そのものは名寄せの完全なキー情報ではないんですよね。
三井住友のシステムがどうなっているのかはよくわかりませんが、もし名寄せされているのであればそれが「便宜上」であることを理解しないままオペレーションしてしまったってことで単純にオペミスか運用手順ミスですね。わりと由々しき問題なので隠してなければ行内ではそれなりに問題になって改善指令とか出てるんじゃないかな（住所の違う口座があるかを確認する手順とか）。
そういえば昔、実家の隣に自分の旧姓（つまり実家と同姓）で同名の人が引っ越してきた結果云々って話を見たことがあるけど、いずれにしてもID情報ってのはもうちょっとこう一意性が保証できる何かである必要があって、そういう意味ではマイナンバーは本来はこういうことを防ぐために必要な情報として重要なんですけどねえ…
みずほ銀行こうすれば救えるんじゃないかなあ
とにかく、3.11以来金融庁がうるさいので、ちょっと計画変えますって話もなにか問題があるのかどうなってるんだ報告しろで貴重な時間と金を吹っ飛ばすことになりかねないので計画を変えることに対して及び腰になってしまうという問題があるんじゃないかと思うんですよね。つまり、金融庁が余計な口を出さなければ計画が適正になるんじゃないの？
という話はさておき、やっぱりこっちの業界の人とあっちの業界の人では思うことにだいぶ差異があるんだなあと思いました。
で、結局何百億という予算は多重下請け構造の中で中抜きに中抜を繰り返され、最終的に実際に作業する人には時給数百円しか行き渡らないため、中国や台湾、ベトナムといったところから人が駆りだされてきて、現場の中国人が台湾人と殴り合いの喧嘩を演じるとかもう収集つかないところまで来ているという話です。原発事故の石棺処理みたいな煉獄が、こんな近所に存在しているかと思うと胸が熱くなりますね。
長文日記
僕もこの界隈（金融関連のSI）で働いてますけど、特に銀行案件は商流に厳しく、ゆるいところでも3次請けが限界ってことが多いんですよね。特にうちの会社はわりと真面目にやっているのでわけのわかんない7次請けなんて来ないんですが、その分全然人集まらない。でもまあ金融ってちょっとおかしいところはあって、ボリュームが出る代わりに単価安い部分もあるのでそこも苦しいけど。
なのでこの話が本当だとしたら世の中にはクソな2次請けレベルの会社があるのだなあ…
とはいえ、そもそもこのプロジェクトって、少なくとも10年以上前からやってるはずですよね。
報道の通りで、そんな昔からやっているわけじゃないですよね。本格的には2012年位からじゃない？
そんな瑣末なことはどうでもいいとして、
しかも実際にプログラムを書くわけでもない上流工程のSEが多すぎて、それがまさしくウォーターフォールという形で下流工程に流れて行くわけですが、その過程で二次請け三次請けとたらいまわしを繰り返し、最終的に七次受けという嘘かホントかわからないレベルまで人材の質が下がります。
これが全然わからない。2次請けって言ったらその上流工程のSEそのものだし、3次請けはそこを体制的に強化（あるいは強力なSEレベルのサポート）し、開発時にボリュームを受け持つをするのが役割で、たらいまわしになるわけではないよね。もしこれが本当なら僕の知らないところでクソな2次請け会社が沢山あるのだなあ（まああるんだろうけど）。
ここでの上流工程ってのは当然ですが、プログラムを書く以前に業務をシステム要件に落としこむわけだからそりゃ業務要件沢山あれば人はたくさんいますが多すぎるってのは意味がわからない。単にそれだけの分量要件があるってだけ。人材の質が下がるのは人材マーケットが枯渇しているから。よくこんなやつ提案してくるよなって会社がいっぱいありますが…我慢して使うってことはめったにないけど僕の知らないところでクソ会社では採用しているんだろうな…
そもそもなんでそんなことが起きるかというと、「できます」といってできない会社が多いからです。
周りを見ているとよくそんなことで怒られている会社があるので確かにこれはあるんだろうなあとは思うけどね。
では本当はどうすればいいのかと言うと、みずほ銀行はまず一度大手SIerとの付き合いを保留にして、自社で完全なシステム構築ができる人材を雇うべきです。
ほら、こういう人ですら「完全なシステム構築」とか言っちゃうわけでしょ。そりゃシステム上手く出来ないわけですよ。冗談はさておき、べきですって言って具体的にどうするの？って言うとすぐ答えが出なくなっちゃう問題ですよ。言うのは簡単だけど、実際に計画を立てられる人っているのだろうか。試しにやってみたらどうだろう。
「Webサービス開発みたいにお気楽じゃないんだよ銀行は!」とSIerの方々はおっしゃると思いますが、生き馬の目を抜くようなこちら側の業界では、「サービスが落ちたら遺失利益を賠償しろ」みたいな無茶苦茶な契約を結ばないとならないことが良くあります。それこそ秒速で一億は言い過ぎにしても、1秒止まったら何千万の賠償となったら真剣に設計しますよ。それで落とさないっていうのがWeb屋の意地なわけです。
で、これもちょっとお話の観点が違って議論にならない気がします。1秒止まったところで逸失利益はほぼないけど、1時間止まったら行員とバイトのテーラーさんの時給換算で億単位くらいは軽く無駄になるよね。1日止まったら預金も何十億単位かで流出する可能性があるし、元帳が壊れたら多分何千億単位の損害が出た上に銀行潰れるかもしれないよね。
実際には止めない（レスポンスが完全に保証される）ことが目的ではなくて、致命的な不整合を起こさないことと、問題があったときにどれだけ早く復旧できるかが大事なんですよね。もっと言うと、こういった問題はオンラインよりもバッチ（純粋なバッチじゃなくてオンライン更新バッチもあると思うけど）の方が難しいんですよね。
みずほ銀行の預金者は2400万人だといいますが、ATMは6700拠点。まあ各拠点に平均5つのATMが設置されていると仮定して3万3500端末。Webサービス的な常識で考えるとこの端末数の負荷は余裕すぎるわけですが、まあここにネットバンキングが加わったとしても、数十万人のアクティブユーザが一日に何千回とクエリーを送ってくるソーシャルゲームに比べたらトランザクション数としてはぜんぜんです。
システムのパフォーマンスはそりゃ巨大システムだから当然問題になるんですけど、そこは別になんとかなる問題で、どっちかというとトランザクションのパターンが多いことが問題ですよ。数千パターンはあるわけで。その上で難しい業務なんかだと項目チェックだけでものすごいパターンありますしね。単純にやること、考えなければならないことが多すぎるんです。当然ですが、抱えているデータの量もデータの更新パターンも段違いです。1トランザクションあたりのシステム負荷がソシャゲに比べたら段違いだと思いますよ。
既に実績のあるWebベースの取引システムなんか世の中に腐るほどあるわけで、SIerの言いなりにならず責任者が自分の頭で考えれば遥かに低コストかつ早期にシステムの移行ができそうなものですが・・・
既存の業務を捨てて新規に作るのであれば、低コストかどうかはさておき、スピード感あるものが出来るのは間違いはないですね。住信SBIネット銀行なんてのはまさにそういうのだと思うし、逆に言うと、それは持たないものの強さでしかないんですよね。メガバンクが自社の強みを活かすためには当然過去の切り捨ては出来ないわけです。法律でもガチガチに縛られていて既存のシステムをひょいっと適用することは現実的に不可能なことがほとんどだと思いますよ。
ベンダーが絡むと・・特にIBMなんかは自社のメインフレームを売りたくてしょうがないでしょうし・・・・けれどもそんなもの混ぜた時点で終わります。IBMにしかメンテできなくなるからです。
それはハードウェアの話でしょ？ソフトのところは別にIBMしかメンテ出来無いわけじゃないよ。
まあ他のベンダーも思惑は一緒だろうなあ。三者のベンダーを混ぜると、三種類のシステムが混在するよね、常識的に考えて。つまりIBMのメインフレームと日立のメインフレームと富士通のメインフレームが三つ巴の戦いを繰り広げる壮大なスペクタクルロマンが始まっちゃうよね。せめてどれかひとつにしておけばまだ混乱しなかったかもしれないのに・・・。今更言っても仕方ないけど。
今までの報道を読んでないのかもしれないけど、メインフレームはIBMだけって言われてますよ。日立はUnix使ってるって言われてますよ。ちょっと適当過ぎませんか？
こういう場合は、てっとり早く作れるWebベースのクローンシステムを作って、実際の銀行トランザクションのシステムとのつなぎ込みだけやって部分運用とかをしながらブラッシュアップしていけば、まあすんなり行きそうに思えますけどね。全体の予算がウン百億だから、まあものは試しで1億くらいかけてWebベースのプロトタイプを横で作ってみて「あ、正攻法ではダメかと思ったらこっちでもうまくいくじゃん」っていうことにならないんですかね。
さっきからWebベースWebベースって言っているけど何のことを言っているんだろうかってちょっと疑問に思ってきました。今みずほが作っているのって「実際の銀行トランザクションのシステム」であって、フロントチャネルの更改やっているわけじゃないですよね？で、ここについては既にどこかで言われている通り、3.11のあおりで段階的な構築の目を潰されたという話なので、冒頭の金融庁が悪いという話だと僕は予想してるんだけどな。
名前晒しあげなエンジニアにはご同情申し上げるがユーザーフロントエンドの目に見えるソースにコメント入れるなよ的な何か
タイトルのとおりなんですが。
パスポート更新申請のPDFの仕様が酷いと聞いたので確認してみた - Windows 2000 Blog
htmlソースとか、スクリプトとか、ユーザー側で見れちゃうところにコメント残す神経は正直わからないわけです。修正コメントとかそのへん怪しいですよのマーカーでしか無いし、処理の説明とかバックエンドの仕組みを創造させちゃったりするわけで色々と嫌であります。
官公庁って緩すぎるよな…あんなに監督先には厳しいくせにね。
