アーキテクチャと要件定義の隙間（PDF版）

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

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

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

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

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

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

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

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

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

11. 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26. 21

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

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

アーキテクチャと要件定義の隙間（PDF版）

Atsushi Takayasu

アーキテクチャと要件定義の隙間（PDF版）