先日、営業で伺った会社さんで、「20年くらい前まではSEと言われる人が『業務の可視化』の責任を持っていた。しかし今ではそれはユーザ側の責任だ、と言われてしまう。で、作ってみるとこれではシステム化に十分な情報が盛り込まれていない、となる。昔の仕事の仕方の方が効率的だったのではないか」という趣旨のご指摘を頂きました。
そのお話をお聞きした時に、私がコンサルティングサービスの現場で感じている問題との関係に思い至ったので、今回は趣向を変えて「オープンソース」ではなく「コンサルティング」のお話をさせて頂こうと思います。（因みにその場では、「我々の先輩にあたるコンサルタント諸氏がパッケージシステムの隆盛に乗じてSEと呼ばれる人達からその業務を引きはがした結果」という説を提示すると共に、教科書的な「ユーザ参加の意義」を指摘するという少々煮え切らないお答えをしてしまいました）
我々はコンサルタントとして、時にこの「業務の可視化」の部分のみをお仕事として受けることがあります（実際にはパッケージシステムとのフィット・ギャップ分析の一部として実施されることがほとんどですが、フェーズで区切ればまさに可視化だけを粛々とやることになるわけです）。プロジェクトメンバであるお客様側のご担当の方が文書を書く作業をアドバイザリという立場で支援させて頂くこともありますし、我々が主体となってインタビューから記述まですべてやらせて頂くこともあります。こうした経験の中から1つ言えるのは、確かに「業務の可視化」という作業は人を選ぶ作業に見える、ということです。
#議論が発散しがちな領域なので、以下ではERP導入プロジェクトにおける「プロセスマップ」やSOX法対応における「業務フロー図」のようなフロー図を描く作業を「業務の可視化」と呼ぶことにします。非常に乱暴ですが、ToBeかAsIsか、という違いすら考慮しないこととします。
お客様側にも（残念ならが）我々のようなコンサルタントを生業とする人間にも、品質の高い文書をすぐに描き出すことができる人もいれば、そうでない人もいます。個人差はかなり大きいと感じられます。特にこの種の作業を苦手とする人が陥り勝ちな問題としては、
- 用語が統一できない（同じ文書や部門などの名前が場所によって違っている）
- 粒度が統一できない（あるところでは「箱」1つで表現している作業が、別の場所では2つ以上の「箱」の連なりとして表現されている）
- 語尾などの語法が統一できない（体言止め、などのルールがところどころ破られている）
という表現上のルール違反があり、これらが大部分を占めているとも言えると思います。
もちろん、そもそも何を書いたら良いのかわからない、自分の業務を抽象的に評価することができない、という問題を抱えているように見受けられる人もいます。そういう人は最後まで図を描き上げることが難しいので、お客様が主体となって作業をするタイプのプロジェクトでは別の担当を立てて頂くことになりますし、我々が主体となって作業をするケースではインタビューが紛糾することになります（もちろん、なるべく効率良く情報を収集するためのテクニックも存在しますが、やはりこうした作業に対して相性が良い担当者様の方がインタビューも簡単に済むのは間違いありません）。前者のケースで、引き継ぎ時などに途中まで書いたものを見せて頂くと、ほぼ間違いなく上記の「ルール違反」が含まれている、、、ような気がします。
「業務を抽象的に評価・記述できない人」は表記ルールを遵守できない（ことが多い）、という結論になりますが、これは少し実感に反する結論です。表記ルールが遵守できる人なら、「業務を抽象的に評価・記述できる」のでしょうか？
すぐにYESと回答することはできない問いではないかと思います。単純にイメージの問題としても、「表記ルールの遵守」のために必要なスキルセットよりも「業務の抽象的評価」に要求されるスキルセットの方が高度であるというのが、一般的な認識だと思われます。つまり、より簡単と思われる要求が、より難しいと思われる要求の「十分条件」にあたるという主張になっているわけです。
この違和感の原因を考えると、（少なくともここまでの理屈の上では、）「表記ルールの遵守」というのが実は結構難しい、あるいは、「業務を抽象的に評価・記述できる」というのはそれほど難しくない、のどちらか、もしくはその両方、ということになりそうです。そして、私は「表記ルールの遵守」が意外に難しい、という立場でもう少しこの問題を掘り下げてみたいと考えているわけです。
続きます、珍しく
（文責 Ishii Akinori IT-Coordinator）
最近のコメント