情報システム学会　メールマガジン 2010.1.1　No.05-09 [5]

PDFは http://www.issj.net/mm/mm0509/mm0509-5-sg.pdf

第１０回「情報システムのあり方と人間活動」研究会　【概要報告】

研究会　渋谷・伊藤

　　　詳細は、情報システムのあり方と人間活動第１０回講演資料
　　　　　http://www.issj.net/mm/mm0509/mm0509-5-sg-shiryou.pdf
　　　を参照ください．

■開催日時　平成２２年１１月１３日（土）午後１時３０分～５時
■場所　　　慶應義塾大学日吉キャンパス協生館６階大会議室
■参加者人数　　２０名
■講演題目　「ＩＣＴに関わるユーザー・ベンダーの信頼関係構築」
　　　　　　　～ＩＣＴ関係者のパートナーシップ確立に向けて～
■講演者　　ＤＩＣインフォメーションサービス（株）
　　　　　　代表取締役社長　小田　滋氏

【講演者略歴】
１９７７年　ＤＩＣに入社後、事業部で新製品開発
１９９０年　原料部門で国際調達の組織立上げと購買情報のDWH構築
２０００年　市場開発部で新事業の創出
２００１年　情報システム部門
２００３年　ＤＩＣ情報システム部長
２００９年より現職
経済産業省やＪＵＡＳの部会・委員会・コンソーシアムのメンバー

【講演要約】

　・ＪＵＡＳでは過去２年間、主要ユーザー企業とベンダー企業の議論を通じてパートナーシップ関係強化を報告書にまとめた．“ＩＴ経営普及促進に向けた調査研究報告書”平成２１年度ＭＥＴＩ委託調査

　・ＪＵＡＳでは毎年“企業ＩＴ動向調査”を行い、システムにおける課題を現場目線・経営目線・ＩＣＴ目線で分析している．また“ソフトウェアメトリックス調査”では、システム開発について定量分析を試みている．

　・ユーザー企業においては、“経営者・システムオーナー・システム利用者”と“社内IT'er”は区分され、社内IT'erはＩＴベンダーにより近い立場となるが、ＩＴ業界の歴史が若いせいかパートナーシップ確立のためにはユーザー企業とベンダー企業のコミュニケーション能力に、問題がありそうである．

　・ＩＴ経営普及促進に向けた調査研究報告書ではパートナーシップ確立の阻害要因として以下の６つが挙げられている．

１　要件定義不十分　２　開発費用不透明　３　開発工程不透明

４　契約不完全　　　５　品質未確定　　　６　取引関係不平等

　・講演者はＪＵＡＳにおける活動や自社の開発経験を含めてＩＣＴに携わる者のスタンスについて“ユーザー企業社内IT'er”と“ベンダー企業”は、対峙するものでなく取引関係を超えた信頼関係を構築してゆくべきで、パートナーシップを確立すべきであるとの見解を述べ、また方法論についても言及する．

【講演内容】
■ＤＩＣ社のご紹介

　・ＤＩＣ社の製品群、会社概要、ＤＩＣグループ経営の基本的考え方、ＤＩＣグローバルオペレーションをご紹介頂いた．

　・ＤＩＣインフォメーションサービス社概要

　・ＤＩＣ社のコンピュータ活用の歴史（１９６４年より現在まで）、エンタープライズシステムの体系、ＤＩＣグループでの情報システム部門の役割を

　　ご紹介頂いた．

■緒言

　情報システムの一括請負契約におけるユーザーとベンダー間の諸問題、特にベンダーの開発リスクとそれに伴うユーザーのリスク負担の不透明性を解決するためにパートナーシップの議論がなされた．

　一括請負については、契約の観点からも多段階契約が好ましい．

　要件定義フェーズは成果物の品質がその受託ベンダーの誠意に負うところがあるものの、一括請負よりは健全であるとの考えが示されている．

　経済産業省よりモデル契約書の第1版と追補版が公表されている．

　情報システムにも多くの種類があるが大型の基幹業務システムの開発に関わる議論を中心とする．開発リスクの源泉を要求仕様、要件定義を中心とした相互の情報伝達と信頼性の欠如が主因とした分析がなされている．

　主としてベンダーとユーザー（企業）の問題が取りざたされているが、ユーザー企業を１．社内IT'erと２．システム・オーナー（管理部門）かつまたは経営者、３．システム・ユーザー（システムにアクセスする直接の利用者）に分類し相互の情報伝達と信頼性の向上を模索した．

　なお新たなビジネスモデルのシステム化などのまったく新規のシステム開発はリスクもきわめて高くよりいっそうの相互理解と協調が必要である．

１．システム開発の現状、問題点、改善点

ＪＵＡＳで把握されている統計データからの分析結果の概要を記述する。

Ａ．システム開発の現状、問題点

　　・システム開発の工期・予算・品質の状況　：

　　　工期満足度半分以下　予算満足度半分　品質満足度２／３

　　　⇒残念ながらユーザーとベンダーの良好な関係は長年構築されていない

　　・工期遅延理由分析

　　　工期遅延理由では要件定義までの不備が４０％を占める。

Ｂ．システム開発の改善点:ベンダー

　　・主な委託先に対する満足度　：　パートナーとしての改善は進んでいるが新技術・価格・提案力は依然低い

Ｃ．システム開発の改善点:ユーザー

　　・信頼性向上のための施策　：　要求仕様書に性能・信頼性・運用の各要件を記載せず、作成も他人任せで、リスクを考慮しない工期設定をしている場合が少なからずある．

Ｄ．システム開発の改善点：ベンダーとユーザー

　　・パートナーシップ構築の対象範囲と目指すべき姿　：

　　　ユーザーとベンダーの役割分担や力量の違いに基づいた５つのモデルがある．

　　　要件定義・外部設計はユーザーとベンダーの共同作業であることが好ましい。ＤＩＣ社では、５つのモデルのうち、Ｗｉｎ－Ｗｉｎモデルを目指している．

Ｅ．ベンダー企業とユーザー企業のパートナーシップを阻害する６つの課題

・平成２０年度の抽出課題と平成２１年度検討テーマ

　ＪＵＡＳにおける、昨年度（平成２０年度）抽出課題（６項目）と今年度（平成２１年度）検討テーマ（６項目）について紹介され、それらは課題と検討テーマとして関係づけされている．

・ベンダー企業とユーザー企業のパートナーシップを阻害する６つの課題

　下図において、Ａ～Ｆは、昨年度抽出課題で１）～６）は、今年度検討テーマを各々示す．

パートナーシップ６つの課題図

２．パートナーシップ６つの課題
　前述の、１）～６）の検討テーマについて、課題として詳細に展開、説明する．

２．１　要件定義の課題

　（１）要求定義・要件定義の再整理

　　　・用語定義の必要性

　　　・業務そのものの理解の共通化（業務、業務要件、要件定義）

　　　・要求と要件の違いと役割について

　（２）システム化の流れと各用語との関係図整理

　　　　　問題点として、ＩＴ業界の用語・言葉の定義は分かり易さの面で不十分である．しかし、先進的なベンダーから要求定義における「要件の構造の考え方」が提言されてきており解決の動きは出てきている．

　　　　　少なくとも要求と要件とに誤解が生じないことが重要である．

　（３）「要件の構造の考え方」の紹介

　　　　経営、業務、情報システムの各階層で要求を具体化して要件として定義するときに的確な表現でなければならない．

　　　　⇒要求・要件定義書の作成時には、ユーザーとベンダーでの共同作業が必要でベンダーも一緒に考えないといけない．

　（４）社内IT'erの役割

　　　　社内IT'erは、外部に対する窓口として以下の責務を負う。

　　　　－システム・オーナーや経営者はベースラインがぶれないように業務要求を提示し、ビジョン・スコープ記述書をまとめる。

　　　　－システム・ユーザはユーザー要求を示す．機能についてはユースケース記述書にまとめられる．

　　　　－非機能については機能要求に反映されるものと直接設計書に反映される場合がある。これによって利用者に対して有効なシステムとなる．

　（５）要求工学

　　　・要求情報の関係を以下に整理している。ぶれないビジョンとスコープが肝心であるとの考え方が示された．

　　　　○業務要求（理由と目的）をビジョン／スコープ記述書に記述する。

　　　　○ビジョン/スコープ記述書とユーザー要求（目標と仕事）、業務ルールをユースケース記述書とする．

　　　　○システム要求から機能要求を抽出しユースケース記述書、品質属性、外部インターフェース、制約を考慮してソフトウェア要求仕様書に取りまとめる．

　　　・要求定義の概念プロセス

　現場は事実を語っていても、必ずしも“全て”と“真実”を語っていない！　要求の引き出し（獲得）→分析→仕様作成→妥当性確認（検証）を繰返す

　　　・仕様変更に関する重要な示唆・課題

　　　　○ユーザー企業からの指摘

仕様変更の必然性、コスト、請負契約に関する問題、ベンダーの実力

　　　　○ベンダー企業からの指摘

仕様変更に関する前提条件、委任契約の問題点

　　　　○まとめ

契約形態と仕様変更のタイプ、発注に関するユーザー企業の責任

請負契約の再認識

　　　　○変更管理も重要

　（６）要求定義確立の報酬

　　　○発注者の対応と工期の関係（大規模ＰＴ、５００人月以上の場合）

　　　　　要求仕様・委託先の評価・委託先の進捗管理・委託先とのコミュニケーションのいずれも“できている”場合の工期遵守率は高い

　　　○品質、工期での発注者の対応と顧客満足度の関係（大規模ＰＴの場合）

　　　　　要求仕様・委託先の評価・委託先の進捗管理・委託先とのコミュニケーションのいずれも“できている”場合の予算・品質遵守率も高い

　　　○要求仕様の明確さとプロジェクト全体の満足度

　　　　　要求仕様が明確であれば9割以上満足．

　　　○要求仕様の変更発生と工期遅延度

　　　　　要求仕様の変更は工期に多大なる影響を及ぼすので変更管理は慎重に

２．２　見積の課題：リスク
　（１）見積標準体系

見積金額＝生産物×生産性×単価

　この３つの要素の中にリスクがあるが、リスク要因の見える化によりリスク低減を図る．そのための考え方や基準を作成する．

　契約フェーズを細分化し、かつ生産物量、生産性、単価、残存リスクをベンダーから提示してもらい、ユーザーとベンダーが協力して、リスクを減らし、プロジェクトが成功するように努力する．

見積提示額＝見積原価＋リスクであるが、この中で、リスク部分を減らす努力をする．

　（２）リスク低減の工夫例（６項目）の紹介

Ａ．タイプ別リスク表の活用（設計製作編）

タイプ１　要件定義書を基に見積（リスクはベンダー負担）

タイプ２　要件定義書を基に見積（ただしリスクを発注者に明示）

タイプ３　確認修正済みの要件定義書を基に見積

　　　　　（残存している小リスクを発注者に明示）

　　　　　タイプ１～３を使い分けタイプ３の増加を期待したい．

Ｂ．しっかりした要件定義完了後の開発請負契約へ向けて

　　　　　　リスク標準を参考に要件定義の精度、充足度を向上させる．

Ｃ．顧客窓口特性の影響度

フェーズ別見積金額ついて、顧客窓口の統一性、顧客への依頼事項への期限の遵守状況等を評価し、影響度合いをレベル分けして見積金額へ加減算する。この追加影響度を避けるためには、発注者側の窓口キーマンの意思決定力を高める必要がある．

Ｄ．顧客キーマンの資質分析

顧客のキーマンの資質（高い、中、低い）に応じてベンダーの苦労が決まる。システムが大規模になるほど顧客キーマンが大切．

Ｅ．工期の厳しさ（生産性への影響）

工期短縮率＝（希望工期－基準工期）÷基準工期×１００で計算する。ＪＵＡＳ基準では、１００人月以上のプロジェクトであれば、

基準工期＝２.４×〔投入人月の立方根〕で基準工期を算出する．１００人月未満はこの基準の３０％低い値を活用する

Ｆ．システムライフサイクルコストの重要性

導入費用だけでなく、保守・運用費用を考慮したシステム構築を推進しないと、システムライフトータルでは高くなる．開発費用＋保守・運用費用の総費用を考慮する必要あり．

（一般にトータルでは保守・運用費用の方が、開発費用より高い．）

（ＱＡより）契約、要件定義、見積りに絡むが、以下のような考え方がある．

ユーザー部門がこういうことをやろうと決めているときは、普通、投資総額が決まっている。ユーザーのシステム部門は１０％以上の要件、機能の変化、６ヶ月以上の期間変化が発生したら、再上申する。こういう基準を最初に明確にしておくこと。ＰＭＰでは予算の予備費用を持っておくことを決めている．

（ＱＡより）プライドのＰＪ管理手法の見積りの工程アプローチは次のようになっている．

第一フェーズ：２０～３０％のバラつき

第二フェーズ：１０％前後のバラつき

第三フェーズ：（最終見積り）±５％はバラつく．

見積りが決定したら、計画／納期をくずさないようにしている．

２．３　契約

　ユーザー企業、ベンダー企業間で契約締結後にいかにして揉め事が発生しないようにするかの課題への解決策を示す．

　ＩＴ企画開発モデルタイプ毎について、７つのモデルタイプに分けており、

　どのタイプを選択するのか、ＩＴプロジェクト企画時に明確にして始めることが重要である。この中では「６．Ｗｉｎ－Ｗｉｎモデル」が推奨モデルでＤＩＣ社殿でもこのモデルを目指している．（次ページ図参照）

　また、契約形態と品質の関係を示すデータから、品質指標：換算欠陥率（ベンダーの開発が完了し、納入後、総合テスト～安定稼動までの間に発生する欠陥数）を見ると、一括請負より多段階契約の方が品質指標でよい傾向の結果が出ている．

２．４　欧米の契約形態

　欧米と日本の契約形態について比較した結果が紹介された．

・欧米と日本の契約形態との比較から得られた重要な示唆

　　　　　－リスク

　　　　　－予算

　　　　　－情報システム部門の役割

　　　　　－ビジネス要件の定義

・議論の主なポイント

　　　　　－予算に対する考え方の違い

　　　　　－契約の違い

　　　　　－タイム＆マテリアル契約の特徴と注意点

　　　　　－コスト、品質、納期のトータルバランス

・議論のまとめ

　　　　　－欧米と日本ではやり方が異なる点があるが、リスクの取り方や如何にしてよい関係を作っていくかについては参考になる点がある．よく研究し、日本企業らしいモデルを作れればよい．

⇒雇用形態の違いがシステム開発に影響をもたらしている．

２．５　情報サービス産業が建設業ＣＭ方式の運用可能性（提案）

　建設業約４０００年の歴史を持つ建設業界のプロジェクト方式の形態を紹介する．その中で、建設業界でも増大しつつあるＣＭ（Ｃｏｎｓｔｒｕｃｔｉｏｎ　Ｍａｎａｇｅｍｅｎｔの略）方式があり、発注者のサポートを専門的に行う。ＣＭ方式の役割として、設計は設計専門会社に、施工は施工専門会社に発注されるが、プロジェクトはＣＭ会社が管理する．

　情報システム構築でもＣＭ会社の育成が進めばこの方式の有効性が高いと思われる。情報システム構築分野への適用提案が以下のようになされた．

　情報システム構築でのＣＭ機能としては、ユーザー企業の発注機能を代行し、プロジェクト管理機能を代行する（ＣＩＯ補佐的な役割）。ＣＭ機能遂行者の契約は準委任契約で、技術的中立性を保つ第三者的な立場で、専門機能を提供する。役割機能として、ビジネス設計支援・ベンダー選定・契約支援、工程管理・品質管理・コスト管理を想定する．

２．６　共有すべき「リスク」項目の明確化
　ユーザーとベンダーが協力し合って失敗プロジェクトをなくすためには

　　1．契約手法の使い分け（生産物、生産性、単価、リスクの明示）

　　2．開発手法の使い分け

　　　（自社開発、外注化）（ウォーターフォール、イテレーション）

　　3．要件定義の確実化（評価方式、基準の明確化）

　　4．品質目標の設定と評価（非機能定義の明確化とコスト基準の策定）

　　5．共同作業のためのコミュニケーション

　が必要であり、そのための目標項目と評価指標の設定が急務である

（ＱＡから）リスクに関して、リスクとして話せるリスクは顕在化、認識できていているが、やってみないと分からないリスクについて、どう顕在化させるか、把握できた時点からどのように処理するかについて、ユーザー、ベンダー両者間で取り決めをしておくことが重要である．

欧米でのやり方では、リスク対策のために委任契約をとっている．

３．システム開発に思うこと
　システム全体を俯瞰してみると、開発手法に関しては万能なモノはなく、システムライフサイクルの長いもの、全社データウェアハウス, トランザクション・データ　ハブ, 大福帳などエンタータープライズシステムの根幹のシステムでは堅牢性と保守性を尊重したウォーターフォール開発を重視する．一方、システムライフサイクルの短いもの、業務システム、画面とその遷移や帳票設計、個別の処理が主体のものはＳＯＡ・ＯＯＡ、パッケージソフトやアジャイル開発などで行う方法もあると考える。
　具体的な例として、ＤＩＣ社のプロジェクト管理手法とＪＵＡＳでの開発モデルを紹介する。

　　－ＤＩＣ主要英語圏プロジェクト管理手法

（この手法は、シックスシグマを習熟している企業で良く使われる模様）

　　－ＤＩＣ日本におけるシステム開発方法

（ウォーターフォール型フルスクラッチ開発、週次進捗管理型が主流）

　　－Ｕ字型開発モデル（ＪＵＡＳ）

Ｕ字型開発モデルはフロント・ローディングの考えと一致する手法

４．　まとめ：パートナーシップ構築に向けて

　◎ユーザー企業がなすべきこと

　　・何が課題でどのように解決すべきか決断をして要求を明確にすること

　　・漏れのない明確な要件定義書を作成すること

ベンダー企業が作成した場合はユーザー企業も納得ゆくまで理解する

　　・見積・契約に際しては、生産物量、生産性、単価、リスクの明細の提示を求め評価すること

　　・仕様が変化する、あるいは未決定部分が多い場合は委任契約を採用し、トラブルを避けること

　　・仕様と効果のバランスを考え無駄な投資をしないこと

　　・ベンダー企業のプロジェクトマネージャーに協力しユーザー企業としての責任を果たすこと

　　・必要ならばプロジェクト支援コンサルタント（建設業界でいうコンストラクションマネージャーＣＭｒ）を活用し、プロジェクトの成功を心がけること

　　・システムを活用し効果を出すことが企業に貢献することである。効果評価をおこない業務、情報システムの改善に励むこと

　◎ベンダー企業がなすべきこと

　　・ユーザー企業が要件定義書を作成した場合は、正しく評価し、リスク点を示し、十分な会話をすること

　　・要件定義書をベンダー企業が協力して作成する場合は、発注者の要求に沿った提案を心がけ最小費用で最大効果をだすこと

　　・見積・契約に際しては、生産物量、生産性、単価、リスクの明細を提示し、透明性を確保し顧客の信頼を得ること

　　・仕様の変化、環境の変化を予測し、仕様変更がミニマムになる設計を行いトラブル回避すること

　　・次工程以降の作業内容も配慮し、当初の予算枠に入るよう誘導すること

　　・常に技術を磨き更に良い方法を追究すること

　◎共同で取り組むべきこと

　　・各種作業の評価基準の作成に留意し、日本流情報サービス産業の基礎作りに協力すること

　　・グローバルを常に意識し世界に乗り出す準備をすること

■結語
　モノ（システム作り）からコト（何が出来るか）へ
　述べてきたようにもはやベンダーと社内IT'erが対立しているときではない。経営陣やシステム・オーナー、社内ユーザーとコミュニケーションを図り要求を確実にする．
　富士通「新要件定義手法」「価値観マーケティング」、ＩＢＭ－ＤＯＡ「ＤＦＤモデリング」など）
　一方、ユーザーの意見を過剰に信頼することが大きなリスクであることを前提にシステムを開発する．
　要求工学の導入によりユーザーの“インタビューやフロー図による業務分析”にとどまらず、“行動や思考の分析”を行い“有るべき姿”を模索する日立「ＥＸアプローチ」などの方法論が確立してきた．
　現場重視に加えて、経営視点でのシステム化計画が可能な環境になってきた．
　ＩＴ経営ロードマップに纏められたように情報システムが経営を支えるコトであるという認識が広まってきている．