mixiでITコーディネータを「目指そうかなあ」という方に、メッセージを頂いて、「ITコーディネータの仕事って？」という質問を受けたまま、結果的にほったらかしにしてしまっています。
なんとも、難しくて・・・・
以前に書きかけた私がITコーディネータになったわけも書きかけのままだったりしますし・・・
まず、ITコーディネータの資格取得するに当たっては、ITコーディネータのIT化のプロセスというものを講習で学びます。
が、これは、プログラマではなく、業務系のSEなら誰もが「目新しいことはない」と思う内容です。
業務系のSEであれば、『業務分析』は必須技術ですから。
そして、業務分析は昔（私が仕事を始めた頃）は『問題解決』型の現状改善が主でしたが、その頃から『戦略的』情報システムという言葉が流行始めて、経営戦略に則った業務分析が主流となります。
で、バブルがはじけてBPRになるわけです。
というわけで、ITコーディネータになってからも、なる前も、私の仕事内容はさして変わっていません。
お客様の「もやもやぁとしたニーズ」を無理やり「経営の中長期計画」と整合性を取った「ビジョン」に置き換える。「中長期計画」がない場合は、経営理念とか業界のトレンドから勝手にテキトーなビジョンを作ってしまうこともあります。
それを「要求仕様」という名の、「こんなことがしたいねん」という絵に描いた餅にします。
で、予算とコストパフォーマンスを考えてお客様がお金を払いやすい程度の提案にする。
これが、引き合い段階。
受注後は、受注金額に応じて、絵に描いた餅の贅肉をそぎ落として行きます。
「この金額じゃ、これしかできん！」
「いや、これは不便やな」
「ほな、こんな方法で我慢しとき！」
「でも、これとこれもやりたい」
「そんなに欲張ると、つかいこなせんからあきまへんわ。次にしましょ」
と、巨大に膨らみがちな夢を現実の世界に近づけていくのが設計。
業務改善までを受けた場合は、人の動きや組織間のルールもいじくります。
（ここまでやると効果的ですが、経営コンサルタントにはやってもらいたくても、「システム屋」にはやってもらいたくないと思うお客様が多いようです。）
プログラマさんたちを煽てたり、脅したりしながら機能を実装するのが開発。
お客様を思いっきり煽てて、機械を回させるのが運用。
このフェーズでは信じられないようなアホなトラブルにも動じない度胸と演技力を要求されたりもします。
そして、モニタリングコントロールにあたる業務は今のところ、ありません。
ITコーディネータなんて資格制度がない頃から、ベンダの業務SEは（御用聞きエンジニア以外は）ITCのプロセスに則って仕事を進めてきているはずです。
ITCのプロセスは、需要家サイドにたって、経営戦略策定→情報化計画→調達→開発→運用→モニタリングコントロール
という一期通貫のプロセスを体系だてて整理したものです。
調達のフェーズを除いては、ITベンダが委託を受けて参加しうるものです。
（実際に、汎用機全盛でメーカーSEが顧客に囲い込まれている時代には、経営戦略の策定フェーズから参加していました。）
調達フェーズを加えたことで、ITコーディネータの立場の中立性を担保しています。
ところで、実際のITコーディネータ達はどんな人たちでしょうか？
私が知っている限りでは、半数以上がITベンダの社員です。
制度の発足当初は部長クラスの方が主流でしたが、最近では係長、主任クラスの中堅が会社の金で取得するようです。
残りの半数が税理士、公認会計士などの会計系の事務所の方。
そして残りが、経営コンサルタントなどのコンサル系の方。
皆さん、本業の説得力を高めるためにITCのプロセスを担保にして仕事の手法（ツール）として活用しています。
そうです。ITコーディネータはそれだけで「食っていける」という独立したお仕事にはなっていません。
現在のところ、ITコーディネータがネットワークを利用して、協業による中小企業に対する業務改革の推進プログラムを提供するといような試みを、一部のグループで実施しているようです。
そろそろ忘年会。ITC仲間の皆様ともお会いする機会があるので、他の方はどうなのかリサーチしてみます。
なんとも、難しくて・・・・
以前に書きかけた私がITコーディネータになったわけも書きかけのままだったりしますし・・・
まず、ITコーディネータの資格取得するに当たっては、ITコーディネータのIT化のプロセスというものを講習で学びます。
が、これは、プログラマではなく、業務系のSEなら誰もが「目新しいことはない」と思う内容です。
業務系のSEであれば、『業務分析』は必須技術ですから。
そして、業務分析は昔（私が仕事を始めた頃）は『問題解決』型の現状改善が主でしたが、その頃から『戦略的』情報システムという言葉が流行始めて、経営戦略に則った業務分析が主流となります。
で、バブルがはじけてBPRになるわけです。
というわけで、ITコーディネータになってからも、なる前も、私の仕事内容はさして変わっていません。
お客様の「もやもやぁとしたニーズ」を無理やり「経営の中長期計画」と整合性を取った「ビジョン」に置き換える。「中長期計画」がない場合は、経営理念とか業界のトレンドから勝手にテキトーなビジョンを作ってしまうこともあります。
それを「要求仕様」という名の、「こんなことがしたいねん」という絵に描いた餅にします。
で、予算とコストパフォーマンスを考えてお客様がお金を払いやすい程度の提案にする。
これが、引き合い段階。
受注後は、受注金額に応じて、絵に描いた餅の贅肉をそぎ落として行きます。
「この金額じゃ、これしかできん！」
「いや、これは不便やな」
「ほな、こんな方法で我慢しとき！」
「でも、これとこれもやりたい」
「そんなに欲張ると、つかいこなせんからあきまへんわ。次にしましょ」
と、巨大に膨らみがちな夢を現実の世界に近づけていくのが設計。
業務改善までを受けた場合は、人の動きや組織間のルールもいじくります。
（ここまでやると効果的ですが、経営コンサルタントにはやってもらいたくても、「システム屋」にはやってもらいたくないと思うお客様が多いようです。）
プログラマさんたちを煽てたり、脅したりしながら機能を実装するのが開発。
お客様を思いっきり煽てて、機械を回させるのが運用。
このフェーズでは信じられないようなアホなトラブルにも動じない度胸と演技力を要求されたりもします。
そして、モニタリングコントロールにあたる業務は今のところ、ありません。
ITコーディネータなんて資格制度がない頃から、ベンダの業務SEは（御用聞きエンジニア以外は）ITCのプロセスに則って仕事を進めてきているはずです。
ITCのプロセスは、需要家サイドにたって、経営戦略策定→情報化計画→調達→開発→運用→モニタリングコントロール
という一期通貫のプロセスを体系だてて整理したものです。
調達のフェーズを除いては、ITベンダが委託を受けて参加しうるものです。
（実際に、汎用機全盛でメーカーSEが顧客に囲い込まれている時代には、経営戦略の策定フェーズから参加していました。）
調達フェーズを加えたことで、ITコーディネータの立場の中立性を担保しています。
ところで、実際のITコーディネータ達はどんな人たちでしょうか？
私が知っている限りでは、半数以上がITベンダの社員です。
制度の発足当初は部長クラスの方が主流でしたが、最近では係長、主任クラスの中堅が会社の金で取得するようです。
残りの半数が税理士、公認会計士などの会計系の事務所の方。
そして残りが、経営コンサルタントなどのコンサル系の方。
皆さん、本業の説得力を高めるためにITCのプロセスを担保にして仕事の手法（ツール）として活用しています。
そうです。ITコーディネータはそれだけで「食っていける」という独立したお仕事にはなっていません。
現在のところ、ITコーディネータがネットワークを利用して、協業による中小企業に対する業務改革の推進プログラムを提供するといような試みを、一部のグループで実施しているようです。
そろそろ忘年会。ITC仲間の皆様ともお会いする機会があるので、他の方はどうなのかリサーチしてみます。
