このようなものをクラウド・コンピューティングとは言わないのではないかと思います。私はクラウド化の条件は次の要件が満たされていることだと考えております。

１．クライアントにはブラウザもしくはシンクライアントを利用する（クライアントに業務ソフトを導入しない）

１．カスタマイズを実施した場合にもアプリケーション・サーバは肥大化しない（ユーザ固有のプログラムをアプリケーション・サーバに載せない）

１．ユーザ固有情報はデータベースに格納される（ユーザ毎にデータベースを個別に持つのではなく同一データベース上に複数の会社のデータを格納する）この場合、カスタマイズ情報もデータとしてデータベース・サーバに格納される

１．ユーザ自身が業務システムの改修が可能なようにカスタマイズ手法を公開する

上記の内容が揃って初めて、「クラウド化した」といえると考えます。

現在、オーストラリアのＲａｙｔｅｃｈｎｅｔ社（http://raytechnet.net）が開発したABBR（application builder binary resource）が一番簡単で確実なクラウド化のフレームワークだといえます。

ABBRはデータ定義から画面作成、サーバロジックの作成、データ照会、データ入出力（CSV）をすべてパラメータで行うことができ、ABBRを使うことでカスタマイズ情報をデータとしてデータベースに格納することが可能です。また、過去の資産であるクラスを画面作成ツールから呼ぶこともできますので、今までのノウハウやユーザに公開したくないプログラム内容も同時に利用することができます。

このことにより業務用パッケージソフトを販売している会社がすぐにでもクラウド化を実現することができます。画面作成ツールはコントロールを画面に置き、プロパティを記述するだけです。コンパイルせずその情報をデータとして格納し、実行時に翻訳して利用します。サーバロジックも同じように条件分岐や処理内容を記述するだけです。コンパイルは一切せず、処理ロジックをデータとして格納し、実行時に翻訳しながらデータ処理を行います。

このことによりカスタマイズをすべてデータすることによりアプリケーション・サーバの肥大化を防ぐことができます。クラウド・コンピューティングを実施するうえでアプリケーション・サーバの保守管理は大きな負担になりますが、ＡＢＢＲを利用することでアプリケーション・サーバの保守負担を軽減します。

興味をお持ちの方は一度、Ｒａｙｔｅｃｈｎｅｔ社のホームページを覗いてみてはいかがでしょうか！！ＡＢＢＲの説明が日本語で載っています。

クラウドという言葉が新聞紙面を賑わせている割にクラウド商品の数は多くありません。ＡＳＰ、ＳａａＳ、クラウドとさまざまな言い方がされてきましたがここで一度、クラウド・コンピューティングにおける商品としての条件について考えてみたいと思います。

まず、最初に定義しなければならないのはユーザがユーザ自身のパソコンからインターネット経由で業務アプリケーションに接続し、業務を行うということです。この場合、登録されたデータはクラウド上のサーバに保存されるということになります。

この定義だけでクラウド用業務ソフトといっていいのでしょうか？私はこの定義は大前提であり、必要十分条件ではないと考えています。クラウド用業務ソフトが持っていなければならない機能は「システム運用するためのカスタマイズをユーザ自身でできること」ではないかと考えています。そのためにはプログラムをコンパイルすることなく利用できることが重要な点ではないかと思います。パッケージソフト時代によく使われた言い方をすれば「パラメータ」を変更することでカスタマイズ可能なものにするということになります。ここで言う「パラメータ」の役割は以下の６点になります。

画面レイアウトが自由に変更できること（項目の追加、削除、初期値設定）

サーバロジックが変更できること（ＤＢの更新やデータ取得）

ＤＢのカスタマイズ領域を利用して、ユーザ固有な情報を追加できること（画面、サーバロジックとも）

照会画面が簡単な設定で自動的に作成されること（ＣＳＶ出力が可能なこと）

ローカルシステムとのインターフェースが簡単に設定できること（クラウドからローカル、ローカルからクラウド双方向可能なこと）

帳票設計を行うことで自由に管理資料や伝票が作成できること

これはプロフェッショナル・ボランティア（一般企業ではシステム部門担当者やシステムに精通した業務担当者）が自社のシステムをクラウド・コンピュータ形式においてもシステムの維持管理を保証することを言います。自社システムからクラウド・コンピューティングに移行するためには、この保証は最低限行われなければならないものだと考えています。

この基準に照らして、そのような機能を有しているクラウド用フレームワークは「ＡＢＢＲ（アバー）」（ＡｐｐｌｉｃａｔｉｏｎＢｕｉｌｄｅｒＢｉｎａｒｙＲｅｓｏｕｒｃｅ））と呼ばれる製品だけです。ＡＢＢＲとは「短縮する」を表す言葉で、ここでは「開発時間を短縮する」ことを目的として作成されたものを意味します。

次回はこのＡＢＢＲについて詳細に報告したいと思います。

クラウドからクラウド２へ 

「クラウド・コンピューティング」と言う言葉が一般的になって久しい今日、「コンピューティング」を略して「クラウド」と呼ぶのが一般的になってきました。そして今「クラウド２」と言う新しい概念が広まりはじめています。

「クラウド２」は「クラウド」に対するアンチテーゼに対する新テーゼとして現れた概念です。「クラウド」に対するアンチテーゼとしてもっと顕著なものは「クラウドは一元的な機能を提供しているだけで統合化された業務システムを提供できない」というものです。

この指摘は「クラウド」が「ソフトウェアを所有から利用へ」、「利用可能なソフトウェアはインターネット上に存在する」と定義し、ソフトウェアをインターネット上に置き、利用者に「必要な時に必要なだけ利用してもらう」サービスと定義したことに起因したものです。「クラウド」は元々、業務全体をサポートすることを目的にしてきませんでした。これは「クラウド･コンピューティング」の所期の解釈の間違いから始まったことだと考えられます。

「クラウド」には２つの異なったスペルと意味があります。「Cloud（雲）」「Crowd（群集）」。

クラウド･コンピューティングの初期にはアイロニカルにこの２つの意味を説明していましたが、いつの間にか「Cloud（雲）」＝インターネットという考え方だけが普及してしまいました。「クラウド２」とはその忘れ去られた「Crowd（群集）」を復活するものです。

クラウド･コンピューティングの最も有名な例としてしばしば、例にあがるのが「リナックス」です。リナックスはオープンソースでプロフェッショナル・ボランティアが参加して完成してゆく手法で出来上がったものです。「クラウド」から「クラウド２」への進化はどの様なものになるのでしょうか？この答えはユーザ自らが修正可能な（もしくは新規に機能を追加可能な）システムの提供と言うことになります。

一般的に「カスタマイズ可能なSaaS」という言い方がされていますが、私が言う「クラウド２」はこれとも異なります。ユーザ自らがカスタマイズするとは従来のカスタマイズとは異なり、コンパイル・フリーな環境を提供し、ユーザ自らがシステムを積極的に修正することを許す仕組みのことです。業務システムは業務を利用するユーザが一番正しく理解し、業務改善の主人公であるという当たり前な視点に戻るということです。分業化したシステム管理の一部をユーザ自身に戻すことが「クラウド２」の目的だと言ってしまっても過言ではないかもしれません。

　どの産業よりも、グローバル分業が進んでいる製造業において、ITの活用も、クラウド2の概念を取り入れて、上手く分業化できるようなるといいのだが。

＜A＞
当社では約30年前から製作図面に、職人が必要と思う情報を自分で書き込んだものを全てTIF形式のイメージファイルとしてシステムに残しています。次工程の申し送りを書くという目的のもので、記録を残すという観点で始まったものではありません。そのため、現場は、負担を感じずスムーズに記録を残しています。
手書きとはいえ、なぜ、図面データを全製品、余すところなく残しているかというと、リピートオーダーが、全生産の9割を占めているからです。こだわりのものづくりに徹し職人を大切にするという一貫した活動のもとで、一方でITはツールとして徹底的に活用するという考え方が浸透しています。営業面では、「まかせなはれ！オーダーメイド」を入口とするバネポータルWebサイトで実績が上がっていますが、それに先駆けて設計/製造部門のIT化が世間よりも早くから進んでいました。95年頃、設計に携わるベテランが纏まって退職する時期で、危機感を感じました。当時は、案件がある度に本を調べたり、先輩技術者に聞いたりして図面を起こしていました。そこで、96年、設計技術熟練者のノウハウをシステム化したバネ設計支援システム（UNCLE）を構築し、プロセスシートからCADによる自動作図、製造指示書（強度計算、荷重計算など含む）の自動生成が極めて短時間で出来るようになりました。同時に、電子承認機能含む図面管理システムを同時に導入することで、結果として、出図リードタイムが、わずか１時間に短縮されました。 UNCLEつまり、「おじさん」という名前のこのシステムは、厳しい中にもやさしい職人の気持ちが表現されています。

設計というのは、放っておくと擦り合わせ設計になるものなのです。新しいモデルを設計すると製品専用の新部品が生まれ、新部品専用の製造設備や製造用の治具などが生まれます。次のモデルの開発の時に、また同じことを繰り返します。
これを古式設計と言います。この設計思想を逆転させる、すなわち限定された製造設備や治具を準備しておき、それから作られた少数のモジュラー部品を準備します。少数のモジュラー部品の組み合わせ方を変えることによって、変幻自在の多様なモデル設計をする状態を作ればいいのです。ただし、変幻自在の多様なモデル設計をするためには、事前に一括的な設計をする必要があります。これがすなわち、新式設計、製品アーキテクチャーの変革になるわけです。

21世紀は、地球環境保護が非常に重要なテーマになってきています。UNEP(国際連合環境計画)が有効なエコデザインとしてモジュラーデザインが必要だと言っています。ただ、このUNEPは概念、考え方は持っていますが、実践的な方法論は持っていません。確固とした方法論がまだ世の中にありませんでした。

スウェーデンのバス・トラック製造メーカーのスカニア社のケース

実際に新式設計としてのモジュラーデザインをしてきている会社があります。スウェーデンのバス・トラック製造メーカーのスカニア社です。
図-5のように、スカニア社は、多様な製品を作っています。
しかしながら、少数のモジュラーコンポーネントの組合せを変えるのみで、様々なバリエーションの製品を設計製造しています。「Meet widest possible demand with minimumnumber of components」とあります。これは、最小のコンポーネントで最大のお客様要求に対応するということを意味します。

フロントガラスは共通、バックミラー、ヘッドランプ共通、フロントグリルの一部は共通、エンジンはもちろん共通。こういう状態を1930年から追求して50年にはモジュラーデザインとして確立させているわけです。
デンマークにレゴブロックの会社、レゴ社がありますが、スカニアはこことモジュラーデザインの共同キャンペーンを張ったこともありました。つまり、スカニア社は自分たちの製品の究極の理想型は、レゴブロックだといっているのです。
日本には、極めて個別受注型のメーカーが沢山あります。バス、トラックは個別受注型の典型的な製品です。トラックに搭載するものは野菜や魚を搭載する冷凍車になるのかなど、積荷によってまちまちで、典型的な個別受注です。ところが、それに対してスカニアはこういっています。「わが社は顧客の要求は最大限に尊重するが、お客の要求に個別には対応しない。」個別対応しないまま、顧客要求に最大限対応できるよう、十分な事前設計を行った部品を準備しておき、部品の組合せを変えることによって、最大のお客様の個別の要求に応える、と言っています。いかに個別受注型と言っても、オールニューで対応する必要はありません。既存の仕様の製品に、ある機能のどこか一部を改良するなどで対応しています。よって、根本的な部品レベルで見ると、共通の部品が、多くあります。しかし、多くの企業では、共通にできうる部品やモジュラーを共通にしていません。末端部品まで非共通にしている、という実態があるのではないしょうか。

スカニアの経営成績は図-6の通りです。欧州トラックメーカーは、ダイムラー、ボルボ、パッカー、マン、スカニアとありますが、売上でみればスカニアは中堅メーカー。ところが、営業利益率で見ると何と13 ％ 。直近5 年間の経営成績を見てみると何と13％。直近5年間の経営成績を見て見ると、営業利益率（税引後）は、自動車大不況と言われた昨年でさえも営業利益率は14％、純利益は10％も稼ぎ出しています。これに対してスカニアの経営陣はこう言明しています。「わが社のモジュール設計は、わが社の高収益を保証している。」第一章(P-03)で解説したVコスト（ヴァラエティコスト）とCコスト（コントロールコスト）が非常に低い会社だといえます。一言で言えば、固定費が非常に低い優良企業なのです。
このような会社の設計者は、擦り合わせ業務の工数が少なくてすみます。したがって、機能設計、生産設計、皆、一人でやっている多能工が活躍しています。これも固定費を抑える要因です。

最近よく3次元化された映画やテレビなどが話題になっていますが、皆さんはもうご覧になられたでしょうか？縦・横の2軸である2次元から、奥行きという軸が加わった3次元化により、立体的に表現されることで伝わる情報量が飛躍的に上がり、見ている側もその臨場感に引き込まれることと思います。メディア（機械）を経由しての一方的な情報伝達ですが、曖昧な部分を可能な限り排除した情報伝達手段の一つといえます。

ビジネスの世界で情報伝達するシーンといえば、やはり検討結果を資料（文字）で見せながら、実際に説明（音声）するというプレゼンテーションでしょうか。前述したメディアでの情報伝達と比較すると、対象相手とリアルタイムに相互にコミュニケーションできることが異なる点といえますが、それでも考えがうまく伝わらずに四苦八苦することが往々にあります。環境や立場、価値観が異なる人に時間的制約がある中で、自分の思いをまっすぐに伝えることは非常に難しいものです。

情報伝達するためのコミュニケーションは、大きく「言語」による伝達と「非言語」による伝達の2種類あると言われていますが、ここでは「言語」による伝達として、書き言葉（文字）や話し言葉（音声）について考えてみたいと思います。

書き言葉（文字）による伝達
以前、こんなことがありました。
ある課題に対して、自分なりに検討した結果を案ベースで資料化を行い、レビューを受けた時のことです。私は上司に説明した後、最後に「それは案なのか。それだったら、資料に"案"と書け」と言われました。そこで初めて気づいたのですが、上司と私の間で認識のズレが発生していたのです。私は初めから案ベースで相談していたつもりが、上司から見ると、不確実なことがなく考え抜かれた結論の可否を問われていると思われていたのです。

同じ資料、同じ説明方法だとしたら、勿論、お客様とも同じ認識のズレが発生しますよね。こちらはまだ不明瞭な部分があることを認識していて、「ジャストアイデア」として一緒に議論することが目的であるにも関わらず、完成したものと認識される。その内容に抜け・漏れがあったり、論拠がなかったりすると、信頼を失うことにもなります。これはとても些細なことですが、大変重要なことです。

要はその資料の目的として、相手に何をしてほしいのか（決定するのか、一緒に検討するのか、検討をお願いするのか）、を明確にして資料中に表現することが重要です。

話し言葉（音声）による伝達
分かりやすい、伝わりやすい話し方とはなんでしょうね。相手が理解できる表現を使用する、相手の理解度を測りながら話すなど、考えると色々ありますが、私が最も意識していることは「接続詞」です。

「接続詞」は文と文の関係を表しており、それは論理そのものといえます。「順接」であれば、前の部分の内容から結果となる、「逆接」であれば、前の部分の内容とは逆の結果になるもの、などなど。

資料として完成した後、スピーチの準備を行うと思いますが、言うこと全てを原稿にまとめても、聞き手を見ながら説明する内容を変更したり、途中で質問を受けたりと、往々にして予定通りにはなりません。そもそも言いたいキーワードは資料に表現しているはずなので、それらがどういう関係であるか整理して、話す際はどの「接続詞」を用いるかを予め決めておくだけでいいはずです。その作業こそが論理を整理、又は形成しているといえます。

こうすることで聞いている人は、次に結果を言うのか、まとめ・要約を言うのか、これまでと全く逆のことを言うのか、それぞれの繋がりが分かるので理解しやすくなります。

「考える力」と「伝達する力」は両方必要
論理的思考を用いてお客様要件に合致した検討を行ったとしても、それを相手に正確に伝達できなければ、良い成果（＝評価）は生まれません。つまり、「考える力」と「伝達する力」という２つの力は、ある一定レベルで身に付けておくべきスキルであり、どちらか一方でも欠けてはいけないスキルです。いずれの力にせよ、論理的であることが必要だといえます。

＜A＞
当社は、95年、業界初のISO9002を認証取得しました。例えば、発電所の安全弁のバネについては40年保証、橋梁のバネについては100年保証を求められるのですが、品質の要は職人の思いとスキルにありま す。そのため、社内技能検定制度を導入し、常時、スキルとモチベーションの向上に取り組んでいます。

線バネ製造技能士と板バネ製造技能士とい国家資格があるのですが、国内の優良バネ製造技能士の約3分の１は当社の職人です。
また、一般的に、出世という概念は、主任～係長～課長とマネジメントに向いて設定されていますが、当社は技術職にも職能性制度があって、技師補～技師～主席技師～技師長という４つの段階を作り、給与・賞与にフィードバックしています。社員には、大卒もいれば高卒もいて、給与の出発点には差がありますが、定年退職時までその違いをひきずっていくのはおかしい。頑張ったら頑張っただけ評価する会社でありたいと思います。人と人を比べるのではなく、去年より今年どれだけ能力を伸ばしたかを評価し、伸び代を評価にフィードバックしています。当社は、中小企業ですから、いかに、人に育ってもらい、いかに大手に勝つか、「負けず嫌い魂」が成長を支えているのかもしれません。

日本の製造業・コンピュータ活用文化再考という表題で７回に渡ってアレコレ書いてきましたが、本日より、クラウドコンピューティングの製造業への活用について語っていきたいと思います。
日本の製造業は、海外拠点も含めた、全世界単位での、業務効率化、設備や部品の共通化を実現したダイナミックなコスト削減を恒常的に行えなければ、世界市場、特に強豪中国韓国のメーカー伍して戦えない状況だと言えます。一回一回、丁寧に、自社仕様にシステムを設計し導入していたのでは、新興国の旺盛な需要にスピードが追い付きません。こうやって考えて行くと、この時代、どうしても、クラウドコンピューティングの活用を検討せざるを得ない状況にあると考えます。私は、長年、生産管理システムの開発導入に従事してきましたが、工夫や英知をこらしたシステムを大事に囲いこむのではなく、クラウドの形でオープンに使えるようにし、国内外問わず多くの企業で業務効率化やコスト削減に活用してもらいたいと考えるようになりました。いわゆる事務作業のクラウド化ではなく、生産管理、物流管理、イーコマースなど、付加価値部分のアプリケーションをクラウドシステムとして提供できるよう、研究開発を進めています。これから暫く、クラウドコンピューティングをモノづくりに活用していく、意味意義や、最新事例などを考察していきたいと思います。

さて、まず最初に、クラウド・コンピューティングとは何ぞや？という点について、確認していきたいと思います。
企業のシステムは、サーバなどの大型コンピュータとデータベースやアプリケーションを各社それぞれ所有することで運用するのが一般的でした。しかし、2008年頃から出てきた「クラウド・コンピューティング」では、ハードやソフトウエアを自社で保有したり、ITベンダーから借りるのではなく、必要な機能、つまり美味しいところだけをインターネット経由で利用する業務システムの利用形態です。実際、クラウド活用して様々な企業がITコストの削減に成功しています。 似たような言葉として、ＡＳＰとかＳａａＳとか呼ばれることがありますが、新聞紙上ではこのところ「クラウド・コンピューティング」と言う言葉が定着してきているようです。

さて、この「クラウド・コンピューティング」も日本で受入れられるためにはいろいろなことを乗り越えて行かなければならないと感じています。 乗り越えるためには、そもそも「経営者自身がシステムを意思決定ツールとして利用する」ことに目覚めて頂く必要があると感じています。「クラウド・コンピューティング」とは、コンピュータ部門の自前主義とはまったく反対にある概念です。 独自のシステムを維持管理するためには、膨大な費用が発生します。また、システム部門が行わなければならない情報戦略的な仕事よりもシステムを維持することに主眼が置かれている企業を数多く見受けられます。
これは本末転倒と言わなければならないものです。
「クラウド・コンピューティング」を導入することでシステム部門は、システム維持管理から開放され、本来行うべき「情報戦略」について時間を割くことができます。また、その資質のないシステム要員を他の部門に配置転換することもできます。
新聞紙上で「自前システム構築するのと比べて、６、７割システム投資が削減される」と言われる理由はこのような無駄な費用をシステム部門から削減できるからでしょう。
また、ハードウェア及びその保守に膨大な費用を掛けていることも忘れてはいけません。
経営者自身がシステムを使うと言うこととシステム部門でシステムを作り続けることの違いをまずは理解しなければなりません。
システム部門の仕事は情報を迅速に整理し、タイムリーにユーザ部門に提供することです。 今まではそのためにシステム部門はプログラムを作り続けなければなりませんでした。 それが「クラウド・コンピューティング」を利用することでシステム部門の仕事は「情報の整理」や「ユーザ部門の要望収集」に変わります。
このことは情報戦略を構築するためのスピードアップと費用対効果をあげることになります。
そして、そのことを経営者主導で行うことに意味があります。

クラウドシステムの活用範囲の現状（2010年5月24日現在）

国内企業におけるクラウドシステムの活用を、既に報道されている情報からざっくり拾ってみました。
パナソニック、TOTO、富士ソフトABC、経済産業省、損保ジャパン、HOYA、広島県、リクルートといった企業が既にクラウドシステムを、業務アプリケーションとして導入もしくは導入プロジェクトとして進めています。活用用途の多くは、メール、スケジュール管理、顧客情報管理、といったいわゆる事務処理への活用が主流です。
唯一、パナソニックのファクトリーオートメーション（FA）の事業会社において、海外拠点との連携も考慮した工場の生産管理システムを、広島県では、電子申請サービスといった、企業は事業体の付加価値部分のアプリケーションのクラウド運用にチャレンジしています。
日本企業、特に製造業は、もの凄いスピードで増え続ける消費新興国の需要に、応じて行くために、かなりのスピードで、海外拠点を立ち上げていく必要に迫られています。海外拠点の機能は、生産、販売のみならず、一部の設計開発業務に至る、幅広い範囲を求められるようになりました。これまででは考えられないスピードで海外拠点を立ち上げ、現地でヒットする製品を次々投入していかなければ、中国韓国勢に負けてしまいます。そういう意味で、生産管理の機能まで含まれたクラウドシステムの活用は、製造業の海外複数拠点の立ち上げや、改善改革のスピードアップに効果を発揮し、製品競争力向上につながっていきそうです。また、システム導入工数の削減や、生産設備や部品の共通化にもつながり、大幅なコスト削減も実現可能です。

＜A＞
工数削減・品質向上のための徹底的な設計業務改善を目標とし、大きく二つの取り組みを行いました。一つ目は、「場所主体」から「モノ主体」管理にするために、一図面一設計図番に変えるという点です。
設置場所から図番を採番するのではなく、設計図番を定義し、図面には形状や加工に関する情報のみを記述しました。そして、設置場所に依存するモジュールや部品としての機能を表す情報は、工事番号・モジュール番号に関連付けられた手配番号で表現するというルール付けも行いました。
二つ目は、このような管理体系で、設計図番を図面管理コード（図面を特定するための一義的な番号）として定義し、表題欄＋部品欄の情報をベースにした属性・構成検索を可能にした図面管理/部品表システムを構築し、設計ＢＯＭと製造BOMの連携を進めていきました。

製品スペック情報一元管理の難しさは設計変更にあり

＜Q＞
図面管理/部品表システムを、設計変更対応や新機種立ち上げなどにも活用されていることと思いますが、これまでの業務プロセスが属人的だったため、運用に乗せるのは、かなり難しかったのではないでしょうか？

＜A＞
当社のようなエンジニアリング企業では、設計変更が非常に多く、変更時の運用ルールの明確化及び、変更を支援するための仕組み作りが非常に重要です。

Ａさん、Ｂさん、二人の設計者が、同時に、案件違いで類似仕様の製品を設計するようなケースを例にとります。まず、Ａさんが、担当案件固有のイレギュラーな変更があったため、設計変更をし、図面のリビジョン（以下Rev.）を上げます。同時に同一モジュールを使って類似仕様製品の設計をしているもう一方のＢさんは、設計開始時に参照した図面が最新のものと認識し、そのまま設計を進めていきます。この結果を後で見ると、同一モジュールを使った製品なのに、互換性のない設計変更による不具合が生じています。

このため、Ａさんが行ったような、使い回しが効かないような特殊な変更は、設計図番を必ず変える、つまり、互換性がない場合は、Rev.の更新ではなく新図番を取るルールを定義しました。今まで場所主体で書いていたので、他の設計者の都合は無関係に、各設計者が、自由にRev.を上げていました。そこを、Compassプロジェクトでは、"機能の変更時には、必ず図番を変える"、"互換性がある場合のみリビジョンを上げる"というルールの徹底を行いました。
図番の採番やＲｅv.更新業務を、スムーズに行ってもらうために、エクセルのマクロを使った簡易システムを用意しました。このシステムには、「流用」、「差替」といった設計変更に関する言葉の意味まで定義し、マクロのボタンを押して決められた処理手順に従うことで、自動的に図面の素が出来るよう工夫しました。

2009年度の決算を見ると、黒字回復している企業が増えた。

多くは、リストラによる人員削減、土地建物や設備の売却など、お荷物なものを探し、削っていく。
どちらかというと、後ろ向きなコスト削減である。そんな事を頑張った1年と言えるだろう。

しかし、2010年の各社の動向を見ていると、前向きなコスト改革に取り組む企業が増えたように思える。

◆設計段階でいかに製品コストをマネジメントするか？
◆設計と製造がいかに連携してコストダウンを行っていくか？
◆原価企画をより活動的に行うにはどのようにするか？

このように、製品のコスト構造を改革する 『原価企画』 や 『コストマネジメント』 を仕組み化する動きが出てきている。

筆者は、様々な企業にて、『コストマネジメント』 や 『原価企画』 の仕組みづくりに取り組んできた。
筆者のような外部のコンサルタントに依頼が来る時は、殆どの場合がその企業にて一度は取り組んだが上手くいかなかった。
もう自社だけの推進では上手くいかないので、外部の知識や知恵を借りようとなった場合だ。
平たく言えば、改革に一度は失敗した企業が、外部コンサルタントを活用するのである。

自社で仕組み改革を推進して成功していたら、我々のような外部コンサルタントにはお声が掛からない。当たり前の話である。

筆者が関わった企業様を良く分析すると、改革の失敗には共通点があった。
そこで、主な３つの点に絞って解説をしたい。
逆の言い方をすると、この３つに気をつければ、成功に近づくという事になる。

3回に分けて、解説をしていくので、是非改革推進のヒントにしてもらいたい。

原価 ＝ 精度 ？

成功に近づく（＝失敗しない）１つ目のポイントとして、　『精度を求めすぎない』　 ということである。どうしても、「コスト」「原価」という言葉を聞くと、ついつい精度良く、詳細にとなってしまうのである。

今まで、コストが見えなかった。もしくは、コストの精度が悪かった。という不満があるところに、今から、仕組みの改革をしようとなると、コストの活用目的を無視し、「どうせなら精度良くしてもらいたい」と思う人が多いのである。

たしかに、精度が悪いより、精度良い数値を提供してもらった方が何かと嬉しいのも分かる。
しかし、無闇やたらに精度を要求してしまっては、データ構造や計算処理が複雑になりお金や時間ばかりかかってしまうのである。
お金がかかりすぎ、検討に時間ばかり費やすことで、そのうちプロジェクトが止まってしまうのである。

皆さんが、要件を伝えるユーザ部門の立場であれば、「どうせなら」という気持ちを捨てて、目的を明確にした上で原価の精度を要望してもらいたい。
この「どうせなら」という軽い気持ちが、全社の重要なプロジェクトが止まってしまうのである。

また、原価を専門にしている方は、複雑な計算処理が出来る仕組みがすばらしいと勘違いしていることも多い。
改革目的、製品構造、業務構造からすると、場合によっては簡易的な原価の仕組みでも十分な場合がある。
しかし、原価の専門家からすると、無意味に複雑な計算処理を作ってしまうのである。

「こんな複雑な配賦処理の仕組みを考えた！これで原価の精度が悪いなど言わせない！」などの、言い訳にするためである。

共通して言えることが、全て"計算"にフォーカスしており、原価を"活用すること"　を無視していることが多い。

繰り返しになるが、改革は何かの目的を達成させるためにある。
計算を複雑にし、こだわった計算ロジックを構築することではない。

コストの仕組みを構築する場合は、活用目的を明確にし、それに合った精度を追求してもらいたい。

＜A＞
当社の特長は、お客様が必要とする仕様をお聞きし、どんな仕様のバネでも対応できるという点です。他社なら、規格品や規格に準ずるサイズしかできませんというところを、我々はコンマ1ミリ単位でも作りますし、お客さんの図面を見て「その設計では無駄ですよ」といった提案ができるのが強みだと思います。要求仕様のバネに、納期対応力やバネに関する技術情報を付加し、その組み合わせ一式、つまりソリューションとして買って頂く。提案営業型で価格決定権を持ち続けています。

また、2003年からバネのe-ディクショナリーとして全国のユーザーに使ってもらおうという狙いで、「まかせなはれ！オーダーメイド」と名付けたWebサイトにリニューアルしました。東海バネのWebを覗くと、バネのことなら何でも分かるよう、当社の技術的な知識やノウハウを全部公開してみたら、一気にお客様が増えました。初年度が105社。その後181、233...という具合に年約200社ペースで新規顧客が増えています。

このWebサイトが、仕様のすり合わせに対して効果的に機能しています。お問い合わせ欄に要求仕様の詳細についてお伺いする機能を持たせており、お客様自身も、項目を埋めていくことで、こんなバネがほしいという潜在的なイメージが顕在化するようです。問い合わせ項目をもとにお客様のご要望を具体化した図面を出し仕様を詰めていきます。