なぜITエンジニアは業務設計が苦手なのか？

いろいろなプロジェクトで感じていることの中に、いわゆるIT系のエンジニア、およびコンサルタンとは業務要件定義と設計が苦手なようです。設計書をまとめていくという作業自体に関しては知識もありますし、フレームワーク等下敷きになるものも持っているためか、抵抗感はないようです。しかし、要件定義作業そして設計内容に関してはかなり苦手意識が強い人が多く、また人によっては品質もまちまちです。

思いついたことをつらつらと書きますので乱文ですが、感じていることをざっくり書いてみたいと思います。

原因はいくつかあると思いますが、大きな原因の一つに、「デジタルな設計思考による論理の落とし穴」があります。よく間違える「Aは親切である」、「Aはアメリカ人である」、従って「アメリカ人は親切である」という例で考えてみると、「A＝アメリカ人であるため、A＝親切と規定するのであれば、すべてのアメリカ人に親切という属性を持たせること」ということで、例の論理は成立します。この隠れた処理論理を前提として明記しないまま、業務の仕様やルールを規定してしまうことで、現実には発生する”それ以外”という状態を規定することを怠ってしまうことが多いようです。

システム設計で考える、様々な条件、属性の持たせ方には、人的作業と別に規定しているシステム処理上の規則があります。それは善でも悪でもなく、システム処理として必要であるから定義を行っていることです。しかし、システムが提供する画面から向こう側はシステムの論理では動きません。従って、処理にはすべて例外が付きまといますし、マニュアルに規定したとしても、エラーや実情に合わせて異なる処理ルールで物事を進めてしまいます。

従って、システム的な発想そのものではなく、そこでおいている前提をすべて取り払って発生する事象に関して、処理ルールを規定しなくてはいけませんが、これが結構難しい作業のようです。システムという、一定ルールの中で動くものと、ルールはガイドラインであり、実際には逸脱行為やエラーが発生することを前提とする人的業務。その差を埋めるためには、この壁を乗り越える必要があるようです。

様々なところで発生しているマニュアルの弊害、つまり対応の不備なども、実は同じ「すべてはルールの中で動く」という前提のもとでマニュアルを作成し、その遵守を求めることで発生していると思います。