ついついシステムエンジニアが資料作りでやってしまう論理の飛躍とはなにか

システムエンジニアだからついついやってしまう失敗というのがあるんですよ。どこで見つけられるかというと、資料の中でよく見かけます。どういう失敗かというと、資料を順にめくっていると突然、話が飛んでしまう「論理の飛躍」です。これ、不思議と作った本人が気づかないことが多いです。逆に、初見の人は見つけられる。初見の人が見つけられるなら、書いている本人が見つけられてもいいのですけどね。

具体的なイメージがある方が良さそうなのでそれっぽく書くと、とある新業務を担う組織の業務システムを構築するする際に、業務手続きからフローを作成し、システムの仕様を具体化した上でプログラム仕様に展開すると思います。そういったケースです。

・とある業務をシステム化するので仕様を決めていく手続きを合意したい
・組織の規程でその業務を主務とする組織の定義、役割が定義されているのでそれを範囲と定義する
・とある業務の主業務を具体的に業務手続きのフローとして具体化し、人系とシステム系と分別した案を作る
・システム化対象での必要な機能仕様を提示する
・プログラムの仕様を提示する

システムエンジニアが資料を作るとついついやっていしまうのが無意識にシステム開発のドキュメントになってしまうというもの。まだ、体系的であれば多少は、これ、文書の目的と違うぞって、気づく可能性はありますがまぁ、はまりやすいです。システム開発の中は自分のフィールドですからね。無意識に自分のフィールドで戦おうとするわけです。　

・とある業務をシステム化するので仕様を決めていく手続きを合意したい　→　目的

・組織の規程でその業務を主務とする組織の定義、役割が定義されているのでそれを範囲と定義する　→　根拠

・とある業務の主業務を具体的に業務手続きのフローとして具体化し、人系とシステム系と分別した案を作る　→　対象となる界面の提案

・システム化対象での必要な機能仕様を提示する　→　案だが、目的とは違う

・プログラムの仕様を提示する　→　案だが目的から随分離れてしまっている

話がおかしくなるのは４つ目からです。目的は仕様を決めていく「手続きを合意したい」ですから、

・システム化対象での必要な機能仕様を提示する　→　分別したうちのシステム系について、協議する対象は誰それで良いか

・プログラムの仕様を提示する　→　協議対象者とは、システム方式、機能仕様の検討、実現仕様をある時間軸で進める

のような感じに変更すると本来の目的を達成するための文書になる。ちょっと強引な例に見えるかもしれないけれど、実際、見かけるものですよ、現場では。類似の例だと、システム化の方向を検討する資料がいつの間にか製品選定になっているというもよくある。ベンダの提案はそんなのばっかりですけどね。

最後のページやappendixが製品選定ならいいですが、その前に方向性までの資料として成立していないといけない。逆に言えば、方向性を示さなければ、読み手からは論理が飛躍しているようにしか見えないわけです。

よく言えば強引にシナリオを作っているだけなんですけどね、それじゃ誤魔化せないんですよ、頭の良い人は。簡単に見破られちゃう。