LOC生産性でチームの開発能力を評価してほしくない
最初に、すいません。ただのグチです。
まあ、仕事をしていると嫌なこともあるわけで、腹の中でモヤモヤしているのも健康上良くないので、ここで整理してみようかと。
チームの開発生産性の比較にLOC生産性を使うな
結論はこれなんですけど、もうちょっとだけ。
保守開発なんてやっていると、他システム起因のプロジェクトにチームとして案件支援を行うことがあるのですが、それらを統括するPMO部隊の発言で、ひっくり返りそうになるのがコレ。
「今回は各チームとも生産性を○○KLOC/MM以上にして欲しい」
「オタクのチームは、見積生産性が☓☓KLOC/MMで生産性が悪いんじゃないか」
この手の発言聞くとやる気激減なわけですけど、仕事なので仕方が無い。。。
所謂クソコードが多いプロジェクトの方が生産性がよく見える
そもそも、チームの開発生産性を比較するのに、LOC生産性を使うのは問題がおおすぎるのですよ。
保守開発の現場では、今回開発予定規模を「母体係数法」を使うことがあります。
この母体係数法では、
今回修正規模 ＝ 実修正規模 ＋ 母体規模 × 係数
なんて式で開発規模を求めるわけですが、母体規模が大きければ大きいほど今回修正規模が大きくなるわけですね。
てことは、
- コードクローンがたくさんある
- 到達不能コードがたくさんある
- モジュール分割せずに巨大ソースを書く
なんて状態のプログラミングを行っているチームのほうが母体規模が大きいってことになるわけで。
で、オッサンはちまちまリファクタリングしたりして、少しでも書きやすいコード、修正しやすいコードにしようとメンテナンスしているわけですけど、そうやってメンテナンスすればするほど、母体規模は小さくなるし、修正が必要な量も少なくなる。
でも、実現する機能量は変わらないので、必要となるテストやドキュメントなどはさほど減らない。
なので、見た目上LOC生産性が悪くなるようにみえるわけなんですよね。
改善すればするほど、何もしないチームよりも生産性が低いなんて言われたりしたらふざけるな、といってしまいたくなるわけですよ。
まったく、やってらんない。
そもそもプロジェクト特性を無視して開発生産性を比較するな
LOC生産性なんて指標だと、数字出すこと自体は案外柔軟に行えるもので、プロジェクトの形態を問わず生産性を算出できるわけですが。。。
バッチ中心のプロジェクトと、オンライン中心のプロジェクトの生産性を単純比較するなよと。
同じような理由で、生産性が出づらい基幹系システムと生産性が稼ぎやすい情報系システムを比較したり、生産性が出づらい超大規模なプロジェクトと生産性が稼ぎやすい小規模プロジェクトを比較するのも違うだろうと。
プロジェクト特性により、必要となるタスク、開発量は変わってくるのだから、十把一絡げにLOC生産性を評価してもしょうがないだろうに。
というか、同一チームにおける過去の案件と次回案件での開発生産性の比較以外で生産性なんか使うもんじゃあないだろうと。
予算削減の理由として開発生産性を問題にするべきじゃあない
こんな感じで生産性が問題になるってのは、要は予算を減らしたいって思惑なわけなんですけど、生産性なんて「生産性悪いんじゃないの」なんて指摘したって当然上がるわけない。
むしろ、どこかに歪みが生じるわけで、リスク上昇や品質低下などろくな事にはならんと思うわけなんですよね。
予算を減らしたければ、基本は要求といったフォーカス減らすべきでしょう。
無駄な要求、無駄なタスクを要求し、上積みしているにもかかわらず開発生産性が悪いって言うのは筋違いだろうと思うわけです。
まとめ
まあ、仕事を依頼する側も結局は更に上役に対して説明するために、LOC生産性を利用するって理屈もわからなくはないわけです。
誰にでもカンタンに計測ができるLOC生産性ならば、数多くのチームが共通の指針として算出する事自体は簡単です。
大人数、多数のチームが参画するようなプロジェクトでは仕方が無い理由があるのでしょう。
とはいえ、最初に戻るわけですけど、LOC生産性をチームの開発能力比較に使わないでほしいわけですね。
アカウンタビリティを易きに流れLOC生産性を使うのではなく、チーム特性ごとにきちんとした分析指標で説明できるようにしたほうが有用だと思うわけです。
全くやってらんないわけです。愚痴りたくもなりますよ。
以上
システムの裏の裏の制約が表に出た話
数週間も経過したらちょっと。。。システムは、実際にはその後ろで商流が動いているので、データの書き換えは容易でも、取引や契約の訂正は困難なわけで。。。諸経費も発生してるだろうしねえ
興味深かったので、ちょっとだけ。
代理店ビジネスフロー
ちょっとブコメ見てて気になったのですが、案外多くの人がHISの設計をフールペナルティと考えている点。
ホントかな？
HISみたいな代理店業務の業務フローは以下の様な感じかと。
- HISがエンドユーザから注文を受注
- HISは、ユーザからの注文をチェック、取りまとめて、航空会社に発注
- 航空会社は航空券を手配
まあ、要はシステム的には入力されたデータはそのまま右から左に航空会社に連携しているんですよね。バッチファイルかなんかで。
実は、元記事でも触れているのですけど、
4万円を失うのはあまりに辛いので、HISと航空会社に直接電話したが両方ともまったくダメだった。両方も「一切修正はできない」との一点張りだった。
とあるように、名前変更ができないってのは、航空会社の仕様ですね。
ちなみに、JALのホームページ*1見ると、「格安航空券の記載内容の変更はできません」「取り消しは5万円頂きます」なんてあるので、HISが請求する取消手数料って航空会社請求の取消手数料であり、HISは徴収してないんじゃないのって気がします。
※HISでも航空会社が予約変更を許容している通常料金の航空券であれば、予約変更や取消対応するとの記載がありますし。*2
航空会社は、早期に予約を確定することで格安航空券成り立たせている事情もあるので、キャンセルに制約かけているんじゃないのかな、と思います。
大きなビジネスほど関連システムは多い
ところで、今回の航空券販売みたいなビジネスなんかもそうですけど、ビジネスの規模が大きくなればなるほど、関係会社やシステム間連携がどんどん増えてくんですよね。
オッサンが担当しているシステムでも、ビジネスのフロントエンドから起算すれば、ひとつの取引を完了させるため１０～２０のシステムで処理されるなんてのも珍しくないです。
このようにどんどんビジネスの規模が大きくなってくると、業務上の制約とか手数料規定、取引の締め時刻などってビジネス上のボトルネックにより内容が左右されることもよくある話。
まず理解できないのは、なぜ予約後に一切の変更ができないシステムになっているのか、ということだ。普通考えると、電子的な記録なのだから修正することは容易のはずだ。
表向きはよくわからなくても、システムの先の先ではビジネス上の理由などから色々制約が発生しているなんて珍しくないんですよね。
結局、電子データ変更は容易でも、その裏のビジネス、取引を変更することは容易では無いってことですね。
そんなんで、顧客と対峙しなければならないところを担当している人は、色々説明に苦労するわけなんですよね。
んなもん自分らのせいじゃないのに。。。的な理不尽を感じることは多いんじゃあないかな。
まあ、UIがわかりづらいってのはHISへの苦情を申し入れてもいいとは思いますけど、それ以外の理由をHISに文句言っても仕方ないんじゃあないかな、なんて思います。
まとめ
まあ、4万円損したのは残念としか言いようがないので、次回以降気をつけましょうって感じですね。
以上
「顧客情報管理、再委託を原則禁止 経産省が指針改正へ」の雑感
ここ最近、シフト体制で昼夜逆転生活で動いていたものですっかりブログの更新を怠ってしまいました。
まあ、仕事しているのだから、仕事優先になってしまうのは仕方が無いのですが、三十路過ぎると正直夜間シフトや早朝シフトの勤務はキツイ。。。
帰宅してから何もする気が起きなくなってしまいますよ。
前置きはさておき。。。
うわ～、これはダメでしょ。
お役所がこの手の話に関わるとろくでもないことになる代表例みたいな事例になりそうです。。。
BPOはどうする？
個人情報の委託は、別にシステム屋だけじゃあなく、BPO等の業務アウトソーシング会社でも扱ってます。コールセンタ委託なんかも。
ココらへんの会社は業務の専門家ではあるものの、システムの専門会社ではないため、システムの運用は再委託することもよくある話。
そういったBPO系の会社はことごとく影響を受ける可能性があります。
てか、親会社 → グループ内のBPO委託 → グループ内システム子会社のシステム運用、みたいな企業運営にも影響が出てきてしまうわけで。
セキュリティの向上につながらないのに、余計なコストがかかってしまう企業は涙目ですね。
自社データセンタを持つものだけが生き残るか。。。
多分、経産省は今回のベネッセ事件で「多重請負が～」みたいな声が多く発せられているのを見て、このような対策を打ち出そうとしているのかもしれませんが。。。
で、この方針が正式に運用された場合、「自前のインフラを持ってない会社はどのようなインフラ運用すれば良い？」という素朴な問題にぶち当たります。
ハウジングサービスは当然情報管理の再委託となります。AWSなどのIaaSも同じ。
つまり、この経産省方針に従うと、個人情報を管理する必要があるサービスは、実質的には自社データセンタや自社内のサーバルームにてオンプレミスで運用しなければならないということとなります。
昨今、AWS上でサービスを提供しているってWEBサービス、いくつかありますけど、この運用が実施されたら間違いなくいくつかのサービスは停止となるわけで。
ぶっちゃけ、システム屋の受ける影響よりも、WEBサービス系のベンチャーの方が影響が大きいんじゃないかな、と思います。
まとめ
代表２つ書きましたが、個人情報の再委託禁止とかになると他にも影響は計り知れないです。
てか、この前も書いたとおり*1、雇用関係など人に着目したってセキュリティ問題の解決は困難だし、付随する影響も大きい。
まあ、お役所がこの手の話に口出しするとろくな事にはならないでしょうね。。。
以上
エビデンスなどの成果物の最適解は現場によって違うよね
こういうのは非常に興味深い話で、同じSIer、同じ元請けのPMだって成果物の定義がバラバラだったりするので、他所さん面白いことやっているなあって思える話題です。
昔、詳細設計でプロマネが成果物定義をろくにやってないと、実働メンバーが苦労するって話*1を書いてましたけど、それと似た話ですね。
自分の現場での成果物定義
まあ、こんなこと書いているとお前のところではどんなんだと言われそうなので、現在の現場で定義している成果物をカンタンに説明します。
なお、保守開発の現場となります。
単体テスト
個々のライブラリ、アプリケーション毎のテストで実行した結果のAPI出力結果や処理ログ、DBダンプのテキスト。
顧客納品物から除外するようにしているので、まあプロマネであるオッサンが確認できる形の証跡であれば良しとする方針です。
結合テスト
話題のEXCELに。ブラウザ出力画面をスクリーンショットをペタばり。
ただし、seleniumをカスタマイズしたものから自動で出力されたスクショを、これまたEXCELに自動で貼り付けるスクリプトでエビデンスを編集。これをJenkinsで自動実行。
リグレッションテストでは、検証自体はブラウザに出力されたhtmlソースを過去の正常結果とdiffを取り、差分を許容できる場所以外での差分有無だけを自動判定させるスクリプトで検証するようにしてます。
seleniumでどうしても自動化できなかった僅かな部分だけ、手作業＋目検を行う形。
システムテスト
結合テストとほとんど同じだけど、テストシナリオなどの都合上、システム運用が絡むのでJenkinsの動きがちょっと違う。
・・・
まあ、ざっとこんな感じです。
ちなみに、EXCELにエビデンスを貼り付けている理由は大したことがなく、
- ユーザも含めて、社内標準PCで新たなアプリケーションをインストールすることがなく参照可能なファイルフォーマットであること
- サイズが違うスクリーンショットなどを、画面遷移順に並べるたり、コメント追記などの編集が容易なファイルフォーマットであること
ぐらいの理由なので、ぶっちゃけユーザの会社のPCで見られるものなら、ファイルフォーマットはなんでも良いってのが本音ですね。
スクショエビデンスの目的としては、「顧客への納品物」「マニュアル作成のための資料」「過去バージョンの動作追跡」など、案外使い道は多いものです。
成果物の形を決める要因
とまあ、こんな感じで成果物を定義しているわけですが、成果物の形をどう定義するか、どうやって作成するかについては大体以下の様な要因があると思ってます。
- 最終承認者の要望（エンジニアか、非エンジニアか、現場か、お偉いさんか）
- 承認者との関係（信頼度合いとか、受け入れ可能なフォーマットとか）
- 顧客との契約の形態（受託開発売切、保守開発、自社内製）
- ソフトウェアライフサイクル（永続、有期限、単発）
- 作業者との契約の形態（内部、請負、SES、派遣）
などなど。
これらの要因によって、適切な形のエビデンス、テスト実施方針が決まるかと思いますので、成果物を決めるプロマネは注意しておいたほうがいいかなと思います。
で、こういった背景を無視して「EXCELエビデンスなんてSIerの闇」なんて言ってもナニイッテンの、で終わってしまう場合もあるため、きちんと背景は抑えておいたほうが良いかなと思います。
ところで、「SIerは自動化ツールを使ってないからおかしい」なんてのをたまに見かけますけど、「受託開発売切、単発ソフト」の現場でテスト自動化なんて行ってたら、あっという間に過剰コストで大赤字です。
オッサンも、ぶっちゃけ保守開発の現場でなければ自動化なんてしなかったし。
状況に応じた最適解は様々なので、あまり自分の視界からだけで語ったりするのはよくないんじゃないかな、と元記事みて思いました。
まあ、オッサンも自分の視界から語っているのでどこまで俯瞰できているかは、微妙なんですけど。
SIerの闇
ところで、元記事は「SIerの闇」なんて語っているわけですけど、個人的に感じる本当の闇は別のところにあって。
ぶっちゃけ、テスト自動化など推進していて常々考えさせられるのは「自動化して効率化した作業工数はどこに消えたのか」。
お客からもらうカネは変わらない。けど、テストは自動化した結果、必要となる作業量は減少している。。。
あんまり多くは語れないですが、「誰かの何か」は、きっとどこかの闇に消えたのでしょう。
まとめ
ところで、この手の話で気になるのがあまりにも目的意識が共有されてない件。
元のまとめのツイートしている人の現場でも、多分、その現場のPMなりの事情と目的はありそうな気がしますが、その目的や事情が憶測で語られ、目の前の現象だけが問題と語られる点。
目的意識をメンバーで共有するのもプロマネの仕事だったりするので、そういった共有感を高められるようなチームマネジメントすることが、このSIerの闇をはらう一番の処方薬な気がします。
以上
Selenium Testing Tools Cookbook
- 作者: Unmesh Gundecha
- 出版社/メーカー: Packt Publishing
- 発売日: 2012/11/23
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
「人月問題」や「多重請負」は「害悪の原因」ではなく結果
上記の４５の弊害。どれも微妙に指摘できそうな内容ばかり。。。ちょっとばかり検証してみますか。
害毒として挙げられている事項について検証
４５の害毒それぞれ微妙に突っ込みどころがあるので、個々解説を書こうと思ったら、半分ぐらい書いた段階で既に５０００文字を突破てしまいました。。。
もうやめやめ。こんな長文誰が読むんだい。
というわけで、代表例を幾つかピックアップして指摘。
因果関係が逆転
１．労働集約型産業のままで知識集約型産業に脱皮できない
逆逆。主力である「受託開発」が労働集約的な仕事だから、労働力に応じた収益となるため人月商売や多重下請が発生するんですよ。害悪、ではなく原因。
他にも、「６．いつまでも手工業、システム開発の工業化が進まない」も同じです。受託開発で、ユーザごとに業務要件、システム要件が違うがため、工業化が進まないわけで。で、工業化が進まないから、力技に頼るがため、多重請負になるわけで。。。
原因と結果を逆転しても、何の問題提起にもなりません。
一般論のすり替え
２１．不況時に多くの技術者が失業の危機に直面する
「多重請負」していないとされるアメリカも、不況時には１０万人単位でレイオフされてます。２０００年初頭のITバブルはじけた時のこと、もう忘れたのですかいな。
シリコンバレーのIT企業に吹き荒れるレイオフの嵐（1/2）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)
ココラヘンは、労働需要と雇用の関係で、別に多重請負とは関係ない一般論をさも多重請負の問題点としてすり替えているだけです。こういうストローマン的な詭弁は関心しないなあ。かえって、多重請負の方が、プロジェクト間での要員調整を容易にしやすいことから、失業の防止弁となっているなんていう話もあるわけで。
他にも一般論とのすり替えとして、商流の問題である「３．SIerを頂点とした明確な“格差社会”が存在する」、プロジェクトマネジメントの問題である「２０．定期的に発生する失敗プロジェクトでデスマーチとなる」などなど。
ユーザの問題のすり替え
２７．システムで余計な機能も作り、ユーザー企業の無駄なプロセスを温存
これと、「１３．「言われた通り何でも作る」という御用聞き営業が蔓延」を組合せてみればわかりますが、要は「ユーザの過剰な要求に応えている」ということを害悪としているわけです。でも、これをベンダの責任というのはただのユーザ問題のすり替え。てか、多重請負関係ないじゃん。。。
たしかに、ユーザが無駄なプロセスを作るのは、ユーザにとってもためにならないし、オッサンも要件定義等の際には「このプロセスは省力化できるような作りにしましょう」なんて提案することあります。
ただ、あくまでベンダができるのは提案まで。最終決定はユーザの責任以外に他なりません。
これって、「大盛りサービスだからって食べ過ぎて太ってしまった。賠償しろ」って言っているようなもんじゃあないですか。。。言いがかりにもホドがある。
同じような話は「２８」「２９」「３１」などもそう。
てか「３２」なんてひどい話。ユーザはITにより新たなビジネスを生み出すために仕事を依頼しているわけで、ユーザに吸い取られるって。。。お金を出してくれるユーザのIT投資全否定してどうするの。全ての投資活動、BtoBの仕事を否定しているようなもんです。
それは害悪ではない。。。
一番最初に「ITベンダーの経営幹部をはじめ関係者も「何とかしなければ」と思うだろう。」と書いているわけなんですけど、多分、この話をITベンダの上役が聞いたら大喜びします。
ITベンダの目標は、より上流工程の仕事を勝ち取ること。顧客のIT戦略に深くコミットすることで高い付加価値を出すことです。
これは、世界中のITベンダでは結構常識的な戦略です。欧州ではそうやってITベンダが、顧客のIT戦略に密接に関わろうとしてます。*1
また、ユーザ企業の戦略としてITOを積極的に進めている事情もあります。特に、非IT企業であれば、本来のコア事業に集中することでより高い付加価値を出せるってこともあるため、戦略的なITO/BPOを活用する事例も多い。
これは、ただの利害の問題ですね。
他にも「４１．経営がリスクを取ることに不慣れ」なんかも、リスク志向は経営戦略の問題なので、不慣れだからって問題にならない場合もありますよ。低リスクで安定した収益を稼げるってことだって、立派な価値として評価される場合もあります。
ITproの記事との矛盾が。。。
あれ？過去ITProの記事で、「事業部門がITベンダに直接依頼」とかって書いてたような気が。。。
IT部門のイメージは「抵抗勢力」：日経コンピュータDigital
まあ、何年も前から事業部門からの直接的な仕事の依頼、多いですよね。こんなんもうとっくの昔の話と思ってましたが。。。
自ら記述した記事と反する問題点を上げるってのは、間の抜けた話です。
・・・・
っと、ちょっと書きすぎました。
上記のような要領でツッコミを書いていたら、あっという間に長文の出来上がりなのでこのぐらいまでにしておきましょう。
確かに、いくつかの事項については、「人月商売」「多重請負」の害悪として間違いない、というのもありました。
「人月商売」の害悪は、「３６．技術者数で売り上げが決まり、成長が難しい」。これは間違いないです。再委託先ベンダを見ると、確かに技術者稼働率が重要目標としているベンダもたしかにあります。人月商売は安定的で低リスクな反面、スケールが効きづらいのは間違いないです。
「多重請負」の害悪は、ここには書いてないですけど「委託横流しによる利益中抜き」が問題じゃないんですかね。つまり、エンジニアへのフリーライド。
余談）出版業界は外れてばっかりの他業界分析よりも、自己分析が先では
上記の通り、今回の記事は題名に偽りあり、と言ってもいいようなぐらい、過半数が人月商売や請負の問題に関係ない内容ばかりでした。４５個も頑張って挙げようとしたのはわかりますが、もうちょっと落ち着いて分析しなさい、と言いたいぐらい。
そもそも論として、この手の話は１０年、１５年前から繰り返されているわけですが、本当に問題であれば、何らかの弊害が出ていてとっくにおかしくない。にも関わらず、毎年のように同じ話を繰り返している。であれば、演繹のロジックなり、前提なりが間違っていることを疑うべきでしょう。
そういった指摘として、真っ当に業界にいる人間として、
「極言暴論」の読者にも「以前に何度も聞いた話」とシニカルに受け止められてしまったりする。「このままでは日本のIT業界に未来は無い」と叫んだところで、「またですか」とオオカミ少年扱い。
という反応が出てもおかしくない。岡目八目って言葉もありますが、こんだけ大きくなった市場で傍から見える情報は限界がある。一般的に考えれば業界の中の人のほうが情報も多いし、正確な認識も持てそうなもんで、業界人の指摘については一考の余地があると考えてもいいと思うんですよね。でも自説を疑うどころか、
“ゆでガエル”状態になっている人には、湯の温度が多少上がったぐらいでは危機感を持って受け止めてはもらえない。
と指摘者をゆでガエル扱いする有り様。今の今まで外れ続けてきたのに、どんだけ傲慢なんだと。
ぶっちゃけ、メディア業界の人って顧客や他の業界をきちんと見てないし、分析もいまいちですよね。何が何でも自説が正しい。だから、取材とかだってシナリオありきの取材をしたりして、取材先とトラブルになったりもする。問題を指摘されたってへっちゃら。むしろ、指摘者を「自説を理解しない愚か者」扱いする。
外れてばっかりのIT業界の問題点を指摘してないで、出版業界の問題点をきちんと分析できるようになったほうがいいんじゃないかなあ。いや、１０年１５年間外れ続けてきた同じことを言い続けていたり、自分の頭のハエもろくに追うことができないのに、上から目線で他業界を語っていたりするのってよっぽど"ゆでガエル"状態なんじゃあないかな。。。
まとめ
この前のpaizaへの指摘*2の際にも同じこと書いたんですけど、人月商売や多重請負って「受託開発」ってビジネスモデルの結果であって、原因じゃあ無いと思います。
で、これまた「受託開発」はユーザ要求が原因であるわけで。。。
ユーザ企業にだって言い分はあり、「パッケージが機能で過不足があり業務に支障がある」とか、「新規業務のための革新的なサービスを作りたい」なんてニーズがあるから、受託開発を選んだりする場合もある（パッケージで十分じゃん、て場合も多いですけど）。
そういった、ビジネス上の構造を見ていけば、「 IT業界の人月商売、多重下請けがもたらす45の害毒」なんて語るのって、木を見て森を見ずじゃあないかな、と思うわけですよ。問題はそんな局所的な部分じゃないだろと。
短くするつもりが結局４０００字近くまで書いてしまった。。。
反省。
以上
ベネッセ事例の改め。「人」に着目したセキュリティ議論は問題を解決できない
いい具合に容疑者逮捕、報道も一巡し、自分の個人情報も流出したことが確定したことですので、改めて情報をまとめてみますか。
セキュリティ運用のおさらい
まず、セキュリティ運用について。
外部からの攻撃に対して、主に内部者からの攻撃に対抗するためにはセキュリティ運用を行う必要があります。
セキュアなシステム運用を行う上で、いくつかの対応がありますが、オッサンが内部メンバーに対して説明するときには「隔離」「監視」「権限」みたいな概念で説明してます。
隔離は、物理的、論理的に重要なデータを普段使用する場面から隔離してセキュリティを高めること。静脈認証システムの導入、本番との切り離し、GWサーバの導入など、ですね。
監視は、 アクセス監視などを行うことにより、攻撃を速やかに発覚させることでセキュリティを高めることです。侵入検知システムの導入、ログ監視運用の実施、監視カメラの導入など、ですね。
権限は、利用と承認というプロセスを得ることで、複眼的な利用の妥当性チェックを行うだけでなく、権限上位者を限定することで監視や隔離をやりやすくし、セキュリティを高めること。アクセス承認システムの導入、特別権限者に限定した入退出管理、端末利用権限とUSB持出権限の分離など、ですね。
完璧なセキュリティ対策は無い、とよく言われています。技術の進歩により破ることも可能と。
なので、通常は上記のような施策を複数導入することで、「現時点の技術では限りなくセキュリティ突破が困難」な状態にするわけであり、定期的な運用設計の更新が必要となるわけです。
所謂個人情報を管理する企業であれば、上記のセキュリティ運用を最低１重以上設定しているもんですね。
オッサンの会社では、これを４重ぐらいに設定しているので、本番データに触るときは面倒くさいことこの上ないわけです。。。。
ベネッセのセキュリティ上の問題点
じゃあ、上記を踏まえてベネッセのセキュリティ運用の何が問題だったのか、整理してみます。
セキュリティ運用に対して一番正確な言及をしているな、と思ったのは以下の記事。
萩原栄幸の情報セキュリティ相談室：ベネッセの情報漏えい事件を分析 問題点と今後の可能性とは何か (1/3) - ITmedia エンタープライズ
報道から伺えるベネッセのセキュリティ運用は以下のとおり。
- 端末のUSB利用不可制御
- 端末アクセスログの監視
- データアクセス権限者の設定
ただし、いずれも正常に稼働していないことが判明してます。
１．の端末のUSB利用不可制御は、「隔離」に該当する対策です。
実際には、スマートフォンによる接続により回避されてしまっていることが判明してます。セキュリティ上の穴を塞ぎきれてなかったわけです。
２．の端末アクセスログの監視は「監視」に該当する対策です。
実際には、個人情報流出の指摘を受けるまで、全くチェックされてなかったわけです。セキュリティ上大穴が開いている状態です。
３．のデータアクセス権限者の設定は「権限」に該当する対策です。
実際には、委託先の容疑者にも全データアクセス権限が与えられている様に、適切な管理がされておらず、まともな運用になっていなかったことが判明してます。この場合は、本番確認の都度、限定的な参照権限を与えるのが一般的な運用です。セキュリティ上、何も管理されていない状態です。
上記のように、ベネッセのシステム運用は無きに等しい状態であることが判明してます。
これでは、上場会社の個人情報を取り扱う会社として、責任を追求されても仕方ない状態といえるでしょう。
待遇や業界構造みたいなポジショントークは筋違い
さて、前回のエントリでは。「人」に着目したセキュリティ議論は問題を解決しないと言いました。
ただ、案の定というかやはりセキュリティ運用以外のワキの議論が活発になってしまってます。。。
幾つか、はてなで目にとめた記事を挙げさせて頂いてますが、いずれも「下請構造が悪い」「待遇が悪いからだ」みたいな問題点で語られているわけです。
ところが、実際のところ、容疑者の実情見てみますと
名簿業者に売却して計約２５０万円を得たという。捜査関係者によると、松崎容疑者は趣味のパチンコや競馬に金をつぎ込み、消費者金融から借金を重ねていた。月給約３８万円のうち、約１１万円を毎月の返済に充てていたという。
なんて報道がされてます。
月収３８万。。。年収ベースだと、６００～７００万円ってとこですかね。
今回の容疑者は、ベネッセ子会社「シンフォーム」から業務委託された委託先会社社員です。
客先常駐の形をしているためシンフォームとは「派遣」の形で契約を結んだかもしれませんが、委託先会社の中では「正社員」なわけですね。
IT業界、特にSI屋では結構よくある話ですけど、委託先会社のほうが大企業で、実は委託元よりも給料が良い、なんてことあります。
ベネッセの平均給与が７００万、３０代月収が３０万なんて情報*1もありますし、ヘタしたら松崎容疑者の方がベネッセ社員よりも給料が良いんじゃあないかな、なんて思います。
つまり、給与の多寡なんて犯罪を犯すのに関係ないんですよ。
ぶっちゃけて言えば、「待遇を良くしてセキュリティ犯罪を防ぐ」ってのは、セキュリティ運用「監視」が正常に働き、問題があった場合に懲罰を与えることができる運用ができて初めて効果を発揮するんですね。さらに言えば、セキュリティ権限上上位に位置する一部の人間だけ高待遇など、「権限」対策と組合せてメリハリをつけたりだとか。
待遇云々ていうのは、セキュリティ運用が正常に機能して初めて成立する話なんですよ。
今回のベネッセの様な、セキュリティ運用が穴だらけな状態であれば、犯行に対する抑止力が下がってしまい、給料がどんなによくとも犯罪を犯す人間は出てくるでしょう。実際、起きているわけですし。
さらに言えば、待遇云々で改善するためには、待遇と情報流出犯行の損得の比較ができるだけの合理性のある判断力を全ての人間が持ってることが必要。正直、現実的には無理だと思います。そんな合理的な判断ができたら、松崎容疑者はギャンブルで借金はそもそもしないんじゃないかなと思います。
また、情報流出の少なからずの理由として待遇面以外の「職場への復讐」「産業スパイ行為」があることを忘れちゃあいけない。
セキュリティ運用を語らずして、業界構造や待遇の話を語っても、問題の根本解決に向かうのは難しいと思います。
まとめ
事件発生当時に書いたことを繰り返します。
セキュリティ保全のためのIT運用システム（アクセス認証システム、USB利用制御ソフトなど）をきちんと有価なものと認識、導入することで、「人頼りのセキュリティ」から「システム頼りのセキュリティ」に変わらなければ、今後も情報漏洩は起き続けるものと思います。
これ。結局、事件発生から情報が一巡しましたが、オッサンが最初に書いた内容に変わりがないと思ってます。
蓋を開けてみれば、ボロボロのシステム運用だったベネッセ、待遇はそこそこ良かったものの犯行を犯した容疑者、となるわけです。人の問題というのは、ちょっとつらいでしょう。
「人」にフォーカスした議論って、システム運用などに関わったことがない人だとどうしてもポジション持ちやすい話なので、今回のような事例で語られちゃったりするのだと思います。しかし、そういったポジショントークでは問題を防ぐことはできないと思います。
というようなことを、子供の情報を流出させられた怨みつらみのポジショントークで語っているわけです。
余談
そういや、容疑者は３９歳、年収６００～７００万前後でベネッセの仕事。。。
委託先会社を幾つかに限定できそうな気もしますが、間違いだったらアレなんでここでは書かない方向で。
以上
ベネッセからお詫びの手紙が来た
ベネッセからお手紙が来た
上記の件について、ベネッセからお手紙がきました。
【重要】個人情報漏えいについてのお詫び
平素は格別のご高配を賜り厚く御礼申し上げます
このたび、弊社内で調査を行ってきた結果。。。
ほうほう。どうやら、奥様と子供の個人情報を盛大に流出頂いたみたいですね。。。
災難な話です。
さて、情報漏洩したと確定したことで、いくつか気づいたことがあったので、ちょこっとだけメモしておきます。
退会者情報を削除していない
以前、「こどもちゃれんじ」を一時期だけ利用しており、退会したのですが、退会後の情報が残されていたみたいですね。。。
どうやら、ベネッセでは退会した会員情報も残しているみたいです。
そういや、退会後もベネッセからダイレクトメールきてたもんなあ。
子供向けのダイレクトメールが最近増加してた
ここ最近、ベネッセ以外からも子供宛のダイレクトメールが何通か届いてました。
居住市内にある写真スタジオだったりするのですけど、接点が無いところからのダイレクトメールだったので、もしかしたら情報流出したのでは？と疑ってました。
偶然かもしれませんが、もしかしたらジャストシステム以外にも、名簿を購入した業者がいる可能性がありますね。
流出情報に退会情報も含まれているかもしれない
流出した個人情報ですが、肝心のジャストシステムからはダイレクトメールきてなかったんですね。
もしかしたら、見込み客、現会員、退会者ぐらいの情報も流れたのかもしれません。
で、退会者は効率が悪そうなので送ってないとか。
今回のベネッセからの手紙を見ると
今回お客様情報が漏えいしたデータベースの稼働を停止することで、さらなる漏えいを発生させない措置が完了しております。
なんて記載があります。
通常の会員メニューの参照などはできるみたいですし、多分、基幹システムではなく、CRMなどの営業用顧客情報から流出したのかな、なんて予測できます。
まとめ
正直、退会者の情報は、退会と同時に削除しておいたほうが良かったんじゃあないかなって思うんですよ。
知恵袋なんか見ると、「こどもちゃれんじから退会したのにダイレクトメールがとどく」なんてQAが寄せられたりしてますし、今回みたいに情報流出した際の被害が拡大してしまうし。
会員の状態で流出したのなら、まだ多少諦めがつきますけど、退会したあとも個人情報流出の危険性にさらされていたってのもどうかと思うわけです。
まあ、というわけで流出してしまった我が家族の個人情報ですが、ベネッセの対応としてこのまま今回の手紙を送っておしまいなのか、次の動きがあるのか楽しみだったりもします。
さすがにこのまま音沙汰なしってのは無いと思いますけど。
以上
![みんなでつくった しまじろうベストヒット [DVD]](http://ecx.images-amazon.com/images/I/51klmF--CTL._SL160_.jpg "みんなでつくった しまじろうベストヒット [DVD]")
