ロジックの強い・弱いはどこから来る？

仕事をしていると「それはロジック的に弱い」と言われることがある。ではどうやったら強いロジックを組み立てられるのか、はあまり示されることはない。

「自分で考えろ」ということだと思うので、少し書いてみたい。

事務の世界におけるロジック強度を支えるのは全体の整合性だ。以下に、整合性を支える各要素を書き出してみたい。

パターン網羅は十分か

ABCの3つの工程で成り立っている仕事があったとする。Aだけを見たら正しいと思われるロジックでも、BやCと組み合わせるとおかしくなることはよくある。

例えば、Aには3種類のステータス、Bには2種類のステータス、Cには4種類のステータスがあるとすると、3×2×4=24種類のパターンを考えて本当にこのロジックで正しいか、を評価しなくてはいけない。

ところが、Aの3種類のステータスだけを対象としてロジックを組み立ててしまうと、全体を見渡している人はすぐに違和感を覚えるのだ。

締め切りが迫っているからと、成果を焦って反射神経で喋ってしまうと、反論やツッコミを受けた途端にしどろもどろになってしまう。後輩にはあまり見せたくない姿だ。

人員配置や時系列は整合的か

組み立てた結果、B工程の人間だけやたらと締め切りがタイトになってしまうと、ミスが発生しやすくなり事務が破綻する。

締め切りが厳しいということは、その時間帯に厚めに人員配置をしなくてはならなくなるので、必要な最大人員数が増大する。

人員予算の獲得に向けたロジックもあわせて整備できていないと、そこから穴が空いて全体が崩壊する。

イメージアップの事例は突き詰められているか

どんなに正しいロジックでも、相手に伝わらなければ意味がない。伝わる表現選びも仕事のスキルだ。特に現場サイドの人に一瞬でイメージできる事例は持っておかないといけない。

立場が違うからといって伝えることを妥協しめいたら、"弱い合意"のまま突き進むことになり、締め切り間際におおごとになる。

「この施策を採用したら、どんなデメリットがあるの？」

ダメな例:「①と②と③の条件を満たしたものが救えなくなります」
・・・条件を羅列しているだけで、「具体的にどんな事例か」という質問の意図に答えていない。

良い例:「〇〇のような事例は全滅します」

エンジニアの人たちは1つ目の「①と②と③の条件を満たしたものが救えなくなります」という言い回しを多用する。なぜなら、彼らはプログラムで条件分岐を作成するのが仕事だからだ。

その言い回しをそのまま使うのではなく、具体的な事例に置き換えるのが、プロジェクトを円滑に進めるシステム企画者としての役割である。