情報システム構築におけるアンカリングの悪影響を緩和する手段についての研究－ 大規模ＥＣシステムの失敗プロジェクトの事例分析を基礎とする提案芦塚裕一＜論文の概要＞１．研究の背景と問題意識
情報システム構築プロジェクトの失敗については多くの事例が発表され、その原因についても様々な研究がなされている。情報システムプロジェクトの失敗として、リリース予定日の遅延、当初予算の超過、リリース後障害によるトラブル等があげられるが、最悪の場合「動かないコンピュータ」としてシステムのリリースそのものが出来ない状態になってしまうケースもある。特に営利企業における情報システム構築プロジェクトの失敗は経営に大きなダメージを与えてしまうケースもある。また、大手金融機関のシステム統合プロジェクトの失敗例のように社会問題化してしまう例もある。
一定規模以上の情報システム構築プロジェクトの場合、様々なステークホルダーが複雑に関与しながら、膨大なタスクを実施・統合してゆく必要がある為、失敗プロジェクトとなるリスクは他の経営プロジェクトよりも比較的多いと思われる。
情報システム構築プロジェクトに関わらず、そもそもあらゆるプロジェクトには必ず失敗する可能性が存在する。そして、それぞれのプロジェクトにはその特有の失敗要因があるはずであり、情報システム構築プロジェクトにも「特有の失敗要因」はあるはずである。
これまで情報システム構築の失敗要因についてプロジェクト管理技法を中心として様々な先行研究が行われてきているが、情報システム構築プロジェクトの意思決定に関して情報処理能力の観点から失敗要因を分析した研究はほとんど見当たらない。しかし、実際の情報システムプロジェクトの失敗は、意思決定の情報処理的な側面による意思決定の失敗を要因としているケースが少なくないと思われる。本研究では情報システム構築プロジェ
クトの意思決定に関する情報処理的な失敗要因について、意思決定のアンカリング分析モ
デル〔渡邉晶子（2006）〕を参考に、実際に行われた情報システム開発を事例として、「情報システム構築プロジェクトに悪影響を与えるアンカリング」を構築プロセス毎に整理する。そのうえで構築プロセス別に整理された悪影響を与えるアンカリングとそれを緩和する為の手段について一般化を試みたい。なお、本研究が対象とする構築プロセスは、いわゆるウォータフォール型のものである。
２．分析フレームワークについて
本研究では意思決定のアンカリングモデル〔渡邉晶子（2006）〕を基礎にして、大手百貨店の大規模 EC サイト構築プロジェクトの失敗事例を分析し、そのプロジェクトの失敗要因となったアンカリングの抽出・整理を行なう。そして、その抽出・整理を土台にして、情報システム構築プロジェクトに悪影響を与えるアンカリングの一般化を試みる。
先行研究〔渡邉晶子（2006）〕では、アンカリングを「可能集合の主観的限定」と定義している。アンカリングは、比喩的にいえば、意思決定者が意思決定前提に対して、「錨」を降ろしてしまう事である。本研究では上記の定義を基本的に引継ぐ。このアンカリングによって意思決定できる範囲が限定されてしまう為、アンカリングへの対応がシステム構築プロジェクトの失敗の原因となることがあると想定する。そして、対応次第で致命的な失敗を回避することができると想定して、「悪影響を与えるアンカリングへの対応」の定石を示す。なお、アンカリングは「避けるべき偏見」と同じものではない。それぞれの段階で「可能集合の主観的限定」がなされなければ、意思決定はできない。逆に、上手な「可能集合の主観的限定」によって、情報処理能力に限界がある意思決定者は効率的な判断を行うことができるのである。したがって、本研究が目的にすることは、アンカリングの悪影響を緩和する手段の提案であって、アンカリングの排除ではないことに注意が必要である。
本研究では、渡邉晶子（2006）の発展として、情報システムの失敗に影響を与えるアンカリングを情報システムの構築プロセス別に整理する事を試みた。本研究で対象とする情報システム構築プロセスはウォータフォール型のシステム構築プロセスである。具体的には「経営意思決定（経営戦略策定）／IT 課題の抽出／RFP 作成／提案依頼・評価/開発方式の選択／スケジュール・予算策定/ベンダー選定・契約/要件定義/外部・内部設計／テスト・リリース」の順番で情報システム構築が進むことを想定して、それぞれの段階でプロジェクトの失敗に繋がる可能性が高いアンカリングを事例から抽出し一般化した。
なお、本研究は、ユーザー側の視点からアンカリングへの対応を考えるものである。したがって、本研究では、情報システム構築を実際に行うベンダー側の視点ではなく、情報システム構築を発注側から、すなわちユーザー側の視点からプロジェクトの失敗に影響を与えるアンカリングを抽出・整理する。
３．本研究の対象事例
本研究が考察の基礎とした事例は、「大手百貨店Ａ社の大規模 EC システム構築プロジェクト」である。本事例を対象とした理由は、①当初計画されたリリース予定日の遅延や、予算超過などの面で失敗したプロジェクトであること、②いくつかのアンカリングによる悪影響が失敗に繋がった典型的な事例であること、③当該プロジェクトメンバーから直接事例の情報を入手可能なこと、を理由としている。
Ａ社は我国を代表する大手百貨店で連結売上高は 1 兆円を超えているが、競合大手百貨店と比較すると 30～40 歳代の女性に対するファッション系商品（主にアパレル商品）の売上が少なく、このセグメントにおける売上強化が大きな経営課題となっている。その課題の解決手段の一つとしてファッション系商品に特化したモール型の EC サイトを構築し、ファッション系商品の販売を強化する事を意思決定し、経営トップの「社運をかけて取組む」という号令のもと、該当 EC サイト構築のプロジェクトが開始された。しかし、プロジェク

ト開始の意思決定からリリース予定日までの期間が約 5 ヶ月程度しかなく、当初からスケジュールに余裕の無いプロジェクトであった。その結果、最終的には①リリース予定日からの遅延、②当初予算の超過、③リリース後のシステムトラブルなどが発生してしまう結果となってしまった。
４．事例分析の整理
Ａ社の EC システム構築プロジェクトの構築プロセス毎に悪影響を与えたアンカリングを整理したものが以下の表である。

〔表：A 社プロジェクトで悪影響を与えたアンカリング〕

このプロジェクトでは、そもそもスケジュールに余裕の無いプロジェクトであったこともあり、各段階の意思決定の「可能集合」が狭く設定される傾向があった。その「可能集合」は意思決定者のアンカリングによって設定されたものであるが、そのアンカリングがシステム構築プロセス全体を通して、結果として悪影響を及ぼすことになった。
本事例におけるプロジェクトの本事例におけるプロジェクトの失敗は①スケジュールの遅延、②予算の超過、③リリー
失敗は①スケジュールの遅延、②予算の超過、③リリー
ス後のシステムトラブルの 3 点であるが、その結果を導く要因となったアンカリングはそれぞれの失敗毎に異なっていると考えられる。スケジュールの遅延に関しては経営 TOP からの過大な期待とベンダーへの無理な要求が悪影響を与えていたアンカリングだと解釈され、予算の超過に関しては当初予算の算定の甘さが悪影響を与えたと思われ、リリース後のシステムトラブルに関しては無理なスケジュールとレビュー不足が特に悪影響を与えたアンカリングだと考えられる。
なお、上記のアンカリングの分析は事後的な解釈であることに注意が必要である。当事者にとって、各時点では「そうせざるをえない」と思えるからこそ、アンカリングなのであり、アンカリングは自覚的に行われる失敗要因ではない。だからこそ、アンカリングへの自覚を高めることが、失敗の確率を下げるのである。
本事例から、情報システム構築プロセス毎に悪影響を与えるアンカリングの具体例をリストアップすることができた。
５．悪影響を与えるアンカリングを回避する手段
大手百貨店Ａ社の事例によって認められた「情報システム構築プロセス大手百貨店Ａ社の事例によって認められた「情報システム構築プロセス毎に悪影響を与えるアンカリング」を一般化し、そのアンカリングの悪影響を緩和する手段について考察を行った。その考察結果を整理したものが以下の表である。

〔表：情報システム構築に悪影響を与えるアンカリングと緩和手段〕

悪影響を与えるアンカリングを緩和する手段については、当該プロジェクトに参加したメンバー及びそのプロジェクトを請け負ったシステムベンダーに対して、「どうすればアンカリングを緩和できたか」という質問をプロジェクト終了後に実施し、その回答を参考にして一般化を試みた。
６．まとめ
本研究により情報システム構築プロジェクトにおいては、構築プロセス毎に異なる悪影響を与えるアンカリングが存在することが確認できた。また、それぞれのアンカリングがプロジェクトの意思決定に対して悪影響を与えることによって、システム構築プロジェクトを失敗へと導く要因となる可能性が改めて確認された。
また、システム構築プロセス毎に発生するアンカリングによる悪影響の結果は一様ではないが、悪影響を緩和する手段についてもある程度事前に予測・対応できることがプロジ
ェクトの参加メンバーへのヒアリングによって確認できた。ただし、アンカリングはそのすべてを排除することは原理的にできないのであり、悪影響を緩和する手段があらたなアンカリングを生み、それが新たな問題を引き起こす可能性がある。
本研究ではアンカリングの悪影響を緩和する手段の一般化について、A 社の事例のみによって考察している。また、ウォータフォール型の構築プロセスを前提にした一般化をおこなったものである。よって、今後はさらに分析事例を増やと同時に、ウォータフォール型以外の構築プロセスについてのパターン化と緩和手段について考察を深めてゆく必要がある。