事業会社のエンジニアは要件定義をできない
あるところで、業務改善と言うプロジェクトを担当しているエンジニアがいた。その業務改善と言う名のプロジェクトは、一見小さな小改善プロジェクトに思えるが、実はバックオフィスの業務改善を範囲としていて、側から見るとかなり大変なプロジェクトにしか見えなかった。
現行業務のIT化はアドホックに導入されたシステム群が乱立していて、いわゆるシステム連携は人的リソースに依存していたり、オフィススイートに依存していたため、業務改善プロジェクトに過剰というほどの期待が寄せられていた。
担当しているエンジニアは自らやりたいと手を挙げ、そのプロジェクトに勇ましく望んだが、定常業務も担っており、進捗は若干遅れ気味で加熱していた期待は次第に冷えかかっていた。
マイルストーンを聞くと月末までにToBeの業務モデルを作り、業務部門と合意したいのだと思いもある一方、その合意のミーティングは設定をしていなかった。
エンジニアは締め切り駆動型であるから、若干、力技でミーティングを設定し、それに合わせて作業を進めるように促すと、実際ミーティングは設定された。
あるレビューのあと、件のミーティングでは何をするつもりなのかをヒヤリングをしてみると、ヒヤリングした現行業務からToBeモデルの業務を説明し、その場で新業務としてオーソライズさせるということを考えているのを知り、絶望的にならざるを得なかった。新業務を初見で短時間で飲み込めという算段だったのだ。
さらにその先の数ヶ月先の筋道を説明させると、工程と成果物の繋がらなかったり、必要な物を飛ばしている。イメージ的にはToBeモデルからいきなりシステムデザインをしようとしていた。要件も業務とITの界面も何もない。こんな状態でコンサルでも声がけしたらいいようにされるイメージしか湧かない。
これを知った時点で件のミーティングをキャンセルすることを促し、その方向になった。
自分の見えている全体像から言えば、次の可能性が高い。
- このエンジニアは、業務システムの要件定義をしたことがない
- さらに言えば、RFPを出したこともない
- 工程（アクティビティ）と成果物の定義ができない
- DFDの階層化のような粒度で情報を整理した経験がない
要件定義をしたことがないと判断するのは、工程の設計がデタラメに見えるからである。たかが業務改善だろうが、ToBeモデルを成立させるための要件がなければUATで検証できない。
RFPはその要件を列挙したものだ。機能、非機能、運用、セキュリティなどの目線が必要であるし、制約条件も列挙されていなければならない。
工程と成果物がデタラメなのは手戻りを是としているのではないか。業務担当からすればこれはたまらない。
情報の粒度を意識して整理できなければ、業務改善するときの情報の整理、優先順位づけで迷子になりかねない。
要件定義などのIT企画などのプロジェクトは、事業会社のエンジニアは経験する機会は多そうだが、実際には体系的な知識がなく、経験ベースでやるとこんなことになってしまうのではないだろうか。
何も型にはまったやり方を期待しているのではなく、やらねければならないことを決め、その通りにやればいいのである（結局テーラリングするわけだ）から、好きにやって良いのだが、最低限やらなければならないこともあるし、特に主管の違う業務設計については相当のコミュニケーションの時間を掛け、刷り込みながらやらないと納得感を得ないままアウトプットだけができ、結果、使われないシステムが出来上がってしまいそうである。
