2012.01.27
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い(7)
■特許庁の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億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視点で書く。
情報共有
入札前の情報漏れにしても、その後のNTTとのやりとりにしても、情報漏洩やそれにまつわる金銭の動きは犯罪だ。けどもそれが行われた動機が私利私欲のためだけとは思えない。
共有されるべき情報が共有できるようにされていない。やりとりできるべき情報ができるようにされていない。必要な情報がちゃんと流れていないから、イレギュラーな方法で流れている。特許庁, NTT, TSOL この三社間のコミュニケーションがどこも投げやり丸投げ気味で、慢性的に情報不足だった感が伺える。ここを改善する必要があるよね。
極秘情報は必要最小限にして、より情報の共有を図るべき、入札前に必要な情報は公開できるようにすべきって報告書でも書かれている。
入札システム
入札での評価が金額偏重で、マネージメント力を評価してなかったって問題。マネージメント力を評価してないのマジやばい。あ、でもマネージメント力を評価するには、全体を理解できる人材が必要だよね。で、次の問題に繋がるんだけど。
上流偏重
報告書だと、上流の話しか出てこない。だから、「設計もろくにできないで55億無駄にしたのか!」って話になるけど、ちょっと待って。設計しかできない人間が山ほどいても捗るわけがないってことなんだよ。特に、このプロジェクトは既存システムを0から作り直すのだから、既存システムをよく理解して、また既存システムにかかわる技術者とよくコミュニケーションが取れて、それを設計に正しく咀嚼できるスキルの持ち主が必要で、設計しかできない人材ではなく全体を理解できる人材が必要だったはず。
既存システムをちゃんと理解できてない人間だらけになったということが報告書でも繰り返し指摘されてるけど、その根底には設計しかできない人間が山ほどいても捗るわけがないという問題があると思うんだ。
時間かけすぎ
6年?そもそも設計に数年ってのが、もうそういうの無理が来てるって感じ?6年経つ間に色々変わっちゃう。
どうしても、がちがちのウォーターフォールでやるなら、もっと受注も小分けにして、まずは既存システムの仕様まとめプロジェクトから開始するのが良かったんじゃないかな。
6年まとめてどん!だと中断の決断もなかなかできないよね。
問題が浮き彫りになったきっかけが汚職ってどうなの
これだけプロジェクトが炎上していたのに、汚職がきっかけで調査が入るまで炎上がちゃんと認知されていなかったというのがやばくね?もし汚職が見つからなかったら、炎上のまま・・・
これは国のプロジェクトだから汚職で厳しい調査が入って、プロジェクト炎上まで色々赤裸になったという見方もあるかも。民間だったらもっとなし崩し的に炎上プロジェクトを続行するケースが多いように思う。
人数増やせば解決できるというやり方
もうね、
TSOLによる設計作業は ,平成18年当初60人体制でプロジェクトをスタートさせたが,翌年初めには遅延が 始まったため,順次増員を行い,同19年3月には200人,同年5月には450人体制とした。
(((( ;゚Д゚)))ガクガクブルブル
TSOLは ,工程の遅れの解消に向けて,大幅な人員の増強でこれに対処しようとし,平成20年11月以降に は 1300人もの体制を整えたが
(((( ;゚Д゚)))ガクガクブルブル
破滅の足音しか聞こえない・・・
人数を増やすと教育コストが増える
あたりまえのこと。TSOLでも仕様をしっかり理解してる人は少数だったのに、増員の9割は下請けだったのだから、さらに破滅の様相が想像できるってものだよ。
下請け構造
大量の下請け同士の連携や情報共有がされていなかった。経験やノウハウの共有がなされていなかった。と報告書にある。なんでこうなっちゃうんだろうな。何のためのプロジェクト管理なんだろ。ノウハウの管理はもっと意識されるべきだよ。
そもそも、開発の遅れは人を増やす事で対処できるものなのだろうか?
人数増やしてプロジェクトが炎上するというのは、お約束すぎる。規模の大小や分野にかかわらず、開発をやった事のある人ならわかると思う。
開発や設計って?という人にもわかりやすいように説明する。
例えば、優れた売れっ子のマンガ家がいて、老練な担当者がついていて、名アシスタントがいて、才能ある若手アシスタントがいて、10人のチームでマンガを描いていたとしよう。一方、大して技術もない凡人を100人集めて、前出のチームと同じマンガができるとかと聞かれたらどう思うだろう?殆どの人はそれは無理じゃない?と思うだろう。1000人でも無理かもしれない。
開発も同じなんだよ、本質的にはね。
でもそう思われにくいのはなんでだろう?それは多分、開発に従事する人にはマンガ家のような才能や際立った技術は必要ないと思われてるからだ。言われた所を言われたようにベタを塗るだけがプログラマの仕事だと思われているからだ。実際それをプログラマなのだと定義している会社もある。技術はお金にならない低俗なものだという偏ったイメージもこの世界には蔓延している。それが上流偏重の問題なんだ。
売れっ子のマンガ家のような設計(マンガで言えばネームや原作)からプログラミングまでこなせる技術者、老練な担当者のようなプロジェクトマネージャ、名アシスタントのような匠のプログラマ、勉強熱心な技術者は実際に存在してる。並以下の人材を倍集めたって100人集めたって彼らと同じものができるわけじゃない。
でも、どんなプロジェクトにもそんなスター的な人材が確保できるとはいえないし、単純な増員で対応できるようにする必要が、日本の大きな会社や大きなプロジェクトではあった。それを可能にするのが分業化だ。工程を徹底的に分業化することで、末端のセクションの習得コストを出来る限り低くし、品質の維持も図る。言い方を変えれば、創作を出来る限り製造にするということ。
それによるデメリットは明確だよね。新しいアイデアが実現されにくくなる。時代の流れの速さに追いついていけない。個々の持っているスキルが生かされない、技術が評価されない。技術者のモチベーションが下がる。なにより、正しい分業化とマネージメントが行われずに盲目的に人数を増やすと、ただただ炎上にしかならないってこと。お金だけが莫大にかかっていくということ。
55億かけてもやめたのは英断だった
これは間違いない。
このまま続けていたら、沢山の技術者の尊い人生がデスマに捧げられただろう。数年間のどろどろの煮詰まった成果物は、黒歴史を語るまいとひた隠しに、更なる問題を生み出しながら使われ続けただろう。考えただけで悪夢だ。
このプロジェクトのやりなおしに、どれだけ前回の経験が生かされるのか、そこにこそ注目していきたいと思う。
1
■http://anond.hatelabo.jp/20120127061544
誰も責任を取らずいかされないから公務員なんだよ
2
■http://anond.hatelabo.jp/20120127091112
公務員だけの問題じゃないでしょ。
アホITに丸投げした特許庁もアホだけど、東芝ソリューションとNTTというか
日本のアホ上流と奴隷下流に分断したIT産業の終焉の図式が非常によくわかる好例。
単なる汚職事件や枝野反省しろや55億賠償しろ、よりも大きな問題が潜んでる。
3
■http://anond.hatelabo.jp/20120127094757
いや、設計しかできないの意味が分からなかった。
簿記会計の処理するために 自分自身が簿記できるくらい勉強する のは 設計に入るし
デザイン周りの処理するのに 簡単なデザインできるくらい勉強するのは 設計に入るし
プロ並みにとはいわんが、業務知識があって、それをベースにそれぞれのプロとコミュニケーションして設計するってのは設計の基礎。
既存システムの巻き取りで、死にながら既存システムのコードを読んでコードレベルで、旧設計を理解するのも設計の基礎
って思ってる俺は間違ってるのか?
(俺自身 大規模設計の時はそれをやるので、最初はプロと作って業務知識を担当者に教えてもらうところから始める)
設計だけの設計がなんか、半完成のプラモを組み立てるみたいなことをイメージしている気がした。(それ設計違う)
設計はそもそも、そのプラモの型を作るほうだよね。
例えが違うかもしれないけど、楽譜が読めないけど指揮者なら出来る、みたいなことをいわれても、指揮の前提には、楽譜が読めて、総譜を暗記していて、その次に指揮ってのがプロでしょ?指揮しかできない。っていわれたら、普通は楽譜は読めるのが前提だよね。一般的には。そうじゃなければ、指揮の真似で棒を振るしかできないという言い方になると思う。
4
■http://anond.hatelabo.jp/20120127104659
んーそれが現状のITは上流はろくにコード読めないのが当たり前になってる
http://el.jibun.atmarkit.co.jp/karyu/2008/10/sepg2-0e2d.html
http://d.hatena.ne.jp/ryoasai/20120125/1327501906
本当はあなたの言うとおり、設計するならそれについて知らないといけないのが当たり前なんだけどそうじゃなくなってるのがおかしい。
だから設計の真似事しかできない、だろうね。それを設計だと言ってる。
5
■http://anond.hatelabo.jp/20120127110723
いちおうフォローしておくと
大規模SI,SE会社でも 部署によってはコードリーディングから始める部署もあるから 会社名というより部署名。
同じ会社でも ビルやオフィスが違うと 設計=なんちゃって設計 だったり 設計=コード読めるだったりする。
その辺が 大規模会社の 問題点かと思う。 できる部署もできない部署も 同じ会社名でよばれるからね。
それで、いや会社に出したんだから会社として責任取れよってお客さんは思うけど、そんなん別部署だし。
NTTや東芝程の大会社ともなれば、部署が違えばもはや別会社。
その辺を踏まえて 設計を発注しないとお客さんはあぶないとおもう。
そうはいっても、 設計=コード読めるレベルの人は高給取り確定で そこらの小さな会社にいるかと言われると・・・
というレベルだし、やっぱり大企業に出すしか無いというのもまたけっこう真実だと思う。日本の場合。
結局、XXさんだから発注したみたいに、人の名前が入らないプロジェクトはやばいよ。
で、いいたかったのは、おれらだけでも、なんちゃって設計を設計と呼ぶのはやめようぜって話でした。ありがとう。
6
■http://anond.hatelabo.jp/20120127112318
そうはいっても、 設計=コード読めるレベルの人は高給取り確定で そこらの小さな会社にいるかと言われると・・・
横だけど、この辺の意図がいまいちわからない。
「設計=コード読める」は「良いエンジニア」の代名詞として言ってるの?
むしろ「何ちゃって設計」と同レベルの悪い例かと思うんだが。
「悪い例」として言ってるんだとすると「高給取り確定」の意味が分からない。
4
■http://anond.hatelabo.jp/20120127104659
正しくはエクセルで仕様書を書くしかできない

コメント
コメントする