アナウンス:スラドとOSDNは受け入れ先を募集中です。
コメント: Re:文系と理系の象徴 (スコア 5, 参考になる) 112
あの~仕様の変更どころか、東芝ソリューションは技術力が低くて、そもそも仕様をまとめることができなかったという状態だったんだけどね。
特許庁から独立している会計監査院がまとめた資料からの引用。
業務要件の詳細化
システム開発に当たっては、発注者が業務要件の定義を行うのが通常であるが、特許庁は、受注者が特許庁の業務等を分析して業務要件を詳細化して提案することとしていた。
TSOLは、技術力の高い設計担当者を配置して上記の作業を行うとする提案を入札時に行っていたが、実際には、提案を実現する技術力を有する設計担当者を配置しておらず、現行のシステムの業務要件等を分析することが困難となっていたため、TSOLから、当初予定していた60人の3倍を超える200人の設計担当者を投入して現行のシステムに係る全てのプログラム設計書を精査して、現行の業務要件等の分析を行うとする提案がなされた。
コメント: Re:ターミネーター? (スコア 5, おもしろおかしい) 45
俺はVHSの再生が難なく出来るようになった小1頃に、
親父の裏ビデオを発見して拝んだアレの驚きのおかげで、今でも純潔を保てている。
まったく放任が一番だ。こういうヤブヘビ型のトラウマ体験があっても面白いじゃないか。
コメント: Re:文系と理系の象徴 (スコア 5, 興味深い) 112
>>システム開発に当たっては、発注者が業務要件の定義を行うのが通常であるが、
>>特許庁は、受注者が特許庁の業務等を分析して業務要件を詳細化して提案することとしていた。
>正直、これが最大の原因だと思うけど。
>他社が受けても、これがクリアできるかどうかだと思うなぁ。
複雑珍妙な縦割り業務形態で、特許庁の中の人自身が、要件定義することが不可能な制約状況下、
現行システム入れてるNTTデータだけが唯一、業務全容を理解していたので、
うまくデータに落とさせる筈が、データのアホな営業が贈収賄でパクられて入札に参加できず、
結果、廊下で立ってるデータ以外は誰も実現不可能なんだけど、入札は実施せざるを得ず、
まあ被害を最小限にするため、最低価格のTSOLに落とさせるか、
・・・・・みたいな成り行きを、中の人が言ってたという噂。
#グループ会社なのでAC。
orcinusのコメント: 調査報告書 (スコア 4, 参考になる) 112
とりあえず、「調査報告書」を読もう。・・・私はこれから読む。
http://www.meti.go.jp/press/20100820003/20100820003-2.pdf
maiaのコメント: Re:特許庁のシステム開発が破綻した本当の理由 (スコア 4, 興味深い) 112
あれ、マイナスモデされちゃいましたね。おかげで色々面白い記事が見つかりました。
「特許システムのあるべき姿を追求した」という話で、途方もなくデカい話だった(中略)「動かないコンピュータ」どころか、動きようがないコンピュータだ。(中略)思うに、あまりにデカい「夢」を見て(見されられて)しまい、その「夢」がいつまでも捨て切れず、その「夢」の実現迫り続けた。
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
技術を特許庁の業務にどう活かすかという具体性・現実性に乏しく、技術オリエンテッドで物事が進んでいた。(中略)技術をどう活かすかという結果イメージがシナリオレベルで不明確で両者(発注側・開発側)どちらも説明できていないのだ。
特許庁次期基幹システム開発中断〜真の問題は役所にITエンジニアが不足していること
本件の本質的な問題点として役所側にSE、つまりIT技術者がいないことが非常に大きな問題だと、私は考えています。(中略)多くの官公庁がこの提案依頼書を自分達で作成する能力・専門知識に欠けています。多くの場合、現行システムを開発した業者にこの提案依頼書の作成を無料で手伝わせるのです。業者側は提案依頼書の作成を手伝うことで新システムの内容を他社よりも早くしかも詳細にわかる(中略)今回の中断したシステムの提案依頼書作成もNTTデータが手伝っていた
役所にIT技術者がいないのは、致命的だと思う。まあ、根っからそうだとは思うけど。
reichiのコメント: タブレットで十分かもしれないけれど、遠隔操作が未成熟 (スコア 4, 興味深い) 134
トラブルの無さ、必要十分という意味では、「印刷」を除けばほぼ新しいニーズの無い祖父母レベルはiPadでこと足りています。
(ネットスーパーでの注文や、メール、Webでの調べ物などなど、最近はSkypeまで使ってます)
「印刷」もAirPrint対応のプリンタでほぼほぼ実用になってきてます。のこるは年賀はがきの印刷がネックですね。
ただ、もう少し要求の高い子供や奥さんレベルになると、新たなニーズが出てきた時に遠隔操作ができないタブレットは結構致命的で、
Windowsのリモートアシスタンスやリモートデスクトップ。vProレベルの遠隔操作が出来ればいいのにと思う場面に出会います。
まともに使えるWindows RT機が発売されたら、奥さんと子供のPC環境をVDI化して管理できれば完璧かな?などと考えていたりします。
Android系はまだあまりにアプリのインストールが簡単すぎ&陳腐化早すぎで、子供には持たせたくない。
その意味では、iOSに限定した話です。はい。
iOS系もできるだけクラウドサービスを活用して、何かあった時に端末自体を操作しなくても対応できるようにするのが良いかと・・・
#Gmail&Googleカレンダー、YouTubeなどのアカウントは、私が家族分を一括管理。うまくいかないときはWEB操作で問題解決。
#子供に見せるアニメはAirVideoサーバで一括管理。
#祖母が読みたい本を追加削除するのもi文庫HDでFTPフォルダ管理、ComicGrassのHTTPサーバ管理
#孫の写真などは、iPadではなく、auのPhoto-Uで遠隔管理してます。
#単身赴任で、東京から愛知、三重の家族のPC&タブレットを保守する。おっさんでしたorz...
deleted userのコメント: Re:アダルトだけクラウド化してみては? (スコア 4, 興味深い) 45
そういう使い方をしてアカウントを停止された人もいるようです。
コメント: みんな釣られすぎ。 (スコア 4, 興味深い) 112
みんな釣られすぎ。
これは、来年度(平成25年度/2013年度)の予算確保を確実にするために、庁内から打ちあげている、というのが時期的にはオチ。
10月の会計検査院の記事の時点からほとんど情報は増えていないし、計画そのもの(主には、2022年以降に新システム完成)は、既に2012年9月には表に出てる。
- 「特許庁業務・システム最適化計画(改定案)」に関する意見募集(パブリックコメント)について
http://www.jpo.go.jp/iken/saitekika_kaiteian.htm - 「特許庁業務・システム最適化計画(改定案)」<PDF 288KB>
http://www.jpo.go.jp/iken/pdf/saitekika_kaiteian/kaiteian.pdf
この時点で、およそ5年毎の2期(第I期と第II期)にわけて開発することになっているので、10年かかるのは、羞恥周知の事実。
本計画では全体をおよそ5年毎の2期に分ける(2.2 参照)。前半約5年を第Ⅰ期とし、まずは特許・実用新案系のシステムの一部につき、システム構造を簡素化し、中核的業務についてリアルタイム化を実現する。並行して、特許庁システムの処理・データの内容や各システム間の連携関係等につき、綿密な分析調査を行う。
後半約5年は第Ⅱ期とし、特許・実用新案系のシステム構造の簡素化に引き続き、技術的難易度が相対的に高い意匠・商標系のシステムについても簡素化を進め、もって、全業務システムのリアルタイム化を実現する。
ちなみに、上でパブリックコメントに出ている案については、既に、政府全体としても確認していて、これに対して、「各府省情報化統括責任者(CIO)補佐官等連絡会議」から出ている助言がこちら。
- 特許庁業務・システム最適化計画の改定(案)に対する助言
http://www.kantei.go.jp/jp/singi/it2/cio/hosakan/dai73/73jogen.pdf
プロジェクトの再開に当たっては、各府省におけるシステム開発の事例等を参考にし、当該プロジェクトを適正に進めるための体制を検討するとともに、事前のリスク分析を含むプロジェクト管理を的確に行うことが必要。
一般的な論調としては「へーなるほど」なんだろうけど、この記事で、
- 「はやくしないと知財立国があぶないね」
- 「遅れているとはいえ、1年でも早く完成すべき」
- 「できるだけはやく計画を再開すべき」
- 「来年度(2013年度)には開始しなくてはならない」
- 「本件の予算を削ってはならない」
となって、遅ればせながらの予算要求にて、特許庁から財務省に、財務原案→政府案 に圧力をかけることになるってこと。庁の情シスか会計・官房から、毎日新聞にお願いが飛んだんだろうなあ。(ちょうど、政権交代で予算をつくりなおしているわけで。)
ikotomのコメント: Re:発注者問題 (スコア 4, 参考になる) 112
はい。仰るとおりだと思います。 > 現行ルール&会計監査員
実際、懸念事項は多々あるでしょう。私も色々思いつきましたが、
そういったデメリットを踏まえても、やっぱりプロトタイピングを導入する(導入のために手筈を整える)メリットは
大きいのではと思うんですよね。
・プロトタイプ(必ず捨てる)というものに対する予算が付きにくいかもしれない
-> いきなり開発するよりお得である、ということをどれだけ理解してもらえるかですね。
・そもそもプロトタイピングしたからって、ちゃんとしたもの作れる保証がない
-> 逆に、プロトタイプで作れないなら、いきなり本ちゃんで作れるわけないかと。
であれば撤退時の被害が少ないので、失敗したらむしろプロトタイピングにして良かったことになります。
お役人的にも言い訳しやすいですよね!「本来困難極まるプロジェクトでしたので(俺は悪くないが)被害を最小限にする方法を選択しました(プロトタイピングじゃなきゃもっと大変だったんだぜ)」
・プロトタイプ運用に付き合わされる現場から文句が出る
-> 最終的に使いやすいシステムができれば現場にとって一番得であることを納得させる
特に今回のような、運用がわかりにくいシステムでは現場へのヒアリングのため
特定担当者ばかり負荷がかかる(結果として十分ヒアリングできない)という問題があります。
プロトタイプという誰でも目に見えるもので「深く狭く」から「浅く広く」へ負担を下げれることは大きいと思います。
・プロトタイプは裏金作りに利用しやすい
-> そこはお役所の良心しだいですけど・・。
というか裏金なら別にプロトタイプじゃなくても今でも普通にゴニョゴニョ・・・
ともあれ「コンクリートから人へ」と言うなら、コンクリートに合った方法(ウォーターフォール)でなく
人、つまりソフトウェアに合った方法へと変えるべき、と思います。
工事という意味でソフトウェアがコンクリートに劣るところは、複雑で完成像が見えないこと。
逆に優れているところは、捨てる費用がほぼゼロな点。建物は作っちゃうとなかなか壊せないですから。
納得のいくものができるまで、作ってはクシャクシャに丸めてポイ、とするのがソフトウェアの正しい作り方です。
(まあ実際はハードがなきゃ動かない、のはさておき)
個人的に金言としている「銀の弾丸はない」との言葉どおり、
プロトタイピングが向くものと、ウォーターフォールが向くものとそれぞれあるはずです。
少なくとも現状のウォーターフォール一択よりは、幅を広げるに超したことはないのではないかと。
#長文失礼