要件定義は、システム開発において達成すべきシステム機能や性能などを明確にする工程である。要件定義では、業務部門はシステムで実現したいことを明確にし、IT部門は業務部門の要望を基に実装するシステム機能や性能などを検討していく。業務部門とIT部門で検討した結果は、要件定義書に取りまとめた上で合意するのが一般的だ。

　IFRS対応などで新たなプラットフォームを導入する場合の進め方は、（1）現行業務・システム機能を棚卸し、（2）新たな業務に対するシステム要求事項を整理した上で、（3）新システムの機能を明確化、それを基に、（4）システム実現案（業務パッケージ選定）を検討し、最終的には予算や期限を鑑みて、（5）システム機能のリリース順序決定、という順番で行う。

　この進め方における難所の1つは「（1）現行業務・システム機能の棚卸し」にある。新たなプラットフォームを導入する場合、基本的に全てのシステム機能は作り直しになる。その際、現行のシステム機能の中からどの機能を新システムへ引き継ぐかを決めなければならない。本作業にて十分な調査・検討を怠ると、サービス開始直前にシステム機能の漏れが発覚する、あるいはリリースしたが業務上利用されないシステム機能が多くなり、システム機能の開発に掛けた費用や労力が無駄となるといった悲劇が起こる。ある事例では、現行踏襲という名の下に約1万8000のシステム機能をそのまま新システムへ実装する方針で進めていたが、要件分析の過程で実際に利用されているシステム機能が5000程度であることが判明した。

　もう1つの難所は「（5）システム機能のリリース順序決定」にある。予算や期限上の制約からシステム機能を一度にリリースできない場合、システム機能の中からリリースするものを選別しなければならない。その際、どのような観点でシステム機能を分類し、どのようなリリース方針とすべきか判断できないケースが多々ある。システム機能を検討したメンバーは自分の定義したシステム機能に対する思い入れが強く、そのため誰も譲らずいつまでたっても決まらないという状態になってしまう。

　要件定義の推進に関しては、これらの2つの難所を乗り切るための運用術を紹介する。

• 運営術（1）：システム・業務の観点で現行システム機能の利用実態を調査し、真に必要なものを見極める
• 運営術（2）：経営上の位置付けからシステム機能を分類し、リリースの順序を決める

運営術（1）：システム・業務の観点で現行システム機能の利用実態を調査し、真に必要なものを見極める

　1つ目は、「現行業務・システム機能の棚卸し」で、現行のシステム機能から、真に必要なものを見極めるための運営術だ。システム機能の見極めは、業務プロセス上の必要性を踏まえた整理が必要となるため業務部門を巻き込んだ上で実施すべきである。システム機能の必要性は、システム上の利用可否の調査および業務上の利用実態の調査を基に特定する。具体的には4ステップで進めていく。

Step1　現行システム機能洗い出し

　IT部門にて、現行システムに登録されているシステム機能の全量を、仕様書などを基に洗い出す。

　仕様書が整備されてない場合は、画面／帳票／システム間インタフェース／バッチプログラムといった観点からプログラムを調査し、一覧表に取りまとめる。なお、本ステップはあくまでシステム機能の全量把握が目的であるため、洗い出しは機能名称など機能概要が分かる程度でとどめておく。

Step2　システム上の利用可否調査

　次に、洗い出したシステム機能が実際に利用できるか調査する。システム機能の中にはプログラムとしては存在するが、実際には既に廃止扱いになり利用できないものもある。利用可否を調査する際は、プログラム構造を可視化するツールを利用すると効率的だ。ツール入手が困難であれば実際にシステムを利用して確かめる。例えば、画面であればメニュー画面から入力画面へ遷移し、入力業務が問題なく完了することを確認するといった具合だ。

Step3　業務上の必要性整理

　続いて、IT部門・業務部門協同で、利用可能なシステム機能が業務プロセス上どの程度必要なものか整理する。

　システム機能の中には過去のサービスや規制に基づいて実装したものの、もはや利用してないものもある。それらを抽出し、捨てる判断をするため、システムのアクセスログなど利用状況を定量的に把握可能なデータを入手しておく。最終的に移行しないシステム機能を見極めるため、特に利用のないもの、もしくは少ないものについては業務プロセス上必然性を整理しておくことが肝要だ。

Step4　新システムへの実装機能特定

　最後に、業務部門でシステム機能の利用状況と業務上の必要性を踏まえて新システムへの実装機能を見極める。

　業務利用の多い、あるいは通常利用されている機能は実装対象とし、業務利用なしのものは実装対象外を原則とする。業務利用が少ない機能は、業務継続と収益性の観点から実装要否を決定する。この原則を踏まえてシステム機能を「実装必須」「可能であれば実装」「実装不要」の3種類に分類し、実装機能を見極める。

　要件定義ではこのような進め方で必要な機能を特定し、ユーザー受け入れテストで最終確認することで、必要なシステム機能の実装漏れや、不要なシステム機能の作り込みを防ぎ、ビジネス効果の高い新システムを構築することが可能となる。

運営術（2）：経営上の位置付けからシステム機能を分類し、リリースの順序を決める

　2つ目は、「システム機能のリリース順序決定」にて、システム機能のリリースの順序を決めるための運営術だ。リリースの優先順位は、ビジネス効果に直結するため経営層を巻き込んで決定すべきである。システム機能の経営上の位置付けは、業務継続上の対応要否と効果創出の大きさの2つの観点から整理する。具体的には、システム機能を4つに分類した上で、リリースの順序を検討していく。

1. 業務継続機能

　現行サービスを維持するための機能であり、本システム機能なくしては業務が成り立たない。従ってこの機能は初回リリース時に全て盛り込んでいく必要がある。なお、やむを得ず段階リリースする場合、リリースされない機能は当面既存システムを利用することになるため、そのためのインタフェースを検討しておく。

2. 制度対応機能

　法律や規制順守のための機能であり、これも企業として対応必須であるが、法律や規制の施行開始までは一定の猶予がある。これらのシステム機能は、制度対応の時限性を踏まえて、プロジェクトにおける段階リリースのタイミングとの整合性を取りつつ対応するよう考慮する。

3. 戦略機能

　コスト削減やリスク回避などの大きな効果を創出するための機能であり、早期にリリースすることで収益向上の効果も早く享受できる。従って業務継続機能や施行開始の迫った制度対応機能を対応した上で、可能な限りリリースを前倒すことを検討する。

4. 業務改善機能

　業務を改善するための機能であり、業務継続上の必要性や、収益向上の効果はそれほどない。しかし、現場社員のモチベーションに直結するものも多いので、主軸となる機能のリリース順序を決めた上で、業務改善機能の優先順位と、各種リリースへの影響や対応余力を考慮し段階的なリリースを定義するとよい。

　このようにシステム機能を経営上の位置付けから分類しリリース順序を検討することで、限られた予算や期限を守りながらも、最大のビジネス効果を発揮するシステム機能をリリースしていくことが可能となる。

信頼できるベンダを選定するためのプロジェクト運営術

　システム開発を成功させるためには、パートナーとなるベンダの選定が非常に重要である。しかしその難易度は高く、ベンダ起因によるシステム稼働時期の延期や、稼働後のシステムトラブル頻発といった話をよく耳にする。失敗の原因をベンダ側の過失として簡単に終わらせてしまうのではなく、ユーザー企業側のベンダ選定プロセスにも改善の余地がないかいまいちど振り返る必要がある。

　ベンダ選定の進め方は、（1）RFP（Request for Proposal　提案依頼書）の作成と展開、（2）評価基準の策定、（3）ベンダ提案受け入れ、（4）コンペ実施、（5）提案評価・ベンダ選定　という順番で行う。

　この進め方における難所の1つは「（1）RFPの作成と展開」である。RFPは、システム開発などを発注するに際して候補先のベンダに具体的な調達要件を示すための文書である。ベンダはRFPに従って提案書を作成するため、RFPで提示した要件が不足している、あるいは要件が曖昧な場合、自社製品の提案に終始した提案書や、要件と異なる新たな提案書がベンダから提出される事態が起こり得る。

　もう1つの難所は「（2）評価基準の作成」である。ベンダ選定においては、価格はもちろん要件の充足性など複数の評価基準が考えられるが、事前に明確な基準と各基準に対する重み付けを定義せずに価格のみを重視した結果、十分なスキルを持たないベンダが選定されてしまい、プロジェクトが失敗する可能性もある。

　ベンダ選定に関しては、これら2つの難所を乗り切るための運用術を紹介する。

• 運営術（1）：三位一体（調達部門、業務部門、IT部門）で、網羅性・充足性のあるRFPを作成する
• 運営術（2）：ユーザー企業の狙いと結びついた評価軸を設定し、真のパートナーとなり得るベンダを見極める

運営術（1）：三位一体（調達部門、業務部門、IT部門）で、網羅性・充足性のあるRFPを作成する

　システム開発を調達する場合、その専門である調達部門がRFPを作成するケースは多い。しかし調達部門のみでRFPを作成してしまうと、業務部門、IT部門が重視している要件が織り込まれず、網羅性・充足性のないRFPになる可能性が高くなる。そのため、調達部門が全体を取りまとめ、個別事項を業務部門とIT部門がそれぞれ詳細化するなど、一体となってRFPの作成を行う必要がある。

　各部門がRFPを作成する際に主に盛り込むべき項目は以下の通りである。

調達部門

• 契約事項：契約形態、契約期間、費用支払、機密保持、著作権など、契約に当たっての基本事項を示す：契約形態、契約期間、費用支払、機密保持、著作権など、契約に当たっての基本事項を示す
• 委託内容：作業範囲、納品成果物などを定義することで、ユーザー企業とベンダの作業分担、提示を求める成果物を明確化し、契約開始後の認識の違いを防止する：作業範囲、納品成果物などを定義することで、ユーザー企業とベンダの作業分担、提示を求める成果物を明確化し、契約開始後の認識の違いを防止する
• 提案方法：提案書および見積書の記述要領を提示し、各ベンダが同様の記載フォーマットに則ることで、横並び確認を容易にする：提案書および見積書の記述要領を提示し、各ベンダが同様の記載フォーマットに則ることで、横並び確認を容易にする

業務部門

• 目的：システム化の背景と具体的な達成目標を提示し、ベンダと共有する：システム化の背景と具体的な達成目標を提示し、ベンダと共有する
• 業務概要：当該システムにより実現される業務内容やサービス対象を提示し、ベンダの業務に対する理解を深める：当該システムにより実現される業務内容やサービス対象を提示し、ベンダの業務に対する理解を深める

IT部門

• システム概要：（システム更改案件の場合）現行システムの全体像、機能一覧、環境構成などを提示することで、ベンダの現行システムに対する理解を深める：（システム更改案件の場合）現行システムの全体像、機能一覧、環境構成などを提示することで、ベンダの現行システムに対する理解を深める
• 委託内容：システム化の範囲、セキュリティ要件、非機能要件、スケジュール、システム側体制などを提示することで、ベンダからの具体的な提案・見積もりを可能とする：システム化の範囲、セキュリティ要件、非機能要件、スケジュール、システム側体制などを提示することで、ベンダからの具体的な提案・見積もりを可能とする
• ベンダ要件：ベンダおよび参画するプロジェクトマネジャー、リーダー層に求める実績・知識・経験を定義するとともに、標準化された開発管理手法の保持を義務付ける：ベンダおよび参画するプロジェクトマネジャー、リーダー層に求める実績・知識・経験を定義するとともに、標準化された開発管理手法の保持を義務付ける

　このように、各部門が提示すべき要件を詳細に定めることで、網羅性・充足性のあるRFPの作成が可能となる。

運営術（2）：ユーザー企業の狙いと結びついた評価軸を設定し、真のパートナーとなり得るベンダを見極める

　ベンダ選定における評価軸を設定する際、RFPに記載した調達要件を一律に評価するだけでは十分でない。ユーザー企業がシステム開発において達成したいこと、およびシステム開発における重要テーマが実現可能なベンダを選定できるよう考慮すべきである。

　以下は、弊社が支援した大規模システム更改案件における評価軸の一例である。

必須条件

　評価に値するベンダか見極めることを目的に、ユーザー企業が指定したフォーマットに則って提案しているかといった形式的なチェックとともに、経験や実績、保有する技術、必要とする資格などから、ベンダの信頼性を判断する。この評価観点が全て満たされていることを最低条件としている。

要件充足性

　システム開発において達成したいことが実現できるベンダか判断するために、ユーザー企業が求める要件に対して実現性のある提案をしているか評価する。

ここでは各種要件の優先度に応じて配点を行い、優先度の高い要件に対して有意義な回答をしていること、かつ一定以上の点数をクリアすることを条件とする。

重要テーマへの対応

　その大規模システム更改案件において重要テーマ、例えばコスト削減への貢献、システムの拡張性・将来性、品質向上への貢献などの観点において要件を満たしているか評価する。

　ここでは各テーマの優先度に応じて配点を分割し、評価を行う。

価格評価

　各ベンダの提案価格を点数化して評価する。評価全体に占める価格評価の割合を50％と、要件に対する評価と価格に対する評価の重み付けを同等のレベルとしている。

　このように、ユーザー企業がシステム開発に求める要件を反映した評価軸を作成することで、信頼できるパートナーとなり得るベンダを選定することが可能になる。また、提案内容の評価はもちろんだが、実際にプロジェクトを担当するマネジャーに提案内容のプレゼンを依頼し、プロジェクトの目的や推進上のポイントを把握しているか、信頼に足る人間性か定性的に確認していくことも重要だ。

さまざまな難所を乗り越えていくために

　IT部門・業務部門の連携タスクを成功へ導くための運営術について、要件定義、ベンダ選定を例に述べてきた。推進におけるポイントは第3回「経営と業務部門の協力を引き出すプロジェクト運営術」でも示したとおり、関連部門で合意しておくべきことを明確にした上で、検討した内容をプロジェクトの正式な成果物へ取りまとめていくことである。正式な成果物として残すことで現在のタスク推進に寄与することはもちろん、将来同様のタスクが発生した場合にも参考にすることができるためタスク推進の運営と成果を継続的に高めていくことが可能となる。

　また要件定義やベンダ選定は、ビジネス効果やプロジェクトの成否を左右するような重要なタスクであるため、最終段階では必ず経営層を巻き込んで正式な承認を得ることが重要だ。そうすることで経営層、業務部門、IT部門が一体となったプロジェクト運営が可能となるだろう。

　次回は最終回として、大規模・全社規模のプロジェクトを安定して運営していくことを目的とした、プロジェクト計画段階でのリスクの識別や品質管理の要諦について考察する。