公開日時: 2006/12/25 11:25
著者: 草木生(そうもくしょう)
年末でもあり、某研究会の忘年会も先週あった。
その話の中で、いわゆる要求開発(≒要求分析)にはストーリー、シナリオを提供しなくてはならないかも知れないと提案した。
先週書いた、
メソドロジは、
2:6:2の内、6割の人間の底上げを可能にする
にかかるのであるが、単純にフェーズの定義・説明、そこに関わるスキル定義・説明、成果物定義・説明、では機能せず、シナリオレベルのノウハウを注意書きでも良いから提供した方が利用者の拡大、ひいてはプロジェクトの失敗が減るように思うからである。
プロセス・コンサルとコンテンツ・コンサルの違い
やはり、プロトコルとして用語の相互理解が必要だろうと思われる。
開発現場のSE、システムエンジニア諸氏には嫌われるコンサルだが、少なくとも複数種類存在していることを知ってもらいたい。
プロセス・コンサル
・開発プロセス、課題解決のプロセスを支援する
現状分析、To-Beモデルのモデリング、体制なども含めてサポートするコンサルタント であり、プロマネの基本ノウハウ+課題アプローチ・モデリングノウハウを持つ
いわゆる、RFP作成から基本設計、外部設計くらいを担当するが、プロマネになった 場合はカットオーバーまで責任を持つこともある
コンテンツ・コンサル
・事業部の企画であるとか、企業の基幹システムの課題などを調査・報告する
その企業の現状と競合他社状況を分析、報告を出していく
報告書としては、分厚いものであり、発注するユーザ側にも1キロ一千万円くらいの
感覚があるらしい
現状ではインターネットの発達で苦しくなっている
独自の調査報告は、インターネットで70%程度は揃えられるようになってきており、
どこに独自色を出すかが難しくなっている
日米でのコンサルティングの違い
アメリカでは、コンサルティングがかなり軽いように思われる。
そのツールにある程度精通していると、あっという間にコンサルタントである。
それを日本に持ち込んでいるのが、外資系のソフトウェアベンダであろう。
日本では、ひょっとしたら何でもできるのがコンサルタントであり、まさに超人を期待されて始まるコンサルテーションもある。
ITコンサルの定義付けは、まだ一般的な理解を得ていない。
筆者は、10年程度はシステムコンサルとしてやっていたと思われるが、それにも一般的な理解はない。
瑣末な職種なので、一般的な理解を今後も得ることは無いだろう。
0 件のコメント:
コメントを投稿