アカウント名:
パスワード:
毎日の記事にこうある。
- 同庁の審査部門などから、機能の追加要求が断続的に寄せられたことが混乱に拍車をかけた...
- 特許庁が発注段階で、どういうシステムが必要かを詳細まで文書に落とし込む『見える化』をしていれば、ここまで開発が混乱することはなかった...
#なんだかなあ。
予算の段階から、プロトタイプ作成を分けておくのはどうですか。お役所ならではの、予算が初めにあって、そっからモノをいきなり作っちゃうから失敗しちゃうんじゃないかな。
初年度: XXシステムのプロトタイプ開発。予算NNNの範囲でXXのプロトタイプを開発。 プロトタイプによるユーザー調査から、本ちゃんシステムの要求機能、予定価格の見積もりを作成次年度: XXシステムの入札、本開発。
ユーザーは実物を見るまで(使うまで) 間違った意見しか言わない、ぐらいに考えとくべき。実際に動くプロトタイプを見せて、使わせなければ、良いシステムなど作れるわけがないと思います。
ならばこそプロトタイプ開発のみで予算を立てる。プロトタイプは本ちゃん開発と違って、予算を決めておかないと際限なく工程が膨らむものなので、予め予算額が決まっているお役所的な配分はむしろ都合がよい。お役所的発注方法と非常に相性がよい、とも言えるでしょう。
予算の範囲内で満足いくプロトタイプが作られれば、本ちゃんシステムの要求定義はプロトタイプをもとに過不足なく定義すればよいだけだし、実際に作ってからの話だから本開発の予定工事価格も算出しやすい。仮に初年度予算では満足いくプロトタイプを作れなかったとしたら、次年度でもう一度、別のプロトタイプを作り直せばいい。本開発は、納得いくプロトタイプを作れてからで十分です。
>> 仮に初年度予算では満足いくプロトタイプを作れなかったとしたら、
という仮定が、現行のお役人様ルールで通用するかが最大の問題ではないでしょうか?
というか、会計検査院が納得するかどうかが最大の問題かと
はい。仰るとおりだと思います。 > 現行ルール&会計監査員
実際、懸念事項は多々あるでしょう。私も色々思いつきましたが、そういったデメリットを踏まえても、やっぱりプロトタイピングを導入する(導入のために手筈を整える)メリットは大きいのではと思うんですよね。
・プロトタイプ(必ず捨てる)というものに対する予算が付きにくいかもしれない-> いきなり開発するよりお得である、ということをどれだけ理解してもらえるかですね。
・そもそもプロトタイピングしたからって、ちゃんとしたもの作れる保証がない-> 逆に、プロトタイプで作れないなら、いきなり本ちゃんで作れるわけないかと。であれば撤退時の被害が少ないので、失敗したらむしろプロトタイピングにして良かったことになります。お役人的にも言い訳しやすいですよね!「本来困難極まるプロジェクトでしたので(俺は悪くないが)被害を最小限にする方法を選択しました(プロトタイピングじゃなきゃもっと大変だったんだぜ)」
・プロトタイプ運用に付き合わされる現場から文句が出る-> 最終的に使いやすいシステムができれば現場にとって一番得であることを納得させる特に今回のような、運用がわかりにくいシステムでは現場へのヒアリングのため特定担当者ばかり負荷がかかる(結果として十分ヒアリングできない)という問題があります。プロトタイプという誰でも目に見えるもので「深く狭く」から「浅く広く」へ負担を下げれることは大きいと思います。
・プロトタイプは裏金作りに利用しやすい-> そこはお役所の良心しだいですけど・・。というか裏金なら別にプロトタイプじゃなくても今でも普通にゴニョゴニョ・・・
ともあれ「コンクリートから人へ」と言うなら、コンクリートに合った方法(ウォーターフォール)でなく人、つまりソフトウェアに合った方法へと変えるべき、と思います。
工事という意味でソフトウェアがコンクリートに劣るところは、複雑で完成像が見えないこと。逆に優れているところは、捨てる費用がほぼゼロな点。建物は作っちゃうとなかなか壊せないですから。納得のいくものができるまで、作ってはクシャクシャに丸めてポイ、とするのがソフトウェアの正しい作り方です。(まあ実際はハードがなきゃ動かない、のはさておき)
個人的に金言としている「銀の弾丸はない」との言葉どおり、プロトタイピングが向くものと、ウォーターフォールが向くものとそれぞれあるはずです。少なくとも現状のウォーターフォール一択よりは、幅を広げるに超したことはないのではないかと。
#長文失礼
みんな釣られすぎ。
これは、来年度(平成25年度/2013年度)の予算確保を確実にするために、庁内から打ちあげている、というのが時期的にはオチ。
10月の会計検査院の記事 [srad.jp]の時点からほとんど情報は増えていないし、計画そのもの(主には、2022年以降に新システム完成)は、既に2012年9月には表に出てる。
この時点で、およそ5年毎の2期(第I期と第II期)にわけて開発することになっているので、10年かかるのは、羞恥周知の事実。
本計画では全体をおよそ5年毎の2期に分ける(2.2 参照)。前半約5年を第Ⅰ期とし、まずは特許・実用新案系のシステムの一部につき、システム構造を簡素化し、中核的業務についてリアルタイム化を実現する。並行して、特許庁システムの処理・データの内容や各システム間の連携関係等につき、綿密な分析調査を行う。後半約5年は第Ⅱ期とし、特許・実用新案系のシステム構造の簡素化に引き続き、技術的難易度が相対的に高い意匠・商標系のシステムについても簡素化を進め、もって、全業務システムのリアルタイム化を実現する。
ちなみに、上でパブリックコメントに出ている案については、既に、政府全体としても確認していて、これに対して、「各府省情報化統括責任者(CIO)補佐官等連絡会議」から出ている助言がこちら。
プロジェクトの再開に当たっては、各府省におけるシステム開発の事例等を参考にし、当該プロジェクトを適正に進めるための体制を検討するとともに、事前のリスク分析を含むプロジェクト管理を的確に行うことが必要。
一般的な論調としては「へーなるほど」なんだろうけど、この記事で、
庁の情シスか会計・官房から、毎日新聞にお願いが飛んだんだろうなあ。(ちょうど、政権交代で予算をつくりなおしているわけで。)
それでは、年末の道路工事と同じレベルですね。
地球温暖化とか、エコ・ブームだの、プラズマ・なんたら、マイナスイオンとか、ユビキッタ(だっけ?)とかの予算ちょうだい(ぴよぴよ)ごっこと同レベルという認識でよいでしょうか?
# 多少、間違ってても、ツッコミを入れるほど、暇な人はいないと信じてるし。
・もともと特許庁はシステム更新を真剣には考慮していなかった。・が、政治的理由により更新が行われることになった。・現行システムは古くから使われているもので、拡張に拡張を重ねた複雑怪奇なものであった。・新システムの開発に当たっては現行システムの解析から始める必要があった。・しかし特許庁に全容を知るものはいなかった。・そこでインタビューから始めることにしたが、TSOL(と外注先)のレベルがイマイチで、いつまで経っても全容がつかめなかった。・そもそも更新の必要性をそれほど感じていなかった特許庁は、新システムに求めるものを具体的に決められなかった。・そういうわけで作業は遅れに遅れた。・プロジェクト管理は旧来の人月計算で行われていたので、遅れ=人員不足となってしまった。・リカバリは追加人員の投入のみ。そういうわけで下請け業者が次から次へと投入された。・人月の神話状態になり、ますます遅滞した。わずかにできあがってくるドキュメント類の品質もまちまちとなった。・関係者一同はこの状態をプロジェクト管理の問題との結論に達した。・プロジェクト管理を行うためにアクセンチュアがやってきた。・だが問題はプロジェクト管理以前のところにあったため、アクセンチュアが管理しようとすればするほど混乱が生じ、作業は遅滞していった…
思うに関係者全員が人月の神話の読書会でも開くほうがよっぽどマシだったんじゃないかな。
>思うに関係者全員が人月の神話の読書会でも開くほうがよっぽどマシだったんじゃないかな。面白いね。平家の亡霊が平家物語を聴くような、なんとも言えない光景になるな。
耳にもお経を書くのを忘れずに!
本来そこを解決するためにコンサルがいるんだが途中からコンサル入れてなにがしたかったんだろうな
コンサルって「コンサル」以外に「困猿」がたくさんいるんです。残念なことに後者の方が多いんですよね、、、。
>コンサルって「コンサル」以外に「困猿」がたくさんいるんです。
たまにこの手の話題が出るたびに誇張されたエピソードを見ているからか、ほぼ 「コンサル」=「困猿」 だと思ってしまってます。
そういう評判がネットにあふれているのになんであんなにホイホイお金払っちゃうんだろう。
言い訳をなすりつけて責任をとってくれる(行政にとって)ありがたい人柱のような人のじゃないの。
「言い訳をなすりつける」ってのは聞かない言い回しだなあ。意訳すると、こう言うことだろ?
言い訳をでっち上げて、顧客とコンサルタント自身以外に責任をなするつける
もしそうだとすると、そういうコンサルタントを「人柱」と呼ぶのは違和感があるな。あえて言うなら「人柱製造機」あたりだろう。
# 冬休みと関係あるのかな?
責任をどこかになすりつけて生贄を探してくれるありがたい存在かもね。
炎上したお得意さんのところに無償で火消しに行ったら、後から入ってきたコンサルによって、放火犯に仕立て上げられたことがありますが。あきらかにお客さんの失火。
仕事の段取りが付いて「さあ始めるぞ」って時に、お役所の上の鶴の一声でいきなり参入。書類の作成料を増やして足を引っ張るくせに、何ら仕事をせずに一番の利益を持って行くってイメージが実体験上大きいよ。
ここでなら言っても良いだろう。公共の仕事で後から出てくるコンサルなんてのは、ほぼ全てダニだと思って間違いなし。
アクセンチュアはWBS作れって言うだけでしたよ。作業が増えるだけで、進め方へのアドバイスとか、庁との意識あわせとか何もしなかったですね。
これで人月200万以上取るんだから、いい商売です。
言われないとWBSつくんないの?
EVMは作っていたらしいよ。そのWBS作れっていいはじめたのも調査委員会みたいだけれど。
分厚いRFP書いた(NTTDに書かせた)、って庁は偉そうにいきがってましたが、中身は良きに計らえしか書いていない。NTTDが取ることを前提に記述したのだから当然です。
基本となる法令や国際法、それらに対応するための暗黙的な運用、大量の人力を使っての仕分け作業、外注に出してる作業、審査の実態もろもろ、大量のイレギュラーの塊なのが現状。
自分の仕事は知っていても、それら全部を把握してる人はいないし、どこまでやるかを決められる人は庁にもTSOLにもいない。
調達仕様書はIBMビジネスコンサルティングサービス(現在は日本IBMと経営統合)と作ったって報じられてるけどね。それを元に入札実施した、とも。
http://itpro.nikkeibp.co.jp/article/COLUMN/20121204/441882/ [nikkeibp.co.jp]
リンク先の内容が正しいなら、仕様書と全く異なる提案を特許庁がしてきた時点で色々アウトだよね。後でちゃぶ台返しするなら入札の意味がない。
#それにしても今さらなんで新聞記事に・・?
どこでもそうだとは思うのですが、
「調達仕様書の元ネタ」はデータが作っています。それをもとに、IBMが「調達仕様書」を作ります。
「調達仕様書」を作った業者はその案件に入札できないので、そういうカラクリになってます。
なので、実質はデータが作りました。
>中身は良きに計らえしか書いていない。>基本となる法令や国際法、それらに対応するための暗黙的な運用、>大量の人力を使っての仕分け作業、外注に出してる作業、>審査の実態もろもろ、大量のイレギュラーの塊なのが現状。>どこまでやるかを決められる人は庁にもTSOLにもいない。
それでもデータはプロジェクトを成功させて、東芝は失敗した。その差こそが致命的だったんだろw
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
発注者問題 (スコア:4, 興味深い)
毎日の記事にこうある。
- 同庁の審査部門などから、機能の追加要求が断続的に寄せられたことが混乱に拍車をかけた...
- 特許庁が発注段階で、どういうシステムが必要かを詳細まで文書に落とし込む『見える化』をしていれば、ここまで開発が混乱することはなかった...
#なんだかなあ。
Re:発注者問題 (スコア:5, 興味深い)
Re:発注者問題 (スコア:3)
予算の段階から、プロトタイプ作成を分けておくのはどうですか。
お役所ならではの、予算が初めにあって、そっからモノを
いきなり作っちゃうから失敗しちゃうんじゃないかな。
初年度: XXシステムのプロトタイプ開発。予算NNNの範囲でXXのプロトタイプを開発。
プロトタイプによるユーザー調査から、本ちゃんシステムの要求機能、予定価格の見積もりを作成
次年度: XXシステムの入札、本開発。
ユーザーは実物を見るまで(使うまで) 間違った意見しか言わない、ぐらいに考えとくべき。
実際に動くプロトタイプを見せて、使わせなければ、良いシステムなど作れるわけがないと思います。
ならばこそプロトタイプ開発のみで予算を立てる。
プロトタイプは本ちゃん開発と違って、予算を決めておかないと際限なく工程が膨らむものなので、
予め予算額が決まっているお役所的な配分はむしろ都合がよい。
お役所的発注方法と非常に相性がよい、とも言えるでしょう。
予算の範囲内で満足いくプロトタイプが作られれば、本ちゃんシステムの要求定義は
プロトタイプをもとに過不足なく定義すればよいだけだし、実際に作ってからの話だから本開発の予定工事価格も算出しやすい。
仮に初年度予算では満足いくプロトタイプを作れなかったとしたら、次年度でもう一度、別のプロトタイプを作り直せばいい。
本開発は、納得いくプロトタイプを作れてからで十分です。
Re: (スコア:0)
>> 仮に初年度予算では満足いくプロトタイプを作れなかったとしたら、
という仮定が、現行のお役人様ルールで通用するかが最大の問題ではないでしょうか?
Re:発注者問題 (スコア:1)
というか、会計検査院が納得するかどうかが最大の問題かと
Re:発注者問題 (スコア:5, 参考になる)
はい。仰るとおりだと思います。 > 現行ルール&会計監査員
実際、懸念事項は多々あるでしょう。私も色々思いつきましたが、
そういったデメリットを踏まえても、やっぱりプロトタイピングを導入する(導入のために手筈を整える)メリットは
大きいのではと思うんですよね。
・プロトタイプ(必ず捨てる)というものに対する予算が付きにくいかもしれない
-> いきなり開発するよりお得である、ということをどれだけ理解してもらえるかですね。
・そもそもプロトタイピングしたからって、ちゃんとしたもの作れる保証がない
-> 逆に、プロトタイプで作れないなら、いきなり本ちゃんで作れるわけないかと。
であれば撤退時の被害が少ないので、失敗したらむしろプロトタイピングにして良かったことになります。
お役人的にも言い訳しやすいですよね!「本来困難極まるプロジェクトでしたので(俺は悪くないが)被害を最小限にする方法を選択しました(プロトタイピングじゃなきゃもっと大変だったんだぜ)」
・プロトタイプ運用に付き合わされる現場から文句が出る
-> 最終的に使いやすいシステムができれば現場にとって一番得であることを納得させる
特に今回のような、運用がわかりにくいシステムでは現場へのヒアリングのため
特定担当者ばかり負荷がかかる(結果として十分ヒアリングできない)という問題があります。
プロトタイプという誰でも目に見えるもので「深く狭く」から「浅く広く」へ負担を下げれることは大きいと思います。
・プロトタイプは裏金作りに利用しやすい
-> そこはお役所の良心しだいですけど・・。
というか裏金なら別にプロトタイプじゃなくても今でも普通にゴニョゴニョ・・・
ともあれ「コンクリートから人へ」と言うなら、コンクリートに合った方法(ウォーターフォール)でなく
人、つまりソフトウェアに合った方法へと変えるべき、と思います。
工事という意味でソフトウェアがコンクリートに劣るところは、複雑で完成像が見えないこと。
逆に優れているところは、捨てる費用がほぼゼロな点。建物は作っちゃうとなかなか壊せないですから。
納得のいくものができるまで、作ってはクシャクシャに丸めてポイ、とするのがソフトウェアの正しい作り方です。
(まあ実際はハードがなきゃ動かない、のはさておき)
個人的に金言としている「銀の弾丸はない」との言葉どおり、
プロトタイピングが向くものと、ウォーターフォールが向くものとそれぞれあるはずです。
少なくとも現状のウォーターフォール一択よりは、幅を広げるに超したことはないのではないかと。
#長文失礼
みんな釣られすぎ。 (スコア:4, 興味深い)
みんな釣られすぎ。
これは、来年度(平成25年度/2013年度)の予算確保を確実にするために、庁内から打ちあげている、というのが時期的にはオチ。
10月の会計検査院の記事 [srad.jp]の時点からほとんど情報は増えていないし、計画そのもの(主には、2022年以降に新システム完成)は、既に2012年9月には表に出てる。
http://www.jpo.go.jp/iken/saitekika_kaiteian.htm [jpo.go.jp]
http://www.jpo.go.jp/iken/pdf/saitekika_kaiteian/kaiteian.pdf [jpo.go.jp]
この時点で、およそ5年毎の2期(第I期と第II期)にわけて開発することになっているので、10年かかるのは、
羞恥周知の事実。ちなみに、上でパブリックコメントに出ている案については、既に、政府全体としても確認していて、これに対して、「各府省情報化統括責任者(CIO)補佐官等連絡会議」から出ている助言がこちら。
http://www.kantei.go.jp/jp/singi/it2/cio/hosakan/dai73/73jogen.pdf [kantei.go.jp]
一般的な論調としては「へーなるほど」なんだろうけど、この記事で、
となって、遅ればせながらの予算要求にて、特許庁から財務省に、財務原案→政府案 に圧力をかけることになるってこと。
庁の情シスか会計・官房から、毎日新聞にお願いが飛んだんだろうなあ。(ちょうど、政権交代で予算をつくりなおしているわけで。)
Re: (スコア:0)
それでは、年末の道路工事と同じレベルですね。
地球温暖化とか、エコ・ブームだの、プラズマ・なんたら、マイナスイオンとか、ユビキッタ(だっけ?)とかの
予算ちょうだい(ぴよぴよ)ごっこと同レベルという認識でよいでしょうか?
# 多少、間違ってても、ツッコミを入れるほど、暇な人はいないと信じてるし。
Re:発注者問題 (スコア:3, 参考になる)
・もともと特許庁はシステム更新を真剣には考慮していなかった。
・が、政治的理由により更新が行われることになった。
・現行システムは古くから使われているもので、拡張に拡張を重ねた複雑怪奇なものであった。
・新システムの開発に当たっては現行システムの解析から始める必要があった。
・しかし特許庁に全容を知るものはいなかった。
・そこでインタビューから始めることにしたが、TSOL(と外注先)のレベルがイマイチで、いつまで経っても全容がつかめなかった。
・そもそも更新の必要性をそれほど感じていなかった特許庁は、新システムに求めるものを具体的に決められなかった。
・そういうわけで作業は遅れに遅れた。
・プロジェクト管理は旧来の人月計算で行われていたので、遅れ=人員不足となってしまった。
・リカバリは追加人員の投入のみ。そういうわけで下請け業者が次から次へと投入された。
・人月の神話状態になり、ますます遅滞した。わずかにできあがってくるドキュメント類の品質もまちまちとなった。
・関係者一同はこの状態をプロジェクト管理の問題との結論に達した。
・プロジェクト管理を行うためにアクセンチュアがやってきた。
・だが問題はプロジェクト管理以前のところにあったため、アクセンチュアが管理しようとすればするほど混乱が生じ、作業は遅滞していった…
思うに関係者全員が人月の神話の読書会でも開くほうがよっぽどマシだったんじゃないかな。
Re:発注者問題 (スコア:3, おもしろおかしい)
>思うに関係者全員が人月の神話の読書会でも開くほうがよっぽどマシだったんじゃないかな。
面白いね。
平家の亡霊が平家物語を聴くような、なんとも言えない光景になるな。
Re: (スコア:0)
耳にもお経を書くのを忘れずに!
Re:発注者問題 (スコア:1)
本来そこを解決するためにコンサルがいるんだが
途中からコンサル入れてなにがしたかったんだろうな
Re:発注者問題 (スコア:2, すばらしい洞察)
Re:発注者問題 (スコア:1)
コンサルって「コンサル」以外に「困猿」がたくさんいるんです。
残念なことに後者の方が多いんですよね、、、。
Re:発注者問題 (スコア:1)
>コンサルって「コンサル」以外に「困猿」がたくさんいるんです。
たまにこの手の話題が出るたびに誇張されたエピソードを見ているからか、
ほぼ 「コンサル」=「困猿」 だと思ってしまってます。
そういう評判がネットにあふれているのになんであんなにホイホイお金払っちゃうんだろう。
Re:発注者問題 (スコア:1)
言い訳をなすりつけて責任をとってくれる(行政にとって)ありがたい人柱のような人のじゃないの。
「言い訳をなすりつける」ってのは聞かない言い回しだなあ。
意訳すると、こう言うことだろ?
言い訳をでっち上げて、顧客とコンサルタント自身以外に責任をなするつける
もしそうだとすると、そういうコンサルタントを「人柱」と呼ぶのは違和感があるな。
あえて言うなら「人柱製造機」あたりだろう。
# 冬休みと関係あるのかな?
Re: (スコア:0)
責任をどこかになすりつけて生贄を探してくれるありがたい存在かもね。
炎上したお得意さんのところに無償で火消しに行ったら、後から入ってきたコンサルによって、放火犯に仕立て上げられたことがありますが。
あきらかにお客さんの失火。
Re: (スコア:0)
仕事の段取りが付いて「さあ始めるぞ」って時に、お役所の上の鶴の一声でいきなり参入。
書類の作成料を増やして足を引っ張るくせに、何ら仕事をせずに一番の利益を持って行くってイメージが実体験上大きいよ。
ここでなら言っても良いだろう。
公共の仕事で後から出てくるコンサルなんてのは、ほぼ全てダニだと思って間違いなし。
Re:発注者問題 (スコア:1)
アクセンチュアはWBS作れって言うだけでしたよ。
作業が増えるだけで、進め方へのアドバイスとか、庁との意識あわせとか
何もしなかったですね。
これで人月200万以上取るんだから、いい商売です。
Re: (スコア:0)
言われないとWBSつくんないの?
Re:発注者問題 (スコア:2)
EVMは作っていたらしいよ。
そのWBS作れっていいはじめたのも調査委員会みたいだけれど。
Re: (スコア:0)
分厚いRFP書いた(NTTDに書かせた)、って庁は偉そうにいきがってましたが、
中身は良きに計らえしか書いていない。
NTTDが取ることを前提に記述したのだから当然です。
基本となる法令や国際法、それらに対応するための暗黙的な運用、
大量の人力を使っての仕分け作業、外注に出してる作業、
審査の実態もろもろ、大量のイレギュラーの塊なのが現状。
自分の仕事は知っていても、それら全部を把握してる人はいないし、
どこまでやるかを決められる人は庁にもTSOLにもいない。
Re:発注者問題 (スコア:1)
調達仕様書はIBMビジネスコンサルティングサービス(現在は日本IBMと経営統合)と作ったって報じられてるけどね。それを元に入札実施した、とも。
http://itpro.nikkeibp.co.jp/article/COLUMN/20121204/441882/ [nikkeibp.co.jp]
リンク先の内容が正しいなら、仕様書と全く異なる提案を特許庁がしてきた時点で色々アウトだよね。後でちゃぶ台返しするなら入札の意味がない。
#それにしても今さらなんで新聞記事に・・?
Re: (スコア:0)
どこでもそうだとは思うのですが、
「調達仕様書の元ネタ」はデータが作っています。
それをもとに、IBMが「調達仕様書」を作ります。
「調達仕様書」を作った業者はその案件に入札できないので、
そういうカラクリになってます。
なので、実質はデータが作りました。
Re: (スコア:0)
>中身は良きに計らえしか書いていない。
>基本となる法令や国際法、それらに対応するための暗黙的な運用、
>大量の人力を使っての仕分け作業、外注に出してる作業、
>審査の実態もろもろ、大量のイレギュラーの塊なのが現状。
>どこまでやるかを決められる人は庁にもTSOLにもいない。
それでもデータはプロジェクトを成功させて、東芝は失敗した。
その差こそが致命的だったんだろw