１．はじめに
こんにちは。テクノロジーイノベーショングループ所属の長澤です。
インフラ入門な連載記事を久々に書くべく、今回筆を取りました。
これまでのインフラ入門記事は、
といった流れで来ていますが、今回はあえてピンポイントな内容から離れて、「インフラ要件定義」をテーマに書いてみたいと思います。
個人的な考え方・意見に基づくものが大半ですが、何かのお役に立てれば幸いです。
２．インフラ要件定義・・・その前に
私は、インフラの要件定義のゴールは、以下の3つだと思っています。
1. インフラでの提供機能・構成を固めること
2. システムの非機能要件を固めること
3. お買い物リスト・見積をまとめること
進め方としては、1番と2番を並行で固めていき、最後に3番と基本設計フェーズの進め方をお客様と合意します。
そのうち、初めに手を付ける1番と2番のベースとなるのは、「システムで為したいこと」となります。
すなわち、1番と2番のアウトプットは、お客様の業務・経営課題の解決や、お客様の更なる成長といったような目的を、最良の形で達成するものとなっている必要があります。
要件定義フェーズでは、アプリケーションチームとインフラチームが分かれ、それぞれの対面のお客様と話して要件を詰めていくことが多いと思います。
その際、インフラ側は業務・アプリケーションを脇に置いて、インフラだけの実装・コストや採用技術にこだわってしまう・・・みたいなことがままあります。
その結果できあがるのは、お客様がシステムで為したいことから乖離した、例えば 「性能的に業務にならない」 とか、「スカスカでToo Much」 のような残念なインフラです。
では、こういった残念な結果を回避するために、限られた時間の中で我々インフラチームはどうすべきか。
マネジャー層任せでなく、 アプリケーションチームと自ら積極的にコミュニケーションを取り、業務要件や機能要件をなるべく頭に入れておくことに尽きると、私は思っています。
コーディング以外の全てを担当するインフラチーム、特にそのリーダーは、アプリケーションチームの代弁者も担い、お客様のインフラチームに、「業務・機能要件に基づき、このインフラである」といったような説明ができるようになるべきです。
その説明が、いわゆる「システム化方針」の一部になります。
少し話はそれますが、お客様のアプリケーションチームとインフラチーム間の考え方や課題意識の相違や、コミュニケーション不全も「あるある」です。
上述のようなアプリケーションチームとの積極的なコミュニケーションは、その橋渡しを担い、プロジェクト全体が一枚岩となる一助にもなると思います。
ということで、インフラ要件定義のスタートラインは、アプリケーションチームとインフラチーム、すなわちプロジェクト全体のベクトルを合わせることであり、その結果として、プロジェクト全体が納得できるシステム化方針ができあがると、私は思っています。
（自分もまだまだできてないなぁと自戒しつつ・・・）。
「業務アプリケーションのコードになる部分以外は全て自分のタスク」という意識で、自ら動いていきましょう。
３．インフラ要件定義（前半戦）
いよいよインフラ要件定義が始まります。
インフラ要件定義では、まずは要件定義のゴールに向け、
- インフラとして提供しなければいけない機能として何があるか（※本稿では、 「インフラ機能要件」 と題します）
- インフラとしてどのような構成・レベル感で作っていくべきか（※本稿では、「インフラ非機能要件」 と題します）
といった部分の仮説を立てます。
これらは、 「システムとして為したいこと」 に基づく必要があるのは、前述の通りです。
そのため、アプリケーションチームの要件定義を受けて具体化や肉付け、または軌道修正等も発生するため、初めから精緻なものは不要です。
一方で、自分の中にゴールイメージがないと、首尾一貫した内容にならなかったり、そもそもお客様との会話にならなかったりもするので、要件定義を始める頃には何かしら仮説を持っておくことが必要です。
インフラ要件定義では、セッションの回数や濃度等も踏まえて、そうして作った仮説を適切な議論の単位（テーマ）に分割した上で、それぞれお客様と議論していきます。
３－１．インフラ機能要件定義
インフラ機能要件定義では、「業務アプリケーションが担う処理以外にどんな機能が必要か」といったところを明文化していきます。
その際、
- 現在の持ち物で転用・相乗りできるもの
- 現在の持ち物で利用が必須のもの
- 現在の持ち物で不足しているもの
なども明らかにしていきます。
例えば、
- 既に認証基盤を持っているから、その認証基盤とSSOできるようにしてほしい
- データベースはリッチなものを持っているので相乗りしてほしい
- 新たに全社の統合ジョブ基盤として使えるジョブ基盤を作ってほしい
などでしょうか。
構成面や処理方式に関わることはもちろんですが、非機能面で引きずられる部分があったり、現行他システムへの影響を気にしなければいけなかったりもするので、「他システムと一緒に」系のお話には注意が必要です（上の例は全部そうですね）。
また、「インフラ=業務アプリケーション以外全て」と捉えると、インフラ機能要件定義を抜け漏れなくやりきるのは難しいことです。
ゆえに、なるべく抜け漏れなく対応するための一助として、各種構成図（ハードウェア、ネットワーク、ソフトウェア、アーキテクチャなど）を早めに作成すべきと、私は考えています。
視覚的に訴えるものがあれば、自分たち・お客様ともに抜け漏れや流用資産の有無なども気づきやすいですし、ある程度網羅感を持って話ができるためです。
こちらも、Factとして既におさえている部分以外は仮説ベースで作り、ブラッシュアップしていければかまいません。
ただし、最終的なアウトプット資料の仮バージョンとして作り、セッションのための資料はなるべく作らないようにしましょう。
これは「要件定義だから」というお話ではありませんが、有限の作業時間において最終的に捨てる資料を作るのは非効率です。
（もちろん、説明のための補足資料などはその限りではありません）。
ちなみに、当然ながら、お客様毎に構成や所有資産、欲しい機能などは異なるので、機能要件定義の方がよりお客様とのコミュニケーションが大切になるような気がします。
３－２．インフラ非機能要件定義
一方のインフラ非機能要件定義については、整理のために便利なツールが既に存在します。
皆さん良くご存じの、**非機能要求グレード2018(IPA)**です。
非機能要件を網羅的に整理できることはもちろんですが、公開されている指標に基づいてスムースに議論できるので、非常に有用性が高い代物です。
個人的には、非機能要件定義のベースはこれが全てと捉えても、事足りるかなとも思っています。
（逆に非機能要求グレードと全く違う軸で要件定義をしている方がいれば、教示いただけると幸いです）。
さて、非機能要求グレードをおさらいすると、大きく6つに分割して定義されています。
- 可用性
- 継続してサービスを提供し続けられるか
- 性能・拡張性
- ピーク時や将来も見越して、パフォーマンスを維持できるか
- 運用・保守性
- 安定・安心してシステムを使い続けられるか
- 移行性
- 安全にローンチできるか
- セキュリティ
- 様々なセキュリティリスクに対応できるか
- 環境・エコロジー
- 環境関連の制約や守るべき条約などがあるか
大項目の中身については本稿では触れませんが、各大項目に更に細分化された小項目が定義されており、様々な要求・要件を網羅的に明確化できます。
ただ、網羅的である一方で、細かすぎる部分や、似通った内容を複数箇所で定義することになっている部分もあります。
そのため、最初から最後まで須らく議論の俎上に載せると、おそらく要件定義フェーズのセッションが全てその議論で埋まってしまいます。
また、お客様の興味の大部分は、「システムを使って何を為すか」と、「そのために、なぜこの非機能レベルなのか」という部分なので、全ての項目を議論の俎上に載せることは、お客様からするとあまり意味がありません。
それにも関わらず、全ての項目に対して全力で議論をしようとすると、お客様に「この人は今回のシステムで重要視すべき点がわかってないのでは？」といった不信感を与えることにもなり得ます。
（多忙なスケジュールの中で調整したにも関わらず、ドキュメントを見れば済むような話を何時間も聞かされるストレスも想像に容易いですよね）。。。
そのような考えの元、私が非機能要求グレードを用いる場合は、
1.大項目レベルでの方針を立てて認識を合わせる
2.ポイントになると考えられる部分と、後々認識齟齬のダメージが大きそうなものを小項目レベルでピックアップして議論する
といった2段構えの対応で要件を明確化するように、心がけています。
大項目レベルの方針は小項目の調整・相談などの際にも立ち戻れる軸となるように、以後ぶれないような形で定義・合意します。
また、小項目のうち、お客様にとってポイントとなるような部分については、方針の中にも文言を含めることが多いです。
一方、小項目レベルにおいては、お客様にとってポイントとなるようなものに加え、例えば性能面など後工程で調整・相談が入る可能性があるといった申し送り事項含め、合意することが大切です。
後は、「SLAなのかSLOなのか」といった、曖昧にしていると、後で双方が不幸になるような部分についてもしっかり合意します。
なお、議論の場で取り扱わなかった部分も、原則としてドキュメントベースでお客様とレベル感とその理由を共通認識化することは並行で行います。
ドキュメントでのやり取りの中で、些末な部分含め、認識齟齬を抑制することが目的です。
ただし、例外もあります。
お客様の工数も有限なので、「ドキュメントベースでも確認不要」ということがお客様と合意できる項目は、そちらは割愛してしまってもかまわないと考えています。
（経験上、「環境・エコロジー」の大項目は、よくその対象になる気がします）。
お客様のインフラチームの方々は、全社のシステムを横断で見ていることがままあり、現行システムの運用保守対応や他案件の対応などで多忙なこともあります。
お互いの合意の元、正しく濃淡をつけて推進するように心がけます。
４．インフラ要件定義（後半線）
インフラ要件定義の前半戦で、要件はほぼ固まっているので、後半戦ではお買い物リストや見積をまとめます。
今回は、オンプレミス環境の場合と、パブリッククラウドの場合で分けて記載したいと思います。
なお、ソフトウェアについては、どちらの場合も大きく差異はなく、お買い物リスト（ソフトウェア一覧）をまとめ、ライセンスやサポート料金などの見積を取得する形となります。
これらは比較的納期も短いので、調達含め大きな問題になることはないのですが、ライセンス体系や必要数については注意する必要があります。
ソフトウェアによっては、オンプレミスの物理マシンと、仮想マシンやパブリッククラウドでライセンスの必要数が変わってくるものがあります。
また、クライアント側のライセンスについても、手配を忘れないように注意が必要です。
加えて、既にお客様が持っているもので事足りる可能性もあるので、今一度ライセンス体系とお客様が本当に所有していないのかを確認します。
４－１．オンプレミス環境の場合
オンプレミス環境でのシステム構築の場合、作成した構成案からお買い物リスト（ハードウェア一覧）をまとめ、見積を取得します。
なお、在庫状況によっては納期が数か月かかることもあるので、余裕を持って見積を取り、そして発注することが必要です。
（詳細設計・構築の棲み分けの考え方や案件規模にもよりますが）、個人的には、基本設計フェーズの早めのタイミングで発注プロセスが回せていないと、構築スケジュールへの影響が心配になります。
また、その納期の都合もあり、予定稼働期間（※5年or7年が多いです）の間、要件を満たせるハードウェアを発注する必要があります。
ゆえに、多くの場合は、現在のビジネス規模に対しては過剰なリソースを持つハードウェアや、十二分にリスクに備えたハードウェアを購入します。
その特性上、あまりにリッチな要件をベースにしてしまうと、予算をオーバーするだけでなく、基盤更改時にもリソースが過剰に余っていたという残念なことにもなり得るので、要件の妥当性について、よりしっかりとチェックする必要があると思います。
その妥当性を考えるときに立ち返るのも、 「システムを使って何を為すか」です。
- 企業の基幹業務を担うシステムだから、可用性の面では妥協できないが、業務のピーク性があるわけでもないので性能・拡張性は、目をつぶれる。
- 業務側で運用回避できるから、可用性の面は妥協できるが、セキュアな情報を扱っているからセキュリティ面は妥協できない。
などなど、お客様毎、そしてシステム毎に、本当に重要な部分は違うはずです。
そのあたりを汲み取り、お客様にとってコスト面も含めた最適・最良の構成で合意し、見積を取得するようにします。
余談にはなりますが、業務系と直接関係ないメンテナンス用などのネットワーク回線の引き込みに関しての見積・調達プロセスは、忘れがちな気がするので注意しましょう。
（実際はそんなにかからないことが多いですが）、納期として2か月程度見込んでおく必要があり、手配が漏れると、構築期間中ずっとデータセンタに行って作業することになります。
ハードウェアレイヤの作業は当然現地作業が必要ですが、例えばミドルウェアやソフトウェアの設定作業などは、必ずしも現地でやる必要はないはずです。
にもかかわらず、わざわざデータセンタに出向いて作業するとなると、移動時間の工数などもバカになりません。
４－２．パブリッククラウド環境の場合
一方、パブリッククラウド環境の場合は、クラウドベンダーの見積ツールが公開されているので、作成した構成案を元にそちらで見積を行います。
○AWSの場合・・・AWS Pricing Calculator
○Azureの場合・・・料金計算ツール
○GCPの場合・・・Google Cloud Pricing Calculator
予約インスタンスを使うのか、従量課金インスタンスを使うのかといった部分や、各インスタンスの稼働時間をどれくらいと想定するか等、インフラ要件定義前半戦で議論が漏れていたものがあれば、お客様と追加で認識合わせをします。
なお、パブリッククラウド環境においても、要件の妥当性をチェックする必要はあります。
ただ、必要に応じてリソースを追加したり、リスクに備えたサービスを追加したりということが可能なので、予定稼働期間を見越した要件と、初回稼働日時点での要件を分けて整理し、それぞれの構成案を考えることで、少なくとも初回稼働日時点でToo Muchな基盤となることは抑止できるはずです。
５．さいごに
「インフラ要件定義」をテーマに、その中で行う作業や、個人的に意識していることや考えていることを、つらつらと書きました。
要件定義は、お客様のために何が最良なのかを考え抜き、そしてお客様と共に現実のものにしていく最初の数歩のフェーズです。
フワフワしたものを形にしていくフェーズなので難しい部分もありますが、「システムを使って何を為すか」 を念頭に置きながら、関係者と活発にコミュニケーションをとり、プロジェクト全体で納得できる要件定義ができるように頑張りたいものです。