<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>???</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/" />
    <link rel="self" type="application/atom+xml" href="http://www.smartec.co.jp/support/atom.xml" />
   <id>tag:www.smartec.co.jp,2008:/support//3</id>
    <link rel="service.post" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3" title="???" />
    <updated>2007-06-25T07:35:44Z</updated>
    
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type  3.2-ja-2</generator>
 
<entry>
    <title>コラム第２９回： Start of smartec 2.0</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=122" title="コラム第２９回： Start of smartec 2.0" />
    <id>tag:www.smartec.co.jp,2007:/support//3.122</id>
    
    <published>2007-06-25T00:48:44Z</published>
    <updated>2007-06-25T07:35:44Z</updated>
    
    <summary>コラム第２９回： Start of  smartec 2.0 2007.6.25...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２９回： Start of  smartec 2.0</h3><br />
<div class="date">2007.6.25</div><br />
<div class="date">池田賢一</div><br />




弊社では、7月から新しい年度が始まります。2007年7月も新年度のスタート月なのですが、今年は、代表者が交替して始めて迎える新年度となりました。

年度のスタートを迎えるにあたり、スマーテックは新しい事業のテーマとして、 smartec 2.0 を掲げることにしました。今までとは違うスマーテックの活動を、こんな言葉で表現し、ビジネスを行う際の原点とするキーワードにしていきたいと思っています。これから数回程度、このコラムを使って、スマーテックが掲げる新しい活動とは何か？について、オープンにしていきたいと思います。

スマーテックはもともと、産総研が開発したソフトウェア・プラットフォームをベースに、製造業向けのソリューションを開発・販売する目的で設立した会社でしたが、ここで事業の主軸を大きく変えようと考えています。この変化を、Web2.0に倣って smartec 2.0 と呼ぶことにしました。変化の方向も、今さらながら「PCからインターネットへ」となります。



<b>smartec 2.0 とは？</b>

スマーテックに入社する時、さらに、代表取締役に就任する時、「いったい、どんなビジネスをしていけば良いのだろう？」と、深く考える必要がありました。それまでの自分のキャリアや、最近のIT業界の動向等々を頭の中に思い浮かべていたのですが、もっとも気になったのは、「関係する企業と、そこで働く人々と、その仕事」のことだったのです。

「最近IT業界は人気無いし…」であったり、「企業システムって、本当にそうやって作るのが良いのだろうか？」とかを考えていくうちに、「これまで、このIT業界で20年に以上お世話になったのだから、現状を良い方に変化させらるような活動をしよう。」と、思い立ちました。

そう、一言で言うと、こんなビジネスをしていきたいな、ということですね。

 “企業活動”とその中で働く人々が幸せになるよう、“インターネット技術”を使って、活動する“場”を創造し、運営することを、ビジネスとして行う。そして、このような活動を、 smartec 2.0　と呼ぶことにし、我々の活動の柱とすることにしました。



<b>さて、これから･･･</b>

私は、スマーテックという会社を通じ、より多くの企業や、その中で働く人々と仕事をしていきたいと考えています。　だとすれば、我々が何者なのか？を理解していただく、すなわち、キーワードと、内容だけでなく、具体的にはどんなビジネスをするのだろう？ということについて、明らかにする必要がありますね。

そして、私達が、このWebサイトを通じて、メッセージを発信していくことは、まさしく、スマーテックと皆さんが、協調して仕事をしていく、“場”のはじまりだと思うからです。

今後、 smartec 2.0 について、以下のような面からオープンにしていきたいと思います。

　■基本となる考え方と目標
　■目標を達成するための方法論
　■具体的に参加するまたは、しているプロジェクトとは？

今も、そして、これからも私たちと関わる全ての方々に、我々のメッセージとして発信していきたいと思います。
今後とも、よろしくお願いします。



<br /><br />
<a href="http://www.smartec.co.jp/support/column/backnumber.html">←コラム バックナンバー</a>
<a href="http://www.smartec.co.jp/support/dictionary/index.html">←悪魔の辞典</a>
<a href="http://www.smartec.co.jp/company/contact/index.html">←コメントはこちら</a>]]>
        
    </content>
</entry>
<entry>
    <title>コラム第２８回：見える化のためのスケール変換</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=97" title="コラム第２８回：見える化のためのスケール変換" />
    <id>tag:www.smartec.co.jp,2006:/support//3.97</id>
    
    <published>2006-08-03T15:00:02Z</published>
    <updated>2006-10-16T13:30:26Z</updated>
    
    <summary>コラム第２８回：見える化のためのスケール変換 2006.8.4 長谷部泰幸 『パ...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２８回：見える化のためのスケール変換</h3><br />
<div class="date">2006.8.4</div><br />
<div class="date">長谷部泰幸</div><br />




『パーキンソンの法則』の第二法則として、こんなものがあります。

In deciding on capital projects, the time taken to reach a decision will be inversely proportional time to the cost of the scheme.
（投資予算の議論では、決定に要する時間は、その計画の予算規模に反比例する。）

例えば、会議室に20万円弱のホワイトボードを買う案件については、各々が知識・経験・勘所をもっているため、高いとか安いとかマーカーの維持費がどうしたと議論が始まり、収拾つかなくなってしまいますが、他方で、企業を500億円で買収する議題を扱う会議の場合は、分からない人ばかりで議論にならず、結局判断できなかったり、後で責任をとりたくないといった保身感覚が働いて、短時間で反対なしで決まってしまうことがありがちです。

この例で分かるとおり、可視化の目的が、「見えるようにして」、「迅速な状況把握」を促すものだとしたときに、最初に考慮すべきやっかいな問題が、その大きさといいますか、『スケール』にあると考えています。人間は、自分が正確に理解可能な大きさの範囲が案外狭く、その範囲からはずれた途端に「見えなく」なります。

ただ、これは、人間イコール動物と考えれば、極めて自然な姿。何らかの工夫をすることで、人間にも適格な判断が出来るように『見える化』をしてやれば解決できます。それが今回のスケール変換というわけです。要するに、ものごとを、人間の理解可能な大きさに収めてあげるということです。


<b>世界の現状を可視化する</b>

スケール変換することにより、今の世界の現状について「見える化」したのが、大ヒットした『世界がもし100人の村だったら』（池田香代子再話・C.ダグラス・ラミス対訳・マガジンハウス）でしょう。（この本は、中国、台湾、韓国、タイ、フランス、スペインでも続々と翻訳出版されているそうです。）

世界の人口を63億人だと考えると、これは私たちが正確に理解できる範囲を超えていますが、それを「100人」というスケールにひき直すことで、今現在の世界の現状について、そして、その中で自分がどこにいるのかを、スッと理解することができます。この「スッと」というのが、見える化の究極の目的でもあります。

世界がもし１００人の村だったら・・・

１００人のうち５２人が女性です
４８人が男性です
３０人が子どもで　７０人が大人です

７５人は食べ物の蓄えがあり、雨露をしのぐところがあります
でも、あとの２５人はそうではありません
１７人は、きれいで安全な水を飲めません

もしもあなたが空爆や襲撃や地雷による殺戮や
武装集団のレイプや拉致におびえていなければ
そうではない２０人より恵まれています。

銀行に預金があり、財布にお金があり
家のどこかに小銭が転がっている人は
いちばん豊かな８人のうちの１人です

【『世界がもし100人の村だったら』より一部抜粋】


<b>日本の未来を可視化する</b>

１００人の村と同じアプローチで、日本の未来を考えてみましょう。テーマは最近話題の人口問題とします。

日本の人口は、2006年現在で1億2776万人。出生率が現状の「1.25」のままで人口が推移すると、ざっくり言って50年後には8000万人くらいになります。この「1億」とか「8000万」という数字も、私たちが「スッと」理解するには、スケール変換が必要です。今回は100人の村ではなく、自宅の近隣くらいで考えましょう。

自宅と、その両隣、お向い、裏くらいを想定して、６軒で合計20人のご近所だったとします。１軒で3～4人家族ですから、夫婦に子どもが1～2人、または同居のご両親が1～2人いるということです。ごく普通の風景です。

まず、50年後に8000万人になるということは、合計20人のご近所だったものが、13人に減ることを意味します。これに「１軒で3～4人家族」を適用すると、ご近所の６軒のうち２軒が空家になるというのと同等であることが分かります。

人口問題で最も深刻なのは「少子高齢化」だと言われますので、これについても20人のご近所の中で考えて見ましょう。今現在の人口構成を、20人のご近所の中で再現すると、だいたいこのようになります。

【今の構成】
■６軒のご近所で20人

●おじいちゃん・おばあちゃん：　４人
●おじさん・おばさん　　　　　　：　７人
●おにいさん・おねえさん　　　：　５人
●赤ちゃんと子どもたち　　　　：　４人

50年後の統計としては、例えば、「65歳以上の高齢者が人口に占める比率が、現在の21.2％から36.9％になる」と言っても直感的には分からないので、上記の構成で「見える化」を試みますと、こうなります。

【50年後】
■６軒のご近所で20人　→　２軒が空家で13人に

●おじいちゃん・おばあちゃん：　４人　→　５人　（増えた）
●おじさん・おばさん　　　　　　：　７人　→　４人　（４割減った）
●おにいさん・おねえさん　　　：　５人　→　２人　（半分以上減った）
●赤ちゃんと子どもたち　　　　：　４人　→　２人　（半減した）

どうでしょうか。
人口問題では、年金の破綻とか医療・介護にばかり焦点があたっていますが、こうやって自分の近所で考えてみると、50年後には、あらゆるものが一変することを予感できます。

今回取り上げたスケール変換については、他にも面白いものが沢山あります。今回は世の中を見える化する説明だけで終わってしまったので、次回は「個人の人生」を見える化するトピックスを提供する予定です。


<br /><br />
<a href="http://www.smartec.co.jp/support/column/backnumber.html">←コラム バックナンバー</a>
<a href="http://www.smartec.co.jp/support/dictionary/index.html">←悪魔の辞典</a>
<a href="http://www.smartec.co.jp/company/contact/index.html">←コメントはこちら</a>]]>
        
    </content>
</entry>
<entry>
    <title>見える化のためのスケール変換</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20060804.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=111" title="見える化のためのスケール変換" />
    <id>tag:www.smartec.co.jp,2006:/support//3.111</id>
    
    <published>2006-08-03T15:00:01Z</published>
    <updated>2006-10-16T13:33:11Z</updated>
    
    <summary>コラム第２８回：見える化のためのスケール変換 2006.8.4 長谷部泰幸 『パ...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２８回：見える化のためのスケール変換</h3><br />
<div class="date">2006.8.4</div><br />
<div class="date">長谷部泰幸</div><br />




『パーキンソンの法則』の第二法則として、こんなものがあります。

In deciding on capital projects, the time taken to reach a decision will be inversely proportional time to the cost of the scheme.
（投資予算の議論では、決定に要する時間は、その計画の予算規模に反比例する。）

例えば、会議室に20万円弱のホワイトボードを買う案件については、各々が知識・経験・勘所をもっているため、高いとか安いとかマーカーの維持費がどうしたと議論が始まり、収拾つかなくなってしまいますが、他方で、企業を500億円で買収する議題を扱う会議の場合は、分からない人ばかりで議論にならず、結局判断できなかったり、後で責任をとりたくないといった保身感覚が働いて、短時間で反対なしで決まってしまうことがありがちです。

この例で分かるとおり、可視化の目的が、「見えるようにして」、「迅速な状況把握」を促すものだとしたときに、最初に考慮すべきやっかいな問題が、その大きさといいますか、『スケール』にあると考えています。人間は、自分が正確に理解可能な大きさの範囲が案外狭く、その範囲からはずれた途端に「見えなく」なります。

ただ、これは、人間イコール動物と考えれば、極めて自然な姿。何らかの工夫をすることで、人間にも適格な判断が出来るように『見える化』をしてやれば解決できます。それが今回のスケール変換というわけです。要するに、ものごとを、人間の理解可能な大きさに収めてあげるということです。


<b>世界の現状を可視化する</b>

スケール変換することにより、今の世界の現状について「見える化」したのが、大ヒットした『世界がもし100人の村だったら』（池田香代子再話・C.ダグラス・ラミス対訳・マガジンハウス）でしょう。（この本は、中国、台湾、韓国、タイ、フランス、スペインでも続々と翻訳出版されているそうです。）

世界の人口を63億人だと考えると、これは私たちが正確に理解できる範囲を超えていますが、それを「100人」というスケールにひき直すことで、今現在の世界の現状について、そして、その中で自分がどこにいるのかを、スッと理解することができます。この「スッと」というのが、見える化の究極の目的でもあります。

世界がもし１００人の村だったら・・・

１００人のうち５２人が女性です
４８人が男性です
３０人が子どもで　７０人が大人です

７５人は食べ物の蓄えがあり、雨露をしのぐところがあります
でも、あとの２５人はそうではありません
１７人は、きれいで安全な水を飲めません

もしもあなたが空爆や襲撃や地雷による殺戮や
武装集団のレイプや拉致におびえていなければ
そうではない２０人より恵まれています。

銀行に預金があり、財布にお金があり
家のどこかに小銭が転がっている人は
いちばん豊かな８人のうちの１人です

【『世界がもし100人の村だったら』より一部抜粋】


<b>日本の未来を可視化する</b>

１００人の村と同じアプローチで、日本の未来を考えてみましょう。テーマは最近話題の人口問題とします。

日本の人口は、2006年現在で1億2776万人。出生率が現状の「1.25」のままで人口が推移すると、ざっくり言って50年後には8000万人くらいになります。この「1億」とか「8000万」という数字も、私たちが「スッと」理解するには、スケール変換が必要です。今回は100人の村ではなく、自宅の近隣くらいで考えましょう。

自宅と、その両隣、お向い、裏くらいを想定して、６軒で合計20人のご近所だったとします。１軒で3～4人家族ですから、夫婦に子どもが1～2人、または同居のご両親が1～2人いるということです。ごく普通の風景です。

まず、50年後に8000万人になるということは、合計20人のご近所だったものが、13人に減ることを意味します。これに「１軒で3～4人家族」を適用すると、ご近所の６軒のうち２軒が空家になるというのと同等であることが分かります。

人口問題で最も深刻なのは「少子高齢化」だと言われますので、これについても20人のご近所の中で考えて見ましょう。今現在の人口構成を、20人のご近所の中で再現すると、だいたいこのようになります。

【今の構成】
■６軒のご近所で20人

●おじいちゃん・おばあちゃん：　４人
●おじさん・おばさん　　　　　　：　７人
●おにいさん・おねえさん　　　：　５人
●赤ちゃんと子どもたち　　　　：　４人

50年後の統計としては、例えば、「65歳以上の高齢者が人口に占める比率が、現在の21.2％から36.9％になる」と言っても直感的には分からないので、上記の構成で「見える化」を試みますと、こうなります。

【50年後】
■６軒のご近所で20人　→　２軒が空家で13人に

●おじいちゃん・おばあちゃん：　４人　→　５人　（増えた）
●おじさん・おばさん　　　　　　：　７人　→　４人　（４割減った）
●おにいさん・おねえさん　　　：　５人　→　２人　（半分以上減った）
●赤ちゃんと子どもたち　　　　：　４人　→　２人　（半減した）

どうでしょうか。
人口問題では、年金の破綻とか医療・介護にばかり焦点があたっていますが、こうやって自分の近所で考えてみると、50年後には、あらゆるものが一変することを予感できます。

今回取り上げたスケール変換については、他にも面白いものが沢山あります。今回は世の中を見える化する説明だけで終わってしまったので、次回は「個人の人生」を見える化するトピックスを提供する予定です。


<br /><br />
<a href="http://www.smartec.co.jp/support/column/backnumber.html">←コラム バックナンバー</a>
<a href="http://www.smartec.co.jp/support/dictionary/index.html">←悪魔の辞典</a>
<a href="http://www.smartec.co.jp/company/contact/index.html">←コメントはこちら</a>]]>
        
    </content>
</entry>
<entry>
    <title>バックナンバー一覧</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/backnumber.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=95" title="バックナンバー一覧" />
    <id>tag:www.smartec.co.jp,2006:/support//3.95</id>
    
    <published>2006-08-02T15:00:00Z</published>
    <updated>2006-10-16T13:29:19Z</updated>
    
    <summary>2006.08.04　見える化のためのスケール変換 2006.06.28　見るこ...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[2006.08.04　<a href="http://www.smartec.co.jp/support/column/20060804.html">見える化のためのスケール変換</a>
2006.06.28　<a href="http://www.smartec.co.jp/support/column/20060628.html">見ることはわかること～可視化コラム序章</a>
2006.03.23　<a href="http://www.smartec.co.jp/support/column/20060323.html">導入ステップ⑥＝最終ステップ～システムの運用</a>
2006.02.24　<a href="http://www.smartec.co.jp/support/column/20060224.html">導入ステップ⑤～システムの導入</a>
2006.01.19　<a href="http://www.smartec.co.jp/support/column/20060119.html">導入ステップ④～システムの設計</a>
2005.11.21　<a href="http://www.smartec.co.jp/support/column/20051121.html">導入ステップ③～パートナーの決定</a>
2005.10.06　<a href="http://www.smartec.co.jp/support/column/20051006.html">導入ステップ②～要件定義書作成</a>
2005.09.10　<a href="http://www.smartec.co.jp/support/column/20050910.html">導入ステップ①～システム企画</a>
2005.08.18　<a href="http://www.smartec.co.jp/support/column/20050818.html">ITシステム導入ステップ</a>
2005.08.05　<a href="http://www.smartec.co.jp/support/column/20050805.html">経費をかけず投資効果の高いＩＴ化</a>
2005.07.11　<a href="http://www.smartec.co.jp/support/column/20050711.html">システム開発とは</a>
2005.06.29　<a href="http://www.smartec.co.jp/support/column/20050629.html">ＩＴコストの考え方</a>
2005.06.13　<a href="http://www.smartec.co.jp/support/column/20050613.html">業務標準化と数値目標</a>
2005.05.23　<a href="http://www.smartec.co.jp/support/column/20050523.html">業務フロー図を作りましょう</a>
2005.05.09　<a href="http://www.smartec.co.jp/support/column/20050509.html">生産業務が見えていますか？</a>
2005.04.06　<a href="http://www.smartec.co.jp/support/column/20050406.html">戦略は明確ですか？</a>
2005.03.23　<a href="http://www.smartec.co.jp/support/column/20050323.html">それで、何をしたいのでしょうか？</a>
2005.03.11　<a href="http://www.smartec.co.jp/support/column/20050311.html">中小企業の本音</a>
2005.03.02　<a href="http://www.smartec.co.jp/support/column/20050302.html">よく耳にする『後ろ向き』の話</a>
2004.11.29　<a href="http://www.smartec.co.jp/support/column/20041129.html">イノベーションの提案</a>
2004.11.18　<a href="http://www.smartec.co.jp/support/column/20041118.html">中小企業とIT</a>
2004.11.04　<a href="http://www.smartec.co.jp/support/column/20041104.html">共通プラットフォーム</a>
2004.10.26　<a href="http://www.smartec.co.jp/support/column/20041026.html">スピードの追求</a>
2004.10.20　<a href="http://www.smartec.co.jp/support/column/20041020.html">品質への取り組み</a>
2004.10.14　<a href="http://www.smartec.co.jp/support/column/20041014.html">目的意識</a>
2004.10.06　<a href="http://www.smartec.co.jp/support/column/20041006.html">失敗プロジェクト撲滅</a>
2004.10.01　<a href="http://www.smartec.co.jp/support/column/20041001.html">PLMから学ぶこと</a>
2004.09.21　<a href="http://www.smartec.co.jp/support/column/20040921.html">原則主義</a>]]>
        
    </content>
</entry>
<entry>
    <title>見ることはわかること～可視化コラム序章</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20060628.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=121" title="見ることはわかること～可視化コラム序章" />
    <id>tag:www.smartec.co.jp,2006:/support//3.121</id>
    
    <published>2006-06-27T15:00:01Z</published>
    <updated>2006-10-16T13:33:19Z</updated>
    
    <summary>コラム第２７回：見ることはわかること～可視化コラム序章 2006.6.28 長谷...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２７回：見ることはわかること～可視化コラム序章</h3><br />
<div class="date">2006.6.28</div><br />
<div class="date">長谷部泰幸</div><br />



ITシステム導入の6番目、最終ステップは、「システムの運用」です。システム導入の目的が達成されたかどうかは、この運用の結果で判断することになります。

運用は、それ以前の設計や開発と異なり、終わりのないステップであると言えます。期間も長く、関係者も多く、それだけにコストも膨らみがちです。自前で行うより、専門のアウトソーシング業者に委託するほうがはるかに効率的である場合もあります。

この「運用」において、利用者側として知っておくべきポイントは３つあります。それは「マニュアル」、「効果測定」、「利用教育」です。各々について解説します。

<b>最低限必要なマニュアル</b>

一般に、システム運用に必要なマニュアルは３種類あります。そのうちシステムベンダーから納品されるのが、「操作マニュアル」と「運用マニュアル」です。

「操作マニュアル」とは、実際に操作する時のオペレーションマニュアルで、「運用マニュアル」とは、システムを上手く活用するための注意書きにあたり、特例処理とトラブル復旧処理に関する記述があります。

３番目に必要なマニュアルが「業務マニュアル」で、これはシステムを活用していくための業務ルールにあたります。これはシステムベンダーからの納品はなく、自社で業務ごとに作成し、システムが稼働する前に用意しておくべきものです。また、このマニュアルは定期的な見直しが必要です。

<b>導入の効果を測定する</b>

システムをより効率的に運用していくために、また、システムを拡張し、より良いシステムにしていくため、システム導入の効果を測定する必要があります。

運用段階において、当初想定していた目的に対する貢献度を、具体的な数値などで評価します。システム設計段階での評価を事前評価、システム導入段階での評価を中間評価とするならば、運用段階での評価は事後評価にあたります。このように、「システムが導入できたらそれで良し」ではなく、導入の効果を測定し、次につなげていくＰＤＣＡサイクルの確立が最も重要になってきます。

そうした検討を行う機会（「業務マニュアル見直し会議」など）を設けていくことも利用者側の仕事です。

<b>利用教育体制</b>

どんなに良いシステムを導入しても、従業員がうまく使いこなせなければ意味がありません。そのためには、「業務マニュアル」の充実と、教育プログラムの考案が必要です。

また、ＩＴ化によって、今まで得られなかった新しい指標が簡単に得られるようになります。こういった指標は業務目標の設定等に役立ちますが、その指標をうまく使いこなす人材の育成も必要です。業務知識がなければ、こういった指標も使いこなせません。

このように、やはりＩＴシステムはツールであって、最終的には「人」であるといえるでしょう。人で始まり、人で終わるのがＩＴシステムの本来の姿なのです。

<b>「業務のＩＴ化」連載コラムは今回で完結</b>

コラム第10回を皮切りに、これまで15回の連載で業務のＩＴ化について連載コラムを書いてきました。予定通りの内容を網羅できたので、ここで一段落です。ホームページのアクセス数をカウントすると、このコラムのうち最も読まれているのは、「業務フロー図」に触れたもののようです。次いで「要件定義」がテーマのコラムとなっています。

今回の連載は、生産管理という業務を対象にしてみましたが、業務フロー図を作成したり、要件定義するという作業は、どんな会社のいかなる仕事にも有用な内容です。

変化の激しい環境の中で成長を続けるのが企業の宿命ですが、そうすると２～３年くらいで、どんな業務も属人化してきます。元々は定型業務だったのに、いつの間にか担当者が独自の方法論を駆使する非定型業務になってしまうケースは、どこの会社にも見られる現象です。それを放置することは、あらゆる面でのボトルネックの原因になりがちです。

こんなときに、業務フローや要件定義書で一度「業務の棚卸し」をやってみてはいかがでしょうか。業務の持つ付加価値を客観的に分解できるなど、解決のための色々なものが見えてくるでしょう。

スマーテックでは、ＩＴ化と直接関係なくても、こういった業務支援のサービスを実施しています。ご興味を持たれたらぜひ<a href="http://www.smartec.co.jp/company/contact/index.html">お問合せください</a>。]]>
        
    </content>
</entry>
<entry>
    <title>悪魔の辞典</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/dictionary/" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=90" title="悪魔の辞典" />
    <id>tag:www.smartec.co.jp,2006:/support//3.90</id>
    
    <published>2006-06-13T15:00:00Z</published>
    <updated>2006-06-14T07:43:55Z</updated>
    
    <summary>悪魔の辞典（あ行） IBM【あい・びー・えむ】 米国の大手企業のこと。日本名は「...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="dictionary" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">悪魔の辞典（あ行）</h3><br />
<br />

<b>IBM【あい・びー・えむ】</b>
米国の大手企業のこと。日本名は「国際事務機械株式会社」という。

<b>暗証番号【あんしょう・ばんごう】</b>
(1)自分の誕生日のこと　(2)自分の電話番号の下４桁のこと　(3)家族の誕生日のこと　(4)結婚念日のこと　(5)恋人の誕生日のこと

<b>アルバイト【あるばいと】</b>
ドイツ語のarbeit。大学生が社会勉強の為、個人個人で行う全学科共通の一般教科。自由選択なので、個人によって単位数はまちまちだが、この教科の学年末の評定で“５”を貰えた学生は、本来の教育課程を飛び越し、即座に社会に出て働くことが許される。

<b>インターネット【いんたーねっと】</b>
(1)現代の投機対象のこと。歴史的にはチューリップの球根、近年の日本では1980年代後半の土地がこれに相当する。　(2)なぜかホームページのことを示す場合が多い勘違いされたネットワーク技術のこと。　(3)企業が株価を上げるために利用するキーワードのこと。　(4)電話会社が「交換」という役割を有料で担うのに対し、この「交換」をユーザー・サイドに持ってきた新しい通信の仕組みのこと。　(5)パソコン通信というと暗いイメージがあるため付けた名前。　(6)アダルトものによって急速に普及した技術のこと。<I>《類義語》ＶＨＳ</I>

<b>いし【いし】</b>
『石』と書くと一般に硬いもの。『意思』と書くと一般にもろいもの。

<b>いたいけ【いたいけ】</b>
女性の出世に伴って変わる名前のひとつで、少女時代の状態を示す。数年後には「いけいけ」になり、数十年後には「いきいき」と変化する。

<b>育児書【いくじ・しょ】</b>
子育ての本を装って、本当は親を育てるために書かれた本のこと。

<b>いい加減【いい・かげん】</b>
自らの能力に見合った、その人の行為の度合い。たいていの場合、この言葉が使われるときは、行為・能力に見合った度合いまでこぎつけないので、行為を行った人物の低性能さを証明する。

<b>イオカード【いお・かーど】</b>
急いでいる時に限って残額が130円以下である改札機通過型プリペイドカード。同種のものに「SFカード」等がある。

<b>意味論【いみ・ろん】</b>
意味論の意味は、意味論の意味論によって決められる。

<b>運【うん】</b>
いちばん大事なときに限って最低値になり、どうでもいいときに限って最高位になる個人パラメータ。<I>《類義語》さいころ</I>

<b>エンジン【えんじん】</b>
動力源。中で必死に猿人（えんじん）がペダルをこいでいることからこう呼ばれる。

<b>大船に乗ったつもり【おおぶね・に・のった・つもり】</b>
かつての銀行。タイタニック号の乗客。

<b>オヤジ【おやじ】</b>
(1)男のコが悪ぶって父親のことを言うときの呼び名。　(2)年齢とは無関係に、雰囲気や頭髪、匂い、服装などの特徴を端的に表現するときに用いられる言葉。　(3)病気になると困るもののひとつ。不幸にして病気になったときに食べるのは「おじや」という。ちなみに、子供の行く手をはばむ行為を行ったときには「とおさん」と言う場合もある。

<h3 class="title">悪魔の辞典（か行）</h3><br />
<br />

<b>会社セミナー【かいしゃ・せみなー】</b>
会社説明会のこと。パンフレットを読めば分かるような話をされ、つまらないビデオを見させられ、突然「訪問カード」なる志望書を書かされたり、抜打ちの適性検査を受けさせられ、次回の予定を詰め込まれる。たとえつまらなくても、文句は会社から半径1km以内では決して口にしてはならない。最初の数回は緊張して望むが、ダレてくる頃が愚痴をキャッチされやすいので注意が必要だ。

<b>核分裂【かく・ぶんれつ】</b>
○→８のこと。《比較語》細胞分裂：Ｏ→Θ→θ→８→οο→ＯＯのこと

<b>カジュアルフライデー【かじゅある・ふらいでー】</b>
ゴルフ・ウェアを着て会社に出勤する金曜日のこと。

<b>カロリーメイト【かろりーめいと】</b>
習慣性があるらしく、リクルートスーツ姿の人の鞄にかなりの確率で入っている。固形物・液体ともに経口摂取する。液体の方はその味ゆえに置いている店が少なくレア物。末端価格が高いからというわけではない。

<b>看板娘【かんばん・むすめ】</b>
店の前に吊るされた、その店のお嬢さんのこと。

<b>肝を冷やす【きも・を・ひやす】</b>
次に細かく刻んで卵と一緒に炒める。

<b>キャンバス【きゃんばす】</b>
木の枠に布を張り、その上に学校を建てること。

<b>禁煙【きんえん】</b>
成人の文盲率を調べるために大きな文字で張り出される標語。わが国は思ったよりこの文字を読めない人が多いため、教育制度の見直しが求められている。

<b>口車【くち・ぐるま】</b>
この前友人が免許をとったので乗せてもらった。

<b>携帯電話【けいたい・でんわ】</b>
(1)ケータイのこと。(2)カメラとトランシーバーのついた電子メール送受信装置のこと。(3)ウェアラブルコンピュータという言葉を消滅させた電話機のこと。(４)街中で大声をあげても通報されないための演出小道具のこと。普段から発声練習が必要な、劇団や合唱団所属のひとに人気がある商品のひとつ。

<b>蛍雪の功【けいせつ・の・こう】</b>
夏は蛍を食べて飢えをしのぎ、冬は雪を食べて渇きをしのぐ、ということ。

<b>結婚指輪【けっこん･ゆびわ】</b>
これをしたとたん生活が苦しくなり、はずすとさらに苦しくなるという呪われたアクセサリー。

<b>剣【けん】</b>
ペンより弱いものとされるが、実際にペンだけをもって戦場へ赴いた例は聞いたことがないので、実戦においては剣はペンと互角、またはそれ以上かもしれない。

<b>公衆電話【こうしゅう･でんわ】</b>
実際に探し始めると周りには全く見あたらず、「もういいや」と諦めると案外近くにあったりする代物。そして、自分の並んだ列が一番待たされる。《類義語》公衆便所

<b>コールドゲーム【こーるど･げーむ】</b>
野球用語のひとつ。５回終了後にあまりの寒さにために試合続行が不可能なときや、どちらか一方の選手が凍死してしまって試合の続行が無意味になったときに、それまでの得点で勝負を決めること。

<b>ゴルフ【ごるふ】</b>
(1)散歩の英訳。　(2)一緒にプレイするひととは、散歩、食事、風呂と長時間に渡り談笑の機会があるため、接待として利用されている。接待として肌を触れ合うのであれば柔道やレスリングが最適だが、なぜか接待柔道などは存在しない。　(3)これを行う場所には会員権というものが存在し、1980年代後半の日本では、株式、土地とともに投機の対象となっていた。損をすると全部自己責任となる株式と違って、会員権は譲渡損失による税金還付が受けられるという素晴らしい投機対象であった。マネーゲームの損失の一部を国が補ってくれるシステムになっていたのである。

<h3 class="title">悪魔の辞典（さ行）</h3><br />
<br />

<b>サービス【さーびす】</b>
対価を払う側にとってはタダの物と認識され、対価を受け取る側にとってみれば値段に合わない高価な物と認識される人間の行為の称号。

<b>錯覚【さっかく】</b>
俺って才能あるじゃん。

<b>雑誌【ざっし】</b>
主義主張がないのに、言論の自由を盾に弱者をいびる出版物。広告とその広告の解説記事によって構成される書物。大きく専門誌と総合誌に分けられ、専門誌ではよりきめ細やかな商品広告が行われ、総合誌では評論家達が営業活動を行う場となっている。

<b>さっちゃん【さっちゃん】</b>
子供の時はバナナを半分しか食べられなかった女性だが、その後、遠くのほうに行ってしまい、 成人したころにはマーガレット・サッチャンと改名し、英国の首相にまで出世したという人物。鉄の女として有名。

<b>三角関係【さんかく・かんけい】</b>
男女三人の年齢を合計すると百八十であること。

<b>システム手帳【しすてむ・てちょう】</b>
プリクラ用アルバムの別名。

<b>就職成金【しゅうしょく・なりきん】</b>
交通費の差額で稼ぐこと。例えば北海道民が東京で活動をする時に、交通費を数社分まるまる貰っておきながら一回の上京ですべて用を足せば差額は全部自分の懐に入る。当然、交通費をくれる会社を事前にリサーチしておくことが重要である。人によっては数十万円単位で稼いでいるらしい。

<b>シンクロナイズドスイミング【しんくろないずど･すいみんぐ】</b>
鼻のつぶれた女性が笑いながら溺れている様子という意味の英訳。

<b>人事考課【じんじ・こうか】</b>
(1)エコヒイキを定量化し、正規分布させるという高度な技を直感的に完成させてしまう作業のこと。(2)管理職が部下に対して威厳を示すために利用できる数少ないツールのひとつ。(3)一般的に、評価を付けてから順位を決めているように思われているが、その実、逆のことをやっているため、他人に決して見せられない秘密のイベント。《類義語》プロセス評価　(4)会社側が管理職のことを信頼しているように見せかける手法のひとつ。

<b>心配【しんぱい】</b>
友人から面白い話を聞き出すときに使用する態度。

<b>スピード【すぴーど】</b>
(１)のむと気持ちの良いものだが、習慣性があり違法。(２)だすと気持ちの良いものだが、習慣性があり違法。(３)みると気持ちが悪くなるものだが、習慣性もなく適法。

<b>スポーツマン【すぽーつまん】</b>
ウルトラマン、スパイダーマンなどとともに世界を守る崇高な使命を与えられた存在。しかし、他のヒーローに比べ押しが弱く、また孤独さに欠けるため主流にはなれなかった。また、最近ではその数が増えすぎたためモラルの著しい低下が指摘されてきている。。

<b>税金【ぜいきん】</b>
国家を国家ならしめる重要要素。これの回収と再分配こそが政治であるとさえ言われる。我が国の税制の特に素晴らしい点は、税金を支払うことに税金をかけるという消費税を発見したことだろう。さらに、我が国の税政策に賛辞の念を加えるとすれば、好況の時は好況だから税金を沢山とる、不況の時は国庫が苦しいから税金を沢山とる、という永久増税過程理論を採用したところにある。

<b>生命保険【せいめい･ほけん】</b>
(1)本来、人生のリスク部分(病気や災害、死亡など)を補うためにかけておく金融商品であるが、最近では保険会社の倒産などにより、資産を失うかもしれないというリスクを楽しむために加入するもの。(2)定期・終身・養老の３種類しかないはずなのに、これらをイロイロな比率で組み合せ、名前を付けて、あたかも新商品のように見せかけることができる金融商品。(3)自分の人生をオカネで測定してみようと思った時に、それを測るひとつの手段。「こんなものか」と思うことも多い。

<b>セクハラ【せくはら】</b>
「君、胸いくつ？いひひ。」「ふたつです。」「・・・」

<b>センチメンタル【せんちめんたる】</b>
感傷的な気分の長さを表す単位。 他に感傷的な気分の面積や体積を表わす平方センチメンタルや立方センチメンタルなどがある。

<b>洗脳【せんのう】</b>
（１）「お客さん、どこか痒いところないですか？」　（２）他人が自分と異なる考え方を持ち、自分の考えは相手の考えより正しいと信じる時、相手を自分の側へ傍迷惑にも引き上げようとする行為。

<b>千利休【せん・の・りきゅう】</b>
(1)日本が誇る数学者のひとり。ワビ＋サビ＝（ワ＋サ）ビという因数分解の基本を考え出した。　(2)日本が誇る発明家のひとり。利休箸はいいとして、利休バック、利休饅頭から利休瓦などまであるのには驚かされる。

<h3 class="title">悪魔の辞典（た行）</h3><br />
<br />

<b>ダイエット【だいえっと】</b>
(1)「DIE＋EAT」食べると死ぬよ、という脅迫の言葉を兼ねた素晴らしい風習。(2)必要の無いと思われる人間はやりたがり、必要ありと認められる人間ほど触れたがらない餓死のシミュレーション。戦時にそなえての訓練でもある。

<b>対話【たいわ】</b>
自分の言いたいことを言って、相手の言うことを聞かないこと。

<b>対称【たいしょう】</b>
オーバーヘッド・キックに対してアンダーヘアー・チョップ。

<b>単語登録【たんご・とうろく】</b>
内容を見ると、その人物のパソコン利用目的が良く分かるように仕掛けられたワナ。

<b>知恵熱【ちえ・ねつ】</b>
高村光太郎がかかっていた病気。

<b>地球に優しい【ちきゅう・に・やさしい】</b>
人類のほうが地球より偉いということを標語にした言葉。

<b>チャット【ちゃっと】</b>
指八丁手八丁の英訳。

<b>中間管理職【ちゅうかん・かんりしょく】</b>
(1)会社の中の「その他大勢」の総称《類義語》ミドル・マネジメント(2)偉い人ではなく、若い人でもなく、平社員でもなく、大切な意思決定権限もないひとのこと。但し、責任だけはある場合が多い(3)役員が社員を末端まで管理するのは疲れるので、「中間」に配置して管理しやすいように工夫したことによって生まれた職位(4)地位的には中間にあるにもかかわらず、報酬は決して中間ではない管理職のこと(5)ハンコをキレイに押す技術を身につけるために設けられたポジション。

<b>町内会【ちょうない・かい】</b>
去年と同じでいいじゃないということを取り決める目的で酒を飲む会のこと。

<b>沈黙は金【ちんもく・は・きん】</b>
言い逃れできない状況を、「男らしい寡黙」に見せかける技術。

<b>ディズニーランド【でぃずにー・らんど】</b>
親が子供に「列をつくって並ぶことは日本人の美徳である」ことを躾るために設けられた教育の場

<b>手打ちそば【てうち・そば】</b>
武士が家臣や町人などを自ら斬り捨て、そのままよくのばしてそばにする。

<b>テンキー【てん・きー】</b>
数えてみたら17個あった。

<b>電子メール【でんし・めーる】</b>
(1)プライベートな目的で利用しても、傍目には仕事をしているように見せかけることのできる演出商品(2)簡単にメッセージのやり取りができるため、返事が来ないと利用者が不安になったり、人間不信に陥るネットワークシステム。そのため、相手には確認の電話を入れることがある。(3)国語力のない者同士の不信増幅装置。

<b>転職【てんしょく】</b>
ろくでなし→ひとでなし。

<b>ドット【どっと】</b>
点々がいっせいに笑う様子。

<b>トップダウン【とっぷ・だうん】</b>
よく繰り返される方策。人間が、自分以外の持つ権力を非常に嫌うことを証明している。

<h3 class="title">悪魔の辞典（な行）</h3><br />
<br />

<b>ナックル【なっくる】</b>
演歌を歌うときに装着。

<b>ナビゲーター【なびげーたー】</b>
ワニの一種。自動車の助手席に生息し、乗客を食べる。

<b>入社式【にゅうしゃ・しき】</b>
(1)普段、大勢の前で話すことのない役員のために、あまりコストをかけずに用意できる講演会(2)役員の話に対して、居眠りする人数がいつもより少ない貴重な集まり(3)会社案内の内容や、面接時の会社紹介にはウソが多いということを新入社員に告知する式典(4)一部の新入社員が、転職を考え始める最初の日(5)新入社員にとって、生涯でもっとも、近くに座っている異性が気になってしかたがない日

<b>ニュージーランド【にゅーじーらんど】</b>
赤ちゃんだけしか住めない国。政治もすべて赤ちゃんによって行なわれる。

<b>人月【にん・げつ】</b>
生産能力を表しているように見えて、実は逆の解釈も可能な単位。他の科学系単位と異なり、絶対値を定義できないことから、方便として用いられることが多い。

<b>ヌシ【ぬし】</b>
沼や湖にいる。ネス湖はネッシー、屈斜路湖はクッシー、 平沢湖はヘイタクシー。

<b>捏造【ねつぞう】</b>
(1)取材メモのこと (2)神の手のこと (3)世論調査や市場調査のこと

<b>年金【ねんきん】</b>
古くは「金」利殖詐欺や、どこかの宝石屋が「○年後に、この宝石を同価格で買い取ります」と言ったという詐欺事件が問題になったが、おそらく数年後、これら一連の詐欺事件に続くであろうと思われる「国家ぐるみの一大詐欺」の総称。

<b>ネット対応携帯電話【ねっと・たいおう・けいたい・でんわ】</b>
(1)暇つぶし機能付き携帯電話のこと。 (2)電波を受けることで脳を刺激するのに飽き足らない人が、親指を素早く動かすことで、さらに脳を刺激するようつくられた道具。

<b>ネットバンキング【ねっと・ばんきんぐ】</b>
銀行に出向けばタダでできることを、わざわざ高価なパソコンや携帯電話を使い、しかも通信料まで支払ってできるようにした画期的なサービスのこと。

<b>ノートＰＣ【のーと・ぴーしー】</b>
少し高価なステータスシンボル的機械のこと。IT業界などには、仕事上どうしても必要という人々もいるが、どちらかというと見掛けを気にするカッコつけが持ち歩く確率が高い。

<h3 class="title">悪魔の辞典（は行）</h3><br />
<br />

<b>歯医者【は・いしゃ】</b>
手品師のこと。お客の口の中に金属を入れ、その金属をお客のポケットのサイフからコインとして取り出すという芸を得意とする

<b>派遣社員【はけん・しゃいん】</b>
(1)業務内容や業績にかかわらず時間給で会社に勤めるための方法　(2)正社員が優越感を持てるようにと、会社が準備した環境のひとつ　(3)自分の部署には見当たらないような美女（または美男）を比較的簡単に配置できる唯一の方法　(4)家事手伝い中のお見合いで、イイひとがいなかった場合に、自分から探しに行くための手段のひとつ　(5)とてもじゃないが正式採用は無理と思われる会社での生活を経験できる制度《類義語》ホームステイ

<b>パワーポイント【ぱわーぽいんと】</b>
(1)中身の薄いプレゼンテーションを、印象良く見せるために考えられたソフトウェア製品のこと　(2)大きなディスク容量と高価で高速なＭＰＵをふんだんに使わせるために投入された戦略商品の代表格　(3)紙芝居作成ツール

<b>ヒッチハイク【ひっちはいく】</b>
車を止めて一句詠む。

<b>不確定性関係【ふかくていせい・かんけい】</b>
物理学をカジッたことのある人なら、量子力学でいうところの「粒子の位置と運動量を同時に測定する場合の精度についての関係式」だと分かる。この場合、『不確定性』の関係を意味する。しかしながら、一般には、不確定の『性関係』と捉えられる場合も多いため、決して「これを極めようと研究しています」と言ってはいけない。

<b>フレックスタイム【ふれっくす･たいむ】</b>
(1)出勤時間を遅らせても大丈夫なように導入された勤務時間体系のこと　(2)どの程度フレックスなのかの基準がないため、それほどフレックスでなくてもこの呼名を使うことのできる制度　(3)会社案内で、先進的な企業であることを印象づけるために書かれるキーワード　(4)ごくまれに、リラックスタイムと勘違いしているひともいるらしい

<b>扶養家族【ふよう・かぞく】</b>
浪人は不要家族という。

<b>ペーパーレス【ぺーぱーれす】</b>
発信人が全員分のコピーをして配布するのが面倒なので、電子的に全員に配布したあと、各自にプリントさせる手法のこと

<b>ボーナス【ぼーなす】</b>
(1)一年に２度、まとまった金を渡して、消費人口代表のサラリーマン達に少しでも大きな買い物をさせようとする風習。 (2)ステージをクリアすると、色々な条件に従ってもらえる特別な点数のこと。 (3)普段の給料を押さえ目にして、ボーナスに頼らなければ生活できないようにし、会社への依存度を高めさせようという人事上の戦術。

<b>本社ビル建設計画【ほんしゃ･びる･けんせつ･けいかく】</b>
事業計画を発表するに際して、たいして将来性のあるプランを思いつかなかったときに抜く伝家の宝刀。本社ビルは往々にして「昔は良かった」ことを示す思い出の記念碑になりやすいらしい。

<h3 class="title">悪魔の辞典（ま行）</h3><br />
<br />

<b>マイクロソフト【まいくろそふと】</b>
(1)ちっちゃなソフトウェアのこと (2)コンピュータ関連のベンチャー企業として成功するには、決してオリジナル製品を作ってはいけない。ネットワーク上に転がっている他人のアイデアを頂戴するか、アイデアごと会社を買収するかのどちらかである…ということを身を持って証明した偉大な会社《反対語》ネットスケープ、ロータス・デベロップメント

<b>マイル【まいる】</b>
(1)武士が果たし合いのとき、自分と相手の距離を互いに言うのに利用する単位のこと (2)困った出来事の長さを表す単位のこと (3)降参した敵を数える単位のこと

<b>マクロ経済学【まくろ･けいざいがく】</b>
ツナの取れ高について体系化された経済学のこと

<b>ミスマッチ【みすまっち】</b>
メスのマッチ。火がつくと激しい。

<b>無敵【むてき】</b>
お金持ちで、頭がよく、スポーツ万能の上に精神力も強く、強大な権力を持っているのに腰の低い人物のこと

<b>村八分【むら･はちぶ】</b>
(1) 村から８分で行くことの出来る近郊地域のこと (2)元には、葬式と火事を除いて相手にされないことを指した。村の中でこの二つ（＝二分）は、本人だけの問題ではないからである。しかし現在、子供のイジメは日常茶飯事、冠婚葬祭はボイコットすることを公言する輩も多く、火事にいたっては、近所中がやじ馬になるケースすらある。現代は、この二分に相当するものを見つけるのが難しいため、村十分というのが正しいかもしれない。

<b>無料送迎【むりょう･そうげい】</b>
お客側からのわがままによって発生した違法行為に限りなく近い利便性の名前。「白バス」「白タク」行為であり、安全性は考慮されていない。もちろん、万が一の事故に対する保証が全くないことには誰も触れない。

<b>目は口ほどにものを言う【め・は・くち・ほどに･ものを･いう】</b>
鬼太郎のオヤジ

<b>メンツ丸潰れ【めんつ･まるつぶれ】</b>
ドイツの高級車が交通事故でペシャンコになる様子

<b>名物料理【めいぶつ･りょうり】</b>
とても美味しいはずなのに、全国に広まらないという不思議な料理のこと

<b>桃太郎侍【ももたろう･ざむらい】</b>
ひとつ、人の世の生き血をすすり。ふたつ、不埒な悪業三昧。みっつ、三日月ハゲがある…。あれ？


]]>
        
    </content>
</entry>
<entry>
    <title>導入ステップ⑥＝最終ステップ～システムの運用</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20060323.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=110" title="導入ステップ⑥＝最終ステップ～システムの運用" />
    <id>tag:www.smartec.co.jp,2006:/support//3.110</id>
    
    <published>2006-03-28T15:00:01Z</published>
    <updated>2006-10-16T13:31:20Z</updated>
    
    <summary>コラム第２６回：導入ステップ⑥＝最終ステップ～システムの運用 2006.3.23...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２６回：導入ステップ⑥＝最終ステップ～システムの運用</h3><br />
<div class="date">2006.3.23</div><br />
<div class="date">長谷部泰幸</div><br />



ITシステム導入の6番目、最終ステップは、「システムの運用」です。システム導入の目的が達成されたかどうかは、この運用の結果で判断することになります。

運用は、それ以前の設計や開発と異なり、終わりのないステップであると言えます。期間も長く、関係者も多く、それだけにコストも膨らみがちです。自前で行うより、専門のアウトソーシング業者に委託するほうがはるかに効率的である場合もあります。

この「運用」において、利用者側として知っておくべきポイントは３つあります。それは「マニュアル」、「効果測定」、「利用教育」です。各々について解説します。

<b>最低限必要なマニュアル</b>

一般に、システム運用に必要なマニュアルは３種類あります。そのうちシステムベンダーから納品されるのが、「操作マニュアル」と「運用マニュアル」です。

「操作マニュアル」とは、実際に操作する時のオペレーションマニュアルで、「運用マニュアル」とは、システムを上手く活用するための注意書きにあたり、特例処理とトラブル復旧処理に関する記述があります。

３番目に必要なマニュアルが「業務マニュアル」で、これはシステムを活用していくための業務ルールにあたります。これはシステムベンダーからの納品はなく、自社で業務ごとに作成し、システムが稼働する前に用意しておくべきものです。また、このマニュアルは定期的な見直しが必要です。

<b>導入の効果を測定する</b>

システムをより効率的に運用していくために、また、システムを拡張し、より良いシステムにしていくため、システム導入の効果を測定する必要があります。

運用段階において、当初想定していた目的に対する貢献度を、具体的な数値などで評価します。システム設計段階での評価を事前評価、システム導入段階での評価を中間評価とするならば、運用段階での評価は事後評価にあたります。このように、「システムが導入できたらそれで良し」ではなく、導入の効果を測定し、次につなげていくＰＤＣＡサイクルの確立が最も重要になってきます。

そうした検討を行う機会（「業務マニュアル見直し会議」など）を設けていくことも利用者側の仕事です。

<b>利用教育体制</b>

どんなに良いシステムを導入しても、従業員がうまく使いこなせなければ意味がありません。そのためには、「業務マニュアル」の充実と、教育プログラムの考案が必要です。

また、ＩＴ化によって、今まで得られなかった新しい指標が簡単に得られるようになります。こういった指標は業務目標の設定等に役立ちますが、その指標をうまく使いこなす人材の育成も必要です。業務知識がなければ、こういった指標も使いこなせません。

このように、やはりＩＴシステムはツールであって、最終的には「人」であるといえるでしょう。人で始まり、人で終わるのがＩＴシステムの本来の姿なのです。

<b>「業務のＩＴ化」連載コラムは今回で完結</b>

コラム第10回を皮切りに、これまで15回の連載で業務のＩＴ化について連載コラムを書いてきました。予定通りの内容を網羅できたので、ここで一段落です。ホームページのアクセス数をカウントすると、このコラムのうち最も読まれているのは、「業務フロー図」に触れたもののようです。次いで「要件定義」がテーマのコラムとなっています。

今回の連載は、生産管理という業務を対象にしてみましたが、業務フロー図を作成したり、要件定義するという作業は、どんな会社のいかなる仕事にも有用な内容です。

変化の激しい環境の中で成長を続けるのが企業の宿命ですが、そうすると２～３年くらいで、どんな業務も属人化してきます。元々は定型業務だったのに、いつの間にか担当者が独自の方法論を駆使する非定型業務になってしまうケースは、どこの会社にも見られる現象です。それを放置することは、あらゆる面でのボトルネックの原因になりがちです。

こんなときに、業務フローや要件定義書で一度「業務の棚卸し」をやってみてはいかがでしょうか。業務の持つ付加価値を客観的に分解できるなど、解決のための色々なものが見えてくるでしょう。

スマーテックでは、ＩＴ化と直接関係なくても、こういった業務支援のサービスを実施しています。ご興味を持たれたらぜひ<a href="http://www.smartec.co.jp/company/contact/index.html">お問合せください</a>。]]>
        
    </content>
</entry>
<entry>
    <title>システム企画（導入ステップ⑤）～システムの導入</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20060224.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=109" title="システム企画（導入ステップ⑤）～システムの導入" />
    <id>tag:www.smartec.co.jp,2006:/support//3.109</id>
    
    <published>2006-02-23T15:00:01Z</published>
    <updated>2006-02-24T06:06:31Z</updated>
    
    <summary>コラム第２５回：導入ステップ⑤～システムの導入 2006.2.24 長谷部泰幸 ...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２５回：導入ステップ⑤～システムの導入</h3><br />
<div class="date">2006.2.24</div><br />
<div class="date">長谷部泰幸</div><br />


ITシステム導入の５番目のステップは、そのまま「システムの導入」です。設計段階が終わるとシステムベンダーは開発を実施します。開発が終わったら何の支障もなく動くのかというと現実はそうではありません。

一般的に、システムの導入時には、当初予定していなかった問題が発生するものです。実際運用を開始してから、うまく動かないといった事態になると業務に大きな支障を与えます。したがって、事前に様々な状況を想定したテストを行うべきです。

もちろん、システムベンダーの内部には、膨大な項目のチェックリストが存在しますが、それは提供側の観点での内容です。利用側としてチェックポイントとなる項目を５点解説しておきます。

<b>【１】業務の流れに沿った処理が出来ているか</b>

個別機能の確認ではなく、業務が出来る形に処理できているか、出力できているかどうかの確認を行うテストが必要です。

<b>【２】現行システムとの連携ができるか</b>

導入後も現行のシステムと連携させながら利用することを想定している場合、データのやりとりがスムーズに行えるかどうかのテストが必要です。

<b>【３】業務のピーク時でも安定して処理できるか</b>

通常の業務では安定して動いていても、業務のピーク時に、処理能力が足りなくなるようであれば問題です。いったいどのくらいの量の処理が出来るのかといったテストが必要です。

<b>【４】特例の処理が出来るか</b>

業務においては、イレギュラーなケースも発生します。そういった事態に対応するために、特例の処理が出来るかどうかといったテストが必要です。

<b>【５】移行期間を設ける</b>

事前に様々な事態を想定していても、システム導入時にはトラブルがつきものです。新システムに移行する場合は、現行システムとの移行期間を置くことが大切です。]]>
        
    </content>
</entry>
<entry>
    <title>システム企画（導入ステップ④）～システムの設計</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20060119.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=98" title="システム企画（導入ステップ④）～システムの設計" />
    <id>tag:www.smartec.co.jp,2006:/support//3.98</id>
    
    <published>2006-01-18T15:00:01Z</published>
    <updated>2006-01-19T03:30:51Z</updated>
    
    <summary>コラム第２４回：導入ステップ④～システムの設計 2006.1.19 長谷部泰幸 ...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２４回：導入ステップ④～システムの設計</h3><br />
<div class="date">2006.1.19</div><br />
<div class="date">長谷部泰幸</div><br />


ITシステム導入の４番目のステップは「システムの設計」です。パートナーであるシステムベンダーを選定したら、そのベンダーとの協業体制をつくり、設計という作業を行います。

<b>設計にも種類がある</b>

システムベンダーにとっては、｢設計｣というと、大きく２つの設計局面があります。一般的に「概要設計（外部設計）」と「詳細設計（内部設計）」と呼ばれており、各々で作成される成果物（設計書類）や作業項目が異なります。
この２つの設計について、詳しく知っておく必要はありませんが、ポイントだけは基本知識として持っておくと良いでしょう。

<b>概要設計（外部設計）</b>

ひとことで言えば、利用者の立場からITシステム全体を定義する設計のことです。要件定義書に記載されたシステムを実現するために最初に行う作業となります。
ここで決められる主な内容は、システムの機能、業務フロー、画面、帳票、ファイルなどの論理設計などです。

<b>詳細設計（内部設計）</b>

こちらの設計は、ITシステムの立場からシステムの内部構造を定義します。
プログラムの構造を決めたり、ファイルの物理設計を行ったりしたうえで、システムの性能や容量などの再検討も行います。

<b>利用者としての関わり方</b>

要件定義書でどのような目的を達成するためのシステムである、という大枠は決まっていますが、設計には利用現場からの具体的な要望も盛り込んでいかなくてはなりません。利用者としては、システムが本当に実態にあっているかを判断する必要があります。
システムの機能は、「①入力」→「②処理」→「③出力」に単純化できます。利用現場がチェックするのは、必要な情報が必要な形で「③出力」できるか、間違いなく「①入力」できて処理されるか、といった「①入力」、「③出力」に関する部分です。特に「③出力」に関してのチェックは必要です。また、こうした要望を盛り込んで、設計を始める前にレビューを行うことが必要です。これは、システムのできあがりイメージを共有するためにも必要です。

<b>設計段階でのチェックポイント</b>

設計段階では、出力・入力がきちんと行えるかをチェックすることが大切です。特に出力に関するチェックは大切で、システム構築後に必要なデータが出力されないといった事態を避けましょう。主なチェックポイントを以下にまとめておきます。

<b>【出力に関するチェックポイント】</b>

□業務に必要な情報が必要な形で出力出来るか
□既存システムとスムーズなデータ受け渡しが出来る形で出力できるか

<b>【入力に関するチェックポイント】</b>

□人的ミスを少なくする工夫が盛り込まれているか
□機能より操作性を重視しているか

<b>【その他のチェックポイント】</b>

□処理のピーク時でもシステムが十分対応できるか
□クラッシュ時のリスク回避する機能があるか
□システムの自動化は変更の余地を残しているか
□機種選定基準は将来性も考慮されているか
□設計前のレビューは行ったか]]>
        
    </content>
</entry>
<entry>
    <title>システム企画（導入ステップ③）～パートナーの決定</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20051121.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=96" title="システム企画（導入ステップ③）～パートナーの決定" />
    <id>tag:www.smartec.co.jp,2005:/support//3.96</id>
    
    <published>2005-11-20T15:00:01Z</published>
    <updated>2006-01-19T03:31:54Z</updated>
    
    <summary>コラム第２３回：導入ステップ③～パートナーの決定 2005.11.21 長谷部泰...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２３回：導入ステップ③～パートナーの決定</h3><br />
<div class="date">2005.11.21</div><br />
<div class="date">長谷部泰幸</div><br />


ITシステム導入の３番目のステップは「パートナーの決定」です。要件定義書を作成したら、今度はパートナーであるシステムベンダーの選定を行います。このステップは４つに分けて解説します。

<b>【１】事前に絞り込む</b>

システムベンダーとは、システム導入後も、システムの保守管理等で長くつきあっていく必要があります。したがって、最適なシステムベンダーをパートナーとして選定することは、大きな要素の一つと言えるでしょう。しかし、多くのシステムベンダーからの提案を聞いても、同じように判断するのはなかなか困難です。
そこで、システムベンダーに提案を求める前に、ある程度の選定を行う必要があります。同業他社での評判やインターネットでの情報、システム導入に詳しい人、雑誌、パンフレット等の情報をもとに、どんな業者に提案して貰うのかを事前に絞り込みましょう。一般的には３～５社程度に絞り込んでから、提案を求めることが良いようです。

<b>【２】ベンダーへの説明を実施</b>

システムベンダーに対し、先に作成した要件定義書をもとに説明を行います。システムベンダーに対し１社１社説明する場合も多くあるようですが、説明会のような形で同時に説明するやり方もあります。
各社が顔を揃えて、各社の観点での質問や回答を共有するという意味で、説明会の開催は関係者に多くのメリットがあります。

<b>【３】見積や提案価格を取得</b>

システムの評価は、投資対効果で決まります。その投資対効果を検討する上でも、見積の取り方には注意が必要です。複数のシステムベンダーに見積を依頼すると、各社のフォームで提示され判断が難しくなります。
ある程度の項目を決めた共通フォーマットを作成し、システムベンダーに記入して貰います。これにより、複数のシステムベンダーを横並びに評価することが出来ます。見積は、ハード費やシステム開発費、ネットワーク構築費、教育研修費などのイニシャルコストだけでなく、保守管理費、バージョンアップ費などのランニングコストについても提出してもらう必要があります。

<b>【４】提案内容からパートナーを選定</b>

見積の提出と同時に各社からの提案を受けます。各社を評価するための様々な項目が考えられますが、最低、以下のような評価軸は考慮する必要があります。

　・　求めているシステムコンセプトや導入目的の理解度
　・　システムの構成（信頼性、効率性、安全性など）
　・　運用保守体制とサービス評価
　・　開発に要する期間
　・　瑕疵担保期間
　・　担当者の評価
　・　システム構築の費用

　選定に際しては、何を重視するかという基準をある程度決めておいたほうが良いでしょう。提案価格だけで決める場合もあるでしょうし、少し高いけれども、要件定義時に気付かなかったことを提案してくれたベンダーを採用する場合もあるでしょう。

<b>提案内容で分かる信頼度</b>

パートナーとして信頼できるシステムベンダーかどうかは、提案内容や見積でわかる場合もあります。次のようなことに注意して、提案や見積をチェックしてみましょう。

　①　見積りの中に不要なものは入っていないか
　②　性能過剰になっていないか
　③　どういった場合に追加費用が発生するのか
　④　ハードウェアの費用が相場からかけ離れていないか

また、提案の中に少し将来の夢を描いてくれるベンダーもいます。ある程度の想定で、投資対効果を算定してくれるベンダーもいます。システムベンダーとは今後長いおつきあいをしていくパートナーです。信頼できるパートナー選びには細心の注意を払いましょう。]]>
        
    </content>
</entry>
<entry>
    <title>システム企画（導入ステップ②）～要件定義書作成</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20051006.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=94" title="システム企画（導入ステップ②）～要件定義書作成" />
    <id>tag:www.smartec.co.jp,2005:/support//3.94</id>
    
    <published>2005-10-05T15:00:01Z</published>
    <updated>2006-01-19T03:36:19Z</updated>
    
    <summary>コラム第２２回：導入ステップ②～要件定義書作成 2005.10.6 長谷部泰幸 ...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２２回：導入ステップ②～要件定義書作成</h3><br />
<div class="date">2005.10.6</div><br />
<div class="date">長谷部泰幸</div><br />


ITシステム導入の2番目は「要件定義書の作成」です。自社で開発する場合でも、外部のシステムベンダーに依頼する場合でも、この手の書類を作成します。

<b>要件定義書とＲＦＰ</b>

システムベンダーに、「どんなＩＴシステムが欲しいか」を示す書類は、「要件定義書」、「提案要望書」のように様々な呼び名があります。ここ最近は、ＲＦＰ(Request For Proposal)という呼び名が一般的に普及しつつあります。
このコラムでは、自社のシステムを自前で開発する『手作り派』も対象にしているため、要件定義書という呼称を利用していますが、内容の本質はどれも同じものです。

<b>記載すべき内容</b>

どういったシステムを望んでいるのかを明確に示すのが要件定義書です。ここでは、外部システムベンダーに検討を依頼する場合の要件定義書に必要な記載事項をご紹介します。

①会社概要
会社の概要を記載します。記載する内容は、主要取扱製品、主要取引先、売上高、従業員数、本社・支店・営業所・工場などの所在地、社内組織などです。

②システム導入の目的
システム導入の狙いは何か、どういった事につなげたいのかを明確に示します。この部分が明確になっていないと、システムを導入すること自体が目的になりかねません。

③要件定義内容
システム導入の目的を達成するため、システムにどのような機能を必要としているのかを明示します。欲しい機能を記述するほか、業務フローの中でどう活かしていくのかも検討します。

④現行システムの説明
既にシステムを導入している場合は、それはどのようなシステムなのか、どの部署がどのように利用しているのかなどの概要を記載します。現行システムの説明資料も準備することも必要です。また、旧来のシステムは、導入するシステムと置き換えるのか、それとも連携して利用していくのかも明示します。

⑤データ量調査
実際に取り扱う予定のデータ量を見積もり、処理する能力がどの程度必要なのかを記述します。各種マスター類の内容と処理数のほか、処理される伝票の枚数は、どの時期にどのくらいの量があるかを明示します。

⑥希望スケジュール
いつ稼働を開始させたいかを明示します。また、どういった段階を踏んで導入したいかも示します。]]>
        
    </content>
</entry>
<entry>
    <title>システム企画（導入ステップ①）～システム企画</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20050910.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=93" title="システム企画（導入ステップ①）～システム企画" />
    <id>tag:www.smartec.co.jp,2005:/support//3.93</id>
    
    <published>2005-09-09T15:00:01Z</published>
    <updated>2006-01-19T03:36:32Z</updated>
    
    <summary>コラム第２１回：導入ステップ①～システム企画 2005.9.10 長谷部泰幸 I...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２１回：導入ステップ①～システム企画</h3><br />
<div class="date">2005.9.10</div><br />
<div class="date">長谷部泰幸</div><br />


ITシステム導入の最初は「システムの企画」です。このステップで何を行うかについて、７つの項目に分けて解説します。

<b>【１】目的の明確化</b>

ＩＴシステムの導入を検討する前に、もう一度「目的」を確認してください。ＩＴシステムを導入するのは社内の業務改善や設備運用効率化のためですか、それとも、納期の即時回答など、取引先との関係を構築するために必要なのですか。貴社の置かれている立場を、様々な視点で再検討してみましょう。そのためには全体業務の把握が大切です。

『システム導入でこれがしたい』。経営者は目的を明確に持ってください。

<b>【２】ＩＴシステム化範囲の明確化</b>

何がしたいのかが明確になれば、それを達成するために、業務のどの範囲に、どのようなシステムを導入するのかを検討します。

システム導入を行うかどうかは「戦略や目的に対する貢献度」で判断するしかあり得ません。どのようなシステムを導入することで、業務はどう改善されるのか、どう効率化するのか、どの程度貢献するのかを事前に検討します。

また、導入したい範囲の優先順位も合わせて考え、順次ステップアップしていく長期的なビジョンを持ち導入していく方法も考えられます。

<b>【３】導入体制の確立</b>

①経営者のリーダーシップ

システム導入後は、導入前に比べ業務の変化が伴います。社内では、システム導入にあわせ組織の変更などが必要な場合も出てくるかもしれません。当然、従業員からの反発も予想されます。

ＩＴシステムを導入し、業務改善を図っていくために、経営者に求められるものは強いリーダーシップです。従業員に対してきっちりと説明し、導入に協力してもらう雰囲気を作り上げる必要があります。経営者の指導力は、社内だけでなく社外にも影響します。ネットワークの普及によって、システムの導入は取引先企業にも影響を与えることがあるからです。

②システム導入担当者を設定する

また、システム導入に関して、経営者の片腕となり、実際の作業を指揮するシステム導入担当者（担当チーム）が必要となります。

ここで注意しなくてはいけない事は、システム導入担当者が現場から孤立しないように配慮する必要があります。システム導入担当者が現場から孤立してしまうと、現場のニーズにあったシステム構築が出来ず、システム構築が「絵に描いた餅」に終わってしまうからです。現場の知識や要望の吸い上げをスムーズに行うためにも、システム導入担当者と現場との友好な関係構築を、経営者は意識しておくべきです。

<b>【４】ＩＴシステム導入手順の候補選択</b>

ＩＴシステム導入の評価は、投資対効果、すなわち「目的達成に対する貢献度」と「かかった費用」との兼ね合いで決まります。ＩＴシステムをどんな手段で導入するかを検討しましょう。

ＩＴシステムの導入方法としては、過去のコラムのように①市販パッケージソフトの購入、②ＡＳＰでの導入、③オーダーメード専用システムの構築、④一般向け汎用アプリケーションの利用などが考えられます。自社の業務形態や従業員のＩＴレベルなどを考慮して、どのシステムをどのように導入していくのか、どのように連携をとるのかを検討しましょう。

<b>【５】信頼性や安定性の方針決定</b>

ＩＴシステム検討の際、機能面や性能面ばかりに注目しがちですが、壊れた場合や稼動が停止した場合のことも考える必要があります。最悪の事態として、蓄積してきた重要なデータが失われる可能性もあります。そのような事態に対処するため、データのバックアップ方法や復旧方法の検討が必要です。

信頼性や安定性にどの程度のレベルを求めるか。このイメージがないとまったく検討できません。
システムベンダーに保守管理をお願いする場合は、一般的にバックアップシステムは充実しています。しかし、対応時間が限られていたり、費用がかかるという難点もあります。迅速な対応を行うためには、社内でもシステムの管理がある程度出来るシステム担当専任者を確保する必要があるかもしれません。

<b>【６】コード体系の統一</b>

取引先、部品、機械、従業員、工場、材料などのコードはシステム企画段階でどう統一するのか検討しましょう。独自で付与するのか、業界の標準やＥＤＩネットワーク標準を利用するのか、大まかにはこの２つが考えられます。

<b>【７】導入スケジュールの立案</b>

システム構築には、現場からの情報収集とその結果のフィードバックが必要です。システムを導入するために、どの段階で、そういった意見を吸い上げ反映させていくのか、どういったテストで信頼性を高めるのかなど、スケジュールを具体的なフローに落としていきます。

スケジュールが明確で、しかも現場の従業員がそのスケジュールを理解していることがスムーズなＩＴ導入には不可欠です。]]>
        
    </content>
</entry>
<entry>
    <title>ＩＴシステム導入ステップ</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20050818.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=92" title="ＩＴシステム導入ステップ" />
    <id>tag:www.smartec.co.jp,2005:/support//3.92</id>
    
    <published>2005-08-17T15:00:01Z</published>
    <updated>2006-01-19T03:36:41Z</updated>
    
    <summary>コラム第２０回：ITシステム導入ステップ 2005.8.18 長谷部泰幸 ここか...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第２０回：ITシステム導入ステップ</h3><br />
<div class="date">2005.8.18</div><br />
<div class="date">長谷部泰幸</div><br />


ここからのコラムは、実際にITシステムを導入する場合のステップについて記述します。今回は全体像を示し、次回以降で各ステップの内容と重要なポイントに触れます。

<b>ITシステム導入手順の全体像</b>

ITシステムの導入はどのようなステップで進めていけばよいのでしょうか。

安価なパソコンソフトを買うなど、今すぐに取り組めるレベルのIT化は、何度でも試すことができます。しかし、本格業務のサポートを目的に、ある程度の投資を行う場合は、手痛い失敗を避けるためにも、段階を踏んだ検討が必要です。標準的には、以下のようなステップでシステムを構築していきます。

①システムの企画
システム導入の目的・手段に対し、どのような体制で取り組むべきかを経営者が決定します。

②要件定義書の作成
企画内容を中心に、要件定義書を作成します。システムベンダーに説明する場合だけでなく、自社開発の場合にも作成したほうがベターです。

③パートナーの決定
パートナーとなるシステムベンダーを決定します。

④システムの設計
現場の意見を吸い上げながら仕様を固め、システムの設計を行います。

⑤システムの導入
様々なテストを行いながら、移行期間を置きながらシステム導入を図ります。

⑥システムの運用
マニュアルを作成し、システムの運用を行い、人材教育も併せて行います。

⑦導入効果のフィードバック
システム導入効果を測定し、業務改善につなげます。

こうした流れや考え方は、オーダーメードのシステムを導入する時だけでなく、ASPなどでシステムを導入する際や市販ソフトの選定にも応用することが出来ます。もちろん、自社開発を志す場合も同様です。

<b>経営者が決定・決断を</b>

システムを導入して何をしたいのか、どの業務を効率化したいのか、システムの大枠を決め、導入を決断するのは経営者です。
同時に、システム導入は、現場での業務の進め方が変わるため、従業員のコンセンサス形成が重要です。したがって、トップダウン型かボトムアップ型かという選択ではなく、業務知識（現場の声等も）を十分に持った経営者が決断し、現場のニーズをくみ取りながら詳細を詰めていく流れが理想的です。

<b>ASPや市販ソフトウェアの場合のステップ</b>

ASPでITシステム導入を図る場合でも、まったく同じような考え方でITシステム導入を進めます。
導入の流れで異なる点は、④システムの設計が不要であるかわりに、⑤システム導入にあたって、ASPや市販ソフトにあわせた業務の見直し、業務の再設計が必要なことです。業務にあわせてシステム化を図るか、既に出来上がっている業務システムにあわせて自社の業務を再設計するかという違いです。

ASPや市販ソフトウェアで実現されている業務と、自社業務の違いを知るために、「フィット・ギャップ分析」と呼ばれる方法を用いて、相違点を明確にします。特にパッケージ・システムを導入する際に、この分析結果を使うと、システムベンダーへ何を要望すべきなのかが明らかになります。]]>
        
    </content>
</entry>
<entry>
    <title>経費をかけず投資効果の高いＩＴ化</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20050805.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=91" title="経費をかけず投資効果の高いＩＴ化" />
    <id>tag:www.smartec.co.jp,2005:/support//3.91</id>
    
    <published>2005-08-04T15:00:01Z</published>
    <updated>2006-01-19T03:36:51Z</updated>
    
    <summary>コラム第１９回：経費をかけず投資効果の高いIT化 2005.8.5 長谷部泰幸 ...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第１９回：経費をかけず投資効果の高いIT化</h3><br />
<div class="date">2005.8.5</div><br />
<div class="date">長谷部泰幸</div><br />


ITシステムの導入を考える場合、コスト面については、なかり幅広い選択と工夫の余地があるというお話をしました。ここでは、経費をかけないIT導入について少し掘り下げてみます。

<b>買うのではなくサービスとして借りる</b>

ASP（アプリケーション・サービス・プロバイダー）と呼ばれるサービスでは、インターネットを介してソフトウェアを借りて使うことが出来ます。ASPで提供されるのは、電子メール、営業支援、会計・給与・販売管理、マーケティングソフトなど多岐にわたっています。最近では、生産管理システムや在庫管理システムなど、特定業種向けのサービスも登場しています。利用者は、必要なソフトの利用を申し込み、それに応じた利用料を支払います。月額3～5万円の基本利用料と、必要なオプション料金の組合せという形式が一般的です。

<b>メリットとデメリット</b>

①ASPのメリット
ASPを利用することで、初期費用を大幅に抑制することが出来るほか、サーバーのメンテナンス、バージョンアップに対する費用がかかりません。ITシステムが陳腐化する速度は早いですし、セキュリティ対策に係る技術開発も日進月歩で進んでいます。ASPはバージョンアップや、セキュリティ対策も包括的にサービスしてくれるので、このような不安は解消される点はメリットです。ITに関する専門的な業務をアウトソーシングすることができます。

ADSLのように、安価で通信速度の高いインフラが提供されているため、どのような規模の企業でも比較的取り組みやすい方法と考えられます。

②ASPのデメリット
一方、ASPは、自由にカスタマイズすることが出来ないため、自社の業務に合わない場合もあります。また、既に社内システムを持っている場合、システム間連携がとりにくい場合もあるといった問題もあります。

<b>３次元CADですら借りることができる</b>

ASPの仕組みとは少々異なりますが、あの高価が３次元CADですらサービスとして借りることができるようになりました。日本ユニシス・エクセリューションズが平成17年7月から開始した「<a href="http://www.excel.co.jp/cadmeister/index.shtml">CADMEISTER</a>」という新サービスです。

必要なときに必要なだけ3次元CADを使えるよう、1時間200円～という従量課金でのサービス提供を行っています。少し前ならワンセット数千万円だった3次元CADも、いよいよ新しい時代に突入したというわけです。

<b>市販ソフトの活用＋スマーテックのテンプレート</b>

経費をかけず、生産業務IT化にすぐに取り組む方法として、表計算ソフトやデータベースソフトなどの、一般向けの汎用アプリケーションを利用することが考えられます。こうした汎用アプリケーションは、比較的低価格であるうえ、扱いやすいため、比較的取り組みやすいです。しかし、扱えるデータの量が限られているほか、複雑な作業を行う場合や、大量のデータを扱う必要がある場合、複数のユーザーで利用する場合のシステムの安定性・整合性には課題があります。

また、自分でシステムを構築していく必要があり、その人件費を考えると、決して安価な方法とはいえません。

このあたりの問題を解決するのが、スマーテックの生産管理、工程管理製品です。表計算ソフトで生産に関するマスターデータを管理することを前提とし、表計算ソフトが苦手な「トランザクション管理」の部分を、業務テンプレートとして提供するように企画開発したものです。無償で入手できるデータベース管理システムを活用しており、表計算ソフトの手軽さとデータベースの安定性の両方の長所を生かすように開発しました。

テンプレートとしているのは、自由にカスタマイズしていただく環境を提供するのが目的です。ASPのデメリットである「カスタマイズできない」という部分がご不満のユーザーにぜひご検討いただきたい製品です。

<b>IT活用のカギは人間</b>

ITシステムを導入することで、何でも達成できるような錯覚に陥る方も少なくありません。しかし、パソコン自身が入力してくれたり、判断してくれたりはしません。迅速で正確な処理を行うためには、正確な入力ができる人が必要です。また、新しく得られた指標を活用するには、その指標を正しく理解し、次の展開や目標を的確に定める事が出来る人が必要なのです。

<b>必要なのは業務知識</b>

何度も述べているように、ITシステムの導入は手段であって目的ではないので、システムの導入が業務の改善や効率化につながらないと意味がありません。業務の上でどこがネックになっているのか、どこが非効率なのかを知らないと適切なシステムは導入できません。IT化というと難しく聞こえ、専門知識を持っていないと適切に判断できないと思っている経営者は少なくありませんが、IT化の成功のために、経営者が備えておくべき知識は、IT知識ではなく業務知識なのです。

システム導入のためのIT知識は、スマーテックが実施している要件定義のご支援サービスの活用や、システム担当窓口を設置するなど、工夫次第で極めて投資効果の高い対応することが可能です。]]>
        
    </content>
</entry>
<entry>
    <title>システム開発とは</title>
    <link rel="alternate" type="text/html" href="http://www.smartec.co.jp/support/column/20050711.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.smartec.co.jp/cgi-bin/mt32/mt-atom.cgi/weblog/blog_id=3/entry_id=89" title="システム開発とは" />
    <id>tag:www.smartec.co.jp,2005:/support//3.89</id>
    
    <published>2005-07-10T15:00:01Z</published>
    <updated>2006-01-19T03:38:57Z</updated>
    
    <summary>コラム第１８回：システム開発とは 2005.7.11 金田忠士 　最近、悪質リフ...</summary>
    <author>
        <name>smartechp</name>
        <uri>www.smartec.co.jp</uri>
    </author>
            <category term="column" />
    
    <content type="html" xml:lang="ja" xml:base="http://www.smartec.co.jp/support/">
        <![CDATA[<h3 class="title">コラム第１８回：システム開発とは</h3><br />
<div class="date">2005.7.11</div><br />
<div class="date">金田忠士</div><br />


　最近、悪質リフォームによる詐欺事件が毎日のように紙面を賑わせています。専門的な判断基準を持たない一般の人々、特にお年寄りにターゲットを絞り、住む家が危険にさらされているという脅し文句で煽り、不当な価格設定で契約を結ばせるという悪質なものだそうです。

　さて、私見ですが本件のポイントは下記の4点にあると考えています。つまり、

　(1)契約締結に至る判断基準が専門的。
　(2)納品物(つまり、リフォーム結果)が契約締結時に実物が存在しない。
　(3)返品が不可能。(かかってしまった工数は取り返しが効かない)
　(4)価格設定の妥当性が一般人には判断が困難である。

　このように、一般人が妥当性その他に関して判断が困難な例は住宅に関することだけではありません。例えば弁護士に相談する場合、あるいは医者にかかる、手術の承諾書にサインをするといった場面においても一般人にその内容の妥当性を正確に判断できるわけではなく、その専門家を信用する以外に手はないのが現実です。

　同じことはそのままシステム開発にも言えると思います。システム発注側、つまりユーザはシステム開発に関する専門知識を持たず、契約の時点で完成品を目にすることもできず、納品物のクオリティが気に入らないからと契約を破棄することも難しい(そもそも一目見てシステムのクオリティを判断できるかどうかも怪しい)、さらにその価格を類似システムと比較することもできず妥当性を判断するための情報も入手が困難、ということです。

　一般に、大規模(に限った話ではありませんが)システム開発では、プロジェクトがスタートする時点でプロジェクトのゴールを明確にイメージできているものは一人もいない、と言われています。もちろん、システムを開発するにあたっての目的や大まかなゴールは設定されてはいるようですが、例えばコスト削減であったり、新しいサービスの導入であったり、それはあくまでも抽象的なお題目のようなものでしかなく、具体的なシステムの全貌としてはイメージできているものはいません。したがって、システム開発のプロジェクトが開始されるとまず何をするかというと、発注側と受注側とで意識あわせを行いつつ、技術的な実現可能性や、開発費、開発期間等限られたリソースの中で試行錯誤と妥協を繰り返していく中で、発注側の抽象的なイメージを実際に機能するシステムとして具体化していく作業を行うことになります。いわゆる分析、設計と言われるフェーズです。これこそがシステム開発の本質と言えます。

　ここで重要となるのが、発注側と受注側とでゴールとなるシステムの具体的なイメージがお互いに共有できるか否かです。発注側はシステム化の対象となる業務分野の専門家として、そして受注側はシステム開発の専門家としてお互いの持つノウハウ、知識、経験をすり合わせ、コンピュータ上にシステムとして実装する部分と、人間(つまり、そのシステムを業務として利用する現場の担当者)が判断を下すことにしてシステム化を行わない部分を明確にし、その境界線を決定します。

　この境界線を決めていく過程では、システム開発者、つまり受注側の姿勢として、如何に発注側の求めているものを引き出すことができるか、がポイントとなりますが、一般に発注側の担当者はシステム開発に慣れているわけではなく、受注側が得たいと思っている情報をが得られることはまれですし、本来、発注者が本当に望んでいることと全く異なることを求めていることも多々あります。ここでシステム開発側にはもっとこちらの意図を汲んでくれと言いたいところではありますが、なかなか思うようにいかないのが現実だと思います。

　そこで是非とも検討していただきたいのが、第三者なのです。つまり、システム開発の専門家でありながら発注側と開発側との間に立ち、発注側の要望を可能な限り汲み取り、開発側にそれを伝えることを使命とする役割を導入するのです。TV番組「大改造!!劇的ビフォーアフター」という番組で出てくる「匠(たくみ)」という存在。システム開発の世界には建築士に相当するような公的資格は存在しませんが、あの「匠」という存在に少しでも近づきたいと考えているのです。]]>
        
    </content>
</entry>

</feed> 

