<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/ME2.2.3" -->
<rss version="0.92">
<channel>
	<title>駅前ＩＴ相談所 by まいどフォーラム</title>
	<link>http://www.ekimae-it.com</link>
	<description>「まいどフォーラム」によるIT相談所のページです。</description>
	<lastBuildDate>Tue, 27 Jan 2009 04:38:53 +0900</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>ja</language>
	
	<item>
		<title>新まいどフォーラムHPへの誘導分</title>
		<description><![CDATA[このページは、2008年3月以前のまいどフォーラムのホームページです。現在は更新をとめております。
セミナーの最新情報等は、こちらをご覧ください。
]]></description>
		<link>http://www.ekimae-it.com/new/%e3%81%be%e3%81%84%e3%81%a9%e3%83%95%e3%82%a9%e3%83%bc%e3%83%a9%e3%83%a0%e3%81%b8</link>
			</item>
	<item>
		<title>.</title>
		<description><![CDATA[
]]></description>
		<link>http://www.ekimae-it.com/new/115</link>
			</item>
	<item>
		<title>.</title>
		<description><![CDATA[
]]></description>
		<link>http://www.ekimae-it.com/new/114</link>
			</item>
	<item>
		<title>成功事例にもとづくERP導入の実務（その３）</title>
		<description><![CDATA[　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ITコーディネータ　松下　悟　
１． はじめに
　　　本稿は、筆者が経験したERP導入を振り返ってその成功要因をまとめたものです。今回は最終回「その３」として、ソフトウェア開発を開始するフェーズから、新システムへ移行してプロジェクトが終了するまでを扱います。
　　　筆者の事例ではベンダー決定からシステム切替え終了までを９ヶ月で行いました。「その２」で解説したベンダー決定～仕様決定が２ヶ月でしたので、本稿ではソフトウェア開発フェーズからの７ヶ月の業務の説明をしています。
２．ソフトウェア開発管理
　　　ERP導入では、一般にソフトウェア開発フェーズでの管理業務は高い負荷ではありません。もちろん、ERPにアドオンで加える修正の製作量、ERPとは別のソフトウェアで作る画面や機能の製作量がリーズナブルな量に収まっているという前提です。通常のソフトウェア開発で行うのと同様に、製作する機能ごと、プログラムごとに明示されたWBSを作って進捗、検査、完了をチェックしていきます。
　　　基本的にベンダーとの契約はソフトウェア開発内容が確定した時点で金額も確定します。このフェーズで仕様決定にまで遡る大きな変更が発生しなければ、ERP導入プロジェクトの予算管理はある程度の目途が着いたことになります。
　　　開発が終わり、機能が揃った部分から、いよいよマスターデータの登録に入っていきます。マスターデータとは、会社の組織、社員、派遣者、客先、発注先、銀行口座、支払い条件など、一連の情報を指します。それらが揃うに従って、実データによるシステムの動き方を逐次検証して行きます。
３．システム切替え準備
　　　ERP導入における最もリスクある作業の一つが新システムへの切替え作業です。いうまでも無く、企業が事業活動を続ける中で切り替えを行いますので、切り替えに失敗するなら膨大な修正作業や再入力作業など一般社員の業務を止めてしまう可能性もあります。決算がまともにできず、業績報告に支障をきたせば、企業の社会的信用、存続にかかわる問題ともなりかねません。切替えに失敗して、旧システムに戻すこともできず、悲惨な状況下で新システムへの改造作業を行わねばならなかった事例は枚挙に暇ありません。
　　　切り替え準備で大切な項目は以下の4点です。
　　　　　１) 新システムへのデータ移行方法の決定とそのためのツール作成
　　　　　２）システムの切替え手順と日程、体制
　　　　　３）教育の方法と日程
　　　　　４）切替え後のシステム使用方法のサポート
　　　これらを周到に、かつ綿密に計画することがプロジェクト後半の成否を握ります。以下に、各項目について述べていきます。
４．データ移行方法
　　　システム切替え時には、旧システムから経理情報をすべて一旦ファイルに出力し、新システムにそれを読み込ませることでデータを移行します。簡単に言うとこれだけですが、実際には実にさまざまな経理上の事象や措置がしてあって難航する作業です。
　　　まず、社員情報や客先情報、発注先の情報など、比較的変化の少ないマスターデータ類はあらかじめ抜き出して新システムにに移しておくことができます。多少の変化は、後追いでERPに手入力しても対応できます。ただ、筆者のケースの場合、本稿のシリーズ（その１）で述べたように2社の基幹システム統合を同時に行いました。これは単に基幹システムを切替える場合には無い事象、つまり2社が同じ顧客やベンダーを別々の分類で管理していたり、同じ相手で支店の口座が違う、支払い条件が違う、統合した2社がかつて互いに顧客でもあり互いに発注先でもあって、案件の消し込みが必要であるなどありとあらゆる事象が現実に発生して、一つの整合性あるデータに作り直すために多大の労力を要しました。この混乱はプロジェクト工程に影響を与えました。
　　　また、受発注の状態、発注額、仕掛案件の金額、各種財務上の金額などはデータ量が多量であり、当然ですが人的作業の力業で新システムへ移すことは実際的ではありません。移行ツールとして旧システムからデータを抜き出して新システムが読める形でファイルを作るプログラムを作る必要があります。移行準備としてこのプログラムを作り、何度も実データでシミュレーションをして、確かにそのツールによって正しく旧システムから新システムへデータを移せることを慎重に確認します。何度も予行をして問題をつぶします。
　　　特に、旧システムがスパゲッティ状態、つまり変更に次ぐ変更で例外処理だらけであるときには、ある時点のデータで新システムへの移行を行ってみて新旧システムを慎重に比較する必要があります。異常値を見つけるならば都度原因を探り、あるべき姿を決め、その状態を新システムで実現できるように移行プログラムに対応機能を追加します。
　　　今回のように2社の基幹システムを統合する場合にはプログラム作成だけで通常の倍、さらに2社のデータの整合を確認するためにその倍以上の手間を要しました。
　　　筆者の事例では、当初、ソフトウェア開発開始から５ヶ月目の月末に旧システムでの最終月締めを行い６ヶ月目に新システムへ移行する工程を立てていました。しかし、上述のマスターデータの不整合と例外処理対応で移行ツールのプログラムを修正し続けたためにツール完成が間に合わず、結局１ヶ月切替えを延期しました。工程変更において、社長への説明を行い、承認を取り付けて社内アナウンスを実施しました。
　　　
５．システム切替えの手順と日程、および体制
　　　切替え手順の計画にはベンダーの経験を借りつつ社内調整を重ねて慎重さが求められます。手順は次のとおりです：
　　　　　１）（N-1)月の月次決算をN月の初めに旧システムで終えます。
　　　　　２）N月の数日間、旧システムへの入力を凍結します。
　　　　　３）その間に新システムへデータを上述のツールで読み込ませます。
　　　　　４）新システム上で旧システムの状態と数値を確認します。
　　　　　５）数字が一致していれば、新システムの使用を開始します。
そして、新システムでN月の決算を無事終えれば、とりあえずは成功ということになります。
　　　大きな企業の場合、経理部門を中心に事業部の経理担当、営業部門、調達部門ら、データ確認の体制を組んで、何をどの期間でチェックを終えるか、綿密な工程と体制を組みます。手順の説明、それぞれの役割の確認、担当者の疑問に対する回答など、切替えの約３ヶ月前から何度も話し合いの場を持ち、説明し、意識合わせをしました。
　　　社長、財務担当役員、事業部長ら、関連する部門トップの協力を取り付けておくことは言うまでもありません。社内へ切替え工程をアナウンスする日程やアナウンスの方法も周到に準備します。
６．教育の方法
　　　新システムの教育も十分な配慮に値するテーマです。システムが切替えられたあとでは新システムを使わなければ企業活動が行えない訳ですから、とにかく全社員に自分が使う範囲を教える必要があります。
　　　教育の内容は、部門からプロジェクトに参加しているプロジェクトメンバーの意見を入れつつ部門ごとにコンテンツを考えました。経理部門、調達部門、営業部門、各事業所の業種ごと、経費等の処理担当者ごと、などです。教育のテキストと研修用の実機環境も準備しました。十数台のパソコンを教育用セットとして事業所を順回すパターンです。
　　　システム切替え予定日の2ヶ月前から教育日程を組み、1日ないし2日の教育をとにかく全員に受けさせます。役員クラスから受講命令を出させます。また、各部門のプロジェクトメンバーは自部門の社員が理解するよう内容調整や日程調整に責務を与えます。使い方が判らないという声が上がることは当該部門の教育活動の不徹底ということで、役員やプロジェクトメンバーの責任を問うことさえもしました。教育は技術者をプロジェクト本部から派遣して行いました。
　　　実際にパソコンを操作できる環境を作ること、できる限り多くの教育要員をシステム部門から出すこと、全員が教育を受けるよう徹底させること、そして各部門にある程度はシステムについて教育のできる要員を置くこと（今回はプロジェクトメンバー）。これらが教育成功の鍵と考えます。役員クラスを巻き込み、システムが入った後で部門の業務を停止させるのは部門責任者の責任、とまで認識を持たせました。
　　　今回のERP導入において、結果的にシステム切替え後に問い合わせの殺到によるプロジェクト側の機能停止は起きませんでした。システムが使いにくい、あるいは実務に使用不能である状況も生じませんでした。これらの事象が起きなかったのは、仕様決定までに各部門からプロジェクトに参加したメンバーが自部門の要求を反映できたこと、あるいは妥協できる範囲を把握して仕様を決めたこと、そして事前教育に重きを置いた成果でした。
７．システムの切替えとその後のサポート
　　　これまで述べてきた準備の下に移行を決行しました。旧システムでの決算を終え、旧システムの使用を凍結し、新システムへデータを移行します。そして新システムであらかじめ決めておいた財務諸数値を関係者全員が確認していきます。その結果が次々とプロジェクトの本部に報告されます。若干の数値の不一致に対して人力でデータ変更を加え、新システムの使用を開始して問題がないとの判断を下します。そして切替え前日夜に翌日からの新システム使用を全社へ通達します。
　　サポート体制として、新システムの使用開始日から約１ヶ月間、主な部署単位にシステム開発の技術メンバーを配置し、技術メンバーと部署のプロジェクトメンバーが部員からの問い合わせに応えること、プロジェクト本部への問い合わせは技術メンバーかプロジェクトメンバーから必ず行うことをルールとしました。結果的に、このような要員配置と連絡ルールを決めて体制を敷いたことが、プロジェクト本部側への問い合わせ殺到などの混乱を回避できた要因でした。新システムを使い始めて１週間、２週間、だんだんと問い合わせが減ってきます。そして月末には再び問い合わせが増え、それに対応している間に切替え後初めての月締めを迎えます。
　　　切替えは、年度末をはずすことが賢明です。ただでさえ処理数が増える年度末にシステム切替えを重ねることは非常に危険です。事情のわかった担当者の人数はどの企業でも限られていますから、その人数でデータを確認できる量を物理的に超してしまう場合もあるでしょう。データ処理量が特に多くない月を選んで切替え、さらに何度か新システムでの月締めを経験させて問い合わせを減らしてから、満を持して年度末の決算を迎えられるように工程を組みます。　　
　　　本事例では、ソフトウェア開発開始後から６カ月目の月末締めを旧システムで行い、切替を経て、７ヶ月目の月末決算を新システムで終えることができました。その数ヵ月後、新システムでの年度末決算も無事終えることができ、ERP導入プロジェクトは終了を宣言しました。
８．プロジェクト全体の結び
　　　このようにしてERP導入を無事終えることができました。いうまでもなく、当初定めたERP導入の目的は旗印として最後まで貫きました。また、ERPの選定や仕様決定の段階で社内各部門を巻き込み、プロジェクトに各部門からメンバーを出させ、導入後に仕様に関するクレームが出ない（言わさない）手順を踏みました。導入教育の実施ややデータ確認に各部門の十分な協力を取り付けられる仕掛けをするとともに、各部門が困らないようにプロジェクト側で人資源を用意して配置していきました。
　　　ERP導入を行う上での混乱は多くの場合、人的要因によるところが多いでしょう。会社トップの意思がフラフラする、現場から不満の声が上がる、各部門がプロジェクトに非協力的になる、などです。導入にはもちろん技術面での優秀なスタッフが必要です。信頼できるベンダーがいなければシステムは見込みどおりには動きません。が、それに加えてプロジェクトリーダーが人的リスクへの備えをし、企業の職制を使える限り使い、統制を保って最後までERP導入を指揮し続けることが成功の要因であることを述べて、３回にわたったERP導入事例紹介を終えます。　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上
]]></description>
		<link>http://www.ekimae-it.com/thesis/%e6%88%90%e5%8a%9f%e4%ba%8b%e4%be%8b%e3%81%ab%e5%9f%ba%e3%81%a5%e3%81%8ferp%e5%b0%8e%e5%85%a5%e3%81%ae%e5%ae%9f%e5%8b%99%ef%bc%88%e3%81%9d%e3%81%ae%ef%bc%93%ef%bc%89</link>
			</item>
	<item>
		<title>「バンドマスター方式」によるＩＴコーディネータ収益モデルの検討</title>
		<description><![CDATA[＜はじめに＞
クライアントの企業規模が大きくなると、ひとくちにＩＴ化といってもその範囲は上流から下流まで多岐に及ぶ。大きくは経営寄りのもの、システム寄りのものがあり、さらにシステム寄りのものには、ＳＥ寄りのものからプログラマー寄りのものまである。経営寄りのものでは財務系のもの、マーケティング系のものなど、とてもひとりの専門知識では賄えない広さと深さがあるといってよい。そこで、比較的大型の案件を処理するにあたり、ＩＴコーディネータの横のつながり、チーム連携が重要になってくるのである。
　いっぽうＩＴコーディネータは、その資格維持の仕組み上、協会に認定された「届出組織」というグループ単位で活動していることが多い。セミナーや勉強会は届出組織によって主催されることがほとんどなので、大半のＩＴコーディネータは、なんらかの届出組織に所属し、そこで顔見知りになり、ビジネス上の連携が始まりやすいのである。
　コンサルタント間の連携については、税理士と社会保険労務士、司法書士といった、いわゆる士業を営む専門家同士が組合を作ったりして連携するケースが珍しくない。相互補完的な業務を行うために、クライアントにしてみれば、ワンストップでサービスを享受できるメリットがある。
　ところが、それぞれが独立したコンサルタント同士の連携はうまくいかないケースも多々ある。皆がプライドを高く持ち、専門性の高い仕事をしている有能な個人のため、それぞれがマイペースであり、お互いがお互いの専門分野を理解できず、しかもそれぞれが自分の利益を優先しがちだからである。極端に言えば呉越同舟があたりまえ、異なる流儀同士が衝突しないほうが不思議だともいえる土台があるわけである。
　そこで、このＩＴコーディネータ同士の不安定結合状態を解決する目的で、われわれ“まいどフォーラム”が試験的に取り組んでいるのが「バンドマスター方式」による組織連携マネジメントである。
＜バンドマスター方式の定義＞
「バンドマスター」とは、ジャズでよく使われる用語で、略して「バンマス」という。同じバンドでも、ロックバンドでは使われることはないのだが、要するにバンドを仕切るリーダーのことである。特にここでは、即席ユニットで演奏されるジャズライブをイメージしていただきたい。ついさっきまでは赤の他人同士だったサックス奏者やドラマー、ピアニストでも、集まったとたんにプレイできる、そのイメージである。「お互いにプロなんだから好き勝手に演奏してもいいライブになる」とはいかない。たとえ即席とはいえ、やはりバンマスを決めて、どのパートを誰がどんなふうに受け持つかについての仕切りが必要である。それがなければ「個別最適の積み上げが全体最適になるとはかぎらない」という結果に終わるであろう。
　ＩＴコーディネータには、大手企業に勤務する企業内コーディネータや、税理士や中小企業診断士を本業とするフリーのコーディネータ、システム開発やホームページ制作の会社を経営するベンダー型コーディネータなどのタイプがあり、勉強会の中で緩やかな連携を保っている。中堅企業からシステム導入の相談を受けたとしても、単独では処理できないので、数人のコーディネータに声をかけ、それぞれの得意分野を担当してくれるように依頼することになる。そこで「誰がバンドマスターになるか」についての完全合意が重要になるのである。
　結論から言えば、バンドマスターは、企業からファーストコンタクトを受けたＩＴコーディネータがなるのが原則ルールである。全責任を負う自信がないので放棄する場合は別だが、自らが営業活動を行い、クライアントに信頼され、某かのプロジェクトを託された最初のＩＴコーディネータこそが、そのプロジェクト全体を最優先してコントロールする権利をもつと見なすわけである。
＜バンドマスター方式の実践のために＞
バンドマスター方式の考え方をひとことで表すなら、「営業力があって、お客さんを見つけることができて、仕事を取ってこれるＩＴコーディネータがいちばん偉い」である。どれだけ専門知識が豊富でも、マーケットが見つからなければ収益は上がらないのであるから、この原則はコンセンサスを得やすいと思われる。ただ、営業力とリーダーシップは比例しないので、バンドマスターになったＩＴコーディネータが必ずしもリーダーとして最適ということにはならないかもしれないが、そのリーダーシップの欠如をチーム全体で補おうという姿勢が大切である。報酬に関わる金銭トラブルも大いに予測されるので、バンドマスターの頭越しに勝手な取引や提案をクライアントに対してしないことを盛りこんだ契約書にサインしておくことが欠かせないであろう。
　バンドマスターに求められることを整理してみると、お客さんを見つけたらまず、自分の所属している組織やその他の人脈から、プロジェクトメンバーを選定し、受託業務を遂行できるワークフォースを揃えること。集められた各メンバーが自身の指揮権に従う旨の契約を締結すること。この時点で、メンバーの貢献度合いに応じて、ある程度の報酬分配方針を明らかにし、造反が起こらないようにしておくこと、等である。
　予算が数百万、数千万に上るシステム導入案件が、ＩＴコーディネータ個人に単独委託されることは考えにくく、受注窓口としては、法人格のあるＩＴコーディネータのグループ（ＮＰＯ法人など）が想定される。確かにバンドマスターは、プロジェクト毎に招集される即席ユニットにおいては全責任者なのであるが、対外的な信用という意味では、組織としての最終責任者はやはりその法人の代表である。つまり、いくら緩やかな連携を前提とする即席ユニットといえども、法的根拠のある連帯責任を負っている社会人の集まりであることが絶対条件であり、バンドマスターを適切に指導育成する責務が、法人の代表者にあることは言うまでもない。
ＩＴコーディネータ　永田祥造
]]></description>
		<link>http://www.ekimae-it.com/thesis/banmas</link>
			</item>
	<item>
		<title>【システム開発依頼の失敗と成功】</title>
		<description><![CDATA[■はじめに■
　昨今、縦割り行政の問題が取沙汰されています。情報システムも同じ様に、各行政組織は膨大な情報を持っていますが、横断的な繋がりが余り無く、必要な情報を収集するには、行政組織毎に確認する必要があります。一般市民としては面倒に思う事が多々あります。
　しかし、スピードが重要なビジネスの場では、必要な情報を必要な時に取り出す事が出来ないと、競争相手に先を越されてしまう事があります。今回は、システム子会社を持つ会社の商品設計支援システムの｢システム開発依頼の失敗と成功｣について書かせて頂きます。この会社は製品を設計する為にいくつかの部門を持っており、各部門毎に重要な情報を管理しています。これらの部門は関連性が強く、データの共有が必要ですが、各々が情報を管理しているため、必要な情報を一括して取り出すことが出来ません。まさに縦割り行政に通じるところがあります。
　また、この会社は年間に複数のシステム案件をシステム子会社に開発依頼していますが、完成したシステムの中には、要件を満たしているにも関わらず、十分に活用されないシステムも存在します。この様な無駄な投資を削減する為に、システム子会社への要件依頼の方法を見直しました。
■システム開発依頼の失敗■
　システムを開発する場合、自社の要望を資料にまとめＩＴベンダーに依頼するという方法が一般的だと思います。
　しかし、この会社ではシステム開発を行なう時は、システム子会社からシステムエンジニアを呼んで、欲しい機能や画面・帳票イメージを伝え、システムエンジニアに資料を提出させるという方法をとっていました。システム子会社のエンジニアは若い社員が多く、依頼した内容をメモし、後日きれいな資料にして持ってきます。資料の内容も、依頼した要件が漏れなく書かれています。しかし、実際にシステムが出来上がってみると、不満な点も少なくなく、使いにくいという理由などで開発したシステムは、十分に活用されなかったり、作業時間が短縮した人がいる反面、増加した人もいて考えていた様に効果が上がらない事もありました。これは、システムエンジニアが依頼者側の業務を理解していないと共に、依頼した内容や方法にも問題があったと考えられました。
■要件依頼方法の改善■
【分析】
　もっと効果のあるシステムの開発を行う為に、システム開発時の作業の分析を行いました。この会社の各部門はそれぞれ専用システムを所有しています。すなわち、各システムはその部門に必要な機能しか備えておらず、部門間の情報連携が十分に取れていませんでした。また、システム開発依頼をする側にはコンピュータシステムの開発に関する知識や経験があまり無い為、開発要望をシステム子会社のシステムエンジニアとの打ち合わせの場で決定していくという方法をとっていました。
　問題点としてあがったことをまとめると、
(1)互いに必要な情報を、各部門で管理しているためデータの有効活用をしにくい。
(2)システム開発の依頼内容を、打ち合わせの場で決定しているため、依頼漏れが多く発生する。
　と言う事でした。
【改善】
　今後のシステム開発・改善で、より効果の高いシステムを作るために、これらの問題を改善する事になりました。
　改善方法として、以下の案が挙がりました。
(1)現状の把握
　関連部門間で効率良くデータを連携するために、関連する｢部門の業務｣と｢所有システム｣を資料化(表・図化)し、本来あるべき姿を想像出来るようにする。また、今後のシステム開発・改善時に、｢他部門との関連｣や｢無駄な作業の発生｣を考慮し、より広い視野でシステム開発依頼を行えるようにする。
(2)依頼内容の資料化
　システムエンジニアとの打ち合わせ時に決定していた依頼内容を、打ち合わせ前にまとめて資料化する事で、依頼の抜け漏れを削減する。
(3)システムエンジニアとの打ち合わせ
　システム開発を成功させるためには、依頼者側とシステムエンジニアとの協力が不可欠である。システムエンジニアは業務内容について理解が浅いため、(1)(2)の資料を使用し｢各関連部署の業務内容｣と｢開発を依頼するシステム要件｣をリンクして理解できるように説明することに勤める。その上でシステムエンジニアからの意見や提案を聞く様にする。
■改善後のシステム開発依頼■
　新規システムの開発を行なう事となり、まず部門内の要件を資料化し、部門内および関連部門でレビューを行い様にしました。この時、現状把握の為に作った、部門間の関連業務・関連システムをまとめた資料を使い、これまで見つける事が難しかった、リリース後に発覚するであろう追加要望や問題点を早期に発見する事が出来ました。
　また、システムエンジニアに明確な依頼が出来るようになった為、システムエンジニアから以前よりも多くの意見や提案を引き出せるようになりました。
　この結果、仕様確定後の仕様変更を削減し、システム開発を行った事で発生する事があった無駄な作業時間を無くすことが出来ました。
■おわりに■
　これらの資料は、システム開発時の参考資料(教訓)として使われる事になりました。今後のシステム開発・改善時に隠れた要件や問題点の早期発見をするために役立つと思います。また、これらの作業で深く思った事は、システム開発を成功させる大事な要素として、依頼する側の積極的な参加と、依頼される側のユーザ業務に対する理解(および興味)が必要だと思いました。
ITC　中谷　正明(006596)
]]></description>
		<link>http://www.ekimae-it.com/thesis/%e3%80%90%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0%e9%96%8b%e7%99%ba%e4%be%9d%e9%a0%bc%e3%81%ae%e5%a4%b1%e6%95%97%e3%81%a8%e6%88%90%e5%8a%9f%e3%80%91</link>
			</item>
	<item>
		<title>成功事例にもとづくERP導入の実務（その2）</title>
		<description><![CDATA[                                                       ITコーディネータ　松下　悟 
１．はじめに 
　　　本稿は、筆者が経験したERP導入を振り返ってその成功要因（CSF）をまとめたものです。今回は「その２」として、導入するERP製品が確定した後のフェーズ、つまり実際に導入に取り掛かるフェーズから、仕様決定フェーズまでを扱います。 
２．構築プロジェクトの立上げ　　～再びプロジェクトとその方針を周知させる～ 
　　　ERPを納めるベンダーと契約を取り交わし、いよいよERP導入プロジェクトがスタートしました。改めてプロジェクト立上げを社内で宣言し発信しました。宣言にはERP選定フェーズの開始時と同様に次の項目を含めました。
　　　　　　１） ERP導入の目的（原価管理の精度改善、仕掛り品の減少、など）
　　　　　　２） 導入方針（システムを導入して自社の業務プロセスを改善する、など）
　　　　　　３）社長をトップに置いたプロジェクト体制と実務メンバーの明示と周知
　　　　　　４） カットオーバー日を明示した工程
　　　　　　５）概略の予算
このような宣言の目的は、言うまでもなくプロジェクトを全社員に認知させ、その目的や方針を周知しておくことです。プロジェクトが進んでいってシステムの使い方が説明されると、社員が行わなければならない業務への直接影響が明らかになってきます。その段階では、「そんな面倒くさいことになるの？」といった声が必ず上がってきます。その前に、あらかじめ目的や方針を繰り返し何度も発信しておきます。
　　　例えば正式な受注書面を客からもらう前に何かの資材を先行して発注する、といったルール無視が散見されているとします。それに対してERPという仕組みを嵌めてしまうことで、ルール違反をできなくする訳です。ERPによって「プロセス改善（適正化というべきか）」という目的に沿い、業務の進め方を変えさせることを実現していくわけです。いずれ実務者からはいろいろな例外処理に対応するよう要求が出てきます。その多くはYesともNoとも言える事項です。その事態に備えて、導入目的や方針という原理原則を繰り返し明示します。無理な要求に対してはプロジェクトとの目的との不整合を理由に拒否することができるよう、プロジェクトの開始時から繰り返し周知しておきます。
　　　プロジェクトメンバーは専任者と各部門から出された兼務者で構成し、だれがプロジェクトメンバーかも様々な機会を用いて社内に周知しました。これは選定フェーズと同じです。カットオーバーの目標日も大きく掲げます。いくらの費用をかけてERPを導入するかも概算額を周知しました。「失敗するとこれだけの費用が無駄になるよ。」ということを社員に知ってもらうためです。 
３．プロジェクト全体の工程　　～関与させたい人に逃げられないように仕組む～ 
　　　これから、フィット＆ギャップ分析、仕様決定、製作、データ移行準備、教育、システム切替試行、システム切替、切替後のサポート、の順序で工程が進みます。
　　　最初のフィット＆ギャップ分析では、各部門からの兼務者に対してデモを見させるなどして意見を出してもらうことが必要です。「わたしが仕様を決めた訳ではない。」と、あとになって逃げ口上を言わせてはなりません。デモを見てもらうために、短期間でもプロジェクトに専念してほしい時期や日数をあらかじめ要求しました。役員などを含めて兼務者の上長にもこの件を依頼しておきます。プロジェクトでは短期間で仕様を固めるために、限られた日程でデモなどの日程を組まざるを得ません。他の業務によって結果的にデモに出席しないメンバーが出てこないよう、前もって布石を打つことは重要です。 
４．ギャップの把握（フィット＆ギャップ分析（１））　　
　　　　　　　　　　　　　　　　　　　～ストーリーを作り操作イメージをチェックする～ 
　　　フィット＆ギャップ分析を行ってシステムの仕様を決めていきました。今回のプロジェクトではERPベンダー選定の段階でも一度粗いフィット＆ギャップ分析を行いました。再度、ベンダーにデモをしてもらうに際して、以前にスキップしたこと、現実に業務で生じる異常ケースなどを社内各部門から来ている兼務者（プロジェクトメンバー）に出してもらいます。それをもとにデモを行うときのストーリーを作りベンダーでストーリーどおりのデモを準備します。その上でプロジェクトメンバーを集め、ストーリーに沿って、オリジナル仕様のERP上でどのような動きになるか、実務でどれほどの業務作業になるかを関係者に見させます。その結果、「画面が複数になって作業性が悪い」とか「その数値を入力するときには同じ画面にこの情報が必要」、といった声が出されるわけです。
　　　分析の結果は、次のように分類しました。
　　　　　　１）ERPオリジナルの仕様で導入するもの
　　　　　　２）ERPの中にアドオンで開発して組み入れるもの
　　　　　　３）ERPとは別のソフトウェアで画面や機能を作るもの 
もちろん、できる限り１）で対処して社員に使ってもらうのが望ましいです。当初からの目的と方針に沿って判断しても、どうしてもオリジナル仕様では不都合な場合や煩雑さが我慢できない場合のみ、２）もしくは３）での解決を図ります。
　　　例として、「月次の経理作業を行う際に、旧システムでは1画面で済んでいた作業が多数の画面にまたがってしまう、しかも処理すべき件数は毎月多数発生する。」というコメントに対して、オリジナルを我慢して使ってもらうべきでないと判断しました。アドオンで対処しました。
　　　別の例として、部署ごとに異なる複雑な上長承認の流れがありました。普通に組織ツリーに従って順に上位者の承認を取る部署もあれば、途中で工務部門のチェックを通す部署もあります。これらにいちいち対応させてシステムのワークフローを組むことは面倒で、いつまた組織変更などで手を加える必要が出るとも限りません。この問題に対しては、指定用紙を準備するなどしてペーパーで承認ルールを補うこととし、システムでの対応は行いませんでした。
　　　１）、２）、３）に分類した結果はまとめてプロジェクトメンバー全体で協議し、その結論に対して一人ひとりに責任意識を持ってもらいました。これは、兼務者が自部署のメンバーから「使いにくい」とクレームを受けたときに、兼務者自ら仕様を決めた過程を相手に説明し、自部署を納得させてもらうためです。このあたりもプロジェクトの統制を維持するために大切なステップです。
 ５．ギャップ対策あれこれ（フィット＆ギャップ分析（２））　　～安く安全にギャップを埋める～
　　　ギャップ対策は千差万別です。ここでは、そのテクニックを取り上げます。
　　　対策として取りうる方法は上記のように、２）アドオンか３）別ソフトウェアを利用する、です。一般に費用を考えると一般に２）は高くつきます。アドオンで画面を増やすことは、単純な画面であっても高額の変な費用を通常ベンダーは要求してきます。また、ERPがバージョンアップされるたびにアドオン機能への影響を考慮しなければなりません。
　　　一方、ERPにはたいていの場合、標準機能で外部システムとのデータ送受機能が備えられています。そのインターフェイス機能を利用して、別のソフトにERP内部の数値を書き出したり、別のソフトからERPへデータを書き込んだりすることができます。この方法は、ソフトを製作するプログラマがそのERPに詳しくなくとも製作に携わることができ、一般に２）よりも安く多くの画面/機能を作りこむことができます。筆者の経験したプロジェクトの場合、このやり方でギャップを相当部分クリアすることができました。ERP標準の外部インターフェイス機能だけを使っておくならば、ERP本体がバージョンアップされる場合でも影響は少ないでしょう。つまり、将来出てくるであろう改造が必要な場合でも、費用も抑えられると考えられます。ERPを導入したが、数年後バージョンアップに際して多額の費用を請求されて困った企業も多いはずです。
　　　止むを得ず２）を実施する場合ですが、そこでも内部機能的なアドオンはできるだけ避けます。単純なアドオン、画面など目に見えるアドオンに絞ります。これも費用追加と後々のトラブルを少なくするためのテクニックです。
　　　これらの検討を行うために、当然ベンダー技術者との綿密な相談、調整が必要となります。フィット＆ギャップ分析で抽出したギャップを、このフェーズでは一つひとつ丁寧に解決策を決めていきます。 
６．仕様決定まで 
　　　フィット＆ギャップ分析の結果を分類し、ギャップ対策には具体的な処置方法を用意して、仕様を決定しました。繰り返しになりますが、決定された仕様についてメンバー１人ひとりに「自分が決めた」と言う意識付けを要求します。決定仕様を元にベンダーとの最終価格を決定することができます。この時点で、予算に対して実際いくらでERPが導入できるか確定します。社内承認を経て、いよいよシステムの製作に入ります。 
７．仕様決定までの結び 
　　　以上が、仕様決定までのフェーズでの経験です。ベンダーとの契約後、再度プロジェクトの立上げを宣言してから仕様決定まで２ヶ月を要しました。このあと、専任者を中心にシステム製作の期間に入ります。
　　　本稿（その２）で扱ったフェーズにおいて大切なことは、
　　　　　　１）使う場面をストーリーにし、
　　　　　　２）それに沿ったデモをERPのオリジナル仕様で行わせ、
　　　　　　３）そのデモをプロジェクトメンバー全員で評価させること、
　　　　　　４）目的/方針を固守しつつアドオンを最少化すること、
　　　　　　５）安価なギャップ対策に知恵を絞ること、　　　　　　　　　　です。
　　　プロジェクトの目的や方針を振れさせたりせず、当たり前の手順や行動を着実に実行することがプロジェクトを成功裏に完遂するために必要であることを、ここでも強調しておきたいと思います。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上
]]></description>
		<link>http://www.ekimae-it.com/thesis/%e6%88%90%e5%8a%9f%e4%ba%8b%e4%be%8b%e3%81%ab%e3%82%82%e3%81%a8%e3%81%a5%e3%81%8ferp%e5%b0%8e%e5%85%a5%e3%81%ae%e5%ae%9f%e5%8b%99%ef%bc%88%e3%81%9d%e3%81%ae2%ef%bc%89</link>
			</item>
	<item>
		<title>「検証ユニット方式」の実践によるＩＴＣ収益モデル例・５</title>
		<description><![CDATA[──訴求ポイントを誤った要注意事例──
＜はじめに＞
これまで４回にわたり、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がＩＴコーディネータの収益確保に結びついている例を見てきた。
　今回は、やや視点を変えて、「検証ユニット方式」運用におけるネガティブな側面に焦点を当て、案件がうまく進まなかった例を取り上げてみたい。
　本事例（Ｅ社とする）は、新米ＩＴコーディネータのＷ氏が、ある人の紹介で、Ｅ社を訪問したところから始まる。
　Ｗ氏は、“まいどフォーラム”のホームページを読んだり、メンバーからの聞きかじりで、「検証ユニット方式」の概要については理解していた。というか、理解しているつもりだった。現実には、アピールすべきポイントをはきちがえていたために、クライアントにも誤解を与えてしまい、人間関係がぎくしゃくする結果となってしまった。
＜１回転めの留意点＞
　すでに何度も述べてきたように、検証ユニット方式では「はじめに成果ありき」が原則である。第１回転めに、クライアントは「なきに等しい投資リスク」を負担し、ＩＴコーディネータから「ちょっとした軽い助言指導」を受ける。それでもＩＴ化の初期段階では、長年積もった悪い習慣が断ち切られるおかげで、意外と大きな成果（無駄の解消）が出やすい。そこをＰＲするのが肝心である。つまり、いかに自己の消耗を抑えながら、相手にとっての最大メリットを引き出すかが成否の分かれ目といえるのである。
　Ｗ氏にかぎらず、ここの部分をまちがって解釈してしまうＩＴコーディネータが少なくないと思われる。「最小の投資で最大の効果」という箇所を曲解してしまうと、ボランティアでもしないといけないような錯覚に陥り、「とにかく安い、安い」ばかりをアピールすることになり、けっきょく自分のスキルを安売りすることになってしまうのである。これはコンサルタント業に限ったことではないが、「売りやすくするために料金を下げる」というのは実に危険な選択であることを肝に銘じておかなければならない。
　「できるだけ相手にお金をかけさせるべきではない」というのは当然の心構えなのだが、いつでも「少なければ少ないほどよい」わけではない。「かかったコスト以上の成果」が出ているならば、成果に見合うだけの報酬はいただいたほうがよい。仕事はどこまでも仕事であって、ボランティアではないのである。
＜１回転めの検証＞
　Ｗ氏は、最初の１回めの訪問時にすでに、社内のホームページ運営などに関していくつもの重要な気づきがあったため、順を追って丁寧に改善のポイントを助言していった。例えばＥ社は、ホームページ制作を委託した会社に「ＳＥＯ対策費」という名目で毎月数万円の費用を支払い続けていたのだが、Ｗ氏が被リンク状況やキーワード設置などについて調べたところ、特に何も対策らしきものが見当たらなかった。どう考えても「継続的な支払いを打ち切るか成功報酬に切り替えるべき」というのが妥当な選択肢だった。
　Ｅ社の社長は、Ｗ氏のアドバイスを素直に受け入れ、毎月数万円のＳＥＯ対策費を打ち切った。それだけで年間数十万円のお金が節約になった。社長は喜んでＷ氏にＳＥＯを任せることにした。Ｗ氏の意識としてはＳＥＯはお金がかけなくてもできるもので、ちょっとした根気があれば成果が出る（表示順位が上がる）ものだった。あまりに簡単な助言だったため、報酬もなにもなく、第一回めの訪問は終わった。
　Ｗ氏のテコ入れによって、Ｅ社の検索サイト表示順位は少しずつ上がっていったのだが、問題はこの先で、実はＥ社社長は、「ＳＥＯ」の意味もよくわかっていなかった。「ヤフー」とか「グーグル」という検索サイトの存在価値もわからなければ、上位表示の意義もわからない。事実、検索順位が多少上がったからといって、それだけで会社に対する問い合わせが増えるような魅力的なコンテンツに肝心のホームページがなってなかったのである。
　社長はＷ氏になんとなく感謝しているし、現実に会社の経費は年間数十万円も浮いている。けれど、ＩＴでもっと大きな経営改善に貢献したいと考えているＷ氏は、「ＳＥＯを徹底すれば、お金をかけずに（ただで）ホームページが営業してくれる」と社長に説明をしてしまった。この言い方が致命傷だったのである。実際には検証ユニットの第１回転めで数十万円のコストカットが実現しているのに、その成果を帳消しにする言い方をしてしまった。帳消しにするだけならまだしも、ただで営業させると期待させたホームページが期待どおりに働かず、かえって失望させてしまったのである。
＜検証ユニットのあるべき姿＞
　では、Ｗ氏が墓穴を掘ってしまった原因はどこにあるのか。それを整理してみよう。まず検証ユニットの第１回転めには、「客観的にもパッと見てわかりやすい、しかも実感として感じられるくらいスッキリした成果」を出すことが求められる。相手はＩＴのことがよくわからない素人だからである。
　ゆえに例えば、ＳＥＯ対策費をカットして浮いたお金をそのままホームページ更新料として然るべきデザイン会社への支払に回したらどうだったであろうか。「同じ費用で、ホームページが毎月どんどん新しくなって、１年後には営業効果が出る」という仮説を示していたら‥‥である。それだと、ＩＴコーディネータ自身がイニシアチブを取って、ホームページのコンテンツを改善するための指示をデザイン会社に出すことができる。デザインが変わるのであればＩＴの素人でもパッとみてちがいがわかる。お金をかけないＳＥＯと組み合わせれば、たとえわずかでも問い合わせがくるようにできたはずなのである。その「問い合わせ」を、自身が生み出した成果として認めてもらい、たとえ幾ばくかでも報酬を払ってもらえるよう、あらかじめ経営者とのあいだで詰めておくべきであった。
　経営者は、すでに発生している固定費については覚悟ができているわけだから、それをタダにするというだけの成果よりも、同じ経費で明らかな改善を見せたほうがよいのは自明である。そして、たとえ額は小さくても、成果と報酬がリンクしていることを印象づける意味の請求を、できるだけ早めに起こしたほうがよいであろう。クライアントには「払う習慣」、自分自身には「いただく習慣」をつけていくことが──特にかけだしのころは──肝要である。
]]></description>
		<link>http://www.ekimae-it.com/thesis/shuekimodel5</link>
			</item>
	<item>
		<title>製造業顧客向け独立ITCとしてどう想いどう起業するか</title>
		<description><![CDATA[１、起業する意義
①     成熟経済下の日本の製造業
現在の製造業のビジネスモデルを大別すると、大きく垂直統合型と水平分業型に分かれる。
 垂直統合型では、製品設計、部品設計から部材の調達、組み立て、販売、メンテナンスまでライフサイクル全体を自社の企業下で実行されます。
　当モデルの代表起業例は、トヨタ自動車や松下電器などですがこのモデルでは設計から生産、販売まですべてを自前で行いますので、他社との差別化も図れ利益が取れる仕組みが構築できます。
　
　一方水平分業では、同一製品においてスペックやインタフェースを公開することで標準化を進めセットメーカ、部品メーカなど複数の企業が、あたかも一体化したような形で企業活動を行います。水平分業型の代表例はパソコンで、セットメーカと部品メーカがそれぞれ自社の強みを生かし規模を大きくしながら共存共栄することでビジネスを構築してゆきます。 
グローバル競争下にある現在、日本のセットメーカは付加価値をつけ収益を高める策として、これからも垂直統合型のビジネスを展開してゆくものと思われます。
　　ここでの課題は精度の高いグローバルなマーケティングでありサプライチェーンの構築であります。　またこのサプライチェーンの中で主導をなす敏感にマーケットの動きを感知するセンサーとセンサーに連動した瞬間瞬間ごとの変種変量のものつくりの仕組みの構築にあります。
　　一方部品メーカの多くは、ムラタ製作所や日本電産などの大手を除き相変わらず大手企業の下請けとして垂直統合型の一部機能として位置づけられ零細低収益組織から脱却できずにいます。
　　これらの多くの企業は技術的側面から見ると、他社がまねのできない製造技術を保有しておりながらそれが評価されず現状に至っています。
　　セットメーカのおごりでもあり甘えでもありますが、部品メーカもそこから脱皮する企業変革の動きができていない結果でもあります。
　　本当に他社にまねのできない差別化技術であることのPRや設計と連動した一連の
短納期開発生産の仕組みや、多品種微量生産にするなど垂直統合型の一部機能から水平分業モデルへの脱却などビジネスモデル変革が必要となってきます。
②     製造業のIT活用課題
次に製造業のIT有効活用度について見てみなす。
　セットメーカ、部品メーカを問わず中堅以上の製造業ではほぼ押しなべて
・     販売システムと販売分析管理システム
・     製造、購買、在庫管理システム
・     設計CADシステム
・     会計システム
・     人事給与システム
など基幹組織の基幹業務のコンピュータが稼動しています
しかしながらその実態は
・     製造、購買、在庫管理システムではビジネス環境変化の波について行けずに
その結果、的確な手配計画が作成できず単なる注文書／製造指図書発行機に成り下がっており製造管理システムとして有効に機能している例は多くはありません。
また、基本をなす在庫管理精度が低い、BOMの維持管理ができない、などでシステムが動かない原因となっている企業が散見されます。　
・     原価管理システムでは月締めの月次決算型で月中の収支予想が出来ない、また月末も仕掛りが不十分にしか把握で月次決算情報が当てにならない事態を引き起こしている。
また、需要変動対応として相変わらず在庫積み増し方の生産をおこなっており、実際販売に基づく収支管理になっていない。
・     設計CADシステムでは、相変わらず２次元の製作図面作成機能にとどまっており設計のスピードアップやものづくりと直結した開発設計機能の仕組みを有していない。
③     起業する意義
上記のごく製造業を取り巻く環境は大きく変化しており、その中で経営的観点からの課題や製造管理面からの課題に対応し、それにどう立ち向かっていいか答えを見つけ出せていない企業が多く存在する。
私は、これまで養ってきた経験、知恵を生かし、これら企業がより高収益で活力に満ち社会に貢献することで継続的に存在している会社であり続けるよう支援してゆきたい。
２、製造管理システム導入における問題点と原因／対策
　２－１、効果的稼動を阻害する要因
①     生産計画に基づきMRPをまわして手配しているが計画変更が多発して手配／手配変更が追いつかない
②     手配変更が多発し、何が正しい手配か管理不能になり発注者および納入業者とも混乱する
③     内作製造においては、現場管理者が出荷計画書などに基づき独自の判断でものづくりを進めその結果、完成品の過不足を招いたり、使用部材の過不足を招く結果となる。
④     また計画とは別の動きとなるため現場の進捗や問題点の見える化ができなく、問題が内在化し、改善が進まない。
また原価の把握もできなくなる
⑤     設計変更や新製品に対する部品表（PM/PS）の維持管理ができずあやまった手配や部品出庫指示となってしまいシステムが正常に動作しなく使い物にならなくなる。
⑥     部材の置き場が明確化、固定化できていなかったり、勝手に入出庫されたりするため帳簿在庫と現物在庫との差異が多発し、正しい手配が出せないなどが起こり必要部材の欠品が発生し生産に支障をきたす。
⑦     欠品防止のため安全在庫を見すぎ過剰在庫の原因となっている。
⑧     長納期品に対し的確な調達手段が取れておらず、欠品／過剰在庫を起こしている。
⑨     ビジネス環境や調達環境にうまく適合できていないため、システムトータルとして効果的にものづくりを支援するシステムになっていない。
⑩     高額を投下しシステムを構築／稼動させるもトップの思いの実現や、当初計画の効果が出せていない。
　２－２、効果的稼動を阻害する要因と解決策
　　上記問題点に対し真因分析すると以下のように分類される
　　２－２－１、システム導入前の準備PHASE
①     構築システムの目標値の未設定や目標値設定に対する達成手段の未整備および達成手段に対する成功要因の不明確さ
②     生産管理システムを不稼動に導く各種要因に対する自企業の業務遂行能力調査と問題点に対する事前業務改善の実施が行われず問題点が内在化したままシステム化される
　　２－２－２、システム構築中のPHASE
①     業務の動きとシステムの動きの整合性をとる業務再設計が十分に行えておらず、稼動時のイレギュラー処理や問題発生時の対処を通してシステムと現場の動きが乖離してゆく
②     顧客要件を多く取り入れてしまったり過大な期待の仕組みを取り込む結果、システムのあちこちで不整合が発生したり、現場のちょっとした動きの変化にシステムが追従できず、結果現場が利用しなくなる。
２－２－３、稼動後のPHASE
①     システム維持管理組織の未整備により現場のニーズを吸い上げれなかったり、また現場の勝手な動きを阻止できなかったりし、結果として現場の動きとシステムの動きが乖離しシステムが動かなくなる
②     部品表維持組織の未整備により、部品表精度が低く結果としてシステムが正常に動作しなくなる。
③     KPIの測定やPDCAサイクルを定期的にまわす活動がされずシステム稼動後の評価および改善が疎おろそかになり改善活動が進まない。
３、効果的製造管理システム構築／稼動に向けたソリューションの提供
上記各種原因に対処するため以下のソリューションを提供する
（１）システム導入に向けたKGI、KPI設定と達成手段の策定支援
　（２）製造業務円滑化に向けた現状業務課題の抽出と業務改善指導
　（３）システム設計フェーズにおける顧客要求事項の抽出とその選択およびシステム機能の設計
　（４）現状稼動システムにおいて効果的運用を阻害している要因の分析抽出と改善策策定および実施指導
　（５）効果的原価計算／原価管理システムの構築指導
　（６）導入企業様の立場にたちソリューションベンダーの開発管理
　（７）高付加価値ビジネスモデルへの転換指導
４、事業化に向けた活動
　４－１、提供ソリューションの明確化とご紹介資料の作成、実績のご紹介
　４－２、HPの開設
　４－３、起業PRと営業活動
・     これまでのビジネスパートナーへのPR（お付き合いのあったシステム販社）
・     これまでのシステム導入エンドユーザへのPR（どうするか思案中）
・     ITCビジネス推進グループへの参加
５、終わりに
　　当レポートでは製造管理業務改善を中心にまとめた。
　私のもう一方の想いであるビジネスモデル変革については次回にまとめてみたい。
　　いずれにせよ、上記３項で示したソリューションの提供を通して日本の中堅／中小製造業の発展に少しでも寄与できたらとの想いで事業に取り組んでゆきたい。
　　　　　　　　　　　　　　　　　　　　　　　　　　以上　　ITコーディネータ　白須　廣幸　　　　　　　　　　　　　　　　2008/03/17作成
　　　　　　　　　　　　　　　　　　　　　　　　
]]></description>
		<link>http://www.ekimae-it.com/thesis/%e8%a3%bd%e9%80%a0%e6%a5%ad%e9%a1%a7%e5%ae%a2%e5%90%91%e3%81%91%e7%8b%ac%e7%ab%8bitc%e3%81%a8%e3%81%97%e3%81%a6%e3%81%a9%e3%81%86%e6%83%b3%e3%81%84%e3%81%a9%e3%81%86%e8%b5%b7%e6%a5%ad%e3%81%99</link>
			</item>
	<item>
		<title>コミュニケーション”に関する一考察</title>
		<description><![CDATA[主題　コミュニケーション”に関する一考察
 サブテーマ　ＩＴマネジメント成功の種！（あらゆるプロジェクト成功の陰に有る技術）
ITC　武島　直行（No.00002711）
はじめに
　昨今のＩＴ関連セミナーには”コミュニケーション技術”をテーマに取り上げたものを良く見かけます。
また、多くの参加者を集めているのもこの手のテーマのセミナーのように見受けます。
　これは、世間一般に、”コミュニケーション”の重要性あるいは、困難性が認識されているということと、考えます。
　ところで、一般の生活の中での”コミュニケーション”と何が異なるのでしょうか？
　親子・兄弟姉妹、友人、夫婦、etc
　ＩＴはもとより、多くのビジネスの現場においては通常の”コミュニケーション”とは別の”コミュニケーション”が要求されているのでしょうか？
序論　“世間、環境の変化”
　昨年は史上希に見る暖冬、今年は例年にない”積雪”を記録するなど、異常気象？の一端を身近に感じております。
　団塊の世代の方々の退職時期も到来しつつあり、関連する報道も時折、新聞や雑誌に掲載されています。
　日本人いや、日本も随分と変わってきたように感ずるのも小職が年を取ったせいでしょうか。
本論１　”恥を知れ！”
　私が小学校の６年生の時、今でも鮮明に残っている場面があります。
　授業中、黒板に示された問題を解くようにと、皆に指示があり、私も得意げに解いて、皆の解答を待っていました。
　皆が一通り解き終えて、正解が示されて、「正しく解けた人？」と、担任が聞いたので、私も”迷いながら”手を挙げていました（実は、解き方は合っていたけれども、途中の計算にミスがあって正解ではなかったからです）。
　担任は、何故か私のノートを見るなり、１発のビンタを右の頬に浴びせてきました。
“ビシイ”「恥を知れ！恥を！」と、一言頂戴したのですが、今でもその声を鮮明に記憶しています。
　これは、その後の私の行動規範を築いた一つの事件でもありました。
　（今の世の中、ビンタなんて暴力とされるのでしょうか）
　当時、幼いなりに、何故？って、考えていました。
　それも、スポーツを観戦していて、回答らしいことに気づいたのです。
（自慢ではありませんが、小職は勉強ではトップクラスで私立中学受験も打診されていました）
　・　よく、バレーボールなどでタイムで選手が集まった際に、エース格の選手を中心に叱咤している光景
　・　あるテレビ番組で、「そんなプライドなんか捨てろ！何の厄にも立たない」、という、先輩刑事？の一言
　・　何のポスターでしたか、「人が見てないと思って、ルールに反して良いのか？」という問いかけ
　これも一種のコミュニケーションと思います。この時の担任の気持ちがどれに近かったのかは不明ですが、確実に私に対する痛烈なメッセージであることには変わりありませんし、私自身、以降は世間に何らの背を向ける行為をすることはしない、と心に誓い、実行してきましたから、先生の行為は意味を持った、と言えると思います。
ただ、このコミュニケーションも欠点を持っておりまして、今でも当人に確認をしたわけではありませんから、一方的な理解に終わってしまっていることです。この場合、信頼感がないと成り立たないような、結構危険な意思伝達の手段であるように思います。
本論２　”出来ました”と”判ってます”
　上司と部下の会話の中で、“出来ました”、という返事がでてきました。
　通常なら、上司はこれで収めることなく、”出来上がった内容の確認”を行わねばならないのですが、その時は、この上司は“そうか”と聞き流しました。
　このときも、私は“何故？”と感じておりました。
　案の定、そのプロジェクトは納期通りに終わらず、納期通り仕事を済ませていた私までもがその影響を被って、残業代も出ない残業（今は奉仕残業と呼ぶのだそうです）に半年余りを費やし、帰宅できたのは月に数日といった悲惨な毎日を元気に生きていた新人の時代が鮮明によみがえってきます。
　プロジェクト管理に関する技術も話題も今では、数段多く提供されている現在でありながら、多くのプロジェクトが予定通りに進んでいないのは何故なのでしょうか？
　小学生当時の私のような心境であったのか、会話や報告を適当に終わらせたい一心であったのか、なすべきことが判っていなかったのか、当事者のレベルが違いすぎるのか、．．．種々、要因を推察することが出来ます。
おそらく、その要因の最たる部分が解決されていないことは事実でしょう。
では、どうしてそのような事態に至るのでしょうか？
　“報連相”の訓練はどこの企業でも盛んに行われています。非常に結構なことです。
しかし、現実問題では研修した通りには行われていないのではないでしょうか？
どうして？
　教育・訓練は、ＯＪＴが最も効率が良く、仕事に反映できると思います。
　しかし、残念ながら、”報連相”やコミュニケーションの研修は技術研修ほど行われていないのではないでしょうか。人間関係はどうか？育ってきた環境の相違で、価値観や考え方の全く異なる人間の中での意思伝達は？
　果たして、コミュニケーションは上手くいくのでしょうか？多分、表面的いは行われていても、実際には機能していないのではないでしょうか。
　指示されることは楽であり、マニュアル通りに仕事を維持・運営していくことで一定の評価を得られれば、十分？と思っている人類はどれくらいおりましょうか。
　親子間でコミュニケーションがとれていない、そのような人間が、果たして他人とのコミュニケーションを行えましょうか？
　
　私は、見ず知らずの人に混じったときほど、マナー・モラルを気にしますが、今の若者たちは逆のように思います。
知人間での自分の評価やプライドあるいは気配りが優先されているからと、私は思います。
”恥”を感ずる場所が異なっているのでしょうか。
　「判っています」と答える方ほど、言動が不一致です。本当は判っていないのです。だから、注意されるのですが,指摘されることを好ましく思っていない人類は、必ず、「判っています！」と断言します。
　コミュニケーションはありがたいもの、と思えるようになれば、「ありがとうございます」と言えるようになれば会話も実のあるものになるでしょう。
　今、思い出す、松下幸之助氏の「素直になりなさい」。
本論３　”水戸黄門の主題歌”
　「人生楽ありゃ苦もあるさ」、確かに言い当てています。
　今風の人類はやたら“苦”を嫌がります。
　常に“楽”でありたい、と本気で思っているのでしょうか？
　”苦楽”の経験があるのでしょうか？
　何故、”楽だ””苦だ”と判断できるのでしょうか？
　これは推測ですが、”経験したこと”、”誰かが先に経験したこと”は”楽だから”自分もします、けれども、”自分が初めてするのは困る”、ことの意思表示のようにも思えます。
これにはマニュアルもありませんから。
　
　よく聞く言葉、「理解したら（納得したら）やります」もこれと同じ事を言っているのではないかと思います。
　人数の多少は関係なく、プロジェクトメンバーとのコミュニケーションは、ある意味で、文化の異なった外国人と仕事をするようなものと同じように考えています。
　扱う言語が共通である以外には、相互に理解・納得できる項目を多くしていく他はない、とも思えます。
　最終的には、相互にメリットを共有できる結果を生み出すことができるコミュニケーションの手段と実際が求められているように思います。
まとめ　”キャバ嬢との会話”
　あまり行ったことはないのですが、この手の商売の方と会話するのは結構楽しいものがあります。
　残念ながら、全員と言うわけではなく、特定の”売れっ妓”になりますが、彼女らは自分の欲しいもの、あるいはしてほしいこと、を相手の口で言わせることに長けています。
　当然、こちらの感情や素性とか予備知識とかをしっかり把握しているようです。
　よく、”相手の気持ちになって”とか、言いますが、”相手の考えること”や”言い分”とか、あるいは”表情の変化”とかを敏感に認識できない人類には、このような芸当が出来るとも思えませんし、期待するのも愚かに思います。
　これが出来るから、トップに君臨しているのだと思います。
　判りやすく言えば、「”相手が嫌がること”を、あなたはしてほしいか？」と問われた場合に、何をしたら嫌がるかが理解できない人類とは、この手のコミュニケーションは全く機能しないのです。
　この点では将棋とかは上手く出来ています。
　年齢差のある人間の間でも、決まったルールのもとで指すことに関しては”相手の指して欲しくない”所に”指す”ことが勝つポイントでもあるので、双方がそのように励みますから、目指すところも明確です。
　ここには、言葉ではありませんが、立派にコミュニケーションが成立している、状態であると思います。
　コミュニケーションは、当人に限らず、環境や条件によって成功の度合いが左右されます。
　単に小手先のコミュニケーションの技術だけを習得しても役には立たないように思います。
　皆さんは如何思われますか。
 
ラベル: ITマネジメント 下書き 08/03/15 by IT狸
]]></description>
		<link>http://www.ekimae-it.com/thesis/%e3%82%b3%e3%83%9f%e3%83%a5%e3%83%8b%e3%82%b1%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e2%80%9d%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e4%b8%80%e8%80%83%e5%af%9f</link>
			</item>
</channel>
</rss>
