Hatena::ブログ(Diary)

novtan別館 このページをアンテナに追加 RSSフィード Twitter

2017-08-17

品質の定量的評価について

もうね、客先常駐をとにかく悪と認定したいポジショントークなだけとしか見えないけどね。

これね。

【悲報】客先常駐システム開発で今もステップ数によるバグ検出数基準が使用されていることが判明 - 株式会社アクシア

ブコメとかでも何度も書いているけどさ、客先常駐がことさら悪いわけでもない。一括で受注して持ち帰り開発だったとしても、自社の製品開発だったとしても、同じ問題は起きる。クソなプロジェクトはクソなプロジェクトが引き起こす問題なんだよ(当たり前)。

客先常駐が往々にしてクソなのは、客がクソな上にその客と長く付き合わざるを得なくなるから相対的なクソ度が上がるってだけだし、逆に言うとクソじゃない、素晴らしい客先で常駐の仕事をやれるのであればそれはSIerとしては喜ばしいことなんだよ。

持ち帰り開発なんてフロアコスト自己負担だからな!100人月で見積もりだして80人月でやります!儲かります!みたいな話だったら目的を吐き違えているしね。真に有能なSIerは客先常駐をしながら、人月で見積をしながら、投入人数が見積もりの人月を割っていても容認されるのだよ。

で、品質評価の話ね。品質評価ってのは定量的な評価も定性的な評価もやる必要がある。定量的な評価ってのはソフトウェア工学的な観点からある程度指標が作られる(定量的な評価を嫌がる人のうち結構な割合がこういうソフトウェア工学的な考え方を軽視していて、感覚で仕事をしている気がしてならない)。もちろん、それは「指標」にすぎないから、そのプロジェクトの特性を説明していないし、要員のレベルも説明していない。大規模になればなるほど平均的に指標に近づくことが多いんだけど、そういう指標ってわりかし人間の能力を低く見積もっているから、相対的に低い能力が混在しがちな大規模プロジェクトにおいては案外よく状況を洗い出してくれる。

つまり、そういうことなんだよ。

当然だけど、定量評価ってのはそれ以上でもそれ以下でもない。基準値以上にバグが出ないと捏造してでもバグを出せ、みたいな話はもちろん伝説ではない。某ベンダーとか某ベンダーとかは批判されているとおり、管理ぐらいしかできない人を使って下請けにまるっとやらせるクソプロジェクトを組成したりするからね(とは言え、そのプロジェクトがクソになるのがその下請けにスキルが足りないことに起因していることはままある)。でも、その数字通りにならなかったのはなぜか、ということは考える必要はある。(特にウォーターフォールにおける)プロジェクトの品質管理というのは工程ごとにやるべきことを許容されるリスクの範囲に収めて実行できたか、ということに尽きるわけだから、そこがはっきりしていない場合に疑ってかかるべきなのは当然だ。クソなのは、はっきりとした理由付けで問題あるなしの結論を出すのではなく、単に数が足りないからだめだってなっちゃうことね。然るべき理由があるのにそれを評価できないというのはPMOがクソなわけだ。ただ、数字を軽視すべきではない。

この話が難しいのは、こういう管理の結果、数字が合わないと先に進めないみたいな認識が蔓延した結果、数字合わせに終止することがあるってところ。これはプロジェクトの進め方がまずくて、問題に正直に向き合えないパターン。遅れることが許されない、みたいな空気が蔓延すると捏造は日常茶飯事になる。

じゃあ、数字の管理しなければ品質が上がるの?そんなわけないよね。炎上プロジェクトの最大の問題は、正確な情報収集に基づき、正しく判断を下すことができないことだ。その判断をするための重大な指標としての基準をトップレベルできっちり決められないのであれば、プロジェクトなんてろくな結果を産まない。なので、

プログラミングを行わない元請け企業であるSI企業は、プログラムレベルの試験などには介入せずに、もっと上位の結合試験等のフェーズだけ行えば良いと思います。プログラムの試験のバグ検出数のような基準を作るのであれば、実際にプログラムを実装している企業が現場の実情に合わせて基準を作るべきです。

なんていうのは寝言にすぎないと思う。SI企業が実情に合わせた基準を作り、結果を評価できないというのがおかしなことであって、実装する企業にクオリティコントロールを丸投げするプロジェクトなんて事故ったら死人が出るからね。

2017-03-13

Oracleのライセンスコスト問題となぜOracleなのか

またかよ的な話です。日本の企業がOracleを使っている場合の理由の大半は(と言うといいすぎだろうけど)、「よくわからないからOracle」だと思っています。現場からどんなに非難を浴びようが、Oracleです。わからないから。わからないというのを解決するためには金を払うしかないんですよ。逆に言うと、Oracleのライセンスが高くてもわかるようになるくらいだったらその程度の金は払ってもペイするわけですね。ということはつまり、限度を超えると「あれ、わかったほうが安くね?」となる可能性がかなりあります。もっとも、分かった上でOracleを選択するというケースもあるのでその場合わかるコストが高く付く場合もあります。いや、Oracleを使うからわかんなくてよいという理屈はおかしい。なぜなら、仮にOracleに払う金額が妥当であったとしても、Oracleを使ってシステムを構築するベンダーがトンチンカンなことを言ってもOracleを知らないユーザー側は丸め込まれるしか選択肢がありません(丸め込まれた、という言い訳をできる余地込で)。

Oracleが高いという問題はOracleをわかる人を雇うより安いのかという問題が常について回るわけです。Oracleじゃないものを使って問題が起きたときに誰がどう責任を取るのか。難しい話ではない一方で、めんどくさい話ではあります。

「高い」が最大の問題になったときに、でかい会社がOracleを捨てるという選択肢を取り始めたら日本におけるOracleの利用の波が大きく変わるのではないかと思ったり思わなかったりします。なおDB2

2016-11-14

みずほ銀行システム刷新の再延期に思う大規模システムの難しさ

出ましたね。

ニュース - みずほ銀行、勘定系システムの統合・刷新で2度目の延期を検討:ITpro

実際のところ、3.11のあとのアレがなかったらこんなに急いで「全部やります」って計画じゃなかったはずなので延長したから「老朽化」したシステムを云々ということはそれほど大きな問題じゃないんだけど、計画しているコストが大分変わっては来ますね。何しろ巨大なシステムですから、お役御免になる予定だった時期がずれるだけで保守工数がその分全部伸びるわけで、今回は何しろ全部やる予定なのでその全部が全部伸びる上にテストに従事している「新しい方の全部」の人たちの工数も伸びた分必要になるわけですからね。

よく、どこかが遅れている結果スケジュールを進捗させるがそのどこか以外は順調なはずだから面積を変えずにスケジュールだけを伸ばす(月あたりの人数を減らす)という戦略を取ることが有りますが、そもそもこういう場合はそのどこかのせいで整合性を取る試験が実施できない、というパターンだった場合は安易に人を削ると現場が崩壊したりしますし、まあ調整が難しいんだろうなあ。

特に下流側のシステムは上流のデータが全部揃わないと結局のところちゃんと出来ているのかわからない(し、上流もその下流のデータがちゃんとあっていることがわからないと本当にちゃんと出来ているのか自分たちではわからないこともある)ので、一部のサブプロジェクトの問題が全体の品質に波及したりとかそういうことを考えるとこの判断は正しいというか当然と言うか、そもそも金融庁が「障害起こしたらコロス」とプレッシャーをかけている中で延期の判断って大変だと思うんだけどそれが判断できないとしたらお前ら自分たちのリスクも見積もれないのに客の与信判断とかできんのかよって話になるのでまあ今回は頑張ったんじゃないかなとは思います。

投資の問題はあるけど、今回に関しては絶対に事故れないはずなので慎重にやってほしいと思うんですよね。ここで事故ると業界が崩壊するから(崩壊しちまえよと思う反面、事故度が高すぎて波及効果がヤバイので勘弁して欲しい)。

2016-09-12

「処罰」が物事を好転させることってあんまないのでは?

医者とか管制塔とかで事件が起きた時に必ず言われるのが「当事者を処罰することは改善につながらない」って話なんだけど、IT業界も例外じゃないのでは?

というか、大企業病としてシステムをダメにしている一つの大きな要素は「失敗したらキャリアが死ぬ」にあるんじゃないかと思うけど。

「官公庁のシステム開発については、プロジェクトに携わる民間の技術者の勤務時間を1日8時間とする。それを超える残業は一切認めない」。こんな法律を作ってみてはどうか。発注者として最低最悪の官公庁のシステム開発と、安倍政権の掲げる長時間労働の是正など働き方改革を両立させる方法は、これしかないと思うぞ。いや、本当に。

木村岳史の極言暴論! - 公共のシステム開発で“デスマ”、官僚も処罰すれば全てうまく行く:ITpro

なんかタイトルでいう処罰はこの残業禁止を破ったら、らしいんだけど、まあ正直技術者側の実感からすると、残業は事の本質とは基本的に関係ないので残業禁止はありがたいとしても、それで発注者側のクオリティが変わるかというとまあ変わらんと思う。ロジックとしては残業を禁止するとシステムを完成させるためにはまともな要件定義をやってまともな設計をやってまともな開発をしなければどうやったって間に合わないし予算も膨らむから真面目にやるようになる、ということなんだろうけど、まー無理でしょ。高度なレベルの専門家を適切な値段で雇い、高度な専門家教育をきちんとやってITという仕事が医者や官僚に比肩するくらい、誰でもできるものではないという状態に持って行かないとね。「高くてもいいから優秀な人材を」っていうことをきちんとやれば発注規模がデカイだけでエンジニアを一山いくらだと思っている巨大案件(複数)から優秀な人材がどんどん流出してくんじゃないの?ま、優秀な人材を判断するためには優秀な人材が必要なんだけどね。

2016-07-11

名寄せって難しいのよね

同姓同名同生年月日くらいだったら「便宜上」同一人物として扱っているシステムは結構多いと思うよ。

事故の経緯に関し、銀行側の説明をまとめると、次のようになります。

寝屋川支店では、死者の親族からの要請を受けて、死者の銀行口座を閉じた。この際、三井住友銀行の全国の顧客の口座一覧の中で、死者と同姓同名、同じ生年月日の人物を、住所を確認せずに閉じた。

404 Not Found

その人がどの支店に属する人かが重要であった時代ならともかく、今銀行にとってリテールのお客さんの住所は富裕層ならともかくそうじゃなければそれほど大きな意味合いを持っていないことも多いでしょう。

銀行についてはペイオフの絡みでずい分昔に名寄せのシステムは整えたんですが、実際のところ、システム的な名寄せを全て信じて何かをすることは難しいので名寄せされた人はことが起きた時にある程度人力で確認をすることが前提なんじゃないかと思います。住所ってよく変わる上に変わったことが通知されないことが結構ありますから、住所そのものは名寄せの完全なキー情報ではないんですよね。

三井住友のシステムがどうなっているのかはよくわかりませんが、もし名寄せされているのであればそれが「便宜上」であることを理解しないままオペレーションしてしまったってことで単純にオペミスか運用手順ミスですね。わりと由々しき問題なので隠してなければ行内ではそれなりに問題になって改善指令とか出てるんじゃないかな(住所の違う口座があるかを確認する手順とか)。

そういえば昔、実家の隣に自分の旧姓(つまり実家と同姓)で同名の人が引っ越してきた結果云々って話を見たことがあるけど、いずれにしてもID情報ってのはもうちょっとこう一意性が保証できる何かである必要があって、そういう意味ではマイナンバーは本来はこういうことを防ぐために必要な情報として重要なんですけどねえ…