まだ続いていたんだという、驚き

　特許庁は２４日、２００６年から始めた新たな情報システムの開発を中断することを決めた。これまでに５５億円の予算を投じたが、別のシステムを考える。枝野幸男経済産業相は「大変申し訳なく思う」と謝った。

　新システムは特許の出願や登録に使い、中国の特許情報を調べられ、国際化への対応もねらっていた。開発の遅れで、特許を申請する利用者は、機能の低い古いシステムを使い続けることになる。特許庁は中国の情報検索などができる最低限のシステムに絞り、別の方式で開発する。

　新システムの開発期間は０６年１２月から１４年１月。設計を東芝ソリューションと、開発管理をアクセンチュアと契約した。

　開発の遅れは、主に設計の不備が原因。特許庁は検証委員会を設け対応を考えてきたが、委員会は２３日、中断を求める報告書をまとめた。業者が今までに作ってきた設計情報は、特許庁の別のシステム開発に生かしていくという。
朝日新聞デジタル：費やした５５億円、水の泡に　特許庁がシステム開発中断 – ビジネス・経済

この記事を見てまず驚いたのは、この開発はまだ続いていたんだ! ということでした。
「まだ」というのは、今を去ること2年前、特許庁のシステムはこんな事件で話題になっていました。

志摩被告の起訴状によると、２００５年８月ごろから昨年１１月ごろにかけ、新システム設計開発事業に関する情報を伝える見返りとして、ＮＴＴデータで当時、統括部長兼営業担当部長だった沖被告から計約２５０万円分のタクシー代をわいろとして受け取った、としている。
収賄罪で技官を起訴　特許庁汚職 – 47NEWS（よんななニュース）

特許庁発注のコンピューターシステム設計開発事業をめぐる汚職事件で、収賄罪で起訴された同庁技官のほかに職員３人が、複数のシステム開発会社側から飲食接待やタクシー代の肩代わりなどで計約９４万円近くの利益供与を受けていたことが２０日、分かった。
特許庁職員３人に利益供与　飲食、タクシーで９４万円 – 47NEWS（よんななニュース）

実はこの事件を受けての調査報告書では、利益供与問題の再発防止策と並んで、開発状況の調査も行なっています。

2010年8月時点での調査報告書の内容

調査報告書 特許庁情報システムに関する調査委員会(PDF注意)
http://www.meti.go.jp/press/20100820003/20100820003-2.pdf

利益供与・文書流出の再発防止(事実解明チーム)

まとめは、P.34からになります。
最初の2項目は「倫理意識の徹底」「情報管理の整備強化」とありがちな内容でおもしろみがありませんでしたが、3つめが「入札手続きの改善」とあってなかなか読ませます。(P.36から)

供与した事業者の側には、短い提案期間でよりよい提案書をまとめあげようとする動機があった。
収賄した3職員は、受注のプロセスには携わっていなかったのですが、より良いシステムを作るために外部の専門家に意見をもらいたいと考えていたこと、背景にあるんだよ…という内容です。

よりよいものを作りたいと思いに、入札・応札のルールが足枷になっているのだったら、出すべき情報はとっとと出して、接待して情報を得ようとするようなことはなくすようにしたらどう? という、このような調査報告書としては、わりと具体的な提案がされている印象を受けました。

とはいえ、今となっては、この点はあまり重要ではなくなっていますね。

開発状況の分析(技術検証チーム)

この時点で喫緊の課題となっていたのは、開発の遅れということで、上記の利益供与の再発防止とは、独立した調査として、TSOLによる設計と、アクセンチュアによるプロジェクト管理、特許庁の取り組みについて分析が行われています。(P.63から)

「提言」という形をとっていますが、結論としては、

• 発注者の特許庁は責任感持って仕事しろ(P.68)
• プロジェクト管理支援のアクセンチュアは特許庁とTSOLの合意の上、対策案を実施させるまでが仕事だろ(P.72)
• 設計一次請けのTSOLは、今まで設計してきたメンバーで固定しろ(P.75)
• 特許庁は現行システム担当のNTTデータに対して、必要な情報を提示するよう、働きかけるように(P.76)
• 再開するなら、特許庁中心にプロジェクト憲章を作成して、役割分担と責任を明確にしろ(P.78)

となっています。

「技術」検証というわりには、プロジェクト管理に関する指摘が目立つ内容になっています。
外部の人が調査しても、中身が合っているかよくわからないから「品質管理プロセス」へのツッコミが多くなったのでしょう。
こんな状況だったので、てこ入れして、どうにかなりそうならGo、どうにもならなそうだったらSTOPの判断をすることになるだろうな。設計の品質もぼろぼろみたいだし、STOPがかかるんだろうな。
と思っていた次第です。

2012年1月時点での調査報告書の内容

技術検証報告書 ～フォローアップ結果とりまとめ～ (PDF注意)
http://www.meti.go.jp/press/2011/01/20120124001/20120124001-2.pdf

再開に向けて動き出したのでしょうが、それから、1年半経過して、やっぱダメ、ギブアップということになりました。
上記報告書で挙げられた「提言」に対して、ぜんぜん取り組めていないよね、という内容になっています。
それだけでも残念な事態ではあるのですが。

そもそも7年かけて開発してたら…

新聞報道だと、設計担当のTSOLの品質が悪者にされていますが、実際これだけお金をかけて、まだ動くものが作れていない…というのは、全部一括ではなくて、機能別に発注するとか別のやりようがあったんじゃないのか?という疑問です。

だって、そもそもの予定では丸7年もかけて、開発しようとしていたんですよ。
7年たってたら、外部環境は相当変化していますよね。

その点に関しては、報告書のpp.8-9が答えてくれています。

とりわけ国際的環境は大きくかつ急速に変化しており、その結果、早急にシステム構築の必要な新たな政策項目や、対応優先順位を上げなければならない政策項目が顕在化しつつある。例えば、特許審査においては外国文献検索の重要性が急激に増大しており、外国文献に対応できる新たな検索システムの構築が喫緊の課題となっている。

こうした外部環境の変化を踏まえると、プロジェクトの再開に当たり、現行の一括開発手法を引き続き採用するとなると、最終稼働までの間、今後複数年にわたって政策項目の実現が先送りとなってしまうことに加え、これまで同様、遅延等のリスクを伴う可能性も大きい。
そこで、特許庁において、プロジェクトの再開に当たっては、特許庁ＣＩＯ主導の下、このような外部環境の変化を取り込んだ改定最適化計画を策定するとともに、一括開発手法にこだわらず、実現性の高い新たな手法を採用することも視野に入れて今後のプロジェクトの進め方を検討する必要があると考えられる。

一括開発手法にこだわらないという、上記の結論に2010年の報告書の時点で至っていれば、55億円かけて、「設計書」なるものが大量に作成されて、動くプログラムができてないなんてことになってないのではないかなと考えるわけです。
特許をとりまく状況を受けて、優先順位が高い機能から細切れにして開発していくようにすれば、よかったんじゃないかなーと。

でも、ここでキッパリやりなおすのは英断だと思いますけどね。
埋没費用 – Wikipedia
http://ja.wikipedia.org/wiki/%E5%9F%8B%E6%B2%A1%E8%B2%BB%E7%94%A8

最後に

身近なところで、5年かけて開発して、動いているけどゴニョゴニョ…な例を聞いていたので、明日は我が身の思いとともに、そこそこ読みこんでしまいました。報告書を読んでなにを感じるかは、その人の経験に依存する部分も多いと思います。

外部要因で優先順位がころころ変わるなら、それに対応する手法を、契約、意志判断、設計・開発でとるべきなんだろうな…ということを、これからの私の仕事でも念頭に置いておきたいと思います。

Takuya Y./ベン @atauky

ついったーでは言わなそうなこと。「過去ログ読め」(2009-08-17 20:12:15)

link

との携帯からのつぶやきに思いがけずたくさんのReTweetをいただきました。
もとの発言が2ちゃんねるで良く見るものだったせいか、反応も2ちゃんねるばかりになりましたが。
では、なぜ2ちゃんねるでは良く見かける発言が、Twitterでは見かけないのでしょうか。
考えてみたいと思います。

システムの特質

「今」がすべて

最初にあげた「過去ログ読め」は、タイムラインがどんどん流れていくというリアルタイム性から、まず、ありえない発言だろうと思ってつぶやきました。
ですが、将来的には、過去ログを漁って「こんな発言してやがった」とかする輩も出てくるかもしれません。

ブロック可能

nowri @konity524

「半年ROMってろ！」も追加ｗ RT @minol: ｗｗｗ RT @naosukebe: 確かに！ RT @atauky: ついったーでは言わなそうなこと。「過去ログ読め」(2009-08-17 20:25:49)

link

つぶやいてなんぼのTwitter。うざければ、ブロック・リムーブで見えなくなるから一安心?

あなたの見ている世界と私が見ている世界は違う

神野奈緒 @kaminonao

「今北産業」RT @akiichi: 「名無しに戻る」「氏ねじゃなく死ね」「吊ってくる」 RT @korori39: ｢半年ROMれ｣ RT @atauky: ついったーでは言わなそうなこと。「過去ログ読め」 【8/22 梅田で梅酒オフやんよ！興味があったらＤよろ】(2009-08-17 20:26:07)

link

「今北産業」は「今きた。三行でいままでの話をまとめて」の意味です。

掲示板においては、「みんな同じ内容スレッドを見ている」という前提があるからこのようなことが言えますが、Twitterではそんなこと書かれても、あなたのタイムラインわからない。

やさしい振舞い

	ぶれたん @Blaze_nico	「ゆとり」 RT @kaminonao: 「今北産業」RT @akiichi: 「名無しに戻る」「氏ねじゃなく死ね」「吊ってくる」 RT @korori39: ｢半年ROMれ｣ RT @atauky: ついったーでは言わなそうなこと。「過去ログ読め」 【8/22 梅田で梅 …(2009-08-17 20:27:09)	link
	カワムラヨシヒロ @4416	確かに！ RT @aki_55p: これが助け合いの空気を生む一端なのは確か！ RT @RT_report: RT @atauky ついったーでは言わなそうなこと。「過去ログ読め」(2009-08-17 20:31:09)	link
	天枷コロリ @korori39	｢ggrks｣ RT @akiichi: 「名無しに戻る」「氏ねじゃなく死ね」「吊ってくる」 RT @korori39: ｢半年ROMれ｣ RT @atauky: ついったーでは言わなそうなこと。「過去ログ読め」 【8/22 梅田で梅酒オフやんよ！興味があったらＤよろ】(2009-08-17 20:18:56)	link

「ggrks(ググれカス)」などの罵声はあまり見かけないですね。匿名掲示板においては、罵声をあびせても発言主がだれであるかわかりませんが、罵りのようなネガティブな発言を繰り返す人はTwitterにおいてブロック & リムーブの憂き目にあうことでしょう。

おそらく、ggrksではなく

Takuya Y./ベン @atauky

ついったーでも使いそう「ググれカス」ただしオブラートにくるんで。「○○と××って言葉で検索すると見つかると思います」(2009-08-17 20:22:16)

link

このような提示のしかたになるのではないかと想像します。解決策を示していて、まだしもやさしさがあります。

IDレベルではありますが、継続して発言主が特定できるという仕組みが「見られている」という意識を生むのでしょうか。
IDを変えるとなると、別のIDを取得の上、フォローしなくてはいけないですからね。BOTでも作らない限り大変な手間です。

ただし、1万人ぐらいからフォローされているくらいの人になるとゲリラ的に@で罵声を浴びせることは可能なような気がします。特定するのも面倒ですしね。

まとめ

2ちゃんねるのような匿名掲示板と比較して

• 掲示板では同じスレを見ている前提、Twitterでは同じタイムラインを見ている人は(まず)いない
• TwitterではユーザIDが固定、変更するのが面倒
• 自分の発言も含め過去ログを追いづらい

といった特徴があります。
「スレ」のタイトルと>>1 の発言という「話題」を中心に構築される掲示板の世界とは違う展開を見せるわけです。
「人」を中心としたサービスなので、あいさつのやりとりもあるわけですね。

問題解決のフレームワークとか言われても、ちっともピンとこなかったのですが、「問題を解決する流れ」というのはだいたいこんな感じではないか..というのを考えたので、まとめてみました。

ただし、システムインテグレータ(SIer)勤務で、システム障害の対応だったり、維持管理をしていての問題解決だったりするので背景は相当かたよっているとは思うのですが。

7つのステップ

図は、Xmindで作成しました。

• 問題
• 仮説
• 調査
• 検証
• 解決
• 実行
• 評価

のステップです。

実践すると、たぶんこんな感じ。

• 問題: 夜間バッチ処理が完了すべき時間までに完了しない
• 仮説: どこかのジョブで処理に想定外の時間がかかっているんじゃない?
• 調査: ジョブごとの開始終了時間の取得→時間がかかっているジョブを確認
• 検証: 時間がかかっていることを確認
• 問題: なぜ時間がかかっている?
• 仮説: 非効率なSQLになっていないか?
• 調査: SQLの詳細情報を取得
• 検証: 負荷の高いSQLを確認する
• 解決: 負荷の高いSQL効率のよいものにして、時間短縮をはかる
• 実行: 本番環境へリリースする
• 評価: 処理時間の短縮したか確認する

問題〜検証までが、問題点を明らかにするためのアクションになります。
具体的な「解決」につながるようになるまで、問題〜検証を繰り返します。
検証で仮説が「はずれ」となれば、新たな仮説をたてて、調査〜検証を行います。

重視するポイント

上の7つのうち、システムのお守りをしていて重要だなと感じるのは、

• 仮説
• 調査

です。

特に仮説のほうが重要です。
仮説を上手に立てられると、問題解決までの時間と作業が少なくてすみます。
プログラムが想定どおり動かない原因を解決するにも、目のつけどころが違っていて、いつまでたっても解決できないこともあります。
ピントのずれた調査はいくらやっても徒労です。

また、現状をおさえるための調査ツールをたくさん知っていることは、調査時間の短縮につながります。

• ネットワークの問題?→ping,traceroute, wireshark, サーバ上のパケットキャプチャーツール
• サーバのリソース?→vmstat、sar、df

などなど。
専門家にたよるにしても、こんなこと調べるための手段はある?といった質問ができると、回答が早いです。

「仮説」と「調査」がうまくなるには、システムがどう動いているか仕組みを知る必要があります。
「解決」について承認を得るスキルというのも顧客に説明する立場として重要に思えます。
しかしながら、しっかりした「仮説」と「調査」に基づいた説明ができれば、顧客が感じる納得感が大きくなると思いますので、結局「仮説」と「調査」が大事かなと考えます。

最後に

コンサルタントの思考の流れというのも、もしかしたら、たいして変わらないのかな..と思いました。
現状を知り、解決策を導くということには変わりませんが、

• 問題点を明らかにするまでのツールが違う
• 「世の中」の仕組みを知らなくてはいけない

というのがポイントなのかもしれません。

自分が昔習った病院は、「部分の専門家」を生み出す方針だった。
患者さんの方針は上司が決めて、研修医は、まずは手を動かす。
胸水のたまった肺炎の人が入院する。チェストチューブを入れるとか、 人工呼吸器をつなごうだとか、そういう決断は上司が行ってくれて、 研修医は上司の監督下に、手を動かす。
手が動くと、なんだか上手になったようで、やる気が出る。「一人前」になった気がする。
そればっかりやってると、「治る」というのは、部分を積んだ先に、いつの間にか降ってくる何かみたいに 思えてくる。目をつぶって、ひたすら目の前の「煉瓦」を積むことだけに没頭していると、 いつの間にか、そこに「家」ができあがるような。
もちろんそんなことをしても、できあがるのはせいぜい「壁」で、本当は、 指揮をする「大工」がいて、はじめて家が建つんだけれど、「煉瓦の専門家」だった自分には、 それが見えなかった。

もうすぐ家が建たなくなる – レジデント初期研修用資料
http://medt00lz.s59.xrea.com/wp/archives/176

なんか、今の自分の職場のことを言われているようでぎょっとしました。
ある情報を右(A社)から左(B社)に流すようなGWシステムの構築を今担当しているのですが、情報の流れ全体をおさえて会話できる若手がいないように感じます。
「ネットワークの専門家」や「DBの専門家」は、自分の仕事に必要な情報が降ってくるのを待っているだけ。
システム全体のイメージを描いて、各専門家に仕事を渡していく人(元エントリの「上司」)のスキルを身につけようとする人が、若手にはいないように感じています。
まず、会社全体として、「専門家」を作る方向に傾いているようです。

みんな縫えるし切れるし薬も知ってるし、論文だって読む。「手を動かす」ことだったら、 たいてい何だってできるはずなのに、怪我した人を診て、その人が「治ったイメージ」を想像して、 そこまでの道筋をつける、そうした訓練をだれもうけていなかったものだから、 救急外来は最初の頃、まわらなかったんだという。
現地にはそれでも何人か、道筋をつけられるベテランがいて、もちろん現場は動いたのだけれど、 その人たちは「取り替え」が効かないものだから、交代できなくて、ずっと現場に張り付いていたのだと。
あと何年かして、ベテランが現場からいなくなると、このときの状況が再現されそうな気がして、けっこう怖い。

もうすぐ家が建たなくなる – レジデント初期研修用資料
http://medt00lz.s59.xrea.com/wp/archives/176

「サーバの専門家」、「DBの専門家」、「ネットワークの専門家」….は、構築が始まってしまえば、手を動かすことはできるんです。
でも構築にいたる道筋をつけることができない。
ホスト→オープン化の流れを、最前線で受けとめることになった、ベテランの方はこの筋道をつける作業に長けているように思います。
そして、今も最前線にいます。
この人たちが定年などでいなくなる前に、こういうスキルを身につけた人を十分確保できるのか..

まず、自分自身が「上司」スキルを身につけられるように取り組んでいきます。
私自身は「手先が不器用な自分でもなにかを創る仕事ができるかもしれない」という思いで、今の会社に入りました。子どものころ、家を建てていた大工さんと棟梁さんのイメージがあったのかもしれません。
その思いに正直に生きたいと思います。

ブログ専用プラットフォーム「JournalSpace」（初めて聞く名前）が、バックアップを取ってないメインのデータベースが消去され、サービス停止に追い込まれた。JournalSpaceブログによると、どうやら会社に恨みをもつ元社員が悪意ある行為を働き、結果としてデータベースが上書きされたものらしい。

JournalSpaceの悲劇：バックアップ取らずに全データ喪失、倒産
http://jp.techcrunch.com/archives/20090103journalspace-drama-all-data-lost-without-backup-company-deadpooled/

Here is what happened: the server which held the journalspace data had two large drives in a RAID configuration. As data is written (such as saving an item to the database), it’s automatically copied to both drives, as a backup mechanism. The value of such a setup is that if one drive fails, the server keeps running, using the remaining drive. Since the remaining drive has a copy of the data on the other drive, the data is intact. The administrator simply replaces the drive that’s gone bad, and the server is back to operating with two redundant drives.

http://journalspace.com/this_is_the_way_the_world_ends/not_with_a_bang_but_a_whimper.html

RAID1(ミラーリングによる冗長化)をデータのバックアップとして使っていたため、サービス復旧不可能になったというお話し。
RAID1のミラーリングはディスク障害の対策にはなっても、故意にデータを消去するような
rm -rf /
が相手ではデータが消去されてしまいます。

個人的にも社内OAのシステムで、元システム管理者に全削除の攻撃を喰らったことがあるので、それ以来データのバックアップにはことさら気を遣っています。
せめて、前日の状態に戻せないとつらいですね。

子どものころ、「ケンちゃんラーメン」というインスタントラーメンが売られていました。
このCMがいつまでたっても「ケンちゃんラーメン 新発売!」と言っていたので、当時の小・中学生はネタにしていたものと想像します。

最近これと似たものを見つけました。
「新1000円札」対応の自動販売機です。いつまで「新1000円札」なんでしょうか。
もう「新札」発行から4年経過しているんですよね。
E券とかD券とかで周知徹底したほうが古いお札の対応も切り捨てやすいと思うのですが。

日本銀行券 – Wikipedia
http://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E9%8A%80%E8%A1%8C%E5%88%B8

さて、自分の仕事を振り返ると、「次期システム」という言葉もやっかいです。
現在担当しているプロジェクトが、まさにこんなネーミングです。
今や「次期の次期」の構築になっているんですが…
「三次オンラインシステム」というように「○次」としたネーミングのほうが、後から振りかえったときにわかりやすいですね。

「システムに歴史あり」で、どういう経緯で発展してきたかを整理すると、「当時の合理性」というものが露になります。当時としてはいい選択だったとしても、現状では正しいとは限りません。
技術も発展しているのですから。

どこからつっこめばよいのか…

新生銀システム改竄のインド人を逮捕　「正社員になれないのは人種差別」と腹いせで – MSN産経ニュース

http://sankei.jp.msn.com/affairs/crime/080716/crm0807161151017-n1.htm

採用を断られた腹いせに新生銀行の社員用ウェブサイトを改竄（かいざん）したなどとして、警視庁ハイテク犯罪対策総合センターと原宿署は不正アクセス禁止法違反などの疑いで、インド国籍で東京都江戸川区清新町、元派遣社員、アビナッシュ・シャルマ容疑者（３２）を逮捕した。

調べでは、シャルマ容疑者は今年２月１８日から３月１１日までの間、以前、新生銀に派遣社員として務めていたときに入手していたＩＤとパスワードを使い、６７回にわたって新生銀の内部ネットワークに不正にアクセス。

４回かけて約２６００件のファイルを削除するなど社員用ウェブサイトを改竄した上、自分の犯行が発覚していないか確認するため、６３回にわたって同社幹部のメールをのぞき見た疑い。

シャルマ容疑者は平成１６年に、インドにある新生銀子会社から派遣され、約３年間、新生銀でシステムエンジニアとして勤務。「自分のレベルを上げたい」と１９年１０月に退社して別の金融機関に転職したが、今年２月ごろ、人員削減のため辞職勧告を受けた。そこで、再就職仲介会社を通じて新生銀に正社員採用を申し込んだが断られた。

「日本人じゃないから採用されず、人種差別を受けた」と思いこんで犯行に及んだという。

シャルマ容疑者の犯行により、新生銀の内部システムは約１５時間停止。社員用ソフトが使えなくなるなどの被害が出た。顧客の情報流出や金銭的被害はないという。

まず、
・退職した社員がどうやって内部ネットワークに侵入したのか
かなぁ。

勘定系などお金のデータがあるネットワークは、それなりに分離されているはずで、パスワード変更の運用もしているはずです。さもなきゃ金融庁との勝負でボロ負けしてしまう。

以下、想像で語ります。

今回は情報系と呼ばれる、勘定系(基幹系)のデータを集計・加工して社員が使えるようにするシステムが被害に遭っているのでしょう。
このへんのシステムだと、VPN経由でシステム担当者がメンテできるようになっていても、それほど違和感はないように思います。

足がついたのも、外部と内部を接続するVPNの受けサーバの履歴だったりするんじゃないかなぁ。
で、あわててアカウント消したりなんかして。

相対的に重要度が低いと思われている情報系のシステムは、パスワード管理なんかもけっこういい加減だったりするのかもしれませんね。人の出入りが激しいと、共用のユーザIDとちっとも変更されないパスワードで運用されていることも充分ありえます。

・派遣社員は信用できない論

今回は外からの侵入によりやられていますが、内部で”正社員”の管理者が悪意をもって、「rm -rf /」的行為をすると同じことが発生します。結局、管理人を信用しないときのコストと信用したときのリスクをどう考えるかの問題です。
「派遣社員を信じるなんて」という人は、正社員が同じことをやったらなんて言うのだろう。
だとしたら、正社員も疑ってかかるべきなんじゃない?

・日本人じゃないから正社員になれない

システム担当者だと日本人も正社員として雇ってもらえるのかどうか。