はじめに
大規模システムを構築するにあたり、要件定義以降の開発業務を担う事業者の選定は最重要課題のひとつである。しかし、重要な業務であるにも関わらず、自社にノウハウが蓄積されていないことで、調達担当者が手探りで業務を進めていることも多い。
その結果、経験や技術力が不足している事業者を選定したり、結果的に費用が膨れ上がったり、最悪の場合、システムをリリースできないという事態も招きかねない。
これら事態を防ぐためにも、大規模システムの調達業務（ウォーターフォール型での開発を想定）、さらにRFI工程にフォーカスして、数多く見受けられる課題とその対応策についてお伝えしたい。
なお、ここで解説する調達業務とは、要件定義以降のシステム開発業務の調達を指しており、一般的には、IT戦略に基づいたシステム化基本計画が策定された次の段階で実施されるものである（図表参照）。
システム調達業務には、RFI（情報提供依頼／情報提供依頼書）、RFP（提案依頼／提案依頼書）、RFQ（見積依頼／見積依頼書）の実施が含まれるが、既に要望の実現方法や費用感が分かっている場合はRFIを省略したり、スケジュールの兼ね合いでRFPとRFQをひとまとめで実施したり、その時々で実施スタイルを変えることとなる。
本記事では、下図に記載のRFIの各フェーズで見受けられる課題と対応策について説明する。
図 システム導入の流れとRFI実施の位置づけ
1.RFIの実施工程
RFIの目的は、システム調達を行うにあたり、システム化要望（システム化することで解決したい課題など）に対するよりよい実現方法の情報提供、そしてその方法を実施するにあたっての費用感、必要となる期間など、基本情報を収集することにある。
実施に必要となる準備としては、システム開発の目的の明確化・社内共有、役割分担、要求事項の取りまとめ、調達範囲・単位・方式の検討、その他前提事項の検討、RFIの作成、RFI依頼先事業者の選定、事業者対応（説明会や質疑応答の実施）などがある。これらの工程で、課題としてあがりやすい事項とその解決策について触れていきたい。
2.システム開発の目的の明確化・社内共有
まずはシステム開発の目的の明確化・社内共有で見受けられる課題に着目する。
「何を解決するためにシステムを開発するのか」これはシステム化の基本計画策定段階で議論がなされているべき話であり、ここでは策定された目的の再確認（認識の共有）が求められるわけだが、そもそも目的が不明確であったり、設定した目的を関係者間で十分に共有されていなかったりということは往々にしてある。
目的が不明確である場合、要件を決める際の判断の拠り所が不明確となり、検討に想定以上の時間を要したり、費用だけを重視した議論となったりしかねない。
また、設定した目的が関係者間で十分に共有されていない場合は、議論が発散しやすく、時間切れのため納得感の低い形で議論を終えることとなり、後々に議論の蒸し返しが発生しやすくなる。
そのため、物事を判断する際には目的に立ち戻れるよう、プロジェクトのキーパーソンを含むメンバー全員で、打ち合わせの度に繰り返し目的の振り返りを行うことが勧められる。
3.役割分担
役割分担では調達業務フェーズにおける、各部署の役割分担を行う。調達業務を含むプロジェクト全体の体制構築はプロジェクト発足時に定められることとなるが、各フェーズでの詳細な役割分担は都度調整が必要となる。
そして、ここで見受けられる課題が「役割の明確化」である。システム開発だからシステム部に任せるという考え方もよく見受けられるが、それでは実際の業務が考慮されない、実務に耐え難いシステムとなりかねない。
特に調達段階では、システム化の目的が果たせるよう、目的に対する責任を負っているユーザー部門の積極的な参加は必須となる。もしもユーザー部門を動かすことが難しい場合は、トップダウンで調整することが勧められる。そのためにも、体制構築時から経営層を巻き込んでおくことが肝要である。
4.要求事項の取りまとめ
要求事項の取りまとめでは、現場から経営層まで幅広く意見を吸い上げること多いが、ここでよく見受けられる課題は、RFI段階で事業者へ伝える要求事項の粒度感や業務要件の決定である。言い換えると、RFIを通して得たい情報の決定となる。
要求事項を現場から経営層まで幅広く確認した場合、要求事項の粒度感が異なったり、業務要件とシステム要件が入り混じっていたりするため、何を事業者へ伝えればよいのか選定に困惑することが多い。だからといって、収集した要求事項をそのまま事業者に伝えると、事業者も、何の情報を求められているのか分からず、結果、的外れな情報の提供となりかねない。
このような事態を防ぐためにも、要求事項の取りまとめ段階ではRFIの実施目的に立ち戻ることが重要となる。RFIの目的は、システム化することで解決したい課題に対し、よりよい解決策（実現方法）の情報を収集することである。そのため、RFI段階では、解決したい課題、つまり、業務要件にフォーカスし、実現方法は指定せず、事業者に考えてもらうことが重要となる。
業務要件にフォーカスするためにも、収集した要求事項は、業務要件とシステム要件に分類し、細かな業務要件については統合していくという作業が必要となる。様々な実現方法について、実現可否を確認したい気持ちも分かるが、事業者の創意工夫を促すためにも、実現方法の指定は極力避けたいところである。
5.調達範囲・単位・方式の検討
調達範囲・単位・方式の検討では、システム化範囲、調達単位、事業者の選定（評価）方式の検討が行われる。ここで課題としてあがりやすい事項として、適切な調達単位の設定がある。調達範囲が広範である場合は、調達単位を一括とするのか、もしくは分離するのかの検討が必要となる訳だが、どのように決めればよいのか正解が分からないという声を聞くことも多い。
一括調達とする方がシステム間連携の調整が容易となったり、契約対象となる事業者が1社となることで事務作業もシンプルとなったり、メリットがある。一方で、調達範囲が広い程、応札できる企業が限られたり（大企業しか参入できないなど）、サブシステムのカスタマイズ性が落ちたり、ベンダーロックインが発生しやすくなったりする。ちなみに、分離調達を行う場合は一括調達のメリット／デメリットと逆の内容となる。
調達単位検討の際は、上述のメリット／デメリットを踏まえ、自社にとって見過ごすことができないメリットやデメリットは何かを明確にしたうえで、調達単位の方針を検討する必要がある。ただし、RFI段階では、調達単位の目星は立てながらも、確定しないことで、事業者のRFI参加を促し（早期の離脱を防ぐ）、事業者が得意とする分野について広く情報提供を得られる形とすることが勧められる。
6.その他前提事項の検討
その他前提事項の検討としては、システムのリリース時期の設定、セキュリティレベルの設定、事業者の作業場所や機器の設置場所の指定有無などがある。ここで見受けられる課題としては、譲歩可能な前提条件の選定がある。
RFIでは前提条件を踏まえた情報提供を依頼するわけだが、前提条件を厳しくすればするほど、不調や費用高を招くこととなる。また、既存事業者が居る場合、前提条件を厳しくすることで、「新規事業者の参入を受け入れるつもりが無いのでは？」「既存事業者へ依頼する前提で、形だけの調達を行おうとしているのでは？」と受け取られ、RFIの辞退を招きかねない。
RFIでは、多くの事業者に参加してもらい、広く情報提供してもらうことが目的となるため、妥協可能な条件を明示し、議論の余地があることを示す必要がある。そのため、どうしても譲れない条件、見直し可能な条件やその範囲、条件設定の理由（懸念事項）を明らかにすることが勧められる。
そして上述の課題をひとつずつ解決したうえで、検討結果をドキュメントにまとめ、ようやくシステム開発事業者へ情報提供の依頼を行うこととなる。
ここでお伝えした、システム開発の目的の明確化・社内共有、役割分担、要求事項の取りまとめ、調達範囲・単位・方式の検討、その他前提事項の検討といった各工程で見受けられる課題については、解決が後手に回ると、問題が肥大化し、対応に苦慮することとなるため、可能な限り各工程内で解決することが勧められる。