2012-01-27

特許庁の55億かけて頓挫したプロジェクトの報告書が面白い

http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース

http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書

まりは、ありがちな汚職だと思えた・・・その巨大プロジェクトの実体は!

1部~2部で内容が重複してるからストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。

これについてのブコメTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視点で書く。

情報共有

入札前の情報漏れにしても、その後のNTTDとのやりとりにしても、情報漏洩やそれにまつわる金銭の動きは犯罪だ。けどもそれが行われた動機が私利私欲のためだけとは思えない。

共有されるべき情報が共有できるようにされていない。やりとりできるべき情報ができるようにされていない。必要な情報がちゃんと流れていないから、イレギュラー方法で流れている。特許庁, NTTD, TSOL この三社間のコミュニケーションがどこも投げやり丸投げ気味で、慢性的情報不足だった感が伺える。ここを改善する必要があるよね。

極秘情報は必要最小限にして、より情報の共有を図るべき、入札前に必要な情報は公開できるようにすべきって報告書でも書かれている。

入札システム

入札での評価が金額偏重で、マネージメント力を評価してなかったって問題。マネージメント力を評価してないのマジやばい。あ、でもマネージメント力を評価するには、全体を理解できる人材が必要だよね。で、次の問題に繋がるんだけど。

上流偏重

報告書だと、上流の話しか出てこない。だから、「設計もろくにできないで55億無駄にしたのか!」って話になるけど、ちょっと待って。設計しかできない人間が山ほどいても捗るけがないってことなんだよ。特に、このプロジェクト既存システムを0から作り直すのだから既存システムをよく理解して、また既存システムにかかわる技術者とよくコミュニケーションが取れて、それを設計に正しく咀嚼できるスキルの持ち主が必要で、設計しかできない人材ではなく全体を理解できる人材が必要だったはず。

既存システムをちゃんと理解できてない人間だらけになったということが報告書でも繰り返し指摘されてるけど、その根底には設計しかできない人間が山ほどいても捗るけがないという問題があると思うんだ。

時間かけすぎ

6年?そもそも設計に数年ってのが、もうそういうの無理が来てるって感じ?6年経つ間に色々変わっちゃう。

どうしても、がちがちのウォーターフォールでやるなら、もっと受注も小分けにして、まずは既存システム仕様まとめプロジェクトから開始するのが良かったんじゃないかな。

6年まとめてどん!だと中断の決断もなかなかできないよね。

問題が浮き彫りになったきっかけが汚職ってどうなの

これだけプロジェクト炎上していたのに、汚職きっかけで調査が入るまで炎上がちゃんと認知されていなかったというのがやばくね?もし汚職が見つからなかったら、炎上のまま・・・

これは国のプロジェクトから汚職で厳しい調査が入って、プロジェクト炎上まで色々赤裸になったという見方もあるかも。民間だったらもっとなし崩し的に炎上プロジェクトを続行するケースが多いように思う。

人数増やせば解決できるというやり方

もうね、

SOLによる設計作業は ,平成18年当初60人体制でプロジェクトスタートさせたが,翌年初めには遅延が 始まったため,順次増員を行い,同19年3月には200人,同年5月には450人体制とした。

(((( ;゚Д゚)))ガクガクブルブル

SOLは ,工程の遅れの解消に向けて,大幅な人員の増強でこれに対処しようとし,平成20年11月以降に は 1300人もの体制を整えたが

(((( ;゚Д゚)))ガクガクブルブル

破滅の足音しか聞こえない・・・

人数を増やすと教育コストが増える

あたりまえのこと。TSOLでも仕様をしっかり理解してる人は少数だったのに、増員の9割は下請けだったのだから、さらに破滅の様相が想像できるってものだよ。

下請け構造

大量の下請け同士の連携情報共有がされていなかった。経験ノウハウの共有がなされていなかった。と報告書にある。なんでこうなっちゃうんだろうな。何のためのプロジェクト管理なんだろ。ノウハウ管理もっと意識されるべきだよ。

そもそも、開発の遅れは人を増やす事で対処できるものなのだろうか?

人数増やしてプロジェクト炎上するというのは、お約束すぎる。規模の大小や分野にかかわらず、開発をやった事のある人ならわかると思う。

開発や設計って?という人にもわかりやすいように説明する。

例えば、優れた売れっ子マンガ家がいて、老練な担当者がついていて、名アシスタントがいて、才能ある若手アシスタントがいて、10人のチームでマンガを描いていたとしよう。一方、大して技術もない凡人を100人集めて、前出のチームと同じマンガができるとかと聞かれたらどう思うだろう?殆どの人はそれは無理じゃない?と思うだろう。1000人でも無理かもしれない。

開発も同じなんだよ、本質的にはね。

でもそう思われにくいのはなんでだろう?それは多分、開発に従事する人にはマンガ家のような才能や際立った技術は必要ないと思われてるからだ。言われた所を言われたようにベタを塗るだけがプログラマ仕事だと思われているからだ。実際それをプログラマなのだ定義している会社もある。技術お金にならない低俗ものだという偏ったイメージもこの世界には蔓延している。それが上流偏重の問題なんだ。

売れっ子マンガ家のような設計(マンガで言えばネーム原作)からプログラミングまでこなせる技術者、老練な担当者のようなプロジェクトマネージャ、名アシスタントのような匠のプログラマ勉強熱心な技術者は実際に存在してる。並以下の人材を倍集めたって100人集めたって彼らと同じものができるわけじゃない。

でも、どんなプロジェクトにもそんなスター的な人材が確保できるとはいえないし、単純な増員で対応できるようにする必要が、日本の大きな会社や大きなプロジェクトではあった。それを可能にするのが分業化だ。工程を徹底的に分業化することで、末端のセクションの習得コストを出来る限り低くし、品質の維持も図る。言い方を変えれば、創作を出来る限り製造にするということ。

それによるデメリットは明確だよね。新しいアイデアが実現されにくくなる。時代の流れの速さに追いついていけない。個々の持っているスキルが生かされない、技術が評価されない。技術者モチベーションが下がる。なにより、正しい分業化とマネージメントが行われずに盲目的に人数を増やすと、ただただ炎上しかならないってこと。お金けが莫大にかかっていくということ。

55億かけてもやめたのは英断だった

これは間違いない。

このまま続けていたら、沢山の技術者の尊い人生デスマに捧げられただろう。数年間のどろどろの煮詰まった成果物は、黒歴史を語るまいとひた隠しに、更なる問題を生み出しながら使われ続けただろう。考えただけで悪夢だ。

このプロジェクトのやりなおしに、どれだけ前回の経験が生かされるのか、そこにこそ注目していきたいと思う。

追記

時間ができたら後で読む

特許庁業務・システム最適化計画」(改訂版)について

http://www.jpo.go.jp/torikumi/system/system_optimize_re.htm

実際の業務の内容がある

http://myatsumoto.hatenablog.com/entry/2012/01/26/082554 良いまとめ

1/28 NTTNTTD に修正。

  • 誰も責任を取らずいかされないから公務員なんだよ

    • 公務員だけの問題じゃないでしょ。 アホITに丸投げした特許庁もアホだけど、東芝ソリューションとNTTというか 日本のアホ上流と奴隷下流に分断したIT産業の終焉の図式が非常によくわ...

      • いや、設計しかできないの意味が分からなかった。 簿記会計の処理するために 自分自身が簿記できるくらい勉強する のは 設計に入るし デザイン周りの処理するのに 簡単なデザイ...

        • んーそれが現状のITは上流はろくにコード読めないのが当たり前になってる http://el.jibun.atmarkit.co.jp/karyu/2008/10/sepg2-0e2d.html http://d.hatena.ne.jp/ryoasai/20120125/1327501906 本当はあなたの言うとおり...

          • いちおうフォローしておくと 大規模SI,SE会社でも 部署によってはコードリーディングから始める部署もあるから 会社名というより部署名。 同じ会社でも ビルやオフィスが違うと ...

            • そうはいっても、 設計=コード読めるレベルの人は高給取り確定で そこらの小さな会社にいるかと言われると・・・ 横だけど、この辺の意図がいまいちわからない。 「設計=コー...

        • 正しくはエクセルで仕様書を書くしかできない

  • 「人数増やすと…」について補足。 http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1 スケジュールが遅れているソフトウェア開発プロジェクトにさらにプログラマを追加すると...

  • はてぶのコメント見てると、「それでも1400人以上の雇用は国に守られた」というたぐいのものがいくつかあったけど、 確かにエクセルの関数すらよくわかならないけど方眼紙にするのは...

  • 多段下請け構造の下部では、技術持っていてもお金が入ってこない。 そんなんじゃ、一部の変人を除いて技術力で食おうって気は失われていく。 ちょっと勉強してこうしたらよくなるの...

  • お金持ちに大量に触れて気づいた8の共通点 http://anond.hatelabo.jp/20110825105018 3317users 生活・人生 2011/08/25 --------------------- 自分でWEBサービスを作りたいと思っている人へ http://anond.hatelabo.jp/201...

  • 今年度 総合 タイトル ブクマ数 日付 カテゴリ 1 14 先日倒産したメモリメーカーの友人と飲んできた話 2073users 2012/02/29 コンピュータ・IT 2 15 【2012超まとめ...

    • 前提 「iPhoneアプリを作りたいなら」ではない。 「売れるアプリを作る企画力」や「イケてるUIを作るデザイン力」なしに、「アプリ開発に必要なObjective-Cの技術力」だけあっても意味...

  • 今年度 総合 タイトル ブクマ数 日付 カテゴリ 1 (14) 先日倒産したメモリメーカーの友人と飲んできた話 2085users 2012/02/29 コンピュータ・IT 2 (15) "Hello world!" ...

  • 今年度 総合 タイトル ブクマ数 日付 カテゴリ 1 (14) 先日倒産したメモリメーカーの友人と飲んできた話 2085users 2012/02/29 コンピュータ・IT 2 (15) "Hello world!" ...

  • ランク タイトル ブクマ数 日付 カテゴリ 1 急がばまわれ式・堅実で一番効率的な英語の勉強法 7900users 2009/10/26 22:02 学び 2 20年来のつらさがほぼ消えたことにつ...

  • ランク タイトル ブクマ数 日付 カテゴリ 1 急がばまわれ式・堅実で一番効率的な英語の勉強法 7900users 2009/10/26 22:02 学び 2 20年来のつらさがほぼ消えたことにつ...

  • ■特許庁の55億かけて頓挫したプロジェクトの報告書が面白い http://anond.hatelabo.jp/20120127061544 上記では人気マンガ家の制作を例に、 すべてをトータルで把握できる人間が必要みたいに書...

  • ■http://anond.hatelabo.jp/20120229223543 半導体は日本の国策みたいなもんだかんな ■http://anond.hatelabo.jp/20120926165407 業者宣伝乙って感じだけど有益な情報もけっこうあるかねいいね ■http://anond.h...

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん