要求の明確化

設計フェーズの概要：RFPという羅針盤の準備、要件定義という航海図の策定

ITインフラ基盤構築プロジェクトにおける設計フェーズは、まさに航海の計画を立てるようなものです。その中でも「要求定義」は、目的地を明確にし、どのような船で、どのようなルートで向かうのか、その大まかな全体像を描く、非常に重要な段階と言えるでしょう。このフェーズで、クライアント様が「何をしたいのか」「何が必要なのか」を具体的に言語化し、プロジェクトの目指すべき方向性を定めます。

私たちがプロジェクトを進める上で、この要求定義がしっかりしているかどうかが、その後の全てに影響してきます。後になって「思っていたのと違う」とならないためにも、この段階でしっかりと話し合い、お互いの認識をすり合わせることが不可欠です。RFPという羅針盤が正確でなければ、どんなに素晴らしい航海士がいても、目的地にはたどり着けませんからね。近年では、アジャイル開発プロセスを採用するケースも増えていますが、初期の要求定義の重要性は変わりません。

クライアントサイドの視点：あなたの「本当に欲しいもの」を伝えるために

ITインフラ基盤構築プロジェクトにおいて、クライアントである皆様の役割は、まさに「夢を語る人」です。この「要求の明確化」フェーズでは、皆様が「ITで何をしたいのか」「どんな課題を解決したいのか」「将来的にどうなっていたいのか」といった、漠然としたイメージを具体的な言葉でベンダーに伝えることが求められます。これが、RFP（提案依頼書）という羅針盤の形で表現されることが多いですね。

「でも、ITのことなんて詳しくないし…」そう思われる方もいらっしゃるかもしれません。ご安心ください。専門知識はベンダーが持っています。皆様にお願いしたいのは、「どんな未来をITで実現したいか」という、皆様のビジネスの根幹に関わる部分を、率直に、そして遠慮なくお話しいただくことです。時には、「あれもこれも」と欲張りたくなる気持ちも分かります。しかし、本当に必要なものは何か、優先順位はどうつけるのか、といった点も、ベンダーとの対話を通じて整理していくことが大切です。過去には、クライアント様が「とにかく早く」とだけお伝えになり、結果的に本来の目的から外れたシステムが構築されそうになったこともありました。そうならないためにも、しっかりと対話を通じて、皆様の「本当に欲しいもの」を明確にしていきましょう。特にクラウドネイティブ環境やIaC（Infrastructure as Code）の導入を検討されている場合は、将来的な運用や拡張性も視野に入れた要求の提示が重要になります。

ベンダーサイドの視点：お客様の想いを「形」にする第一歩

ベンダーサイドの私たちにとって、この「要求の明確化」フェーズは、お客様の想いを「形」にするための、まさに最初のステップです。クライアント様からのRFPという羅針盤、あるいは直接のヒアリングを通じて、漠然とした「やりたいこと」や「困っていること」を、具体的なITインフラの要件へと落とし込んでいきます。そして、それを基に要件定義という航海図を作成していきます。

この段階で特に意識するのは、「なぜそれが必要なのか」という本質的な問いかけです。お客様が「Aという機能が欲しい」とおっしゃった場合、私たちは「なぜAが必要なのか？」「Aが解決する課題は何なのか？」といった深掘りを行います。そうすることで、お客様自身も気づいていなかった本当のニーズや、より良い解決策が見えてくることがあるからです。

例えば、以前あるお客様から「とにかくストレージを大容量にしたい」というご要望がありました。詳しくお話を伺うと、実際にはデータの保存期間やアクセス頻度に応じた階層化ストレージの方が、コスト面でも運用面でも最適解であることが判明しました。

このように、お客様の言葉の裏にある真意を汲み取り、専門家としての知見を加えて、最適な提案に繋げることが私たちの役割だと考えています。このプロセスにおいて、セキュリティ要件やDevOpsの考え方を初期段階から組み込むことで、より堅牢で効率的なインフラ基盤を構築する土台を築きます。

設計成果物の詳細：RFPという羅針盤と、要件定義書という航海図を使いこなす

「要求の明確化」フェーズにおける代表的な成果物として、「RFP（Request For Proposal：提案依頼書）」と「RFI（Request For Information：情報提供依頼書）」、そして「要件定義書」が挙げられます。これらは、まさにベンダーに「こんなシステムが欲しいんだけど、どうかな？」と問いかけ、その具体的な道筋を示すための、重要なコミュニケーションツールとなります。

• RFI（情報提供依頼書）:
  まだ具体的な要件が固まっていない段階で、市場にどのようなソリューションがあるのか、どのような技術トレンドがあるのかなどを広く情報収集するために発行します。特定のベンダーに絞らず、幅広いベンダーから情報を得ることで、自社のニーズに合ったソリューションを見つける手がかりとします。目的としては、情報収集と市場調査の側面が強いですね。
• RFP（提案依頼書）:
  RFIである程度情報収集が進み、自社の要件がある程度固まった段階で、具体的な提案を求めるために発行します。RFPには、システムの目的、達成したい目標、具体的な機能要件や非機能要件、予算、納期などが詳細に記述されます。ベンダーは、このRFPという羅針盤に基づいて、具体的なシステム構成や費用、開発スケジュールなどを盛り込んだ提案書を作成します。
• 要件定義書:
  ベンダーがRFPに基づいて提案を行い、クライアントとベンダー間で合意が形成された後、プロジェクトの具体的な方向性を示す航海図として作成されるのが要件定義書です。RFPで示された大まかな方向性を、より具体的かつ詳細な機能要件、非機能要件、システム構成図、データフローなどを盛り込み、プロジェクトメンバー全員が共通認識を持てるようにします。近年では、クラウド環境の特性を考慮した要件や、セキュリティバイデザインの観点も盛り込むことが一般的です。

どちらも非常に重要な書類ですが、作成する際には、自社の状況と目的に合わせて使い分けることが肝要です。これらの書類が明確であればあるほど、ベンダーからの提案も的確になり、結果としてプロジェクトの成功に繋がります。

品質保証とテストの観点：航海図が正しく描かれているかを確認する目

ITインフラ基盤構築プロジェクトにおける品質保証とテストは、完成したシステムが「要求の明確化」フェーズで定めたお客様のニーズを本当に満たしているのかを確認するための、いわば「目」のようなものです。RFPという羅針盤と、要件定義書という航海図の段階でどれだけ綿密に計画を立てたとしても、実際に構築されたものがお客様の期待通りであるかは、テストを通じてしか確認できません。

単体試験、結合試験、総合試験といった様々なテストフェーズがありますが、それぞれの目的は異なります。
単体試験では個々のコンポーネントが正しく動作するか、結合試験では複数のコンポーネントが連携して動作するか、そして総合試験ではシステム全体としてお客様の要求を満たしているか、といった観点で検証を行います。テスト計画の策定やテストケースの設計は、この要件定義書の内容をベースに行われます。もし、要件定義書があいまいであれば、どのようなテストを行えばよいのかも不明瞭になり、結果として品質が保証されないシステムになってしまう可能性があります。

例えば、過去に経験した事例では、要件定義での非機能要件（性能や可用性など）の記述が不十分だったため、テスト段階で想定したレスポンスタイムが出ず、本番稼働後にパフォーマンス問題が発生したケースがありました。この場合、初期の段階で「ユーザーが同時に何人アクセスしても〇秒以内に応答する」といった具体的な数値を航海図（要件定義書）に盛り込んでいれば、早期に問題を発見し、手戻りを最小限に抑えられたはずです。一方で、要件を過度に厳しく設定しすぎたために、実現が困難になったり、過剰なコストがかかったりする「失敗パターン」もあります。成功の鍵は、現状の課題と将来の目標をバランス良く盛り込むことにあると言えるでしょう。

運用設計と継続的改善：未来を見据えた航海図の重要性

ITインフラ基盤構築は、システムが稼働して終わりではありません。むしろ、稼働後の「運用」こそが、システムの価値を最大化し、長く使い続けるための要となります。この「運用設計」もまた、要件定義という航海図と密接に関わってくる重要な要素なのです。

システムが稼働した後に、どのような運用体制が必要なのか、監視はどうするのか、バックアップやリカバリはどう計画するのか、インシデントが発生した際の対応フローはどうするのか、といった点を事前に検討し、設計に盛り込んでおく必要があります。これらの運用要件も、お客様のビジネスの特性やリスク許容度によって大きく異なります。例えば、24時間365日止まってはいけないシステムであれば、非常に堅牢な運用設計が求められますし、多少の停止が許容されるシステムであれば、それに合わせた設計でコストを最適化することも可能です。DevOpsの観点から見ても、運用設計を開発の初期段階から考慮することで、継続的な改善サイクルがスムーズに回るようになります。

プロジェクトの初期段階で未来の運用まで見据えた要求を明確にし、それを航海図に落とし込んでおくことで、稼働後のトラブルを未然に防ぎ、継続的な改善サイクルを回していくための基盤を築くことができます。