以下の資料は、著作権法と不正競争防止法の保護を受けています。
従って、資料の一部あるいは全部について、ＣＩＯパートナーズ株式会社からの承諾を得ずに、いかなる方法においても無断で、複製、ノウハウの使用、企業の展開等をすることは禁じられています。
恐れ入りますが、上記をご承諾頂ける場合のみ、以下のレポート名をクリックして頂き、本編にお進みください。
講演１ 業務改⾰の進め⽅（クリックして開く）
アジェンダ
１．業務改⾰とは…
１－１．業務改⾰とは…
ビジネスシーンでは「業務改⾰」は⼀般的に利⽤されている⾔葉です。
しかしながら、⼤辞林などでは、「業務改⾰」というキーワードは⾒当たりません。
ただし、「業務」「改⾰」の２つのワードの各々の意味は収録されています。
| 業務 | 日常、継続して行われる職業上の仕事 （用例）日々の”業務”に励む |
| 改革 | 基盤を維持しつつ、制度や機構・組織などをあらため変える事 よりよく改める事 （用例）役所の機構を”改革”する |
つまり”業務改革”とは、
日常、継続帝に行われている仕事を、基盤は維持しつつ、制度や機構・組織などの”枠組み”まで踏み込んで、よりよく改める事
詳細は、後ほど解説します。
１－２．業務改⾰と改善活動の関係
⽇頃の継続的な改善活動で成果が上がらなくなってきた時は「ゴール・到達点」ではなく、「業務改⾰のタイミング」です。
改⾰と改善は相互に補完関係
改善活動と業務改⾰は、決して互いに「相反する」ものではない！
１－３．業務改⾰の対象領域〜業務改善との⽐較〜
１－４．社内制度や取引形態に踏込んで変⾰するには…
- いきなり細部の検討に⼊らない 〜トップダウン思考〜
- 先ず、取り組み⽬標（改⾰⽬標）を達成する為の論点や、⽬標を達成できる業務イメージ（あるべき姿）の検討から着⼿する。
- 具体的には、組織・体制⾯、社内制度⾯、取引形態の各観点で新業務モデルのイメージを固める。
- ⼀般的には、「トップダウン・アプローチ」といわれる。
- システム部⾨だけで検討しない 〜全社ＰＪ体制の確⽴が不可⽋〜
- 社内制度や組織体制の⾒直しは経営企画部⾨との検討が⽋かせない。
- 同様に特に取引形態の⾒直しは、購買部⾨や営業管理部⾨との検討が⽋かせない。
- こうした部⾨の協⼒を得られる様、最初から「巻き込んだ」プロジェクト体制を検討する事が肝要といえる。
１－５．変⾰に向けた２つのアプローチ法〜トップダウンとボトムアップ
| アプローチ | 検討後の業務モデル |
|---|---|
| トップダウン | 概略（スキームや考え方が中心の内容） ・具体的な業務プロセスにまで、落とし込めない事が多い ※「絵に描いた餅」の原因 ・現状とのかい離が広がる（現実味がない検討結果に陥る）懸念がある |
| ボトムアップ | 詳細（システム整備に直ぐに着手しやすい） ・業務プロセスの変更で終わり勝ち（社内制度や組織・機構の見直しに踏み込まない場合が多い） ・成果は単なる結果論 ※目標は「お題目」に過ぎない場合も少なくない ⇒だからトップはＩＴ投資にＧＯをかけ難い |
業務改⾰には、トップダウンとボトムアップの２つの合わせ技が不可⽋
〜業務改善はボトムアップで⼗分。但し⼤きな投資で⾼い⽬標に挑む改⾰にはトップダウンも⽋かせない
２．標準的な業務改⾰の進め⽅
２－１．業務改⾰のロードマップ（全体シナリオ）
- 先ずは業務から…
前述の通り、業務改⾰では「社内制度」「組織体制」「取引形態」などに切り込んでの変⾰が避けては通れない。
従って、いきなり細部の検討に⼊らず、先ずは業務の検討から始める事が絶対条件といえる。 - 先⾏した施策実⾏
例え同じ段階（次）の取り組みであっても、新システムへの移⾏に先⽴って、業務系の施策を順次、先⾏して実施する事は⾮常に有意義。
（全てをシステム移⾏に合わせると経営トップやユーザーの“間延び感”が⾼まるリスクが⼤きくなる） - 段階的な取り組み
設定した改⾰⽬標によっては、２段階（以上）に分けて取り組むケースも少なくない。
＜例＞
１次改⾰：親会社→２次改⾰：グループ会社
１次：業務の改⾰→２次：マネジメント改⾰
２－２．業務改⾰の⽬標設定
改⾰⽬標は、経営課題の解決を念頭に、
Ｑ）業務の“質”の向上、Ｃ）コスト削減、Ｄ）スピード化に分解して設定する。
| 改革目標の観点 | 各目標のポイント | 目標（例） |
|---|---|---|
| Q：業務の”質”の向上 | ・経営管理（マネジメント情報）の高度化、日常業務の質の向上の双方が含まれる。 ・特に日常業務の質の向上では、内部統制等の充実、顧客管理の充実など多岐に渡る。 | 得意先別の利益管理体制の確立 月次決算の精度向上 |
| C：業務コストの低減 | ・多くの企業で最も採用されている目標 ・システム要件との関連づけも分かり易い。 ・但し、人員削減を目指す場合、単なる工数削減では達成できない事も多い。 ・また、広義には、間接部門の人件費の変動費化なども含まれる。 | 事務量の○○％削減 管理部門スタッフの○○％削減 |
| D：業務のスピード化 | ・決算早期化などが該当。 ・経営のスピード化として、毎月の取締役会や経営会議等の開催日程に合わせて、目標を設定する事も多い。 | 月次単体決算の○○営業日以内の完了 |
改⾰⽬標は「経営課題の解決」を⾒据えて、且つ複数の観点を組み合せて設定する
〜定めた⽬標は取組み計画と共に取締役会等で決議・承認を得ておく事が望ましい〜
２－３．プロジェクト編成のポイント
Point1．先ず業務に着⽬できる体制を…
現在の社内制度や体制ありきで改善点を洗い出し、システム開発業者を招いて、いきなり「要件整理」（Fit Gap）を進めるケースがあります。
ただ、こうしたアプローチでは、ITコストの増⼤を招くばかりか、
情報システムの構築が「⼿段」から「⽬的」に変質してしまい、当初の改⾰⽬標（すなわち、経営課題の解決）が“置き去り”になりかねません。
業務改⾰に取り組む際は、システム部⾨のみならず、
経営企画部⾨や各管理業務部⾨からのメンバーを集めて、業務⽅針や体制を検討できる体制を整える事が肝要です
Point２．前向きな協⼒者を徐々に増やす
現状踏襲を前提とせず、業務の⾒直し（変更）を前提とした取組みでは、社内の抵抗勢⼒の激しい抵抗にあう事が少なくありません。
しかし、現状を踏襲するたけでは、経営課題の解決とは程遠い取組みです。
こうした事態に陥らない為に⽋かせない重要な要素として、【動機づけ】と、【傾聴・取り込み】が挙げられます。
すなわち、経営課題の解決を⽬指して改⾰⽬標を明確に掲げる事で、現状を否定する事なく、改⾰への動機を与える事ができます。
更に、実態調査ヒアリング等を通じて、各部⾨や担当者が抱える問題を理解し、検討材料に取り込む事で、
徐々に社内の⽀持者や協⼒者を増やしていく事が、業務改⾰の成功には不可⽋といえます。
Point３．経営者の理解と持続的な関与
多くの業務改⾰プロジェクトでは、あるべき姿（仮説）と業務（現状）のすり合わせを経て、⾃社に適した改⾰後の業務モデル像を定め、全社を挙げて取組みます。
つまり、当初思い描いていた仮説（業務モデル）が変遷しつつ、会社全体で実現化に向けて取組む事が⼀般的です。
従って、経営者（責任者）は、企画から新業務への移⾏まで、
⼀貫してプロジェクトへの関与を続け、検討状況を理解し、必要に応じて判断を下す事が不可⽋といえます。
すなわち、改⾰の⽅向性や総論から各論・具体論に落とし込んだ後も、決して部⾨任せ、担当者任せにしない事が求められます。
２－４．新業務の構想策定の進め⽅〜トップダウンとボトムアップを組み合せて取り組む〜
改革目標に繋がらない問題は「問題」に非ず【仕分けが大切】
３．効率化に向けた改⾰⽅針と取組み事例
３－１．業務の効率化に効果的な改⾰⽅針
第３章では、様々な改⾰⽬標の中でも、「業務の効率化」に焦点を絞って解説を進めます。
私たちのこれまでの経験に基づき、業務の効率化にとって⽋かせない３つの改⾰⽅針を以下に列挙します。
重複業務の削減
- 多くの企業の管理業務では、⽇次と⽉次の重複⼊⼒やシステム間での重複⼊⼒、類似する管理帳票の作成、複数部⾨での同種の確認作業など、業務の重複を招いています。
- しかも、業務重複は業務負荷の増⼤を招くばかりでなく、誤⼊⼒や確認の形骸化等のリスクを⾼めたり、決算情報の早期確定（と迅速な意思決定）を阻む等のデメリットも多い。
- 従って、部⾨間での業務分担の明確化や管理要件の整理、システム間のデータ連携の促進等を通じて、重複業務や類似業務・帳票の統廃合を進める必要があります。
業務の平準化
- 管理業務は業務特性上、期末や⽉末、経理部⾨に業務負荷が集中する傾向があり、多くの企業ではこうした業務負荷の偏重が業務の効率化や決算の早期化の妨げとなっています。
- 従って、期末や⽉末処理の前倒し、経理部⾨に集中する業務の分散化に向けて、ITの有効活⽤や他部⾨への業務移管、権限委譲、取引先への協⼒要請等を検討する必要があります。
業務の最適化
- 管理業務では、同じ業務処理であっても会計的視点（会計リスクの視点）と現場の視点（事業リスクの視点）で、その業務が持つ重要性が異なり、各々に対応すべく結果的に業務負荷の増⼤を招いている事態を多く⾒受けます。
- 従って、双⽅の視点から業務の重要性を再検証し、チェック体制の最適化を図るといったリスクアセスメント・アプローチによる業務の最適化を検討する必要があります。
３－２．事例：業務の平準化（デイリークロージングの実現）
事例データ
- 対象企業
メーカーＡ社 - 対象業務
販売⽤の機器装置の設置に伴う⼯事費（外注費）の管理業務
※同社では年間、数万件の設置が発⽣ - 問題
毎⽉末に⼤量の請求書が外注先より送付され、請求内容のチェック〜未払い計上が⽉末⽉初の⼀時期に集中。
決算早期化に向けたボトルネックになると共に、⽉末業務の煩雑化、チェック漏れの発⽣等様々な問題を招いていた。
- 当該業務の主な問題点
- 作業の再外注が発⽣し、正確な費⽤を算定（確認）する事ができなかった。
- 請求書を受領する迄に待ち時間が⽣じていた。（約４〜５⽇）
- ⽉次処理の中で⾦額⾯の再確認が必要となっていた。
- 作業結果データを費⽤計上に活かす事ができず、再⼊⼒が必要となっていた。（適⽤する科⽬もその際に確認）
- 改革方針と対策
| 対策 | 内容 |
|---|---|
| 取組みａ | １．外注内容の体系化（メニュー確⽴）と価格体系の統⼀ ２．仕訳のパターン化（費⽤計上の現場完結化） ※現場で費⽤計上を完結させる為の業務環境整備の⼀環として対応 ３．業務システムと会計システムのデータ連携の実現 |
| 取組みｂ | １．請求書の廃⽌（⽀払明細への切替） ２．⽀払明細の修正分の翌⽉決済対応を実現 |
※これらを実現する為に、⼯事業者（外注先）を集めた説明会の準備と開催、個別調整なども実施
３－３．事例：業務の最適化（リスクアセスメントの採⽤）
事例データ
- 対象企業
⾷品メーカーＢ社 - 対象業務
⾷品卸売（顧客）向け販促リベート（蔵出しリベート、センターフィー等）の管理業務
※⾷品業界の販促リベートは、⾷品メーカーで把握できない卸売（顧客）から⼩売店への出荷実績に基づいて請求額が算定される為、メーカーにとって⾦額的重要性が⾼い⼀⽅で管理が難しく、業界共通の課題といえる。 - 問題：毎⽉⽉初に顧客から請求書（1,000件前後）を受領。ただし、請求内容チェックは上述の通り元来、難しい事から、Ｂ社では少しでもチェックの精度を⾼める為、各営業担当者が⾃らの担当顧客からの請求分をチェックしていた。結果として、（１）チェック作業に膨⼤な時間を費やし決算早期化を阻害、（２）請求内容の誤りが数か⽉後に発覚した事もあり、（３）“出来る営業マン”ほど、⽉初に負荷が集中するなどの弊害を⽣じていた。
- 改革方針と対策
請求内容チェックに、“メリハリ”をつける。その為に
- 基準値（グループ）の設定全ての請求書を⼀律にチェックする現状を改め、⾦額的重要性を踏まえた基準を個別に設定
- 各グループ毎にチェック体制を確⽴特に、最重要グループは現状よりチェック体制を強化する事で、スピード化、効率化と管理強化の両⽴を実現
【パレート分析とは…】
焦点をあてる商品、顧客、部品などを特定し、重点的に対策を講じる事で、成果の最⼤化を⽬指す分析⼿法。
代表例
（１）２０：８０の法則
（２）製造業におけるＡＢＣ分析
４．業務改⾰を成功に導く為の秘訣（第１部の総括）
業務改⾰を成功に導く為の３カ条
業務改⾰（中でも特に合理化）を⽬指すには、新しい「何か」を加えて、実現を⽬指すのではない
反対に「今ある何か」を“捨てる・割り切る”事が重要！
- 例えば、現⾏システムに新しい機能を追加・実装しても、業務改⾰で掲げる様な改⾰⽬標を達成できるケースは殆どありません（“便利機能”は増えるでしょうが…）。むしろ、様々な拘り（例えば、全件を均しくチェックする、全ての取引先の要望に合わせて個別に対応する、等）を割り切る事で、まだまだ業務の効率化の余地が残されている企業は少なくありません。
- ただし、「捨てる・割り切る」には、（１）経営トップが確固たる信念をもち、（２）明確な⽬標を掲げて、（３）組織の壁を越えて検討できる体制づくり、が⽋かせません。
「仏」を作って終わりではない。むしろ…仏に魂を⼊れる作業が重要！！
- 例えば、新しい業務システムが本番稼働し、新しい社内制度、業務体制、（外注先などとの）取引形態を制定しても、そこで、業務改⾰が完結ではありません。むしろ、新しいシステムや新しい制度・体制などの「定着化」を図る活動が重要です。新しい制度やルールを作っても、実務担当者が変更の主旨を理解し、賛同を得ていなければ、業務改⾰の実効性は限定的です。
最後に、多くの会社に当てはまる点ですが…⾃分の会社を「特別視」しない！
- 正しく「案ずるより産むが易し」です。私たちが聞く事の多くは「…でも、それは他所でも普通にある事」です。
ＣＩＯパートナーズ株式会社
代表取締役 吉田明弘
講演２ ベンダーマネジメントのツボ（クリックして開く）
第２部の構成
１．ベンダーマネジメントとは
情報システム部⾨が抱えられる⼈員には限りがある。
情報システム⾃体も⾼度化・複雑化し⾃社要員のスキルだけでは対応しきれない状況もあり、開発プロジェクトにおいて⼈的資源やノウハウを外部に求めることは、⽇常的な⾏為となっています。
しかしプロジェクトの失敗原因としてベンダーマネジメントの不⾜がクローズアップされ、訴訟例も増えています。
【ベンダーマネジメントとは…】
- 開発・運⽤・保守の各々の局⾯で、取引先が提供する付加価値（役務・サービスや納品物）をＱ（品質）、Ｃ（コストの妥当性）、Ｄ（納期）の観点から発注者（依頼者）の⽴場で、継続的に管理、検証する事
- また、特に企画局⾯において経営戦略に沿った施策（企画）の具体的な検討・⽴案に向けて技術動向、他社動向等の検討材料（情報）を収集すると共に、ニーズ（要件）に⾒合った適切なパートナーを選定する事
つまり、ベンダーマネジメントとはシステム部⾨の限られたテーマではなく、
企業の成⻑を司るコア・コンピタンスに⼤きく関係
２．情報システム部⾨の業務とベンダーマネジメント
⾚字（⾚線）部分を中⼼に、ベンダーマネジメントは、様々な業務で必要に…
３．ベンダーマネジメントを実現するための前提条件
ベンダーマネジメントを⾏うに当たって以下の項⽬についてユーザーとベンダー双⽅の合意形成が取れていることが前提となります。
- 外注の⽬的と範囲の明確化
ユーザーとベンダーとの間で利害が対⽴して、プロジェクトの実⾏の障害となることが少なくありません。
事前に「外注の⽬的と範囲」を明確にしてプロジェクト全体で合意を得ておくことは重要です。 - 役割と責任の明確化
ユーザとベンダーにおいて役割と責任が曖昧なままプロジェクトを開始しがちです。
「決定事項と思っていたら、実は未決定のまま進んでいた」「課題の検討を担当者が忘れていたため、課題が放置されていた」といったことが発⽣しないよう、計画段階で役割分担を取り決めておくことで、タスク毎の実⾏責任を明確化する事が重要です。 - 丸投げはしない：ユーザ企業も積極的にシステム開発プロジェクト管理に関与する
業務改⾰の⼀環として、システム開発プロジェクトは実⾏されます。
ベンダーが請け負ったＳＩプロジェクトでは、ベンダーが開発プロジェクトの遂⾏責任を持つわけですが、システム開発を完了させ業務改⾰を予定通り実現するためには、ユーザーもベンダーの報告だけでなく、開発プロジェクトの状況を正しく把握すべく、開発プロジェクト管理に積極的に参加していくことが必要です。
４．プロジェクトの局⾯とベンダーマネジメント
プロジェクト局⾯に合わせたベンダーマネジメントが重要です。
４－１．システム選定
システム選定の流れは、以下の通りとなります。
- プロジェクトの⽬的に沿って外注化範囲と⽬的を設定します。
- 事前に複数の候補ベンダーを選出と情報収集をしておき、ＲＦＰに基づいた提案をベンダーに依頼します。
- ベンダーからの提案を受け、客観的に公平な評価を実施したうえで、システム選定を⾏います。
- プロジェクト⽬的に沿った機能要求事項を洗い出し、ＲＦＰにまとめます。
- ベンダーに依頼する業務範囲と⼯程（発注スコープ）を決定し、いつまでにどのような⽅法（⼊札、数社による競合、特定ベンダーとの交渉）で、どの程度のコストと納期で発注するかを決めます。
- 発注スコープに内在するリスク分析を⾏い、契約形態（請負・準委任・派遣等）と契約条件・条項を決め、候補ベンダーへＲＦＰを提⽰します。
- ベンダー提案の評価シートを予め作成し、数値化して評価します。
【評価項⽬】- 技術⾯
- マネジメント⾯
- 価格⾯
４－２．契約
ベンダーとの契約で重要なのは、「きちんとした契約を取交わす＆⾒直す」事です。
- 局⾯に応じた契約形態をとる
- 新システム導⼊の際、要件等をまとめる局⾯と、その後の設計〜開発、テスト局⾯では、対価の対象が異なる事が多い。（※また、運⽤・保守の際にも、多くの場合で同様）
- こうした場合、対価の対象が異なる契約を、「⼀括受託」などの形態でまとめて契約するのではなく、各々の局⾯に応じて、契約形態を変更する事が、相互の権利関係を明確にする上でも望ましい。
- 役務に対価を⽀払う（例：要件定義など）→準委任契約
- 引き渡されるシステム⾃体に対価を⽀払う（例：設計・開発局⾯など）→請負契約
- 契約内容をきちんと詰める
- ベンダーとの取引関係の中で、特にリスクが⼤きい項⽬は、予め契約内容を双⽅で協議し、合意形成しておく事が望まれる。
- 具体的には、①知的財産に関する権利関係、②再外注（⼆次請け、三次請け）、③ベンダーの管理責任、④契約の更新、⑤（特に役務の）サービスレベル、⑥瑕疵担保責任の範疇、保障期間などはベンダーの「⾔う通り」に契約して後々、問題とならない様に注意する必要がある。
- 妥当性のある⾦額で契約する
- 「⼀式」などの内訳が分からない⾒積りや、ＳＥのスキルと作業に要するスキルの⽐較検証が出来ない⾒積りでは、妥当性のある⾦額での契約は望めません。
- また、「相⾒積り」による検証のみならず、経年効果（ベンダーのスキル蓄積効果）を考慮に⼊れた契約⾦額の⾒直しが重要といえる。
４ー３．プロジェクトの管理
請負型のプロジェクトにおいて、管理実⾏主体はベンダーにあります。
但し、ベンダーに管理を丸投げするのではなく、ユーザーも主体的にプロジェクトの各局⾯に応じたプロジェクト管理のＰＤＣＡサイクルを回していく事が必要です。
（１）開始
ユーザーが効果的にベンダーマネジメントを実施するためには、プロジェクトの開始前に、実施可能な仕組みを作り、ベンダーとの合意をもって役務・提供や成果物の提供を受けることが必要です。
- ユーザー、ベンダー双⽅でプロジェクト⽬標を共有する。
- 会議体の設定を⾏い、会議の⽬的と参加メンバーの決定を⾏う。（以下は例）
- 週次進捗会議…各作業項⽬の進捗確認と課題の状況整理と対策検討
- ステアリングコミッティ…進捗上の懸念事項・課題について対応⽅法の決定指⽰
- 開発スケジュールや品質管理についての管理指標の作成と管理⽅法等については、必ず確認します。
- 開発スケジュールの⽴案と、詳細化したＷＢＳによる進捗管理
- 成果物の明確化（作成者と合意形成の相⼿も明⽰する）
- 品質管理⽅法（成果物の検収時期と検収基準）ルールの作成
- 開発標準（ルール）の作成
- 要員・開発体制の提⽰（と妥当性チェック）
- 次フェーズ移⾏の基準
- ベンダーが社内管理で使⽤した資料を使った進捗会議を⾏うことも⾮常に有効です。多くのベンダーが社内管理⽤として使⽤しているプロジェクト管理ツールを評価・確認して、利⽤可能なものは活⽤していく事が重要です。
（２）実⾏
ベンダーの作業状況は把握しにくく、⾃社作業と同じレベルで管理することは不可能です。
請負契約・準委任契約では、どこまで踏み込んで管理するかも難しい問題であり、プロジェクト管理はポイントを絞って⾏うことが要求されます。
以下の管理を中⼼としたベンダマネジメントのＰＤＣＡサイクルを実⾏することが重要です。
- 進捗管理：週次の進捗会議、報告書内容に基づき進捗状況をチェックする
ＷＢＳを基に予定と実績を対⽐することで作業の状況を⾒える化し、対応を検討します。
現状を（特に悪い報告）もれなく把握するためには、ベンダーとの関係を密にとり、進捗・品質・問題等が⾃然にとれるような関係になることが求められます。 - 課題管理：発⽣した問題・課題を個別管理する
⽣した問題や検討課題を早期に報告管理するルールを徹底させます。
ポイントは、①対象の課題の状況（誰がボールを持っているか・期⽇までに対応可能か）と、②対応の完了は対象となる成果物に反映させて終了とすることです。 - リスク管理
ユーザーが⾏うリスク管理では、ベンダーのリスク管理の状況を評価し、不⼗分と判断した場合には、ユーザーの視点でベンダーを⽀援しリスク管理を徹底させることが必要です。
気になったリスクを進捗会議等の場で確認して、「気づき」を与えることも重要です。 - 品質管理：納品・レビュー計画に沿って随時レビューを実施する
検収時に不具合を発⾒（＝即）進捗の遅れに繋がります。
これを避けるため、納品前の事前チェック・レビューの実施、テストプランの事前レビューを⾏うことと局⾯移⾏での承認プロセスで成果物のレビューを効率的に⾏うかが重要です。
（３）検収
契約に記載されている納品物がもれなく納品されているか、品質は次⼯程に回しても問題はないかレビューを⾏い、検収します。
成果物の品質が低ければ、下流⼯程の成果物の品質がそれ以上になることはありません。
プロジェクトの各局⾯により検収内容は異なり、必ず上流局⾯での成果物が検収の基準となります。
詳細設計書のレビューまで必ず⾏う。
但し、詳細設計書の記述内容がシステム寄りで、ユーザーに記載内容が判らないケースも多く⾒受けられます。詳細設計書の記載内容についてもユーザーが確認可能なように、何をするプログラムなのかをプログラムの概要に記載し、新業務フローとの関連が取れるような形で作成することが必要です。さらに、変更管理についても記載していく事で、設計書の履歴を確認できることも重要です。
テストの局⾯についても、単体テスト、結合テスト、総合テスト、ユーザーテストの局⾯がある。
それぞれのテストの⽬的は異なっており、開発の各局⾯の要求事項が満たされているかを確認する場であり、特に受⼊テストは開発局⾯最後の重要な検証となります。
４－４．終結
開発プロジェクトが終息すると、以下の項⽬を確認して、検収書をベンダーに渡し、⽀払を⾏うことになりますが、
プロジェクト終了時のゴタゴタの中で漏れ等を発⽣させないため、予め確認項⽬をチェックリスト化しておくことが有効です。
- 最新化された成果物がすべて納⼊されたことの確認。
- 瑕疵担保責任期間・保証期間の確認。
- 開発プロジェクト後の運⽤・保守について、システムに関する様々なスキルが運⽤・保守メンバーに引き継がれていることの確認。
- プロジェクト中に渡した機材、資料の回収が⾏われていることの確認。
- その他契約書に記載された作業で未履⾏の作業はない事の確認。
ベンダーマネジメントに関しての評価を⾏います。
ベンダーの評価だけでなく、ベンダーマネジメント⾃体の評価を⾏い次回以降の開発プロジェクトに対して、ベンダマネジメント⾃体のレベルアップを図ることができます。
- 今後も継続して取引を⾏うことが有効なベンダーなのか。
- システム選定と発注プロセスの改善事項はあったのか。
- 契約に関して、追加記載すべき事項があるのか。
- プロジェクト管理において、改善点はなかったのか。
上記事項をまとめて、ベンダマネジメントに反映させていく事で今後のプロジェクトの成功確率はさらに向上するものと確信します。
５．業務改⾰プロジェクトを成功させるために
これまでプロジェクトを成功させるためのベンダーマネジメントのポイントを挙げてきました。
各⼈が“やらなければならないこと”を明確化し、“ちゃんとやっていること”を確認することです。
ベンダマネジメントとは、当たり前の事を当たり前にやる状況を作り出すことです。
そのためには…
| 最初が肝⼼ | ・機能要求事項を洗い出しＲＦＰにまとめる。 ・きちんとした契約を取交わす。 ・各局⾯での成果物を明確化する |
| 共有化 | ・プロジェクト⽬標を共有し、物事を決定する際の原則とする。 ・最初に管理ルールを明確化し、共有し、実践する。 ・前の局⾯の成果物が次の局⾯の基礎資料と認識し、皆で共有化を図る。 |
| 信頼関係 | ・外注の⽬的と範囲を明確にして役割分担を明確にする。 ・管理するだけでなく、ユーザーとベンダー双⽅が信頼しあう関係。 ・ベンダーの能動的なアクションを引き出していく事。 |
ＣＩＯパートナーズ株式会社
代表取締役 吉田明弘
講演３ 投資の最適化に向けたシステム選定（クリックして開く）
アジェンダ
１．システム選定の流れ
RFP（提案依頼書）の作成〜ベンダー選定・契約締結までの主な⼯程と問題点を以下に列挙します。検討の流れ（Step１〜６の期間︓3カ⽉〜）
| Step | 作業項目 | 散見される問題など |
|---|---|---|
| 1 | 提案依頼書（RFP）作成 | ・必要な情報がRFPに盛り込まれていない。 →プロジェクトが始まった後で⾒積り額が増加する要因に… |
| 2 | 提案依頼（RFP説明会） | ・提案を依頼するベンダー（候補先）が少ない。 ・各社に「どうせ、“当て⾺”では︖」の疑⼼が払しょくできない。 |
| 3 | 各社の提案検討支援 | ・特に、既存ベンダーと新規ベンダーの間で情報格差が埋まらない。（公平な競争環境が構築できない） |
| 4 | 提案内容の評価 | ・コストや機能⾯にばかり焦点をあてて評価してしまっている。 |
| 5 | 詰め交渉 | ・⾒積り⾦額ばかりに関⼼があつまり、作業計画や契約条項など、重要事項の詰めが置き去りにされてしまっている。 |
| 6 | 経営層への上申（契約締結） | ・⾒積り⾦額ばかりに焦点があたっている。（投資対効果を説明しきれていない） |
近年、こうした問題を抱えたままでシステム構築を始め、後々⼤きな⽕種を抱えるケースが散⾒される。
２．ＲＦＰに盛り込むべき事項
| プロジェクトの概要 | データ構造 | 提案依頼内容 |
| ✔ 改⾰⽬標、対象範囲 ✔ 全体ロードマップ ✔ システム構築の役割分担、など | ✔ 主要な業務情報と内容 ✔ 業務情報間の相関（ＥＲ図） ✔ 主要マスタ、データベースの ⼀覧と概要、など | ✔ 前提条件 ✔ サイジング基礎情報 ✔ 提案のポイント ✔ 提案・選定の流れ、など |
| 新システム全体像 | 主な管理業務の概要 | 別紙 |
| ✔ 構築⽅針 ✔ 新システムの全体像、など | ✔ 管理業務の⼀覧表 ✔ 各業務の主な機能構成 ✔ 各業務のデータと処理の流れ ✔ 処理パターン、など | ✔ 業務⼀覧表 ✔ 個別要件⼀覧表 ✔ 現⾏業務フロー図 ✔ 現⾏システム・ネットワーク構成図 ✔ 現⾏システム画⾯・帳票サンプル ✔ ⽤語集、など |
| インターフェイス | 重要な個別要件の概略 | |
✔ データ連携の⽅針 ✔ 主なデータ連携パターン ✔ 主要システムとの連携内容、など | ⤴【注意】現状に引っ張られ過ぎない事 事前にシステム再構築に合わせて「業務をどう変えたいのか」を検討し、落とし込む事︕ |
|
３．提案ベンダーの絞り込みシナリオ（某社・基幹系システムの場合）
充分に検討を重ねたＲＦＰを提⽰すれば、ベンダー各社が提案内容を検討している時点で「撤退表明」するケースも少なくない。
その後、提案内容の⽐較・精査と詰めの交渉を妥協せずに⾏う為にも、最初は多め（６〜８社程度）に依頼をかける事が望ましい。
４．情報格差をなくし、公平な競争環境を構築する
ベンダー間の情報格差をなくし、公平な競争環境を構築するには、以下の３点が⽋かせません。
- 提案の検討期間を充分に確保する
- 特に基幹系システムの再構築の場合、１ヶ⽉程度の期間をとる事が望ましい。
- また、該当期間は「待ちの姿勢」をとる事なく、各社との積極的なコミュニケーションが⽋かせない。
- 各社からの問合せや回答は全てオープンにする
- 提案の検討期間は、各社からＲＦＰ内容等に関する質問や問い合わせが多く発⽣します。
- こうした質問・問い合わせ内容、及び、回答を全ての提案依頼先にオープンにする事を推奨します。
- これは、各社の検討内容の“質”を周知し、各社の検討に拍⾞をかける為にも有効です。
- 時間を有効活用し、各社の顧客の「生の声」を聴く機会とする
- 各社の提案内容を選定する際には「各社からの提案内容」のみならず、各社の「顧客の声」が重要な判断材料となります。
- 特にベンダー各社が提案活動を本格化させている当該期間は、各社の積極的な対応が期待できます。
５．不適切な評価を防ぐには…
（１）評価の観点
「モノ・カネ」で最良の選択が出来れば、”後は何とかなる”との考えは捨てるべき。
近年のシステム再構築は「ヒト」（ＳＥ・メーカー）が、最もＰＪの成否を左右する！！
（２）評価時に陥りがちなエラー（注意点）
各ベンダーからの提案内容を公正に評価するには、評価時に起こしやすいエラー（過ち）を犯さない事が求められます。
⼼理学的にも提唱されている⼈間が陥り易い認知バイアス（評価を歪めるエラー・注意点）を以下にまとめます。
| 認知バイアス | 各々の認知バイアスの内容 | |
|---|---|---|
| 1 | ハロー効果 | ある対象を評価をする時に顕著な特徴に引きずられて他の特徴についての評価が歪められる現象のこと。（例えば、⼀つ 優れた項⽬があると、他の項⽬も優れていると評価してしまう事） |
| 2 | 寛⼤化傾向 ・ 厳格化傾向 | 寛⼤化傾向は、全般的に評価結果が⾼めになってしまうこと。その原因としては、評価者が対象の業務内容に精通してない、 などが考えられる。（厳格化傾向は上記の逆） |
| 3 | 中⼼化傾向 | 特に、質問紙調査などにおいて「どちらともいえない」といった、ほぼ中⼼あたりで偏りの少ない判断に集中し、評価対象の差がつかないこと。 |
| 4 | 対⽐誤差 | 絶対基準ではなく、何らかのモデルを基準にして、評価対象を評価するエラーのこと。対⽐誤差により評価を過⼤あるいは、過⼩に評価してしまう危険性がある |
| 5 | 論理誤差 | 評定者が⾃分⾃⾝で評定要素間の関連性を論理的に考えてしまい、関連がある項⽬を同⼀評価、もしくは類似評価してしまう傾向のこと |
| 6 | 期末効果（直近効果） | 全ての事象を評価の対象にするのではなく、直近（評価を実施するタイミングに近い時点)の事象が強く印象に残り、評価結果に影響すること。 |
| 7 | 近接誤差 | 評定にあたって⽣じやすい⼼理的傾向のひとつで、最近の評定結果の影響を受けてしまう傾向のこと。 （例）前回の評価がｘｘだったから、今回の評価もｘｘだろう… |
| 8 | メーキング（逆算化効果） | 最初から落としどころを決めて評価してしまうこと。 絶対評価・分析的評価の意義をよく理解していない評価者が陥り易い。 |
６．きちんと契約を取り交わす為に…〜軽視できないリーガル・チェック〜
きちんと契約を取り交わすには、妥当性のある⾦額で契約する事、は⾔うに及ばず、（１）局⾯に応じた契約形態をとる事（⼀括契約しない事）、（２）各リスクを抑制する為に契約内容を適切に詰める事、が⽋かせません。
- 局⾯に応じた契約形態をとる
- 新システム導⼊の際、要件等をまとめる局⾯と、その後の設計〜開発、テスト局⾯では、対価の対象が異なる事が多い。（※また、運⽤・保守の際にも、多くの場合で同様）
- こうした場合、対価の対象が異なる契約を、「⼀括受託」などの形態でまとめて契約するのではなく、各々の局⾯に応じて、契約形態を変更する事が、相互の権利関係を明確にする上でも望ましい。
| 契約形態 | 各契約形態の意味 | 主な対象 |
|---|---|---|
| 準委任契約 | 委任者の業務の⼀部の遂⾏を受任者に委託し、受任者がこれを承諾することで成⽴する契約 | 要件定義システムテストなど |
| 請負契約 | 請負者がある仕事を完成させることを約束し、注⽂者がその仕事の結果に対して報酬を与えることを約束する契約 | 設計・開発局⾯ |
| 賃貸借契約 | 賃貸⼈が賃借⼈に、あるものを使⽤させることを約束し、賃借⼈がこれに対して賃料を⽀払うことを約束する契約 | ソフトウェア使⽤許諾 |
- リスクを抑制する為に、契約内容を適切に詰める
- ベンダーとの取引関係の中で、特にリスクが⼤きい項⽬は、予め契約内容を双⽅で協議し、合意形成しておく事が望まれる。
具体的には、①知的財産に関する権利関係、②再外注（⼆次請け、三次請け）、③ベンダーの管理責任、④契約の更新、⑤（特に役務の）サービスレベル、⑥瑕疵担保責任の範疇、保証期間などはベンダーの「⾔う通り」に契約して後々、問題とならない様に注意する必要があります。
- ベンダーとの取引関係の中で、特にリスクが⼤きい項⽬は、予め契約内容を双⽅で協議し、合意形成しておく事が望まれる。
７．業務改⾰の成果（⾒込み）とシステム投資を合わせた上申
ＩＴ規制を厳しく求められる昨今、ベンダーから提示された見積書だけを元に上申書を作成しても、経営層から差し戻される企業が多い。
経営層の適切な審議と承認を得るには、「業務改革などの改革効果」の試算・提示が欠かせない。
その為、効果の試算において、業務部門との事前討議・調整が欠かせなくなっている、といえる。
８．最適な選択をする為に…（第３部の総括）
最後に、システム選定を成功に導く為に、当社が考える３カ条を以下に列挙します。
ベンダー（各社）から⾒た案件の重要性を意識的に⾼める活動をする
- 提案ベンダーの中で「今回の案件の重要度」が⾼まると、（１）優秀な（エース級）ＳＥがアサインされる、（２）⾦額等を含む交渉で優位に働く、など多くのメリットが享受できます。
- その為には、提案ベンダーの営業担当役員やソリューション部⾨の責任者など「担当営業」以外にも接点を増やし、「会社対会社」の関係を構築する事が⽋かせません。
最初から「答え」を決めて、システム選定を儀式にする事は厳禁
- 最初から「答え」（採⽤ベンダー）を決めた出来レースは、その他の提案ベンダーに必ず察知されます。こうした出来レースは、時間や労⼒を浪費するばかりか、採⽤（予定）ベンダーを含めた全ての提案ベンダーから「全⼒提案」を得られず、割⾼な⾒積りや不利な条件での契約となるリスクが極めて⾼いです。
- 採⽤ベンダーが決まっているのであれば、わざわざ複数の提案ベンダーを集めたシステム選定プロセスは不要です。
システムだけで進めようとしない。あくまで業務改⾰の⼀環として扱う
- 基幹系システム再構築に伴い数億円単位の投資を検討する場合、「新システム導⼊に直接的な改善効果」だけで、投資額が回収できるケースは殆どありません。
- システム開発は「投資額も⼤きく」関⼼が向かいがちですが、あくまで「業務改⾰の⼀環」である事を常に意識して、経営層や業務部⾨と対話する事が重要です。
ＣＩＯパートナーズ株式会社
代表取締役 吉田明弘