メッセージ。 - UMLじゃないものを使うという選択肢

ちょっといまさら感がありますけど、デブサミ2006に参加したとき感じたことを、1つアウトプットしてみます。
岩切さんの日記で、セッション資料ダウンロードベスト3というのが発表されてるんですけど、この中の「天使のSEと呼ばれる知恵〜現場ユーザーにも分かる業務フローはこれだ！」サントリー株式会社　片山隆というセッションに参加して、案外面白いと感じました。

片山さんというのはもともとシステム屋さん上がりの人で、サントリーへ転職して入った人なんですね。それでまぁバリバリ仕事をされているうちに実力を認められて、あるとき子会社立ち上げに際してその業務フローを定義するよう指示されたとのこと。そこで、普通ならUMLを使うのだけど、そうしないで独自フォーマットでワークフローを作ったというお話をされていました。

普通は「えー？ 独自？ まじですか？」と思うのだけど、なかなかこの人のお話に説得力があってね。「業務フローは、会社役員や現場の人が理解できたほうがいいと思った」とおっしゃっていました。上記URLにPDFがあって、その20ページ目に書かれてますけど、そういう業務フロー図を作るほうが、
- 開発者は業務理解に役立てられる
- ユーザーは自分の業務が全体の中でどういう役割なのかを理解できる（業務改善に使える）
- ユーザーは異動があったときスムーズに引き継ぎできる
- 開発者は、開発から保守フェーズへの引き継ぎをスムーズに行える
ということでした。

図の作成も、独自のソフトウェアを使うんじゃなくてパワーポイントを使って書く、とかね。こういうのって、結構大事じゃないかなぁと思うんですよね。「システムはナマモノ」と考えて、いろんな人が、いろんなきっかけで改善できるようにしておくというのは。一部の人がシステムを作って、そこに人員を歯車のように割り当てる。それじゃあ硬直しますよね。

要件が変わりにくいシステムを作る場合や、詳細仕様レベルならUMLもいいでしょうけど、場合によっては、積極的にUML以外を使う手もあるだろうなぁと。言うなれば（社内）バザール型の業務フロー定義かもしれない。あらためて振り返ってみると、要件定義のときにUMLは使えないですよね。現場の人間に確認してもらえないんだから。コーディングするときでも、全体を俯瞰するのは役に立ちますし、片山さんの提案されている方法って、結構いいんじゃないでしょうか。