ご紹介にあずかりました、高安でございます。 本日はご来場いただきまして、ありがとうございます。アーキテクチャと要件定義の隙 間というテーマでお話をさせていただきます。 アーキテクチャと要件定義の隙間と題していますが、アーキテクチャについては非機能 要件の実現としてとらえ、要件定義工程での話をさせていただければと思います。 ただ、非機能要件については要件単体で語ることができないと常日頃考えております。 なぜかと申しますと非機能要件は実現手段の予算が大きく異なる分野と言えるからで す。詳しい話はアーキテクチャ分析のところでご説明するとして、予算上限がある場合、 通常はあると思いますが、その場合に非機能要件をビジネスの要件だけで語るのは厳 しいという意味で要件定義でもアーキテクチャを意識する必要があります。 前置きはこのくらいにして、中身にはいりたいと思います。 1

まず、アジェンダです。 今日お話する内容を書かせていただいております。要件を二つの観点でとらえ、システ ム分析（機能要件の観点）とアーキテクチャ分析（非機能要件の観点）に分かれてお話 させていただく予定です。 2

自己紹介ですが、SIerとコンサルファームを行き来して、20年くらいが立ってしまいまし た。インフラからソフトウェアに渡るまで、アーキテクチャ設計や技術管理などをおこ なってきました。 3

昨年、本をだしました。設計に関する本ですのでご興味ある方はお手にとっていただけ ればと思います。すいません、宣伝でした。 4

5

さて、はじめにということでいくつかお話させていただきます。まず、今日の話の対象に ついてですが、現行システムがある状態で、課題やリプレースが必要な状況において、 要件定義をおこなうシチュエーションです。よくある話として、現行と同じだから違いだ けをヒアリングしてみたいな状況があるのではないでしょうか。現行の要件（状態）が実 は死角になり、あとでトラブルを引き起こすことが結構あると考えています。 要件定義においては、ここで書いた下の図のように、要求開発、現状分析が2本柱とし てあると考えています。その他には、それらを取りまとめて、実際の要件であったり、開 発計画だったりを取りまとめることを表しています。（ステークホルダーでの同意などそ れはそれで難しいわけですが） 単純にインフラリプレースに伴う単純な移行であれば、あまり問題はないと思いますが、 新システムとなると「変化に対する抵抗」という人間として避けられない感情・考えにつ いて対応する必要があります。このような抵抗、抵抗というと言葉が悪いかもしれませ んが、に対応するために最初からステークホルダーを巻き込んで新しいものを作ってい く必要があります。このような手法は極めて重要ですが、今回の内容の対象外です。 6

要件定義の難しさは、枠組みの決まっている内容を元に思考することではないところに あります。設計はテーマに基づいて、技術的背景、制約に基づいて最適な選択を行い ますが、要件定義はそのテーマを決めるところにあるため、対象とする業務や組織が 背景としている方針や思考に基づいて、テーマを決定する必要があります。 もし、コツがあるとすると以下の4つになるのではないかと私は考えています。 常に価値を意識する これは、価値基準あるいは価値観を明確にして判断する必要 があるということです。民間企業においては、お金が儲かるというのは大きな価値基準 ですが、別の価値基準があるかもしれません。例えば、管理部門であれば、ガバナン スによる統制ができることが価値かもしれません。さらに、公共機関においては、それ ぞれの組織によって異なるでしょう。要件はこのような価値に基づいて判断されるので、 重要だといえます。実は明示化されていないだけで、暗黙のうちにやっているのではな いでしょうか。 2つめが仮説検証型の思考に基づく必要があります。すべてをヒアリングで聞くことは できません。ですので、標準的な方法（過去の経験や伝聞、書籍等のノウハウなどをも とにしたもの）に対して、差分だけを確認していくという方法を取ります。 3つ目がモデルの利用です。これは概念モデルではなく、リファレンスモデルとしての モデルです。要件を整理する場合、MECE（もれなく、だぶりなく）を意識して、網羅的に 整理する場合に既存の枠組みは有効です。今回の分析もEAに基づいて、方法を組み 立てています。次のページで簡単にリファレンスモデルの例をご説明します。 4つ目が、理想と現実のバランスをとるということです。可能であれば、理想的な要件 としたいのですが、現実的な制約などを意識して考える必要があります。非機能要件 は現状のデータに基づいて判断した方が現実的な内容が得られます。 7

ここにいらっしゃる皆様におかれましては、いやそれは違うと思われる方もいらっしゃる と思いますが、私はこの4つが重要だと考えており、そのため現行分析が有効だと考え ています。 7

先ほど、お話したリファレンスモデルをいくつか紹介したいと思います。 一つ目がエンタ-プライズアーキテクチャです。聞いたことはあるけど、要件定義と何の 関係が？とお思いだと思います。本質的には要件定義よりもさらに前の段階で利用さ れるのであまり関係はないのですが、次のページで説明する分割視点は応用が効きま す。 2つ目がDMBok（Data Management Body of Knowledge）です。これは組織におけるデー タの取扱い、ガバナンスなどを取り扱う上での基礎知識を表すものです。データ分析を する際に参考になります。 3つ目がTOGAF（The Open Group Architecture Framework）におけるADM (Architecture Development Method)です。本来は複数のシステムにおける全体アーキテクチャを定 義し、システム化計画をおこなうためのフレームワークですが、移行や実装ガバナンス のフェーズ等があり、参考になります。 8

システム分析の際にEAの分解に基づいて、分析をおこなうので、EAに簡単に触れてお きます。 日本ではあまり利用されていないので、政府が定義したEAの資料から引用しました。 最初のレイヤーが方針・業務のレイヤー、2つの目のレイヤーがデータのレイヤー、3つ 目がアプリケーションのレイヤー、4つ目はアーキテクチャのレイヤーでもありますが、 ここでは技術のレイヤーとして表現されています。 この4つの分野に基づいて、分解して分析をおこなっていました。 この4つの視点のうち、上位の3つの視点において現行システムを分析する方法と意味 について説明していきます。 9

10

まず、最初は業務関する視点です。この視点では悩ましい点が1点あります。それは作業を行 う上での分析範囲です。対象業務だけを対象としたいのはやまやまなのですが、対象業務だけ おこなうと十分ではありません。全体としてどう位置づけになるのか、その対象業務がどう変わ ることで全体に対してどういう影響、いい意味でも悪い意味でも与えるのかを判断する必要が あるためです。そのため、ある程度広い範囲で業務を確認する必要があります。少なくともその 業務がなぜ価値を生みだせるのかを考えた場合にその価値となりうるフロー全体を確認する 必要があります。細かく踏み込むのは対象業務だけで問題ありません。また、いろいろな資料 や情報をもらうことになりますが、それだったらと顧客の期待値が高まりすぎてしまわないよう に、いわゆる期待値コントロールが重要となります。 業務の分析の段取りとしては、 まずゴールの確認をします。全体システム化計画、政府に関する機関などですと「システム化 最適化計画」等がありますので、その内容で目指すべき方向性及び大きなレベルでの課題を 確認します。もしなかったらそれに類するものを作るか、ヒアリングをします。話としては大きな 話になってしまいますが、重要なポイントです。このことで、先ほどお話した価値基準あるいは 価値観に関する共有をおこなうことになります。 次にその組織全体の業務の体系を確認します。大きく分けて何をしているのかを確認すること になります。対象業務がその体系のどこに位置づけになるかを確認し、その所属している体系 全体を俯瞰します。（販売管理であれば、その体系のみを対象として、補助業務である人事管 理はその俯瞰から外すことができます。当たり前のことかもしれませんが） その次に、その対象業務の業務フローを確認し、ステークホルダーの確認、対象組織の位置 づけを明確にし、オペレーションの観点、管理の観点、経営の観点でどのようなことが行われて いるかを確認します。 最後に今までの分析した情報を元に、業務移行をどのようにおこなうかをあたりをつけます。例 11

えば、パイロットプロジェクトとして一部だけ移行する、地域単位で移行する、サブシステ ム単位で移行するなどを考える必要があります。これは、要件定義に続く開発計画に影 響を与えていくため重要な作業です。 このように現行分析の結果、業務の位置づけ、業務の重要性、業務の特殊性（簡単に 置き換えができるかどうか）、対象システムの規模等により、移行の方法・方式にあたり をつけるとともに、移行に必要なシステム機能があれば、その観点も忘れずに機能要件 にできるようにします。 11

次がデータの視点です。この視点は極めて大事です。実はここの観点に着目するべきだと私は考えています。 本当は業務が一番大事なのですがその観点では皆様の認識は同様で、実践されていると思うので、次はデータの観点に着目すべきだと思います。 最初に、業務の観点から確認するのが先ほど分析をすると話した業務フローをもう一度、データの流れの観点で確認していきます。精密に実施する ことは難しいと思いますので、全体を俯瞰しながら業務上重要なデータを何かを考え、概念モデルを描きながら業務視点でいつデータが作られてい るのかを確認します。 One Fact in One Place、一つの事実は一箇所で入力されるべきという格言がありますが、その観点にもとづいて同じデータが複数箇所で作成されて いないか、その整合性に苦慮していないかを確認するとよいでしょう。特に対象業務でない外の業務、時には組織の外から取得する場合もあるで しょう。住所データ、郵便番号データなどはその代表例かもしれません。 次に現行データの分析をおこなうのですが、詳細は次のページでご説明します。 データに関する分析の最後は、データ辞書を確認することです。重要なデータは現実、データに基づく（設計書ではなくデータそのものに当たる）とい うのが重要ですが、重要でないデータについても、データ辞書を確認し、データ項目やコードの内容について確認します。データ辞書はほとんどのお 客様において存在していないと思いますが、重要な情報となりますので、いっそうのこと作成して、時間のある限り根堀り葉堀り聞いてしまうのも重要 だと思います。あるお客様においては、私はこの分析をおこなって、お客様よりもデータに詳しくなったケースもあります。 発表資料の関係でこれらをシーケンシャルに書いてありますが、実際はこれをインクリメンタルに実施して、概念モデルを網羅的に実施します。デー タ辞書を作る場合は、すべてのデータになる可能性もあります。 このデータ分析は、DMBOKにおけるリファレンスデータ管理、マスタデータ管理等を参考にして手順化し、いくつかのプロジェクトで試してみましたが、 要件を整理するにあたり回り道ではありますが、データは文書よりもモノを言うというか、システム背景を読み取らせてくれました。 12

なかなかできないことなのですが、現行データをすべてもらって、データの分析をおこないます。 なかなかできないというのは、2つの理由があって、一つは工数の問題です。 要件定義工程は知識を取得するフェーズであるため、アウトプットに比類して工数がかかりま す。その結果、顧客へのアウトプットへの見え方と工数のバランスが悪く、工数がいくらあっても 足りないくらいです。そのため、開始前にきちんとした説明をおこない、工数の重要性などを説 明しないと実施できません。あるいは移行設計では本作業を行うので、それを前倒しすると 思ってもいいかもしれません。 もう一つの観点はセキュリティの問題です。秘密保持契約は当然結ぶわけですが、現行データ は重要な情報を多く含んでいるので提供していただけない、あるいは見せていただけないとい うことも当然あります。個人情報などはマスク等をする手間もありますので難しいのですが、で きうる限りもらえるように交渉していただき、可能であればDBのダンプをもらい、データ分析者 のみが利用するDBに格納し、SQLを利用していろいろな観点で分析をおこなうことをおすすめし ます。 本作業を実施できるとなったら、まずリバースすることによるエンティティの確認と業務分析や 業務視点のデータ分析によって作成した概念モデルのデータがどのように格納されているかま た、そのデータ量が同程度あるかを確認することです。全般的な把握となぜこのエンティティが あるかわからない点などを整理して、分析の課題とします。 次に具体的なデータを元にデータの分類をおこないます。この分類とは、商品の種別を表す コード等を特定し、コードがどのような意味をもつかを整理します。実はここが地道な作業です。 この作業の目的は3つあります。 ・一番目の目的は、データの分類がロジックと影響をあたえるかどうかを判断するための一覧 を作成することです。商品のカテゴリコードがロジックに影響することは少ないでしょうが、メー カ直送品、自社配送などの配送分類などはロジックに影響が与える可能性があります。この例 では、ヒアリングで聞ける可能性は高いですが、ガバナンスや管理会計上のロジック等はヒアリ ングで聞き漏らしてしまい、設計工程以降に判明してしまい、本質的な解決が計れなくなってし まう可能性があります。そのため、この分類が整理できていることが望ましいです。この観点で は、ドメイン値の統制がされていれば資料から読み取ることができるかもしれません。 ・次に移行における難易度や工数を評価することができます。ドメイン値やコード体系がきちん と運用されていれば、マッピングするだけで対応できるのでデータ移行の難易度は高くありませ んが、その運用が統制されていないと、残念なことに一般的には統制されていません。そのた め、データのクレジングが必要な場合がほとんどです。コードの運用は重要ですが、いつの間 13

にか一つのコードが複数の意味になってしまったり、コード表等にない分類コードが生ま れてしまったりします。 ・この地道な作業の目的の最後は、このデータを元にテストデータを作ることで現実的 な十分なテストを行うことを検討できることです。すべてのオリジナルデータを使うのは セキュリティ上難しい点もありますが、商品データ等公開されていてかつテストデータの 種別が多いものについては本データを移行ツールを作って、テスト用のDBに変換してし まいテストすると網羅性の高いテストをすることが可能になります。意外にテストデータ の網羅的作成は難しいのと手間がかかるのでここで検討してしまうと良い結果が生ま れると思います。 13

次にアプリケーションの観点をお話します。システムは複数のアプリケーションから構成されま す。そのため、現行のアプリケーションがどのような構成になっているか、アプリケーション間の 関係を洗い出し、時にはジョブスケジューラの設定やアプリケーションソースコードの解析等を おこない、関係を確認します。 また、アプリケーション開発者の方であれば、よくわかると思いますが、アプリケーションの構造 を整理します。これによって必要な場合はソースコードのどこを見ればよいかを確認することが できます。 これらの情報を元に、データ分析でわかった主要データのライフサイクルをソースコードや設計 書から整理し、入出力情報やアプリケーションでの位置を確認しておきます。その内容を元に 更に踏み込んでデータ分類に基づく、ロジックを分析します。そして、新システムでは処理方針 が同様とは限りませんが、現行システムで作成されるデータの鮮度などもわかるためデータの 処理方針を確認していきます。 これはバッチアプリケーションで作成されているか、オンラインアプリケーションで作成されてい るかで確認できます、また、全体の課題が意外にソースコードに埋め込まれている場合もある ため、課題の原因がないかを確認します。特に保守性に課題がある場合は、ソースコードなど に原因がある場合もあります。多くの場合、再起テストなどの問題と思われますが時にはソー スコードにパラメータとなるべきものが埋め込まれて課題となっている場合もありますので確認 したほうが良いでしょう。 ここまでで、業務、データ、アプリケーションの観点での現状システムの分析で得られるものに ついてお話させていただきました。現状分析を網羅的に詳細にしようとすると相当の時間と労 力がかかります。それでも文書から読み取れれば、ある程度時間が短縮でき、記述されていな い暗黙知をヒアリングすることで効率的に行うことができますが残念ながら、文書が更新されて いない無いということも割りと当たり前に起こってしまうため、時にはソースコードや生データそ のものにあたる必要があります。その時にはすべてをおこなうとすると膨大な時間がかかって しまうので、全体像を明確にした後で、必要な部分とそうでない部分を判断し、必要でない部分 は、入出力などのインタフェースのみを明確にした上で大きなブラックボックスとして取り扱うこ とで効率化を測り、要件定義の期間内で必要な情報を取りまとめていきます。 このような分析結果と新システムに対する業務・機能に対する要件を併せて、機能要件を取り まとめます。（この現状分析結果は、要件として取り込まれるだけでなく、設計工程における移 行設計のインプットとなります） 14

次にアーキテクチャについてお話したいと思います。先ほどお話した通り、要件定義と してアーキテクチャを捉えるのは非機能要件が実現方式と密接に絡むからです、例え ば、可用性という観点で、24時間365日まったく止まらないシステムを構築するとします。 少し前までは電源やデータセンターをまたがり、すべて二重化、三重化をおこなう必要 があるため、億単位でのインフラ投資が必要でした。今でこそ、クラウドをうまく利用す ることでそれほどかからなくなりましたが、他の要件、例えば、セキュリティに関して厳し い要件があり、クラウドを利用できないとなると少し前のコスト水準に戻ってしまいます。 このように非機能要件は実現手段であるアーキテクチャを踏まえて、要件を見据える 必要があるという意味で要件単体で語ることができないのです。 そのため、非機能要件を決定する際には技術をよく理解しているアーキテクトが参画し ていると良い結果が得られると思います、 15

さて、1枚目のスライドはご覧になられたこともあると思いますが、Software Intensive System のためのアーキテクチャ記述標準 – IEEE Std. 1471-2000に提示されている図で す。この図はアーキテクチャの複雑性とアーキテクチャを表現が多様に渡ることを表し ています。 ですので、アーキテクチャについて検討する場合は、きちんと定義しないと話が噛み合 わなくなります。本日の視点はシステムアーキテクチャ（特にインフラに視点をあててお 話したいと思います。これは非機能要件を多くはインフラ等の基盤によって実現する場 合が多いからです。性能や保守性等、アプリケーションアーキテクチャに依存する部分 もありますが、その部分は軽く触れるだけに留めさせていただきます。 16

システムアーキテクチャとして捉えるべき観点は本図で表すネットワーク、ストレージ、サーバ、ソフトウェ アの4つです。 ネットワークはシステム内はもちろん、システム間のデータのやり取り等に影響を与えます。そのため、こ れも現状分析としては、ネットワークの全体像を把握し、ネットワーク構成図を確認または作成します。新 システムをどのネットワークに繋げそうか、その結果どういうネットワーク構成になるのか、システム移行 はどのようにおこなえそうかのあたりをつけます。この段階で決定してはいけませんし、決定する必要も ありませんが、いくつかのパターンによって新ネットワーク構成ができることを把握します。これらは要件 に対する制約となりえます。 次にストレージの構成や容量、性能値等を確認します。DBMSにとって最大のボトルネックになる可能性 があるのがストレージであるため、現行システムがどのように取り扱っているかを確認するとシステムに 対する考え方がわかります。データ容量についても概要レベルで良いので把握しておくとデータ分析の 論理的な量と併せて、データ量やその成長率の予測を立てる材料となります。また、IOPSのような性能の 指標を確認しておくとよいでしょう。 次にサーバに関する現状分析ですが、サーバの一覧、サーバの構成、構成とも関係しますがサーバの 性能及びOSを把握します。台数が多いとなかなか難しいですが、例えばＶＭwareのCapacityPlannerなど のツールを用いることでサーバ構成（インベントリ情報）、性能情報の取得をおこなうことができるので、 便利です。昨今のシステムはインフラとして仮想化あるいはクラウドに設置することが一般的になってい ますので、一度計測してサイジングするのも良いのではと思います。これらについては弊社でも対応でき ますし、HPさんにもサービスがあります、先ほどのストレージの性能情報であるIOPSについてもサーバ内 部のディスクについては取得することができます。 最後にソフトウェアですが、ソフトウェアには2種類あります。一つはASやDBMSといったミドルウェアとそ れらのミドルウェア上で動作するアプリケーションです。アプリケーションの分析は先程のシステム分析 の中でおこなう話なので割愛しますが、ミドルウェアについては把握しておくとよいでしょう。サーバを縦 軸に、ミドルウェアを横軸にしたマトリクスを作成し、どのサーバにどのミドルウェアが入っているかを確 認できる表を作成しておくとよいでしょう。ミドルウェアについてはバージョンも記すことで、最近話題に なったOpenSSLのセキュリティ脆弱性などの場合にも利用できる資料となります。（現状分析なのでおま けみたいなもので、新システム用に作成すべきですが） 17

このような整理をおこなった上で、背景にある非機能要件を読み取ります。予算や技術上の制 約でできなかったことは読み取れないので、更に非機能要件がある場合もありますが、通常は 現状よりもサービスレベルが落ちることはあまりないので、ある場合でも予算と見合いになるの で現状のラインを知らないと調整ができなくなってしまうので、現状のサービスレベルあるいは 非機能要件を推測します。 まず、可用性はネットワーク機器、ストレージ機器、サーバの冗長化構成（NICなどの部品レベ ル、筐体レベル）、クラスタウェアなどのミドルウェア等からどの範囲の可用性を求めているかを 把握します。アクティブアクティブの構成とアクティブスタンバイの構成では通常、アクティブスタ ンバイの構成は障害検知から切替までに1分から数分のシステム停止を許容しています。この ように構成からサービスレベルを読み取ることができます。 運用の方針については、監視項目の一覧やバックアップの内容（時にはバックアップスクリプト 等を確認し）から推測します。監視の通知先や障害復旧時間の確認等をおこなうことでサービ スレベルや運用上の要件を推測することができます。 セキュリティについては、構成から読み取ることは難しいのですが、セキュリティ機器の導入有 無や運用回線のあり方などがある程度のことはわかります。（これはセキュリティポリシーと データ分析の暗号化対象などからも確認する必要があるでしょう） 最後にオンラインとバッチの処理方針を確認することですが、これはややアプリケーションより なのでシステム分析の守備範囲かもしれませんが、バッチ処理でまとめて行うのをオンライン に非同期処理において後続処理として実現する処理方式などもあり、システムアーキテクチャ における視点としても捉えることができるためここでもとりあげました。 ここでは、特にデータ連携がどのような方針において行われるかを確認し、そのデータのあり 方について評価します。例えば、販売管理システムでピッキングなどの在庫管理や配送依頼等 の連携が日次バッチで行われることを前提としていると、リードタイムは自然と長くなります。 これが課題でなければ連携処理に複雑な処理を行わずETLでも十分であることになります。 外部システム連携は意外に工数のかかる複雑な内容であるため、システム分析ではデータの 観点からここでは処理方針と連携方式について一緒に確認して、連携要件として明確化してお いたほうが、開発の見積もりを見誤らなくて良いと思います。 18

性能は計測してみないとわからないので、現行システムにおいてもインフラ特性を確認 しておきましょう。その場合、ここで列挙した情報を取得しておくとサイジングしやすくな ると思います。それぞれのリソースについて確認上の注意点について説明します。 CPU使用率は単純に高いからNGというわけではないのでロードアベレージ等と併せて 判断する必要があります。 メモリの使用率についてはOSがキャッシュを保つ場合があるので併せて確認する必要 があります。 ストレージはランダム・アクセスとシーケンシャルアクセスの違いによって指標の評価が 異なります。 ネットワークについては、スループット（帯域）とレイテンシーがわかればいいのですが、 レイテンシーはすぐ確認できるので、スループット（帯域）を現行の監視ツールの統計 データなどで確認します。 DBサーバについてはDBMSの性能統計も重要な情報です。OracleであればAWRレポー ト、STASPACKなどがそれにあたります。 実際は新システムのDBアクセスパターンに依存するのであくまでも参考レベルにしか なりませんが、インフラのサイジングとしては同じ傾向のアプリケーションとして考える ことができます。 （先ほどのオンライン、バッチ処理方針が変更になるとそれを考慮したサイジングをお こなう必要がありますが） これらの基本情報で、性能上のポイントや基礎データとしての意味、現行のアクセス頻 度等を確認し、非機能要件とすることができます。 このあたりは現行システムを調べてどうなるのかという話もありますが、何もないところ 19

から議論するよりも現行にアクセス頻度などを配慮して、検討を進めると良いです。 19

現行の調査を整理して、機能要件と同等に整理をするわけですが、非機能要件整理 の過程は予算という別の制約があるため、段階が異なるためあえて、一枚スライドを用 意して説明したいと思います。 現行要件を文書、ソースコード、設定ファイル、具体的な性能調査結果等に基づき、 サービスレベル及び非機能要件としてとりまとめます。更に現行の課題等を解決する ために追加する内容を踏まえ、想定すべきソリューションやシステム構成を整理します。 その結果、概算予算を出すことが可能になるので、インフラとして利用できる予算感と して問題なければそのまま非機能要件を確定し、非機能要求グレードや非機能要件定 義書としてとりまとめ、想定ソリューションを概要設計として取りまとめます。 もし、予算感と合わない場合は、要件の再検討をします。インフラの予算が高くなる傾 向にあるのは、 ・必要以上の冗長性を求められた場合の機器構成・ファシリティ・ネットワーク ・IO性能がボトルネックとなる場合のストレージ構成 ・仮想化を行えない要件によるファシリティコスト ・インターネット回線の速度（帯域保証等） ・WAFなどの特殊なネットワーク機器 （昨今のStrutsの脆弱性でWAFの位置づけも見直されるかもしれませんが） 等がコストに大きく影響します。 本末転倒かもしれませんが予算というのは大きな制約ですので、要件を調整し、最終 的な非機能要件を確定していきます。機能要件は段階として、第1フェーズではここま で、第2フェーズでは何をといった形で段階を踏むことができるので洗いだした内容をい つやるかという調整も可能ですが、非機能要件については段階を踏めない基盤もある ためこのようなアプローチが有効となります。もちろん、拡張性も非機能要件ですので、 段階を踏んだ、アクセス数が多くなったら対応するなどの考え方を持つことができます。 20

クラウドであれば、ある程度段階を踏むことは可能ですが、クラウドが適用できない場合 もあるのでその場合はじっくりと検討する必要があるでしょう。 20

21

蛇足になりますが移行というのは大きな問題です。 現状分析をおこなう一つの理由が移行を適切におこなうためにどのような段取りを踏 むかを要件定義の中で検討し、どういう移行計画が適切かを検討することです。 移行は本スライドで書いてあるように、業務移行、システム移行、データ移行の3つに 分かれてそれぞれが影響しながら進めていきます。 単純に考えるとデータ移行だけなのですが、システムの切替や切戻しも大きなテーマ ですし、システム側の移行がうまく言っても業務が移行できなければ立ち行かなくなり ます。そのため、この3本柱で進めるのです。 個人的には、SIer時代にはあまり移行に深く首を突っ込まないで、結合テストまでをプ ロジェクトで、総合テスト支援の中でデータ移行を検討するといったレベルの経験しか なかったので、この中の皆様におかれてもそういう方もいるだろうと思い、蛇足ながら 最後に移行の話をさせていただきました。 22

最後に今日おつたえしたかったことを3点にまとめました。 一つ目は、現状分析は重要です！ 私は、すべてをヒアリングで聞くことはできないという考えに立っています。ヒアリング で確認できるのは、あくまでも現状分析の不明点と現行の課題で解決したい内容につ いてだけだと考えたほうがよいと思います。 もちろん一緒に巻き込んで新システムについて考えていくことも可能ですが、顧客と同 じ土俵に並ぶためには現状分析をしてからの方が適切だと考えています。 2つ目には非機能要件を考える場合は、予算は大きな制約であるということです、実現 手段を考えるのは設計段階であることは間違えありませんが、予算感を把握するため にも逆算しながら要件を調整すると良いと考えています。 3つ目はあまり話としてはでてきませんでしたが、現状分析は必要だとといっても目的 は現状を把握するための知識獲得の手段であって、目的ではありません。新システム がどうあるべきかは今回説明させていただいた内容の延長線上にあります。何を変え るべきなのか見極めが重要です。これこそが要件定義を行うエンジニア、コンサルの腕 の見せどころです。お互いに精進しましょう。 以上で、私のセッションを終わらせていただきます。ご清聴ありがとうございます。 23