koufuuの日記: ふと思ったこと(コンサル、SE、PG)
日記 by
koufuu
表のストーリーを読んで、ふと思ったこと。
あの中で出てくる「コンサル」ってのは、何を指してるんだろうね?個人的には、コンサルがプログラムを書ける必要は認めていない。ただし、コンサルの1分野であるシステムコンサルであれば、プログラムを書いた経験はあるに越したことは無い、SEならプログラムを書いた経験が必須だと思う。
具体的には、システム構築に絡む職種は上流から、経営コンサル、システムコンサル(SC)、SE、PGと分業していると思う。そして、それぞれが、隣の職種とコミュニケーションが取れるだけの知識をもつ必要があると思うのだ。もちろん、一人2役であれば、それだけ広い範囲の知識が必要なわけだ。
俗に業務知識と呼ばれる知識(場合によっては特定の会社固有の知識も業務知識に含まれると思う。)は、SCやSEが主として押さえておくべき知識だと思う。SEであれば、担当する顧客がどういう業務をしているかと言うレベルでいいだろうが、SCであれば、業界に属している他社がどういう業務のやり方をしているかについて一般論を知っておく必要があるだろう。対して、経営コンサルであれば、業務知識はもちろんのこと、業界が今後どう進んでいくかについて一見識を持っている必要があるだろう。
上の段落の「会社固有の知識」を補足すると、帳票IDや、コード類を覚えているぐらいでないとダメな場合もあるのだ。会社によっては、会話ではコード番号が飛び交うだけで、それが何をさすのかは、その会社では常識となっている場合もある。その場合、そのコードを覚えていないと、顧客からの要件を聞き出せない、若しくは、お互いにストレスを覚えるという状況になるわけだ。特定の顧客に張り付いているSEなら、その企業の主要なコード類は覚えておいたほうがいいだろう。
んー、直感レベルだと、たとえば、システム提案をする場合でも、SEは「貴社では、~という業務なので、~というシステムはどうでしょうか。」、SCは「貴社では~とされていますが、他社では~というやりかたもあります。私は、~という観点から~がいいと思いますが、どうされますか?」。経営コンサルなら「今後、業界では~という動きが表面化してくると考えています。貴社もそれに備え、~という対応を取ることが望ましいと考えます。(経営コンサルの場合、対応策はシステムに限らないが)」。って感じかなぁ?いや、我ながら、嘘っぽいな。すまん、忘れてくれ。
おっと、一応、上の段落の「経営コンサルの場合、対応策はシステムに限らない」を補足しておくと、ある企業での課題の解決策として、たとえば、「組織改変」という選択肢もあるだろうし、「社員の給与体系変更」もあるだろう。あるいは、「管理会計の見直し」もある。それらを検討する際に、ITの知識が無ければ困るだろうか?そんなことは無いはずだ(もちろん、テーマによっては必要なものもあるだろうが)。そして、それらの詳細を詰めた結果、それを管理するシステムを作る必要があると言う段になって初めて、SCの出番となるわけだ。そのとき、SCは経営コンサルの話す言葉を理解できないと困るし、経営コンサルはSCに意図を正確に伝えられないと困るわけだ。
それはともかく、経営コンサルを名乗りつつ、三文字熟語(ERP、SCM、CRM、…)を連発する輩のほうが問題だろうと思う。そういうのは、三文字熟語のシステムを構築すること自体が目的化してしまっていると思うのだ。そして、そういう輩は三文字熟語を業務上なんのために導入するのかが不明確だから要件を固めきれず、後工程にしわ寄せてしまうんだろうと思う。
とか偉そうなことを言って困猿を名乗っている、おいらも、この分類で言うとSC~SEぐらいなんだがね。恐らくは、PGの立場からでは、SEぐらいは判別できても、経営コンサルとSCは一緒くたに考えてしまっているんだろうなぁと。ひょっとすると、SC~SEぐらいの立場から見ているだけでは良く分からないだけで、経営コンサルも細分化されたり、さらに上の階層があるのかも知れませんが。
と、表のストーリーでは、つっこみが怖いので、日記に書いてみるテスト。でも、コメントは歓迎。
あの中で出てくる「コンサル」ってのは、何を指してるんだろうね?個人的には、コンサルがプログラムを書ける必要は認めていない。ただし、コンサルの1分野であるシステムコンサルであれば、プログラムを書いた経験はあるに越したことは無い、SEならプログラムを書いた経験が必須だと思う。
具体的には、システム構築に絡む職種は上流から、経営コンサル、システムコンサル(SC)、SE、PGと分業していると思う。そして、それぞれが、隣の職種とコミュニケーションが取れるだけの知識をもつ必要があると思うのだ。もちろん、一人2役であれば、それだけ広い範囲の知識が必要なわけだ。
俗に業務知識と呼ばれる知識(場合によっては特定の会社固有の知識も業務知識に含まれると思う。)は、SCやSEが主として押さえておくべき知識だと思う。SEであれば、担当する顧客がどういう業務をしているかと言うレベルでいいだろうが、SCであれば、業界に属している他社がどういう業務のやり方をしているかについて一般論を知っておく必要があるだろう。対して、経営コンサルであれば、業務知識はもちろんのこと、業界が今後どう進んでいくかについて一見識を持っている必要があるだろう。
上の段落の「会社固有の知識」を補足すると、帳票IDや、コード類を覚えているぐらいでないとダメな場合もあるのだ。会社によっては、会話ではコード番号が飛び交うだけで、それが何をさすのかは、その会社では常識となっている場合もある。その場合、そのコードを覚えていないと、顧客からの要件を聞き出せない、若しくは、お互いにストレスを覚えるという状況になるわけだ。特定の顧客に張り付いているSEなら、その企業の主要なコード類は覚えておいたほうがいいだろう。
んー、直感レベルだと、たとえば、システム提案をする場合でも、SEは「貴社では、~という業務なので、~というシステムはどうでしょうか。」、SCは「貴社では~とされていますが、他社では~というやりかたもあります。私は、~という観点から~がいいと思いますが、どうされますか?」。経営コンサルなら「今後、業界では~という動きが表面化してくると考えています。貴社もそれに備え、~という対応を取ることが望ましいと考えます。(経営コンサルの場合、対応策はシステムに限らないが)」。って感じかなぁ?いや、我ながら、嘘っぽいな。すまん、忘れてくれ。
おっと、一応、上の段落の「経営コンサルの場合、対応策はシステムに限らない」を補足しておくと、ある企業での課題の解決策として、たとえば、「組織改変」という選択肢もあるだろうし、「社員の給与体系変更」もあるだろう。あるいは、「管理会計の見直し」もある。それらを検討する際に、ITの知識が無ければ困るだろうか?そんなことは無いはずだ(もちろん、テーマによっては必要なものもあるだろうが)。そして、それらの詳細を詰めた結果、それを管理するシステムを作る必要があると言う段になって初めて、SCの出番となるわけだ。そのとき、SCは経営コンサルの話す言葉を理解できないと困るし、経営コンサルはSCに意図を正確に伝えられないと困るわけだ。
それはともかく、経営コンサルを名乗りつつ、三文字熟語(ERP、SCM、CRM、…)を連発する輩のほうが問題だろうと思う。そういうのは、三文字熟語のシステムを構築すること自体が目的化してしまっていると思うのだ。そして、そういう輩は三文字熟語を業務上なんのために導入するのかが不明確だから要件を固めきれず、後工程にしわ寄せてしまうんだろうと思う。
とか偉そうなことを言って困猿を名乗っている、おいらも、この分類で言うとSC~SEぐらいなんだがね。恐らくは、PGの立場からでは、SEぐらいは判別できても、経営コンサルとSCは一緒くたに考えてしまっているんだろうなぁと。ひょっとすると、SC~SEぐらいの立場から見ているだけでは良く分からないだけで、経営コンサルも細分化されたり、さらに上の階層があるのかも知れませんが。
と、表のストーリーでは、つっこみが怖いので、日記に書いてみるテスト。でも、コメントは歓迎。
ふと思ったこと(コンサル、SE、PG) More ログイン