技術者の育成関係の仕事をしていると、「上流工程で、業務要件にそってうまく情報システムの機能を設計できないんだよね」と相談されることがある。
コンパクトに、私なりの情報システムの基本設計相当の上流設計プロセスを言語化してみたい。

まず、「情報システムの設計できた」という状態（ゴール）を設定することが重要だろう。
私の考えでは、次の２点が満たされていることである。
① 情報システム投資にかかわる目的が業務プロセス上、システム機能上、達成されている（もしくは達成できそう）
② 必要なシステムの機能が洗い出され定義されている（漏れがほとんどないという意味）

①②を達成するためには、まず「情報システムとは何か」という理解が必要である。
私の思考のベースには「情報システムとは『情報』の『システム』」がある。つまり、業務に沿って情報が効率的かつ正確に伝達されることで、業務プロセスの効率や効率性以外の達成目標（業務プロセスのアウトプット）に対して有効性を向上させることができるということである。言い換えると、デジタルな情報の流れを情報システムで効率化することで、投資目的となるKGIを具体的なKPIに分解したときに、KPIの向上が期待できるということである。

ここでは、基幹システムにおける取引系情報システムを対象とするが、本思考においては、情報システムで扱う「情報」に注目することが重要となる。

主として②の達成が中心となるが、
１．情報システムで扱う「情報（モノとコト）」を洗い出し、構造化することである（例えばER図やオブジェクト図にて。細かなデータモデリング技術は省略）。
２．「情報」が構造化されると、それぞれの「情報」の生成から消滅までの状態の遷移を定義していく。
３．「情報」の状態遷移を定義できると、「情報」遷移に対し、誰がどのような情報の操作を行うのかを「業務プロセスのパターン」として整理することができる。
４．さらに、それぞれのパターンで間違った情報が入る可能性がわかるとエラーに対する対応も機能や入力ルールが整理できる

以上のパターン網羅性や業務上の情報アクセスの欠落を確認できると、②の情報システムの機能要件がほぼ洗い出された状態となる（この時点ではASIS機能の整理に近い）。

さらに、①に示す目的やKPIを高めるために、業務プロセスや、その時の情報のアクセスに変更を加えていくこととなる。情報のアクセスの変更により、先ほどの、２，３，４の情報の一貫性が保てるかを確認できれば、ほぼ情報システムの機能設計は完了する。

最初の情報の洗い出しに、業態のドメイン知識や、情報システムのタイプに対するセオリーを知っておく必要があるが、こうして整理してみると、それほど特殊な作業ではない（実は例外的な業務パターンをどこまで整理できるかがポイントだったりする ー もちろん例外は実装しないという選択もある）。

なお、KPIの設計とかは、私の著書を確認いただきたい（残念ながら2013年出版なので廃盤、中古のみとなるが）

参考文献
向正道(2013)「ITマネジメントの新機軸」日経BP社.