よくシステム導入において、AsIs分析をどのようにするか、どこまで行うか悩ましいと思います。
そこで、今回はAsIs分析をどこまで行い、どのように生かせばよいか、解説していきたいと思います。
今回は、赤俊哉さん著書「だまし絵を描かないための– 要件定義のセオリー」を参考文献としながら、私の考え、経験と共に解説します。
この記事を読んでわかること
システム開発において活かすべきAsIs情報が何かわかるようになる！
それでは解説していきます。
結論
活かすべきAsIs情報は４つ！
〇現行業務の問題点
〇非機能に関する情報
〇データ構造
〇コード体系
１つずつ解説していきたいと思います。
前提
今回はできる限りあらゆるシステム開発に通じる考え方を解説していきたいと思いますが、基本的には、現行システムの刷新プロジェクトを対象としており、ToBeモデルの検討時にどのようにAsIs情報を活かすかという観点で記載しています。
そのため、新システムの開発プロジェクトを想定していただければと思います。
なお、スクラッチ開発案件であっても、パッケージ導入案件であっても、どちらの場合であっても今回紹介する考え方は適用できると思いますので、ぜひ参考にしてみてください。
現行業務の問題点
１つ目は現行業務に関する問題点です。
赤さんの著書では記載されていませんが、これが一番重要だと思います。そもそも論という気はしますが、新システムの導入の多くは現行システムに何かしらの問題があるために行われます。
プロジェクトによっては、現場からの強い要望が理由ではなく、システムの老朽化によってやむを得なく刷新する必要があったという事例もあると思います。しかし、その場合であっても、現行システムですべてが完璧に回っている訳ではないというのが実態です。
そうした場合、現行業務で抱えている何かしらの問題については、新システムの導入によって解決されなければいけません。
もしくは、システムの導入目的が問題解決の主たる目的ではないのであれば、現行の問題は、新システム以降も残るということを明示する必要があります。
そういう意味で、現行抱えている問題というのは必ず顧客からヒアリングすることが重要です。
しかし、注意点があります。それは、現行業務のヒアリングに注視しすぎてはいけないということです。あくまで、問題が何かを理解し、その問題がどうなるかを整理するためにインプットにしか過ぎません。
そのため、現行業務のヒアリングに時間を割きすぎたり、現行業務の整理に力を割くことは本末転倒です。
非機能に関する情報
２つ目は非機能要件です。非機能要件については、現行の情報が存分に利用可能です。
赤さんの著書においても以下のように記されています。
データ更新及び業務処理の頻度、処理速度や応答速度、データ量、そして昨今では最低限求められていたユーザビリティなどについて、現行システムのドキュメントやUIのハードコピー等を参照して洗い出します。
だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
非機能要件を一から定義することは非常に困難です。
特に昨今は、システム部門とシステム開発を進めるだけではなく、事業部門とITベンダが一緒になってシステム開発を進めるケースが増えています。
そうなると、余計に事業部門では、非機能要件について検討することは難しくなります。また、ITベンダが示した非機能要件について、その良し悪しを判断することも非常にハードルが高くなっていきます。
そのため、現行システムがどのように動いているのか、どのような条件が動いているかは、新システムを検討するうえでも非常に有用な情報になることは間違いありません。
データ構造
３つ目はデータモデルです。
データモデルというのは、業務を表す静的なビジネスモデルだと言われます。（対して、業務フローは動的なビジネスモデルと言われます。）
そのため、業務の本質が変わらない限りに、データモデルは大きく変えない方が業務影響は少なく済むと考えるべきです。仮に、業務フローが変わったとしても、データモデルが変わらなければ、企業として蓄積されるデータは変わらないため、根本のところでは業務影響はないと私は思います。（当然、業務フローが変われば、ユーザや利用者への影響はあります。ただし、企業というマクロな視点では影響が小さいと言えます。）
そのため、現行のデータモデルについては最低でも核となる部分については頭に入れておくべきだと思います。
赤さんの著書でも以下のように記載されています。
概念データモデル、データライフサイクルが把握可能であるもの＝CRUDマトリクス等。なければ、ドキュメントを基に、データ構造の概要が把握可能なレベルのラフなAsIs概念データモデルは作成しましょう。
だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
すべてを明らかにすることは、これもまた時間のかけすぎに繋がります。そのため、核となるような領域やエンティティとその関係性に絞って分析するように心がけます。
コード体系
最後は、コード体系です。
赤さんの著書でも一番時間を割くべきと言われいますが、私もコード体系が一番重要だと思います。なぜなら、一番現行業務の”様子”を読み解くことができ、且つ、ToBeモデルへの反映も比較的ハードルが低いからです。
現行システムで「〇〇区分」「△△フラグ」と呼ばれるような意味ありなコードについてはその利用目的や意図を明らかにしておきましょう。受注番号を構成する要素（12桁構成＝8桁（年月日）＋2桁（事業所番号）＋2桁(事業所ごとの連番)など）などもその一例です。
これらの情報から業務の条件判断や、状態、ステータスを表すコードになることが非常に多いです。また、どのようなビジネスロジックを検討しなければいけないかも明らかになります。
それでいて、これらは論理ＤＢ設計、物理ＤＢ設計にも比較的取り込みやすいため、明らかになればなるほど現行システムからスムーズに新システムへ移行、構築することができます。また、データ移行などの移行設計も格段と行いやすくなります。
ここでも、固執しすぎには注意します。
決して現行踏襲のシステムを構築することが目的ではありません。そのため、現行のコード体系に沿って構築しなければいけない訳ではありませんし、現行に倣った結果、一番最初に挙げた現行の問題点について解消されなければそれこそ本末転倒です。したがって、現行分析のしすぎは要注意です。
しかし、こうしたコード体系はデータモデルを検討する際にも非常に役立ち、開発者に様々な情報を与えてくれることは間違いありません。
ぜひ、現行システムでどのようなコード設計をしているのか情報収集してみてください。
最後に、赤さんの著書からも引用し、その重要性を念押ししたいと思います。
現行コード体系のなかには、現行システムのロジックがたくさん詰まっています。特に「意味ありコード」は要注意です。
だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
まとめ
今回は、AsIs情報をどのようにシステム開発に活かすかについて解説してきました。
現行の問題点をしっかりと抑えることから始め、この問題を解決するために新システムの検討を行います。その際に、現行システムの非機能要件やデータモデル、コード体系をインプットにすることで、よりスムーズに検討が進むと思います。
そして、現行システムから新システムへの乗り換えもスムーズになります。
ぜひ、今回の内容をシステム開発に活かしていただければと思います。
最後までご覧いただきありがとうございました。
コメント