第66回例会報告
今回は、BSIAパートナーシップ分科会からの発表です。タイトルは「こうすれば良好なパートナーシップが構築できる！～ITベンダーの力を借りてプロジェクトを成功させる秘訣～」。
日本の企業システムの開発運用は、その多くを外部専門会社（ITベンダー）に依存しています。その一方、クラウドサービス等の充実でユーザー企業がシステム開発を主導しやすい環境が整ってきたとも言われています。しかしながら、その分ビジネスの変化も技術の進化もスピードは加速し、複雑化しており、やはりITベンダーの力を借りないことには企業システムは成り 立ちません。しかし、主役（最終責任者）は、あくまでユーザー側のはずです。ユーザー企業とITベンダーが良好なパートナーシップを構築する為には、お互いにどう取り組んだらよいでしょうか。
＜BSIAパートナーシップ分科会の活動＞
当分科会ではこのような問題意識を持って、月例でさまざまな業種の、さまざまな立場のメンバーが、自分が関わったプロジェクトのパートナーシップ構築の成功例・失敗例を発表し、成否の鍵となったポイントは何だったのかを議論しています。
今回の発表では、その中から、
・数十のマルチベンダーで進めた大病院のシステム構築プロジェクト成功のポイント
・トラブルの原因となりやすい要件定義がうまくいくアイデア
・情シスメンバーの人財育成におけるITベンダーとのパートナーシップ
など、具体的な事例を6つご紹介いただきました。
＜発表＞
「プロジェクト成否のカギ」 －要件定義の齟齬をなくせ－
鈴木由里（さくら情報システム）
要件定義の齟齬をなくせ
ITプロジェクト失敗の原因の多くは要件定義にあるといわれている。では何故要件定義工程で齟齬が発生するのか？その原因は様々だ。旧システムと同じ機能を，と言ったが旧システムの全機能を洗い出せなかったとか，表面上の要求は確認し文書化もしたが，テスト・検証フェーズで細かいニュアンスの違いが多く発生したりとか，そもそもユーザ主導ではなく，IT部門が主導でプロジェクトが進行するなどなど。
突き詰めていけば，情報システムというものが不可視なものであり，それが口頭で伝えられたリ，明文化されなかったりということでイメージの共有がなされないことに尽きる。
実際の事例をベースに具体的に検証していこう。
・事例1 ソーシャルメディアの課金システム
Excel，アクセスで運用されていた業務のシステム化案件。要件定義は，他社が実施したものを引き継いだ。その仕様は一見まとめられているように思えた。しかし，実は記述されていた要件は，氷山の一角であった。要件の再定義を3か月かけて実施した。それでも妥協をお願いした機能もあった。
この事例では，明文化された要件定義ドキュメントが存在しており，それを製造すればいいという前提でプロジェクトを引き継いだことに問題があった。業務要件というものは，どこまで行っても資料に記述しきれない部分がある，という前提で取り組むべき案件であったといえる。
・事例2 工程管理システム
この案件は，要件定義によるプロジェクト失敗を上手く回避した事例である。
まず，この案件は条件が良くなかった。関係者のロケーションは，東京・名古屋・アメリカ・中国と4か所に分かれている、言語も異なるという状況であった。
だからこそ，コミュニケーションの設計に注力をした。具体的には，インターネット上でのコミュニケーション環境，モデリングツールなどによるイメージの共有，何をいつまでに誰と合意するのかということを事前にコミットするなどを行った。特に動画ツールを使った仕様確認，マニュアル作成などのコミュニケーションが効果的であった。成功のポイントは，早い段階での合意形成，実現性のある完成形のイメージ，ToBeの業務フローを早期に掴むことがあげられる。
・パートナーシップ向上に向けて
同じイメージを共有するためには，早期に試行運用ができること，実運用の観点でのレビュー，運用イメージの早期確立が大切なポイントとなる。これらをサポートするツールとして，クラウドを活用した「動く仕様書」で要件定義を行うことなどは効果的だろう。（https://www.sakura-is.co.jp/solution/ps-000-109.html）
「マルチベンダーだらけでも成功する方法～病院の大規模システム構築プロジェクトから～」
宇羅勇治（ITコンサルタント）
医療関連の情報システムは，オーダリングシステムが先行して導入されてきた。オーダリングシステムとは，患者の検査や，薬の処方情報を伝達・共有するシステムをいう。これに医師の所見を加えるという形で電子カルテは進化してきている。但し，日本はベンダーが集約されていないなどの理由で海外より導入が進んでいないといえる。
電子カルテに関する要件は，下記の3つが定められている。
・真正性：正しさを保証すること
・見読性：いつでも閲覧できること
・保存性：復元可能な状態で保存すること
これらは，紙のカルテ時代とは異なる方式で実現しなければならない情報システムの課題である。
電子カルテシステムと，それを支える総合医療情報システムは3つの階層がある。それは，最下層の医療機器レイヤー，次に部門システム，その上に電子カルテシステム，という構成となっている。この中の医療機器と部門システムのレイヤーは，一つのベンダーに統一することが難しい。また医療機器の機器変更，部門システムの更新などによる変化が激しい。検査等の数値の精度などが変わることもある。これらの上位に位置する電子カルテシステムは，下位システムの変化に対して柔軟に対応しなければならないものなのである。
・運用設計
だから，電子カルテシステムの導入においては運用設計が重要になる。部門システムが停止した時に，電子カルテはどう動作するかなど，考慮点は多い。
また，総合テストは実業務に沿ったシナリオを設計し複数回の実施が必要であろう。
業務を安定的に運用するために，一次ヘルプデスクを常駐することとした。この一次ヘルプデスクは，IT運用と医療の知識が両方必要とされる。具体的には，PC等が壊れた場合に即時対応を行ったり，研修教育を行ったりという作業を行う。
次に，運用監視ソフトウェアも大切である。全システムのPC，ネットワーク機器等の監視を行い，ログを収集する。そのログは一次ヘルプデスクが解析を行い予防に役立てる。またバックアップ，データの世代管理なども重要だ。特に画像データなどは大容量になる。これらは古い分をDVDに記録するなどの工夫を行った。
これらの運用体制を支えるのは，やはり人材である。その人材の育成も戦略的に行った。部門システムや医療機器など，マルチベンダーをコントロールし折衝できることや，トラブル時に医療停止時間が最短となるように対応できることなどが要求される。
最後に，このプロジェクトにおいては，それを成功に導いたトップの言葉があった。それは，病院長からの「使ってみて改善することが大事である」というものだった。
「ITベンダーのIT化は簡単？困難？ 」～ベンチャーマインドと上場責任の葛藤～
田中琢馬（テクノスジャパン）
テクノスジャパンの田中様からの事例は，ITベンダーが自社の基幹業務システムを構築するという事例である。
その基本方針は，開発の外部発注，パッケージベースの導入，サーバはクラウドを利用，構築後は子会社展開を，というものであった。
しかし，実際にプロジェクトを実施してみるといくつもの問題が発生した。それは，仕様変更の発生と外製化によるコスト増加，それによるスピード低下，管理会計のレベルダウンなどであった。管理会計に関しては内製でエクセルを利用するなどして急場をしのいでいる。また，テクノスでは組織変更及びそれに伴うコンセプト変化が激しい。それによる仕様変更も余儀なくされた。
もちろん，IT企業であるから社内に技術者は多く存在する。しかし，これら人員はお金を稼ぐ存在であり，メーカでいえば製品/商品にあたるもの。だから簡単に登用することは難しい。それゆえ外部発注となるのだが，企業戦略や管理会計の方式などの変化による仕様変更が重荷となっている。また，従業員も自社の基幹システムにそもそも興味がないということも問題だ。
現在，このプロジェクトは構築の途にあるが，社内システムというものの特性を見ることができる。それは，社内システムというものは，その企業文化を色濃く反映するということだ。ベンチャー色が強ければ企業戦略は刻々変化するだろう。きっちりかっちりという基幹システムであるが，構築している端からコンセプトが変わっていくのであれば永遠のプロトタイプという気持ちで取り組む必要があるかもしれない。
「ユーザーがまじめなら、委託先は応えてくれる 」－シンプル まじめ 相互信頼－
佐々木典夫（元山之内製薬（現アステラス製薬））
・外部委託の多い製薬企業の事例
ITプロジェクトは失敗が多いものだが，成功のカギはユーザ側がまじめに取り組むことが肝要である。そして後述するSCOT理論を適用しプロジェクトを成功に導いた事例である。医薬業界の事例であるが，その中でも医薬情報担当者（MR：Medical Representative）のSFAに関する領域を取り上げる。
・SCOT理論
S：Skill
Skillは，ハードスキルとソフトスキルに分かれる。そして，ハードスキルは，ビジネススキルとOAスキルがある。ビジネススキルは業務及び仕事そのもののスキルであり，OAは道具としてのOfficeツールを使いこなす能力をいう。
ソフトスキルは，情報共有の心のことだ。ハードスキルに増して重要な要素と言える。
C：Contents
Cはコンテンツであり，データベースを構成するトランザクションやマスターが該当する。
O：Organization
Oは組織である。これは，その企業の風土，文化，体制，人員評価モデルを指す
T：Tool
Tはツールである。これは，情報システムの利用者，情報システム部門，パートナーが力を合わせた結果として出来上がる，ハードやソフトとなる。
これらの要素は，システムのライフサイクルでその重みが変わってくるという特徴がある。
・SFAの事例
MRのSFAに関する事例になる。初期の導入は1991年にさかのぼる。この時はメインフレームが基盤であったが，失敗に終わっている。その原因は，MR活動の法規制の変化の問題が大きかった。但し，マスターの不備（Contents）や，MRがコンピュータを使いこなす能力（Skill）も不足していたことも一因であった。
次に1996年に第2次のSFAを導入したがこれも問題があった。その問題はコンテンツそのものと言えた（Contents）。魅力的な情報がMRに提供されないと利用は推進されない。これは質的・量的両方が不足していた。また，MR自身が入力する情報も不正確なものが見られた。（Organization）
そして，1998年に成功に転ずる。その要因はコンテンツの大幅な充実（Contents）と，バックオフィスサービス（Organization）の強化である。SCOTのT，つまりツールに関しての不満は許容範囲のものであった。
・まとめ
各人員のロールとSCOTにおいて，特に重要なポイントをまとめる。
まず，経営，役員等のマネージャ層においては。Skillにおいて，システム化の目的の理解，実現に向けての責任が重要となる。また，人事異動の後任者への継承も大切なマネージメントである。
ユーザ及び情報システム部門は，Organization要素として，実現への責任感を持つことが重要となる。パートナーにおいても，Organization要素が大切だ。具体的には，悪い情報こそ迅速に情報共有することなどがあげられる。
ユーザ企業とパートナー企業は対等でなければならない。そのために大事なのは，シンプル／まじめ／相互信頼だ。
「官庁にだってできるんだ。」パートナーシップ実現へのチャレンジ
土肥亮一（会計検査院）
会計検査院は，税金で運営されている各種団体の監査を行うことを事業としている。
その会計検査院に籍を置く立場から，情報システムはどのようなものであった欲しいのか，パートナーシップに対する思いを発表したい。
・欲しいものはわからない。
ITプロジェクトの大問題である要件定義。それは何が欲しいのか？から始まる。しかし，そもそも，利用者は何が欲しいかわからないのではないか？
妻と夫の会話を想起してみてほしい。妻が夫に，「今晩何が食べたい？」と聞き，夫は「何でもいい」と答える。この状況が要件定義の本質をとらえている。
では，それぞれの思いはどうか？ユーザは，うまく仕事をこなしたい，ストレスなく使い生産性を上げたいということが第一だ。情報システム部門は，これに答えるために先回りし進化したサービスを提供できることが望ましい。
その情報システムはLEGOのようにあってほしい。LEGOは簡単であり安価で使いやすい。イメージの共有も思いのままだ。
LEGOのようにイメージを容易に共有できれば齟齬もなくなるだろう。但し注意も必要だ。それは，言葉では表現できない情報というものが存在するからだ。それは，企業や文化において，当たり前すぎて文章化されないような情報をいう。奈良時代のトイレ事情は分かっていない。それはあまりにも当たり前すぎて文書にならなかったからだ。
・パートナーシップ改善
特に官公庁の案件を受注するときの受注者には，無意識のバリアがあったりする。もちろん大きな誤解であり民間企業と変わるところはない。
そして，パートナーシップ改善は，コミュニケーションモデルのそれと通じる。具体的には，システムレビューを受注者側のオフィスで行うことだったり，プロジェクト担当者を固定することだったり，懇親会の企画だったり。コミュニケーション環境を改善するという実に基本的な行いが大切なのである。
・会計検査院の事例
公務員というものは，マネージメント教育が不足している。それでいてマネージャに昇格するという問題がある。
そこで，IT検査スキルアップ研修を始動させた。2005年にさかのぼる。これはIT研修でもありマネージメント研修でもある。研修は3年をかけ，卒業すると協力者となる。現在10期性まで育っている。
また，「IT検査人材育成・活用戦略」としてIT人材の採用，調達の計画的な配置を行っている。その中では，大学院やIT関連企業への出向などにより育成戦略も含まれる。
・まとめ
外に視野を向けることで，楽しく，理解も進む。それによりコミュニケーション環境が改善され，よりよいパートナーシップが構築することができるだろう。
「ユーザーが腹を括ったことで成功した話」～ Windows NT 基幹システムを通じて ～
舛巴 智（富士通 元花王）
舛巴様の発表は，パートナーシップの分科会としてではなく，ゲストスピーカーとなる。
内容は，花王時代のWindows NTシステム導入の事例である。
・EUC
1995年ごろ，EUCという言葉が使われるようになった。そこで，Windowsパソコンを導入した。当時は，Windows3.1，Accessは1.1であった。その時，AccessがEUCに使えるという手ごたえを得た。そしてそれは，ノンプログラミングを前提とした取り組みであった。
・汎用機からNTサーバへのダウンサイジング
最初は社内で抵抗もあった。ダウンサイジングはLinuxの提案もあったがWindows NTを採用した。これは，プログラミングやコマンド操作を行わないEUCを実現するためのこだわりがあったからだ。
結果としては，Accessのフォームを400本，レポートを200本など，ほぼノンプロミングで作成することができた。どうしてもプログラミングしなければならなかったのは，モジュラス11チェックなどの7本だけである。
ノンプログラミングなのでエンドユーザでメンテナンス可能である。おまけというわけではないが，音声によるガイダンス機能も実装した。
これらは，日本初のNTサーバ基幹システムであった。汎用機5台をNTサーバ1台にし，画面検索のレスポンス，バッチ処理の時間も大幅に改善された。
その後は，サーバを更新していきながら数年後には汎用機時代の15倍の性能を実現した。
プロダクトのバージョンアップも容易であった。これもノンプログラミングであったからだ。コードがなくクエリー中心のシステムなのでスムーズな移行が実現できた。
結果，15年間して幕を閉じたが，1円の誤差もなく運用を終了することができた。
・まとめ
では，何故このような成功を収めることができたのか。それはもちろん，ノンプログラミングのこだわりもあるが，ユーザ企業主導のマネージメントが大きい。プロジェクトマネージメントを外部のSIベンダーに求めてはならない。自分たちが腹を括り，信念とこだわりでプロジェクトをやり遂げることが肝要だ。
提言「ベンダーによるロックインは悪いことなのか？」
安藤和美（花王ビジネスアソシエ）
花王ビジネスアソシエの安藤様からのプレゼンテーションは，当パートナーシップ分科会とは関係はなく，個人としての提言という形で話をいただいた。
・背景
ITの技術領域は拡大するも，人材の育成が遅れている。また，ITベンダーも様々に多様化している。ERPベンダー，SI，ツールベンダー，クラウド運営業者などだ。
特に，デフォルト化されたERPの保守料金の高騰に，IT予算の多くが食われている。ガートナーの調査では，このようなツールの保守料を含めIT部門は9割が保守に予算がとられているとのことだ。これでは新しいシステムの企画，予算確保ができないという苦しい状況にある。
また，同じくガートナーの調査では，企業のIT支出の29％が情報システム部門ではなくビジネス部門から出ているという。
・施策（2015年）
このような背景の中，どのように打開をするかを模索してきた。2015年の提言では，アジャイルを基盤にした「納品のない受託開発」というモデル，または超高速開発モデルへの移行というものであった。だが，やはり予算がとれないと問題が解決できないというジレンマを抱えた。
・施策（2016年）
ではどうするか？
2016年の提言ではあったが，再度提示したい。それは，事業部門によるシステム化だ。つまり，事業部門（ビジネスユーザ）が，第2のIS部門になること。競争力の源泉をビジネス部門が自らイニシアティブをとり推進することだ。
すると，ビジネス部門が直接ベンダーとのパートナーシップを構築することになるだろう。もちろん，ITベンダーは情報システム部門に，なんら気兼ねせずにアプローチしてもらいたい。
質疑応答
花王ビジネスアソシエの安藤さまへ
・ビジネス部門とITベンダーがパートナーシップを構築するときに，ビジネス部門のITスキルが不足していると難しいのでは？そのような時のベストプラクティス，コツなどはあるか？
当社の事例では，情シス部門をスピンアウトした人員がキーマンとなるように仕向けた。また，ビジネス部門でのIT導入も，クラウドサービスという形式で利用料を月額支払うとすれば導入しやすいのではないか。また，企業として各部門に「情報システムプロデューサー」というような職務を認知させることが重要だ。
・ビジネス部門でのシステム導入は，部分最適，人依存になるのではないか？
そのシステムを利用しての結果責任は部門にある。だから人に依存していて，その人員がいなくなったとして不要ならやめればよい。必要なら引き継げばいいだろう。
・ITベンダーとのパートナーシップとなると，IT以外のスキル，具体的には企画能力やコミュニケーションスキルが必要になるだろう。このような育成についてはどうだったか？
これはやはり難しい問題だと感じる。
実際には教育のアウトソーシングも行った。ITベンダーに出向のような形で武者修行にも出した。結果が出たかどうかは難しいが，結局はマネージメントが重要だ。マネージメントスキルを育成することが大切になるだろう。
