■失われた２０年とチェンジリーダーの減少

　ＩＴ導入プロジェクトにおいて、その成否を分かつ大きな要因のひとつに「チェンジ・リーダの存在」がある。しかしこの20年近くは、欧米流のマネジメント手法に基づいて数字（成果評価,キャッシュフロー,etc.）を追い続け人材育成をおろそかにしてきた結果、驚くほどチェンジリーダーという人材が減少している。

　チェンジリーダーとは、ＩＴ導入プロジェクトにおいて、情報システムと業務プロセスの変革の中核となって、プロジェクトの目標を達成し成功に導くキーマンである。その立場は、情報システム（ＩＴ）部門であっても、実務部門であっても良いが、外部のＩＴベンダーではなく導入企業側に存在すべきであろう。

　では、企業がそういった人材の必要性を感じていないわけでもなく、また企業によってはそれなりの予算を確保して手厚い人材教育を実施しているにもかかわらず、本当に意味での「チェンジリーダー」が育っていないのはなぜか？


■チェンジリーダーが育っていない具体例

「チェンジリーダー」が育っていない要因を導き出すために、私が関与したＩＴ導入プロジェクトの現場で発生した事実を例示する。まずは、実務部門での事例である。

１）ＳＣＭ／サプライチェーン・マネジメント・システム導入プロジェクト
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　サプライチェーン・マネジメント（以下、ＳＣＭ）システムの導入では、組織や会社の枠を超えた「情報共有」がＩＴ面での中核となる。また、共有した情報に基づいて業務プロセス（ビジネスモデル）を変えてしまうようなケースもある。こういったＳＣＭ導入プロジェクトのチェンジ・リーダーには、複数の組織や企業の枠超えた「調整能力」と、その利害関係者の意識を変えさせる「ビジョン」、そしてプロジェクトを計画し推進する「実行力」が求められる。

　Ｇ社では、実務部門の幹部社員（Ｎ氏）をリーダーとするＳＣＭ導入プロジェクトを組織した。Ｎ氏は、これまでにも部門システムの構築ではリーダを経験したことがあった。ＩＴ部門の経験は無いが、部門におけるシステム化要件をとりまとめ、ベンダーに発注して予定どおりにシステムを稼動させたことがあり、必然的にＮ氏をリーダーとするＳＣＭ導入プロジェクトがスタートした。

　ところが、ＳＣＭ導入プロジェクトが始まってみると、Ｎ氏が立てたスケジュールがことごとく遅延して再スケジューリングを繰り返し、またプロジェクトに参画しているメンバーからもクレームが続出する事態となった。それは、Ｎ氏が自分一人で考えた机上論（理想的なプラン）でプロジェクトを進めようとしたためであった。　ＳＣＭ導入プロジェクトでは、作業効率の向上といったファクターよりも、GIVE&TAKEでの情報提供とその活用がメインであり、Ｇ社プロジェクトでも組織間の利害調整がプロジェクト成否の重要ポイントであった。当然、Ｎ氏に対してそのことは事前に認識をさせており、プロジェクト途中でも何度も確認をしていたいたが、机上論が中心で他部門に対しても高圧的な対応をとるなど、自らの「行動を変える」ことができなかった。

２）基幹システム再構築プロジェクト
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　次は、ＩＴ部門での事例である。

　Ｔ社では基幹システムの再構築プロジェクトを企画し、外部コンサルタントが参画した「新業務システム基本計画の立案策定」を終え、具体的なシステム要件分析設計に着手した。分析設計のプロジェクトは、第一次開発の対象とするサブシステム毎に複数のＩＴベンダーと、対応する社内ＩＴ部門の担当者で組織し、プロジェクト・リーダーは、Ｔ社のＭ氏が担当することとになった。　Ｍ氏は、入社以来18年ＩＴ部門に所属するベテラン社員である。今回の開発範囲はＭ氏の担当してきた分野ではなく他部門から転籍してきたばかりではあったが、人事上も幹部社員一歩手前の評価をうけており、Ｍ氏にとってもこのプロジェクトはキャリアの面からも重要なテーマであった。

　しかし、プロジェクトが発足して具体的な分析設計作業が始まってみると、Ｍ氏のプロジェクト・マネジメントスキルの無さが露見した。チームセションの開始時刻になってもセションが始まらない。来週のセション予定が見えない。プロジェクト課題が整理されていない。プロジェクトメンバーで情報が共有されない。問い合わせに対するレスポンスが遅い、あるいは無い。等など、たとえＰＭＰの資格はなくても、プロマネの立場であれば果たすべき役割が果たせない。当然、ＩＴベンダーからだけでなく社内メンバーからもクレームが上がり、プロジェクトが崩壊の危機に陥いる事態になった。

　Ｍ氏はこれまで、手厚い社内教育メニューにしたがって、数々の講習会に参加してどれも好成績で修了している。プロジェクト・マネジメントについても、ＰＭＰ受験対策講座やコミュニケーション,ファシリテーションといったテクニックだけではなく、担当分野での実務を通じた経験も有しているはずである。しかしそれは、自分が得意とする限られた範囲のみでしか機能しないのである。　また、基幹システムの再構築においてもＳＣＭの導入と同様、単に作業の効率化だけでなく、ＢＰＲ（ビジネス・プロセス・リエンジニアリング）も含まれ、利害の対立する実務部門間の調整も求められる。

　Ｍ氏は、自身が知らない分野で、そして初対面となるメンバー構成の中で、プロマネとしてどう振舞うべきかを体得してはいなかったのである。あるいは、頭では理解できていても行動することができないのである。


■「チェンジ・リーダー」が育たない原因

　２つの事例に共通していることは「行動が変えられない」ことである。頭では理解した（つもり）であっても、実際にどうやって行動したら良いのかが判らないのである。つまり、様々な書籍や講習会を通じて、知識としては習得しており、本人も習得したつもりになっている。そして、習得した知識は実践の中で試してみて調整を加えながら体得していくことは、広く一般的に当たり前のプロセスである。

　そう、その「当たり前のこと」が「当たり前に出来ない」ことが問題なのである。

　こういった場合、「行動が判らない」のであれば「行動のやり方を指導（個々に指示）」すれば良いというものではない。本質を理解していない（理解できない）状態のまま個々に指示しても、指示されたことに従う（従おうとする）だけであって、行動そのものには何も変化があらわれない。プロジェクトでは様々な案件が連鎖的にかつ同時並行で進行していく。その内の一つを指示に従って行動したとしても、次々と迫ってくる案件をサバいていくことは不可能である。

　では、なぜ本質が掴めないのか？
　それは、従来は「当たり前」であった「人を育てる」ことを怠ってきたことに他ならない。

　ここ数年、製造現場での熟練工の技能が見直されており、従来は徒弟関係の中で継承してきた技能をＩＴで継承するようなことも始まってはいるが、その基本は「人と人とのつながり」であることには変わりない。これはＩＴ導入の現場でも全く同じである。

　失われた20年の間も、企業内では人材育成の重要性は十分に認識されており、キャリア形成プログラム（ＣＡＰ）制度を導入した企業も少なくない。しかし、その教育内容は「講習会受講」やe-Learning/CBTといった「知識学習」が中心であった。一方で、本質的な人材育成実践の場であるはずの「現場」では、数字（納期,売上,成果,キッシュ,etc.）が最優先され、現場で人材を教育するというミッションが希薄化（消滅）してしまっているのである。つまり「教育は人事部門」のように「他人任せ」にして、「現場での人材育成」を放棄しているのである。

　これは、現場を預かっている管理者あるいはマネージャーの怠慢である。
　また、そういった管理者やマネージャーを放置してきた経営者の怠慢である。

　今、あたなの会社ではどうでしょうか？
　現場で人材（人財）を育成していますか？


■どうやってチェンジリーダーを育成するのか

　チェンジ・リーダーの素養として、不確実で不揃いな情報から、仮説（シナリオ）をたてて情報を収集し、その仮説を検証するスキル（仮説検証）が求められる。常日頃から情報収集のアンテナを高くし、社内外の様々な情報や潮流をウォッチすると同時にコミュニケーションをとっている必要があるが、そういった行動は本人の意識（問題意識,危機意識,当事者意識）から生まれてくるものである。

　では、どうすればそういった意識付けができるのか？

　まず、経営者や管理者／マネージャー自身が、その意識を持たなければならない。　あるいは、経営者や管理者／マネージャー自身が、そういった行動を起こさなければならない。　つまり、チェンジ・リーダーに求める行動を自らも実行することである。
　であるとするならば、経営者の行動はまさにその実践であるといえる。　経営者＝チェンジ・リーダー（オーナー）である。ここで問題となるのは管理者／マネージャーであろう。

　前述の事例でも真因はそこにあった。
　Ｎ氏の場合、実務部門の立場でありながら現場での実務経験がほとんどない。入社以来、いくつかの部門を経験してはいるが、その業務を自らが責任を持って遂行することがなかった。たとえあったとしても、それは極限られた範囲に止まっていた。ただ、理論的なアプローチが出来るという面が、部門情報システムの開発や改善には有効であったため、Ｎ氏のマネージャーは彼を安住させてしまったのである。
　Ｍ氏の場合には、入社以来18年、限られた範囲での業務に携わったきたこと。その中で、意識のあるマネージャーとの出会いが無かったことであろう。ただ、Ｍ氏自身には問題意識はあったが、結果的に前職の管理者との対立から生じた精神面でのキズを引きずっていることも判明した。

　ここ数年、心の病(風邪)である「うつ患者」が急増しており、メンタルヘルスケアが声高らかに叫ばれている。たしかに社会現象として由々しき事態であるが、スキルをアップさせるためには、プレッシャーが必要である。プレッシャーの無い仕事では人は育たない。しかし、プレッシャーが大きすぎると押し潰されてしまう。また、何か行き違いで『心が折れる』こともある。心が折れてしまうと、そのパワーは後ろ向きに流れていく。

　だからこそ「現場教育」が必要なのである。
　現場から遠く離れたオフィスの会議室ではない。ましてや電話やメールでは決してない。

• 現場でのクロスコミュニケーション（重なり合う）
• 知と知、知と情、知と技といったクロスファンクショナルなナレッジ

　それは、場当たり的な「ＯＪＴ（On the Job Training）」ではなく「意識のある現場教育」である。徒弟制度の中で当たり前に伝承されてきた技能であり『共育（共に育つ）』である。


■時間がかかる。だからこそ今すぐ着手！

　以上のように、チェンジリーダーが育たない真因とその対策を考えてきた。

　ＩＴ導入プロジェクトの成否は「チェンジ・リーダー」の存在如何にかかっているともいえる。　しかし、対策を講じれば即座に「チェンジ・リーダー」が育成できるわけではないことは明白である。　中には、ちょっとしたキッカケで瞬間に「チェンジ・リーダー」となる人材もあるが、概ね長い歳月が必要になってくる。しかも、それを企業文化（ＤＮＡ）としての継続がなければ成立しない。

　企業の経営者にとっては、今さら「中長期的な人材育成を・・・」といわれても、今まさに直面しているプロジェクトを何とかしないわけにはいかない。人材が育つまで待っているわけにもいかないので、外部の人材を活用することになるが、そこにＩＴコーディネータという切り札がある。

　ＩＴコーディネータは中立的な立場であり、そのスキルと経験次第では「チェンジ・リーダー」となりうる人材像である。また、ＩＴＣプロセスの中では人材育成計画も含まれており、中長期的な人材育成計画の立案を支援することができる。

　ただ、やはり本来は社内にそういった人材は不可欠である。
　人材育成には膨大な時間が必要になる。

　だからこそ今すぐ着手！
　人材育成計画の立案に際しては、様々な教育カリキュラムとともに、
　現場教育(共育)をぜひ取り入れてもらいたい。

（ＩＴコーディネ?タ／植松栄介）

ラベル: ITマネジメント

■はじめに　

RFPは提案依頼書であり、RFIは情報提供依頼書である。システム開発にあたり、自らのニーズや現状をとりまとめ、書類の形で複数のITベンダーやシステム･インテグレーターに渡す資料を言う。口頭でニーズを伝えるのとは異なるため、依頼の目的や求めている物事がハッキリし、曖昧さや人情（普段の営業付き合い）要素が排除されるため、適切で公平な競争提案を貰いやすくなる。

小職は、仕事柄、RFPを発行する立場とRFPを受け取って提案する立場の両方を経験することがある。そのときの経験からすると、提案する立場から見て良いRFP/RFIを書く人は、会って話をしても優秀であるし、提案しにくいRFP/RFIを書く人は、会って話をしてもなかなかピントが定まらない場合が多いように思う。

本論では、そのときの経験などを踏まえ、RFP/RFIを作成する際に陥りやすいモラル上の問題を指摘し、より良いRFP/RFIを作成する為の参考とするためのヒントを提示する。

■RFP/RFIが流行り始めた

ここ最近、RFPという言葉がシステム開発ベンダーの中でもかなり知名度を上げてきている。ほんの少し前であれば数億円以上の大規模なシステム開発でなければRFP/RFIといった言葉は聞かれなかったし、プログラマでもその言葉を知っている人は少なかった。こういう変化の中の一部には、システム提案を依頼するときにはRFP/RFIを書いて依頼しようという、ITコーディネーターの地道な呼びかけや活動もあるのだろう。

ただ、依頼をかけるユーザー企業や団体が純粋に自前でRFP/RFIを作成する場合はまだまだ少ないように思われる。多くの場合、RFPやRFIを書くためには相応の専門能力が必要であるため、ITコーディネータがRFP/RFI作成に携わったり、普段から出入りのあるITベンダーが作成する場合が多いように思われる。（小職もその一人である）

また、RFP/RFIを受ける側のシステムベンダーも、仮にその内容が自社でできない内容であっても、名乗りだけは上げておくという態度をとることも多い。営利活動からすれば、そういう態度をとるのは自然な話である。そして、肝心のRFPはシステムベンダーの関係会社や子会社、協力会社等の手に渡ってゆく。

一般的にRFP/RFI発行の手続きを行う場合は、依頼元と依頼先と秘密保持契約を締結してから、RFP/RFIを提示するものだが、同等の秘密保持契約を継承する限りにおいて、依頼先がさらに他に依頼することを認めているケースが多い。

実際、システムベンダーやシステムインテグレーターは、ハードウェアメーカーや、通信業者、関連ツールベンダー等に相談しながら進めなければ、納期、金額、性能保証体制などRFPに書かれている事項は満たすことができないので、これは特異なケースではない。

■RFP/RFIを受けたシステムベンダーの立場から

さて、RFP/RFIにも出来、不出来がある。もちろんユーザー企業内での現状分析の具合やRFP/RFI作成までの時間等の問題で満足に要件を固めることができない場合も多いため、内容の正確さや濃さについての出来、不出来はあっても仕方が無いと思うのだが、それ以前の問題もある。それは、RFP/RFIを貰って提案ベンダーの立場になった時に提案書を書いて提出する側の不満や苛立ちとして現れてくる。多くの場合、RFP/RFIの提出期限は２週間程度であるが、２週間で作成できる限度を超えた情報提供を依頼してくるRFP/RFIに出会うことがある。

■開発ベンダーの手法に深入りしたRFP

たとえば、「開発ソフトウェアの品質管理をどのように行って、提供製品の質を維持するのか？」という課題に関して、プロジェクト管理手法やテスト手法、使用しているツール等を事細かに記述させ提出させようとするものがある。ある程度の開示は必要であろうが、提案書を記述する側は、別のことを警戒するのである。

すなわち、このRFP/RFIが他のシステムベンダーの手によって書かれたものであるとすると、秘密保持契約があるとはいえ、事実上、こちらの手の内を他のシステムベンダーに読まれてしまっていることになってしまう。ユーザーに理解してもらうのはよいとしても、開発効率を上げるための工夫は、基本的には他社に知られたく無いことでもある。

あるいは、パッケージソフトのデータベース設計図、スキーマ構造図、エンティティ設計書を出してください、などといったRFPも存在する。ERPソフトにおいて、データベース設計は一種の知的財産であり、秘密保持契約があるとはいえ、購入するかどうかわからない人々に簡単に開示するわけにはいかない。

■矛盾したRFP

あるいは、ベンチャー企業や新規事業のシステム提案依頼で多いのが、将来計画が非常に曖昧で、どの時点の企業規模で見積もればよいのかわからないといったものである。
これらにはRFP自体に矛盾があるものも多い。

たとえば、一人１個を買うのが普通の、１個ｎ万円の商品があるとして、その伝票発生数や、営業担当の数、年間販売計画数量などが、矛盾している場合である。１営業マンが１０分に１個ずつ訪問販売してゆかなければいけない計画になっていたり、月に１０台程度販売している工作機械が、システムを導入した直後から毎月８０台ぐらい売れる計画になっているが、生産設備は現状のままで月産５０台が限度であったりという具合である。

■経営計画を考えさせようとするRFP

一見IT提案のようで、よく読むと新規事業やビジネスモデルの検討依頼のようなものもある。

通常、RFPでは、ユーザーニーズとベンダー各社が持つ技術や製品、ソリューションとのフィット＆ギャップを明確にしてゆくことにより、依頼ベンダーを絞り込んでゆくことが重要になる。

ところが、時折「あなたが持っているIT技術を使って、私たちのビジネスモデルをどう変えることができるのかを示してください」とか「ホームページを開設すれば、月商いくらぐらいになると考えられますか」といった質問が設定されていることがある。そして「そう考えた前提条件を残さず書き出しなさい」といった注意書きが載っていることが多い。

たしかに、RFP/RFIの目的のひとつとして、ユーザーが知らない画期的な手法や製品を市場から情報提供してもらうという事があるのだが、そこに裏付けを求めるべきではないだろう。

また、経営者からRFP執筆者やITコーディネータには「IT化でいくら儲かるんだ？」といった投資効果に直結した質問が降りてきて、対応しないければならない場合もあるが、その質問をRFPに記述するのは、仮に依頼元の正直な気持ちだとしても、馴染まないように思われる。

■前提条件不足のRFP

RFPを書いている現場では、時間不足、情報不足のまま見切り発車してしまうことが多い。十分なITコーディネートを受けていなかったり、社内の情報化戦略が固まっていない場合には、特にそうなりやすい。

問題は、RFPの中に提案するのに十分な情報が盛り込まれていないことである。たとえば、依頼企業・団体のIT経営成熟度に関する情報や、情報システム部門やシステムに詳しい人の能力や権限に関する記述が少ない場合がある。

たとえば、導入後のサポートやシステム運用等について見積もりを得ようとするならば、その組織のIT経営成熟度や担当者のスキル等がわからないと、なかなか提案しづらいものである。つまり、全社のシステム運用体制や会社の情報化がどのように浸透しているのかがわからないため、提案自体が非常にブレたものになる。

他にも、サービスレベル、セキュリティレベル、おおよその予算感覚などが抜け落ちていることが多い。

そして、こうした前提条件が不足しているRFPに対して、質問をすると「貴社が最適だと思う構成で提案してください」といった曖昧な逃げ口上で回答される場合や、「それでは数パターン例示してください」という場合がある。

だが、システム提案する側からすれば、まじめに数パターンを検討し、コスト算出することは難しい場合が多い。それこそ、松・竹・梅の３パターンで金額が数倍違うものを提示することになってしまう。これではRFP/RFIによって要件を整理したことにはならない。
しかし、多くの場合見積金額の根拠はかなり細かく書くことが求められている。

これでは、むしろ提案者側に重たい負担だけがのしかかってくる。

■提案依頼者と提案者の関係

RFPを受け取ったシステムベンダーの行動を考えてみよう。システムベンダーの営業としては当然仕事が欲しいから、自分の事業範囲に少しでも関係しそうな部分があれば、会社に戻りRFPを提案書作成者であるシステムエンジニアに渡すことになる。

しかし、多くの提案書作成者は、他の十分な仕事量を抱えた上で、１週間とか１０日といった限られた提案時間を与えられ、大量の資料を作成してゆかなければならない。特に優秀なシステムアナリストやシステムエンジニアには普段の仕事でも業務が集中しがちである。

ある提案では、RFP/RFIどおりに提案書を作成したら、200ページに及ぶ大作になったことがある。添付資料などをあわせると、ざっと300ページである。ところが、断るときには、電話１本である。営業が訪問しても、プロジェクトが始まって忙しいからとなかなか会えない。

このような体験を重ねてゆくと、次回RFP/RFIが提示されても、まじめに返事しようという気にはならない。

■良いRFP/RFIとは

良いRFP/RFIとは、必要十分な情報が矛盾なくコンパクトに伝えられていることは重要であるが、それが提案書作成者に気持ちよく情報開示してもらうものでなければならない。 特にシステムベンダーの選択肢が少ない地方では、良いRFP/RFIを作成してベンダーとの関係を良好に保つことも重要である。 これを踏まえたうえで、前述した良くないRFP/RFIの例に対して、どのようにすればよいかを以下に示してみたい。

■開発手法に深入りしないRFP/RFI

プロジェクト管理能力に対する不安や、システム品質に対する不安を取り除いて欲しいというスタンスで、記述することが重要である。つまり、どの程度のシステム品質やプロジェクト管理が遂行できれば不安ではないのかを提示することが重要で、そのような経験が過去どの程度あるのか、不安を除去する証明する提出資料は開発費用に含まれるのか、別途費用を払えばどのような上位オプションがあるのかを訊くようにする方が良い。


■矛盾しないRFP/RFI

RFP/RFIに矛盾が見つかると、提案書作成者はそのRFP/RFIの全ての記述が疑わしくなる。したがって、矛盾が発生しないようにチェックをすることが肝要であるが、どうしても整合性が取れない場合は、どの数字を基軸に提案を展開してゆけばいいのかを明示する必要がある。

つまり「現段階では将来の売上計画と今回のビジネスモデルおよび費用計画は必ずしも整合性を持っていません。したがって、別紙に示す費用計画を元にご検討頂き、売上計画などは参考程度にお考えください」等と、提供情報の精度に濃淡を付けるなどの工夫が必要となる。

■経営計画を与えるRFP

経営計画に関わる情報は、遮断し、決まっていないことは決まっていないと明示し、それ以上の要求は書くべきではない。

■前提条件をはっきり記載するRFP/RFI

前提条件は変動があるとしても、はっきり記載することが必要である。例えば、３年後の新規顧客数がどの程度になるかは、誰だって分からない。しかし、RFP/RFIの主目的は、同じ前提になった時にどのベンダーが一番良い提案を返してくれるかを判断するというところにあるわけであるから、３年後の新規顧客数のような数値は固定させてベンダーに提示しないといけない。同様に、セキュリティレベルは、「Pマークを取得できる程度の企業環境だと仮定し、それに相応しいセキュリティを提供すること」といった表現が考えられる。

システムの二重化や信頼性に関しても、システムコストが大きく変わる要素である。ハードウェア価格だけではなく、二重化のための特別ハードウェアや、それらを正しく起動／終了させる運用手法等も変わってくるため、RFP/RFIには必ず記載するようにする。どうしても明確な記述が出来ない場合は、「現在のシステムと同等か、やや高いレベル程度とする」といった記述等を検討する。

また、システム部門が保有するスキルに関してはできるだけ記載したほうが良い。技術者（社員、協力会社）のおおよその年代とスキル等をたとえばITSSの技術レベルで表現し、日常の業務内容や保有技術（開発言語、システム設計力など）を表にまとめ、人事異動が頻繁かどうか等を示すだけでも、運用の提案には大きく役立つ。一般従業員のパソコンスキルに関しても、社員教育を見積もりに含むのであれば、触れておいたほうが良い。

また、はっきり記載できない部分がある場合、要求する情報や提案は精度を落として提示してもらうような配慮が必要である。

■まとめ

良いRFP/RFIなのかどうかを判断する為の、絶対的な指標や客観的な測定値を設けることは難しいしコスト的にも馴染まないと思われる。もとより、世間にRFP/RFIを書き慣れたエンジニアやアナリストはまだまだ少ない。

もし、RFP/RFIを書きなれた人が近くに居ないのであれば、まずちいさなRFIを書く機会を沢山与え、RFI/RFPを書くための文書部品を書き溜める機会を作っておくと良い。最初に社内のシステム構成図や、システム部門のスキルマップなどを書いてしまえば、数年経ってもそれなりに使えるものである。

また、提案を依頼し、どこか１社に決めた後、選に漏れたベンダーを呼び、落選理由を説明すると共に、「また次回別件でRFP/RFIを提示する機会があると思うので、今回お渡ししたRFP/RFIの中で書きにくかったところがあればお教えいただきたいと思います。またもし、参考になるような他社のRFP/RFIがあれば、章立てだけでも見せていただけないでしょうか？」という依頼をしてみてはどうでしょうか？

こうしたタイミングはRFP/RFIを書く技術を磨く良いチャンスである。良いRFP/RFIには良いベンダーが付き、提案書作成者も真剣に取り組むものであるから、長期的な視点から考えても、非常に有用なミーティングになるはずである。

多くのRFP/RFIに接する機会を持っているITコーディネータは、良いRFP/RFI、悪いRFP/RFIを世に問うてゆくのも責任の一部ではないかと感じている。

ITコーディネータ／太田垣博嗣

ラベル: ITマネジメント

　３年ほど前、全国にチェーン展開している小売店の基幹システムの開発プロジェクトが発足しました。そのプロジェクトにＳＥとして担当することになったのが始まりである。
　このプロジェクトは当初５名体制でスタートしました。そして、ピーク時には２０名近くのエンジニアが投入され、開発期間も３年を要する大規模なものでした。私は、そこでバッチ系のＳＥリーダーとして携わる事になりました。そこで私が体験した事、気づいた事を論じていきたいと思います。

１．大きく分断された開発体制

　このプロジェクトの当初は、５名体制で同じ開発場所で作業を行っていました。ところが、プロジェクトが進むにあたってメンバーが増え今の場所での開発作業が困難になってきました。本来なら、プロジェクト開始前からメンバーが増えた時の開発場所の手配をすべきところでした。ところが、課題として気づいてはいたものの実際に行動を起こすまでにはいたりませんでした。

　そこで、今後の開発体制をどうするべきかを話し合った結果、大きく２つに分断することとなりました。１つは、ＷＥＢを中心として画面系の開発チーム、もう一つは夜間更新、集配信を中心としたバッチ系の開発チームとする事になりました。既存の場所には、バッチ系チームが残り、画面系のチームは、そこから電車で３０分ぐらい離れた場所で開発を行うこととなりました。そして、それぞれのチームにプロジェクトマネージャ（以下、ＰＭとする）を配置して、進めて行くことになりました。

　分断後当初は、問題なくやっていたのですが、時間が経過するとともにチーム間のコミニケーション量低下、理念の違い、一体感の欠如が生まれていました。

　ある時、要件変更が発生し共通のデータ仕様を変更せざるをえない状況となりました。そこで事件が発生しました。互いのチームが保身に走り、自分のチームが有利になるような変更案を提案するようになりました。本来であれば、プロジェクト全体からの視点に立って最適な選択をするべきであるが、チーム間での信頼関係の無さがこのような結果になってしまった。結局、バッチ系のチームが折れる形となって事態は収拾することになった。もちろん、Win-Loseの関係では、互いの関係が改善されるわけでもなく、より一層関係に深い溝ができる事となった。

　なぜ、こうような事態になってしまったのか。順に考察することにした。

<1> ＰＭのコミニケーション力不足

　　　まず、それぞれのＰＭのコミニケーション力不足が考えられる。メールや電話等でのコミニュケーションはあったものの、場当たり的でその量は多いとは言えなかった。まず何よりも、互いの事を理解しようという気持ちが欠けていたのが、一番の問題だった。本来であれば、互いに協力関係を築いてプロジェクトを推進していかなければならないのであるが、自己の利益を追求してしまい対立関係に陥ってしまった。

<2>プロジェクトメンバー全員がオーバーワーク稼動

　　続いて考えられるのは、無理な短納期要望を受けて、プロジェクトメンバー全員がオーバーワークであった。もちろん、お客様からは厳しい低コスト要望があり、ぎりぎりの人数でやらざる得ない状況にあった。メンバーには、過労による疲労感、ストレスがまんえいしていた。そんな状況で、全体を思う心の余裕がなく自己の利益のみしか考えられない状況に陥っていたのであった。

　やはり、分散型開発を行う場合は、しっかりとしたコミニケーション計画をプロジェクト内で規定して、理念を共通化させ、信頼関係を構築していく事が重要ではないかと感じます。そして、利害関係が対立した時はどちらが、Win-Loseになるのではなくて、互いがWin-Winになる別の案を模索するべきだと考えます。その為にもメンバーには、全体の利益が個別の利益に繋がることを理念として共有化させることが重要ではないのだろうか。よって、メンバーの精神状態を常に正常な状態に保つ為にも、無理な残業や過度なスケジュールを引いて追い込むのは、やめるべきなのである。

２．長期化する内部進捗ミーティング

　このプロジェクトを管理している一人のＰＭは、１日２回の進捗ミーティングをプロジェクト内で行う。業務が開始して１時間後と定時終了後に行うのが日課になっているのであった。このミーティングは、システム開発メンバー全員で行い、その日の進捗状況、遅れや問題点を報告するものであった。形式としては、一人ずつ順番に報告していく形を取っていくものであった。その報告に対して、ＰＭが一人ずつにアドバイスをして問題を解決していく形をとっていた。この手法は、問題点をプロジェクトメンバー全員で情報共有ができ、全員で問題解決をしていく姿勢にしてチームの団結力を高める効果を狙うものであった。

　ところが、報告するメンバーが１０人程度いるので、長時間、拘束されるミーティングになってしまった。まず、進捗報告の準備に３０分程度かける。そして、１回のミーティングが平均３０分くらいなのだが、長くなると１時間、２時間と行われる時がある。ひどい時は、１日の半分が進捗ミーティングをしている時があった。特に、スケジュールの遅れや問題が複雑化する程、議論が長期化する傾向にあった。これの弊害として、問題のなかったメンバーやスケジュールの遅れのなかったメンバーまで、この進捗ミーティングが原因で遅れることになってしまった。まさに本末転倒な事態になってしまったのである。

　理想の進捗管理とは、「誰もが容易に進捗状況を可視化することができること。問題点があれば情報は皆で共有すること。問題解決は、最小限の利害関係者で解決するようにして、早期に情報公開をすること。」、と私は考えます。前段で紹介した事例のような、定期的に皆を集めてミーティングする事は大事だが、それが頻繁になると本来やるべき作業にも影響が出てくるのは当然である。その為にも、進捗管理を工夫して効果的で時間の掛からないものにするべきだと考えます。

＜最後に＞

　分散されたプロジェクトのその後・・・

　このプロジェクトは、納品機能をいくつかに分け段階的にリリースをすることになっていました。１段目のリリースは、多少のトラブルはあったものの無事に終えました。そのタイミングでメンバーが減少し、再び分散された開発体制が統合されることになりました。その後、ＰＭ体制も一本化されてチーム間で失った信頼関係も取り戻すようになりました。それは、指揮系統が統一されたのと、プロジェクトが収束することによって残業時間も減り、スケジュールにも余裕が出てきたことがあり、チーム内にもゆとりができた事が大きな要因だったのかと感じる。今までは、分断されたことによってチーム連携（コミニケーション）する工数が発生して、その連携によるトラブルも多発していた。それが、解消されただけでも開発工数の削減に繋がりスケジュールにも余裕が出てきたのであった。やはり、お金を掛けて無理してでも「ワンフロア」で開発体制を構築することが、開発工数の削減に繋がるのではないかと感じました。

ITコーディネータ　森木　康太

ラベル: ITマネジメント

■ITコーディネータはコンサルタントなのか？
コンサルタントとは企業内だけでは解決できない専門的な問題を解決するための支援業務を行う者と思われます。特に問題を解決するために有効なソリューションを提案し効果を実証することだろうと思われます。ITコーディネータ資格を取得したとき経営戦略立案手法も勉強したのだから個人的にコンサルタント資格を得たように感じました。コンサルタントの定義自体が曖昧なので自分自身がそうだと思えばそれでよいのでしょうが、現在実際にITコーディネータとしての活動を行ってみるとどうも違うように感じております。ITコーディネータはコンサルタントなのか？顧客は何を期待して依頼してくれているのか？ITコーディネータはその名前のとおりコーディネータなのであってそんなに大上段に構える必要はないのではないか？それぞれの契約によって変わるかもしれませんが、自身の経験からコンサルタントとITコーディネータの違いについて考えてみました。

■コンサルティング開始
約１年前にある企業とコンサルティング契約を締結しました。上場企業で約５名の情報システム人員を有している企業ですが、３０年来利用しているシステムのため現在の情報システム人員は運用保守業務が主体となってしまっており、現在在籍している人員でシステムを初めから構築した経験はありませんでした。そのシステムを全面的に刷新することとなり、その構築支援として契約いたしました。はじめは、ITコーディネータにおけるコンサルティング契約ですからプロセスガイドラインに沿って経営戦略から立案ですよとか、SWOT分析などを提案し実施しようとしたのですがどうもあまり乗り気でなく、そのような構築手法理論などは優先順位が低く必要性は感じてくれましたが、そんなことよりもっと重要なことがあるという返事で実行されませんでした。今回の契約は決して安い金額ではなく、ではもっと重要な問題とは本当に重要なのかと、こちらが悩むようになりました。

■でも必要とされている

元々依頼内容がITコーディネータにぜひプロジェクトに参加して欲しいというそんな程度でした。しかし、ITコーディネータのプロセスガイドラインが気に入って依頼されているわけでもなく、何か違う価値をITコーディネータに求めていました。プロセスガイドラインに沿った活動をしているわけではないのに、またその作業を行おうという思いもないのに、それでいて契約を切られるわけではなく、次は何時着てくれるのですかと、なぜか必要とされている状況が続きました。では何を行っていたかと言うと、システム構築を行っていく過程では様々な問題が発生します。コンピュータ専門用語の正確な理解、ベンダー側担当のSEが不満に思っていること、利用者が疑問に感じていること、そして経営者からの突然のシステム変更要望など、そのような様々な問題に対してどのように対応していくべきか、経験がないと中々出来ない作業だと思われます。またそもそもSEの不満、利用者の疑問などを気づき、すばやく対処していくことも難しいことであり、高度なスキルが必要になると思われます。そして導入を予定しているシステムはうまく業務に適用するのかどうかを見極める目利き力も必要となります。そのような情報システム構築に関しての相談役のような役割をしておりました。そのような過程で、もしかして顧客はシステム構築におけるITCのプロセスガイドライン理論の提供とその実行ではなく、この「気づき」と「目利き力」を求められてるのではないのかと考えるようになりました。さらには、問題点を気づいた時にわかりやすく伝えてくれて、解決のために中立的な立場で関係者を集めて対策を打てるコーディネーション能力を持った、まさしくITのためのコーディネータが求められているのではないかと考えるようになりました。もちろんプロセスガイドラインは重要でありその知識があるからこそ、必要な関係者をコーディネートし解決に向けた対策がうてるようになると思います。しかしプロセスガイドラインを知っていると言ってもその程度の知識というのも現実に感じました。それを顧客もわかっていたのではないかと考えています。

■情報システム室代行業はコンサルタント？

ITコーディネータとしてのコンサルティング契約は、自らが高度な経営理論及びシステム理論を伝え解決していくことではなく、顧客視点となって経営者の想い、利用者のシステムにおける疑問の相談窓口となる情報システム室の代行業だと考えるようになりました。役割が情報システム室ですから突然、経営者、利用者の方に対してまずはSWOT分析です、と言っても皆さんびっくりされるだけであり、受け入れられなかったのは当然だと現在思っております。それよりも、普段利用者及びSEがシステムについて感じていること、最新のITの活用事例ってどんな感じ、そして経営とITを結ぶ方法などを経営者と話し合えるような身近な相談窓口として存在するだけで非常に重要な役割を得ていると思われます。特に中小企業ではシステムにおける専門部署もないところが多く、このような役割を担うITコーディネータは今後特に重要になると感じました。契約していただきました上場企業でも実態はあまり変わりがないことが今回の経験で分かり、よりこの思いは強くなりました。資格を取得した時はコンサルタントになった気分でしたが、最近ではそんなに肩肘を張らず情報システム室代行業と考え、もし経営戦略立案などが必要であれば経営コンサルタントをコーディネートし、その結果をうまく情報システムへ反映できるように助言をすれば良いのではと考えております。ITコーディネータの役割は経営とITの橋渡しですが、トップダウンアプローチだけではなく、実際に情報システムを利用される方と経営者の橋渡しも非常に重要な役割だと思います。ITコーディネータはそれぞれの立場での想いを意見として取りまとめる。または聞いてあげる。そして理解してあげる。そんな人材だと考えるようになりました。それはまさしく情報システム室が担う作業でありコンサルタントの仕事ではありません。その作業を代行できる存在意義は、コンサルタントではないITコーディネータとしても、特に人材不足の中小企業にとっては非常に重要な役割であると思われます。

ITコーディネータ 認定番号：0023112004C長尾　道晃

ラベル: ITマネジメント

００　サマリー
CobiTは、ＩＴコーディネートを推進する際のCBK（Common Body of Knowledge）として有効である。本稿では、CobiTを活用し、ある企業の情報化成熟度を検討し、その後の中長期情報化戦略の方向性を設定した体験に基づき、ITコーディネータがCobiTを活用する方法について論ずる。

以下、その要旨である。
（１）CobiTを厳格なITガバナンス成熟度評価ツールとして用いず、対話、啓蒙ツールとして用いる。（２）CobiTに書かれている内容をやさしく時間を掛けて議論してゆくうちに、キーパーソンがCobiTをベースにしたバランスの取れた価値観を持つことができるようになる。
（３）議論には半年程度の時間が必要であるが、効果は高い。
（４）目前の課題を解決する、実際のITコーディネート作業と並行して進めるのが良い。


０１　はじめに
CobiTは、またITコーディネータの必須知識となっており、筆者がITコーディネータになるための必須研修を受講した際には、研修の最後に日本語のCobiTテキストを提供された。したがって、本稿の読者は、CobiTの内容をある程度理解しているものと想定し、本稿では詳しい説明は行わない。

ただ、筆者の感覚では、ITコーディネータになるための研修会では、CobiTの存在に触れる程度であり、実際のITコーディネートの場で活用している方は、意外と少ないのではないかというのが正直なところである。理由はいくつかあろう。
　・CobiTのように、企業全体のITガバナンスを検証するという考え方は、日本では一般的ではない
　・CobiT第2版が抽象的で日本では使い物にならなかった。
　　　（CSF/KPI等が今のように整備されたのは現行の第3版からだったと記憶している）
　・原文が英語で、第3版の日本語訳も解りにくい。（誤訳や意味不明用語も無いとは言えない）
このように、ITコーディネートの現場でCobiTを利用するためには、相応の工夫や土壌が必要とされると思われる。

筆者は、あるITコーディネート案件において対象組織の全体像をつかみ、対象組織の担当役員と認識を合わせるためにCobiTを用いたところ、担当役員と非常に良好な信頼関係を築くことができ、現在も長期にわたるITコーディネートを実施中である。 従って、筆者にとってCobiTは実例も豊富で、ITコーディネータや情報システム部門を取りまとめるマネージャクラスには使いやすいツールのように思える。以下、筆者の体験をベースに、どのような位置づけで使えばよいのかを記してゆきたいと思う。


０２　CobiT第3版の構成
CobiTは、米国の情報システムコントロール協会（ISACA：Information Systems Audit and Control Association）が提唱しているITガバナンスの成熟度を測るフレームワークであり、銀行系企業等を中心に活発に利用されていると聞く。

CobiT第3版は、4分野34項目のテーマから成っており、各項目それぞれにCSF、KGI、KPIがかなり具体的に表現されている。これによりコーディネート対象組織が組織の中でどのような情報処理機能を持っておくべきかが解り、0から5までの成熟度モデルにより、ITガバナンスの成熟度がどの程度なのかが見えてくる。

（参考）CobiT第3版の4つの管理プロセス
　1. Planning & Organisation 計画と組織
　2. Acquisition & Implementation 調達と導入
　3. Delivery & Support デリバリと支援
　4. Monitoring モニタリング

CobiT第3版が使いやすいのは、対象組織を見るためのいくつかの切り口／視点を提供してくれるところにある。4つの管理プロセス34項目のテーマという見方以外に、ITプロセスの成熟度で見ることも出来、ITプロセスを動かす「ITリソース」とITプロセスが動かす対象とする「インフォメーションの質」という、2つのコントロール対象ミニマトリックスで見ることも出来る。

なお、日本語版の翻訳だけをたよりにして進めると、意味がわからないことが数多く出てくるので、できれば英語原文も読みながら理解してゆくべきである。訳については、別途論ずる予定であるが、後半のシステムの可用性・キャパシティに関する部分等は、日本語になじまない部分が多く、英語で理解したほうが良い。 （訳の問題についてはこちらのITコーディネータさんも、いろいろ指摘されている）

０３　シチュエーション
CobiTは、対象企業のキーパーソンや問題意識を持つ人物と最初にミーティングを行う際のクイックリサーチに有用なリストを提供してくれる。（ここでの初回ミーティングとは、単なる挨拶やファーストコンタクトではなく、本題に入るミーティングのことを指す。）

ITコーディネートを行う場合、ITコーディネータによっては、ITコーディネータの位置づけを十分に説明しないまま、一方的なヒアリングに入ってしまいがちである。気持ちはわかる。経営戦略やシステム状況等をできるだけ正確に早く理解し、今後の進め方を判断したいがために、相談者を質問攻めにあわせてしまうのである。 こうした質問攻めは、ITコーディネートを行うために必要だから仕方ないとも言える。

しかしながら、相談者の側ではITコーディネータのこうした行動を必ずしも理解してくれているとは限らない。むしろ、「ITコーディネータはITと経営の両方に詳しく、すぐにアドバイスをくれるセンセイだ」という認識のもと、１回のミーティングで、１回なりの何か自分で判断し考える材料がほしいと考えている場合がある。

従って、ヒアリングだけで終わった場合、多少なりとも釈然としないことも多いようである。まして、コンサルタントやアドバイザーを使うことに慣れていない組織の場合は、ミーティング直後に使える「知見」や「新たな問題発見（気付き）」を求める傾向があるため、注意が必要である。

少なくとも相談者側に、”課題をITコーディネータに丸投げしない”という意思があれば（←実際、相談者側はそうあるべきなのだが）、「気付き」のための何らかのヒントを提示し、ミーティングをして良かったと思えるような成果を提供してあげる事が長い付き合いの最初としては良いと思われる。

ところで、初回もしくは二回目のミーティングまでで、対象組織の相談者から情報をヒアリングしてゆく過程で最も把握しにくい情報は、戦略情報化企画に当たる部分である。実際、経営戦略は、たとえそれがIT的視点から疑問視せざるを得ないものであったとしても、なんらかの形では存在している場合が多いし、調達に関わる情報も、情報システム部門や取引ベンダー等からの情報である程度把握できる。

しかし、戦略情報化企画にあたる部分に関しては、経営とITの中間に当たる部分であることもあって、対象組織内で統一的に把握している人物が少ないことが多い。

そこで、CobiTに網羅されているテーマが重要なポイントになってくる。

中長期的な視点から考えた場合、相談者などキーパーソン自身が自社のシステム部門の位置づけや問題点を客観的に把握する目を持つ事が重要となる。 また、相談者とITコーディネータとの間に共通の言語や価値観を持てるようになることも、その後のコミュニケーションを円滑に進める上で重要なポイントとなる。

０４　CobiT活用が効果的な対象
CobiTに網羅されているテーマが重要だといっても、そのままでは消化しにくい。テキストを渡して、「ハイ！このテキストで自己診断してください」と言って診断してもらうわけにはいかない。

CobiTを活用する場合、「企業を診断する」とか「採点してランクをつけ評価する」といったスタンスではなく、「ITに関わるテーマはこんなに広いのですが、何か手をつけておられますか？手を付けられそうですか？不安に思っていますか？」というスタンスで望むべきである。（ランク付けや採点して欲しがる対象組織もあるが、それを目的にしてはならない）

会社の戦略情報化企画を考えるときに、思いをめぐらせないといけない要素がいろいろあって、それらがなぜ重要なのか？なぜ情報システム部長では解決できず、社長や担当役員が関係するのか？ということを理解してもらう事にかなりの重点が置かれると考えたほうが良い。

すなわち、CobiTの活用は、対象組織の短期的な問題解決ではなく、体質改善に効果があるといえる。CobiTが対象としているのは、ITガバナンス成熟度であるため、改善による効果はじわじわとゆっくりと利いてくる。対象組織の柔軟性にもよるが、早くても半年、筆者の経験では数年単位の時間が必要では無いかと考えられる。 したがって、目の前の問題を今すぐ解決しようとしてITコーディネータを頼ってきている場合等には、CobiTの活用は控え、別の方法を検討すべきであろう。

効果は「じわじわとゆっくり利いてくる」と書いたが、これにもコツがある。ガバナンス成熟度を判定し、低いところを引き上げ、全体を平均的（レベル２?３程度）にそろえてやることが良く、情報処理の企画・計画から実施・運用までの見通しがかなりよくなる。（筆者には経験は無いが、場合によっては成熟度が飛びぬけてよい部分をわざと下げて、平均的にしてやる事が良い場合もあるかもしれない。）

ITコーディネートする際に、成熟度を上げて見通しがよくなった部分を上手に褒め、小さなことでも効率化に結びつけて行くことが必要であろう。

一方、対象組織の規模については、数人で構成される小規模事業者では難しいが、情報システム部門やシステム専任者が存在する規模の組織であればまったく問題無く、情報システム部門やシステム専任者が存在しない場合でも、CobiTの大半は活用できる。


０５　具体的なCobiTの活用方法のアウトライン
実際にCobiTを活用するにあたっては、以下の４つのステップを踏む。

ステップ１
初回ミーティングに先立って、作業内容と目的の提示を行う。すなわち、この先どのような領域について質問を行うか、どのような速度で話を進めてゆくか、何がアウトプットかを明示した資料を提出する。

ステップ２
週に９０分×２回、対象組織の相談者やキーパーソン（CIO相当者、経営企画部門）との定期ミーティングをアサインする。

ステップ３
週２回のうち１回目はヒアリング、２回目はヒアリング内容のまとめと次回の説明、という流れを作る。
筆者の場合は、ExcelでA3用紙1枚のミーティングシートを作成した。シートには、「今回のテーマ」「ヒアリング項目」を記述し、「現状」「あるべき姿」「対策」「課題」の欄を空欄にし、ミーティングの前日にメールで送付した。（２週目以降は、前週のヒアリング結果を元に、空欄部分を埋めてゆく）
ヒアリング項目は、各テーマのKPIやKGIを元に具体的な質問項目を記述しておいた。


ステップ４
最後に、報告書を作成する。

４つのステップは、本題のITコーディネートと並行して進める場合もあるし、ステップが完了してからITコーディネートに本格的に取り掛かる場合もあると思われる。

尚、ITコーディネートを進めてゆく中でのCobiTの活用にあたっては、先にも述べたように診断的なスタンスに立たないことである。あくまでITコーディネートをして、効果的なIT投資を促進させるのが目的である。採点はあくまでコミュニケーションを円滑にし、理解を共有するための道具に過ぎない。 CobiTのプロセス記載順序どおり、Planning & Organisationから始める必要は無いし、KPIやKGI等を事細かく追求する必要も無い。分厚い分析資料はできても、全体像を担当者と共有できなかったり、全体像がはっきり見えなければ失敗である。例えば…

・コストコントロールは厳しいが、事前調査コストも出さず、一発勝負をしがち
・IT化を社長の人脈に頼りすぎており、ITベンダーと長期的な関係構築が出来ない
・部門のIT化推進にばらつきがあり、強いところはより強く、弱いところは弱いままであり、全体最適が出来ていない
・運用がベンダー任せででたらめで、データの品質が悪い
・システム部門がITを理解していない経理部の下にあり、良い提案が途中で消えている

などなど。CobiTに照らして様々な角度から検討することによって色眼鏡を掛けずに、対象組織のITガバナンスを理解することができる。


０６　作業内容の提示
初回ミーティングに先立って、目的、作業内容、スケジュールを提示する。初回ミーティングでCobiTを使用する目的を明確にする。ただしCobiTという名称を出す必要は必ずしも無い。このフェーズでの目的は、経営と情報システムとの関係の健全性、成熟度をITCが理解し、相談者と認識を合わせることに設定する。

これによって、
　・情報システム投資の健全性やリスクがわかるようになる
　・場当たり的対応をしている部分、属人的な部分がわかるようになる
　・中長期戦略を立てる場合の判断材料となることを説明する。
作業の進め方は、対象組織の状況や相談者のポジション等により、様々な方法が考えられる。筆者が実施したケースでは、後述するように週に２回、９０分のヒアリングを情報企画室のトップを中心に時折情報システム部長を交えて約半年（２５週間）続けた。


０７　週２回のミーティング
週２回のうち１回目はヒアリング、２回目はヒアリング内容のまとめと次回の説明、という流れを作る。 週に２回×半年間という期間は実際には長く、また担当者にとってもITコーディネータにとっても辛い作業であるが、CobiTが取り扱う広範な分野をCIOに理解してもらうには消化するための時間が必要であり、決して長い時間ではない。

CobiTは、大きく４つの分野に分かれているが、後回しとなるのはシステム監査等の部分である。システム監査は重要な機能であるが、監査機能を持たない対象組織が多く、細かいヒアリングには入ってゆけない場合が多い。また、この時点で監査の重要性を説いても、あまり効果を持たない場合がある。

そこで、この監査部分は簡単に終わらせて、そのかわり、CobiTによる分析結果をどのように現場に還元してゆくかを相談する時間に当てたほうが良い。たとえば、対象組織の特性によって
　・トップダウンで統制力の強いプロジェクトを編成する
　・改善効果の高い部署から改革を断行し、実績を持って全社に広げてゆく
等、さまざまなシナリオが考えられる。

０８　まとめ資料
アウトプットは、戦略情報化企画書のような形や、情報活用成熟度評価レポートのような形が考えられる。CobiTをベースにした診断資料。あまり精密に行っても意味が無いと考える。学術論文ではないし、他の企業に公開するものでもない。社内改革を推進するために効果的なアウトプットかどうかが重要となる。

最終アウトプットとしては、戦略情報化企画書のような形や、情報活用成熟度評価レポートのような形が考えられる。検討すべきは、アウトプットの形では無く、そのレポートを対象組織に戻した場合、どのようなインパクトを与えるかということである。したがって、闇雲にレポートを提出するのではなく、相談者との間でレポートをどのようにリリースすれば最も良い効果を対象組織に与えるかを、ゆっくりと考えて提出すべきである。


０９　相談者の「気づき」
筆者のある事例の場合、相談者は経営企画部門や情報システム部門を監督する役員で、実質的なCIOであった。ただし、職歴からIT部門出身ではなかった。したがって、CobiTの名前は出さず、「こういう広範囲なテーマで定期的なヒアリングを持ちたい」と提案した。相談者は当初、「日次会計」の導入に熱心で、それが実現されば多くの経営課題（経営陣の意思決定の迅速化等）が解決されると考えていた。

しかし、CobiTによる面談を繰り返すうちに、相談者は日次会計システム導入というのが会社が持つリソースや情報の質を考えていない戦術であることに気づき始めた。

むやみにシステムの増強を行う前に、整備しておくべき重要なことが数多くあることに気づいてきた。そして、日次会計に取り組む前に、商品マスターや顧客マスターといった基本中の基本データを洗い直し、現在のシステムが５年以上にわたり蓄積し続けてきた情報と組み合わせて見えるような仕掛けを作るほうが重要であることが見えてきた。

様々な目新しいシステムを次々に提示することではなく、自組織を見つめ正しいポジショニングを図ることが結果としてよりよい経営計画とそれに続く戦略情報化企画を生むことになる。


１０　さいごに
CobiTをベースに情報システム部門のあり方を客観的に見つめ、標準化や測定化を進める土壌が出来始めると、ITコーディネートは非常に楽に進む。また、CobiTが提示するテーマは、ITILを利用する場合にも非常に有効であり、親和性が高い。ITコーディネータ諸氏にあっては、CobiTには500以上のCSF、KPI、KGIが含まれているので、こうしたノウハウをうまく活用し、対象組織の情報活用力の向上に努めていただきたい。

（以上）　約７０００文字

2005年2月16日 ITコーディネータ　0038332004C　太田垣　博嗣

ラベル: ITマネジメント