マクロとミクロは経済学でよく出てくる用語である。インターネットを調べると量子力学や会計でも使うようである。簡単に言えばマクロが全体でミクロが細部ということになろうか。
経済学にそれほど明るい訳ではないが、こんな例でどうだろうか。現在、マクロ経済では「いざなぎ越え」とか言われているが、ミクロ経済では「実感がない」という町の声が聞かれる。どちらも間違いではないのであるが、絶対的な真ではない、というところが重要であろう。
これは、よくネット、新聞、雑誌、テレビの討論番組なんかでの意見や反論を見ていても「これが絶対的である」という立場の人がいるが、視野が狭いと感じることは往々にしてある。国会中継なんかはその最たるものではないだろうか。いい大人が人の発言を聞かず、妨害するべく野次るという、教育上も最低な行為が行われている。今後は「この議員はこの人のこういう意見に対してこういう野次を飛ばした」という情報を開示してはどうだろうかと思う。
話が大きく逸れてしまった・・。
さて、要件定義の際に、やはり「マクロとミクロ」を考慮する必要があると考えている。
ヒアリングするにしろ「担当者」が窓口になり業務の説明を受けたり、要望を聞いたりすることは多いだろう。この担当者の話はマクロだろうかミクロだろうか？
担当者がそれほど全体の業務の細部にまで理解していないために、自分の知っているところだけは細かく、よく知らないところは情報が少ないというのはよくあることだろう。
仕事上はこの担当者の話をマクロとして考えて進めることが多いが、後々仕様変更などが頻発する羽目になることが多い。つまり、ミクロである可能性が極めて高いのである。
要件を定義するためには、マクロ、ミクロの両方を考慮しなくてはならないが、システム開発の場合、マクロとミクロの整合性を取っていく必要がある。
さて、マクロとミクロの整合性を取って要件定義をするためにはどうすればいいだろうか？
次のような例ではどうだろうか？
まずは、現状を理解しないといけないので現状をヒアリングしてフローを作成する。これは担当者とだけでもいいだろう。
次にそのフローが正しいかを検証する必要がある。これはフロー上の作業の各担当者に聞く必要がある。どこから受け取り、どういう作業をして、どこに渡すか、例外はないか、である。
フローが確定したら、業務効率の悪い点、困っている点など、気づいていることを先ほどの各担当者からヒアリングを行う。コミュニケーション能力の高い方は先ほどの段階で行ってもいいが、２回目以降の方が相手は構えないだろう。時間的な制約や各担当者の都合などで一度で済ますかどうか決めるとよい。
この手順を踏めば業務の流れと問題点が見えてくるので、マクロとミクロの整合性を取れた改善案が作成できるだろう。ただし、場合によっては人員削減などにも関わるので、担当者に制約条件を確認し、それを考慮した案を練る必要がある。その時点で経営層やプロジェクトオーナーなどを交えての会議を開くようにする。
上記でいうなれば、作成したフローがマクロ、各担当者からのヒアリング結果がミクロ、に当たるだろう。
業務系のシステムはこのようにマクロとミクロに注意を払い、その整合性を取っていくと、失敗する確立を減らせるだろう。何もこれは私のオリジナルではなく、一般論に近い。ただ、マクロとミクロに関して明示的に注意するような記述をあまり見かけないのでそういう観点を分かりやすく出してみたつもりである。