中堅・中小企業におけるCIOとしての役割とは

2007/03/31

 
■はじめに
 CIO(Chief Information Officer:情報化担当役員)という機能・人材は、大企業においては位置づけられ機能しているが、中堅・中小企業においては、存在していない企業や存在していても十分機能していない企業が多いのが実状である。しかし、今日、中堅・中小企業においても競争力を強化し勝ち残っていくためには戦略的なIT活用は必須であり、それを推進する人材も必要不可欠になってきている。
そこで、CIOとはどのような機能を果たさないといけないのか、そのポイントについてCIOを育成する研修の講師を担当した経験から説明したいと思う。

■CIOの役割
 CIOとは、Chief Information Officerの略で、最高情報責任者、情報化担当役員と訳されます。これまで経営者や役員はITについてわからない人が多く、また、情報システムを担当する責任者は経営のことがわからないという状況であったが、今日、戦略的な情報化の重要性が高まり、経営と情報化の両方がわかり戦略的情報化を推進統括する人材の必要性が益々高まっている。それは大企業のみならず、中堅・中小企業においても、競争優位を保つための経営戦略・経営改革のための戦略的情報化が重要となってきており、これを実行推進できる人材がいない現状から、その必要性が益々高まってきている。
では、CIOとはどのような役割をもつのだろうか。大きく次のように考える。

1.戦略的情報化は経営戦略ありきである。よって、経営戦略策定を経営者とともに
  実施する。その際、どこをIT化すれば、その成果目標達成に最も効果を発揮するかを
  検討する。
2.策定された経営戦略に基づき、戦略的情報化を策定する。
3.策定された戦略的情報化企画に基づき、プロジェクトとして計画から実行、そしてIT導入
  までマネージメントを行い、導入後も成果モニタリングを通して、企業が継続的成長発展
  をするようにPDCAサイクルを回すように推進する。

では、それぞれについて、方法論やスキル等の詳細はまた別の機会にするとして、ポイントを以下に述べる。

■経営戦略策定
1.成功の3条件
 会社が成功するためには、3つの条件があると考える。第1は会社の目標をしっかり定めることである。どういう会社を目指すのか、会社の成し遂げたいこと、ビジョンを描くことである。売上や利益目標など具体的に会社の目標を指し示すことが重要であり、経営者が示すべき目標である。

 第2は会社の現状を認識することである。現在、会社はどのような状態にあるのか、会社の強みは何か、弱みは何か。また、外部の環境変化により予想される機会はどんなものがあるか、逆に脅威となるものに何があるか。会社の内部環境・外部環境を分析することである。以外と自社の強み、弱みはわかっているようでわかっていないことが多い。あまりに近すぎて当たり前になっているので、それが他社から見て強みであっても、中からは気づかないことが多いものである。

 第3は目標へ向かう熱意・情熱である。いくら目標があっても、社長以下全社員がそこへ向かう熱意・情熱がなければ成し遂げられない。社長だけがあっても、あるいは社員だけがあってもできない。全員が目標を達成しようという熱意・情熱を持って取り組まなければならない。
これが成功するための3条件である。このうちのどれかひとつが欠けても成功することはできない。

2.4つの合意形成
  3つの条件が揃ったら、社長と社員全員が合意形成することが大事である。その大事な合意形成に4つあると考える。
 1つ目は目標である。社長も社員も全員がその目標を自分の目標として捉え、全員で向かうべく合意することである。
 2つ目は現状認識。会社の現状は「?である」ということを全員で正しく認識することである。
 3つ目は目標を達成するために、あるべき姿、達成すべき課題である。経営目標を達成するためには「?するべき」をしっかり定め、合意することである。
 4つ目はそれを実現するために「?する」という行動計画である。「?するべき」を掲げただけに終わらせないように、具体的な行動計画を立てて全員で合意することである。
 この4つをまとめたものが経営戦略企画書である。

 CIOの役割は、この3つの条件と4つの合意形成による経営戦略策定において、常に参画し何のための情報化であるかを十分認識し、情報化により最大の成果を挙げられるようにIT知識を踏まえ、提言していくことにある。ここをポイントとしておさえていないと何のためのIT化がわからなくなり、折角作っても経営に役立つシステムとならない。そのために常日頃から会社の状況を認識するとともに、経営とITの両方に関しての知識や世の中の動向について学習研鑽する必要がある。

■戦略的情報化企画
 上記により策定した経営戦略企画書に基づき、次に戦略的情報化企画を策定するのであるが、では、戦略的情報化とはどの様に考えればよいか。
それには、それぞれの企業のIT化のレベルによるが、まず、ITが動かないレベルであれば正しくシステムが動くレベルにしなければならない。実はまだまだ中堅・中小企業においては、システムが動かない、一部しか使っていないという企業が多くある。そのような企業は、まず最低限、システムが正しく動くレベルにしなければならない。次に業務を効率化するというレベルである。業務が効率化され人件費などコストが削減されるという効果を生むレベルである。
しかし、周りの企業も同じようにシステム化を行っている今日では、業務効率化に留まらず、業務改革と一体となった情報化が重要なのです。本来、あるべき業務プロセスの実現を促し、支援するためのIT活用です。業務改革とITは別々になされるものではなく、一体となってこそはじめて実現されるものです。
そのためには経営目標実現のためのあるべき業務プロセスをトップダウンで設計していかなければなりません。それをITによりスピーディに、より低コストに実現するのです。
よいシステムとは経営目標の達成に役立つシステムであり、経営課題の解決を促進し支援するシステムです。そして、経営目標に至る、あるべき姿や経営課題解決の達成度合い、指標をタイムリーかつ正確に捕捉するシステムなのです。

■プロジェクトマネージメント
 戦略的情報化企画が策定できると、それをプロジェクトとして計画から実行を行い、ITシステムの開発から本番稼働まで、目標を達成できるようにマネージメントし導かなければならない。またシステム導入後もシステムが正しく稼働しているか、当初の目標成果を達成できているかどうかをモニタリングしていく必要がある。そのためには、プロジェクトマネージメントについて、知識、スキル、ツールや技法を身につけプロジェクト活動に適用していかなければならない。
知識はPMBOKの知識体系が代表される。また、マネージメントスキルについては、リーダーシップやコミュニケーション力や交渉力などが挙げられる。ツールや技法では、CPMやWBS、EVMなどの様々なツールや技法があり、それぞれの用途・目的に応じて活用する。それぞれの具体内容は今回省略するが、これらの知識・スキル・ツール等を活用し、プロジェクトの品質、コスト、タイムをバランスさせながら、すべてのステークホルダーが納得と共通認識ができるように推進し、プロジェクト目標を達成させることが、CIOとしての重要な役割である。

■企業の推進エンジンたるCIO
 ここまで説明してきたように、CIOは経営者とともに経営戦略を策定し、経営目標を達成するための経営課題と行動計画をまとめ、戦略的情報化の企画および実行により経営目標を最も効果的に達成することが役割なのである。まさにその推進役であり、エンジンである。そのために必要な知識やスキルを身につけるのである。
特に今日、戦略的情報化が企業にとって経営目標達成のための重要成功要因になっていることが多く、戦略的情報化の構築そのものが経営目標達成には不可欠な状況において、CIOの役割はますます大きくなっている。私達ITCは、企業の継続的発展のためにいろいろな場面で支援をさせて頂くが、まさに外部からCIO的に支援をするといっても過言ではない。ITCの役割や期待がさらに大きくなっている中で、一つ一つの企業支援のITC活動が重要な役割を果たし、ITCの存在価値と知名度を高めていくものと確信している。


  ITコーディネータ/吉村 哲也

ラベル:


中小企業における内部統制とIT化について

2007/03/17

 
ITコーディネータ 武島 直行(No.00002711)

はじめに

 2008年J-SOX法の施行に伴い、昨今では金融業界のみならず、あらゆる業種の上場企業では当該法律に対応する方策や試行を通じて、“内部統制”という亡霊につきまとわれているように見受けられる。
一体、J-SOX法のどこが大変で、何故いまさらながらに“内部統制”なのか?
そもそも、上場するためには、一定の水準以上の財務力やビジネスモデル及び組織管理能力(内部統制も含む)が備わっていることを厳しく審査され、毎期毎に報告するというサイクルで運用されていたように記憶しているのだが...
一方で、上場企業をはじめとする世間では一流と称される大企業の騒動を間近に見ている中小企業においても他山の石的に傍観はしていれない、と考えるのは起業者を中心とした中小企業家の一致した見解と思われる。
 今日は、先に触れたJ-SOX法の対処についてではなく、中小企業をはじめとした、一般の企業において、なすべきことを定められたルール通りに行って、その行為が法規範にも触れていないことをチェックしていくサイクル作りをどのように考えて行えば良いか、に関して触れようと思う。

序論

“有るべき姿”とは、“なすべきこと”とは
どこの会社に伺っても大抵は「経営理念」や「経営方針」とか「社是」のようなその企業が企業活動するにあたって理念なり、目標とすることなり、方向性なりを簡単にまとめている。
これを実現するための社員の行動の標として「行動規範」や各種の規則・規程を作成している。最も、社長が行動規範だ、という企業も確かにある。いずれにせよ、何らかの物差しをもって活動を行っていることは確かである。
すなわち、企業の理念の中に“有るべき姿”を見出し、その活動の拠り所・考え方の中に“なすべきこと”を見出すことができそうである。
では、そこに見出す企業の姿が社会にどのように映っているのだろうか?
また、その活動の正当性はどのように確保されるのだろうか?
ここには、企業活動と社会との関連、例えばその企業の設立「意義」・「存在目的」がどのように意識され、どのように実践されているのか、ということが問われているように思う。
以降、企業活動の成り立ちから運営、ビジネスモデルを通じて、その企業の目指すところとITの位置づけといった流れで考察を進めていこうと思う。

本論1

「起業にあたって」
どのような規模の企業でも、初めから存在したわけではない。必ず、起業者がいて、少しずつそのビジネスモデルを確立していき、社会での認知度を上げて、今日の成功を収めている、と考える。
起業に当たって、その考え方は千差万別で、必ずしも社会への貢献や利益をもたらすことを目標としているとは言えない。単に、会社勤めが性に合わないから起業した、あるいは、自分のやりたいことをするために起業した、ということも十分に考えられる。ここに共通することは、いずれも既に確固としたビジネスモデルすなわち利益をあげる仕組みを見出し、その実践において単独あるいは少人数で行う用意がある、ということか。
だが、そのような会社?でもその事業規模が拡張するに及び、規模はともかく、組織を作り、これを運用していく過程を踏むことになろう。大方の起業はこの辺りで転換期を迎えるものと思う。
さて、話を元に戻そう。「起業」するにあたって、経営者は自分の思いを“経営理念”に活動の方向性を“経営方針”等にまとめていく。そうでなくとも、何らかの意思表示を“文字”に表すであろう。この時、社会に貢献する、あるいは、自社が繁栄することで社会に何らかの貢献ができる、などの言葉がキーワードになっているように感ずる。そうなるとその行動規範も反社会的にはならないだろうし、どこの企業も同様な内容になっているものと考える。
そうすると、それに基づいて活動している企業人が何故、反社会的行動を犯さなければならないのだろうか?
それとも、当該反社会的行為をそのように思えなくなってしまっているのだろうか?この点に関しては心理学的な犯罪学的な要素も多く、今回の考察には不向きと考えたく、ここでは割愛したい。

本論2

「ステークホルダー」

 今、巷で話題になっている上場企業の悩みの多くは株主をはじめとする利害関係者(ステークホルダー)との関係、特に株主との位置づけが俄に重要視されてきていることと、情報の公開に関する今まで経験したことのない責務への対応の仕方を模索していることにあるように感じられる。
 最近の事件の多くは、株主をはじめとして社会に対する情報公開(従来は財務報告が中心であった)における虚偽が中心で、これを企業ぐるみで行っている点である。あるいは、見た目を良くしたいが為に利益操作を行なう、という事件が多発しているようである。
 実は中小企業においてもこのことは他人事ではない。むしろ、大企業よりも如実な問題ではないか?
金融機関からの貸し付けを可能とするのは、その企業の財務体質であり、株式を公開していない限り財務報告は不要だが、どのような企業でも納税時には最低限の財務会計資料を提出しなければならず、収益をあげているか否かは明確になる。
先に触れたが、企業の存在意義によってはここで“待った”がかかると言っても過言ではない。
毎年赤字を出し続ければその企業では納税はおろか、社員に給与さえ支払えないこととなり、社会的にはその企業の存在価値は無くなっている。当然に淘汰されていくと思う。
これまでは、利害関係者として外部、例えば株主や出資者ばかりが取りざたされ、内部の利害関係者(社員等)や広い意味での外部、すなわち社会全体といった部分への考慮がなされていなかった場合が多い。
従って、世間にあるいは公的組織への報告すなわち財務報告に心血を注いできたと言っても過言ではなかろう。
ここでは、ありのままの姿を見せることが重要で、誤っても虚偽や隠し事は言語道断であるということは自明の理であるにもかかわらず、何故後を絶たないのであろうか?
利害関係者の枠を本来あるべき姿に捕らえ、その中で誠実に企業活動を行っていくにはどのようにすれば良いのか、これはあらゆる企業家の悩みなのではなかろうか。

本論3

「なすべきこと」

 企業は収益をあげることが史上の使命である。
 その収益は、企業がさすべきことを当然に行って、有るべき姿に向かっていくことで積み重ねていくことが理想であり、また、そうでなければ存在し得ないと前にも述べた。
では、「なすべきこと」とはどのような事でどのようにすれば見つけられるのであろうか?
 大相撲で“強い”力士には共通点がある。それぞれが、このように取り組めば九分九厘勝てる“形”を持っていることだ。別に必殺技ではない。立ち会い・組み方や得手不得手も含めて、この形に持ち込めば勝算が格段に上がる、という形。当然、最初からその“形”に持ち込めば楽に勝てる、ということだ。
 企業活動においても同じ事が言えないか?巷で言う、“ビジネスモデル”などはその類ではないかな。
その企業の得意技だけで勝負できれば、ほぼ負けることはないだろうが、相手も取り口は研究してくるし、相手の不得手を突いて勝負してくるだろう。そのためには、将棋のように相手の差し手を予想してそれぞれに対する差し手を考えて、如何に自分に有利な展開に変えていくか、すなわち、自分の得手の世界に引き込んでいけるか、がポイントで、そのための組織活動が「なすべきこと」であり、そのパターンこそが、当該企業の“ビジネスモデル”になっているのではないかと考える。
 したがって、“ビジネスモデル”が明確で判りやすい場合にはその遂行に関して、細かいルールや決め事を付加していけばよい。そうでない場合には、まずは自社の収益の構造を分析し、理解して、ここで勝負するための企業活動を探って、“決まった形”を創造する必要がある。それは、無理をすることを強いるのではなく、無理なく進められる内容、すなわち多少の余裕をもって行えることが望ましい。実際には想定通りには進まないもので、そのような場合に無理が効かないと絵に描いた餅に止まってしまうだろう。
 私もいろんな企業あるいは個人のビジネスモデルに遭遇してきた。別の機会にこれらを紹介できたらと思う。

まとめ

「自浄作用」

企業の行動原則に関して考察してきたが、人間全てが“善”であることは考えられない。いや、そうであるとしても24時間365日“善”であることには想像もつかない苦痛が伴うのではないか?残念ながら私も弱い人間で、1日の内で“善”で有り続ける時間は数時間としか言えない。“悪”になると言う意味ではないが、よく、“?しておけば、すれば良かった”と後悔する場面では“善”になりきれなかった事に対する反省が占める割合が多いように思う。
 どうすれば、この人間の欠陥?を補佐できよう?
 人間も千差万別であることを考慮すれば、全ての人間が同じ事、同じ機会に同じ苦痛や悩みを持っているとは考えがたく、須く個人差があって然り。
と言うことは、他人にチェックされたり、見て貰ったりするポイントがあっても良いように思う。
ここに相互チェックの意味合いが生まれるのかな。
人間の弱さの比重でこの相互チェックを何十にも重ねていけばよいのではないか。
これが内部統制に通じる考え方ではないかと思う。
要は“なすべきことを”あたりまえに行うことと、行えるように手順(ルール)を決めること、そして、この仕組みが円滑に動いていることを他人の目でチェックし、是正し、改善していくことが内部統制の考え方といっても良いように考え、私はその仕組み作りを中小企業家と行っていく考えである。


追記: この一連の仕組み作りの中でいかにしてIT技術を活用できるか、ITCとしては悩みの種ではある

ラベル:


「検証ユニット方式」の実践によるITC収益モデル例・4

2007/03/03

 
<はじめに>
 これまでの考察で、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がITCの収益モデルとしていかに有効であるかという3つの具体例を挙げた。
 ここまでは、検証ユニットの初期段階(1回転めから3回転めくらいまで)に比較的重点を置いてきたが、今回は、ユニットが4回転め、あるいは5回転め、すなわちIT化のプロセスが中盤以降にさしかったD社(不動産の有効活用支援)の事例を取り上げてみたい。
 Y氏が関与しているのは、D社の事業の中でも特に有人立体駐車場の管理事業である。業界全体としてもほとんどIT化の顧みられない分野で、せいぜいPOSシステムを導入するくらいしかIT活用の取っかかりはないと思われた。
 D社における検証ユニットの1回転めから3回転めくらいまでの経緯は、これまでの3つの事例とほぼ同じであるので、本事例ではその詳細は省略し、4回転め以降、Y氏の関与を通じて、D社の経営トップがどのようにITを企業文化として深化させていったか、そのプロセスを追うことにする。 

<1回転めから3回転めまでの概要>
 有人立体駐車場では、料金計算やPOSレジをきちんとシステム化しているところは極めて少数派である。平面の駐車場は、無人化することによって人件費節約効果が大きいため、システム化が進んだのであるが、立体駐車場のほうは、安全管理面の事情から「どうせ人が必要なんだから人にやらせたらよい」という発想になっていたのである。
 Y氏は、このシステム化の遅れに注目し、料金計算とPOSレジ機能を一体化したシステムの導入をD社に提案し、その開発過程においてベンダーを指揮し、複数駐車場の顧客(車両)一元管理を軌道に乗せた。2回転めでは、利用者の利便向上に大きく寄与するマイレージポイント制の導入を提案、3回転めにはタイムカードシステムまでを統合した労務管理システムの開発をプロデュースした。そのプロセスがすべて順調に推移したために、D社の経営者は、ITの有効性を高く評価し、さらなる活用方法を自ら模索するまでになったのである。 

<4回転めの留意点>
 検証ユニットも3回転めを終えるころになると、どんな懐疑的な経営者であっても、IT推進者たるITCをかなり評価してくれるようになっている。疑り深ければ疑り深いほど、目の前で実際にやってみせたときの「目から鱗」状態は劇的であるともいえるのである。
 そうすると今度は、特にITCがITの効用について説得しなくても、「ITでもっと他にやれることはないか」と経営者自身が自発的に考える姿勢になってくる。「自律成長過程」とも呼ぶべきフェイズ、ITCにとってはとても仕事がやりやすくなる時期がくるのである。
 経営者は、これまで否定していた「流行りのツール」を、「華美な宣伝文句」に踊らされて、突如としていろいろ試してみたくなったりすることになる。ITCとしては、これはこれで困りものなので、うまいこと手綱を締めてかかる必要が出てくるのである。もちろん、本当に良いツールであれば、経営者といっしょになって積極的に検討すべきなのは言うまでもないが、“まがい物”も多いので要注意である。
 D社で社長が自ら取りかかったのが、ネット経由で動作するPOSレジの拡張機能としてのウェブカメラであった。Y氏はカメラには疎いので、はじめは導入に消極的だったが、D社社長の言うには、駐車場のオーナーは、防犯対策としてのカメラには非常に興味を持つのだということであった。さらにD社社長は、自社の駐車場利用者がネットで一元管理できる強みを活かして、「ある駐車場で月極契約をすると、別の駐車場の時間貸しが無料になる仕組み」を考え出した。事業を営んでいないと思いつかない一種の発明(実際にも特許出願中)といえ、これにはY氏も舌を巻いた。

<4回転めの仮説>
 4回転め(5回転め以降も同様)に入ると、経営トップがすでに納得し、自ら推進するフェイズに入るのであるから、ある意味(経営者からITCとしての手腕を評価していただくという意味)では、検証作業は重要ではなくなる。失敗は失敗として、そこから学び、企業文化としてITが定着しているお手伝いをするのがITCのミッションになってくるという具合に、仕事の中味が変質してくるはずである。利益向上に寄与すればIT化は成功、寄与できなければ失敗という、杓子定規な判断から脱皮しなければならないのである。事実、Y氏が関与して以降、D社の業績は順調に伸びており、もはやY氏自身も、ITの実効性という面での評価は求めることもなかった。
 そこでY氏は、D社社長に、経済産業省の推進事業である「IT経営百選」に応募してみることを勧めた。「これまで積み上げてきた自社のIT文化がいかにすばらしいか、あるいは、どこが欠けているか」に関して、外部の評価を受けてみることを勧めたのである。
 あたりまえのことであるが、単に儲かっているとか儲かっていないとかいう基準では「IT経営百選」には入れない。ITを有効に活用して経営の改善に結びつけているか否かが有識者によってチェックされるのである。もしこれで入賞できたとすれば、D社のIT化は一過性のものではなく、企業に文化として根づいていることが客観的にも裏付けられることになる。この提案はD社社長にも快く受け入れられ、D社の「IT経営百選」応募が決まった。 

<結論>
 もしD社が「百選」から漏れていたら、Y氏の提案してきた数々の仕組みは「儲けにはつながっているけれど、会社の文化としては根づいてない」という評価になったわけである。しかしY氏の確信どおり、D社は、「IT経営百選」において最優秀企業に選ばれ、社名とともに評価項目毎の得点までが全国に公表された。今後のIT化の貴重な指針が得られたと、D社社長も至極ご満悦だったのは想像に難くない。
 このように「検証ユニット」にしたがって、ITCが、ユーザー(企業経営者)の猜疑心を無理なく少しずつほぐすようにIT化を進めていくと、当然の流れとして企業IT化は自律成長過程に入る。またそれを外側から歓迎して支えてくれるようなムードや枠組みも、ちゃんと国が用意してくれているわけである。さすが、“e?Japan”を標榜するだけのことはあると言うべきであろう。
 ITCが、国策としてのIT化推進の流れをしっかりと踏まえ、それに呼応するかたちで、中小企業企業のIT化を進めていくならば、“三方良し”の結果が待っている。「検証ユニット」の初期の段階では、ITCは単なる便利ツールとしてITを企業に伝えてよいのであるが、中盤以降では、経営者のマインドの変化も読みながら、企業文化としてITを根づかせていく意識が欠かせない。本事例はその教訓となる好例であろう。


ITコーディネータ/永田祥造

ラベル: ,


成功事例にもとづくITCのためのERP導入実務(その1)

2007/02/18

 
1.はじめに

  ITコーディネータとしての職務上、顧客企業からERP導入の支援を求められることは珍しくはないはずです。そのときみなさんはどのように顧客企業を支援していかれるでしょうか。もちろん、企業規模、導入目的、企業文化、業種、予算規模など背景の相違により、その進め方はさまざまでしょう。

  筆者は、最近自社におけるERP導入を統括し、幸い成功裏にかつこの種のシステム導入としては短期間に完成させることができました。このプロジェクトの成功要因(ITC的に表現すると“CSF”)を振り返って考えてみますと、一つひとつは「当たり前のことを実行する」に尽きます。しかしながら、実際の多くのERP導入は、当たり前のことを当たり前にできなかったために失敗したのではないでしょうか。当たり前のことを行って、あるいは行わせて、プロジェクトをリードする手腕こそITコーディネータにまず求められる責務であると筆者は考えています。
類似した業務に取り組まれるみなさんの参考となれば幸いです。

  なお、本稿では、具体的な名称や数値、商品名などは可能な限り伏せさせていただきました。より具体的な情報を求められる方は「まいど!フォーラム」を通してご遠慮なくお問い合わせください。

2.本稿で扱うフェーズ

  本稿では、まずERP導入プロジェクトの立上げからERP選定までのフェーズ進め方を述べます。その後、社内承認を経て実際の導入へと進むわけですが、後のフェーズに関しては続編に記述します。

3.事例対象とした企業とプロジェクトの概要

  以下は、筆者が取り組んだERP導入について、規模観をもっていただくための情報です。

(企業概要)
 企業規模: 年間売上げ 約600億円、 従業員数 1,500名、 
 業種: 
 製造業(工場設備)対象のエンジニアリングと建設工事、システム開発/保守

(プロジェクト概要)
 期間: プロジェクト立上げ から ERP選定 まで 4ヶ月
      ERP発注 から システム稼動 まで 9ヶ月
 対象業務: 
  事業の原価管理、調達、営業、経理、および決裁にかかわるワークフロー

(付帯状況)
 システムの専門部署を除いて、社内全般にITリテラシーは非常に低い。
 2社合併に伴う基幹システムの統合を兼ねる。
 合併前の2社ではそれぞれオフィスコンピュータで原価管理、調達、経理などを
 処理していた。

4.プロジェクトの立上げ  ・・・・・ プロジェクトとその方針を徹底的に周知する ・・・・・

  システム再構築の意思表明がトップから出されたのを受けて、対象、構築期間、進め方の手順など、企画書を作成しました。そして、社長が企画書を承認しプロジェクトをスタートさせました。

  プロジェクト立上げの宣言には次の項目を含めました。
 1) ERP導入の目的(原価管理の精度改善、仕掛り品の減少、など)
 2) 導入方針
  (ベストプラクティスを導入し自社の業務プロセスを改善する、など)
 3) 社長をトップに置いたプロジェクト体制と実務メンバーの明示と周知
 4) カットオーバー日を明示した工程
 5) 概略の予算

  プロジェクトの周知について: プロジェクトの立上げは社長自ら経営会議など社内で公式に宣言します。当該プロジェクトを知らないことが企業内では職務怠慢と見られるまでに、徹底したプロジェクトへの認知を、役員や幹部社員にしてもらう必要があるからです。ERP導入はトップダウンで扱うべき性格を本質的に持っています。なぜなら、多くの社員にとって業務の仕方は変わらないことが心地よく、変えることは個々の社員から必ず抵抗を受けるからです。ITCにとって社長以下の役員や幹部からの支持を得続けることがプロジェクトの成功に必須です。企業幹部にも、当然ですが、プロジェクトに対する義務感と責務感を持ってもらわなければなりません。プロジェクトへの協力義務について、社長や役員の口から折に触れて全社員に繰り返し発言されるようにITコーディネータが仕掛けることも大切です。
  1)と2)について:  プロジェクトの目的と方針はプロジェクト完遂まで絶対にぐらつかせてはなりません。事前に十分な議論と意識合わせをITコーディネータが社長および担当役員と行っておくことが大切です。またプロジェクトの途中でも目的と方針の再確認を社長以下と繰り返し行います。プロジェクト遂行の途中で必ず抵抗勢力が現れます。それをはねつける力を推進者はあらかじめ用意しておく必要があります。目的と方針の固守はそのための非常に重要な要素です。プロジェクトへの非協力的な姿勢、非協力社員は個人の人事的評価に悪影響を受けることをさえ社員と管理職に認識させる場合もあってよいと思います。
  3)について:  プロジェクトに直接参加する実務メンバーは社内で広く認知されるようにします。核となるプロジェクトメンバーは社内各部署の実務キーマンとうまくコミュニケーションの取れる専任者であるべきです。企業内各部署からも、兼任でよいから、部署要求を整理しまとめる責任を負う担当者をプロジェクトに加えてもらいます。
  4)について:  工程はリーズナブルである限り厳しい短期工程を設定し、かつプロジェクトメンバーで工程厳守の高い認識を共有します。これによりプロジェクトは常に緊張感を保って進められます。また、短期間であることは導入予算低減させるためにも非常に有効です。
  5)について:  概略予算は、調査により同規模他企業の事例を参考にセットします。他社事例を調べることは、ここで示す予算に説得力を持たすために必要なことです。プロジェクトに用意できる金額が他社事例の金額と比べて桁違いに合わなければ、計画を白紙に戻して組みなおすことが賢明です。

5.対象業務の分析   ・・・・・ ERPで何をさせるのか把握する ・・・・・

  このフェーズではERPでカバーされるべき社内業務を分析し文書化しました。これをここでは「業務プロセス分析書」と呼びます。今回の場合、プロジェクト立上げ後1ヶ月をかけて業務プロセス分析書を作りました。
  業務プロセス分析書では、現状の業務とあるべき業務をフロー図などに図式化します。この目的は、ERPで何を行わなければならないか、行わせたいか、ERPで何をさせるのかをプロジェクトメンバー全員が知るためです。ERPを導入し始めたものの、何をさせたいか具体的要求を表現できず、一方で「使いにくい」の大合唱に遭遇し、結局ERP導入が途中頓挫することはよく起こります。社内業務のどこをERPというツールに頼るのか、メンバーが認識を共有する必要があります。そのための図書が「業務プロセス分析書」です。ITコーディネータはこの文書作成を指導し、監査し、まとめさせます。フローは、通常多部門間にまたがる形になるため、部門それぞれがどのタイミングでどのような処理をするか記述させます。一例として、受注から設計、製作、納入、調整、完成検査、検収、売上げにいたる一連の社内業務プロセスがありました。 
  業務プロセス分析書に対しては、自らが作った要求という意識を対象全部門とプロジェクトメンバーに持ってもらいます。業務プロセス分析書をITコーディネータが勝手に作ったとか、自分たちは内容をよく理解していない、などと言わせてはなりません。自分の責任で作った自分たちのための分析であるという意識を企業の全部署に持たせるよう誘導します。
  なお、業務プロセス分析書において、いくつかよくある異常処理(例: 返品、紛失、クレーム処理、受注前の先行処置、など)にも触れておきます。この時点ですべてを記述する必要はありませんが、不完全でも異常処理を認識しておくことが重要です。
 
6.RFP作成とベンダー評価   ・・・・・ ERPベンダーの知恵をフルに使う ・・・・・

  次にERPベンダーに対してRFP(Request For Proposal)を提示しました。ここでRFPの内容とは、前フェーズで作成した企業の業務プロセス分析書です。ERPベンダーの中から企業規模や実績、知名度からいくつかの候補を抽出し、そこに対して業務プロセス分析書を説明します。ERPベンダーには、当社が説明した業務を自社製品を使ってどう実現するか提案させました。このフェーズに2ヶ月を要しました。
  これは非常に重要な進め方です。一言にERPといっても多くの製品が市場に溢れており、その中のどれが自社の業務に合うか使う側(顧客企業)やITコーディネータが自分で判断することは非常に困難です。業務分析書をERPベンダーに提示してベンダー側に考えてもらうことが時間の節約と正しい評価に非常に有効です。
  このフェーズでは次のようにプロジェクトを進めました。
 1) ERPベンダーからの提案書と見積書の提出
 2) 1次評価をして選考対象を絞ること
 3) 選考に残ったERPベンダーの製品を用いたデモ
 4) ERPベンダーの製品を既に導入した企業への訪問調査
 5) 予算と社内事情を考慮してERPでカバーする業務範囲の見直し
 6) ERPベンダーへの追加質問、見積範囲のレベルあわせ
 7) ERP評価表作成

  1)について:  ERPベンダーからの提案書には、どの範囲が当該ERPの標準機能によってカバーされ、どの範囲にアドオン(=追加開発)が必要かを明示させます。いわば荒いフィット/ギャップ分析をここで行っていることになります。言うまでも無く、アドオンが多ければ多いほど初期導入の費用が増加します。期間も余分に必要となります。アドオンされた部分でのバグ検証などシステムの信頼性も落ちます。導入後のメンテナンス、バージョンアップにも手間と時間と費用が余分にかかります。したがって、可能ならばアドオンなして導入できることが望ましいはずです。
  2)について:  選考対象を絞るのは、これ以降のフェーズでの評価の手間と日数を少しでも少なくするためです。
  3)について:  デモでは業務プロセス分析書に沿った業務イメージを各ERPベンダーに製品を使って実際に示してもらいます。各部署から派遣された兼務のメンバーも必ずデモに出席させます。このERP製品の評価のフェーズにおいても、限られたプロジェクト専任メンバーだけでなく、各部署からプロジェクトに入ったすべてのメンバーに参加意識を持たせる必要があります。そしてそれぞれのメンバーに判断を示させます。後のフェーズで、「自分の知らないところでERPを選んだ」と言わせないための重要な手順です。
  4)について:  導入企業訪問では、ERPの評判、導入時に生じた問題、問題に対する対策の工夫など、後フェーズで有効な情報を集めることができます。オリジナルのERPに問題があるとして、それをどのようにクリアできるのか目処を立てることも製品評価の項目の一つとなります。
  5)について:  ERPベンダーのデモや仕様、価格など総合的に判断して、本プロジェクトでどこまでの業務範囲をERPでカバーするか決断します。予算、期間、業務プロセス分析書とのギャップ、などを考えます。すべてのERPベンダーの提案で「業務プロセス分析書」とのギャップが大きいプロセスがあれば、今回の対象業務範囲から思い切って除外する決断も必要です。
  6)について:  見積範囲の精査など細かな詰めは専任メンバーとITコーディネータの連携で処理します。レベル合わせのための見積範囲調整、追加質問などを行って公平さを確保し、また技術課題の対処方法も提出してもらいます。
  そして、7)のERP評価表を作成します。

7.ERP評価表とベンダー決定   ・・・・・ 目的/方針を固守しつつ決める ・・・・・

  いよいよ導入するERPの選択について意思決定を行う段階となりなます。
評価項目は次のようなポイントとしました。
 1) 価格
 2) 当該ERPの特徴と今回の導入方針や目的との合致度当該ERPを選ぶことが、固持すべき当初方針や目的に合致した選択となるかどうか。
 3) アドオンのソフト製作量の大小、およびフィット/ギャップの評価。ERPの仕様や機能に要求との差異や問題がある場合にはその解決方策と費用・工期の概要
 4) 製品デモに対するプロジェクトメンバーからの評価
 5) ベンダー技術者の経験、資質と人数(=人的動員力)。ERP構築時に万一問題が発生した場合、要員を増強してリカバリーできるポテンシャルを評価する。
 6) ベンダー企業とERP製品の継続性。ベンダーが倒産する、ERP製品へのサポートを止める、などのリスク評価。

  これらの評価表を作成し、まずプロジェクトメンバー内での意識統一を行います。これも、「他のだれかが勝手に決めた。」という意識を持たせないためです。プロジェクトメンバーその意識合わせに基づいて書面にし、社内承認手続きを行います。

8.ERP選定までの結び

  以上が、ERP選定までに踏んできた各フェーズと進め方のポイントです。筆者の場合には、プロジェクトの立上げを宣言してから社内承認まで4ヶ月を要しました。選考対象としたベンダーは、当初6社程度。本格的な提案要請は3社に対して行い、最終選考は2社に絞りました。
  内容を見ていただくとわかるように、プロジェクトの立上げ、業務の分析、RFPの作成、ベンダー決定、それぞれに若干の工夫をしつつも、当たり前のことを手順を踏んで行ったに過ぎません。冒頭に述べたとおりです。目的や方針を振れさせたりせず、プロジェクトメンバー全員の当事者意識を維持しつつ、当たり前の手順や行動を着実に実行することがプロジェクトを成功裏に完遂するために必要であることを、改めて強調しておきたいと思います。

             ITコーディネータ 松下 悟 (まいど!フォーラム メンバー)

ラベル: , ,


賦課作業データについての原票イメージング化について

 
地方自治体の賦課作業をおこなうに当たって、その原始データとして使用する各種原票には給与支払い報告書、確定申告書、住民税申告書、年金資料などがあるが、その数が膨大であり且つ紙媒体であるため、その運用管理が大変である。それらの扱いについては、まず賦課準備作業としてそれらのデータについてエントリー作業をおこない、各種資料マスタを作成する。そして全てのデータを入力し終わった時点で、それらのデータを人単位にシステム的に合算するわけであるが、システムでは対処しきれない様々なパターンが存在するため、システム合算後のデータを再度チエックすることになり、その際にはもとの原票に戻り確認することになる。また賦課作業が終わった後にも、修正行為や住民からの問い合わせなどにより、原票に戻って調査することが発生する。
実際に某自治体においては、およそ次のような問題を抱えていた。

● 1月?3月の間に日々発生するこれら原票の並べ替え、入替え作業に時間がかかり、臨時職員採用や時間外勤務のコスト増につながっていた。(それらの原票は合算後の確認行為のめに、事業所別であったり世帯別であったりとその利用目的に応じて並べ変えていた。)
● 課税作業中の確認事項などで元の原票に戻る際や、住民からの問い合わせ時に原票に戻る際、資料を探さなければならなかった。また課税年度については基本的に最大7年度まで遡って事務運用をおこなう必要があるため、資料検索に時間がかかって対応が遅れ、住民サービスの低下につながっていた。
● 膨大な資料ゆえ万一の紛失などによる情報漏洩、個人情報の保護が懸念された。
● これだけの資料を最大7年度分保管するスペースを確保することは限界であったし、またそれらにかかる保管スペースコスト、バインダーコストがかかった。さらに新庁舎建設が差し迫っており、新執務室には近くに必要なスペースが確保できないという懸念事項があった。

以上のような問題を解決すべく原票をイメージ化し、デジタルデータとしてサーバに取り込みパソコン上で管理するよう考えた。
これは社会保険庁や事業所及び住民などより提出された各種課税原票を、カラースキャナ等を用いて画像処理、デジタルイメージ管理を行い仕分け、管理をパソコン上で行うものである。これによりイメージシステムに登録されたデータは問い合わせの迅速化が図れ、また付加機能としてのメモ機能、付箋機能などにより職員の伝達漏れを防止でき、それらの結果、職員には本来の知的作業(課税業務)に専念できることが期待できる。また申告受付業務の際にも過年度の原票をパソコンから参照、確認することにより、より迅速な受付作業ができる。また各出張所でも日替わりで申告受付をおこなっており、出先では過年度の原票確認作業が出来ず不自由であったが、その際にはデータを取り込んだパソコンを申告会場に持ち込むことにより解決できる。また最大の懸案事項であった原票の保管スペースについても、7年分の資料をキャビネットに保管する必要は無くなり、原票は全てイメージスキャン後に倉庫に一括保管すればよい。
以上の経緯によって実際にイメージシステムを導入した結果、次のような効果が得られた。

● 課税資料の仕分けについては手作業による世帯別、町別の並べ替え作業により、仕分けロス・時間ロスが発生していたが、イメージスキャン後は通し番号ナンバリング付きの課税資料を、その番号順(スキャン順)に保管することができ大幅な時間短縮、人的余裕が生まれた。
● ナンバリングについては原票のデータパンチ後に世帯番号順に並べるため、各原票に世帯番号シールを貼っていたが、そもそも並べる必要性が無くなったため、それらの事務作業は無くなった。尚、元原票に戻る必要性が発生した場合いには、スキャン時に通し番号をナンバリングすることにより解決した。
● 台帳綴じについても同様にその必要性が無くなった。
● 確定申告書に添付されていた根拠資料のコピーについて、それらも同時スキャンすることによりその手間が省けた。
● 賦課確認作業については、各種原票を合算した結果について確認作業をおこなうことになるが、従来は世帯単位で綴じた原票に戻って確認作業をおこなっていた。その際、それらの資料を探す手間、資料を綴った台帳を広げるスペースなどの問題があったが、導入後はパソコン上から即座に対象資料を検索し確認することができ、またスペース的な問題もなくなった。さらに原票での簿冊管理の場合、他の職員が簿冊を使用中の時には「待ち」が発生していたが、イメージ管理の場合は「待つ」必要がなくなった。
● 原票保管について従来は2年度分を近くの執務室に、またそれ以前のものは倉庫に保管していたものが、全て倉庫保管になりスペースの有効利用が可能となった。
● 賦課作業後の住民からの問い合わせについても、従来は世帯単位で綴じた原票に戻って確認作業をおこなっており、それらの資料を探す手間、資料を綴った台帳を広げるスペースなどの問題があったが、これについても導入後はパソコン上から即座に対象資料を検索し確認することができ、またスペース的な問題も無くなった。

以上このシステムを導入した得られた効果として、賦課作業時期の臨時職員の削減などによる事務作業の軽減、及び職員が本来の知的作業に専念できる環境になったことによる賦課作業の正確性、また住民サービスの質が向上したことである。
また最後に今後の課題として、現在エントリー作業(パンチ作業)について、その精度や納期などの問題点があるため、次のステップとしてスキャン時にデータを読み取り、エントリーデータとして利用しようという試みを考えている。例えば給与支払い報告書をとると基本的なレイアウトは同様であるが、事業所毎に微妙な差異も見られ、そういった問題を解決していきたい。そうなればさらに、原票データの精度向上やパンチ工程の短縮につながり、職員にとっては余裕をもったスケジュールになることから、より正確な賦課作業事務が期待でき、結果として質の高い住民サービスが生まれるはずである。
  【ITコーディネータ/石井 啓視】

ラベル:


なぜチェンジリーダーが育たないのか

2007/02/17

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

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

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

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


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

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

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

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

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

2)基幹システム再構築プロジェクト
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 次は、IT部門での事例である。

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

(ITコーディネ?タ/植松栄介)

ラベル:


自治体向け基幹システムの共同利用について

 
近年の地方自治体においては国からの交付金が年々減少傾向にあり、また国からの税源移譲もあり、各自治体はそれぞれ自主自立の運営を期待されているという現状がある。そういった背景があり近年の地方自治体は、その運営において様々な知恵を絞り経費削減に努めている。しかし最近は様々な法改正や新法、また事務改善その他の要望による修正経費などにより、その開発コスト及び運用コストが肥大化しているのが現状である。

某自治体の基幹系システムは平成11年から運用してきたが、老朽化や行政の多様化に対応するため見直し時期を迎えた。近年は情報化資産の増大や情報システム群の維持管理運用、個人情報保護やセキュリティ対策により今後、情報化投資額の増加は避けられない状況となってきていた。また法改正、新規追加案件などのシステム改修が例年の如く発生しており、システムが継ぎ足しで歪に肥大化し保守性にも問題があった。それらはおおよそ次のようなものであった。

・情報システム群の構築費、維持管理コストの増大
・複雑化するシステム群への対応(電子XXシステム等のフロント系システムと既存のバックシステムとの連携)
・ 高度な情報セキュリティ対応及び災害対策
・ 行政サービス時間の延長、サービス拠点の拡張

このような状況はどこでも多かれ少なかれあり、他自治体でも同様な問題に直面している。これらの課題を解決するために複数自治体による情報システム群の共同処理・共同運営が総務省を始め多くのアナリストで提唱されているが、システムの共同処理・共同運営には様々な解決事項が山積しており、なかなか実現できない状況である。以下にその問題点を示す。

・共同処理を運営する組織体(一部事務組合、協議会等)の設置の合意形成に時間がかかる。
・各自治体の情報化計画に時間的差異が発生しているため、先行投資を含む二重投資が発生する自治体がでる。
・各自治体が利用しているシステムが違う。また各自治体独自のカスタマイズがシステム化されているため、標準パッケージ化ができない。
・業務手順の標準化が必要(各自治体において、今からシステム化される業務の標準化は比較的容易だが、過去からシステム化されている業務の手順化は難しい)
・情報システム群を運用できる高いセキュリティを確保した建物、設備を用意しなければならない。
・ 共同運用をおこなうための専門的技術を持った人員確保が必要(各自治体からの出向)

これらのことにより、共同で運用するための情報センター(仮称)なるものが必要であると判断し、もともと耐震やセキュリティ面などで条件をみたしている弊社のバッチセンターをそれらに充てることとし、また運用面をトータルサポートなどして共同利用できる体制を整え、利用するにあたってのハードルを低くした。最近の複雑化、高度化する情報システム群への情報化投資は、従来の業務システムへの直接経費よりも個人情報セキュリティ対策、住民サービスの延長に伴う情報システムの運用時間拡大等の維持管理経費を増大させている。システムの維持管理費は、システムベンダ等に支払う直接経費と自治体が用意する間接経費に別れるが、今後の情報システム投資効果はシステムの構築及び維持管理の直接経費だけでなく、システムの運用・管理に係る職員の負担度、サーバー室等の設備費も情報化投資効果として考慮する必要性があり、次のようなメリットがあると考えられる。

・情報システムの維持管理専門技術者を自前で養成していかなくても良いため、教育費を含めた総人件費が負えられる。
・様々な分野の専門技術者が情報システム群と同一場所に居るため、障害発生時の対応が早い。
・災害対策をおこなっている建物や高いセキュリティを確保したサーバー室、及び安全で安定した運転ができる設備を自前で用意する必要がない。
・ソフトウエア、ハードウエア、OS、データベース、後処理加工装置等のコンピュータ資源が複数自治体で共同利用するため、1自治体あたりのコストが低くなる。
・行政サービス時間の延長にともない情報システム群の稼働時間が延長されるが、情報センター集中型で監視をおこなうため人件費コストが抑制される。
・電子XX業務等のフロント側システムと、住民情報システム等のバック側システムとの連携が情報センターにおいて集中管理できる。

以上それらの基盤構築として同規模自治体での共同処理・共同運用、情報システムのアウンソーシング(設備、維持管理のアウトソーシング)を企画、提案したところである。具体的には情報センターで共同運用化する処理として大きく「監視」「運用」「設備」「技術者」といったものがある。また共同利用化する環境についてハードウエア環境とソフトウエア環境について、レイヤー毎にまず?セキュリティ層ではそれぞれファイアウォール管理サーバーの設置及びアクセス管理システム、次にアプリケーション層としてはそれぞれユーザー毎のAPサーバー群及びユーザー毎の手順、さらにデータベース層としてはそれぞれ主従DBサーバーと統括ストレージ及びミドルウエアシステムとデータベースとした。
今回これらの提案が受け入れられ、とりあえずファーストユーザーとして船出をすることになったが、その運用手順などは今後、熟慮していくことになる。ぜひともうまく起動に乗せ、近隣自治体に賛同を呼びかけていきたい。
      【ITコーディネータ/石井 啓視】

ラベル:


「検証ユニット方式」の実践によるITC収益モデル例・3

 
<はじめに>
 これまでの考察で、ITCが企業と契約を結ぶに至るプロセスにおいて、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がいかに役立つか、その実践的手法について明らかにしてきた。
 前回は、「検証ユニット方式」実践の第1回転めに専門家派遣制度(各都道府県に設置された中小企業支援センター等が実施する助成事業)を活用し、より潤滑に契約獲得に結びついた事例を紹介した。
 今回の事例もまた、専門家派遣制度を活用した契約獲得例であるが、第2回転め以降に経済産業省の「IT活用型経営革新モデル事業」という別の公的な助成制度の活用を組み合わせて、顧客便益を大幅に向上させているところに着目いただきたい。
 毎度のことであるが、仕事の発端はささいなキッカケである。本事例(C社=小売業とする)は、ITCのY氏が、共通の知人であるVさんから、販売管理システムの刷新を検討しているC社のマネージャを紹介されるところから始まる。

<1回転めの経過>
 1回転めの留意点については、前回までの考察とほぼ同じであるので、詳しいことは省略するが、肝要なことはやはり、「はじめに成果ありき」を鉄則して、第1回転めにできるだけ相手にお金を使わせないことである。信用創造に重点を置く初期段階にあっては、特に相手が価値や意味を理解できない箇所にお金をかけさせるべきではない。
 本事例では、Y氏は専門家派遣制度の枠内で助言事業を行ったわけであるが、C社が新たに購入しようとしていたPOSシステムについて、C社経営陣の意思決定を覆す決定的なレポートを作成した。そのあらましは以下のとおりである──。
 C社はL社製のPOSシステムを採用していた。が、各端末がC社の直営する各店舗でスタンドアロンで稼働していたために、売上の情報を集めるのに、数年前まではフロッピーディスクを回収しなければならなかった。ここ2?3年は、売上情報をネット上で稼働する別のASPシステムに入力し直してサマリーだけは本社で把握できるようになったが、単品管理はできておらず、POSとは名ばかりになっていた。
 それでもC社は、新規出店のたびにL社製のシステムを購入していた。同じメーカーのもので統一しておくほうがなにかと安心だというのが経営トップの判断根拠であった。他メーカーのシステムが混在すると、予測不能の混乱が起こりそうで不安だというわけであるが、これがY氏の目には明らかに不合理に映ったのである。
 L社のPOSは、スタンドアロンで動いているのだし、導入年代が異なるためにソフトのバージョンがちがっているものもある。日々の売上実績はそもそも別のシステムに店長が手入力し直している現状では、他メーカーのシステムが混在したところで大した混乱が起きるはずがなかった。
 そこでY氏は、将来は全店の業績をネット上で即時に一元的に管理することを命題として、それが可能なシステムにリプレースすることをC社に進言した。そのニーズを完全に満たすシステムはその時点では存在しなかったが、開発できそうなソフトハウス(M社とする)はあった。うまくいけば節約効果は数百万円に上ることが素人目にも明らかであった。そこで、1回転めの検証ステップとして、まずC社でいちばん規模の小さい店舗にM社のPOSシステムを採用し、L社にこだわる必要がまったくないことを確認したのである。

<2回転めの経過>
 2回転めの留意点についても前回までの考察とほぼ同じである。すなわち、1回転めで得られた小さな信用と小さな報酬をテコに、もうひとまわり大きな信用と報酬につなげるという点である。
 1回転めの助言活動で、数百万円に上る目に見える節約効果を実現したY氏は、C社のニーズを完全に満たすシステムをM社に開発させることを提案することになるのであるが、このときにY氏は、経済産業省の「IT活用型経営革新モデル事業」(以後、単にモデル事業と呼ぶ)の活用をC社に勧めたのである。もちろんC社のうち誰ひとりとしてこのような助成事業について知る者はなく、はじめはいぶかしげな反応だったわけだが、コンサルタントであれば誰でもこのような中小企業支援策についての趣意は心得ていて、その活用を促進するミッションを負っているといえるだろう。
 Y氏の提案によれば、C社のニーズに完全に満たす独自のシステム──すなわち、グループとして運営する多くの店舗の稼働状況を、インターネットを介してリアルタイムに本部で一元的に管理できるシステム──を、新たにM社に委託開発すれば、満足度の低い既製のシステムを使うよりも劇的にコストが削減できるとのことである。しかも新たに開発するそのシステムは、ネットやモバイルを活用した新規性の高いシステムであったため、その開発費について国から助成金が出るかもしれないとなれば、C社にとってはたいへん魅力的な提案である。
 2回転めの検証ステップとして、モデル事業に応募する前提条件として、Y氏の助言に従えば本当にC社のニーズを満たすシステムが開発可能なのかどうか、M社にプロトタイプを作成させて実地でテスト稼働させる必要があった。この過程でY氏の“まいどフォーラム”を中心としたITCの人脈(ITCには大別して経営系とベンダー系があるが、そのうちベンダー系のITC)が役に立ったことを書き添えておく。

<3回転めの留意点>
 モデル事業に応募するための事業計画を作成する頃には、Y氏の助言に寄せるC社の期待はかなり大きなものになっている。ただでさえ数百万円の節約効果のあるシステムが、意外に低い費用で新たに開発できることがわかり、しかもその半分を国が助成してくれるというのだから当然といえば当然である。逆にいえば、Y氏としては、この期待をここで裏切るわけにはいかないことになるから、モデル事業として採択されるかどうかが3回転めの肝となる。
 通例の「検証ユニット方式」でも、ちょうど3回転めあたりが「経営戦略」であるとか「ビジョン策定」という意識を経営者側に抱かせる段階であるから、モデル事業応募を名目として、ここで事業計画作成に着手できることはY氏としても都合がよい。しかし、計画作成は必ずしもY氏の得意とするところではないため、またここでも“まいどフォーラム”を中心としたITC人脈が活躍することとなる。公的機関(この場合は近畿経済産業局)向けの書類は、書式が煩雑であったり、言い回しが微妙であったり、数字が厳格であったりするために、慣れていないと摩擦の元となるのである。そこでY氏は“まいどフォーラム”の提唱する「ちょいサポ」(それぞれのスペシャリストが自分の得意な分野に関して少しだけサポートするという意味)という仕組みを使って、別のITC(公的支援活用を得意とする)に応援を依頼したのである。

<3回転めの検証>
 結果として、C社の事業計画は、競争率5倍以上の狭き門をくぐってめでたくモデル事業として採択され、Y氏はC社の期待に応えることができた。モデル事業に値すると進言したY氏の仮説が、公的機関によって検証され、実証されたわけである。ではここでY氏はお役ご免となるかというと、もちろんそんなことはない。近畿経済産業局には事業の進捗を報告するための書類は、Y氏とその仲間のITCの助言がなければ、とても中小企業家自身の手に負えるものではないし、開発委託先ベンダーとの交渉も簡単ではない。今後展開する大きなプロジェクトにとってY氏は必要不可欠な存在となったわけである。

<結論>
 モデル事業として採択された事業計画に基づいて、C社のプロジェクトが進行していくわけであるが、このモデル事業が完結するまでが「仮説?検証サイクル」の4回転めにあたるといえる。
 さらに、モデル事業終了後も、このモデルを世間に広める(C社の知的財産となったモデルを他社向けにカスタマイズして販売)というプロセスがあり、それが5回転めになる。
 このようにY氏は、小さなきっかけから始まり、だんだんと大きな回転になっていくプロジェクトにおいて、各フェイズで立てた仮説が絵に描いた餅にならないように常にコーディネイトし続けるミッションを負うことになるわけである。つまりY氏は、「検証ユニット」の描く成功パターンどおり、めでたくC社と長期に及ぶ顧問契約を締結することができたばかりか、POSシステムの有効活用を図りたい他社からも声のかかるコンサルタントとなったわけである。
 本事例は、公的な中小企業支援施策に関する若干の予備知識があれば、それを「検証ユニット」にうまく乗せるだけで、実績や信用に乏しいITCであっても、よりスケールの大きいプロジェクトに参画できるという好例を示すものであろう。

ITコーディネータ/永田祥造

ラベル: ,


RFP/RFI作成時のITCとしての課題

2007/02/12

 
■はじめに 

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の提出期限は2週間程度であるが、2週間で作成できる限度を超えた情報提供を依頼してくるRFP/RFIに出会うことがある。

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

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

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

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

■矛盾したRFP

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

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

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

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

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

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

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

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

■前提条件不足のRFP

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

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

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

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

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

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

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

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

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

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

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

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

■良いRFP/RFIとは

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

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

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


■矛盾しないRFP/RFI

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

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

■経営計画を与えるRFP

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

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

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

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

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

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

■まとめ

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

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

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

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

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

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

ラベル:


IT導入マネジメント(開発管理編)

2006/04/12

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

1.大きく分断された開発体制

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

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

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

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

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

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

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

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

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

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

2.長期化する内部進捗ミーティング

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

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

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

<最後に>

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

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

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

ラベル:


This page is powered by Blogger. Isn't yours?