アカウント名:
パスワード:
リンク先の報告書を流し読みした感想。 書いてあることは、概ねそのとおりだけど、政府や自治体に現実化できるのか・現実化する意思があるのかという最も重要な点がすっぽり抜け落ちてると思う。
スラドを読む人には理解できないだろうけど、一般組織では情報システムの優先度は本当に低い。 日経クロステックの木村編集委員の連載 [nikkei.com]でよく「ダメな情シス」が描写されてるけど、ああいう感じのところが多くて、現状では発注者責任を全うできる組織は少ないと思う。
地元の役所と取引があるとわかると思うけど、役所では業務が細かく担当者に割り振られていて、ほかの担当者では業務自体をわからなかったりする。 こういう状況で発注者責任を自覚して発注仕様書をとりまとめるなら、各業務の担当者にも導入作業に巻き込むことが必要なんだけど、そういう発想する人はほとんどいない。 大体、課で一人か二人担当者を決めると、その人に任せるという、丸投げ状態ですな。 各システム間で共有する基本的な台帳の連携すら抜け落ちていたり、金がかかるからと要って落としたりすることが起きる。例えば病院システムなら、医事会計システムから患者の基本情報を管理して、電子カルテや調剤支援、検体検査といった各システムで共有すると思うけど、これができていないことがある(というか、ほかのやつのやつたことの後始末している)。 業務担当課は数年に一回しかシステム導入・更新事業を担当しないんだから、基本的なことすら知らない人が大半。 全体を管理する情報システム担当課でこういう基本的なことを計画当初に周知して、人事異動が起こるたびに担当者に教え込む必要があるんだけどしてない。
理想を高く掲げるのなら、まず情報システムに詳しい職員を養成する必要があると思う。 それも組織独自のカリキュラムや基準ではなくて、ITSSを元に全国一律でベンダーもユーザーも共通理解できるものをベースにしないと、まず話ができない。 それと小さなシステムの製作を経験させて、システム化の方法論を学ばせる必要がある。 そして、ある程度、スキルのある人を人数をそろえないと話にならない。
/* ベンダーから中途採用って、本来公的機関が求めている人材とは違う気がするんだよね。 公的機関でプロジェクトを進める際必要なのは、具体的な製品知識よりも業務全体の理解とリスク管理、関係者を巻き込む力だと思うので、ユーザー側でシステム更新プロジェクトを何回も成功させている人材が必要だと思う。 ベンダー側でいったら、本当にトップクラスのプロジェクトリーダーやアーキテクトだろうけど、そういう人が公的機関に来てくれるものか・・・。*/
書き忘れけど、BCPとかいうなら業務プロセス自体の管理にもコストをかける意識が必要だよね。 普段は各担当者に丸投げで、プロセスがブラックボックスになってるのに、システム化の時だけ、要件が明確にできるなんてありえない。 自分たちの業務の根拠と、どう行っているかがわからないと、まずシステム化できないし問題点も文書ができない。
役所はベンダーとの癒着を避けるという目的で3年くらいで担当者が配置換えになるので、詳しい職員の養成なんて無理では。無理というか、養成が済んだ頃には、どっか別の所に行ってしまう。
属人化を避けるために文書化すると、時代に合わなくなっても金科玉条として融通が利かなりそうね
「ベンダー」との取引をやめて内製を基本にした上でジョブローテもやめることだね
ジョブローテってプラス面とマイナス面があるけど職種まで変えるのはマイナスしかないよなー
まぁ、転職しても潰しが効かない状態にする=会社に忠誠を誓わせるって意味では有効なんだろうが。
当町の担当職員は,通常の人事ローテーションの一環として情報システム担当に配属されるだけであり,特に担当職員としての育成の指針も無いので,情報システムに詳しい内部職員が育たない。調査報告書(16ページ)より
そーだよねー。
公共施設予約システムを更新する際に,既存ベンダーからデータの移行費用として5000万円を請求 され,データ移行を依頼することを断念した。調査報告書(18ページ)より
こういう規模は、中規模開発業者でも対応できそうな感じ。ベンダーの多様化と言っても、中規模開発を中規模開発業者が直接請け負うって形がせいぜいだろうね。(それでも、現状よりも競争環境は改善される)多数の中規模開発業者を役所の情報システム部が統括して大規模開発をするのはあまり現実的とは思えない。市民向けサービス(公共施設予約、市民講座予約、健康診断予約、各種予備申請)のシステムを疎結合API連携で開発する形態なら、まあ、現実的だろう。規模と工期によっては、小規模開発業者も直接請け負うことができるだろう。
ま、ゆーて話しても理解できない現場のおバカさんたちに説明してる暇はないので最初から声かけないでねと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
理想は何とでもいえるけど (スコア:4, すばらしい洞察)
リンク先の報告書を流し読みした感想。
書いてあることは、概ねそのとおりだけど、政府や自治体に現実化できるのか・現実化する意思があるのかという最も重要な点がすっぽり抜け落ちてると思う。
スラドを読む人には理解できないだろうけど、一般組織では情報システムの優先度は本当に低い。
日経クロステックの木村編集委員の連載 [nikkei.com]でよく「ダメな情シス」が描写されてるけど、ああいう感じのところが多くて、現状では発注者責任を全うできる組織は少ないと思う。
地元の役所と取引があるとわかると思うけど、役所では業務が細かく担当者に割り振られていて、ほかの担当者では業務自体をわからなかったりする。
こういう状況で発注者責任を自覚して発注仕様書をとりまとめるなら、各業務の担当者にも導入作業に巻き込むことが必要なんだけど、そういう発想する人はほとんどいない。
大体、課で一人か二人担当者を決めると、その人に任せるという、丸投げ状態ですな。
各システム間で共有する基本的な台帳の連携すら抜け落ちていたり、金がかかるからと要って落としたりすることが起きる。例えば病院システムなら、医事会計システムから患者の基本情報を管理して、電子カルテや調剤支援、検体検査といった各システムで共有すると思うけど、これができていないことがある(というか、ほかのやつのやつたことの後始末している)。
業務担当課は数年に一回しかシステム導入・更新事業を担当しないんだから、基本的なことすら知らない人が大半。
全体を管理する情報システム担当課でこういう基本的なことを計画当初に周知して、人事異動が起こるたびに担当者に教え込む必要があるんだけどしてない。
理想を高く掲げるのなら、まず情報システムに詳しい職員を養成する必要があると思う。
それも組織独自のカリキュラムや基準ではなくて、ITSSを元に全国一律でベンダーもユーザーも共通理解できるものをベースにしないと、まず話ができない。
それと小さなシステムの製作を経験させて、システム化の方法論を学ばせる必要がある。
そして、ある程度、スキルのある人を人数をそろえないと話にならない。
/*
ベンダーから中途採用って、本来公的機関が求めている人材とは違う気がするんだよね。
公的機関でプロジェクトを進める際必要なのは、具体的な製品知識よりも業務全体の理解とリスク管理、関係者を巻き込む力だと思うので、ユーザー側でシステム更新プロジェクトを何回も成功させている人材が必要だと思う。
ベンダー側でいったら、本当にトップクラスのプロジェクトリーダーやアーキテクトだろうけど、そういう人が公的機関に来てくれるものか・・・。
*/
業務プロセスの管理にもコストがかかる (スコア:3, 興味深い)
書き忘れけど、BCPとかいうなら業務プロセス自体の管理にもコストをかける意識が必要だよね。
普段は各担当者に丸投げで、プロセスがブラックボックスになってるのに、システム化の時だけ、要件が明確にできるなんてありえない。
自分たちの業務の根拠と、どう行っているかがわからないと、まずシステム化できないし問題点も文書ができない。
Re:理想は何とでもいえるけど (スコア:1)
役所はベンダーとの癒着を避けるという目的で3年くらいで担当者が配置換えになるので、詳しい職員の養成なんて無理では。
無理というか、養成が済んだ頃には、どっか別の所に行ってしまう。
Re: (スコア:0)
属人化を避けるために文書化すると、時代に合わなくなっても金科玉条として融通が利かなりそうね
Re: (スコア:0)
「ベンダー」との取引をやめて内製を基本にした上でジョブローテもやめることだね
Re: (スコア:0)
ジョブローテってプラス面とマイナス面があるけど職種まで変えるのはマイナスしかないよなー
まぁ、転職しても潰しが効かない状態にする=会社に忠誠を誓わせるって意味では有効なんだろうが。
Re: (スコア:0)
当町の担当職員は,通常の人事ローテーションの一環として情報システム担当に配属されるだけであり,特に担当職員としての育成の指針も無いので,情報システムに詳しい内部職員が育たない。
調査報告書(16ページ)より
そーだよねー。
公共施設予約システムを更新する際に,既存ベンダーからデータの移行費用として5000万円を請求 され,データ移行を依頼することを断念した。
調査報告書(18ページ)より
こういう規模は、中規模開発業者でも対応できそうな感じ。
ベンダーの多様化と言っても、中規模開発を中規模開発業者が直接請け負うって形がせいぜいだろうね。(それでも、現状よりも競争環境は改善される)
多数の中規模開発業者を役所の情報システム部が統括して大規模開発をするのはあまり現実的とは思えない。
市民向けサービス(公共施設予約、市民講座予約、健康診断予約、各種予備申請)のシステムを疎結合API連携で開発する形態なら、まあ、現実的だろう。規模と工期によっては、小規模開発業者も直接請け負うことができるだろう。
Re: (スコア:0)
ま、ゆーて話しても理解できない現場のおバカさんたちに説明してる暇はないので最初から声かけないでねと