<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="wordpress/ME2.2.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>

<channel>
	<title>駅前ＩＴ相談所 by まいどフォーラム</title>
	<link>http://www.ekimae-it.com</link>
	<description>「まいどフォーラム」によるIT相談所のページです。</description>
	<pubDate>Mon, 19 May 2008 05:39:40 +0900</pubDate>
	<generator>http://wordpress.org/?v=ME2.2.3</generator>
	<language>ja</language>
			<item>
		<title>成功事例にもとづくERP導入の実務（その３）</title>
		<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>
		<comments>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#comments</comments>
		<pubDate>Sun, 30 Mar 2008 20:00:10 +0900</pubDate>
		<dc:creator>maido-ex</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">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</guid>
		<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>
		<wfw:commentRss>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/feed</wfw:commentRss>
		</item>
		<item>
		<title>「バンドマスター方式」によるＩＴコーディネータ収益モデルの検討</title>
		<link>http://www.ekimae-it.com/thesis/banmas</link>
		<comments>http://www.ekimae-it.com/thesis/banmas#comments</comments>
		<pubDate>Tue, 25 Mar 2008 14:36:35 +0900</pubDate>
		<dc:creator>maido-ex</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">http://www.ekimae-it.com/thesis/banmas</guid>
		<description><![CDATA[＜はじめに＞
クライアントの企業規模が大きくなると、ひとくちにＩＴ化といってもその範囲は上流から下流まで多岐に及ぶ。大きくは経営寄りのもの、システム寄りのものがあり、さらにシステム寄りのものには、ＳＥ寄りのものからプログラマー寄りのものまである。経営寄りのものでは財務系のもの、マーケティング系のものなど、とてもひとりの専門知識では賄えない広さと深さがあるといってよい。そこで、比較的大型の案件を処理するにあたり、ＩＴコーディネータの横のつながり、チーム連携が重要になってくるのである。
　いっぽうＩＴコーディネータは、その資格維持の仕組み上、協会に認定された「届出組織」というグループ単位で活動していることが多い。セミナーや勉強会は届出組織によって主催されることがほとんどなので、大半のＩＴコーディネータは、なんらかの届出組織に所属し、そこで顔見知りになり、ビジネス上の連携が始まりやすいのである。
　コンサルタント間の連携については、税理士と社会保険労務士、司法書士といった、いわゆる士業を営む専門家同士が組合を作ったりして連携するケースが珍しくない。相互補完的な業務を行うために、クライアントにしてみれば、ワンストップでサービスを享受できるメリットがある。
　ところが、それぞれが独立したコンサルタント同士の連携はうまくいかないケースも多々ある。皆がプライドを高く持ち、専門性の高い仕事をしている有能な個人のため、それぞれがマイペースであり、お互いがお互いの専門分野を理解できず、しかもそれぞれが自分の利益を優先しがちだからである。極端に言えば呉越同舟があたりまえ、異なる流儀同士が衝突しないほうが不思議だともいえる土台があるわけである。
　そこで、このＩＴコーディネータ同士の不安定結合状態を解決する目的で、われわれ“まいどフォーラム”が試験的に取り組んでいるのが「バンドマスター方式」による組織連携マネジメントである。
＜バンドマスター方式の定義＞
「バンドマスター」とは、ジャズでよく使われる用語で、略して「バンマス」という。同じバンドでも、ロックバンドでは使われることはないのだが、要するにバンドを仕切るリーダーのことである。特にここでは、即席ユニットで演奏されるジャズライブをイメージしていただきたい。ついさっきまでは赤の他人同士だったサックス奏者やドラマー、ピアニストでも、集まったとたんにプレイできる、そのイメージである。「お互いにプロなんだから好き勝手に演奏してもいいライブになる」とはいかない。たとえ即席とはいえ、やはりバンマスを決めて、どのパートを誰がどんなふうに受け持つかについての仕切りが必要である。それがなければ「個別最適の積み上げが全体最適になるとはかぎらない」という結果に終わるであろう。
　ＩＴコーディネータには、大手企業に勤務する企業内コーディネータや、税理士や中小企業診断士を本業とするフリーのコーディネータ、システム開発やホームページ制作の会社を経営するベンダー型コーディネータなどのタイプがあり、勉強会の中で緩やかな連携を保っている。中堅企業からシステム導入の相談を受けたとしても、単独では処理できないので、数人のコーディネータに声をかけ、それぞれの得意分野を担当してくれるように依頼することになる。そこで「誰がバンドマスターになるか」についての完全合意が重要になるのである。
　結論から言えば、バンドマスターは、企業からファーストコンタクトを受けたＩＴコーディネータがなるのが原則ルールである。全責任を負う自信がないので放棄する場合は別だが、自らが営業活動を行い、クライアントに信頼され、某かのプロジェクトを託された最初のＩＴコーディネータこそが、そのプロジェクト全体を最優先してコントロールする権利をもつと見なすわけである。
＜バンドマスター方式の実践のために＞
バンドマスター方式の考え方をひとことで表すなら、「営業力があって、お客さんを見つけることができて、仕事を取ってこれるＩＴコーディネータがいちばん偉い」である。どれだけ専門知識が豊富でも、マーケットが見つからなければ収益は上がらないのであるから、この原則はコンセンサスを得やすいと思われる。ただ、営業力とリーダーシップは比例しないので、バンドマスターになったＩＴコーディネータが必ずしもリーダーとして最適ということにはならないかもしれないが、そのリーダーシップの欠如をチーム全体で補おうという姿勢が大切である。報酬に関わる金銭トラブルも大いに予測されるので、バンドマスターの頭越しに勝手な取引や提案をクライアントに対してしないことを盛りこんだ契約書にサインしておくことが欠かせないであろう。
　バンドマスターに求められることを整理してみると、お客さんを見つけたらまず、自分の所属している組織やその他の人脈から、プロジェクトメンバーを選定し、受託業務を遂行できるワークフォースを揃えること。集められた各メンバーが自身の指揮権に従う旨の契約を締結すること。この時点で、メンバーの貢献度合いに応じて、ある程度の報酬分配方針を明らかにし、造反が起こらないようにしておくこと、等である。
　予算が数百万、数千万に上るシステム導入案件が、ＩＴコーディネータ個人に単独委託されることは考えにくく、受注窓口としては、法人格のあるＩＴコーディネータのグループ（ＮＰＯ法人など）が想定される。確かにバンドマスターは、プロジェクト毎に招集される即席ユニットにおいては全責任者なのであるが、対外的な信用という意味では、組織としての最終責任者はやはりその法人の代表である。つまり、いくら緩やかな連携を前提とする即席ユニットといえども、法的根拠のある連帯責任を負っている社会人の集まりであることが絶対条件であり、バンドマスターを適切に指導育成する責務が、法人の代表者にあることは言うまでもない。
ＩＴコーディネータ　永田祥造
]]></description>
		<wfw:commentRss>http://www.ekimae-it.com/thesis/banmas/feed</wfw:commentRss>
		</item>
		<item>
		<title>【システム開発依頼の失敗と成功】</title>
		<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>
		<comments>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#comments</comments>
		<pubDate>Tue, 25 Mar 2008 02:41:23 +0900</pubDate>
		<dc:creator>maido</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">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</guid>
		<description><![CDATA[■はじめに■
　昨今、縦割り行政の問題が取沙汰されています。情報システムも同じ様に、各行政組織は膨大な情報を持っていますが、横断的な繋がりが余り無く、必要な情報を収集するには、行政組織毎に確認する必要があります。一般市民としては面倒に思う事が多々あります。
　しかし、スピードが重要なビジネスの場では、必要な情報を必要な時に取り出す事が出来ないと、競争相手に先を越されてしまう事があります。今回は、システム子会社を持つ会社の商品設計支援システムの｢システム開発依頼の失敗と成功｣について書かせて頂きます。この会社は製品を設計する為にいくつかの部門を持っており、各部門毎に重要な情報を管理しています。これらの部門は関連性が強く、データの共有が必要ですが、各々が情報を管理しているため、必要な情報を一括して取り出すことが出来ません。まさに縦割り行政に通じるところがあります。
　また、この会社は年間に複数のシステム案件をシステム子会社に開発依頼していますが、完成したシステムの中には、要件を満たしているにも関わらず、十分に活用されないシステムも存在します。この様な無駄な投資を削減する為に、システム子会社への要件依頼の方法を見直しました。
■システム開発依頼の失敗■
　システムを開発する場合、自社の要望を資料にまとめＩＴベンダーに依頼するという方法が一般的だと思います。
　しかし、この会社ではシステム開発を行なう時は、システム子会社からシステムエンジニアを呼んで、欲しい機能や画面・帳票イメージを伝え、システムエンジニアに資料を提出させるという方法をとっていました。システム子会社のエンジニアは若い社員が多く、依頼した内容をメモし、後日きれいな資料にして持ってきます。資料の内容も、依頼した要件が漏れなく書かれています。しかし、実際にシステムが出来上がってみると、不満な点も少なくなく、使いにくいという理由などで開発したシステムは、十分に活用されなかったり、作業時間が短縮した人がいる反面、増加した人もいて考えていた様に効果が上がらない事もありました。これは、システムエンジニアが依頼者側の業務を理解していないと共に、依頼した内容や方法にも問題があったと考えられました。
■要件依頼方法の改善■
【分析】
　もっと効果のあるシステムの開発を行う為に、システム開発時の作業の分析を行いました。この会社の各部門はそれぞれ専用システムを所有しています。すなわち、各システムはその部門に必要な機能しか備えておらず、部門間の情報連携が十分に取れていませんでした。また、システム開発依頼をする側にはコンピュータシステムの開発に関する知識や経験があまり無い為、開発要望をシステム子会社のシステムエンジニアとの打ち合わせの場で決定していくという方法をとっていました。
　問題点としてあがったことをまとめると、
(1)互いに必要な情報を、各部門で管理しているためデータの有効活用をしにくい。
(2)システム開発の依頼内容を、打ち合わせの場で決定しているため、依頼漏れが多く発生する。
　と言う事でした。
【改善】
　今後のシステム開発・改善で、より効果の高いシステムを作るために、これらの問題を改善する事になりました。
　改善方法として、以下の案が挙がりました。
(1)現状の把握
　関連部門間で効率良くデータを連携するために、関連する｢部門の業務｣と｢所有システム｣を資料化(表・図化)し、本来あるべき姿を想像出来るようにする。また、今後のシステム開発・改善時に、｢他部門との関連｣や｢無駄な作業の発生｣を考慮し、より広い視野でシステム開発依頼を行えるようにする。
(2)依頼内容の資料化
　システムエンジニアとの打ち合わせ時に決定していた依頼内容を、打ち合わせ前にまとめて資料化する事で、依頼の抜け漏れを削減する。
(3)システムエンジニアとの打ち合わせ
　システム開発を成功させるためには、依頼者側とシステムエンジニアとの協力が不可欠である。システムエンジニアは業務内容について理解が浅いため、(1)(2)の資料を使用し｢各関連部署の業務内容｣と｢開発を依頼するシステム要件｣をリンクして理解できるように説明することに勤める。その上でシステムエンジニアからの意見や提案を聞く様にする。
■改善後のシステム開発依頼■
　新規システムの開発を行なう事となり、まず部門内の要件を資料化し、部門内および関連部門でレビューを行い様にしました。この時、現状把握の為に作った、部門間の関連業務・関連システムをまとめた資料を使い、これまで見つける事が難しかった、リリース後に発覚するであろう追加要望や問題点を早期に発見する事が出来ました。
　また、システムエンジニアに明確な依頼が出来るようになった為、システムエンジニアから以前よりも多くの意見や提案を引き出せるようになりました。
　この結果、仕様確定後の仕様変更を削減し、システム開発を行った事で発生する事があった無駄な作業時間を無くすことが出来ました。
■おわりに■
　これらの資料は、システム開発時の参考資料(教訓)として使われる事になりました。今後のシステム開発・改善時に隠れた要件や問題点の早期発見をするために役立つと思います。また、これらの作業で深く思った事は、システム開発を成功させる大事な要素として、依頼する側の積極的な参加と、依頼される側のユーザ業務に対する理解(および興味)が必要だと思いました。
ITC　中谷　正明(006596)
]]></description>
		<wfw:commentRss>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/feed</wfw:commentRss>
		</item>
		<item>
		<title>成功事例にもとづくERP導入の実務（その2）</title>
		<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>
		<comments>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#comments</comments>
		<pubDate>Sat, 22 Mar 2008 13:53:51 +0900</pubDate>
		<dc:creator>maido-ex</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">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</guid>
		<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>
		<wfw:commentRss>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/feed</wfw:commentRss>
		</item>
		<item>
		<title>「検証ユニット方式」の実践によるＩＴＣ収益モデル例・５</title>
		<link>http://www.ekimae-it.com/thesis/shuekimodel5</link>
		<comments>http://www.ekimae-it.com/thesis/shuekimodel5#comments</comments>
		<pubDate>Thu, 20 Mar 2008 12:12:13 +0900</pubDate>
		<dc:creator>maido-ex</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">http://www.ekimae-it.com/thesis/%e3%80%8c%e6%a4%9c%e8%a8%bc%e3%83%a6%e3%83%8b%e3%83%83%e3%83%88%e6%96%b9%e5%bc%8f%e3%80%8d%e3%81%ae%e5%ae%9f%e8%b7%b5%e3%81%ab%e3%82%88%e3%82%8b%ef%bd%89%ef%bd%94%ef%bd%83%e5%8f%8e%e7%9b%8a%e3%83%a2</guid>
		<description><![CDATA[──訴求ポイントを誤った要注意事例──
＜はじめに＞
これまで４回にわたり、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がＩＴコーディネータの収益確保に結びついている例を見てきた。
　今回は、やや視点を変えて、「検証ユニット方式」運用におけるネガティブな側面に焦点を当て、案件がうまく進まなかった例を取り上げてみたい。
　本事例（Ｅ社とする）は、新米ＩＴコーディネータのＷ氏が、ある人の紹介で、Ｅ社を訪問したところから始まる。
　Ｗ氏は、“まいどフォーラム”のホームページを読んだり、メンバーからの聞きかじりで、「検証ユニット方式」の概要については理解していた。というか、理解しているつもりだった。現実には、アピールすべきポイントをはきちがえていたために、クライアントにも誤解を与えてしまい、人間関係がぎくしゃくする結果となってしまった。
＜１回転めの留意点＞
　すでに何度も述べてきたように、検証ユニット方式では「はじめに成果ありき」が原則である。第１回転めに、クライアントは「なきに等しい投資リスク」を負担し、ＩＴコーディネータから「ちょっとした軽い助言指導」を受ける。それでもＩＴ化の初期段階では、長年積もった悪い習慣が断ち切られるおかげで、意外と大きな成果（無駄の解消）が出やすい。そこをＰＲするのが肝心である。つまり、いかに自己の消耗を抑えながら、相手にとっての最大メリットを引き出すかが成否の分かれ目といえるのである。
　Ｗ氏にかぎらず、ここの部分をまちがって解釈してしまうＩＴコーディネータが少なくないと思われる。「最小の投資で最大の効果」という箇所を曲解してしまうと、ボランティアでもしないといけないような錯覚に陥り、「とにかく安い、安い」ばかりをアピールすることになり、けっきょく自分のスキルを安売りすることになってしまうのである。これはコンサルタント業に限ったことではないが、「売りやすくするために料金を下げる」というのは実に危険な選択であることを肝に銘じておかなければならない。
　「できるだけ相手にお金をかけさせるべきではない」というのは当然の心構えなのだが、いつでも「少なければ少ないほどよい」わけではない。「かかったコスト以上の成果」が出ているならば、成果に見合うだけの報酬はいただいたほうがよい。仕事はどこまでも仕事であって、ボランティアではないのである。
＜１回転めの検証＞
　Ｗ氏は、最初の１回めの訪問時にすでに、社内のホームページ運営などに関していくつもの重要な気づきがあったため、順を追って丁寧に改善のポイントを助言していった。例えばＥ社は、ホームページ制作を委託した会社に「ＳＥＯ対策費」という名目で毎月数万円の費用を支払い続けていたのだが、Ｗ氏が被リンク状況やキーワード設置などについて調べたところ、特に何も対策らしきものが見当たらなかった。どう考えても「継続的な支払いを打ち切るか成功報酬に切り替えるべき」というのが妥当な選択肢だった。
　Ｅ社の社長は、Ｗ氏のアドバイスを素直に受け入れ、毎月数万円のＳＥＯ対策費を打ち切った。それだけで年間数十万円のお金が節約になった。社長は喜んでＷ氏にＳＥＯを任せることにした。Ｗ氏の意識としてはＳＥＯはお金がかけなくてもできるもので、ちょっとした根気があれば成果が出る（表示順位が上がる）ものだった。あまりに簡単な助言だったため、報酬もなにもなく、第一回めの訪問は終わった。
　Ｗ氏のテコ入れによって、Ｅ社の検索サイト表示順位は少しずつ上がっていったのだが、問題はこの先で、実はＥ社社長は、「ＳＥＯ」の意味もよくわかっていなかった。「ヤフー」とか「グーグル」という検索サイトの存在価値もわからなければ、上位表示の意義もわからない。事実、検索順位が多少上がったからといって、それだけで会社に対する問い合わせが増えるような魅力的なコンテンツに肝心のホームページがなってなかったのである。
　社長はＷ氏になんとなく感謝しているし、現実に会社の経費は年間数十万円も浮いている。けれど、ＩＴでもっと大きな経営改善に貢献したいと考えているＷ氏は、「ＳＥＯを徹底すれば、お金をかけずに（ただで）ホームページが営業してくれる」と社長に説明をしてしまった。この言い方が致命傷だったのである。実際には検証ユニットの第１回転めで数十万円のコストカットが実現しているのに、その成果を帳消しにする言い方をしてしまった。帳消しにするだけならまだしも、ただで営業させると期待させたホームページが期待どおりに働かず、かえって失望させてしまったのである。
＜検証ユニットのあるべき姿＞
　では、Ｗ氏が墓穴を掘ってしまった原因はどこにあるのか。それを整理してみよう。まず検証ユニットの第１回転めには、「客観的にもパッと見てわかりやすい、しかも実感として感じられるくらいスッキリした成果」を出すことが求められる。相手はＩＴのことがよくわからない素人だからである。
　ゆえに例えば、ＳＥＯ対策費をカットして浮いたお金をそのままホームページ更新料として然るべきデザイン会社への支払に回したらどうだったであろうか。「同じ費用で、ホームページが毎月どんどん新しくなって、１年後には営業効果が出る」という仮説を示していたら‥‥である。それだと、ＩＴコーディネータ自身がイニシアチブを取って、ホームページのコンテンツを改善するための指示をデザイン会社に出すことができる。デザインが変わるのであればＩＴの素人でもパッとみてちがいがわかる。お金をかけないＳＥＯと組み合わせれば、たとえわずかでも問い合わせがくるようにできたはずなのである。その「問い合わせ」を、自身が生み出した成果として認めてもらい、たとえ幾ばくかでも報酬を払ってもらえるよう、あらかじめ経営者とのあいだで詰めておくべきであった。
　経営者は、すでに発生している固定費については覚悟ができているわけだから、それをタダにするというだけの成果よりも、同じ経費で明らかな改善を見せたほうがよいのは自明である。そして、たとえ額は小さくても、成果と報酬がリンクしていることを印象づける意味の請求を、できるだけ早めに起こしたほうがよいであろう。クライアントには「払う習慣」、自分自身には「いただく習慣」をつけていくことが──特にかけだしのころは──肝要である。
]]></description>
		<wfw:commentRss>http://www.ekimae-it.com/thesis/shuekimodel5/feed</wfw:commentRss>
		</item>
		<item>
		<title>製造業顧客向け独立ITCとしてどう想いどう起業するか</title>
		<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>
		<comments>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#comments</comments>
		<pubDate>Mon, 17 Mar 2008 12:44:32 +0900</pubDate>
		<dc:creator>maido</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">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</guid>
		<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>
		<wfw:commentRss>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/feed</wfw:commentRss>
		</item>
		<item>
		<title>コミュニケーション”に関する一考察</title>
		<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>
		<comments>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#comments</comments>
		<pubDate>Sat, 15 Mar 2008 16:42:55 +0900</pubDate>
		<dc:creator>maido</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">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</guid>
		<description><![CDATA[主題　コミュニケーション”に関する一考察
 サブテーマ　ＩＴマネジメント成功の種！（あらゆるプロジェクト成功の陰に有る技術）
ITC　武島　直行（No.00002711）
はじめに
　昨今のＩＴ関連セミナーには”コミュニケーション技術”をテーマに取り上げたものを良く見かけます。
また、多くの参加者を集めているのもこの手のテーマのセミナーのように見受けます。
　これは、世間一般に、”コミュニケーション”の重要性あるいは、困難性が認識されているということと、考えます。
　ところで、一般の生活の中での”コミュニケーション”と何が異なるのでしょうか？
　親子・兄弟姉妹、友人、夫婦、etc
　ＩＴはもとより、多くのビジネスの現場においては通常の”コミュニケーション”とは別の”コミュニケーション”が要求されているのでしょうか？
序論　“世間、環境の変化”
　昨年は史上希に見る暖冬、今年は例年にない”積雪”を記録するなど、異常気象？の一端を身近に感じております。
　団塊の世代の方々の退職時期も到来しつつあり、関連する報道も時折、新聞や雑誌に掲載されています。
　日本人いや、日本も随分と変わってきたように感ずるのも小職が年を取ったせいでしょうか。
本論１　”恥を知れ！”
　私が小学校の６年生の時、今でも鮮明に残っている場面があります。
　授業中、黒板に示された問題を解くようにと、皆に指示があり、私も得意げに解いて、皆の解答を待っていました。
　皆が一通り解き終えて、正解が示されて、「正しく解けた人？」と、担任が聞いたので、私も”迷いながら”手を挙げていました（実は、解き方は合っていたけれども、途中の計算にミスがあって正解ではなかったからです）。
　担任は、何故か私のノートを見るなり、１発のビンタを右の頬に浴びせてきました。
“ビシイ”「恥を知れ！恥を！」と、一言頂戴したのですが、今でもその声を鮮明に記憶しています。
　これは、その後の私の行動規範を築いた一つの事件でもありました。
　（今の世の中、ビンタなんて暴力とされるのでしょうか）
　当時、幼いなりに、何故？って、考えていました。
　それも、スポーツを観戦していて、回答らしいことに気づいたのです。
（自慢ではありませんが、小職は勉強ではトップクラスで私立中学受験も打診されていました）
　・　よく、バレーボールなどでタイムで選手が集まった際に、エース格の選手を中心に叱咤している光景
　・　あるテレビ番組で、「そんなプライドなんか捨てろ！何の厄にも立たない」、という、先輩刑事？の一言
　・　何のポスターでしたか、「人が見てないと思って、ルールに反して良いのか？」という問いかけ
　これも一種のコミュニケーションと思います。この時の担任の気持ちがどれに近かったのかは不明ですが、確実に私に対する痛烈なメッセージであることには変わりありませんし、私自身、以降は世間に何らの背を向ける行為をすることはしない、と心に誓い、実行してきましたから、先生の行為は意味を持った、と言えると思います。
ただ、このコミュニケーションも欠点を持っておりまして、今でも当人に確認をしたわけではありませんから、一方的な理解に終わってしまっていることです。この場合、信頼感がないと成り立たないような、結構危険な意思伝達の手段であるように思います。
本論２　”出来ました”と”判ってます”
　上司と部下の会話の中で、“出来ました”、という返事がでてきました。
　通常なら、上司はこれで収めることなく、”出来上がった内容の確認”を行わねばならないのですが、その時は、この上司は“そうか”と聞き流しました。
　このときも、私は“何故？”と感じておりました。
　案の定、そのプロジェクトは納期通りに終わらず、納期通り仕事を済ませていた私までもがその影響を被って、残業代も出ない残業（今は奉仕残業と呼ぶのだそうです）に半年余りを費やし、帰宅できたのは月に数日といった悲惨な毎日を元気に生きていた新人の時代が鮮明によみがえってきます。
　プロジェクト管理に関する技術も話題も今では、数段多く提供されている現在でありながら、多くのプロジェクトが予定通りに進んでいないのは何故なのでしょうか？
　小学生当時の私のような心境であったのか、会話や報告を適当に終わらせたい一心であったのか、なすべきことが判っていなかったのか、当事者のレベルが違いすぎるのか、．．．種々、要因を推察することが出来ます。
おそらく、その要因の最たる部分が解決されていないことは事実でしょう。
では、どうしてそのような事態に至るのでしょうか？
　“報連相”の訓練はどこの企業でも盛んに行われています。非常に結構なことです。
しかし、現実問題では研修した通りには行われていないのではないでしょうか？
どうして？
　教育・訓練は、ＯＪＴが最も効率が良く、仕事に反映できると思います。
　しかし、残念ながら、”報連相”やコミュニケーションの研修は技術研修ほど行われていないのではないでしょうか。人間関係はどうか？育ってきた環境の相違で、価値観や考え方の全く異なる人間の中での意思伝達は？
　果たして、コミュニケーションは上手くいくのでしょうか？多分、表面的いは行われていても、実際には機能していないのではないでしょうか。
　指示されることは楽であり、マニュアル通りに仕事を維持・運営していくことで一定の評価を得られれば、十分？と思っている人類はどれくらいおりましょうか。
　親子間でコミュニケーションがとれていない、そのような人間が、果たして他人とのコミュニケーションを行えましょうか？
　
　私は、見ず知らずの人に混じったときほど、マナー・モラルを気にしますが、今の若者たちは逆のように思います。
知人間での自分の評価やプライドあるいは気配りが優先されているからと、私は思います。
”恥”を感ずる場所が異なっているのでしょうか。
　「判っています」と答える方ほど、言動が不一致です。本当は判っていないのです。だから、注意されるのですが,指摘されることを好ましく思っていない人類は、必ず、「判っています！」と断言します。
　コミュニケーションはありがたいもの、と思えるようになれば、「ありがとうございます」と言えるようになれば会話も実のあるものになるでしょう。
　今、思い出す、松下幸之助氏の「素直になりなさい」。
本論３　”水戸黄門の主題歌”
　「人生楽ありゃ苦もあるさ」、確かに言い当てています。
　今風の人類はやたら“苦”を嫌がります。
　常に“楽”でありたい、と本気で思っているのでしょうか？
　”苦楽”の経験があるのでしょうか？
　何故、”楽だ””苦だ”と判断できるのでしょうか？
　これは推測ですが、”経験したこと”、”誰かが先に経験したこと”は”楽だから”自分もします、けれども、”自分が初めてするのは困る”、ことの意思表示のようにも思えます。
これにはマニュアルもありませんから。
　
　よく聞く言葉、「理解したら（納得したら）やります」もこれと同じ事を言っているのではないかと思います。
　人数の多少は関係なく、プロジェクトメンバーとのコミュニケーションは、ある意味で、文化の異なった外国人と仕事をするようなものと同じように考えています。
　扱う言語が共通である以外には、相互に理解・納得できる項目を多くしていく他はない、とも思えます。
　最終的には、相互にメリットを共有できる結果を生み出すことができるコミュニケーションの手段と実際が求められているように思います。
まとめ　”キャバ嬢との会話”
　あまり行ったことはないのですが、この手の商売の方と会話するのは結構楽しいものがあります。
　残念ながら、全員と言うわけではなく、特定の”売れっ妓”になりますが、彼女らは自分の欲しいもの、あるいはしてほしいこと、を相手の口で言わせることに長けています。
　当然、こちらの感情や素性とか予備知識とかをしっかり把握しているようです。
　よく、”相手の気持ちになって”とか、言いますが、”相手の考えること”や”言い分”とか、あるいは”表情の変化”とかを敏感に認識できない人類には、このような芸当が出来るとも思えませんし、期待するのも愚かに思います。
　これが出来るから、トップに君臨しているのだと思います。
　判りやすく言えば、「”相手が嫌がること”を、あなたはしてほしいか？」と問われた場合に、何をしたら嫌がるかが理解できない人類とは、この手のコミュニケーションは全く機能しないのです。
　この点では将棋とかは上手く出来ています。
　年齢差のある人間の間でも、決まったルールのもとで指すことに関しては”相手の指して欲しくない”所に”指す”ことが勝つポイントでもあるので、双方がそのように励みますから、目指すところも明確です。
　ここには、言葉ではありませんが、立派にコミュニケーションが成立している、状態であると思います。
　コミュニケーションは、当人に限らず、環境や条件によって成功の度合いが左右されます。
　単に小手先のコミュニケーションの技術だけを習得しても役には立たないように思います。
　皆さんは如何思われますか。
 
ラベル: ITマネジメント 下書き 08/03/15 by IT狸
]]></description>
		<wfw:commentRss>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/feed</wfw:commentRss>
		</item>
		<item>
		<title>”儲ける仕組み”について</title>
		<link>http://www.ekimae-it.com/thesis/%e2%80%9d%e5%84%b2%e3%81%91%e3%82%8b%e4%bb%95%e7%b5%84%e3%81%bf%e2%80%9d%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6</link>
		<comments>http://www.ekimae-it.com/thesis/%e2%80%9d%e5%84%b2%e3%81%91%e3%82%8b%e4%bb%95%e7%b5%84%e3%81%bf%e2%80%9d%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6#comments</comments>
		<pubDate>Sat, 15 Mar 2008 16:39:44 +0900</pubDate>
		<dc:creator>maido</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">http://www.ekimae-it.com/thesis/%e2%80%9d%e5%84%b2%e3%81%91%e3%82%8b%e4%bb%95%e7%b5%84%e3%81%bf%e2%80%9d%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6</guid>
		<description><![CDATA[【主題】”儲ける仕組み”について
 サブタイトル：”ビジネスモデルの実例と儲けるための定石”に関する考察
ITC　武島　直行（No.00002711）
はじめに
　以前、「内部統制」に関する考察を進め、その前提に企業が独自の“儲ける仕組み”を運用して収益をあげることが命題であると言及した記憶があります。
　今回は、その”儲ける”あるいは”儲かる”仕組みに関して、少し掘り下げて考察してみたく思います。
　ただし、これは小職の経験則による記述であり、巷のあらゆる資料や書物によるものではありませんので、ご了解の上で読んでいただければ幸いです。
序論
”収益をあげる”ということ
　表面上は“総売上－経費”が少なくとも０以上で経営が維持されていること、要するに赤字経営ではない、ということで表現できます。
　ところが、”黒字経営を維持する”ためには、継続的にあるいは自然体で維持できる収益を生み出す”形”が必要となってきます。
　たとえば、今大相撲が開催されていますが、“強い”力士は個々に取組に勝てる“形”をもっています。この形に如何に容易に持ち込むことができるか、が強さの差になってきているように伺えます。当然、そのための技の種類や体力・気力も勝負の要素になりますが、自分の”形”でとりきってしまうことで九分九厘勝つ手応えを感ずることができるのではないかと推測いたします。
　このことは、企業間の競争にも共通することではないか、と考えます。
本論１
”己を知る”こと
　兵法で言う、”己を知り、敵を&#8230;”を実際に行ってみます。
　まずは、自社の位置づけというか、活動するエリア（市場）について考えましょう。
　自社が競争する分野・業界について、その特徴や状態に関して、過去の推移は当然として、常に最新の情報を入手して、これを調査・分析することで、自社のポジションやその業界の状態などを把握することから始まります。
　この結果と、自社の得手不得手との関連を抑えておくこととなります。
　その上で、自社の体力を抑えることとなります。
 ・自由に使えるお金（財務力）
 ・製品・サービスを売り込む力（営業力）
 ・同様な製品・サービスに対するコストパフォーマンス（商品競争力）や生産力
 ・製品・サービスを提供する人材とこれを教育する仕組み
　中国の故事に、“己を知れば百戦戦おうが危ういことはない”とあるが、正にその通りに行うこととなります。
本論２
“戦略”と“戦術”
　この違いって、何なのでしょうか？
　実は小職もある長編小説を読み終えるまで、具体的に思い描くことはできませんでした。
（参考までに、その長編小説とは、田中芳樹作「銀河英雄伝説」です。すっかりファンになってしまいました）
　私は次のように考えます。
“戦略”は方針とか“理念”という分野に属して、実戦を行う前に既に勝敗を予測できる状況にもっていく術で、たとえば、戦場で向き合う際には既に勝敗が決していることも想定できますし、戦わずして勝つことも可能となりましょう。
　一方で、“戦術”は実戦における、その都度の作戦や計画のことを指して、個々の力量と技を駆使した戦い方、と考えています。当然、局面ごとに刻々と変わってきます。
　ではビジネスではどのように考えましょうか？
　“戦略”に該当する部分を、経営方針や経営理念、中長期計画や短期計画といったビジネスプランに関する部分、　“戦術”に該当する部分を、強み/弱み（得手・不得手）や商品力、人材や資産とか行動規範といった部分と仮定しましょう。
　ビジネスモデルとは、その企業が実現可能なビジネスプランに従って、ある決まった形・行動規範による資産投入を行うことで収益を得ることができるパターン、と考えることができるように思います。
本論３
”はまった！ビジネスモデル”
私が「なあるほど！」と、感心したビジネスモデルに次の２例があります。
１．コミュニケーションビジネス
　世に言う、“出会い系”です。とかく悪評や悪用が広まっていますから、この場に例示するのも如何かとは思いましたが、判り易い仕組みですから、敢えて例示いたします。
　このシステムを使う契機は、種々有りましょうが、どれも良く似通っているのでは無いでしょうか？
　基本的には、純粋な異性との交友を求めている場合か否かとに大別できましょう。
　ただし、このシステムを提供する側は一概では語れないように考えます。
　まず、利用者の個人情報のみが欲しい場合には、とかく”無料”というキーワードを餌にして、利用者が主体的に個人情報を記入するような仕組みを持ったサイトへ導入するでしょう。
一旦入手した情報を元に、大抵は悪用されるパターンが主流かと思います。
　とは言っても有料であれば悪用は無いか？と問われれば、これも「ノー」と言わざるを得ません。俗に言うポイント制の場合には、如何にしてポイントを多く買わせるか（使わせるか）に注力されており、利用者の足元を見透かしたような情報の授受が延々と続く形態をとります。
（非常にわずかな一部のサイトは”純粋な出会い”を目的として運営されておりますが、ここではこのパターンは除いて語りますので、悪しからず誤解の無いようにお願いいたします。）
　初めから利用者から搾取することを狙っているサイトでは、俗に言う”サクラ”による信憑性のない多くの情報提供に利用者が取り込まれ、目的を達成することなく、利用料金を了解の上、支払っていくという、一見詐欺まがいのモデルに誘引されていきます。
　これは、振込詐欺あるいは偽造請求とか、不同意によるサイトへの登録といった、明らかに違法な運用とは異なって、利用者が主体的に利用した結果のポイント代金と認定できますから、ある意味ではビジネスモデルともいえる代物です。
（会える目的は達成したが、相手が未成年だとか、暴力沙汰に巻き込まれた、といった場合は、明らかに違法性があるものですから、ここで言うビジネスモデルにはあたりません。）
　それから、如何にしてサイト利用者を増やすか、が儲かるポイントとなります。　
　従業員？サクラの場合には、実際に会う危険性はありませんから、性別も年齢も不問ではないでしょうか？情報の伝達手段は最低限メールが使えればよいということですから、運営する側は、如何にして悪評が立たないようにして多くの利用者を長期にわたって維持できるか、ということに注力すればいい、ということになります。
　ただし、サイトの中には短期間で利用休止して、新たに別のサイトとして運営している場合も多く見受けます。この場合は、純粋に効果的なビジネスモデルであるとは言えない様に思います。
　結果的には、利用者が目的を達することができるなど、納得できる形態をとらないとサイトの継続は困難であり、また、広告主も現れない訳ですから、悪徳に終始したサイトは遠からず淘汰させることと思います。
２．リサイクルビジネス
　この場合の収益構造は簡単です。一言で言うと、無償で仕入れて有償で提供することが可能なシステムになっていることです。
　ただし、事業の実現と維持には相当の実行力・交渉力と覚悟が必要であるように思います。
　
　産業廃棄物の場合の一例を下記します。
　まず、タイヤのような２次加工が可能な産業廃棄物を無償（あるいは、回収費用をいただいて）で回収してくる。
当然、これを保管する場所の確保が必要ですが、回収、即、加工が可能であれば大規模な保管場所は不要になります。
　次いで、２次加工したものを、例えば建築・建設等の材料として売ることが可能であれば、これも売買ルートを確立しておくことで、特別な保管場所を有することなく発送が可能となります。
　このモデルの素晴らしいところは、材料に原材料費がかからず、むしろ回収することで収益があがります。ここで何もしなければ、その処分を行うことで費用がかかる、といった構造になりますが、ここで回収物を加工して二次製品にすることで商品価値を付加してしまうことにあります。
また、通常タイヤ当の処分は環境破壊を伴うことを考慮すれば、環境にも多少は優しい事業になります。
　唯一懸念されるのは、使用材料や加工品を保管する場所に関しては、その場所及び運送段階での環境面への悪影響を明確に把握した上での起業を考慮しなければ、公害排出企業のレッテルをいただくことに成りかねないことです。
折角、現代の風潮にマッチしつつある事業ですから、これをクリアして収益性の高いビジネスとして欲しいと思います。
まとめ
　企業が”儲ける”あるいは”儲かる”仕組み作りを行うには次の条件が満たされる必要があるように思います。
　・　活動（競争）する事業分野・市場の分析と自己の戦力分析ができていること
　・　違法性の無い、再現・継続可能な事業プランを持ち、これを実現する手段・体力を有していること
　・　商品・サービスを提供する際に自社固有の”形”（得意技）を持っていること
　・　事業の内容が広く社会に受け入れられること（社会貢献度）
　・　提供する商品やサービスを利用者が使い続ける理由・価値があること、自動的にリピートオーダーとなってかえってくること
　それぞれの企業は固有の商品（サービス）提供手段を有し、これを継続的・計画的に繰り返し運用できる仕組みを構築していくことで、“自社ビジネスモデル”を確固のものとして、より強固な収益モデルを構築しております。
　規模の大小や事業分野の如何を問わず、収益の確保できる条件には共通した要件があるように思います.
　上述は、その一つの考察として提示いたしました。
　今後もアンテナを縦横無尽に広げて、気のついたことをご提供いたしたく思います。
　written　by IT狸　2008/03/15 
]]></description>
		<wfw:commentRss>http://www.ekimae-it.com/thesis/%e2%80%9d%e5%84%b2%e3%81%91%e3%82%8b%e4%bb%95%e7%b5%84%e3%81%bf%e2%80%9d%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/feed</wfw:commentRss>
		</item>
		<item>
		<title>「ＩＴソリューションをバランス・スコアカード（ＢＳＣ）の活用で設定するには」</title>
		<link>http://www.ekimae-it.com/thesis/%e3%80%8c%ef%bd%89%ef%bd%94%e3%82%bd%e3%83%aa%e3%83%a5%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e3%82%92%e3%83%90%e3%83%a9%e3%83%b3%e3%82%b9%e3%83%bb%e3%82%b9%e3%82%b3%e3%82%a2%e3%82%ab%e3%83%bc%e3%83%89</link>
		<comments>http://www.ekimae-it.com/thesis/%e3%80%8c%ef%bd%89%ef%bd%94%e3%82%bd%e3%83%aa%e3%83%a5%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e3%82%92%e3%83%90%e3%83%a9%e3%83%b3%e3%82%b9%e3%83%bb%e3%82%b9%e3%82%b3%e3%82%a2%e3%82%ab%e3%83%bc%e3%83%89#comments</comments>
		<pubDate>Sat, 15 Mar 2008 16:33:34 +0900</pubDate>
		<dc:creator>maido</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">http://www.ekimae-it.com/thesis/%e3%80%8c%ef%bd%89%ef%bd%94%e3%82%bd%e3%83%aa%e3%83%a5%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e3%82%92%e3%83%90%e3%83%a9%e3%83%b3%e3%82%b9%e3%83%bb%e3%82%b9%e3%82%b3%e3%82%a2%e3%82%ab%e3%83%bc%e3%83%89</guid>
		<description><![CDATA[■はじめに
　戦略的ＩＴ導入にあたり経営戦略策定から入ることがプロセスガイドラインでは記載されているが、経営戦略から情報化企画フェーズにいたるところで、より簡便にできる方法はないか、より具体的で理解しやすい方法がないか検討してきた。
そこで戦略の展開とマネジメント手法としてのＢＳＣを活用できないかと考え、ＩＴソリューションを探索する方法を検討した。活用の可能性と方法について、また、活用上の問題点と課題について本論で考察していきたい。
（以下、バランス・スコアカードは「ＢＳＣ」と表記する）
（以下、「戦略目標」とはＢＳＣの４つの各視点で取り組むべき課題、達成すべき目標のことをいう）
■序論
　バランス・スコアカードとは、ビジョンと戦略を明確にすることで、財務数値に表される業績だけではなく、財務以外の経営状況や経営品質から経営を評価し、バランスのとれた業績の評価を行うための手法として、１９９２年に提唱された。
以来、導入している企業も多く見られ、中小企業でも導入活用を推進している例も多い。ＢＳＣの有効性の評価は有識者により分かれるにしても、戦略の因果と可視化ができる点と、戦略目標の指標化をすることで、ともすればお題目になり勝ちな戦略がモニタリングできる点は導入活用の意味は十分あると考えられる。
　ＩＴＣは企業へのＩＴ導入の支援をするにあたって、経営戦略から具体的なＩＴソリューションを検討する手順がより可視化されていれば、経営者の了解も取り付けやすい。また、先立って策定した経営戦略の実行状況の評価も同じ視点でみることができることで、経営のアドバイスと支援が可能になるといえる。
■本論　１　ＢＳＣの導入
ＩＴＣはまず経営者と幹部向けにＢＳＣの導入と展開の学習を進める必要がある。学習は事前に解説書などを提供しておくなどして準備をすすめる。
私のＢＳＣ導入支援経験から言うと、用語の意味と定義は理解されるためには時間がかかる。企業規模にかかわらず「経営戦略」という用語すらビジネス日常用語として頻繁に使用している業種、業界は少ない。ましてＢＳＣ特有の用語について、一度に理解できるとはいいがたい。ＩＴＣなりに砕いた表現や言いかえが必要である。また、ＢＳＣに関する学者やコンサルタントは、自分なりの解釈や自論を書籍等で出しているので、ＩＴＣも十分習得して自分なりの意見を持っておくほうがよい。経営幹部の中には個人的に興味を持ち、研修にも参加した人もいる。ＢＳＣの解釈で論争になったこともあるので、無意味な論争にならないためにも留意する必要がある。意見は意見として受け取り、いかに実務的に有効に使うかという点で討議し、合意することを進めたい。この点では学問的に追求する必要はない。
中期経営戦略の策定に当たっては、従来どおりの現状分析といくつかのツール（ＳＷＯＴ分析など）で戦略の柱となるものを策定しておく。ここではＢＳＣを戦略の展開手法として位置づけているので、戦略策定はプロセスガイドラインに沿って策定する。
さて、事前準備ができたところで、ＢＳＣ展開をはかるが、ＩＴソリューションの眼を見つけることに着目したいので、戦略ＭＡＰが完成させることにより神経を注力する。もちろん後の手順－ＫＰＩ設定、実行計画、アクションプランへの落とし込み－は必須である。
戦略ＭＡＰ上の戦略目標は十分に討議を重ね、全員の納得をとる必要がある。ともすれば戦略目標の表現が抽象的になり、それぞれのイメージがずれていくことがある。たとえば、「顧客ニーズの把握」という戦略目標をあげたところ、いきなりアンケートやヒアリングを想定した人もいれば、顧客情報ＤＢの構築を検討すると口にする人もいる。極端な例であるが。
ＢＳＣの４つの視点でいけば、財務の視点はＩＴ領域ではないので、顧客、業務プロセス、学習と成長の３つの視点をより明確に検討すればよい。
ところで「ＩＴインフラ」は学習と成長の視点に入っていると記載されている書籍もあるが、経験上からは個々の戦略目標からＩＴソリューションを引き出すほうがやりやすい。
次に戦略目標からＩＴソリューションを導く手順に進む。
■本論　２　　ＢＳＣ　戦略目標からＩＴソリューションを導く
　次に戦略目標の整理と内容のイメージなどの統合が行われると、各戦略目標を一覧に列挙する。
戦略目標の実行イメージについて再度検討し、ＩＴでの支援・実現を検討する。この段階では、該当するＩＴは導入済みであるか、否かや、具体的なアプリケーションやハードはなにかの検討には入らない。
先の戦略目標を例にとれば、
「顧客ニーズの把握」は
「現在、自社の営業部隊が担当する既存顧客から要望をくみ上げる仕組みが必要である。つまり自社の取り扱う製品・サービスに関わる要望や自社のビジネスチャンスとなるような潜在ニーズを情報として一元化し、いつでも閲覧加工ができるシステムが必要である。入力や出力方法、データ管理が簡単にできるものを導入することだ。」
と、まとめあげていく。順次、すべての戦略目標について、ＩＴの概要を出していく。
すべてが出ると重複するものもあるので、つまりＡという戦略目標でも、Ｂという戦略目標でも同じシステムが必要となった場合は、要はそのシステムは、ＡとＢの実現と支援で必要とあるということなので、ひとつに整理する。ＩＴが絡まない戦略目標もあるうるので、それはそれで実行計画レベルに落とせばよい。
ここまでは、自社の戦略実行に必要なＩＴがすべて出揃った状態となる。あくまでも戦略的なＩＴということである。現実の商品としてのアプリケーションはなにか、ベンダーはどこかは調達フェーズの項目である。
■本論　３　　導いたＩＴソリューションと現状ＩＴとの整合を図る
　本論　２までで、必要なＩＴは何かが概要レベルですべて出てきたことになる。しかし、
このまま導入の検討に入れるわけではない。日常の業務レベルのＩＴの現状評価が必要であるし、加えて、理想的なＩＴを使いこなせるのか、ＩＴ成熟度の評価はなされていない。コンピュータシステムが利用され始めた何十年も前から、「使いこなせないコンピュータシステム」「動かないコンピュータ」の話題は尽きない。経営者の想いと現場のＩＴスキル、体制の狭間で泣いているベンダーセールス、ＳＥの悩みはここにある。
調査すべき点は２点である。まず第一に「戦略的ではない」日常オペレーションでのＩＴ活用状況の把握である。これは各業務部門での不具合や要望をまとめることである。一般的な調査項目でヒアリングを行い、原因調査、将来への影響度などを整理すればよい。
２点目はＩＴ成熟度であるがこれも個人や組織のＩＴリテラシーなど調査項目はいくつかの手法があるので活用すればよい。ここで肝要なのは、戦略的に導入活用したいＩＴソリューションの実現可能性である。現状ＩＴの改善内容やＩＴ成熟度を加味して、３年計画レベルでの導入計画を策定する。
■結論
　ＩＴソリューションを導き出し手順として、ＢＳＣを利用することを説明してきたが、ＢＳＣを
活用するには、事前準備というハードルが高いともいえるし、企業側のトップから一般社員までの納得が必要で時間もかかることになる。一般的にＢＳＣの活用が広まらないには上の理由によると考えられる。
しかし、経営戦略の企業内での認知促進や共有、各自の役割理解などＢＳＣの有効活用面は大きいと考える。社員が私の勤めている会社はどっちに向かっているか、私の仕事はそれのどの部分を担っているかをわかっていることは企業力の源泉といえる。
ＩＴに関していえば、導入すべき、あるいは改革すべきＩＴは社員にとって、「仕事が増える」「新しい物に取り組まなければならない」という負担を感じている面もある。
戦略とＩＴを有機的に結び、可視化できるという意味において、ＢＳＣの導入活用は十分メリットがあると考える。以上、ＩＴソリューションの探索方法として、ＢＳＣの活用を提案したい。
ＩＴコーディネータ　　河野　順一
]]></description>
		<wfw:commentRss>http://www.ekimae-it.com/thesis/%e3%80%8c%ef%bd%89%ef%bd%94%e3%82%bd%e3%83%aa%e3%83%a5%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e3%82%92%e3%83%90%e3%83%a9%e3%83%b3%e3%82%b9%e3%83%bb%e3%82%b9%e3%82%b3%e3%82%a2%e3%82%ab%e3%83%bc%e3%83%89/feed</wfw:commentRss>
		</item>
		<item>
		<title>ITベンダーの「嘘の進捗報告」を見抜こう</title>
		<link>http://www.ekimae-it.com/thesis/it%e3%83%99%e3%83%b3%e3%83%80%e3%83%bc%e3%81%ae%e3%80%8c%e5%98%98%e3%81%ae%e9%80%b2%e6%8d%97%e5%a0%b1%e5%91%8a%e3%80%8d%e3%82%92%e8%a6%8b%e6%8a%9c%e3%81%93%e3%81%86</link>
		<comments>http://www.ekimae-it.com/thesis/it%e3%83%99%e3%83%b3%e3%83%80%e3%83%bc%e3%81%ae%e3%80%8c%e5%98%98%e3%81%ae%e9%80%b2%e6%8d%97%e5%a0%b1%e5%91%8a%e3%80%8d%e3%82%92%e8%a6%8b%e6%8a%9c%e3%81%93%e3%81%86#comments</comments>
		<pubDate>Sat, 15 Mar 2008 16:26:32 +0900</pubDate>
		<dc:creator>maido</dc:creator>
		
		<category><![CDATA[論文]]></category>

		<guid isPermaLink="false">http://www.ekimae-it.com/thesis/it%e3%83%99%e3%83%b3%e3%83%80%e3%83%bc%e3%81%ae%e3%80%8c%e5%98%98%e3%81%ae%e9%80%b2%e6%8d%97%e5%a0%b1%e5%91%8a%e3%80%8d%e3%82%92%e8%a6%8b%e6%8a%9c%e3%81%93%e3%81%86</guid>
		<description><![CDATA[■はじめに
　ITコーディネータの役割として、経営戦略の策定、IT戦略の策定、IT資源の調達、ITの導入、ITのサービス活用がある。その中にある、「ITの導入」フェーズでは、ITベンダーを利用して、システム開発・導入を委託するケースがある。そこで、システム開発を委託した後のITベンダーの進捗状況や品質のモニタリングを実施しなければならない。
　本論では、私のITベンダー側からの視点、過去のプロジェクト経験から、ITベンダーの進捗状況や品質状況のモニタリング時の注意点を提示する。
■進捗報告の嘘を見抜け
進捗報告は、良く報告しようという人が多いものです。今、多少の進捗の遅れがあった場合でも、後でリカバリができると思って、今日の進捗報告会では、事なかれで済ませたいと思い、「問題ありません。スケジュールどおりに進んでおります。」と言ってしまう。特に、自分を良く見せたい人や、気の弱い人などは、課題を表面に出すのが、「かっこ悪い」、「恥ずかしい」といった感情から、隠す傾向にあるので要注意だ。これらの予防策として、進捗をチェックするこちら側も事前に準備をする必要がある。ここで、嘘を見抜く３つの注意点を紹介しよう。
　まずは、現地で現物を見て現実を知ることを心がけることが重要である。よくある光景で、会議室でスケジュール表と課題シートを出されて、担当者が報告する手法では、本当のプロジェクト状況が見えないと思った方がよい。特に最初の段階で、完了したタスクにおいて作成した成果物の現物を見て確認しないと大変なことになる。よくある話だが、システム導入直前になって、こちらが思っていたのとは、まったく違ったものができていたとか、順調と聞いていた進捗が、実は大幅に遅れが出ていてリカバリ不可能な状態だったとか、報告だけを鵜呑みにして安心するのは非常にリスクが高い。「百聞は一見にしかず」とのことわざがあるが、まさにこれである。担当者の都合の良い報告ばかりを聞くのではなく、現物を見て判断すべきだ。担当者とできれば第三者の有識者にも参加してもらい、現地で現物を前にしてレビューを実施するのが、一番効果的である。
　次に、忙しいITコーディネータがすべてのタスクに関して、レビューを実施するのは時間的に不可能である。その場合は、進捗の達成基準を明確にすることが重要である。例えば、作業担当者に、あるタスクに関するステータスを確認した時に、「完了しました。」と報告があった場合、作業担当者が思う完了と、報告を受ける側で思う完了の基準が違う場合が多い。こうならないように、事前に各タスクに対する完了基準を明確にする必要がある。それをメンバーに対して、周知させ、その基準で報告させる必要がある。そうすれば、報告する側も報告される側も同じ基準で進捗状況を把握することできる。
　三つ目に、成果物の品質を客観的に本質的に理解することが重要である。少し抽象的になってしまったが、その例を後述に記す。
　ケース１．主観的な報告のみで済まそうとしている。
品質の確認をしても、「完璧です。」とか、「問題ありません。」などの、主観的な報告だけで済まそうとしているITベンダーは、もっとも要注意のベンダーである。中小のITベンダーに多い。
　ケース２．見た目は客観的だが、その内容が疑わしい。
進捗報告会での品質の確認で、アウトプットの品質を客観的に判断するには、数値による把握が代表的である。テストケース数やバグ修正数、バグ検出率、レビュー実施回数など指標はいろいろあるが、数字での報告があるからといって品質が高いと騙されてはいけない。ITベンダーは都合の良い数字をならべて、いかにも品質が良いように報告する傾向があるので要注意だ。どこかの雛形プロジェクトから指標をそのままコピーして、担当者がその指標を理解していないで利用しているケースがある。数値の報告を受けたときは、その根拠となるデータやレポートをチェックして、本当にその数値がその成果物の物であるか、改竄や隠蔽がないかを確認する必要がある。さらには、その品質指標がその成果物の品質を示すのに適当かどうかを判断する必要がある。
■まとめ
本論で述べた通り、相手の言っていることをすべて信用して進捗状況を鵜呑みにしてはならない。もう一度、３つの注意点を明示する。
１．「百聞は一見にしかず」・・・現地現物主義でレビューを実施すること。
２．「進捗の達成基準を明確に」・・・報告される側と報告する側で基準を合わすこと。
３．「数字に騙されるな」・・・提示された数字の裏まで、読み取ること。
性善説で相手の事を見たいと思う気持ちもわかるが、ビジネスの世界においては、時には性悪説で相手の事を見ていかなければならない。世の中の大きな流れとして、ビジネスの世界は、性悪説で見ていく動きになりつつある。アメリカからはじまったSOX法が日本にも上陸して、日本の各企業がその準備に追われている。現在のシステム開発の現場も同じで、プロジェクト品質、ソフトウエア品質も客観的な視点での品質提示が求められている。特に成果物を大量に作成するプロジェクトの場合は、その品質基準をクリアする為に多大なコストが必要になる。それを価格に反映できれば良いのだが、市場がそれを許さないのが現状である。しかし、それを克服したITベンダーこそが、今後、生き残っていく会社になるのであろうと考えている。
ITコーディネータ　森木　康太
]]></description>
		<wfw:commentRss>http://www.ekimae-it.com/thesis/it%e3%83%99%e3%83%b3%e3%83%80%e3%83%bc%e3%81%ae%e3%80%8c%e5%98%98%e3%81%ae%e9%80%b2%e6%8d%97%e5%a0%b1%e5%91%8a%e3%80%8d%e3%82%92%e8%a6%8b%e6%8a%9c%e3%81%93%e3%81%86/feed</wfw:commentRss>
		</item>
	</channel>
</rss>
