bewaad institute@kasumigaseki

  • archives by smart archives
  • 06/02/2007 (2:25 pm)

    官僚≒プログラマ仮説

    Filed under: government, computer ::

    似通ったことをそれとなく書いてきたような気がするわけですが。

    あちら側からでもそのように見えると聞いて、独りよがりではなかったと少し安心。

    #ぜひお読みください>同業者諸兄。

    add to hatena hatena.comment 0 user add to del.icio.us 1 users add to livedoor.clip 1 users

    23 Responses to “官僚≒プログラマ仮説”

    1. 竹馬 Says:

      ああ、自分で自分を誤魔化しつつ、目を背けていた現実がを直視させられてしまった。

      ということもなく、「やっぱりそうだよねぇ〜。」としか思わない今日この頃ですね。人の歩みを止めるのは絶望ではなく諦めと昔の人は言ったそうな。

      お体を大切に。

    2. yy Says:

      要は、政治家が仕様書の仕様を決める能力がなく、「こんな感じにしたい」というような曖昧なイメージしか持っていないことが問題なのではないでしょうか。
      憲法改正問題などを見ていても、政治家が憲法が法規であることを理解しているかどうかすら疑わしくなります。
      自分の曖昧な思想や理念で法規を語ってもらっては困るのですけどね。

      昨日、山谷補佐官がNHKに出演して、教育再生会議について語っておられましたが、「あれもしたい、これもしたい、どれも大事」と言うばかりで、具体的な内容は何もなし。
      政治家のこういう曖昧な態度こそ、教育行政迷走の最大の原因であるように思います。

      システム開発なんかを見ていても、具体的な仕様を示さずに、曖昧かつ無茶な要求をする顧客がいますよね。日本の政治家ってまさにそれ、SE泣かせの顧客みたいなもんです。
      そういう意味で、リンク先のエントリは大変興味深かったです。

    3. ゲスト Says:

      これって上手く言ってると思うんですが、公務員(特に下級)とかだと「いい加減に対処して逃げる」って方法が以外と通用する場合が少なく無いんですよ。私の経験からすると。

       SEの人とかはどうなんでしょうか?

    4. webmaster Says:

      >竹馬さん
      多くの方に賛同いただける=勘違いでない可能性が高いことは、喜んでいいのやら悲しんでいいのやら(笑)。

      >yyさん
      トレードオフの理解があるかどうかだと思います。あれもこれもできればいいわけですが、リソースの制約で優先順位をつけるなりをして、どのような組み合わせが最も妥当かを考えなければいけないのが現実でしょう。それがわかった上での指示であれば、こちらもずいぶんと楽になるわけですが(笑)。

      >ゲストさん
      それは、ゲストさんが大いに信頼を勝ち得ているからではないでしょうか。そういう信用を築くことができれば、少なくとも中間からの雑音は少なくていいですよね。

    5. bn2islander Says:

      立場を変えてみると

      「法律は仕様書だ。国民は仕様を要望する大切なお客様だ。政治家はそれを仕様書の形に翻訳する下流のSEだ」

      とも言えますし

      「法令は仕様書だ。官僚はそれを決める最上流のSEだ。医師はそれを実装するプログラマだ。」

      単なる言葉遊びなんですが。

    6. 民間人 Says:

      > リタイヤするかデスマーチが終わるかするまで、給料が保証されてることくらい

      これは、民間との大きな違いですね。さすがに給料が出ないことはあまりないですが、(会社は儲かっているのに)算定基準変更で、「ボーナス減額」は普通にありますもの。
      #個人の査定変更ではなくって、です。

    7. 鍋象 Says:

      >>ゲストさん
      それなりの規模の開発は、企業側SEがそれなりに踏みとどまるし、最後は訴訟沙汰になり、ネゴで返品なんてケースもあります。

      中小企業レベルで自社SEがいなくて社長判断でシステム導入するようなケースで、パッケージソフトの修正を小さいソフトハウスなんぞに任せてしまったりすると、得てしていい加減に対処して逃げたうえで、文句を言おうものなら修正修正で更に追加請求くらうなんてケースもあります。安易に受領印を押してしまうとか、そもそも特定個人に頼りきっていて組織化されていない業務をシステム化するのは難しいとかありますが。

    8. webmaster Says:

      >bn2islanderさん
      いずれにしても、クライアントに対して、要求定義の手前までは意思統一をお願いします、とすらいえない状況は変わりません(笑)。

      >民間人さん
      それもだんだん怪しいといいますか、そのうち再就職禁止だけれども肩たたき(早期退職勧奨)は継続、みたいなことになりそうな気も。

      >鍋象さん
      その「中小企業レベルで自社SEがいな」いクライアントには、省庁も含まれませんか(笑)?

    9. 鍋象 Says:

      >>bewaadさん
      ここで見ている限りでは、人事給与系システムはしっかりしているようでw

      以前うちの会社でトラブルになった、某官庁系を得意とするコンピュータメーカーを見ていると、確かに逃げ切り狙いみたいな事が横行している可能性は否定できないかなと思います。ただ、その責の一部は、それを許してしまっている受領側が負わなければいけないかなぁと。

      以下想像です。現場のシステムを運用する人間とのコミュニケーションが不足した責任者に受領印を押させてしまうというのは逃げ切りの極意じゃないかと思います。そして成果物の品質とスケジュールの両方、あるいはスケジュールを過度に重視する責任者ほど、逃げ切りスタンスの会社とインセンティブが一致してしまうわけで。役所の場合、予算の執行機関とかそういうスケジュール的な縛りがあるのかなと。

      そういえば、役所システムで開発元と訴訟沙汰になったみたいな話を聞いた事が無いのですが、やっぱりあるのでしょうか?

    10. yy Says:

      〉鍋象さん
      例えばの話ですが、年度末に納入されたシステムが、新年度に稼働してからなんらかの欠陥が見つかった場合、表沙汰にすると、検収確認者の過失責任が発生します。
      それよりは、内々で穏便にすませるケースがほとんどではないでしょうか。
      今まで訴訟になったケースってのは、聞いたことがないですね。

    11. 鍋象 Says:

      >>yy
      内々で穏便に済ませるといっても、費用がかかるケースではどうするのでしょう。

      隠されたインセンティブネタついでで。
      通常システム発注は、概要設計で一旦費用清算した上で、システム全体の開発費用を見積もり、価格交渉します。ここではいかに価格を下げるのかという交渉が行われまして、なんとなく無理やりに工数を減らしてしまったりします。
      で、その後詳細設計に入ると、そこでまた追加仕様が発生してほぼ100%金額が変わります。減る事はなく増える一方で倍になる事はザラです。

      民間だと詳細設計に入った時点で発生した追加仕様は、再度予算修正して開発するかしないか判断していきますが、官の場合はどうなんでしょう?

      たとえば僕の知ってる範囲でいくと、某社団なんかは予算から増える際には修正予算をやりますが、相当な手間がかかる上にまったくの不手際扱いされるわけです。某社団は会員がそれなりの高所得者なので内緒で自腹切るなんて裏技で対処しています。このやり方は、理事会が全知全能でそこで許可した金額に100%間違いが無いケースではうまくいくのですが、現実にはそんな事があるわけがなく。
      で、役所の場合は予算を多めに計上しておくという方向で対処してしまったりしないのでしょうか?あるいは、上記の検収者の過失責任分も見込んで予算化しておくとか、さらに妄想を膨らませると、他の契約とチャンポンにして全体で帳尻を合わせるがゆえに随意契約の相手がいつも一緒になってしまうとか、そのうちに隠れ預け金という形の裏金が生じてしまわないかと。
      これは「きっと悪いことをしている」と言いたいのではなく、予算執行に柔軟性が無いとかえって全体の非効率とか、余計な費用がかかってしまうのではないかという疑問を感じたことがありませんか?という質問だと捉えてください。

    12. 一国民 Says:

      システムが不良品だった時に、SEが記憶にありませんとか、プログラマが私は責任とれませんとか、言われたら会社はつぶれますけれども。
      …まあ逃げるSEもいるか…。

    13. yy Says:

      >鍋象さん

      官公庁等に導入する規模のシステムであれば、導入後は通常、専任のSEを配置した保守契約を結ぶのが普通ではないでしょうか。さらに、場合によっては別途業務支援という形の契約を結ぶケースもあるでしょう。
      その体制で、逐次システムのエンハンスを行っていけば、運用開始年度の末には大概の欠陥は修正されているかと。
      一方、業者側としても、保守契約、業務支援や有償の機能アドオンで費用は回収可能かと推測します。特にシステム保守は納入業者以外が行うことはまず無理ですから、いったん納入してしまえば、システム廃棄までは確実に稼げますよね。

      後半のお話ですが、裏金ということはないにせよ、上記のように同じ業者と随意契約が続くという問題は確かにあると思います。しかし、これは予算執行上の問題というよりは、システム依存で業務を行っていることから生じている問題ではないかと考えます。システムの中身がブラックボックスであれば、問題の対応は納入業者に頼るしかなくなりますから。

      余計な費用の発生への対応策としては、とにかくシステム構築前に、業務フローや運用組織を確立し、おおむね運用可能なレベルの確かな仕様を固める、ということくらいでしょうか。でも、そこが多分一番難しいかと…(経験上)

    14. webmaster Says:

      >鍋象さん
      私も具体例は知りませんが、基本的に役所には自前のSEはいませんから(例外はありますが)。昔は随意契約で、ある期の帳尻を次の期で埋め合わせさせたり、なんて形での対応もあったのでしょうけれど、これだけ入札にシフトしてくると、何がしかの変化は生じているはずではあります。

      >yyさん
      情報提供ありがとうございました・・・って言っていいんでしょうか、私(笑)。

      結局、役所の側にきちんと検証できるだけの体制が整っていない=情報の非対称性が存在することにどう対処するのか、という問題なのだと思います。業者の善意を期待する(で、tit for tat流に裏切られた場合には契約を打ち切る)というのが随意契約を前提とした従来の対処方針だったわけですが、競争入札が広がっている今、新たなスキームが構築できるのかどうか、少なくともCIO補佐官に頼りっきりになるのは危ないようではありますが・・・。

      >一国民さん
      やっぱり、「仕様です」と言うのでは(笑)。

    15. 鍋象 Says:

      >>bewaadさん
      >これだけ入札にシフトしてくると

      システムだけは随意契約というわけではないのですか?
      設計だけは随意、プログラミングは競争入札なのかなぁ。

      なお、この件は情報の非対象性というより、予測不能性だと思ったりします。明日の事故るかわからないのと同様にシステムは動かしてみないとわからない面がありまして、将来の支出を変えたくないのなら、何らかの保険をかけておく事が必要になるのかなという事です。理屈の上ではそんな事は無いはずですが、現実的には人間の能力を超えていますので。

    16. のんきゃり Says:

      >鍋象 様、yy 様

      今はよほどのことがない限り入札です。
      システム関係で随意契約で億単位の買い物したら、途端に財務省の予算執行調査と会計検査院と総務省行政評価局に包囲殲滅されちゃいます。

      とはいえ、役所のシステム部門なんて、傍流な部署ですから予算はともかく人材は質・量ともに不足しててますので(本職SEに匹敵する人間なんてまずいないですからね)、いろいろ大変です。

      役所のシステム開発は高めの単価な場合が多いので、オイシイように見えますが、システム設計の失敗や急な法改正で工数が増えたときは、業者に「泣いて貰う」リスクを見越しての単価設定です。その分野のノウハウのない業者が迂闊に不慣れなシステムを落札しちゃうと業者が大出血しちゃうので、毎年同じ業者が落札することがほとんどです。

      んで、高コストなので、○年以内に投資費用が回収できるシステム以外の開発は原則認めない内閣官房の「業務・システム最適化計画」
      http://www.e-gov.go.jp/doc/scheme.html
      なんてので、きめの細かい厳密な管理によるシステム開発を強制しちゃったりしてます。で、システム管理の素人集団&予算・納期の流動性がない環境の役所で厳密な管理なんかしちゃうので、トラブルによる遅延や工数増大に計画が耐えられずに破綻しちゃったり(人事・給与等システムなど)してかなり危険な様相です。

      また、まだ未施行ですが総務省行政評価局の「情報システムに係る政府調達の基本指針」
      http://www.soumu.go.jp/s-news/2007/070301_5.html
      で、システムを部品単位で細かく分割して競争入札すれば自動的に競争原理で安くて高品質なシステムが手にはいるので分割調達を強制しちゃったりしてます。で、調達本数が増える上に詳細な仕様の提示や調達計画書の作成など、調達にかかる行政コストが激増する上にベンダ間の仕様調整やモジュール結合テストの工数増大で、ロクな事になりそうにないです。

      パソコン買いたい素人に「メーカー製PCは割高だから、秋葉原で各種部品をそれぞれ一番安い店を探して買ってきて、自分で組み立てて作るべし。なお、買いに行くときは半年前から詳細な計画を提出すること」と言ってるようなものです。

      ・・・と、問題点の認識は正しいのだが根本原因を解消させないまま皮相的な要因だけを取り除こうとして大失敗、っぽい、田舎役所のような情けない状況ですね。

      さて、この事態、「じつは役所内のシステム運用の管理工数を激増させることによりコンサル・SIの官公庁需要を惹起し、それによってITゼネコン業界の確立と利権の独占を企む、経済界とK産省の陰謀なんだよ!」「な、なんだってー(AA略)」という冗談ともつかない噂が流れてます・・・。(涙)

    17. のんきゃり Says:

      半分当事者なもんで、勢いのまま書いたらかなりの乱文になってしまいました。すいません。

    18. 鍋象 Says:

      >>のんきゃりさん
      細かい情報いろいろありがとうございます。

      >システム設計の失敗や急な法改正で工数が増えたときは、業者に「泣いて貰う」リスクを見越しての単価設定です。

      それは泣いてもらうのではなく、普段笑っていてもらって、いざという時に普通の価格にしてもらうではないかと(^^;。まあ、往々にして普通の価格が常なのでしょうけど。

      >トラブルによる遅延や工数増大に計画が耐えられずに破綻しちゃったり

      >システムを部品単位で細かく分割して競争入札すれば自動的に競争原理で安くて高品質なシステムが手にはいるので分割調達を強制しちゃったりしてます。

      もしかして、これって破綻の範囲を極小化しようという深謀遠慮なのでしょうか(笑)

      基本的にはモジュール化は悪くないと思います。ただし、モジュール化の肝はモジュールを作る事ではなく、モジュール分割とインターフェース設計なわけで。捨てるところの明確化が大事になって、より設計側の比重が上がるわけですね。

      >「メーカー製PCは割高だから、秋葉原で各種部品をそれぞれ一番安い店を探して買ってきて、自分で組み立てて作るべし。なお、買いに行くときは半年前から詳細な計画を提出すること」

      それでも、AT互換機(懐かしいw)はインターフェース設計がしっかりしていますから、僕のようなパソコン素人でも手が出せます。その気になればISAレベルなら外付けボードを作ってしまう事も可能ですし、USBアダプタを利用して接続する外付け基盤くらい作れます。

      この辺の話は、何故か日本では苦手なんですよね。余裕のあるエンジン、余裕のある機体に共通化された部品で、凡庸な性能なれど高い生産性と拡張性を誇った米軍機と、非力なエンジンをカバーするために、独創的で芸術的な設計と、ほとんど手作りで、低生産性&拡張性の低さに甘んじ、生産力が足りないのに新型機開発というリソースを食う方向にいかざるを得なかった日本軍機みたいな。

      >じつは役所内のシステム運用の管理工数を激増させることによりコンサル・SIの官公庁需要を惹起し

      あ、もしかして業務用件定義とか概要設計の類は、コンサルタントへの随意契約だったりするのでしょうか?

      >と、問題点の認識は正しいのだが根本原因を解消させないまま皮相的な要因だけを取り除こうとして大失敗、っぽい、田舎役所のような情けない状況ですね

      なんというか、予算書に載る見かけコストの削減は一生懸命やっているけど、全体の行政サービスのコスト削減という問題を忘れちゃっているような感じですね。
      管理会計なんかでは最終の商品あるいは顧客という単位に全てのコストを還元させて、トータルコストが上がってるか下がってるか評価をします。とはいえ、各部署は社内のプロセスの途中段階で抜き出した指標を部分最適化しているに過ぎないわけです。こういう部分最適化箇所で過度に頑張りすぎると往々にして全体としての効率低下をもたらしたりするので、全体把握と各パートごとの力の入れ加減をコントロールするのが大事になるわけです。そういう意味では、力を入れる場所が正しいのか間違えているのか、盲目のままとりあえずわかりやすいところだけを部分最適化しているように見えます。

      そういや、某社団でも、予算審議の時に必ずでるのが、「ここの部分はメンバー(正会員)に自分たちで作業してもらえばタダです」というのがありまして・・・。メンバーというのはとても機会損失が大きい人たちだったりするのですが(汗)みたいな。

      >>bewaadさん
      本来のネタから逸脱してしまいまして申し訳ありません。

    19. webmaster Says:

      >のんきゃりさん
      情報提供ありがとうございました。

      先日、どこかの報道で、談合根絶のために入札を増やしたら、応札ゼロは増えるは品質検査は大変だはと何かと副作用もあるのだよね、ということが書かれていましたが、それと同様の文脈で論じられるような気がします。もちろん随意契約で怪しいことをし過ぎたせいであり、オール霞が関で見れば自業自得そのものですが、随意契約メインのままでの弊害防止措置の充実という対応も検討すべきだったのでは、というのは抵抗勢力の繰言としてしか処理されないわけでorz。

      >鍋象さん
      本来であれば、それこそコンピュータ関連の調達部門を一元化してそこではSEも採用して、それなりのリソースを割いてきちんとした検証まで行えるようにすべきということのように思いますが、実は昔は電電公社〜NTT系列がそれに近いことをやっていて、それが問題視されての現在ではあります。なまじ公社やらNTTやらだから問題視されるのであって、政府のインハウスにしてしまえば問題視はされないのかなぁ・・・。

      で、どうでもいい話についてであることは承知の上で。
      >この辺の話は、何故か日本では苦手なんですよね。
      >(略)
      >非力なエンジンをカバーするために、独創的で芸術的な設計と、ほとんど手作りで、低生産性&拡張性の低さに甘んじ、生産力が足りないのに新型機開発というリソースを食う方向にいかざるを得なかった日本軍機
      チハタンはオーソドックスな設計と(日本での相対的位置としては)高生産性&拡張性の名機でしたから! 後継機の不在ゆえに老骨に鞭打って第一線で頑張り続けなければならなかったことが不運なだけで・・・。

    20. webmaster Says:

      >鍋象さん
      補足というか書き漏らしですが。

      そうでない場合、価格以外の評価が可能なのか、ということではないかと思います。繰り返しで恐縮ですが、長期にわたる随意契約では、繰り返しゲームとなって裏切るインセンティヴが抑制されるわけですが、毎回入札となると、少なくとも裏切るインセンティヴが抑制される度合いは下がるわけで。予測不能性とは、ベストを尽くしてなお残る不確実性についての話だと認識していますが、そもそもベストが尽くされているかどうかをチェックすることがどの程度可能か、同業ながら怪しいなぁと(笑)。

    21. 鍋象 Says:

      >>bewaadさん
      NTT-DATAの前身ですね。僕は官庁くらいのでかいサイズならインハウスの方が効率的にできそうに思います。

      >価格以外の評価
      価格以外の評価というのは、実はアウトプット単位で計測したコストに還元されます。単位行政サービスあたりの費用とかですね。部分的に切り出して、そこだけ価格ダウンを求めるから漏れたところがコストアップしていきます。こういうのは得てしてトレードオフの関係にあります。

      たとえば、民間の流通業界では納品形態が変わるとコストが大きく変わりまして。バイヤーが見かけの商品仕入単価の引き下げを勝ち取ろうとして納品形態を簡素化しちゃう事が多々あります。その代わり、簡素化された納品形態に対して購買企業側がしなければならない裏方作業が発生して、トータルでは実はまったくコストが変わっていないなんて事が発生します。というか、なまじ一箇所にフォーカスしたがゆえに、他所でコストアップしている事は忘れられてトータルコストアップしている事が多々あります。
      コストダウンと称して行われる購買の値引き交渉は、本来はこの納品形態で変わる、納入業者側と購買側の一連の作業の中での引渡しポイントを動かして「比例費は下げるけど固定費は増える」みたいなトレードオフにおいて最適な業務分担を探す事で、トータルとして販管費のダウンを引き出す行為をさすはずだったのですが、何故か仕入価格引下げそのものをコストダウンと称するようになってしまって、「販管費が増えているぞ。何故だ?」みたいな事に陥ってしまうのでした。
      まあ、その次は、たとえばメーカーにまでさかのぼってPB化する事で新商品開発のコストをカットさせて下請け工場化する事で、仕入価格引下げなんて事をやりますが、これ、そのうちにこうやって囲い込んだメーカー製品が陳腐化していって、自社の商品力に響くんだろうなぁと思うわけです。

      まあ、システム開発では、現実的には事前想定がほぼ不可能なトラブルが起きてくるという不確実性もあるのも別の問題であります。開発都度予備費を基金に積み立てて、不意のトラブルに対処できるようにしとくのが良いと思います。裏でやるから裏金になるわけで表でやればよろしいかなと思ったりします。

      >裏切るインセンティブ

      これは「確実な報復」とセットで起きるものなので、報復側が相手を慮ってしまうと機能しなくなる可能性もあります。

    22. webmaster Says:

      >鍋象さん
      価格以外という書き方をしましたが、短期と中長期といいますか、とりあえずの支払い段階の金目とその導入による影響がうまく総合評価できないということなのでしょう。導入段階で品質評価をし、何らかの問題が生じる可能性をそれなりの精度で見通せればよいのでしょうけれども、それがなかなか、ということなのかなと。究極的にはリスク負担の問題であって、どのような部分までなら発注側、それ以外は受注側の責任で対応という仕分けをきちんとしろということなのでしょうけれども。

    23. リリカルゴルカルApple100% blog遺跡 Says:

      30秒で理解できる日本の政策決定プロセス…

      どこが間違っていて、どこでデスマになるかはIT業界の方なら一目瞭然かと思います。 一応、一般人の方のために頻出台詞を想定しておきます。 有識者1「諸外国には武蘭虎なる (more…)

    Leave a Reply

    TrackBack URI