tag:blogger.com,1999:blog-72794632007-04-07T19:20:41.456+09:00太田垣Blogger171tag:blogger.com,1999:blog-7279463.post-58624488054255066512007-02-17T17:11:00.000+09:002007-04-07T19:20:41.526+09:00近年の地方自治体においては国からの交付金が年々減少傾向にあり、また国からの税源移譲もあり、各自治体はそれぞれ自主自立の運営を期待されているという現状がある。そういった背景があり近年の地方自治体は、その運営において様々な知恵を絞り経費削減に努めている。しかし最近は様々な法改正や新法、また事務改善その他の要望による修正経費などにより、その開発コスト及び運用コストが肥大化しているのが現状である。<br /><br />某自治体の基幹系システムは平成１１年から運用してきたが、老朽化や行政の多様化に対応するため見直し時期を迎えた。近年は情報化資産の増大や情報システム群の維持管理運用、個人情報保護やセキュリティ対策により今後、情報化投資額の増加は避けられない状況となってきていた。また法改正、新規追加案件などのシステム改修が例年の如く発生しており、システムが継ぎ足しで歪に肥大化し保守性にも問題があった。それらはおおよそ次のようなものであった。<br /><br />・情報システム群の構築費、維持管理コストの増大<br />・複雑化するシステム群への対応(電子ＸＸシステム等のフロント系システムと既存のバックシステムとの連携)<br />・ 高度な情報セキュリティ対応及び災害対策<br />・ 行政サービス時間の延長、サービス拠点の拡張<br /><br />このような状況はどこでも多かれ少なかれあり、他自治体でも同様な問題に直面している。これらの課題を解決するために複数自治体による情報システム群の共同処理・共同運営が総務省を始め多くのアナリストで提唱されているが、システムの共同処理・共同運営には様々な解決事項が山積しており、なかなか実現できない状況である。以下にその問題点を示す。<br /><br />・共同処理を運営する組織体(一部事務組合、協議会等)の設置の合意形成に時間がかかる。<br />・各自治体の情報化計画に時間的差異が発生しているため、先行投資を含む二重投資が発生する自治体がでる。<br />・各自治体が利用しているシステムが違う。また各自治体独自のカスタマイズがシステム化されているため、標準パッケージ化ができない。<br />・業務手順の標準化が必要(各自治体において、今からシステム化される業務の標準化は比較的容易だが、過去からシステム化されている業務の手順化は難しい)<br />・情報システム群を運用できる高いセキュリティを確保した建物、設備を用意しなければならない。<br />・ 共同運用をおこなうための専門的技術を持った人員確保が必要(各自治体からの出向)<br /><br />これらのことにより、共同で運用するための情報センター(仮称)なるものが必要であると判断し、もともと耐震やセキュリティ面などで条件をみたしている弊社のバッチセンターをそれらに充てることとし、また運用面をトータルサポートなどして共同利用できる体制を整え、利用するにあたってのハードルを低くした。最近の複雑化、高度化する情報システム群への情報化投資は、従来の業務システムへの直接経費よりも個人情報セキュリティ対策、住民サービスの延長に伴う情報システムの運用時間拡大等の維持管理経費を増大させている。システムの維持管理費は、システムベンダ等に支払う直接経費と自治体が用意する間接経費に別れるが、今後の情報システム投資効果はシステムの構築及び維持管理の直接経費だけでなく、システムの運用・管理に係る職員の負担度、サーバー室等の設備費も情報化投資効果として考慮する必要性があり、次のようなメリットがあると考えられる。<br /><br />・情報システムの維持管理専門技術者を自前で養成していかなくても良いため、教育費を含めた総人件費が負えられる。<br />・様々な分野の専門技術者が情報システム群と同一場所に居るため、障害発生時の対応が早い。<br />・災害対策をおこなっている建物や高いセキュリティを確保したサーバー室、及び安全で安定した運転ができる設備を自前で用意する必要がない。<br />・ソフトウエア、ハードウエア、ＯＳ、データベース、後処理加工装置等のコンピュータ資源が複数自治体で共同利用するため、１自治体あたりのコストが低くなる。<br />・行政サービス時間の延長にともない情報システム群の稼働時間が延長されるが、情報センター集中型で監視をおこなうため人件費コストが抑制される。<br />・電子ＸＸ業務等のフロント側システムと、住民情報システム等のバック側システムとの連携が情報センターにおいて集中管理できる。<br /><br />以上それらの基盤構築として同規模自治体での共同処理・共同運用、情報システムのアウンソーシング(設備、維持管理のアウトソーシング)を企画、提案したところである。具体的には情報センターで共同運用化する処理として大きく「監視」「運用」「設備」「技術者」といったものがある。また共同利用化する環境についてハードウエア環境とソフトウエア環境について、レイヤー毎にまず?セキュリティ層ではそれぞれファイアウォール管理サーバーの設置及びアクセス管理システム、次にアプリケーション層としてはそれぞれユーザー毎のＡＰサーバー群及びユーザー毎の手順、さらにデータベース層としてはそれぞれ主従ＤＢサーバーと統括ストレージ及びミドルウエアシステムとデータベースとした。<br />今回これらの提案が受け入れられ、とりあえずファーストユーザーとして船出をすることになったが、その運用手順などは今後、熟慮していくことになる。ぜひともうまく起動に乗せ、近隣自治体に賛同を呼びかけていきたい。<br />　　　　　　【ＩＴコーディネータ／石井　啓視】jyaritag:blogger.com,1999:blog-7279463.post-62515044433365170692007-02-18T10:47:00.000+09:002007-04-07T18:08:57.189+09:00地方自治体の賦課作業をおこなうに当たって、その原始データとして使用する各種原票には給与支払い報告書、確定申告書、住民税申告書、年金資料などがあるが、その数が膨大であり且つ紙媒体であるため、その運用管理が大変である。それらの扱いについては、まず賦課準備作業としてそれらのデータについてエントリー作業をおこない、各種資料マスタを作成する。そして全てのデータを入力し終わった時点で、それらのデータを人単位にシステム的に合算するわけであるが、システムでは対処しきれない様々なパターンが存在するため、システム合算後のデータを再度チエックすることになり、その際にはもとの原票に戻り確認することになる。また賦課作業が終わった後にも、修正行為や住民からの問い合わせなどにより、原票に戻って調査することが発生する。<br />実際に某自治体においては、およそ次のような問題を抱えていた。<br /><br />● １月?３月の間に日々発生するこれら原票の並べ替え、入替え作業に時間がかかり、臨時職員採用や時間外勤務のコスト増につながっていた。（それらの原票は合算後の確認行為のめに、事業所別であったり世帯別であったりとその利用目的に応じて並べ変えていた。）<br />●　課税作業中の確認事項などで元の原票に戻る際や、住民からの問い合わせ時に原票に戻る際、資料を探さなければならなかった。また課税年度については基本的に最大７年度まで遡って事務運用をおこなう必要があるため、資料検索に時間がかかって対応が遅れ、住民サービスの低下につながっていた。<br />●　膨大な資料ゆえ万一の紛失などによる情報漏洩、個人情報の保護が懸念された。<br />● これだけの資料を最大７年度分保管するスペースを確保することは限界であったし、またそれらにかかる保管スペースコスト、バインダーコストがかかった。さらに新庁舎建設が差し迫っており、新執務室には近くに必要なスペースが確保できないという懸念事項があった。<br /><br />以上のような問題を解決すべく原票をイメージ化し、デジタルデータとしてサーバに取り込みパソコン上で管理するよう考えた。<br />これは社会保険庁や事業所及び住民などより提出された各種課税原票を、カラースキャナ等を用いて画像処理、デジタルイメージ管理を行い仕分け、管理をパソコン上で行うものである。これによりイメージシステムに登録されたデータは問い合わせの迅速化が図れ、また付加機能としてのメモ機能、付箋機能などにより職員の伝達漏れを防止でき、それらの結果、職員には本来の知的作業(課税業務)に専念できることが期待できる。また申告受付業務の際にも過年度の原票をパソコンから参照、確認することにより、より迅速な受付作業ができる。また各出張所でも日替わりで申告受付をおこなっており、出先では過年度の原票確認作業が出来ず不自由であったが、その際にはデータを取り込んだパソコンを申告会場に持ち込むことにより解決できる。また最大の懸案事項であった原票の保管スペースについても、７年分の資料をキャビネットに保管する必要は無くなり、原票は全てイメージスキャン後に倉庫に一括保管すればよい。<br />以上の経緯によって実際にイメージシステムを導入した結果、次のような効果が得られた。<br /><br />● 課税資料の仕分けについては手作業による世帯別、町別の並べ替え作業により、仕分けロス・時間ロスが発生していたが、イメージスキャン後は通し番号ナンバリング付きの課税資料を、その番号順(スキャン順)に保管することができ大幅な時間短縮、人的余裕が生まれた。<br />● ナンバリングについては原票のデータパンチ後に世帯番号順に並べるため、各原票に世帯番号シールを貼っていたが、そもそも並べる必要性が無くなったため、それらの事務作業は無くなった。尚、元原票に戻る必要性が発生した場合いには、スキャン時に通し番号をナンバリングすることにより解決した。<br />● 台帳綴じについても同様にその必要性が無くなった。<br />● 確定申告書に添付されていた根拠資料のコピーについて、それらも同時スキャンすることによりその手間が省けた。<br />● 賦課確認作業については、各種原票を合算した結果について確認作業をおこなうことになるが、従来は世帯単位で綴じた原票に戻って確認作業をおこなっていた。その際、それらの資料を探す手間、資料を綴った台帳を広げるスペースなどの問題があったが、導入後はパソコン上から即座に対象資料を検索し確認することができ、またスペース的な問題もなくなった。さらに原票での簿冊管理の場合、他の職員が簿冊を使用中の時には「待ち」が発生していたが、イメージ管理の場合は「待つ」必要がなくなった。<br />● 原票保管について従来は２年度分を近くの執務室に、またそれ以前のものは倉庫に保管していたものが、全て倉庫保管になりスペースの有効利用が可能となった。<br />● 賦課作業後の住民からの問い合わせについても、従来は世帯単位で綴じた原票に戻って確認作業をおこなっており、それらの資料を探す手間、資料を綴った台帳を広げるスペースなどの問題があったが、これについても導入後はパソコン上から即座に対象資料を検索し確認することができ、またスペース的な問題も無くなった。<br /><br />以上このシステムを導入した得られた効果として、賦課作業時期の臨時職員の削減などによる事務作業の軽減、及び職員が本来の知的作業に専念できる環境になったことによる賦課作業の正確性、また住民サービスの質が向上したことである。<br />また最後に今後の課題として、現在エントリー作業(パンチ作業)について、その精度や納期などの問題点があるため、次のステップとしてスキャン時にデータを読み取り、エントリーデータとして利用しようという試みを考えている。例えば給与支払い報告書をとると基本的なレイアウトは同様であるが、事業所毎に微妙な差異も見られ、そういった問題を解決していきたい。そうなればさらに、原票データの精度向上やパンチ工程の短縮につながり、職員にとっては余裕をもったスケジュールになることから、より正確な賦課作業事務が期待でき、結果として質の高い住民サービスが生まれるはずである。<br />　　【ＩＴコーディネータ／石井　啓視】jyaritag:blogger.com,1999:blog-7279463.post-1142062544398300682006-03-11T16:34:00.000+09:002007-04-01T18:56:56.091+09:00■ITコーディネータはコンサルタントなのか？<br />コンサルタントとは企業内だけでは解決できない専門的な問題を解決するための支援業務を行う者と思われます。特に問題を解決するために有効なソリューションを提案し効果を実証することだろうと思われます。ITコーディネータ資格を取得したとき経営戦略立案手法も勉強したのだから個人的にコンサルタント資格を得たように感じました。コンサルタントの定義自体が曖昧なので自分自身がそうだと思えばそれでよいのでしょうが、現在実際にITコーディネータとしての活動を行ってみるとどうも違うように感じております。ITコーディネータはコンサルタントなのか？顧客は何を期待して依頼してくれているのか？ITコーディネータはその名前のとおりコーディネータなのであってそんなに大上段に構える必要はないのではないか？それぞれの契約によって変わるかもしれませんが、自身の経験からコンサルタントとITコーディネータの違いについて考えてみました。<br /><br />■コンサルティング開始<br />約１年前にある企業とコンサルティング契約を締結しました。上場企業で約５名の情報システム人員を有している企業ですが、３０年来利用しているシステムのため現在の情報システム人員は運用保守業務が主体となってしまっており、現在在籍している人員でシステムを初めから構築した経験はありませんでした。そのシステムを全面的に刷新することとなり、その構築支援として契約いたしました。はじめは、ITコーディネータにおけるコンサルティング契約ですからプロセスガイドラインに沿って経営戦略から立案ですよとか、SWOT分析などを提案し実施しようとしたのですがどうもあまり乗り気でなく、そのような構築手法理論などは優先順位が低く必要性は感じてくれましたが、そんなことよりもっと重要なことがあるという返事で実行されませんでした。今回の契約は決して安い金額ではなく、ではもっと重要な問題とは本当に重要なのかと、こちらが悩むようになりました。<br /><br />■でも必要とされている<br /><br />元々依頼内容がITコーディネータにぜひプロジェクトに参加して欲しいというそんな程度でした。しかし、ITコーディネータのプロセスガイドラインが気に入って依頼されているわけでもなく、何か違う価値をITコーディネータに求めていました。プロセスガイドラインに沿った活動をしているわけではないのに、またその作業を行おうという思いもないのに、それでいて契約を切られるわけではなく、次は何時着てくれるのですかと、なぜか必要とされている状況が続きました。では何を行っていたかと言うと、システム構築を行っていく過程では様々な問題が発生します。コンピュータ専門用語の正確な理解、ベンダー側担当のSEが不満に思っていること、利用者が疑問に感じていること、そして経営者からの突然のシステム変更要望など、そのような様々な問題に対してどのように対応していくべきか、経験がないと中々出来ない作業だと思われます。またそもそもSEの不満、利用者の疑問などを気づき、すばやく対処していくことも難しいことであり、高度なスキルが必要になると思われます。そして導入を予定しているシステムはうまく業務に適用するのかどうかを見極める目利き力も必要となります。そのような情報システム構築に関しての相談役のような役割をしておりました。そのような過程で、もしかして顧客はシステム構築におけるITCのプロセスガイドライン理論の提供とその実行ではなく、この「気づき」と「目利き力」を求められてるのではないのかと考えるようになりました。さらには、問題点を気づいた時にわかりやすく伝えてくれて、解決のために中立的な立場で関係者を集めて対策を打てるコーディネーション能力を持った、まさしくITのためのコーディネータが求められているのではないかと考えるようになりました。もちろんプロセスガイドラインは重要でありその知識があるからこそ、必要な関係者をコーディネートし解決に向けた対策がうてるようになると思います。しかしプロセスガイドラインを知っていると言ってもその程度の知識というのも現実に感じました。それを顧客もわかっていたのではないかと考えています。<br /><br />■情報システム室代行業はコンサルタント？<br /><br />ITコーディネータとしてのコンサルティング契約は、自らが高度な経営理論及びシステム理論を伝え解決していくことではなく、顧客視点となって経営者の想い、利用者のシステムにおける疑問の相談窓口となる情報システム室の代行業だと考えるようになりました。役割が情報システム室ですから突然、経営者、利用者の方に対してまずはSWOT分析です、と言っても皆さんびっくりされるだけであり、受け入れられなかったのは当然だと現在思っております。それよりも、普段利用者及びSEがシステムについて感じていること、最新のITの活用事例ってどんな感じ、そして経営とITを結ぶ方法などを経営者と話し合えるような身近な相談窓口として存在するだけで非常に重要な役割を得ていると思われます。特に中小企業ではシステムにおける専門部署もないところが多く、このような役割を担うITコーディネータは今後特に重要になると感じました。契約していただきました上場企業でも実態はあまり変わりがないことが今回の経験で分かり、よりこの思いは強くなりました。資格を取得した時はコンサルタントになった気分でしたが、最近ではそんなに肩肘を張らず情報システム室代行業と考え、もし経営戦略立案などが必要であれば経営コンサルタントをコーディネートし、その結果をうまく情報システムへ反映できるように助言をすれば良いのではと考えております。ITコーディネータの役割は経営とITの橋渡しですが、トップダウンアプローチだけではなく、実際に情報システムを利用される方と経営者の橋渡しも非常に重要な役割だと思います。ITコーディネータはそれぞれの立場での想いを意見として取りまとめる。または聞いてあげる。そして理解してあげる。そんな人材だと考えるようになりました。それはまさしく情報システム室が担う作業でありコンサルタントの仕事ではありません。その作業を代行できる存在意義は、コンサルタントではないITコーディネータとしても、特に人材不足の中小企業にとっては非常に重要な役割であると思われます。<br /><br />ITコーディネータ 認定番号：0023112004C長尾　道晃まいど！メンバーtag:blogger.com,1999:blog-7279463.post-1105681416992096122005-02-16T16:20:00.000+09:002007-04-01T18:56:56.091+09:00<strong>００　サマリー</strong><br /><a href="http://www.isaca.org/cobit.htm" target="_blank">CobiT</a>は、ＩＴコーディネートを推進する際のCBK（Common Body of Knowledge）として有効である。本稿では、CobiTを活用し、ある企業の情報化成熟度を検討し、その後の中長期情報化戦略の方向性を設定した体験に基づき、ITコーディネータがCobiTを活用する方法について論ずる。<br /><br />以下、その要旨である。<br />（１）CobiTを厳格なITガバナンス成熟度評価ツールとして用いず、対話、啓蒙ツールとして用いる。（２）CobiTに書かれている内容をやさしく時間を掛けて議論してゆくうちに、キーパーソンがCobiTをベースにしたバランスの取れた価値観を持つことができるようになる。<br />（３）議論には半年程度の時間が必要であるが、効果は高い。<br />（４）目前の課題を解決する、実際のITコーディネート作業と並行して進めるのが良い。<br /><br /><br /><strong>０１　はじめに</strong><br />CobiTは、またITコーディネータの必須知識となっており、筆者がITコーディネータになるための必須研修を受講した際には、研修の最後に日本語のCobiTテキストを提供された。したがって、本稿の読者は、CobiTの内容をある程度理解しているものと想定し、本稿では詳しい説明は行わない。<br /><br />ただ、筆者の感覚では、ITコーディネータになるための研修会では、CobiTの存在に触れる程度であり、実際のITコーディネートの場で活用している方は、意外と少ないのではないかというのが正直なところである。理由はいくつかあろう。<br />　・CobiTのように、企業全体のITガバナンスを検証するという考え方は、日本では一般的ではない<br />　・CobiT第2版が抽象的で日本では使い物にならなかった。<br />　　　（CSF/KPI等が今のように整備されたのは現行の第3版からだったと記憶している）<br />　・原文が英語で、第3版の日本語訳も解りにくい。（誤訳や意味不明用語も無いとは言えない）<br />このように、ITコーディネートの現場でCobiTを利用するためには、相応の工夫や土壌が必要とされると思われる。<br /><br />筆者は、あるITコーディネート案件において対象組織の全体像をつかみ、対象組織の担当役員と認識を合わせるためにCobiTを用いたところ、担当役員と非常に良好な信頼関係を築くことができ、現在も長期にわたるITコーディネートを実施中である。 従って、筆者にとってCobiTは実例も豊富で、ITコーディネータや情報システム部門を取りまとめるマネージャクラスには使いやすいツールのように思える。以下、筆者の体験をベースに、どのような位置づけで使えばよいのかを記してゆきたいと思う。<br /><br /><br /><strong>０２　CobiT第3版の構成</strong><br />CobiTは、米国の情報システムコントロール協会（<a href="http://www.isaca.org/" target="_blank">ISACA</a>：Information Systems Audit and Control Association）が提唱しているITガバナンスの成熟度を測るフレームワークであり、銀行系企業等を中心に活発に利用されていると聞く。<br /><br />CobiT第3版は、4分野34項目のテーマから成っており、各項目それぞれにCSF、KGI、KPIがかなり具体的に表現されている。これによりコーディネート対象組織が組織の中でどのような情報処理機能を持っておくべきかが解り、0から5までの成熟度モデルにより、ITガバナンスの成熟度がどの程度なのかが見えてくる。<br /><br />（参考）CobiT第3版の4つの管理プロセス<br />　1. Planning & Organisation 計画と組織<br />　2. Acquisition &amp; Implementation 調達と導入<br />　3. Delivery & Support デリバリと支援<br />　4. Monitoring モニタリング<br /><br />CobiT第3版が使いやすいのは、対象組織を見るためのいくつかの切り口／視点を提供してくれるところにある。4つの管理プロセス34項目のテーマという見方以外に、ITプロセスの成熟度で見ることも出来、ITプロセスを動かす「ITリソース」とITプロセスが動かす対象とする「インフォメーションの質」という、2つのコントロール対象ミニマトリックスで見ることも出来る。<br /><br />なお、日本語版の翻訳だけをたよりにして進めると、意味がわからないことが数多く出てくるので、できれば英語原文も読みながら理解してゆくべきである。訳については、別途論ずる予定であるが、後半のシステムの可用性・キャパシティに関する部分等は、日本語になじまない部分が多く、英語で理解したほうが良い。 （<a href="http://www.ne.jp/asahi/music/marinkyo/kunordiganto/cobit.html.ja.sjis" target="_blank">訳の問題についてはこちらのITコーディネータさんも、いろいろ指摘されている</a>）<br /><br /><strong>０３　シチュエーション</strong><br />CobiTは、対象企業のキーパーソンや問題意識を持つ人物と最初にミーティングを行う際のクイックリサーチに有用なリストを提供してくれる。（ここでの初回ミーティングとは、単なる挨拶やファーストコンタクトではなく、本題に入るミーティングのことを指す。）<br /><br />ITコーディネートを行う場合、ITコーディネータによっては、ITコーディネータの位置づけを十分に説明しないまま、一方的なヒアリングに入ってしまいがちである。気持ちはわかる。経営戦略やシステム状況等をできるだけ正確に早く理解し、今後の進め方を判断したいがために、相談者を質問攻めにあわせてしまうのである。 こうした質問攻めは、ITコーディネートを行うために必要だから仕方ないとも言える。<br /><br />しかしながら、相談者の側ではITコーディネータのこうした行動を必ずしも理解してくれているとは限らない。むしろ、「ITコーディネータはITと経営の両方に詳しく、すぐにアドバイスをくれるセンセイだ」という認識のもと、１回のミーティングで、１回なりの何か自分で判断し考える材料がほしいと考えている場合がある。<br /><br />従って、ヒアリングだけで終わった場合、多少なりとも釈然としないことも多いようである。まして、コンサルタントやアドバイザーを使うことに慣れていない組織の場合は、ミーティング直後に使える「知見」や「新たな問題発見（気付き）」を求める傾向があるため、注意が必要である。<br /><br />少なくとも相談者側に、”課題をITコーディネータに丸投げしない”という意思があれば（←実際、相談者側はそうあるべきなのだが）、「気付き」のための何らかのヒントを提示し、ミーティングをして良かったと思えるような成果を提供してあげる事が長い付き合いの最初としては良いと思われる。<br /><br />ところで、初回もしくは二回目のミーティングまでで、対象組織の相談者から情報をヒアリングしてゆく過程で最も把握しにくい情報は、戦略情報化企画に当たる部分である。実際、経営戦略は、たとえそれがIT的視点から疑問視せざるを得ないものであったとしても、なんらかの形では存在している場合が多いし、調達に関わる情報も、情報システム部門や取引ベンダー等からの情報である程度把握できる。<br /><br />しかし、戦略情報化企画にあたる部分に関しては、経営とITの中間に当たる部分であることもあって、対象組織内で統一的に把握している人物が少ないことが多い。<br /><br />そこで、CobiTに網羅されているテーマが重要なポイントになってくる。<br /><br />中長期的な視点から考えた場合、相談者などキーパーソン自身が自社のシステム部門の位置づけや問題点を客観的に把握する目を持つ事が重要となる。 また、相談者とITコーディネータとの間に共通の言語や価値観を持てるようになることも、その後のコミュニケーションを円滑に進める上で重要なポイントとなる。<br /><br /><strong>０４　CobiT活用が効果的な対象</strong><br />CobiTに網羅されているテーマが重要だといっても、そのままでは消化しにくい。テキストを渡して、「<em>ハイ！このテキストで自己診断してください</em>」と言って診断してもらうわけにはいかない。<br /><br />CobiTを活用する場合、「企業を診断する」とか「採点してランクをつけ評価する」といったスタンスではなく、「ITに関わるテーマはこんなに広いのですが、何か手をつけておられますか？手を付けられそうですか？不安に思っていますか？」というスタンスで望むべきである。（ランク付けや採点して欲しがる対象組織もあるが、それを目的にしてはならない）<br /><br />会社の戦略情報化企画を考えるときに、思いをめぐらせないといけない要素がいろいろあって、それらがなぜ重要なのか？なぜ情報システム部長では解決できず、社長や担当役員が関係するのか？ということを理解してもらう事にかなりの重点が置かれると考えたほうが良い。<br /><br />すなわち、CobiTの活用は、対象組織の短期的な問題解決ではなく、体質改善に効果があるといえる。CobiTが対象としているのは、ITガバナンス成熟度であるため、改善による効果はじわじわとゆっくりと利いてくる。対象組織の柔軟性にもよるが、早くても半年、筆者の経験では数年単位の時間が必要では無いかと考えられる。 したがって、目の前の問題を今すぐ解決しようとしてITコーディネータを頼ってきている場合等には、CobiTの活用は控え、別の方法を検討すべきであろう。<br /><br />効果は「じわじわとゆっくり利いてくる」と書いたが、これにもコツがある。ガバナンス成熟度を判定し、低いところを引き上げ、全体を平均的（レベル２?３程度）にそろえてやることが良く、情報処理の企画・計画から実施・運用までの見通しがかなりよくなる。（筆者には経験は無いが、場合によっては成熟度が飛びぬけてよい部分をわざと下げて、平均的にしてやる事が良い場合もあるかもしれない。）<br /><br />ITコーディネートする際に、成熟度を上げて見通しがよくなった部分を上手に褒め、小さなことでも効率化に結びつけて行くことが必要であろう。<br /><br />一方、対象組織の規模については、数人で構成される小規模事業者では難しいが、情報システム部門やシステム専任者が存在する規模の組織であればまったく問題無く、情報システム部門やシステム専任者が存在しない場合でも、CobiTの大半は活用できる。<br /><br /><br /><strong>０５　具体的なCobiTの活用方法のアウトライン</strong><br />実際にCobiTを活用するにあたっては、以下の４つのステップを踏む。<br /><br />ステップ１<br />初回ミーティングに先立って、作業内容と目的の提示を行う。すなわち、この先どのような領域について質問を行うか、どのような速度で話を進めてゆくか、何がアウトプットかを明示した資料を提出する。<br /><br />ステップ２<br />週に９０分×２回、対象組織の相談者やキーパーソン（CIO相当者、経営企画部門）との定期ミーティングをアサインする。<br /><br />ステップ３<br />週２回のうち１回目はヒアリング、２回目はヒアリング内容のまとめと次回の説明、という流れを作る。<br />筆者の場合は、ExcelでA3用紙1枚のミーティングシートを作成した。シートには、「今回のテーマ」「ヒアリング項目」を記述し、「現状」「あるべき姿」「対策」「課題」の欄を空欄にし、ミーティングの前日にメールで送付した。（２週目以降は、前週のヒアリング結果を元に、空欄部分を埋めてゆく）<br />ヒアリング項目は、各テーマのKPIやKGIを元に具体的な質問項目を記述しておいた。<br /><br /><br />ステップ４<br />最後に、報告書を作成する。<br /><br />４つのステップは、本題のITコーディネートと並行して進める場合もあるし、ステップが完了してからITコーディネートに本格的に取り掛かる場合もあると思われる。<br /><br />尚、ITコーディネートを進めてゆく中でのCobiTの活用にあたっては、先にも述べたように診断的なスタンスに立たないことである。あくまでITコーディネートをして、効果的なIT投資を促進させるのが目的である。採点はあくまでコミュニケーションを円滑にし、理解を共有するための道具に過ぎない。 CobiTのプロセス記載順序どおり、Planning &amp; Organisationから始める必要は無いし、KPIやKGI等を事細かく追求する必要も無い。分厚い分析資料はできても、全体像を担当者と共有できなかったり、全体像がはっきり見えなければ失敗である。例えば…<br /><br />・コストコントロールは厳しいが、事前調査コストも出さず、一発勝負をしがち<br />・IT化を社長の人脈に頼りすぎており、ITベンダーと長期的な関係構築が出来ない<br />・部門のIT化推進にばらつきがあり、強いところはより強く、弱いところは弱いままであり、全体最適が出来ていない<br />・運用がベンダー任せででたらめで、データの品質が悪い<br />・システム部門がITを理解していない経理部の下にあり、良い提案が途中で消えている<br /><br />などなど。CobiTに照らして様々な角度から検討することによって色眼鏡を掛けずに、対象組織のITガバナンスを理解することができる。<br /><br /><br /><strong>０６</strong><strong>　作業内容の提示</strong><br />初回ミーティングに先立って、目的、作業内容、スケジュールを提示する。初回ミーティングでCobiTを使用する目的を明確にする。ただしCobiTという名称を出す必要は必ずしも無い。このフェーズでの目的は、経営と情報システムとの関係の健全性、成熟度をITCが理解し、相談者と認識を合わせることに設定する。<br /><br />これによって、<br />　・情報システム投資の健全性やリスクがわかるようになる<br />　・場当たり的対応をしている部分、属人的な部分がわかるようになる<br />　・中長期戦略を立てる場合の判断材料となることを説明する。<br />作業の進め方は、対象組織の状況や相談者のポジション等により、様々な方法が考えられる。筆者が実施したケースでは、後述するように週に２回、９０分のヒアリングを情報企画室のトップを中心に時折情報システム部長を交えて約半年（２５週間）続けた。<br /><br /><br /><strong>０７　週２回のミーティング</strong><br />週２回のうち１回目はヒアリング、２回目はヒアリング内容のまとめと次回の説明、という流れを作る。 週に２回×半年間という期間は実際には長く、また担当者にとってもITコーディネータにとっても辛い作業であるが、CobiTが取り扱う広範な分野をCIOに理解してもらうには消化するための時間が必要であり、決して長い時間ではない。<br /><br />CobiTは、大きく４つの分野に分かれているが、後回しとなるのはシステム監査等の部分である。システム監査は重要な機能であるが、監査機能を持たない対象組織が多く、細かいヒアリングには入ってゆけない場合が多い。また、この時点で監査の重要性を説いても、あまり効果を持たない場合がある。<br /><br />そこで、この監査部分は簡単に終わらせて、そのかわり、CobiTによる分析結果をどのように現場に還元してゆくかを相談する時間に当てたほうが良い。たとえば、対象組織の特性によって<br />　・トップダウンで統制力の強いプロジェクトを編成する<br />　・改善効果の高い部署から改革を断行し、実績を持って全社に広げてゆく<br />等、さまざまなシナリオが考えられる。<br /><br /><strong>０８　まとめ資料</strong><br />アウトプットは、戦略情報化企画書のような形や、情報活用成熟度評価レポートのような形が考えられる。CobiTをベースにした診断資料。あまり精密に行っても意味が無いと考える。学術論文ではないし、他の企業に公開するものでもない。社内改革を推進するために効果的なアウトプットかどうかが重要となる。<br /><br />最終アウトプットとしては、戦略情報化企画書のような形や、情報活用成熟度評価レポートのような形が考えられる。検討すべきは、アウトプットの形では無く、そのレポートを対象組織に戻した場合、どのようなインパクトを与えるかということである。したがって、闇雲にレポートを提出するのではなく、相談者との間でレポートをどのようにリリースすれば最も良い効果を対象組織に与えるかを、ゆっくりと考えて提出すべきである。<br /><br /><br /><strong>０９　相談者の「気づき」</strong><br />筆者のある事例の場合、相談者は経営企画部門や情報システム部門を監督する役員で、実質的なCIOであった。ただし、職歴からIT部門出身ではなかった。したがって、CobiTの名前は出さず、「こういう広範囲なテーマで定期的なヒアリングを持ちたい」と提案した。相談者は当初、「日次会計」の導入に熱心で、それが実現されば多くの経営課題（経営陣の意思決定の迅速化等）が解決されると考えていた。<br /><br />しかし、CobiTによる面談を繰り返すうちに、相談者は日次会計システム導入というのが会社が持つリソースや情報の質を考えていない戦術であることに気づき始めた。<br /><br />むやみにシステムの増強を行う前に、整備しておくべき重要なことが数多くあることに気づいてきた。そして、日次会計に取り組む前に、商品マスターや顧客マスターといった基本中の基本データを洗い直し、現在のシステムが５年以上にわたり蓄積し続けてきた情報と組み合わせて見えるような仕掛けを作るほうが重要であることが見えてきた。<br /><br />様々な目新しいシステムを次々に提示することではなく、自組織を見つめ正しいポジショニングを図ることが結果としてよりよい経営計画とそれに続く戦略情報化企画を生むことになる。<br /><br /><br /><strong>１０　さいごに</strong><br />CobiTをベースに情報システム部門のあり方を客観的に見つめ、標準化や測定化を進める土壌が出来始めると、ITコーディネートは非常に楽に進む。また、CobiTが提示するテーマは、ITILを利用する場合にも非常に有効であり、親和性が高い。ITコーディネータ諸氏にあっては、CobiTには500以上のCSF、KPI、KGIが含まれているので、こうしたノウハウをうまく活用し、対象組織の情報活用力の向上に努めていただきたい。<br /><br />（以上）　約７０００文字<br /><br />2005年2月16日 ITコーディネータ　0038332004C　太田垣　博嗣太田垣tag:blogger.com,1999:blog-7279463.post-52047999383105458612007-02-17T21:20:00.000+09:002007-04-01T18:56:56.090+09:00<strong>■失われた２０年とチェンジリーダーの減少</strong><br /><strong></strong><br />　ＩＴ導入プロジェクトにおいて、その成否を分かつ大きな要因のひとつに「チェンジ・リーダの存在」がある。しかしこの20年近くは、欧米流のマネジメント手法に基づいて数字（成果評価,キャッシュフロー,etc.）を追い続け人材育成をおろそかにしてきた結果、驚くほどチェンジリーダーという人材が減少している。<br /><br />　チェンジリーダーとは、ＩＴ導入プロジェクトにおいて、情報システムと業務プロセスの変革の中核となって、プロジェクトの目標を達成し成功に導くキーマンである。その立場は、情報システム（ＩＴ）部門であっても、実務部門であっても良いが、外部のＩＴベンダーではなく導入企業側に存在すべきであろう。<br /><br />　では、企業がそういった人材の必要性を感じていないわけでもなく、また企業によってはそれなりの予算を確保して手厚い人材教育を実施しているにもかかわらず、本当に意味での「チェンジリーダー」が育っていないのはなぜか？<br /><br /><br /><strong>■チェンジリーダーが育っていない具体例</strong><br /><br />「チェンジリーダー」が育っていない要因を導き出すために、私が関与したＩＴ導入プロジェクトの現場で発生した事実を例示する。まずは、実務部門での事例である。<br /><br />１）ＳＣＭ／サプライチェーン・マネジメント・システム導入プロジェクト<br />￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣<br />　サプライチェーン・マネジメント（以下、ＳＣＭ）システムの導入では、組織や会社の枠を超えた「情報共有」がＩＴ面での中核となる。また、共有した情報に基づいて業務プロセス（ビジネスモデル）を変えてしまうようなケースもある。こういったＳＣＭ導入プロジェクトのチェンジ・リーダーには、複数の組織や企業の枠超えた「調整能力」と、その利害関係者の意識を変えさせる「ビジョン」、そしてプロジェクトを計画し推進する「実行力」が求められる。<br /><br />　Ｇ社では、実務部門の幹部社員（Ｎ氏）をリーダーとするＳＣＭ導入プロジェクトを組織した。Ｎ氏は、これまでにも部門システムの構築ではリーダを経験したことがあった。ＩＴ部門の経験は無いが、部門におけるシステム化要件をとりまとめ、ベンダーに発注して予定どおりにシステムを稼動させたことがあり、必然的にＮ氏をリーダーとするＳＣＭ導入プロジェクトがスタートした。<br /><br />　ところが、ＳＣＭ導入プロジェクトが始まってみると、Ｎ氏が立てたスケジュールがことごとく遅延して再スケジューリングを繰り返し、またプロジェクトに参画しているメンバーからもクレームが続出する事態となった。それは、Ｎ氏が自分一人で考えた机上論（理想的なプラン）でプロジェクトを進めようとしたためであった。　ＳＣＭ導入プロジェクトでは、作業効率の向上といったファクターよりも、GIVE&TAKEでの情報提供とその活用がメインであり、Ｇ社プロジェクトでも組織間の利害調整がプロジェクト成否の重要ポイントであった。当然、Ｎ氏に対してそのことは事前に認識をさせており、プロジェクト途中でも何度も確認をしていたいたが、机上論が中心で他部門に対しても高圧的な対応をとるなど、自らの「行動を変える」ことができなかった。<br /><br />２）基幹システム再構築プロジェクト<br />￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣<br />　次は、ＩＴ部門での事例である。<br /><br />　Ｔ社では基幹システムの再構築プロジェクトを企画し、外部コンサルタントが参画した「新業務システム基本計画の立案策定」を終え、具体的なシステム要件分析設計に着手した。分析設計のプロジェクトは、第一次開発の対象とするサブシステム毎に複数のＩＴベンダーと、対応する社内ＩＴ部門の担当者で組織し、プロジェクト・リーダーは、Ｔ社のＭ氏が担当することとになった。　Ｍ氏は、入社以来18年ＩＴ部門に所属するベテラン社員である。今回の開発範囲はＭ氏の担当してきた分野ではなく他部門から転籍してきたばかりではあったが、人事上も幹部社員一歩手前の評価をうけており、Ｍ氏にとってもこのプロジェクトはキャリアの面からも重要なテーマであった。<br /><br />　しかし、プロジェクトが発足して具体的な分析設計作業が始まってみると、Ｍ氏のプロジェクト・マネジメントスキルの無さが露見した。チームセションの開始時刻になってもセションが始まらない。来週のセション予定が見えない。プロジェクト課題が整理されていない。プロジェクトメンバーで情報が共有されない。問い合わせに対するレスポンスが遅い、あるいは無い。等など、たとえＰＭＰの資格はなくても、プロマネの立場であれば果たすべき役割が果たせない。当然、ＩＴベンダーからだけでなく社内メンバーからもクレームが上がり、プロジェクトが崩壊の危機に陥いる事態になった。<br /><br />　Ｍ氏はこれまで、手厚い社内教育メニューにしたがって、数々の講習会に参加してどれも好成績で修了している。プロジェクト・マネジメントについても、ＰＭＰ受験対策講座やコミュニケーション,ファシリテーションといったテクニックだけではなく、担当分野での実務を通じた経験も有しているはずである。しかしそれは、自分が得意とする限られた範囲のみでしか機能しないのである。　また、基幹システムの再構築においてもＳＣＭの導入と同様、単に作業の効率化だけでなく、ＢＰＲ（ビジネス・プロセス・リエンジニアリング）も含まれ、利害の対立する実務部門間の調整も求められる。<br /><br />　Ｍ氏は、自身が知らない分野で、そして初対面となるメンバー構成の中で、プロマネとしてどう振舞うべきかを体得してはいなかったのである。あるいは、頭では理解できていても行動することができないのである。<br /><br /><br /><strong>■「チェンジ・リーダー」が育たない原因</strong><br /><br />　２つの事例に共通していることは「行動が変えられない」ことである。頭では理解した（つもり）であっても、実際にどうやって行動したら良いのかが判らないのである。つまり、様々な書籍や講習会を通じて、知識としては習得しており、本人も習得したつもりになっている。そして、習得した知識は実践の中で試してみて調整を加えながら体得していくことは、広く一般的に当たり前のプロセスである。<br /><br />　そう、その<strong>「当たり前のこと」が「当たり前に出来ない」</strong>ことが問題なのである。<br /><br />　こういった場合、「行動が判らない」のであれば「行動のやり方を指導（個々に指示）」すれば良いというものではない。本質を理解していない（理解できない）状態のまま個々に指示しても、指示されたことに従う（従おうとする）だけであって、行動そのものには何も変化があらわれない。プロジェクトでは様々な案件が連鎖的にかつ同時並行で進行していく。その内の一つを指示に従って行動したとしても、次々と迫ってくる案件をサバいていくことは不可能である。<br /><br />　では、なぜ本質が掴めないのか？<br />　それは、<strong>従来は「当たり前」であった「人を育てる」ことを怠ってきた</strong>ことに他ならない。<br /><br />　ここ数年、製造現場での熟練工の技能が見直されており、従来は徒弟関係の中で継承してきた技能をＩＴで継承するようなことも始まってはいるが、その基本は「人と人とのつながり」であることには変わりない。これはＩＴ導入の現場でも全く同じである。<br /><br />　失われた20年の間も、企業内では人材育成の重要性は十分に認識されており、キャリア形成プログラム（ＣＡＰ）制度を導入した企業も少なくない。しかし、その教育内容は「講習会受講」やe-Learning/CBTといった「知識学習」が中心であった。一方で、本質的な人材育成実践の場であるはずの「現場」では、数字（納期,売上,成果,キッシュ,etc.）が最優先され、現場で人材を教育するというミッションが希薄化（消滅）してしまっているのである。つまり「教育は人事部門」のように「他人任せ」にして、「現場での人材育成」を放棄しているのである。<br /><br />　これは、現場を預かっている管理者あるいはマネージャーの怠慢である。<br />　また、そういった管理者やマネージャーを放置してきた経営者の怠慢である。<br /><br />　今、あたなの会社ではどうでしょうか？<br />　現場で人材（人財）を育成していますか？<br /><br /><br /><strong>■どうやってチェンジリーダーを育成するのか<br /></strong><br />　チェンジ・リーダーの素養として、不確実で不揃いな情報から、仮説（シナリオ）をたてて情報を収集し、その仮説を検証するスキル（仮説検証）が求められる。常日頃から情報収集のアンテナを高くし、社内外の様々な情報や潮流をウォッチすると同時にコミュニケーションをとっている必要があるが、そういった行動は本人の意識（問題意識,危機意識,当事者意識）から生まれてくるものである。<br /><br />　では、どうすればそういった意識付けができるのか？<br /><br />　まず、経営者や管理者／マネージャー自身が、その意識を持たなければならない。　あるいは、経営者や管理者／マネージャー自身が、そういった行動を起こさなければならない。　つまり、チェンジ・リーダーに求める行動を自らも実行することである。<br />　であるとするならば、経営者の行動はまさにその実践であるといえる。　経営者＝チェンジ・リーダー（オーナー）である。ここで問題となるのは管理者／マネージャーであろう。<br /><br />　前述の事例でも真因はそこにあった。<br />　Ｎ氏の場合、実務部門の立場でありながら現場での実務経験がほとんどない。入社以来、いくつかの部門を経験してはいるが、その業務を自らが責任を持って遂行することがなかった。たとえあったとしても、それは極限られた範囲に止まっていた。ただ、理論的なアプローチが出来るという面が、部門情報システムの開発や改善には有効であったため、Ｎ氏のマネージャーは彼を安住させてしまったのである。<br />　Ｍ氏の場合には、入社以来18年、限られた範囲での業務に携わったきたこと。その中で、意識のあるマネージャーとの出会いが無かったことであろう。ただ、Ｍ氏自身には問題意識はあったが、結果的に前職の管理者との対立から生じた精神面でのキズを引きずっていることも判明した。<br /><br />　ここ数年、心の病(風邪)である「うつ患者」が急増しており、メンタルヘルスケアが声高らかに叫ばれている。たしかに社会現象として由々しき事態であるが、スキルをアップさせるためには、プレッシャーが必要である。プレッシャーの無い仕事では人は育たない。しかし、プレッシャーが大きすぎると押し潰されてしまう。また、何か行き違いで『心が折れる』こともある。心が折れてしまうと、そのパワーは後ろ向きに流れていく。<br /><br />　だからこそ<strong>「現場教育」</strong>が必要なのである。<br />　現場から遠く離れたオフィスの会議室ではない。ましてや電話やメールでは決してない。<br /><br /><ul><li>現場でのクロスコミュニケーション（重なり合う）</li><li>知と知、知と情、知と技といったクロスファンクショナルなナレッジ</li></ul><br />　それは、場当たり的な「ＯＪＴ（On the Job Training）」ではなく<strong>「意識のある現場教育」</strong>である。徒弟制度の中で当たり前に伝承されてきた技能であり<strong>『共育（共に育つ）』</strong>である。<br /><br /><br /><strong>■時間がかかる。だからこそ今すぐ着手！<br /></strong><br />　以上のように、チェンジリーダーが育たない真因とその対策を考えてきた。<br /><br />　ＩＴ導入プロジェクトの成否は「チェンジ・リーダー」の存在如何にかかっているともいえる。　しかし、対策を講じれば即座に「チェンジ・リーダー」が育成できるわけではないことは明白である。　中には、ちょっとしたキッカケで瞬間に「チェンジ・リーダー」となる人材もあるが、概ね長い歳月が必要になってくる。しかも、それを企業文化（ＤＮＡ）としての継続がなければ成立しない。<br /><br />　企業の経営者にとっては、今さら「中長期的な人材育成を・・・」といわれても、今まさに直面しているプロジェクトを何とかしないわけにはいかない。人材が育つまで待っているわけにもいかないので、外部の人材を活用することになるが、そこにＩＴコーディネータという切り札がある。<br /><br />　ＩＴコーディネータは中立的な立場であり、そのスキルと経験次第では「チェンジ・リーダー」となりうる人材像である。また、ＩＴＣプロセスの中では人材育成計画も含まれており、中長期的な人材育成計画の立案を支援することができる。<br /><br />　ただ、やはり本来は社内にそういった人材は不可欠である。<br />　人材育成には膨大な時間が必要になる。<br /><br />　<strong>だからこそ今すぐ着手！</strong><br />　人材育成計画の立案に際しては、様々な教育カリキュラムとともに、<br />　<strong>現場教育(共育)</strong>をぜひ取り入れてもらいたい。<br /><br />（ＩＴコーディネ?タ／植松栄介）エイスケtag:blogger.com,1999:blog-7279463.post-47832120778322245832007-02-12T18:38:00.000+09:002007-04-01T18:56:56.090+09:00■はじめに　 <br /><br />RFPは提案依頼書であり、RFIは情報提供依頼書である。システム開発にあたり、自らのニーズや現状をとりまとめ、書類の形で複数のITベンダーやシステム･インテグレーターに渡す資料を言う。口頭でニーズを伝えるのとは異なるため、依頼の目的や求めている物事がハッキリし、曖昧さや人情（普段の営業付き合い）要素が排除されるため、適切で公平な競争提案を貰いやすくなる。 <br /><br />小職は、仕事柄、RFPを発行する立場とRFPを受け取って提案する立場の両方を経験することがある。そのときの経験からすると、提案する立場から見て良いRFP/RFIを書く人は、会って話をしても優秀であるし、提案しにくいRFP/RFIを書く人は、会って話をしてもなかなかピントが定まらない場合が多いように思う。 <br /><br />本論では、そのときの経験などを踏まえ、RFP/RFIを作成する際に陥りやすいモラル上の問題を指摘し、より良いRFP/RFIを作成する為の参考とするためのヒントを提示する。 <br /><br />■RFP/RFIが流行り始めた <br /><br />ここ最近、RFPという言葉がシステム開発ベンダーの中でもかなり知名度を上げてきている。ほんの少し前であれば数億円以上の大規模なシステム開発でなければRFP/RFIといった言葉は聞かれなかったし、プログラマでもその言葉を知っている人は少なかった。こういう変化の中の一部には、システム提案を依頼するときにはRFP/RFIを書いて依頼しようという、ITコーディネーターの地道な呼びかけや活動もあるのだろう。 <br /><br />ただ、依頼をかけるユーザー企業や団体が純粋に自前でRFP/RFIを作成する場合はまだまだ少ないように思われる。多くの場合、RFPやRFIを書くためには相応の専門能力が必要であるため、ITコーディネータがRFP/RFI作成に携わったり、普段から出入りのあるITベンダーが作成する場合が多いように思われる。（小職もその一人である） <br /><br />また、RFP/RFIを受ける側のシステムベンダーも、仮にその内容が自社でできない内容であっても、名乗りだけは上げておくという態度をとることも多い。営利活動からすれば、そういう態度をとるのは自然な話である。そして、肝心のRFPはシステムベンダーの関係会社や子会社、協力会社等の手に渡ってゆく。 <br /><br />一般的にRFP/RFI発行の手続きを行う場合は、依頼元と依頼先と秘密保持契約を締結してから、RFP/RFIを提示するものだが、同等の秘密保持契約を継承する限りにおいて、依頼先がさらに他に依頼することを認めているケースが多い。 <br /><br />実際、システムベンダーやシステムインテグレーターは、ハードウェアメーカーや、通信業者、関連ツールベンダー等に相談しながら進めなければ、納期、金額、性能保証体制などRFPに書かれている事項は満たすことができないので、これは特異なケースではない。 <br /><br />■RFP/RFIを受けたシステムベンダーの立場から <br /><br />さて、RFP/RFIにも出来、不出来がある。もちろんユーザー企業内での現状分析の具合やRFP/RFI作成までの時間等の問題で満足に要件を固めることができない場合も多いため、内容の正確さや濃さについての出来、不出来はあっても仕方が無いと思うのだが、それ以前の問題もある。それは、RFP/RFIを貰って提案ベンダーの立場になった時に提案書を書いて提出する側の不満や苛立ちとして現れてくる。多くの場合、RFP/RFIの提出期限は２週間程度であるが、２週間で作成できる限度を超えた情報提供を依頼してくるRFP/RFIに出会うことがある。 <br /><br />■開発ベンダーの手法に深入りしたRFP <br /><br />たとえば、「開発ソフトウェアの品質管理をどのように行って、提供製品の質を維持するのか？」という課題に関して、プロジェクト管理手法やテスト手法、使用しているツール等を事細かに記述させ提出させようとするものがある。ある程度の開示は必要であろうが、提案書を記述する側は、別のことを警戒するのである。 <br /><br />すなわち、このRFP/RFIが他のシステムベンダーの手によって書かれたものであるとすると、秘密保持契約があるとはいえ、事実上、こちらの手の内を他のシステムベンダーに読まれてしまっていることになってしまう。ユーザーに理解してもらうのはよいとしても、開発効率を上げるための工夫は、基本的には他社に知られたく無いことでもある。 <br /><br />あるいは、パッケージソフトのデータベース設計図、スキーマ構造図、エンティティ設計書を出してください、などといったRFPも存在する。ERPソフトにおいて、データベース設計は一種の知的財産であり、秘密保持契約があるとはいえ、購入するかどうかわからない人々に簡単に開示するわけにはいかない。 <br /><br />■矛盾したRFP <br /><br />あるいは、ベンチャー企業や新規事業のシステム提案依頼で多いのが、将来計画が非常に曖昧で、どの時点の企業規模で見積もればよいのかわからないといったものである。 <br />これらにはRFP自体に矛盾があるものも多い。 <br /><br />たとえば、一人１個を買うのが普通の、１個ｎ万円の商品があるとして、その伝票発生数や、営業担当の数、年間販売計画数量などが、矛盾している場合である。１営業マンが１０分に１個ずつ訪問販売してゆかなければいけない計画になっていたり、月に１０台程度販売している工作機械が、システムを導入した直後から毎月８０台ぐらい売れる計画になっているが、生産設備は現状のままで月産５０台が限度であったりという具合である。 <br /><br />■経営計画を考えさせようとするRFP <br /><br />一見IT提案のようで、よく読むと新規事業やビジネスモデルの検討依頼のようなものもある。 <br /><br />通常、RFPでは、ユーザーニーズとベンダー各社が持つ技術や製品、ソリューションとのフィット＆ギャップを明確にしてゆくことにより、依頼ベンダーを絞り込んでゆくことが重要になる。 <br /><br />ところが、時折「あなたが持っているIT技術を使って、私たちのビジネスモデルをどう変えることができるのかを示してください」とか「ホームページを開設すれば、月商いくらぐらいになると考えられますか」といった質問が設定されていることがある。そして「そう考えた前提条件を残さず書き出しなさい」といった注意書きが載っていることが多い。 <br /><br />たしかに、RFP/RFIの目的のひとつとして、ユーザーが知らない画期的な手法や製品を市場から情報提供してもらうという事があるのだが、そこに裏付けを求めるべきではないだろう。 <br /><br />また、経営者からRFP執筆者やITコーディネータには「IT化でいくら儲かるんだ？」といった投資効果に直結した質問が降りてきて、対応しないければならない場合もあるが、その質問をRFPに記述するのは、仮に依頼元の正直な気持ちだとしても、馴染まないように思われる。 <br /><br />■前提条件不足のRFP <br /><br />RFPを書いている現場では、時間不足、情報不足のまま見切り発車してしまうことが多い。十分なITコーディネートを受けていなかったり、社内の情報化戦略が固まっていない場合には、特にそうなりやすい。 <br /><br />問題は、RFPの中に提案するのに十分な情報が盛り込まれていないことである。たとえば、依頼企業・団体のIT経営成熟度に関する情報や、情報システム部門やシステムに詳しい人の能力や権限に関する記述が少ない場合がある。 <br /><br />たとえば、導入後のサポートやシステム運用等について見積もりを得ようとするならば、その組織のIT経営成熟度や担当者のスキル等がわからないと、なかなか提案しづらいものである。つまり、全社のシステム運用体制や会社の情報化がどのように浸透しているのかがわからないため、提案自体が非常にブレたものになる。 <br /><br />他にも、サービスレベル、セキュリティレベル、おおよその予算感覚などが抜け落ちていることが多い。 <br /><br />そして、こうした前提条件が不足しているRFPに対して、質問をすると「貴社が最適だと思う構成で提案してください」といった曖昧な逃げ口上で回答される場合や、「それでは数パターン例示してください」という場合がある。 <br /><br />だが、システム提案する側からすれば、まじめに数パターンを検討し、コスト算出することは難しい場合が多い。それこそ、松・竹・梅の３パターンで金額が数倍違うものを提示することになってしまう。これではRFP/RFIによって要件を整理したことにはならない。 <br />しかし、多くの場合見積金額の根拠はかなり細かく書くことが求められている。 <br /><br />これでは、むしろ提案者側に重たい負担だけがのしかかってくる。 <br /><br />■提案依頼者と提案者の関係 <br /><br />RFPを受け取ったシステムベンダーの行動を考えてみよう。システムベンダーの営業としては当然仕事が欲しいから、自分の事業範囲に少しでも関係しそうな部分があれば、会社に戻りRFPを提案書作成者であるシステムエンジニアに渡すことになる。 <br /><br />しかし、多くの提案書作成者は、他の十分な仕事量を抱えた上で、１週間とか１０日といった限られた提案時間を与えられ、大量の資料を作成してゆかなければならない。特に優秀なシステムアナリストやシステムエンジニアには普段の仕事でも業務が集中しがちである。 <br /><br />ある提案では、RFP/RFIどおりに提案書を作成したら、200ページに及ぶ大作になったことがある。添付資料などをあわせると、ざっと300ページである。ところが、断るときには、電話１本である。営業が訪問しても、プロジェクトが始まって忙しいからとなかなか会えない。 <br /><br />このような体験を重ねてゆくと、次回RFP/RFIが提示されても、まじめに返事しようという気にはならない。 <br /><br />■良いRFP/RFIとは <br /><br />良いRFP/RFIとは、必要十分な情報が矛盾なくコンパクトに伝えられていることは重要であるが、それが提案書作成者に気持ちよく情報開示してもらうものでなければならない。 特にシステムベンダーの選択肢が少ない地方では、良いRFP/RFIを作成してベンダーとの関係を良好に保つことも重要である。 これを踏まえたうえで、前述した良くないRFP/RFIの例に対して、どのようにすればよいかを以下に示してみたい。 <br /><br />■開発手法に深入りしないRFP/RFI <br /><br />プロジェクト管理能力に対する不安や、システム品質に対する不安を取り除いて欲しいというスタンスで、記述することが重要である。つまり、どの程度のシステム品質やプロジェクト管理が遂行できれば不安ではないのかを提示することが重要で、そのような経験が過去どの程度あるのか、不安を除去する証明する提出資料は開発費用に含まれるのか、別途費用を払えばどのような上位オプションがあるのかを訊くようにする方が良い。 <br /><br /><br />■矛盾しないRFP/RFI <br /><br />RFP/RFIに矛盾が見つかると、提案書作成者はそのRFP/RFIの全ての記述が疑わしくなる。したがって、矛盾が発生しないようにチェックをすることが肝要であるが、どうしても整合性が取れない場合は、どの数字を基軸に提案を展開してゆけばいいのかを明示する必要がある。 <br /><br />つまり「現段階では将来の売上計画と今回のビジネスモデルおよび費用計画は必ずしも整合性を持っていません。したがって、別紙に示す費用計画を元にご検討頂き、売上計画などは参考程度にお考えください」等と、提供情報の精度に濃淡を付けるなどの工夫が必要となる。 <br /><br />■経営計画を与えるRFP <br /><br />経営計画に関わる情報は、遮断し、決まっていないことは決まっていないと明示し、それ以上の要求は書くべきではない。 <br /><br />■前提条件をはっきり記載するRFP/RFI <br /><br />前提条件は変動があるとしても、はっきり記載することが必要である。例えば、３年後の新規顧客数がどの程度になるかは、誰だって分からない。しかし、RFP/RFIの主目的は、同じ前提になった時にどのベンダーが一番良い提案を返してくれるかを判断するというところにあるわけであるから、３年後の新規顧客数のような数値は固定させてベンダーに提示しないといけない。同様に、セキュリティレベルは、「Pマークを取得できる程度の企業環境だと仮定し、それに相応しいセキュリティを提供すること」といった表現が考えられる。 <br /><br />システムの二重化や信頼性に関しても、システムコストが大きく変わる要素である。ハードウェア価格だけではなく、二重化のための特別ハードウェアや、それらを正しく起動／終了させる運用手法等も変わってくるため、RFP/RFIには必ず記載するようにする。どうしても明確な記述が出来ない場合は、「現在のシステムと同等か、やや高いレベル程度とする」といった記述等を検討する。 <br /><br />また、システム部門が保有するスキルに関してはできるだけ記載したほうが良い。技術者（社員、協力会社）のおおよその年代とスキル等をたとえばITSSの技術レベルで表現し、日常の業務内容や保有技術（開発言語、システム設計力など）を表にまとめ、人事異動が頻繁かどうか等を示すだけでも、運用の提案には大きく役立つ。一般従業員のパソコンスキルに関しても、社員教育を見積もりに含むのであれば、触れておいたほうが良い。 <br /><br />また、はっきり記載できない部分がある場合、要求する情報や提案は精度を落として提示してもらうような配慮が必要である。 <br /><br />■まとめ <br /><br />良いRFP/RFIなのかどうかを判断する為の、絶対的な指標や客観的な測定値を設けることは難しいしコスト的にも馴染まないと思われる。もとより、世間にRFP/RFIを書き慣れたエンジニアやアナリストはまだまだ少ない。 <br /><br />もし、RFP/RFIを書きなれた人が近くに居ないのであれば、まずちいさなRFIを書く機会を沢山与え、RFI/RFPを書くための文書部品を書き溜める機会を作っておくと良い。最初に社内のシステム構成図や、システム部門のスキルマップなどを書いてしまえば、数年経ってもそれなりに使えるものである。 <br /><br />また、提案を依頼し、どこか１社に決めた後、選に漏れたベンダーを呼び、落選理由を説明すると共に、「また次回別件でRFP/RFIを提示する機会があると思うので、今回お渡ししたRFP/RFIの中で書きにくかったところがあればお教えいただきたいと思います。またもし、参考になるような他社のRFP/RFIがあれば、章立てだけでも見せていただけないでしょうか？」という依頼をしてみてはどうでしょうか？ <br /><br />こうしたタイミングはRFP/RFIを書く技術を磨く良いチャンスである。良いRFP/RFIには良いベンダーが付き、提案書作成者も真剣に取り組むものであるから、長期的な視点から考えても、非常に有用なミーティングになるはずである。 <br /><br />多くのRFP/RFIに接する機会を持っているITコーディネータは、良いRFP/RFI、悪いRFP/RFIを世に問うてゆくのも責任の一部ではないかと感じている。 <br /><br />ITコーディネータ／太田垣博嗣太田垣tag:blogger.com,1999:blog-7279463.post-1142063603170390022006-04-12T17:50:00.000+09:002007-04-01T18:56:56.090+09:00　３年ほど前、全国にチェーン展開している小売店の基幹システムの開発プロジェクトが発足しました。そのプロジェクトにＳＥとして担当することになったのが始まりである。<br />　このプロジェクトは当初５名体制でスタートしました。そして、ピーク時には２０名近くのエンジニアが投入され、開発期間も３年を要する大規模なものでした。私は、そこでバッチ系のＳＥリーダーとして携わる事になりました。そこで私が体験した事、気づいた事を論じていきたいと思います。<br /><br />１．大きく分断された開発体制<br /><br />　このプロジェクトの当初は、５名体制で同じ開発場所で作業を行っていました。ところが、プロジェクトが進むにあたってメンバーが増え今の場所での開発作業が困難になってきました。本来なら、プロジェクト開始前からメンバーが増えた時の開発場所の手配をすべきところでした。ところが、課題として気づいてはいたものの実際に行動を起こすまでにはいたりませんでした。<br /><br />　そこで、今後の開発体制をどうするべきかを話し合った結果、大きく２つに分断することとなりました。１つは、ＷＥＢを中心として画面系の開発チーム、もう一つは夜間更新、集配信を中心としたバッチ系の開発チームとする事になりました。既存の場所には、バッチ系チームが残り、画面系のチームは、そこから電車で３０分ぐらい離れた場所で開発を行うこととなりました。そして、それぞれのチームにプロジェクトマネージャ（以下、ＰＭとする）を配置して、進めて行くことになりました。<br /><br />　分断後当初は、問題なくやっていたのですが、時間が経過するとともにチーム間のコミニケーション量低下、理念の違い、一体感の欠如が生まれていました。<br /><br />　ある時、要件変更が発生し共通のデータ仕様を変更せざるをえない状況となりました。そこで事件が発生しました。互いのチームが保身に走り、自分のチームが有利になるような変更案を提案するようになりました。本来であれば、プロジェクト全体からの視点に立って最適な選択をするべきであるが、チーム間での信頼関係の無さがこのような結果になってしまった。結局、バッチ系のチームが折れる形となって事態は収拾することになった。もちろん、Win-Loseの関係では、互いの関係が改善されるわけでもなく、より一層関係に深い溝ができる事となった。<br /><br />　なぜ、こうような事態になってしまったのか。順に考察することにした。<br /><br /><1> ＰＭのコミニケーション力不足<br /><br />　　　まず、それぞれのＰＭのコミニケーション力不足が考えられる。メールや電話等でのコミニュケーションはあったものの、場当たり的でその量は多いとは言えなかった。まず何よりも、互いの事を理解しようという気持ちが欠けていたのが、一番の問題だった。本来であれば、互いに協力関係を築いてプロジェクトを推進していかなければならないのであるが、自己の利益を追求してしまい対立関係に陥ってしまった。<br /><br /><2>プロジェクトメンバー全員がオーバーワーク稼動<br /><br />　　続いて考えられるのは、無理な短納期要望を受けて、プロジェクトメンバー全員がオーバーワークであった。もちろん、お客様からは厳しい低コスト要望があり、ぎりぎりの人数でやらざる得ない状況にあった。メンバーには、過労による疲労感、ストレスがまんえいしていた。そんな状況で、全体を思う心の余裕がなく自己の利益のみしか考えられない状況に陥っていたのであった。<br /><br />　やはり、分散型開発を行う場合は、しっかりとしたコミニケーション計画をプロジェクト内で規定して、理念を共通化させ、信頼関係を構築していく事が重要ではないかと感じます。そして、利害関係が対立した時はどちらが、Win-Loseになるのではなくて、互いがWin-Winになる別の案を模索するべきだと考えます。その為にもメンバーには、全体の利益が個別の利益に繋がることを理念として共有化させることが重要ではないのだろうか。よって、メンバーの精神状態を常に正常な状態に保つ為にも、無理な残業や過度なスケジュールを引いて追い込むのは、やめるべきなのである。<br /><br />２．長期化する内部進捗ミーティング<br /><br />　このプロジェクトを管理している一人のＰＭは、１日２回の進捗ミーティングをプロジェクト内で行う。業務が開始して１時間後と定時終了後に行うのが日課になっているのであった。このミーティングは、システム開発メンバー全員で行い、その日の進捗状況、遅れや問題点を報告するものであった。形式としては、一人ずつ順番に報告していく形を取っていくものであった。その報告に対して、ＰＭが一人ずつにアドバイスをして問題を解決していく形をとっていた。この手法は、問題点をプロジェクトメンバー全員で情報共有ができ、全員で問題解決をしていく姿勢にしてチームの団結力を高める効果を狙うものであった。<br /><br />　ところが、報告するメンバーが１０人程度いるので、長時間、拘束されるミーティングになってしまった。まず、進捗報告の準備に３０分程度かける。そして、１回のミーティングが平均３０分くらいなのだが、長くなると１時間、２時間と行われる時がある。ひどい時は、１日の半分が進捗ミーティングをしている時があった。特に、スケジュールの遅れや問題が複雑化する程、議論が長期化する傾向にあった。これの弊害として、問題のなかったメンバーやスケジュールの遅れのなかったメンバーまで、この進捗ミーティングが原因で遅れることになってしまった。まさに本末転倒な事態になってしまったのである。<br /><br />　理想の進捗管理とは、「誰もが容易に進捗状況を可視化することができること。問題点があれば情報は皆で共有すること。問題解決は、最小限の利害関係者で解決するようにして、早期に情報公開をすること。」、と私は考えます。前段で紹介した事例のような、定期的に皆を集めてミーティングする事は大事だが、それが頻繁になると本来やるべき作業にも影響が出てくるのは当然である。その為にも、進捗管理を工夫して効果的で時間の掛からないものにするべきだと考えます。<br /><br />＜最後に＞<br /><br />　分散されたプロジェクトのその後・・・<br /><br />　このプロジェクトは、納品機能をいくつかに分け段階的にリリースをすることになっていました。１段目のリリースは、多少のトラブルはあったものの無事に終えました。そのタイミングでメンバーが減少し、再び分散された開発体制が統合されることになりました。その後、ＰＭ体制も一本化されてチーム間で失った信頼関係も取り戻すようになりました。それは、指揮系統が統一されたのと、プロジェクトが収束することによって残業時間も減り、スケジュールにも余裕が出てきたことがあり、チーム内にもゆとりができた事が大きな要因だったのかと感じる。今までは、分断されたことによってチーム連携（コミニケーション）する工数が発生して、その連携によるトラブルも多発していた。それが、解消されただけでも開発工数の削減に繋がりスケジュールにも余裕が出てきたのであった。やはり、お金を掛けて無理してでも「ワンフロア」で開発体制を構築することが、開発工数の削減に繋がるのではないかと感じました。<br /><br />ITコーディネータ　森木　康太まいど！メンバーtag:blogger.com,1999:blog-7279463.post-27627810717883499222007-02-17T16:30:00.000+09:002007-04-01T18:56:01.001+09:00＜はじめに＞<br />　これまでの考察で、ＩＴＣが企業と契約を結ぶに至るプロセスにおいて、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がいかに役立つか、その実践的手法について明らかにしてきた。<br />　前回は、「検証ユニット方式」実践の第１回転めに専門家派遣制度（各都道府県に設置された中小企業支援センター等が実施する助成事業）を活用し、より潤滑に契約獲得に結びついた事例を紹介した。<br />　今回の事例もまた、専門家派遣制度を活用した契約獲得例であるが、第２回転め以降に経済産業省の「ＩＴ活用型経営革新モデル事業」という別の公的な助成制度の活用を組み合わせて、顧客便益を大幅に向上させているところに着目いただきたい。<br />　毎度のことであるが、仕事の発端はささいなキッカケである。本事例（Ｃ社＝小売業とする）は、ＩＴＣのＹ氏が、共通の知人であるＶさんから、販売管理システムの刷新を検討しているＣ社のマネージャを紹介されるところから始まる。<br /><br />＜１回転めの経過＞<br />　１回転めの留意点については、前回までの考察とほぼ同じであるので、詳しいことは省略するが、肝要なことはやはり、「はじめに成果ありき」を鉄則して、第１回転めにできるだけ相手にお金を使わせないことである。信用創造に重点を置く初期段階にあっては、特に相手が価値や意味を理解できない箇所にお金をかけさせるべきではない。<br />　本事例では、Ｙ氏は専門家派遣制度の枠内で助言事業を行ったわけであるが、Ｃ社が新たに購入しようとしていたＰＯＳシステムについて、Ｃ社経営陣の意思決定を覆す決定的なレポートを作成した。そのあらましは以下のとおりである──。<br />　Ｃ社はＬ社製のＰＯＳシステムを採用していた。が、各端末がＣ社の直営する各店舗でスタンドアロンで稼働していたために、売上の情報を集めるのに、数年前まではフロッピーディスクを回収しなければならなかった。ここ２?３年は、売上情報をネット上で稼働する別のＡＳＰシステムに入力し直してサマリーだけは本社で把握できるようになったが、単品管理はできておらず、ＰＯＳとは名ばかりになっていた。<br />　それでもＣ社は、新規出店のたびにＬ社製のシステムを購入していた。同じメーカーのもので統一しておくほうがなにかと安心だというのが経営トップの判断根拠であった。他メーカーのシステムが混在すると、予測不能の混乱が起こりそうで不安だというわけであるが、これがＹ氏の目には明らかに不合理に映ったのである。<br />　Ｌ社のＰＯＳは、スタンドアロンで動いているのだし、導入年代が異なるためにソフトのバージョンがちがっているものもある。日々の売上実績はそもそも別のシステムに店長が手入力し直している現状では、他メーカーのシステムが混在したところで大した混乱が起きるはずがなかった。<br />　そこでＹ氏は、将来は全店の業績をネット上で即時に一元的に管理することを命題として、それが可能なシステムにリプレースすることをＣ社に進言した。そのニーズを完全に満たすシステムはその時点では存在しなかったが、開発できそうなソフトハウス（Ｍ社とする）はあった。うまくいけば節約効果は数百万円に上ることが素人目にも明らかであった。そこで、１回転めの検証ステップとして、まずＣ社でいちばん規模の小さい店舗にＭ社のＰＯＳシステムを採用し、Ｌ社にこだわる必要がまったくないことを確認したのである。<br /><br />＜２回転めの経過＞<br />　２回転めの留意点についても前回までの考察とほぼ同じである。すなわち、１回転めで得られた小さな信用と小さな報酬をテコに、もうひとまわり大きな信用と報酬につなげるという点である。<br />　１回転めの助言活動で、数百万円に上る目に見える節約効果を実現したＹ氏は、Ｃ社のニーズを完全に満たすシステムをＭ社に開発させることを提案することになるのであるが、このときにＹ氏は、経済産業省の「ＩＴ活用型経営革新モデル事業」（以後、単にモデル事業と呼ぶ）の活用をＣ社に勧めたのである。もちろんＣ社のうち誰ひとりとしてこのような助成事業について知る者はなく、はじめはいぶかしげな反応だったわけだが、コンサルタントであれば誰でもこのような中小企業支援策についての趣意は心得ていて、その活用を促進するミッションを負っているといえるだろう。<br />　Ｙ氏の提案によれば、Ｃ社のニーズに完全に満たす独自のシステム──すなわち、グループとして運営する多くの店舗の稼働状況を、インターネットを介してリアルタイムに本部で一元的に管理できるシステム──を、新たにＭ社に委託開発すれば、満足度の低い既製のシステムを使うよりも劇的にコストが削減できるとのことである。しかも新たに開発するそのシステムは、ネットやモバイルを活用した新規性の高いシステムであったため、その開発費について国から助成金が出るかもしれないとなれば、Ｃ社にとってはたいへん魅力的な提案である。<br />　２回転めの検証ステップとして、モデル事業に応募する前提条件として、Ｙ氏の助言に従えば本当にＣ社のニーズを満たすシステムが開発可能なのかどうか、Ｍ社にプロトタイプを作成させて実地でテスト稼働させる必要があった。この過程でＹ氏の“まいどフォーラム”を中心としたＩＴＣの人脈（ＩＴＣには大別して経営系とベンダー系があるが、そのうちベンダー系のＩＴＣ）が役に立ったことを書き添えておく。<br /><br />＜３回転めの留意点＞<br />　モデル事業に応募するための事業計画を作成する頃には、Ｙ氏の助言に寄せるＣ社の期待はかなり大きなものになっている。ただでさえ数百万円の節約効果のあるシステムが、意外に低い費用で新たに開発できることがわかり、しかもその半分を国が助成してくれるというのだから当然といえば当然である。逆にいえば、Ｙ氏としては、この期待をここで裏切るわけにはいかないことになるから、モデル事業として採択されるかどうかが３回転めの肝となる。<br />　通例の「検証ユニット方式」でも、ちょうど３回転めあたりが「経営戦略」であるとか「ビジョン策定」という意識を経営者側に抱かせる段階であるから、モデル事業応募を名目として、ここで事業計画作成に着手できることはＹ氏としても都合がよい。しかし、計画作成は必ずしもＹ氏の得意とするところではないため、またここでも“まいどフォーラム”を中心としたＩＴＣ人脈が活躍することとなる。公的機関（この場合は近畿経済産業局）向けの書類は、書式が煩雑であったり、言い回しが微妙であったり、数字が厳格であったりするために、慣れていないと摩擦の元となるのである。そこでＹ氏は“まいどフォーラム”の提唱する「ちょいサポ」（それぞれのスペシャリストが自分の得意な分野に関して少しだけサポートするという意味）という仕組みを使って、別のＩＴＣ（公的支援活用を得意とする）に応援を依頼したのである。<br /><br />＜３回転めの検証＞<br />　結果として、Ｃ社の事業計画は、競争率５倍以上の狭き門をくぐってめでたくモデル事業として採択され、Ｙ氏はＣ社の期待に応えることができた。モデル事業に値すると進言したＹ氏の仮説が、公的機関によって検証され、実証されたわけである。ではここでＹ氏はお役ご免となるかというと、もちろんそんなことはない。近畿経済産業局には事業の進捗を報告するための書類は、Ｙ氏とその仲間のＩＴＣの助言がなければ、とても中小企業家自身の手に負えるものではないし、開発委託先ベンダーとの交渉も簡単ではない。今後展開する大きなプロジェクトにとってＹ氏は必要不可欠な存在となったわけである。<br /><br />＜結論＞<br />　モデル事業として採択された事業計画に基づいて、Ｃ社のプロジェクトが進行していくわけであるが、このモデル事業が完結するまでが「仮説?検証サイクル」の４回転めにあたるといえる。<br />　さらに、モデル事業終了後も、このモデルを世間に広める（Ｃ社の知的財産となったモデルを他社向けにカスタマイズして販売）というプロセスがあり、それが５回転めになる。<br />　このようにＹ氏は、小さなきっかけから始まり、だんだんと大きな回転になっていくプロジェクトにおいて、各フェイズで立てた仮説が絵に描いた餅にならないように常にコーディネイトし続けるミッションを負うことになるわけである。つまりＹ氏は、「検証ユニット」の描く成功パターンどおり、めでたくＣ社と長期に及ぶ顧問契約を締結することができたばかりか、ＰＯＳシステムの有効活用を図りたい他社からも声のかかるコンサルタントとなったわけである。<br />　本事例は、公的な中小企業支援施策に関する若干の予備知識があれば、それを「検証ユニット」にうまく乗せるだけで、実績や信用に乏しいＩＴＣであっても、よりスケールの大きいプロジェクトに参画できるという好例を示すものであろう。<br /><br />ＩＴコーディネータ／永田祥造ながたtag:blogger.com,1999:blog-7279463.post-1142091601821502232006-03-12T00:37:00.000+09:002007-04-01T18:56:01.001+09:00──専門家派遣制度を活用した成功事例──<br /><br />＜はじめに＞<br />　独立したばかりで実績がほぼ皆無に等しいＩＴＣが、何の信用もない状態で、企業と顧問契約を結ぶに至るプロセスにおいて、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がいかに役立つか、その実践的手法について前回の論文で考察した。<br />　今回は、「検証ユニット方式」の実践にあたって、その第１回転めに専門家派遣制度（各都道府県に設置された中小企業支援センター等が実施する助成事業）を活用し、より潤滑に契約獲得に結びついた事例を紹介したい。<br />　前回同様、仕事の発端はささいなキッカケである。本事例（Ｂ社とする）は、新米ＩＴＣのＹ氏が、個人的な友人のＷさんからＢ社の専務を紹介され、「とりあえず話しだけは聞いてやってもいい」という程度の了解で会社訪問することができたのであった。<br /><br />＜１回転めの留意点＞<br />　検証ユニット方式では、「はじめに成果ありき」が原則で、第１回転めにできるだけクライアント企業にコストの負担をかけないことが重要である。これは相手先がＩＴＣがについて何も知らず、まったく信用がないという前提に立っている。実際、Ｂ社の社長も専務も、Ｙ氏とは初対面であり、経歴や実績等についても詳しく知らされず、明らかに怪訝そうな顔つきで最初の訪問を迎え入れたのである。<br />　Ｙ氏は、ひととおり自らの強みや仕事の進め方を説明したが、ＩＴ化の説明にはどうしても専門用語が多く混じりがちで、それが中小零細企業から毛嫌いされる原因になることも理解している。そこで、あまりＩＴをＩＴとして意識させず、とにかく「公的な制度であること」や「県から補助金が出ること」、「要するに制度を活用すると得だ」ということを強調し、制度の活用を薦めることにしたのである。<br />　中小零細企業の場合、ＩＴに対してそもそも理解が追いつかない面があるのは事実であろう。１回の訪問で、ＩＴ化のメリットを実感してもらうのは困難といえる。かといって、不安心理につけこんで「おたくは遅れてますよ、ヤバいですよ」という論調は厳に慎まねばならない。その点、専門家派遣のような公的制度の場合、中味が理解されていなくても信用されやすいのは事実である。それには甘えさせてもらってよいであろう。専門家派遣制度は、企業側の費用負担が軽い割に回数や時間がきっちりと定められていて、いったん了解されると少なくとも３?５回は会社を訪問して経営陣や担当者と十分なコミュニケーションを図れるというメリットがある。企業の負担より県の補助金のほうが大きいため、コストがかかったという意識はまったくないに等しく、Ｙ氏がよっぽど退屈でないかぎり「なんか得した」という印象が残るはずである。だからこのフェーズでは、３?５回の訪問のあいだに「もっとつきあえば、もっと得なんだ」という確信を相手に与えられるかどうかが重要となる。そのためにも、「お金をかけずに手っとり早く改善できる工程はどこか？」を見つけ出し、派遣終了後に取り組んでみたくなるような具体的な提案を出せることが不可欠といえる。<br /><br />＜１回転めの検証＞<br />　検証ユニットの第１回転めでは通例、「はじめに成果ありき」の原則に基づいて、ＩＴＣにもある程度「汗をかく」ことが求められる。しかし、専門家派遣制度は純粋な助言事業であるから、専門家自身が自ら「手出し」をしてデータベースを設計したり、ホームページをデザインしたりということはしない。したがって、専門家派遣制度による助言活動を第１回転めとした場合、机上の空論が先行してしまう恐れがあると言わざるを得なくなる。そこでＹ氏は、「即効性があって明らかに目に見える成果」は何かと考え、キーボードショートカットを使って入力速度を上げさせたり、フロッピーディスクの使用を禁止してＬＡＮ上でファイル共有を学ばざせたり、プロバイダを低価格なところに乗り換えて通信費を節約したりといった実践型のアドバイスも忘れなかった。わずかとはいえ、それでも月額換算で１万円程度の費用が浮いたのである。さらに一方で、助言活動の成果物として、現状の基幹システムの非効率を指摘し、事務員４名の人件費の無駄が月額換算で合計１０万円を超えるという実証データを経営者に伝えた。<br /><br />＜２回転めの留意点＞<br />　Ｙ氏は、現行のシステムが導入から６年を経過していることや、ソフトを開発したベンダーが倒産してサポートを受けられない状態であること、業務の流れにシステムが合わなくなり、必然的に数々の弊害を生んでいることなどから全面リプレースを急ぐ必要があることを痛感していた。さいわい、助言活動を通じて社長や社員にもシステムの弊害が理解されている様子であった。<br />　Ｂ社は、文房具を中心とする事務用品を扱う卸問屋で、従業員は１２名。うち４名が女性の事務員であった。事務員は、商品の梱包や棚卸しなどの業務も行うが、一日の大半はパソコンに向かってデータ処理に費やしている。業種特性として、他品種で小ロット、商品単価が低いがデータ数は大量であるため、データ入力業務の負荷が非常に高く、システムの不具合によって被るロスは非常に大きかった。<br />　専門家派遣制度を利用すると、企業の負担する金額の３倍の報酬がＩＴＣに入ることになるので、その間は“成果＞コスト”の実現は容易である。１回転めが終わった段階で得られた「小さな信用と小さな報酬」をテコに明確な課題を経営者に示すことができていれば、次に訪問する名目はとりあえず得られる。<br />　ここではシステムの全面リプレースという大型の提案を掲げて第２回転めに入るわけであるが、今回のケースでは、この第２回転めが事実上の１回転めだと考えなければならない。すなわち、まだ目に見える形での成果が乏しいために、提案にも説得力が乏しいのである。Ｙ氏には、リプレースを実行すれば相当の効率化ができるという確信もあったが、性急にそれを進めたのでは従業員の意識が追いつかないことも明白であった。<br /><br />＜２回転めの検証＞<br />　そこでＹ氏は、後に販売管理システムとも連動することになる見積書作成システムを先行して導入することとし、その間のシステム費用（開発費まで含む）は自らが肩代わりして無償とすることにした。従来は見積書作成システムは存在せず、毎日のように営業マンがワープロソフトを使って各自で作成していたため、Ｂ社にとっては「うまくいったら儲けもの、うまくいかなくても損はしない」という筋書きである。無論、導入過程でのＹ氏のコンサルティング・フィーも無償である。<br />　それだけのリスクを背負ってでも実現したかったＹ氏の狙いは、男性営業マンたちが新しいシステムで効率よく見積書を作成している真横で、女性事務員たちが従来のシステムで納品書発行に悪戦苦闘しているという対比を、全社員に「見せつける」ことであった。見積書を作成するために使用する品名マスターは販売管理で使用するものと同じであるし、入力手順もほとんど同じである。「これができたらあれもできる」式にＢ社を納得させることを狙ったのである。<br />　見積書発行システムは、従来のシステムから商品マスターを移行する作業に手間取り、着手からサービスインまでに２ヶ月、そこから営業マンを教育し、軌道に乗せるまでに３ヶ月を要した。しかし、いったん慣れてしまうと、６年前に導入された従来システムと比べてレスポンスが格段に速く、効率の差は歴然としていたために、「早く販売管理のほうも新しいシステムに替えてほしい」という声が事務員さんたちから上がるまでに、さほど時間はかからなかったのである。<br /><br />＜３回転めの留意点＞<br />　Ｙ氏が最初にＢ社を訪問してから８ヶ月、Ｙ氏の訪問回数は20回を超えていたが、Ｙ氏はＢ社に対して直接費用を請求したことは１度もなかった。しかし検証ユニットの３回転めには、ＩＴ化は企業の中枢的な基幹業務に及んでくる。経営トップの業務改善にかける意気込みを確認する意味でも、基幹システム構築に必要な予算組みを行い、さらに自分の貢献度に見合う報酬を正当に要求していくことが肝要となるのである。<br />　見積書作成システムを実際に動かしていれば、その仕組みを販売管理全般に応用したときにどれくらいの効率化が図れるか、それくらいのソロバン勘定は経営者の頭の中にできている。Ｙ氏はそこへさらに、経営戦略策定という新たな着眼点を与え、中期的にはネット上での受注システムとも連動する営業支援ツールとして活用していくのだというビジョンを示した。<br />　このフェーズでは、これから後にも常に“成果＞コスト”が成り立ち続けることをアピールすることが大切である。ＩＴ化とはすなわちＩＴを企業文化として熟成して根づかせていくことであり、外部ＣＩＯとしてのＩＴＣが抜けたらその戦略構想全体が骨抜きになってしまうというくらいの存在感を示す必要がある。少々「脅し」気味になってもかまうことはない。ここでいかに自己の役割を大きく見せられるかどうかが、継続的な顧問契約を結べるかどうかの分かれ道になるのであるから、背に腹は代えられないであろう。<br /><br />＜結論＞<br />　小規模事業者は、大企業のように何人もの専門家を雇うことは不可能で、せいぜい１人か２人のインテリジェンスが「よろず相談」の窓口になっているという現状は前回も述べた。フリーで独立することを志すＩＴＣは、ＩＴを切り口として、まずこの役割を果たすことが求められるのである。われわれ“まいどフォーラム”は、そこにＩＴＣの活躍すべきフィールドがあると考え、そのために極めて有効なツールとして「検証ユニット方式」を提唱するのである。<br />　結果としてＢ社では、Ｙ氏が最初に訪問してから１１ヶ月後という早さで基幹業務の全面リプレースに成功した。ハードの選定と調達、ネットワークの構築、ソフトの設計と開発、ウェブサイトのリニューアルとマーケティングへの活用‥‥等、ＩＴに関わるあらゆるＢ社の意思決定がＹ氏のアレンジメントによって行われ、当然Ｙ氏は、めでたくＢ社と顧問契約を締結することができたのである。<br /><br /><br /><br />ITコーディネータ／永田祥造まいど！メンバーtag:blogger.com,1999:blog-7279463.post-1142065517290777652006-03-11T17:23:00.000+09:002007-04-01T18:56:01.001+09:00＜はじめに＞<br />ここでは、独立したばかりで実績がほぼ皆無に等しいＩＴＣであるという前提で、すなわち名前が売れているわけではなくブランド力もない、つまりＩＴＣという資格がある以外には何の信用もない状態で、企業に入りこんで契約を取っていくためにはどうすればよいか、その過程で、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がいかに役立つか、その実践的手法を考えてみたい。<br />　個人で活躍する多くの独立系ＩＴＣにとって、仕事はほんのささいなキッカケから始まる。友人の勤め先、親戚のコネ、前に努めていた会社の取引先‥‥等、である。本事例（Ａ社とする）は、新米ＩＴＣのＹ氏が、某異業種交流会でＡ社の社長と名刺交換をしたところから始まる。２度、３度と顔を合わせて世間話をしているうちに、「ちょっとウチのシステムを見てほしい」という話題になり、とりあえず会社訪問することができる運びになった。<br /><br />＜１回転めの留意点＞<br />　検証ユニット方式では、「はじめに成果ありき」が鉄則で、第１回転めにできるだけ相手にお金を使わせないことが特に重要となる。つまり、「お金をかけずに手っとり早く改善できる工程はどこか？」に神経を集中すればよいことになる。<br />　とりあえず「ただ働き」の覚悟が必要で、実際に「骨折り損のくたびれ儲け」に終わることもないとは言えない。しかし、もともと情報が入りにくい小規模事業者の場合、「ちょっとここを直せばすぐに経費削減（または売上アップ）に直結するポイント」というのは案外簡単に見つかるのである。<br />　Ａ社の場合は、ネットによる通販がまったく活かされていないことであった。Ａ社は、自社ブランドで海産物を製造加工販売しており、業者向けの卸と個人顧客向けの小売が半々の中堅企業である。地場では知名度もあってローカルなブランドとしては一定の地位にある。Ａ社は過去に、大手のショッピングモールに出店したこともあるし、ホームページも相当な金額で開設している。ただ、時期が早すぎたことも災いして、コストばかりが大きくて成果が伴わなかったのである。<br />　このように過去にやけどをしている会社の場合、そこへ「あといくらかけて‥‥」と言い出したのでは即座に門前払いとなる。しかし逆に、「ＩＴは金がかかる」という先入観があるだけに、１円もかけずに先に喜ばせて差しあげる手段がひとつでも浮かべば前途は明るいのである。Ｙ氏の第一印象は、「うまくやればもっと売れるのに‥‥。ああ、もったいない」というものであった。ネット販売で成功するための必須条件である「オンリーワン」をすでに満たしていたからである。<br />　そこでまずＹ氏の最初の提案は、報酬を歩合制とすることであった。現に売上が上がっておらず、経費がかかっているのなら、「売上が上がらなければお金はいらない」という単刀直入な提案は受け入れられやすい。現状の売上が５、経費が１０であれば、損失は５である。小学生でもわかる単純な計算だが、Ａ社の経営者には撤退の意思はなく、なすすべもなく損失を出し続けている。ここへ、経費を１０のまま、売上を５以上に上げる提案を出せば、まずは断られないのである。（売上を５のまま経費を５にする提案もできるが、これは得策ではない。）「これならどっちに転んでも損はない」という意識さえ植えつけることができれば最初の目的は達成である。<br />　Ｙ氏の第１ミッションは、お金をかけずにネットショップをテコ入れし、売上を伸ばすことである。０円でショップを構築する方法も考えられたが、実際に採ったのは、すでに垂れ流しになっている経費１０を、自分のほうへ回させ、売上５を保証する方法であった。「もし売上が下がったら自分が身銭を切ってでも弁済します」と言い切ったのある。ここにリスクがある。リスクはあるが、小規模事業者をターゲットとして収入を上げていくなら、コンサルティングだけでは厳しいのも事実である。ある程度はプラクティカルなノウハウをもっている必要はあろう。リスクをかぶるだけでなく、汗をかくことも求められる。中小企業の経営者には、そもそもそうでないと相手を信用しないというメンタリティーがあるのだから仕方がない。逆に、このくらいの自信と熱意がなければ、ゼロからスタートでは活路は見出せないということである。<br /><br />＜１回転めの検証＞<br />　Ｙ氏は自らホームページのデザインを手直しした。もともとあるページをそのまま使えるので、大きな負荷ではなかった。ＳＥＯ対策を施し、ログ解析用のスクリプトを組み込むなど、アクセスアップの手法としては基本的なものばかりだったが、Ａ社はそれさえも知らなかった。ホームページの手直しが終わった頃、Ａ社に既存の個人顧客にＤＭを出してもらうこととした。この際のＤＭの送料はＹ氏が負担し、文面もＹ氏が考えた。つまり、Ａ社は何もしなくてよいわけである。<br />　さいわい、ＤＭを出した直後に売上は急増し、しかも持続した。この期間のＹ氏の勉強量と実務上の試行錯誤は相当なものであるが、これらのノウハウは再利用可能な自分のノウハウになるのである。ともかく、これで「このＩＴＣに任せたら売上が伸びるかも」という仮説をとりあえず検証し終えたことになる。契約によって、売上の15％を自分の取り分とすることができた。これは毎月毎年継続的に受け取れるフィーであるから、変動はあるもののありがたい収入となる。このお金を再投資して、さらなる売上アップにつなげることもできるし、その他の業務改善に取り組むこともできるのである。<br /><br />＜２回転めの留意点＞<br />　さて、ここまでで得られたＡ社からの「小さな信用と小さな報酬」をテコに、ここから検証ユニットの第２回転めに入る。このフェーズでは、成果が出ている範囲内でコストを捻出すればリスクがないことを、しっかり説得することができなければならない。経費１０で、売上が１０なら、儲けはゼロなのだが、Ｙ氏が来るまではマイナス５だったのであるから、儲けはゼロでも成果はプラス５なのである。プラス５のうちの２や３を再投資に回したところで、会社にとっては損になっていないという理屈をしっかり納得させることが肝要である。当面の損失を回避できたからといって、そうやすやすと感謝していただけるほど中小企業経営者は甘くないからである。「単なるお人好し」と判断されてしまったら、足下を見られて「はい、ありがとう。さようなら」で終わる可能性が高い。ゆえに、少なくとも３ヶ月から半年がかりで業務改善と呼べるレベルの経営改革に取り組む意思があるかどうか、そのために多少のコストを捻出する気構えがあるのかどうか、トップの腹づもりを確認しておく必要が出てくる。<br />　Ｙ氏は、ネットショップの売上アップをテコに、受注処理の効率化に踏みこむことにした。これまでの受注処理は、電話でもＦＡＸでもメールでも、とにかく受注用の紙（決まった様式もない）に書き写して、それをそのまま加工ラインにまわすという原始的なやり方だったからである。少なくともネット受注に関しては、そのまま加工指図書に出力でき、完了と同時に送り状や納品書に出力できる仕様とし、その後、電話やＦＡＸによる受注をネット受注に合わせるかたちにすれば、失敗する心配がないのでＡ社の納得性も高まると考えた。これなら顧客データベースの一元化もできて一石二鳥である。<br /><br />＜２回転めの検証＞<br />　受注処理のＩＴ化は、着手から９ヶ月かかったが、たいへん大きな成果が出た。Ｙ氏は、はじめにネット受注をシステム化し、電話・ＦＡＸ受注のステップと対比してどれほど効率がいいかをまざまざと見せつけた。この「見せつける」という意識が小規模事業者には重要である。机上の空論を嫌うメンタリティーがある反面、鼻先にぶら下げられた獲物には俊敏に食いつくからである。いったん見せつけておけば、「この受注処理システムにはだいたい○○円かかりますけど、それ以上の効率化ができるっていうの、わかりますよね？」くらいで通じるものである。<br />　ネット受注をシステム化するにあたっては、システム開発のための費用がかかり、これはネットショップの売上改善で得られる歩合制の報酬を上まわるため、ここまでのＹ氏の収支は赤字であった。しかし、すべての受注処理のシステム化を成功させて得られる報酬を合わせればわずかながら黒字となる。検証ユニットでは、２回転めが終わるまで（期間にして約１年）は、儲けは期待しないほうがよいかもしれない。<br /><br />＜３回転めの留意点＞<br />　受注管理が軌道に乗る頃には、Ａ社は、他の業務のＩＴ化を別の業者やコンサルタントに相談しようとは思わなくなっている。逆にいえば、ここまでのステップで辛抱に辛抱を重ね、信頼関係を築いておくことが極めて重要である。３回転めには、ＩＴ化は企業の中枢的な基幹業務に及んでくるはずだからである。<br />　Ｙ氏は、ここまであえて口にしなかった「経営戦略」であるとか「ビジョン策定」「中長期計画」という小難しい言葉をようやく使い始める。経営者の側に戦略という意識がなかった間も、Ｙ氏の頭の中には当然、常に将来ビジョンが用意されていたわけであるから、ここで過去と将来の整合性を語っておけば、さらにＹ氏の印象は良くなるのである。はじめは聞く耳を持たなかった部課長クラスも、ここまで見せつけられれば、いよいよ本腰を入れて取り組んでくれるものである。<br />　このフェーズでは、これから後にも常に“成果＞コスト”が成り立ち続けることをアピールすることが大切である。「恩を売る」というといやらしく聞こえるかもしれないが、継続的な顧問契約を結びたいのであれば、自分が抜けたら元の木阿弥に戻る危険性を臭わせておく努力はやっておくべきであろう。その上で、基幹システム構築に必要な予算組みを行い、さらに自分の貢献度に見合う報酬を正当に要求していくことである。<br /><br />＜結論＞<br />　小規模事業者は、大企業のように何人もの専門家を雇うことは不可能で、せいぜい１人か２人のインテリジェンスが「よろず相談」の窓口になっている。（それさえも見つけられない気の毒な事業者も多い。）フリーで独立することを志すＩＴＣは、ＩＴを切り口として、まずこの役割を果たすことが求められるのではないだろうか。われわれ“まいどフォーラム”は、そこにＩＴＣの活躍すべきフィールドがあると考え、そのために極めて有効なツールとして「検証ユニット方式」を提唱するのである。<br />　結果としてＡ社では、Ｙ氏が最初に訪問してから１年半後という早さで基幹業務のシステム化に成功した。その手腕を評価されたＹ氏は、めでたくＡ社と顧問契約を締結することができ、システム運用を中心としながら幅広く経営革新の相談を受け続けているのである。<br /><br /><br />ITコーディネータ／永田祥造まいど！メンバーtag:blogger.com,1999:blog-7279463.post-1142065024521727302006-03-11T17:15:00.000+09:002007-04-01T18:56:01.001+09:00　　　　　　　　　　　　<strong>はじめに</strong><br /><br />　日本の中小企業やNPO法人でのITの活用は中堅、大企業にくらべて、大幅に遅れているといわれています。特に、関西では、「IT化の有効性」の認識が関東に比べて低いという調査結果もあります。また、「ITの理解、リテラシ」も中堅、大企業にくらべて低い場合が多いのではないでしょうか。<br /><br />「ITの理解、リテラシ」の低い組織に「IT化の有効性」の認識をしてもらう最良の方法は、ともかくITを使って、「役に立った＝コストが下がった、売り上げが上がった」などと実感してもらうことではないかと思います。<br /><br />では、ともかくITを使ってみてもらうにはどうしたらいいでしょうか？<br />ITに限らず、自分の知らないもの、新しいものを買うときには、不安があるものだと思います。<br />「ITってほんまに役に立つの？」<br />「パソコンやソフトを導入しても、使いこなせへんのちゃうか？」<br />こういった不安を乗り越えやすくするための一つの方法は、初期コストをできるだけ下げることではないかと思います。<br /><br />　　　　　　　　　　<strong>「けちけちIT化」とは？</strong><br /><br />本稿でご紹介する「けちけちIT化」（造語です）は<br />「ま、使いこなせへんかっても、これくらいならええか！」<br />といえるレベルの初期投資でスタートできるIT化のアプローチのことです。<br /><br />とくに、われわれMAIDOフォーラムの活動圏である関西の人は総じて「けち」だといわれています。「怪しいものには金をださない。値切れるものはとことん値切る。」という感じです。<br />これは、ITCが小規模企業を支援する上で最初のハードルになっている場合も多いのではないでしょうか？<br /><br />ここでは、このハードルを越える一つのツールとして有効な、「けちけちIT化」のちょっとした実践例をご報告したいと思います。<br /><br />「けちけちIT化」実践のポイントは以下のようなことではないかと思います。<br /><br />　・顧客の実行可能性が最重要<br />　・成果は小さくてもいい<br />　・まずは、今あるものをつかう<br />　・必要最低限の性能でいいので、無料、格安のものを導入<br />　・労力、ストレスは最小限に<br />　・短期集中<br /><br />まず、楽に、IT化の成果を実感してもらうことが目的なのです。<br /><br /><br />　　　　　　　　<strong>「けちけちIT化」の具体例</strong><br /><br />以下、あるNPO法人でのIT化を支援した事例の導入部分をご紹介します。<br /><br />【テーマの選定】<br />ヒアリングの結果、いくつかテーマがありましたが、NPOの会報誌を発行しているチームの責任者のIT化の意欲が高く、メール（メーリングリスト）を利用するだけで業務効率の向上が見込めたので、これをテーマとしました。<br /><br />【IT化前】<br />会報誌の編集は以下のような流れで行われていました。<br />　　　原稿を電話、口頭で１０人程度に依頼<br />　　　手書き、または家のパソコン、ワープロで作成された原稿をFAXや手渡しで回収<br />　　　これを、編集チームでFAX、電話でやりとりしたり、会議を何回か開いて編集、チェック<br />　　　版下を切り貼りで作成して印刷に出す<br /><br />【IT化の提案】<br />この編集作業をメーリングリスト上でやることを提案しました。<br />具体的には、会報誌のメーリングリストをつくり、そこで原稿をMSWordでやり取りして完成まで持っていくというやり方です。<br />具体的には、yahooグループという無料のメーリングリストを使いました。メールアドレスをもっていない人にはyahooメールという無料のメールアドレスを、パソコンをもっていない人には、パソコン購入とインターネット接続をしてもらいました。<br /><br />【IT化後の成果】<br />この方法をとったことで、これまで、編集中に何回も会議をもって作業していたのがほぼすべて在宅で可能になり、ボランティアの方々の負担か大きく減りました。<br />また、電話や口頭で連絡がつかないなど、滞りがちだった流れも、メールでの非同期コミュニケーションになることでスムースに進むようになりました。<br /><br />【その後】<br />このことで、メールをつかって、仕事をすることのメリットが理解され、他のチームや、プロジェクトでもメーリングリストが利用されるきっかけになりました。<br />その後のサイクルでは、ホームページ改訂やイントラネット構築へと進んできています。<br /><br /><br />　　　　　　　　　　<strong>「けちけちIT化」の詳細</strong><br /><br />最初にあげたポイントについて、上記を例に具体的にご説明しようと思います。<br /><br />【顧客の実行可能性が最重要】<br />テーマ選択にあたっては、顧客とITCで実際に実行できる、という見通しがあることが必須です。具体的には「やる人＝やる気があり、やれる人」がいて、途中に引っかかりそうなハードルをITCがクリアする（または、クリアしてもらう人をつれてくる）手段をもっていないと失敗します。上記事例では、責任者の方がパソコンの利用に非常に意欲的で、過去にMS-Dosのパソコンを使っていたと聞いて、大丈夫だと判断しました。<br />また、yahooメールやyahooグループについては、私自身他の案件ですでに使ってことがあり、その特徴や操作を把握していました。　　<br /><br />【成果は小さくてもいい】<br />他にテーマとして、ホームページの改訂や、会員データベースの整備などがあり、こちらの方が、成果としては大きなものが期待できましたが、実現までの期間、必要なリテラシや労力、ソフト購入費などを勘案して、後回しにしました。<br />最初は、「ITの有効性」を理解してもらうことが目的ですので、まずは、楽に、早く成果がでることが最重要です。<br /><br />【まずは、今あるものをつかう】<br />パソコンやソフトの新規購入には大きな金銭的負担がかかるので、所有のハードとソフトについてヒアリングをしました。すでに、チームの数名の方はパソコンで原稿を清書したりしていました。<br />また、個人的にメールを利用している人もいました。<br />すでにスキルを持った人がいるということは、支援するITCの労力を考えると非常に重要です。<br /><br />【必要最低限の性能でいいので、無料、格安のものを導入】<br />キーメンバーの方はパソコンを持っておらず、購入したいと考えていました。<br />型落ちの格安のパソコンと中古のディスプレーを代理で購入しました。<br />メールアドレスや、メーリングリストは無料サービスを利用しました。<br />こういったとき、気をつけることは顧客の予算は最大限に利用することです。<br />たとえば、パソコンに１０万だす気があれば、５万で本体を調達し、プリンタ、ADSL、Officeソフトまで購入してしまうことです。決して、５万でできますよ。と本体だけ購入すべきではないと思います。<br /><br />【顧客の労力、ストレスは最小限に】<br />パソコンの初期設定や、インターネットの契約、メールやメーリングリストの登録などは、ITCが代行しました。<br />設定や登録は１回限りなので、初心者の方の支援の場合は最初はスキップする方がいいと思います。<br />こういった作業は、ITCが代行すれば短時間で終わりますが、そうしないと、そこでくじけてしまうことが多いからです。<br />必須スキルとして、MSWordでの作成とメールに添付して送る方法、開く方法のみに絞ってマスターしてもらいました。<br /><br />【短期集中】<br />人間のやる気は時間の経過とともにどんどんなえてきてしまうのが普通ではないでしょうか？<br />そのためにはITCの労力は最初に短期集中で投下すること、短期に完了するための段取りと必要にせまられるような開始タイミングを選ぶといったことが重要だと思います。<br />上記事例では、パソコンの購入、設定やメーリングリストの開設もできるだけ急ぎ、キーになる方には半日対面でMSワードやメールの使い方をサポートしました。また、メールアドレスの登録やインターネットプロバイダーとの契約などは、本人と話をしたその場でパソコンに向かい、必要事項を聞きながら手続きを代行したりしました。<br /><br /><br />　　　　　　　　　　　　　　　<strong>結論</strong><br /><br />これまでMAIDOフォーラムで研究しきてている「検証ユニット方式」とは、まず最初に実行し、成果をだし、その次に考えて、さらに投資をして、実行し、成果をだすという拡大スパイラル式にIT化をすすめようという考え方だと私は理解しています。<br />「けちけちIT化」は独立ITCが、「検証ユニット方式」を用いて、小企業やNPOなどの支援をする場合の最初のパターンの一つとして有効ではないかと考えます。<br />「ITの理解、リテラシ」や「IT化の有効性」の認識の低い組織にいきなり、経営戦略や情報化戦略の話をしても、２・３回の会議、いや講義で、「わからん、やる気なくなった」となるのが落ちです。そういう組織に対しては、今あるものや無料のものを利用して、最小限のお金と労力で、ともかく成果を実感してもらえることが有効です。<br />まず、「IT化の有効性」を認識してもらい、それをきっかけに「ITの理解、リテラシ」とモチベーションを向上させつつ、成果を出しながらレベルアップしていくことが可能になるからです。<br /><br />しかし、こういった支援をする場合、ITCは「こうすべき」とわかっているだけでなく、実際に顧客が成果をだせるまでの具体的な手段とスキルをもっていることが必要です。<br />たとえば、無料や安価に利用できるソフトやサービスの知識と利用スキル、ヒアリング、ファシリテーションや小さなプロジェクト推進のノウハウ、などです。<br />さらに、コスト負担を抑えるには、アドバイザー制度など公的支援の仕組みの活用も有効でしょう。<br /><br />これから、そういった分野についても、実践ノウハウのご報告ができればと考えています。<br /><br />　　　　　　　　　　　　　　　　　　　　　　　　　ITコーディネータ／布　俊晴まいど！メンバーtag:blogger.com,1999:blog-7279463.post-30244914919946878122007-03-03T16:39:00.000+09:002007-04-01T18:56:01.000+09:00＜はじめに＞<br />　これまでの考察で、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がＩＴＣの収益モデルとしていかに有効であるかという３つの具体例を挙げた。<br />　ここまでは、検証ユニットの初期段階（１回転めから３回転めくらいまで）に比較的重点を置いてきたが、今回は、ユニットが４回転め、あるいは５回転め、すなわちＩＴ化のプロセスが中盤以降にさしかったＤ社（不動産の有効活用支援）の事例を取り上げてみたい。<br />　Ｙ氏が関与しているのは、Ｄ社の事業の中でも特に有人立体駐車場の管理事業である。業界全体としてもほとんどＩＴ化の顧みられない分野で、せいぜいＰＯＳシステムを導入するくらいしかＩＴ活用の取っかかりはないと思われた。<br />　Ｄ社における検証ユニットの１回転めから３回転めくらいまでの経緯は、これまでの３つの事例とほぼ同じであるので、本事例ではその詳細は省略し、４回転め以降、Ｙ氏の関与を通じて、Ｄ社の経営トップがどのようにＩＴを企業文化として深化させていったか、そのプロセスを追うことにする。　<br /><br />＜１回転めから３回転めまでの概要＞<br />　有人立体駐車場では、料金計算やＰＯＳレジをきちんとシステム化しているところは極めて少数派である。平面の駐車場は、無人化することによって人件費節約効果が大きいため、システム化が進んだのであるが、立体駐車場のほうは、安全管理面の事情から「どうせ人が必要なんだから人にやらせたらよい」という発想になっていたのである。<br />　Ｙ氏は、このシステム化の遅れに注目し、料金計算とＰＯＳレジ機能を一体化したシステムの導入をＤ社に提案し、その開発過程においてベンダーを指揮し、複数駐車場の顧客（車両）一元管理を軌道に乗せた。２回転めでは、利用者の利便向上に大きく寄与するマイレージポイント制の導入を提案、３回転めにはタイムカードシステムまでを統合した労務管理システムの開発をプロデュースした。そのプロセスがすべて順調に推移したために、Ｄ社の経営者は、ＩＴの有効性を高く評価し、さらなる活用方法を自ら模索するまでになったのである。　<br /><br />＜４回転めの留意点＞<br />　検証ユニットも３回転めを終えるころになると、どんな懐疑的な経営者であっても、ＩＴ推進者たるＩＴＣをかなり評価してくれるようになっている。疑り深ければ疑り深いほど、目の前で実際にやってみせたときの「目から鱗」状態は劇的であるともいえるのである。<br />　そうすると今度は、特にＩＴＣがＩＴの効用について説得しなくても、「ＩＴでもっと他にやれることはないか」と経営者自身が自発的に考える姿勢になってくる。「自律成長過程」とも呼ぶべきフェイズ、ＩＴＣにとってはとても仕事がやりやすくなる時期がくるのである。<br />　経営者は、これまで否定していた「流行りのツール」を、「華美な宣伝文句」に踊らされて、突如としていろいろ試してみたくなったりすることになる。ＩＴＣとしては、これはこれで困りものなので、うまいこと手綱を締めてかかる必要が出てくるのである。もちろん、本当に良いツールであれば、経営者といっしょになって積極的に検討すべきなのは言うまでもないが、“まがい物”も多いので要注意である。<br />　Ｄ社で社長が自ら取りかかったのが、ネット経由で動作するＰＯＳレジの拡張機能としてのウェブカメラであった。Ｙ氏はカメラには疎いので、はじめは導入に消極的だったが、Ｄ社社長の言うには、駐車場のオーナーは、防犯対策としてのカメラには非常に興味を持つのだということであった。さらにＤ社社長は、自社の駐車場利用者がネットで一元管理できる強みを活かして、「ある駐車場で月極契約をすると、別の駐車場の時間貸しが無料になる仕組み」を考え出した。事業を営んでいないと思いつかない一種の発明（実際にも特許出願中）といえ、これにはＹ氏も舌を巻いた。<br /><br />＜４回転めの仮説＞<br />　４回転め（５回転め以降も同様）に入ると、経営トップがすでに納得し、自ら推進するフェイズに入るのであるから、ある意味（経営者からＩＴＣとしての手腕を評価していただくという意味）では、検証作業は重要ではなくなる。失敗は失敗として、そこから学び、企業文化としてＩＴが定着しているお手伝いをするのがＩＴＣのミッションになってくるという具合に、仕事の中味が変質してくるはずである。利益向上に寄与すればＩＴ化は成功、寄与できなければ失敗という、杓子定規な判断から脱皮しなければならないのである。事実、Ｙ氏が関与して以降、Ｄ社の業績は順調に伸びており、もはやＹ氏自身も、ＩＴの実効性という面での評価は求めることもなかった。<br />　そこでＹ氏は、Ｄ社社長に、経済産業省の推進事業である「ＩＴ経営百選」に応募してみることを勧めた。「これまで積み上げてきた自社のＩＴ文化がいかにすばらしいか、あるいは、どこが欠けているか」に関して、外部の評価を受けてみることを勧めたのである。<br />　あたりまえのことであるが、単に儲かっているとか儲かっていないとかいう基準では「ＩＴ経営百選」には入れない。ＩＴを有効に活用して経営の改善に結びつけているか否かが有識者によってチェックされるのである。もしこれで入賞できたとすれば、Ｄ社のＩＴ化は一過性のものではなく、企業に文化として根づいていることが客観的にも裏付けられることになる。この提案はＤ社社長にも快く受け入れられ、Ｄ社の「ＩＴ経営百選」応募が決まった。　<br /><br />＜結論＞<br />　もしＤ社が「百選」から漏れていたら、Ｙ氏の提案してきた数々の仕組みは「儲けにはつながっているけれど、会社の文化としては根づいてない」という評価になったわけである。しかしＹ氏の確信どおり、Ｄ社は、「ＩＴ経営百選」において最優秀企業に選ばれ、社名とともに評価項目毎の得点までが全国に公表された。今後のＩＴ化の貴重な指針が得られたと、Ｄ社社長も至極ご満悦だったのは想像に難くない。<br />　このように「検証ユニット」にしたがって、ＩＴＣが、ユーザー（企業経営者）の猜疑心を無理なく少しずつほぐすようにＩＴ化を進めていくと、当然の流れとして企業ＩＴ化は自律成長過程に入る。またそれを外側から歓迎して支えてくれるようなムードや枠組みも、ちゃんと国が用意してくれているわけである。さすが、“ｅ?Ｊａｐａｎ”を標榜するだけのことはあると言うべきであろう。<br />　ＩＴＣが、国策としてのＩＴ化推進の流れをしっかりと踏まえ、それに呼応するかたちで、中小企業企業のＩＴ化を進めていくならば、“三方良し”の結果が待っている。「検証ユニット」の初期の段階では、ＩＴＣは単なる便利ツールとしてＩＴを企業に伝えてよいのであるが、中盤以降では、経営者のマインドの変化も読みながら、企業文化としてＩＴを根づかせていく意識が欠かせない。本事例はその教訓となる好例であろう。<br /><br /><br />ＩＴコーディネータ／永田祥造ながたtag:blogger.com,1999:blog-7279463.post-16340327464770520162007-02-18T17:09:00.000+09:002007-04-01T18:56:01.000+09:00１．はじめに<br /><br />　　ITコーディネータとしての職務上、顧客企業からERP導入の支援を求められることは珍しくはないはずです。そのときみなさんはどのように顧客企業を支援していかれるでしょうか。もちろん、企業規模、導入目的、企業文化、業種、予算規模など背景の相違により、その進め方はさまざまでしょう。<br /><br />　　筆者は、最近自社におけるERP導入を統括し、幸い成功裏にかつこの種のシステム導入としては短期間に完成させることができました。このプロジェクトの成功要因（ITC的に表現すると“CSF”）を振り返って考えてみますと、一つひとつは「当たり前のことを実行する」に尽きます。しかしながら、実際の多くのERP導入は、当たり前のことを当たり前にできなかったために失敗したのではないでしょうか。当たり前のことを行って、あるいは行わせて、プロジェクトをリードする手腕こそITコーディネータにまず求められる責務であると筆者は考えています。<br />類似した業務に取り組まれるみなさんの参考となれば幸いです。<br /><br />　　なお、本稿では、具体的な名称や数値、商品名などは可能な限り伏せさせていただきました。より具体的な情報を求められる方は「まいど！フォーラム」を通してご遠慮なくお問い合わせください。<br /><br />２．本稿で扱うフェーズ<br /><br />　　本稿では、まずERP導入プロジェクトの立上げからERP選定までのフェーズ進め方を述べます。その後、社内承認を経て実際の導入へと進むわけですが、後のフェーズに関しては続編に記述します。<br /><br />３．事例対象とした企業とプロジェクトの概要<br /><br />　　以下は、筆者が取り組んだERP導入について、規模観をもっていただくための情報です。<br /><br />（企業概要）<br />　企業規模：　年間売上げ　約600億円、　従業員数　1,500名、　<br />　業種：　<br />　製造業（工場設備）対象のエンジニアリングと建設工事、システム開発/保守<br /><br />（プロジェクト概要）<br />　期間：　プロジェクト立上げ　から　ERP選定　まで　４ヶ月<br />　　　　　　ERP発注　から　システム稼動　まで　９ヶ月<br />　対象業務：　<br />　　事業の原価管理、調達、営業、経理、および決裁にかかわるワークフロー<br /><br />（付帯状況）<br />　システムの専門部署を除いて、社内全般にITリテラシーは非常に低い。<br />　２社合併に伴う基幹システムの統合を兼ねる。<br />　合併前の２社ではそれぞれオフィスコンピュータで原価管理、調達、経理などを<br />　処理していた。<br /><br />４．プロジェクトの立上げ　　・・・・・　プロジェクトとその方針を徹底的に周知する　・・・・・<br /><br />　　システム再構築の意思表明がトップから出されたのを受けて、対象、構築期間、進め方の手順など、企画書を作成しました。そして、社長が企画書を承認しプロジェクトをスタートさせました。<br /><br />　　プロジェクト立上げの宣言には次の項目を含めました。<br />　１） ERP導入の目的（原価管理の精度改善、仕掛り品の減少、など）<br />　２） 導入方針<br />　　（ベストプラクティスを導入し自社の業務プロセスを改善する、など）<br />　３） 社長をトップに置いたプロジェクト体制と実務メンバーの明示と周知<br />　４） カットオーバー日を明示した工程<br />　５） 概略の予算<br /><br />　　プロジェクトの周知について：　プロジェクトの立上げは社長自ら経営会議など社内で公式に宣言します。当該プロジェクトを知らないことが企業内では職務怠慢と見られるまでに、徹底したプロジェクトへの認知を、役員や幹部社員にしてもらう必要があるからです。ERP導入はトップダウンで扱うべき性格を本質的に持っています。なぜなら、多くの社員にとって業務の仕方は変わらないことが心地よく、変えることは個々の社員から必ず抵抗を受けるからです。ITCにとって社長以下の役員や幹部からの支持を得続けることがプロジェクトの成功に必須です。企業幹部にも、当然ですが、プロジェクトに対する義務感と責務感を持ってもらわなければなりません。プロジェクトへの協力義務について、社長や役員の口から折に触れて全社員に繰り返し発言されるようにITコーディネータが仕掛けることも大切です。<br />　　１）と２）について：　　プロジェクトの目的と方針はプロジェクト完遂まで絶対にぐらつかせてはなりません。事前に十分な議論と意識合わせをITコーディネータが社長および担当役員と行っておくことが大切です。またプロジェクトの途中でも目的と方針の再確認を社長以下と繰り返し行います。プロジェクト遂行の途中で必ず抵抗勢力が現れます。それをはねつける力を推進者はあらかじめ用意しておく必要があります。目的と方針の固守はそのための非常に重要な要素です。プロジェクトへの非協力的な姿勢、非協力社員は個人の人事的評価に悪影響を受けることをさえ社員と管理職に認識させる場合もあってよいと思います。<br />　　３）について：　　プロジェクトに直接参加する実務メンバーは社内で広く認知されるようにします。核となるプロジェクトメンバーは社内各部署の実務キーマンとうまくコミュニケーションの取れる専任者であるべきです。企業内各部署からも、兼任でよいから、部署要求を整理しまとめる責任を負う担当者をプロジェクトに加えてもらいます。<br />　　４）について：　　工程はリーズナブルである限り厳しい短期工程を設定し、かつプロジェクトメンバーで工程厳守の高い認識を共有します。これによりプロジェクトは常に緊張感を保って進められます。また、短期間であることは導入予算低減させるためにも非常に有効です。<br />　　５）について：　　概略予算は、調査により同規模他企業の事例を参考にセットします。他社事例を調べることは、ここで示す予算に説得力を持たすために必要なことです。プロジェクトに用意できる金額が他社事例の金額と比べて桁違いに合わなければ、計画を白紙に戻して組みなおすことが賢明です。<br /><br />５．対象業務の分析　　　・・・・・　ERPで何をさせるのか把握する　・・・・・<br /><br />　　このフェーズではERPでカバーされるべき社内業務を分析し文書化しました。これをここでは「業務プロセス分析書」と呼びます。今回の場合、プロジェクト立上げ後1ヶ月をかけて業務プロセス分析書を作りました。<br />　　業務プロセス分析書では、現状の業務とあるべき業務をフロー図などに図式化します。この目的は、ERPで何を行わなければならないか、行わせたいか、ERPで何をさせるのかをプロジェクトメンバー全員が知るためです。ERPを導入し始めたものの、何をさせたいか具体的要求を表現できず、一方で「使いにくい」の大合唱に遭遇し、結局ERP導入が途中頓挫することはよく起こります。社内業務のどこをERPというツールに頼るのか、メンバーが認識を共有する必要があります。そのための図書が「業務プロセス分析書」です。ITコーディネータはこの文書作成を指導し、監査し、まとめさせます。フローは、通常多部門間にまたがる形になるため、部門それぞれがどのタイミングでどのような処理をするか記述させます。一例として、受注から設計、製作、納入、調整、完成検査、検収、売上げにいたる一連の社内業務プロセスがありました。　<br />　　業務プロセス分析書に対しては、自らが作った要求という意識を対象全部門とプロジェクトメンバーに持ってもらいます。業務プロセス分析書をITコーディネータが勝手に作ったとか、自分たちは内容をよく理解していない、などと言わせてはなりません。自分の責任で作った自分たちのための分析であるという意識を企業の全部署に持たせるよう誘導します。<br />　　なお、業務プロセス分析書において、いくつかよくある異常処理（例：　返品、紛失、クレーム処理、受注前の先行処置、など）にも触れておきます。この時点ですべてを記述する必要はありませんが、不完全でも異常処理を認識しておくことが重要です。<br />　<br />６．RFP作成とベンダー評価　　　・・・・・　ERPベンダーの知恵をフルに使う　・・・・・<br /><br />　　次にERPベンダーに対してRFP(Request For Proposal)を提示しました。ここでRFPの内容とは、前フェーズで作成した企業の業務プロセス分析書です。ERPベンダーの中から企業規模や実績、知名度からいくつかの候補を抽出し、そこに対して業務プロセス分析書を説明します。ERPベンダーには、当社が説明した業務を自社製品を使ってどう実現するか提案させました。このフェーズに2ヶ月を要しました。<br />　　これは非常に重要な進め方です。一言にERPといっても多くの製品が市場に溢れており、その中のどれが自社の業務に合うか使う側（顧客企業）やITコーディネータが自分で判断することは非常に困難です。業務分析書をERPベンダーに提示してベンダー側に考えてもらうことが時間の節約と正しい評価に非常に有効です。<br />　　このフェーズでは次のようにプロジェクトを進めました。<br />　１） ERPベンダーからの提案書と見積書の提出<br />　２） 1次評価をして選考対象を絞ること<br />　３） 選考に残ったERPベンダーの製品を用いたデモ<br />　４） ERPベンダーの製品を既に導入した企業への訪問調査<br />　５） 予算と社内事情を考慮してERPでカバーする業務範囲の見直し<br />　６） ERPベンダーへの追加質問、見積範囲のレベルあわせ<br />　７） ERP評価表作成<br /><br />　　１）について：　　ERPベンダーからの提案書には、どの範囲が当該ERPの標準機能によってカバーされ、どの範囲にアドオン（＝追加開発）が必要かを明示させます。いわば荒いフィット／ギャップ分析をここで行っていることになります。言うまでも無く、アドオンが多ければ多いほど初期導入の費用が増加します。期間も余分に必要となります。アドオンされた部分でのバグ検証などシステムの信頼性も落ちます。導入後のメンテナンス、バージョンアップにも手間と時間と費用が余分にかかります。したがって、可能ならばアドオンなして導入できることが望ましいはずです。<br />　　２）について：　　選考対象を絞るのは、これ以降のフェーズでの評価の手間と日数を少しでも少なくするためです。<br />　　３）について：　　デモでは業務プロセス分析書に沿った業務イメージを各ERPベンダーに製品を使って実際に示してもらいます。各部署から派遣された兼務のメンバーも必ずデモに出席させます。このERP製品の評価のフェーズにおいても、限られたプロジェクト専任メンバーだけでなく、各部署からプロジェクトに入ったすべてのメンバーに参加意識を持たせる必要があります。そしてそれぞれのメンバーに判断を示させます。後のフェーズで、「自分の知らないところでERPを選んだ」と言わせないための重要な手順です。<br />　　４）について：　　導入企業訪問では、ERPの評判、導入時に生じた問題、問題に対する対策の工夫など、後フェーズで有効な情報を集めることができます。オリジナルのERPに問題があるとして、それをどのようにクリアできるのか目処を立てることも製品評価の項目の一つとなります。<br />　　５）について：　　ERPベンダーのデモや仕様、価格など総合的に判断して、本プロジェクトでどこまでの業務範囲をERPでカバーするか決断します。予算、期間、業務プロセス分析書とのギャップ、などを考えます。すべてのERPベンダーの提案で「業務プロセス分析書」とのギャップが大きいプロセスがあれば、今回の対象業務範囲から思い切って除外する決断も必要です。<br />　　６）について：　　見積範囲の精査など細かな詰めは専任メンバーとITコーディネータの連携で処理します。レベル合わせのための見積範囲調整、追加質問などを行って公平さを確保し、また技術課題の対処方法も提出してもらいます。<br />　　そして、７）のERP評価表を作成します。<br /><br />７．ERP評価表とベンダー決定　　　・・・・・　目的/方針を固守しつつ決める　・・・・・<br /><br />　　いよいよ導入するERPの選択について意思決定を行う段階となりなます。<br />評価項目は次のようなポイントとしました。<br />　１） 価格<br />　２） 当該ERPの特徴と今回の導入方針や目的との合致度当該ERPを選ぶことが、固持すべき当初方針や目的に合致した選択となるかどうか。<br />　３） アドオンのソフト製作量の大小、およびフィット／ギャップの評価。ERPの仕様や機能に要求との差異や問題がある場合にはその解決方策と費用・工期の概要<br />　４） 製品デモに対するプロジェクトメンバーからの評価<br />　５） ベンダー技術者の経験、資質と人数（＝人的動員力）。ERP構築時に万一問題が発生した場合、要員を増強してリカバリーできるポテンシャルを評価する。<br />　６） ベンダー企業とERP製品の継続性。ベンダーが倒産する、ERP製品へのサポートを止める、などのリスク評価。<br /><br />　　これらの評価表を作成し、まずプロジェクトメンバー内での意識統一を行います。これも、「他のだれかが勝手に決めた。」という意識を持たせないためです。プロジェクトメンバーその意識合わせに基づいて書面にし、社内承認手続きを行います。<br /><br />８．ERP選定までの結び<br /><br />　　以上が、ERP選定までに踏んできた各フェーズと進め方のポイントです。筆者の場合には、プロジェクトの立上げを宣言してから社内承認まで4ヶ月を要しました。選考対象としたベンダーは、当初6社程度。本格的な提案要請は3社に対して行い、最終選考は2社に絞りました。<br />　　内容を見ていただくとわかるように、プロジェクトの立上げ、業務の分析、RFPの作成、ベンダー決定、それぞれに若干の工夫をしつつも、当たり前のことを手順を踏んで行ったに過ぎません。冒頭に述べたとおりです。目的や方針を振れさせたりせず、プロジェクトメンバー全員の当事者意識を維持しつつ、当たり前の手順や行動を着実に実行することがプロジェクトを成功裏に完遂するために必要であることを、改めて強調しておきたいと思います。<br /><br />　　　　　　　　　　　　　ITコーディネータ　松下　悟　（まいど！フォーラム　メンバー）matsushita@まいど!フォーラムtag:blogger.com,1999:blog-7279463.post-68038720966794926922007-03-31T18:33:00.000+09:002007-03-31T19:04:53.016+09:00■はじめに<br />　ＣＩＯ（Ｃｈｉｅｆ Ｉｎｆｏｒｍａｔｉｏｎ Ｏｆｆｉｃｅｒ：情報化担当役員）という機能・人材は、大企業においては位置づけられ機能しているが、中堅・中小企業においては、存在していない企業や存在していても十分機能していない企業が多いのが実状である。しかし、今日、中堅・中小企業においても競争力を強化し勝ち残っていくためには戦略的なＩＴ活用は必須であり、それを推進する人材も必要不可欠になってきている。<br />そこで、ＣＩＯとはどのような機能を果たさないといけないのか、そのポイントについてＣＩＯを育成する研修の講師を担当した経験から説明したいと思う。<br /><br />■ＣＩＯの役割<br />　ＣＩＯとは、Ｃｈｉｅｆ Ｉｎｆｏｒｍａｔｉｏｎ Ｏｆｆｉｃｅｒの略で、最高情報責任者、情報化担当役員と訳されます。これまで経営者や役員はＩＴについてわからない人が多く、また、情報システムを担当する責任者は経営のことがわからないという状況であったが、今日、戦略的な情報化の重要性が高まり、経営と情報化の両方がわかり戦略的情報化を推進統括する人材の必要性が益々高まっている。それは大企業のみならず、中堅・中小企業においても、競争優位を保つための経営戦略・経営改革のための戦略的情報化が重要となってきており、これを実行推進できる人材がいない現状から、その必要性が益々高まってきている。<br />では、ＣＩＯとはどのような役割をもつのだろうか。大きく次のように考える。<br /><br />１．戦略的情報化は経営戦略ありきである。よって、経営戦略策定を経営者とともに<br />　　実施する。その際、どこをＩＴ化すれば、その成果目標達成に最も効果を発揮するかを<br />　　検討する。<br />２．策定された経営戦略に基づき、戦略的情報化を策定する。<br />３．策定された戦略的情報化企画に基づき、プロジェクトとして計画から実行、そしてＩＴ導入<br />　　までマネージメントを行い、導入後も成果モニタリングを通して、企業が継続的成長発展<br />　　をするようにＰＤＣＡサイクルを回すように推進する。<br /><br />では、それぞれについて、方法論やスキル等の詳細はまた別の機会にするとして、ポイントを以下に述べる。<br /><br />■経営戦略策定<br />１．成功の３条件<br />　会社が成功するためには、３つの条件があると考える。第１は会社の目標をしっかり定めることである。どういう会社を目指すのか、会社の成し遂げたいこと、ビジョンを描くことである。売上や利益目標など具体的に会社の目標を指し示すことが重要であり、経営者が示すべき目標である。<br /><br />　第２は会社の現状を認識することである。現在、会社はどのような状態にあるのか、会社の強みは何か、弱みは何か。また、外部の環境変化により予想される機会はどんなものがあるか、逆に脅威となるものに何があるか。会社の内部環境・外部環境を分析することである。以外と自社の強み、弱みはわかっているようでわかっていないことが多い。あまりに近すぎて当たり前になっているので、それが他社から見て強みであっても、中からは気づかないことが多いものである。<br /><br />　第３は目標へ向かう熱意・情熱である。いくら目標があっても、社長以下全社員がそこへ向かう熱意・情熱がなければ成し遂げられない。社長だけがあっても、あるいは社員だけがあってもできない。全員が目標を達成しようという熱意・情熱を持って取り組まなければならない。<br />これが成功するための３条件である。このうちのどれかひとつが欠けても成功することはできない。<br /><br />２．４つの合意形成<br />　　３つの条件が揃ったら、社長と社員全員が合意形成することが大事である。その大事な合意形成に４つあると考える。<br />　１つ目は目標である。社長も社員も全員がその目標を自分の目標として捉え、全員で向かうべく合意することである。<br />　２つ目は現状認識。会社の現状は「?である」ということを全員で正しく認識することである。<br />　３つ目は目標を達成するために、あるべき姿、達成すべき課題である。経営目標を達成するためには「?するべき」をしっかり定め、合意することである。<br />　４つ目はそれを実現するために「?する」という行動計画である。「?するべき」を掲げただけに終わらせないように、具体的な行動計画を立てて全員で合意することである。<br />　この４つをまとめたものが経営戦略企画書である。<br /><br />　ＣＩＯの役割は、この３つの条件と４つの合意形成による経営戦略策定において、常に参画し何のための情報化であるかを十分認識し、情報化により最大の成果を挙げられるようにＩＴ知識を踏まえ、提言していくことにある。ここをポイントとしておさえていないと何のためのＩＴ化がわからなくなり、折角作っても経営に役立つシステムとならない。そのために常日頃から会社の状況を認識するとともに、経営とＩＴの両方に関しての知識や世の中の動向について学習研鑽する必要がある。<br /><br />■戦略的情報化企画<br />　上記により策定した経営戦略企画書に基づき、次に戦略的情報化企画を策定するのであるが、では、戦略的情報化とはどの様に考えればよいか。<br />それには、それぞれの企業のＩＴ化のレベルによるが、まず、ＩＴが動かないレベルであれば正しくシステムが動くレベルにしなければならない。実はまだまだ中堅・中小企業においては、システムが動かない、一部しか使っていないという企業が多くある。そのような企業は、まず最低限、システムが正しく動くレベルにしなければならない。次に業務を効率化するというレベルである。業務が効率化され人件費などコストが削減されるという効果を生むレベルである。<br />しかし、周りの企業も同じようにシステム化を行っている今日では、業務効率化に留まらず、業務改革と一体となった情報化が重要なのです。本来、あるべき業務プロセスの実現を促し、支援するためのＩＴ活用です。業務改革とＩＴは別々になされるものではなく、一体となってこそはじめて実現されるものです。<br />そのためには経営目標実現のためのあるべき業務プロセスをトップダウンで設計していかなければなりません。それをＩＴによりスピーディに、より低コストに実現するのです。<br />よいシステムとは経営目標の達成に役立つシステムであり、経営課題の解決を促進し支援するシステムです。そして、経営目標に至る、あるべき姿や経営課題解決の達成度合い、指標をタイムリーかつ正確に捕捉するシステムなのです。<br /><br />■プロジェクトマネージメント<br />　戦略的情報化企画が策定できると、それをプロジェクトとして計画から実行を行い、ＩＴシステムの開発から本番稼働まで、目標を達成できるようにマネージメントし導かなければならない。またシステム導入後もシステムが正しく稼働しているか、当初の目標成果を達成できているかどうかをモニタリングしていく必要がある。そのためには、プロジェクトマネージメントについて、知識、スキル、ツールや技法を身につけプロジェクト活動に適用していかなければならない。<br />知識はＰＭＢＯＫの知識体系が代表される。また、マネージメントスキルについては、リーダーシップやコミュニケーション力や交渉力などが挙げられる。ツールや技法では、ＣＰＭやＷＢＳ、ＥＶＭなどの様々なツールや技法があり、それぞれの用途・目的に応じて活用する。それぞれの具体内容は今回省略するが、これらの知識・スキル・ツール等を活用し、プロジェクトの品質、コスト、タイムをバランスさせながら、すべてのステークホルダーが納得と共通認識ができるように推進し、プロジェクト目標を達成させることが、ＣＩＯとしての重要な役割である。<br /><br />■企業の推進エンジンたるＣＩＯ<br />　ここまで説明してきたように、ＣＩＯは経営者とともに経営戦略を策定し、経営目標を達成するための経営課題と行動計画をまとめ、戦略的情報化の企画および実行により経営目標を最も効果的に達成することが役割なのである。まさにその推進役であり、エンジンである。そのために必要な知識やスキルを身につけるのである。<br />特に今日、戦略的情報化が企業にとって経営目標達成のための重要成功要因になっていることが多く、戦略的情報化の構築そのものが経営目標達成には不可欠な状況において、ＣＩＯの役割はますます大きくなっている。私達ＩＴＣは、企業の継続的発展のためにいろいろな場面で支援をさせて頂くが、まさに外部からＣＩＯ的に支援をするといっても過言ではない。ＩＴＣの役割や期待がさらに大きくなっている中で、一つ一つの企業支援のＩＴＣ活動が重要な役割を果たし、ＩＴＣの存在価値と知名度を高めていくものと確信している。<br /><br /><br />　　ＩＴコーディネータ／吉村　哲也bruce_ttag:blogger.com,1999:blog-7279463.post-3534210839354695302007-03-17T10:12:00.000+09:002007-03-17T10:21:12.807+09:00ITコーディネータ　武島　直行（No.00002711）<br /><br />はじめに<br /><br />　２００８年J-SOX法の施行に伴い、昨今では金融業界のみならず、あらゆる業種の上場企業では当該法律に対応する方策や試行を通じて、“内部統制”という亡霊につきまとわれているように見受けられる。<br />一体、J-SOX法のどこが大変で、何故いまさらながらに“内部統制”なのか？<br />そもそも、上場するためには、一定の水準以上の財務力やビジネスモデル及び組織管理能力（内部統制も含む）が備わっていることを厳しく審査され、毎期毎に報告するというサイクルで運用されていたように記憶しているのだが．．．<br />一方で、上場企業をはじめとする世間では一流と称される大企業の騒動を間近に見ている中小企業においても他山の石的に傍観はしていれない、と考えるのは起業者を中心とした中小企業家の一致した見解と思われる。<br />　今日は、先に触れたJ-SOX法の対処についてではなく、中小企業をはじめとした、一般の企業において、なすべきことを定められたルール通りに行って、その行為が法規範にも触れていないことをチェックしていくサイクル作りをどのように考えて行えば良いか、に関して触れようと思う。<br /><br />序論<br /><br />“有るべき姿”とは、“なすべきこと”とは<br />どこの会社に伺っても大抵は「経営理念」や「経営方針」とか「社是」のようなその企業が企業活動するにあたって理念なり、目標とすることなり、方向性なりを簡単にまとめている。<br />これを実現するための社員の行動の標として「行動規範」や各種の規則・規程を作成している。最も、社長が行動規範だ、という企業も確かにある。いずれにせよ、何らかの物差しをもって活動を行っていることは確かである。<br />すなわち、企業の理念の中に“有るべき姿”を見出し、その活動の拠り所・考え方の中に“なすべきこと”を見出すことができそうである。<br />では、そこに見出す企業の姿が社会にどのように映っているのだろうか？<br />また、その活動の正当性はどのように確保されるのだろうか？<br />ここには、企業活動と社会との関連、例えばその企業の設立「意義」・「存在目的」がどのように意識され、どのように実践されているのか、ということが問われているように思う。<br />以降、企業活動の成り立ちから運営、ビジネスモデルを通じて、その企業の目指すところとＩＴの位置づけといった流れで考察を進めていこうと思う。<br /><br />本論１<br /><br />「起業にあたって」<br />どのような規模の企業でも、初めから存在したわけではない。必ず、起業者がいて、少しずつそのビジネスモデルを確立していき、社会での認知度を上げて、今日の成功を収めている、と考える。<br />起業に当たって、その考え方は千差万別で、必ずしも社会への貢献や利益をもたらすことを目標としているとは言えない。単に、会社勤めが性に合わないから起業した、あるいは、自分のやりたいことをするために起業した、ということも十分に考えられる。ここに共通することは、いずれも既に確固としたビジネスモデルすなわち利益をあげる仕組みを見出し、その実践において単独あるいは少人数で行う用意がある、ということか。<br />だが、そのような会社？でもその事業規模が拡張するに及び、規模はともかく、組織を作り、これを運用していく過程を踏むことになろう。大方の起業はこの辺りで転換期を迎えるものと思う。<br />さて、話を元に戻そう。「起業」するにあたって、経営者は自分の思いを“経営理念”に活動の方向性を“経営方針”等にまとめていく。そうでなくとも、何らかの意思表示を“文字”に表すであろう。この時、社会に貢献する、あるいは、自社が繁栄することで社会に何らかの貢献ができる、などの言葉がキーワードになっているように感ずる。そうなるとその行動規範も反社会的にはならないだろうし、どこの企業も同様な内容になっているものと考える。<br />そうすると、それに基づいて活動している企業人が何故、反社会的行動を犯さなければならないのだろうか？<br />それとも、当該反社会的行為をそのように思えなくなってしまっているのだろうか？この点に関しては心理学的な犯罪学的な要素も多く、今回の考察には不向きと考えたく、ここでは割愛したい。<br /><br />本論２<br /><br />「ステークホルダー」<br /><br />　今、巷で話題になっている上場企業の悩みの多くは株主をはじめとする利害関係者（ステークホルダー）との関係、特に株主との位置づけが俄に重要視されてきていることと、情報の公開に関する今まで経験したことのない責務への対応の仕方を模索していることにあるように感じられる。<br />　最近の事件の多くは、株主をはじめとして社会に対する情報公開（従来は財務報告が中心であった）における虚偽が中心で、これを企業ぐるみで行っている点である。あるいは、見た目を良くしたいが為に利益操作を行なう、という事件が多発しているようである。<br />　実は中小企業においてもこのことは他人事ではない。むしろ、大企業よりも如実な問題ではないか？<br />金融機関からの貸し付けを可能とするのは、その企業の財務体質であり、株式を公開していない限り財務報告は不要だが、どのような企業でも納税時には最低限の財務会計資料を提出しなければならず、収益をあげているか否かは明確になる。<br />先に触れたが、企業の存在意義によってはここで“待った”がかかると言っても過言ではない。<br />毎年赤字を出し続ければその企業では納税はおろか、社員に給与さえ支払えないこととなり、社会的にはその企業の存在価値は無くなっている。当然に淘汰されていくと思う。<br />これまでは、利害関係者として外部、例えば株主や出資者ばかりが取りざたされ、内部の利害関係者（社員等）や広い意味での外部、すなわち社会全体といった部分への考慮がなされていなかった場合が多い。<br />従って、世間にあるいは公的組織への報告すなわち財務報告に心血を注いできたと言っても過言ではなかろう。<br />ここでは、ありのままの姿を見せることが重要で、誤っても虚偽や隠し事は言語道断であるということは自明の理であるにもかかわらず、何故後を絶たないのであろうか？<br />利害関係者の枠を本来あるべき姿に捕らえ、その中で誠実に企業活動を行っていくにはどのようにすれば良いのか、これはあらゆる企業家の悩みなのではなかろうか。<br /><br />本論３<br /><br />「なすべきこと」<br /><br />　企業は収益をあげることが史上の使命である。<br />　その収益は、企業がさすべきことを当然に行って、有るべき姿に向かっていくことで積み重ねていくことが理想であり、また、そうでなければ存在し得ないと前にも述べた。<br />では、「なすべきこと」とはどのような事でどのようにすれば見つけられるのであろうか？<br />　大相撲で“強い”力士には共通点がある。それぞれが、このように取り組めば九分九厘勝てる“形”を持っていることだ。別に必殺技ではない。立ち会い・組み方や得手不得手も含めて、この形に持ち込めば勝算が格段に上がる、という形。当然、最初からその“形”に持ち込めば楽に勝てる、ということだ。<br />　企業活動においても同じ事が言えないか？巷で言う、“ビジネスモデル”などはその類ではないかな。<br />その企業の得意技だけで勝負できれば、ほぼ負けることはないだろうが、相手も取り口は研究してくるし、相手の不得手を突いて勝負してくるだろう。そのためには、将棋のように相手の差し手を予想してそれぞれに対する差し手を考えて、如何に自分に有利な展開に変えていくか、すなわち、自分の得手の世界に引き込んでいけるか、がポイントで、そのための組織活動が「なすべきこと」であり、そのパターンこそが、当該企業の“ビジネスモデル”になっているのではないかと考える。<br />　したがって、“ビジネスモデル”が明確で判りやすい場合にはその遂行に関して、細かいルールや決め事を付加していけばよい。そうでない場合には、まずは自社の収益の構造を分析し、理解して、ここで勝負するための企業活動を探って、“決まった形”を創造する必要がある。それは、無理をすることを強いるのではなく、無理なく進められる内容、すなわち多少の余裕をもって行えることが望ましい。実際には想定通りには進まないもので、そのような場合に無理が効かないと絵に描いた餅に止まってしまうだろう。<br />　私もいろんな企業あるいは個人のビジネスモデルに遭遇してきた。別の機会にこれらを紹介できたらと思う。<br /><br />まとめ<br /><br />「自浄作用」<br /><br />企業の行動原則に関して考察してきたが、人間全てが“善”であることは考えられない。いや、そうであるとしても24時間365日“善”であることには想像もつかない苦痛が伴うのではないか？残念ながら私も弱い人間で、１日の内で“善”で有り続ける時間は数時間としか言えない。“悪”になると言う意味ではないが、よく、“?しておけば、すれば良かった”と後悔する場面では“善”になりきれなかった事に対する反省が占める割合が多いように思う。<br />　どうすれば、この人間の欠陥？を補佐できよう？<br />　人間も千差万別であることを考慮すれば、全ての人間が同じ事、同じ機会に同じ苦痛や悩みを持っているとは考えがたく、須く個人差があって然り。<br />と言うことは、他人にチェックされたり、見て貰ったりするポイントがあっても良いように思う。<br />ここに相互チェックの意味合いが生まれるのかな。<br />人間の弱さの比重でこの相互チェックを何十にも重ねていけばよいのではないか。<br />これが内部統制に通じる考え方ではないかと思う。<br />要は“なすべきことを”あたりまえに行うことと、行えるように手順（ルール）を決めること、そして、この仕組みが円滑に動いていることを他人の目でチェックし、是正し、改善していくことが内部統制の考え方といっても良いように考え、私はその仕組み作りを中小企業家と行っていく考えである。<br /><br /><br />追記：　この一連の仕組み作りの中でいかにしてＩＴ技術を活用できるか、ＩＴＣとしては悩みの種ではあるIT狸tag:blogger.com,1999:blog-7279463.post-1142062813470167852006-03-11T16:37:00.000+09:002006-03-21T22:49:07.570+09:00<strong>「eBusiness環境の企業情報システム」これからの流通・小売業界の展望</strong> という、寄稿論文をITコーディネータ筒田忠が投稿しました。小売・流通業におけるBtoB(SCM)システムとBtoC(CRM)システムの重要性とその効力を最大限に発揮させるビジネス・コア(ERP)システムの必要性を論じ、変わりゆく情報システム部門の役割とITコーディネータのスタンスを考えてみました。下記PDFファイルをクリックしてご覧ください。<a href="http://www.ekimae-it.com/maido/report/eBussiness_EnterprizeSYS.pdf">eBussiness_EnterprizeSYS.pdf</a>まいど！メンバーtag:blogger.com,1999:blog-7279463.post-1086961867767061562004-06-11T22:49:00.000+09:002005-01-21T11:05:44.843+09:00このコーナーは投稿論文コーナーです。 <br />ITコーディネータ活動の中で気づいたことや、経験談等比較的長めの文章を掲載します。 <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />太田垣