人月計算とか一山いくらじゃなくて、経営計画に沿ったITガバナンスをしよう

development

はてブホッテントリから、システム開発における人月計算やら情報システム部門とベンダー企業の内部完結的な蜜月関係についてなどの話題を扱った Togetter のエントリが流れてきたので、読んだ。以下はその引用と自分の意見。*1

一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス

一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス - Togetter

「人月見積」がだめなのではなくて、「一山いくらの人月見積」がだめなんですよ。八百屋が野菜売ってるんじゃないだから「グラムいくら」みたいに売るのがだめだってこと。人に値段をつけてりゃいいのです。人月300万の人もいれば50万の人もいる、ってのならいい。

  • これは、かつ、年齢が高いからって理由じゃなくてちゃんと能力に応じた金額設定がされている前提かと思う

ついでにいうとユーザー企業でもITガバナンス力を身に付けた担当者がいる「ライン」のほうで独自にベンダー外しの動きが始まっている。むしろ同じ社内の情シスに任せずに。任せられずに。ユーザー企業の社内でラインと情シス・調達部門の利益相反が顕在化してきた。情シスとベンダーの蜜月関係は、ラインから見れば「どっち向いて仕事してんだ」と。自社の、事業の利益になるのかと。大きなインフラ固定資産と予算を抱えた情シスはユーザー企業のなかで大きな既得権益を持つのだが、その既得権がICTのROIを著しく下げ、事業環境の変化に適応する機敏さ(agility)も殺いでいる。"

  • ユーザー企業のIT担当(部門)の動きが始まっている、という意見
    • 逆に、こちらが受注する際にも発注側の内部の事情 (IT システムを導入する目的)、その数値目標は何か？をきちんとヒアリングするということを頭に入れておかないといけない

ぼくはそのポジティブシナリオがすぐに来るとは思えない。ITを理解してないロートル経営者が退陣するのを待たねばならないと思う。世代交代が必要。興味深いのは大企業であっても創業経営者がトップに健在の企業ではIT活用が進んでいる事例があること。ユニクロやソフトバンクを見よ。ITがカネになると理解した企業家は、リスクをとる。サラリーマン経営者"successor"の多くには、このアニマル・スピリットがない。リスクは回避するものだと思ってる。失敗は敗北だと思ってる。一勝九敗でいいとは考えない。

  • 目先のリスク、利益に振り回されて中長期のリスクに見事にやられている例を見かける。下手な新規事業や流行り廃りの、自社事業と関連が薄いものにばかり金を出して社員の教育費など必要なコストを払わないために企業力 (売上)が落ちるという悪循環に落ち入ってしまう、など

「アジャイル」を「終わった」という人は相対的に少ないが、それは「商品」になりにくいからでは。「SOA」は「商品化」されて、売れなかったから、「終わった」と言われるのだろう。私は「SOA」を商品ではなく設計思想だと考えているのだが。
SOA の "A" が特定の製品でも実装技術でもなくて、"アーキテクチャ"に問題意識の焦点があたっただけで画期的なことだと思ってます。古びさせるにはあまりにももったいない。

  • アーキテクチャに手を入れるってことは、既存のシステムやら業務体系にメスを入れるってことだからなかなか導入は難しい。だけれども、それをやらないと時間を経る毎に腐っていく。それを理解した経営者たちは、多少の目先のリスクを抱えてでも設計 (再設計) という大仕事に取り組んでいくのだろう
  • Y Combinator の Paul Graham が言っていた言葉が沁みる。"自分で技術者を見つければ、可能性は約10倍、高くなる。"*2。経営の視点を持って本気で技術に取り組むと、それにより出来上がったサービスは 10 倍以上になる。

(関連)なぜ人月見積がダメか

  • なぜ人月見積がダメか
    http://zerobase.jp/blog/2007/12/post_18.html
    • 開発者の能力、付加価値を無視すること。
      • プログラムを機能別で価格を設定するということは、開発者の能力、付加価値に報酬額を設定することにほかならない？
    • しかし機能別の評価、例えば FP 法はデザインが評価に入っていない
    • UI デザインで機能を減らすと FP 値が減って価格が下がる。
      • ここで、例えば「ユーザ数いくら達成」とか「社内の工数が XX % 削減出来た」とか条件を決めて報奨金をもらうようにすればいいのではないだろうか。デザインが優れているということはユーザが満足のいく使い勝手を得られたということだから、この設定であながち間違いではないはず。

読んでる時に調べた単語

ことば 説明
ICTベンチャー Information and Communications Technology の略*3。それのベンチャー。
ROI Return on Investment (投資利益率)
EAI Enterprise Application Integration (業務アプリケーション統合)。企業内で業務に使用される複数のコンピュータシステムを有機的に連携させ、データやプロセスの効率的な統合をはかること。また、それを支援する一連の技術やソフトウェアの総称。SOA の前身。
SOA Service-Oriented Architecture (サービス指向アーキテクチャ)。サービスをネットワーク上で連携させてシステムの全体を構築していくことを指す。Web サービスで構築することが事実上標準になっている。
DSM Design(Dependency) Structure Matrix (デザイン(依存)構造マトリクス)。各タスク (またはコード) をマトリクス上に並べ、あるタスクが完了時にどのタスクへその情報が渡るか、またはあるタスクを実施する際にどの情報が必要かを可視化する手法。
http://www.itid.co.jp/process/develop/dsm.html
出来高(アーンド・バリュー) 米国での開発の成果物の出来具合を計るための数値。米国では、このアーンド・バリュー方式と報奨付きの契約がセットになっていたためこの商慣習が普及した。
報奨付きの契約 あらかじめ決めた開発コストの範囲で開発を終えた場合、顧客がインテグレータに報奨金を支払うもの。金額の例は、総開発コストの何％、など。

*1:Togetter は Twitter のユーザー同士で集まって意見を集約出来るのでさくっとまとめやすい一方、単に発言を羅列しているだけなのでまとまりが悪く、可読性に掛ける。自分がまとめたいと思った情報はこうしてまとめないと、本当にただ読んで終わりになってしまう、、、

*2:http://d.hatena.ne.jp/lionfan/20110207#1297050051

*3:IT が時代に即した表現ではないから変えたのかな？でも今まで知らなかったわ