タイトルが長いのは仕様です(挨拶)。
実際のところ、キャリアの多くの期間は銀行・信金以外の金融機関を担当していたので、「お前が知らない世界もある」と言われると否めないため、予防線を張ってみた。そう、へたれである。
前々職では業界縛り無しの期間もあったし、前職では中小企業をやってたんで、大きな抜けは官庁・自治体くらいだけどな。
CIOの主張 - 「なぜもっとパッケージを使わないんだ」と海外CIOから指摘受ける、キリンCIO：ITpro 
いやパッケージ使えばいいじゃん。商習慣じゃなくてパッケージに100点満点求めるから採用できない。その代りに自製したものは80点以下でも許容される矛盾。 / “CIOの主張 - 「なぜもっとパッケージを使わない…” http://t.co/dstE5zkggk #biz #Tech
— ꧁🐶꧂ (@shigeo_t) 2014年1月13日
コメントした通りではあるんだが、こういう大企業はほんとうにパッケージ選定には敵が多い。負担できるIT投資金額が大きいだけに、パッケージでもスクラッチ開発でもいずれも選択肢になるわけだが、なぜスクラッチ開発が選択されることが多いのか？
まず、パッケージと大まかに言うと話が収束しないので、パッケージ種別の分類を行う。「地方にITエンジニアは必要か？(その2）」でも使った図である。
今回の話は、レイヤとしては図でいうとグループウェアよりも上が該当する。いくらなんでも自前でOSやミドルウェアを作る非IT企業なんて無いし。いや、ミドルウェアを作る企業はある。競争優位を生むために必要に迫られてという場合もあるし、作った奴を外販していて損していない場合もあるので、そういう作り方であれば合理的な判断と言える。
でもかつて担当した中には、通信プロトコルを自前で持っていた某証券会社があった。今は無いけど。通信プロトコルが独自ということは、通信プロトコルをハンドリングするソフトウェアはミドルウェアから組み込みソフトウェアから全部専用が必要。そこも全部内製ならある意味コストコントロールができるけど、費用を積んでベンダに作らせてた。TCP/IPが普及する前でトークンリングだったけど、営業店とかに設置する通信機器に全部専用ソフトが入っているわけ。通信機器のドンガラは各ベンダの標準品だけど、出荷前に全数その通信プロトコル専用ソフトウェアを入れてテストしてとかやってたら、そりゃ高くつく。そんな無駄遣いするから、業績不振になった時に既存IT資産が負担になって破綻するんだよ。ちょっと縮小しようとしても大金が必要なんだもん。どことは書かないｗｗ。メインベンダ2つのうちどっちかが、そういう極悪な提案したんだろうなあ、オレはヤバくなってから～そろそろ限界かもってくらいの期間しか担当してなかったペーペーだったからよくわからないけどｗ
そういう経験があるんで、前々職で上司が顧客に貸与する機器の導入にあたって、業者から我々のブランドロゴのシールを貼って納入する提案を受けた時、「いらない。次の調達で足枷になるから。」と拒否したとき「分かっているなあ」と思った。
と、話が脇道にそれた。話を戻す。今回の話は、レイヤとしては図でいうとグループウェアよりも上ということにする。流石にオフィスソフトを自製しないでしょ。
元記事で他国のCIOから「パッケージをもっと使うべき」と言われたのは、多分グループウェアよりも上のレイヤだと思う。
まず、そういう指摘をする他国の企業では、下記のロジックで極力パッケージを適用する。
- Aという業務を包含するパッケージは無いか？
- パッケージA1～Anの中でもっとも自社に適合するものはどれか(Fit&Gap分析)
- 候補Aa、Ab、Acの中で最も導入コストが低いものはどれか？(パッケージ費用、カスタマイズ・アドオン開発の費用、現場の作業工程変更に掛かる費用の総和を比較)
- じゃあAbに決定→パッケージ導入して、カスタマイズ・アドオン開発をして、現場に落として、システム移行
多分、日本企業の情報システム部門の人は、上の手順でパッケージ適用できるとは言わないだろう。全く手順が違うから。
- A業務の現場に現在の業務内容・手順をヒアリング
- A業務用のパッケージ候補を持ってきそうなベンダにRFI(Request For Information )で投げる
- RFIに応えて上がってきたパッケージの中で候補選定(パッケージ費用、ベンダとの親密度)
- RFP(Request For Proposal)をベンダに出してコンペの上、ベンダ選定（提案してきた総費用、スケジュール、ベンダとの親密度などで決定）
- 受注ベンダが開発プロジェクトを開始
- 発注企業の要件定義はRFPに書いてある程度のものしかないので、もう一度要件定義ということでA業務の現場に現在の業務内容・手順をヒアリング
- 現場はあまり現状と変えたくない(便利にはなって欲しいのに)ので、WhatをヒアリングしてもHow山盛りで要件がまとめられる
- 同じ発注側企業内でさえ(一般的には)情報システム部門よりも現場のほうが発言力を持っているので、発注企業─受託企業ではさらに力の差がある。そのため、仕様のコントロールが効かず、受注ベンダは費用が折り合わないので再提案しようとプロジェクトをロールバック
- 再提案はパッケージ適用じゃなくスクラッチ開発への変更（場合によっては再RFP→コンペに)
あ、完全にパッケージ適用で始めたはずのプロジェクトがいつの間にかスクラッチになってしまう例を書いてしまった。パッケージ適用のままとしても、
(A)プロジェクトそのものがストップ／無期延期
(B)費用感を見直して発注側が費用負担できるので発注額増で続行
(C)とにかくカスタマイズ・アドオン仕様を削るサブプロジェクト発足
ということでまあ大変。これじゃあ、情報システム部門発案でパッケージ適用なんて話にはならない。関係者の寿命が縮む。
他国の企業がさっくりとパッケージ導入が進むのに、なぜ日本企業ではうまく導入できないのか。答えは簡単。トップダウンかボトムアップかの違い。もうひとつは就業規則の違い。
まずトップダウンとボトムアップでどういう差異が起こるか。どちらがいいということは言ってない。差異のみ。下図に示す。
右上にあるようにボトムアップでいくと、現実解に留まる。トップダウンがいいのかボトムアップがいいのかは結果論。しかしトップの意思で物事が動けば、とりあえず『現状よりも何かが改善する』ことが見込めるパッケージ適用が完遂する。
就業についても文化的な差異はあるが、最も大きな違いはジョブディスクリプションの有無。ジョブディスクリプションについては、Wikipediaから引用する。
ジョブ・ディスクリプションは、職務内容を記載した雇用管理文書である。労働者の職務を明確化することによって「働きの度合い」と「賃金」を繋げる役割がある。成果主義、成果給を導入する際には不可欠なものであり、企業の人事考課方針などに使用される。
日本企業の場合はジョブ・ディスクリプションを明確に示す習慣がほとんど無い。欧米から来たファストフードなどではいわゆる「マニュアル化」と呼称される形で提示されるが、オフィスワークできっちり提示している日本企業は寡聞にして知らない。これがパッケージ適用の敵になる。
その部署や業務に就いて、暗黙知を含めて個々の従事者が修得したモノがその業務の仕様ということになる。会社から「○○を△△の手順でやれ」「◇◇は別部署の業務」とか文書で提示されないわけで、どうしても属人化は防げない。従事者本人がどう思うかという主観を排除する仕組みが無い。
ボトムアップなのでそういうところにヒアリングに行く。ここでアンビバレンツな要素が付加される。ヒアリングされた従事者は、
- 今よりも便利になって欲しい
- 今とあまり変わって欲しくない
という矛盾する意見を持っている。例を出すと、手順・手間そのものは減って欲しいけど、画面や帳票の見た目は変えたくない、とか。今まで手書き帳票が廻ってきて自分でポチポチ画面入力したものを、パッケージ仕様だとOCRでガっと読ませて、画面や帳票で確認すればいいというパターンとかありがちだが、画面を変えるなと言われるとパッケージ屋さんからすると画面や帳票大改造じゃんということになる。現場の従事者からすると、画面や帳票の見た目（というか個々の情報の置き場所）がちょっと変わるだけで再度覚えなおしだし、意見求められたから意見出しただけだしーみたいな感じ。語尾を伸ばすのも仕様みたいな。
そういうことが積み上がってくると、100点じゃないからパッケージが使えないみたいなことになる。開発コスト的にも。ボトムアップなのですごく積み上がる。現場の要求仕様を実現するためには、スクラッチで作ったほうが安いという他国の企業ではあり得ない話。そしてスクラッチ開発したシステムはパッケージに比べて業務の包含度が低くてあまりコストダウン効果が無いとか。スクラッチ開発の場合は、それなりのスケジュールと開発要員が必要なので、最初からフルスペック稼働は難しかったりするし。
トップダウンの場合は基本的にジョブ・ディスクリプションを改訂するだけなので、パッケージを使った新システム稼働に向けては、現場の研修や現場へのヘルプデスクをどうするかとかそういう前向きな話に進むのだが。
まだまだ書くことはあるが、ちょい長くなったので急にまとめる。
どうすべきか？元記事のインタビューイは「常務執行役員情報戦略部部長」という肩書だからCIO相当だよね。答えは簡単でトップダウンでやれである。問題はCIOではなく、どうCEO/COOからトップダウンで落とすか。それぞれの業務の現場はCIOの配下ではない。企業全体としてパッケージ適用を完遂するという意思と、現場業務の変化に対する全力のサポートをきちんと提示する必要がある。基本的には現場の意見はほぼ聞かないわけで、人の気持ちってものを考えれば疎外感を排除し安心感を持たせるというコミュニケーションが必要。そういう部分まで全てデザインするのがCIO以下情報企画・情報システム部門の役務。それは簡単じゃないけど、パッケージ適用しようと思ったらスクラッチ開発になって費用1.5～2倍なんて話よりはラクなはず。
そしてスクラッチで開発すべきなのは、競争優位を獲得することができるもの。パッケージ適用できる部分に費用・労力を投下して疲弊してはいけない
と、日記には書いておこう（龍角散トローチの昔のCM）。このネタのための前振り長いわｗ。
