プロセス・コンサルとコンテンツ・コンサルの違い

年末でもあり、某研究会の忘年会も先週あった。

その話の中で、いわゆる要求開発（≒要求分析）にはストーリー、シナリオを提供しなくてはならないかも知れないと提案した。
先週書いた、
　メソドロジは、２?６?２の内、６割の人間の底上げを可能にする
にかかるのであるが、単純にフェーズの定義・説明、そこに関わるスキル定義・説明、成果物定義・説明、では機能せず、シナリオレベルのノウハウを注意書きでも良いので、提供した方が利用者の拡大、ひいてはプロジェクトの失敗が減るように思うからである。

プロセス・コンサルとコンテンツ・コンサルの違い

やはり、プロトコルとして用語の相互理解が必要だろうと思われる。
開発現場のSE、システムエンジニア諸氏には嫌われるコンサルだが、少なくとも複数種類存在していることを知ってもらいたい。

　プロセス・コンサル
　・開発プロセス、課題解決のプロセスを支援する
　現状分析、To-Beモデルのモデリング、体制なども含めてサポートするコンサルタントであり、プロマネの基本ノウハウ＋課題アプローチ・モデリングノウハウを持つ
　いわゆる、ＲＦＰ作成から基本設計、外部設計くらいを担当するが、プロマネになった場合はカットオーバーまで責任を持つこともある

　コンテンツ・コンサル
　・事業部の企画であるとか、企業の基幹システムの課題などを調査・報告する
　その企業の現状と競合他社状況を分析、報告を出していく
　報告書としては、分厚いものであり、発注するユーザ側にも１キロ一千万円くらいの
　感覚があるらしい
　現状ではインターネットの発達で苦しくなっている
　独自の調査報告は、インターネットで70%程度は揃えられるようになってきており、
　どこに独自色を出すかが難しくなっている

日米でのコンサルティングの違い

アメリカでは、コンサルティングがかなり軽いように思われる。
そのツールにある程度精通していると、あっという間にコンサルタントである。
それを日本に持ち込んでいるのが、外資系のソフトウェアベンダであろう。
日本では、ひょっとしたら何でもできるのがコンサルタントであり、まさに超人を期待されて始まるコンサルテーションもある。

ＩＴコンサルの定義付けは、まだ一般的な理解を得ていない。
筆者は、10年程度はシステムコンサルとしてやっていたと思われるが、それにも一般的な理解はない。
瑣末な職種なので、一般的な理解を今後も得ることは無いだろう。