乱暴ないい方ですが、経営者に標準図法を理解できるように訓練することが必要です。これは筆者の狭い経験からにすぎませんが、経営者はそれを理解できないほど無能ではありません。
標準図法で書くことは困難ですが、読んで理解することは難しいことではありません。経営者が分かりにくいというのは、これまでの表記法(仮に個条書きとしましょう)に慣れているので違和感を持っているだけなのです。違和感は繰り返すことにより低減できます。しかも、多くの標準図法は慣れれば分かりやすいものです。
当初は、標準図法と個条書きの両方を提出し、標準図法を見せながら個条書きの説明をします。次第に個条書きを減らして注釈だけにします。そして、その注釈を標準図表に書き込むだけでよいようにしてしまえば、半ば成功です。
標準図法がとっつきにくいのは、記号が多いからです。例えばクラス図での汎化記号の場所に「まとめると」、コンポジション記号には「自動的に消滅」などのような簡単な書き込みを入れるだけで、かなり理解できるのです。当初は多くの記号に書き込みますが、次第にポピュラーな記号の書き込みを減らしていきます。
筆者の経験では、プロジェクトの当初では標準図法と個条書きを併用しましたが、そのうち標準図法だけでなんとなく分かった気分になり、プロジェクトの終わりごろには、あまり書き込みをしなくてもよいようになりました(どこまで正確に理解したかは疑問ですが)。
この作業には、周囲の協力が必要です。ベンダには、こちらと歩調を合わせて個条書きや書き込みをしてもらうことを依頼します。当初から書き込みなしの標準図法だけで説明されたのでは、経営者は拒否反応を示しますし、いつまでも個条書きを提出されると、そちらばかり読むことになりがちです。
フローチャートの比較分岐や、繰返しなどの表記法がプログラミングを離れて、IT以外でも一般の図法として使われるようになりましたが、標準図法もこのような状態にしたいものです。そうなれば、経営者も自然と理解するようになるでしょう。それには利用部門の協力が必要です。
利用部門では、標準図法に関心を持つ人がいるでしょう。その人に表記法を教えることにより、業務での多様な場面で使ってもらいます。UMLでいえば自分の業務内容をユースケース図、業務の流れをシーケンス図などの表記法を使ってもらうことにより、このような表記法が社内に広まります。
日本版SOX法では多様な文書化が必要です。それを統合管理するには専用ツールを利用するのが適切でしょう。
日本版SOX法では特定の標準図法を指定するものではないし、このツールがシステム開発での標準的な図表を作成するものではありません。しかし、経営者は日本版SOX法に大きな関心を持っているので、文書間の相互関係を明確にしたり、統合的に管理したりするツールの効果を納得するでしょう。
しかも、経営者が自らツールを利用することにより、実際の状況を把握できることを知るので、このような管理方法が有益であることを理解するでしょう。
そうなれば、システム開発や保守に同様なツールがあり、それを活用するためには標準図法に従うことが重要であることを認識してもらうのも容易になるでしょう。
○まとめ
この記事に対するご意見をお寄せください managemail@atmarkit.co.jp
木暮 仁(こぐれ ひとし)
東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査、ISMS審査員補など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」「情報システム部門再入門」(ともに日科技連出版社)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している
Copyright © ITmedia, Inc. All Rights Reserved.