顧客が求めている過剰品質とは何か
そもそも品質の考え方は色々あるけれども、品質とコストがなぜ直結するかというと品質を担保するのは作業だからであり、作業であるならば作業の手間を徹底的に減らせば低コストで高品質を実現できるはずなんだけど、中々そうはならない。
と言うのは、作業の手間を減らすというのは手間を減らすというシステム設計にほかならず、その品質を担保するためには…という無限ループが待っているから。
これは別に手作業の場合はそういうループが起こらないってことじゃない。なぜなぜ分析とかやっていればわかると思うけど、何をどこまでやったらどうなるかということについての一般解なんてのは存在しないし、だからこそ統計的手法でやるしかないわけで、結局のところ、どうやったら精度を最大化してコストを最小化するかの特殊解を常に考え提示していくことがシステム屋の手腕なわけだ。
ここで問題になるのは、手腕というのはすなわち属人性のあるものだということ。
神林：あの、やっぱり過剰品質を求めているというよりは、何が本来品質として必要なのかというところがわかっていないと思うんですよ。だから、とりあえず、「とりあえず」っていう言い方に絶対なるんですけど、こいつとこいつとこいつは今まであったので、今度も作ってほしい、と。いるかどうかについては、俺はよくわからないし、もしかしたらいらないかもしれないけど、でも今までやっているから、これもつけといねっていうのが多いんですよね。
SIがハッピーになれない理由 (1/7)：EnterpriseZine（エンタープライズジン）
で、これが過重労働の元になるってのも実はおかしい。見積もりが甘いだけ（後段でそういう話出てるけど）。これは発注側の見積もりの問題でもある。
ともあれ、精度に関して言うと本来のフェーズで求められていることに対して過剰になるというのはままある。それが過剰であるよねって指摘は普通は刺さらないんだけど、どうしても予算と見積が合わない時に限ってSIerの主張を聞いてくれたりする。ただし、SIerは開発に失敗し、予定より多くの障害を出して、結果として次から元サヤということも多い。
で、なんで過剰になるかって言うとそれはもう「言い訳」のためなんだよね。金融庁とか。ここではロジックが通用しない。「なんでやってないの？」
「と、統計的に見て云々」
「でもやってないから起きたんでしょ？」
「た、たまたまここが問題になっただけで…」
「でもやってたらわかったはずだよね？」
「…」
完璧なシステムは存在しないがUTは（詳細設計レベルの要件まで含めて）完璧にできるなんていうアホなことを考えている人もいる。UTでの障害発生数を「なんで基準値より少ねーんだよ」と言っている同じ口が言う。
でもここで求めていることは単なるポーズであり、ポーズのためにどんだけ投資してますよってことを可視化すると案外口をあんぐり開ける経営層はいるんだと思う。ポーズに投資するくらいなら障害時に土下座するぜってのが経営者として正しいんじゃないかって思ったりもする。まあ場合によるけど。
一つ確実に言える問題は、監督省庁が改善を求めるなら物量じゃなくてロジックにしろよって問題ね。エビデンスだとかチェックリストだとか言っている場合じゃないんだよ。口はさみたいなら専門家連れてこいよコノヤローってね。
最大の問題は、テストという「技術」を作業レベルのものだと軽視していることで、それはユーザーもSIerも一緒だったりはするってのが一番深い闇だと思うけど。
エンジニアの仕事とは
こんなタイトルのくせしてエンジニアの仕事の話は出てきません。
そもそも、エンジニアにそれに見合った待遇を！とかよく言うじゃないですか。それはそれで賛成なんだけど、一方で足元を蔑ろにしていることが多いとも思うんだよね。足元ってのは、極端に言うと「俺はエンジニアとして雇われているんだからそれしかやらない」みたいなの。でもさ、大抵の場合ってその給料って「自分自身でやらなきゃならない事務作業」の部分も含まれているんだよね。稼働の報告とか、精算の手続きとかさ。え、そんなのエンジニアの仕事じゃないって？じゃあ限られたリソースである売上からそれをやる事務の人を雇おう。原資はエンジニアの給料ね。
ってな感じで金や時間を無駄遣いしていることに怒る人もいるんだけどさ、エンジニア的な発想から言うと「じゃあなんか作ってその作業負荷軽減させちまえ」が正しいわけ。自販機（コーヒーサーバーだっけか？）まで行ってから売り切れてるの気づくのやだからオンラインでチェックできるようにしちゃおうぜみたいなやつね。会社に所属しているのであればなおさら、そういう環境は与えられるのではなく自分で作り出していくものだ、ということを意識しなきゃならん。
エンジニアとしてのモチベーションが云々という話を聞くたびにそういうことを思う。こういった部分だけじゃなくて、働く環境は自分たちが作るものだし、それが出来ないのであればその職場はエンジニアリングの職場ではないよね。
会社ってのは会社という確固たる存在があるのではなくて、そこにいる人達が作っている有機体なんだよ。
海外からの入金にマイナンバーが必要という情報の真実性について
金融ネタなのでこっちに。
色んな意味でこの記事は誤解があるんじゃないかと思う。
現在銀行によって対応はバラバラのようだが、マイナンバーなしの口座に海外から送金すると、銀行側で受け取りを拒否するらしい。本人名義の口座間であってもだ。
海外在住者の日本の金融システムからの締め出しが始まった
つまり、海外に住むひとが、日本に送金しようと思ってもNGを食らう。日本の家族や関係者の仕送りがストップされるという状況だ。
これは大きな誤解があって、むしろ「本人名義の口座間」が一番問題で、マイナンバーを取得できない人が日本の自分の口座に入金するのが「海外送金」というスキームでは難しくなるってことですね。ここでの問題は「日本の口座から海外送金」「海外から日本の口座に海外送金」する際の日本の口座側にマイナンバーが登録されているかどうかなので、「日本の家族や関係者の」口座については当然日本の家族や関係者なのでマイナンバーが取得でき、結果として入金できるので問題ありませんね。自分名義の口座だと難しいかもしれない。
なんでこんなことになるかというと、すでに対応されているFATCA（アメリカの外国口座税務コンプライアンス法）対応やここ最近整備されている国際租税回避のための仕組みであるCRS（共通報告基準）の対応によるものです。タックスヘイブンを利用した企業の実質的脱税や犯罪収益の移転を防止するためですね。
ところで、ここまでの話で問題があるとしたら今ちょうど過渡期の中、すでにマイナンバーが登録されてないと入金されない口座があるってことぐらいですかね。マイナンバーの通知は（トラブルを除けば）すでに終わっているので実質的には大きな問題はなさそうです。ちょっと捻って一番問題ありそうなのは海外転勤者が「自分で」「日本の口座から」自分の海外口座にお金を頻繁に移動しているような場合ですね。これは場合によっては面倒そうですが…。あとは日本で収益を上げる事業をしていて、自分自身は海外に在住しているみたいな。まあそういう場合は日本で法人格取れば問題なさそうです。
なので、
現地でドル建てで給与をもらい、それを日本の家族に送金している人は、生活ができなくなる。生存が脅かされるということだ。
海外在住者の日本の金融システムからの締め出しが始まった
なんてのは煽り過ぎであるし、目的を考えると不当とも言えない。そもそもグローバル大企業の租税回避のズルさについてはみんな不満あるんでしょ？
まあ大石さんはBitCoinやら何やらの伝道者でありそういう点についてはアナーキストに近い立場の人だからここぞとばかりに煽っているんじゃないかって思ってしまいますけどね…
USBポートを物理的に塞ぐというセキュリティー対策
http://www.asahi.com/articles/ASJ284PPTJ28PPTB008.html
うん、まあ事務のPCの大半は（マウス刺す以外は）USB使えなくて問題ないし、例外的な場合は管理者の権限によってしかるべく行えばいいわけで、対策としては普通だよね。
逆にこれで「困る」と言っている人はどういう仕事をどういうスペックでしなければならないのか（市役所、という特性も含めて）考えてみて欲しいなあ。
ブロックチェーン活用技術「mijin」のホームページ解説を読み解く（その２）
第二回です。前回はこちら⇒ブロックチェーン活用技術「mijin」のホームページ解説を読み解く（その１） - novtan別館
前回はホームページ上にあるプロックチェーンの特徴というところまで読みました。
今回は続きから。
高機能なブロックチェーンを提供
mijin | ブロックチェーン構築プラットフォーム
「mijjin」は、単に「ポイント」や「独自通貨」を発行管理するためだけのプラットフォームではありません。
マルチ・アセット対応
ビットコインのようなシングルアセットだけではなく、複数のアセットを同時に且つ自由に管理できます。
マルチ・シグネチャ対応
ネイティブでマルチ・シグネチャ（複数電子署名）に対応し、複雑なトランザクションや権限管理にも対応できます。
スマート・コントラクト対応（2016年予定）
単に「ポイント」のようなアセット管理だけではなく、計算処理や複雑な契約を作成し自動実行できます。
これだけ読むとなんだかわかりませんね。金融用語ではアセット＝資産で、複数のアセットといった場合は多分預金とか債権とかそういった別種の資産を指していると思います。ビットコインはその点では貨幣の管理でしたね。
アセットは種類が違うと管理の仕方も違うことが多いので同時に管理することが必要なのかどうかは微妙ですが、取引履歴という点では複数の資産が同時に扱えたほうが便利そうです（その分仕組みが複雑になってしまいそうですが）。
またマルチシグネチャも難しい話。ざっくりとした話は難しくないです。BitCoinで利用されているマルチシグネチャはウォレットからの出金に複数の鍵（署名）が必要にすることで持ち逃げなどの行為を防ぐというようなものですね。秘密鍵が第三者の手に渡るとデータが改ざんされたり盗まれたりしますね。プライベートなブロックチェーンでそういった問題が起きるかはさておき、これを利用すると承認取引みたいなものが簡単に実現できる…かもしれません。
スマートコントラクトについては詳細不明ですが、自動実行ってことは利子入金バッチみたいなことができたりするのかな？あとは稟議決済とか。これは発表待ちですね。
結果として、
アセット管理
mijin | ブロックチェーン構築プラットフォーム
決済システム
契約システム
情報管理システム
などを実現できる、ということになっています。
次回はmijinが目指すコスト削減について。
SI全面否定ネタを書く人はいたところがクソかそいつがクソかのどちらか
SIが技術者のパラダイスだなんてことは当然ありえない話だけれども、なんかこう過度に自由気ままなイメージのあるプログラマー（というかITエンジニア）なんて方がほとんど幻想に近くて一部のプレイヤーだけがそういう仕事をしているわけではあります。これは一般的などの職業にも言えることで、士業ですら例外ではないよね。
で。
SIはやめておけ
まあ不幸だったね、としか思えないんだけど、主語が大きいので一応反論というかSIの擁護はしておこうと思う。
工数至上主義
受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。
「時間（工数）をかければ良い成果物ができるかもしれないが」と言っているけど良い成果物というのは費用対効果が合っている成果物のことだ。素晴らしいコード（これは保守性の面で場合によって必要な一方、保守性の面で場合によっては不必要なものである）も要らなければ要件にない余計な機能もいらない。もし時間をかけた結果として出来た成果物に要件と異なる成果が伴っていたらそれは実際のところちっとも良いものではない。
時間をかけることでもっとも「良い」成果物になる部分は「品質」なんだけど、品質においても100%バグのないシステムを作るのが難しい以上、一定の基準を上回る品質であればよい。品質を確保できない理由が「工数の不足」であればそのプロジェクトが単に見積もりに失敗しているか、深刻なトラブルが起きているかのどちらか。まともなSIerであればどちらの場合も顧客にしかるべき説明をし、自責でない限りは追加請求を行うだろう。顧客と対等な関係が築けているかなんていう曖昧な状態にある事自体が失敗で、裁判に持って行ったら勝てるか否かが最低ラインの基準。とはいえ、信頼関係は合ったほうが良いし、客の財布をしっかり把握しているべきだとは思う。
マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。
僕の所属しているグループの標語に「一番信じられないのは人力の作業」というのがあるんだけど…
テストデータは見やすく整形したExcelシートあたりからマクロで生成すべきだし、テスト結果の検証は検証プログラムでやるべきではないのかと思う。もっとも、それが正しいことを証明することもけっこう大変な部分はあるし、穴が生じても一律機械的すぎるとわからないことがあるので人が一通り眺めるという過程は必要だとは思っているけど。
元増田の現場と上司は残念でした。
前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。
先述の通り、予定工数で無難にプロジェクトが終わり、顧客も満足しているなら何の問題もない。しかしだね、予定工数で無難にプロジェクトを終えるためにはマネジメントするにも最低限の技術力がないと判断が出来ないことが多々あるわけで…
SIの現場ではどうしても発生してしまう「作業者」を自社で抱えておくにはあまりにも効率が悪いというのがSIという仕事の悪いところではあるけれども、「技術者」のベースラインは社内にないと苦しい。だからと言って、下請けしてくれるBPさんに技術力が必要ないということではない。ビジネスを広げていくためには技術力のあるBPさんがいればいるほどその可能性は広がっていくし、顧客なんかよりBPさんとWin-Winの関係であるべきなんだと思う。自社の開発者の技術力が高ければ高いほど、ついてきてくれるBPさんの質も上がるのが常である。
開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。
比率的には非常に効率がいいポイントはこの辺ではある。これ以上になるとよっぽどの統率力がないと成立していかない。そもそも、この比率を上げるってことは確かにプロパー社員一人あたりの売上・利益は上がるんだけど、一方で売上・利益あたりのリスクが加速度的に増大していくのでBPを食わせるために働く会社になってしまう。案外このことをよくわかっていない会社が多い気もしている。
そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。
正直なところ、このあたりの話は業界の悪弊みたいなもの。ユーザー企業側の意識が高くないかぎり、SIerとしてメリットのない提案はしづらい結果として、「技術面での改善」なんてものは本質的に不要だからではある。ただし、こういう問題意識を常に持っていることが新規案件に役に立つということを理解している会社は結構ある。
static BP
ほっとけ。
技術の話
ここは手短に。
テストコード書けない
意味がわかんない。ちゃんと動いているなりの理由があるならともかく、そうでないならありえない話だし、まあその会社がクソってことだ。
リファクタできない
ケース・バイ・ケースである。
レビューない
その会社がクソ
新規技術試せない
新規技術を実PJTで試すなどという概念はSIerには不要だ。堂々と新規技術で案件を取るべきだし、それで上手くいくという裏付けはPJT開始前にあるべきだ。試すってなんだ。もっともうちの会社はわりと無謀なので世の中で実績があるというだけで利用して地獄を見ることもままある（無駄にはならないが。
横に倣え
それは現場がクソだろ。悪いのは相乗りすることではなく非機能要件をきちんと満たすかどうかにすぎないけど。
static Perlおじさん
こいつは確実にクソだがプログラム構造仕様書なる謎ドキュメントは色んな所で書くので書き方は工夫すべきだと思うんだけどまあそれはさておきPerlがクラス構造を持ったのは実際そんなに昔じゃない（ここで言う昔は20年単位）であるので我慢しろ。
給与
SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。
高くねーよ。とはいえ、大手じゃないかぎり500万を超えてくるにはそれなりに仕事ができる必要はあるとは思うけど。
組織の問題
元増田の会社がクソだね。こういう会社は確かに多いけど、そうじゃない会社も多いんだよ。
日本のSIerが死にゆく理由は成立しているのかな
タイトルが変わっていました。
日本のSIerが死にゆく理由 - 山本大の日記
だったんだけど。
セキュリティ事故ってもう日常茶飯事で、萎縮ムードは常識化してる。
大きなSIerになればなるほど、もう社員のことは信用しない。それって大手のSIerが死にゆく理由だと感じてしょうがない。
前時代的セキュリティ滅ぶべし - レベルエンター山本大のブログ
社員さんよ、「信用してないけど結果残せ」って言われてる感じじゃない？
ええと…僕、今大手SIerアンダーの仕事やっていますけど、萎縮ムードとか別に感じない（ちゃんとやろうぜ！というのはある）。
セキュリティ事故は本質的にはSIerが起こすんじゃなくてユーザー企業が起こすものだ。開発現場におけるセキュリティ事故なんてのも例えば大手金融なんかは本番データの扱いが非常に厳密な結果としてSIerはそれなりに安心して作業できる一方で本番と開発のネットワークが全く一緒の中小企業なんてヒヤヒヤするよね。これは金の問題もあるとはいえユーザー企業の意識の問題だし、セキュリティを意識しなくても守れるようにしたいというのは（現場の一部のクソどもを除けば）それなりに統一された見解だと思うんだがね。
それってちゃちな話じゃない。
前時代的セキュリティ滅ぶべし - レベルエンター山本大のブログ
例えば、DropBoxが使えないからリアルタイムな情報共有ができないとか
社外とのGitのやり取りができないから、ソースの共有で手間食うとかそれだけの話じゃない。
これもユーザー企業がそうして欲しいって要望でやることもあれば、ユーザー企業の要望でやらないこともある。クラウドなツールはもちろん便利なんだけど、使い方を誤ると問題が出るってことは使っている人たちはみんな意識しているし、便利ってだけで使っているわけじゃなくて、TPOに応じて使っているはずだよ。
例えば以下３つの事例はなぜ毎年おこるのか？
前時代的セキュリティ滅ぶべし - レベルエンター山本大のブログ
1. セキュリティーカード紛失によるセキュリティー事故
そりゃ環境構築した時点でそれしか選択肢がなかった＆そこから更改する予算がなかったってだけの場合がほとんどでは？新しいセンターを作るときに生体認証を選択肢に入れてることが多いと思うよ（最近良く遭遇する）。で、これをセキュリティ事故の地雷原とか言っているんだけど、別に起こることが盛り込まれていて、発生した時の対策が講じられている事故なんて別にスミマセン気をつけますだよ。もちろん頻発したら仕事に対する姿勢を疑われるけどそれはどんなカテゴリーでもそうだよね（小学生レベルの誤字脱字が頻発している上流の設計者とか）。
2. いまだにミーティングに参加するときには
前時代的セキュリティ滅ぶべし - レベルエンター山本大のブログ
持ち込みPCがダメだから紙を印刷しなくてはならないという
でもスマホは良くて、タブレットはグレーだからNGとか
今急激な勢いで現場が改革されてきていて、特にペーパーレスな会議についてはかなり構築するところが出てきている。もちろんタブレットね。むしろスマホの方が（BYODな環境なない限り）NGでしょ。
3. メールに添付ファイルつけるときに、２通目にパスワード書くとかいうルールでやってる
前時代的セキュリティ滅ぶべし - レベルエンター山本大のブログ
バカバカしさはなんだろう。
１通目は傍受されても２通目は傍受されないとでも思ってるのか。
これは合ってる。意味わかんねー。これは完全に悪弊（意味が無いだけではある）
もうしわけないけど、前時代的なSIer（か、そのそば）でこういう技術が活用できない不幸な現場にだけあなたが詳しいだけではないのかな。
