昨日の投稿をざっと見返してみると冗長な表現が多く、少し落ち込みました。
さて、ややもすればコンサルティングの価値の源泉の1つとも言えそうな「業務の可視化能力」「抽象的な評価能力・表現力」のようなものが、実はより単純そうに見える「表記ルールの遵守」ができるかどうかに依っているように見える。そして、その見かけ上の矛盾は、実は「表記ルールの遵守」というのが意外に難しいってことで説明がつくのではないかと思っています、というところまでご説明したところでした。
業務の可視化というお仕事の成果物は、多くの場合フロー図です。（マジカは非常に美しい例外だと考えるべきだと思います。少なくとも今この瞬間においては）。そして、フロー図そのものが作業のゴールであることというのは非常に稀です。フロー図に従って、業務を分析する、新しい業務に切り替えてもらう、システムを設計する、などの後続の作業があるのが普通です。そして、それらの目的をかなえるためだけであれば、何も細かく表記ルールに準じている必要はないとも言えます。実際、細かい文書作成に時間をとられるくらいなら開発作業を先に進めましょう、という提言には十分な説得力があります。
したがって、「表記ルールの遵守」というのは、多くの場合「絶対にやらなければならないこと」とは思われていない、ということが言えそうです。そして、そのことが難易度を上げ、できない人を生み出しているのではないかと思うのです。
「絶対にやらなければければならない」という認識がなければ、細かい表記ルールに気を配ったり、既に書いてしまった成果物との整合性を常にチェックして矛盾を回避したり、という地味な作業にはどうしたって力が入りません。その意味で「表記ルールの遵守」を「絶対にやらなければならないこと」だと思えるかどうかが、業務の可視化スキルの有無を決定づけているのではないでしょうか。
いわゆるコンサルタントと呼ばれる人間が、お客様側の担当の方やSEと呼ばれる人達に比べて業務の可視化というジャンルでアドバンテージを持てるのだとすると、その理由には2つあるのではないかと思います。1つは、フロー図そのものが仕事上の最終成果であるケースがままあるということです。お客様担当者であればその先の業務そのものが、SEであればシステムの開発が、より上位のゴールとして見えています。もちろん、コンサルタントもより上位の目的を忘れないように心がけているはずですし、むしろそう言う視点も価値の源泉の1つであるとされることも多いと思うのですが、フロー図を作った時点で納品、その成果物の品質で仕事の評価が決まってしまう、というプレッシャが後続タスクが明示されていない分だけより大きくなるはずです。そのため、フロー図の世界の中での品質を追求する＝表記ルールも極力重視する、という結果に繋がります。
もう1つは、陳腐な例えですが、いわゆる”煉瓦を積む人”のようなお話です。やはりコンサルタントの方が、そうでない人に比べて「表記ルールの遵守」がプロジェクトの成功確率を押し上げる、というある種教科書的なテーゼをちゃんと信じている、という傾向があると思います。何故その表記ルールが制定されているのかという背景を理解し、そのことにより将来のどういうリスクを抑えているのか、ということを踏まえた上で作業を行います。そのため、単純に強制される作業ルールとして「表記ルール」を課されているという立場の作業者に比べると相対的に遵守レベルは高くなることが期待できます。（この辺りは、細かく1対1でルールの意味を咀嚼しているとは限らず、人によっては感性でその意義を嗅ぎ取っているとしか思えないようなケースも多々ありますが）
逆に言うと、それが自身の評価に繋がるという環境があり、またルールを遵守することが成功に繋がるという理論的バックボーンに対する信頼感を寄せていない限りは、「表記ルールの遵守」というのは中々難しいことなのではないかと思うわけです。
くどい話を続けた上で最後は精神論か、と言われてしまいそうですが、私は以上のような理由から、「業務の可視化」を実行できるかどうかは個別の知識や技能によるというよりも、むしろコンサルタントですとかビジネスアナリストなどの役割を与え、その役割の意義をしっかりと理解させられているか、という点に大きく依存するだろうと考えています。そしてその役割に耐えられるかどうかが弊社のメンバに期待する条件の1つともなっています。
#でも、例えば中途採用の面接でその対応力が計れるかというと、難しいんですよね。。。
（文責 Ishii Akinori IT-Coordinator）
最近のコメント