DX推進の壁になっている製造業のアウトソーシングを見直すべき。

製造業のアウトソーシングは拡大している

企業のアウトソーシングは企業の成長と共に増える傾向にある。これは生産量の拡大などにより、社内の正規社員を増やすのではなく、外部の派遣企業などを活用し、一時的な業務負荷への対応をするためである。或いは、費用が相対的に少ない社外を利用することで、利益を増加さえるために行われている。

アウトソーシングの問題点

しかし、アウトソーシングにおける問題点は企業のコア技術を社内に残すことができず、生産量の縮小などで再度、社内でその業務を実施する必要があるときに、コア技術が失われ、社内では実施することができない問題を起こすことになる。(技術の喪失)。もう1つの問題点は企業が面倒な業務をアウトソーシングすることで、企業内に業務を管理するだけの社員が増加し、管理業務を仕事と勘違いしてしまうことである。(風土の荒廃)

ものづくりのコア・コンピタンスを忘れてはいけない

今、この2つの問題点で製造業は大変な状態になってしまっているのではないかと推察している。前者のコア技術の社外化から問題の深刻さを挙げると、まず、コア技術(コア・コンピタンス)そのものを意識せずに仕事が大変だから、人が不足しているので社外化していることが多い。コア技術とはものづくりの作り方そのものの技術だけではない。エンジニアはかつて現場の場数を踏んで成長してきたはずである。 

製造業の人材育成と職場環境

しかし、今の時代、新入社員のエンジニアは、いきなり社外の人が活用された状態にある職場環境から仕事を覚えていくしかない。それも自分の仕事は細部化し、与えられた時間の少ない中で業務を進めていくしかない。これは与える側(管理者)の仕事の与え方の問題もある。じっくり考えて仕事を遂行する習慣を身に付けるリードタイムが社員の育成には必要なのである。

考える人材を開発しなければならない。教えられてこなかった教育。

また、インターネットにより、分からないこと、知らなかったことも、短時間に収集することができる。収集した図や文言を引用し、仕事の成果にしてすませることもできる。探すことには長けてはいるが、考える力が身につかない方法である。

現場の見て、頭で考える習慣をつけること

かつてのエンジニア達は工場の現場で物を手にし、油にまみれながら、何故を考え、自分の結論に至り、その結果を、議論することで、更に自分の知識を深めていくことが業務の中で行うことができた。このことは、今でもできない事にはなっていない、できる環境は何も変わっていない。

現場の調査はコア・コンピタンスの重要な業務である。

しかし、現場に足を運ぶ回数が減っているのはどこに原因があるのだろうか。それは、現場の調査は時間と手間がかかるから、社外化していることにも原因がある。他の部署では同じようなことを社外を活用し実施していることを知ると、自分の部署でも同様なことに社外活用を実施したことに思い当たるはずだ。

忙しいと言う職場は忙しくない。それはアウトソーシングしているからだ。

忙しい組織(実は皆忙しいと思うことが多く、暇だと思うことは段々と習慣化し、いつも忙しいと思うように人は考えやすいものだ)はまず、何から効率化すること言えば、現場の調査、あるいは事例の整理などを社外化するはずだ。

効率化とアウトソーシングは逆行している。

効率化とは人が減る方策をまず考えることが先であるのに、生産量の拡大時は、社外化を先に選択してしまったことが多い。実は、この時間がかかり、手間のかかる仕事こそが企業に重要なコア・コンピタンスが含まれていることと管理者は気づくべきである。

経験の積み重ね。面倒なことを避けては技術は身につかない。

振り返るに、人の仕事とは何か。人は全く新しいこと、物に気づき、生み出すことは稀である。それこそ天才と言われた歴史に名を残す賢人以外は、過去の経験や知識をよりどころにして、業務を行っているはずである。手続きや判断が標準化されているものであれば、容易に業務が遂行できる。標準化されていないものであっても、過去の経験や周辺の関係者の知識をまとめて、1つの結論に至っているのである。

考える仕事は内製に戻すべき

コア・コンピタンスは標準化されていないことや物に行き当たった時に、どのように判断をするかという仕事として位置づけられる重要な固有能力である。もし、仮にこのような判断も含めて社外化した業務があるならば、早期に内製化すべきである。


 企業においては、物事を判断する行為や力そのものが企業の能力であり、財産であるはずだ。その一部を社外化してしまっては、もはや企業の能力を社外に分け与えてしまうだけではなく、社外の力を活用しなければ、その業務が行えないことになってしまう。

DXの前に行うべきことはファイル管理である。

ファイルは見つからないのは大問題

これまで、ファイルが見つからない、探せないという問題が大きいということを述べてきた。もう一つは、ファイルの記載内容は正しいのかという問題もある。過去のその時は、その内容で良かったが、現在はちょっと状況が異なっているということもある。しかし、それでも過去のファイルを見たいという欲求は変わらずにある。ファイルは見つからなければいけないものだと思う。

ファイル名と内容の一致性が保証されていない

人はどんなに年齢や経験を経ても、まだまだ知らないことがあるものである。企業の中では、なおさら、知識は共有されなければならない。
 ファイルの名前やホルダー名称からは、その中に記録された知識がどのようなことに関するものかは読み取れない。

これは例えば、1から5の数字が書かれた5枚のトランプカードが目の前にあるとしよう。数を数えられない幼児には、見た目の違いしか区別ができない。年上の子は、順番の数字であると理解する。このような順番の知識が隠れている。

ホルダー階層の区分が理解しにくい。普遍性をもっていないからである。


 ホルダー階層やファイル名を人が見た時は、幼児がこのようなトランプカードを見たことと大差はないのである。ある事の説明のためには、そのことが理解させるようなストーリーとしての説明文が別に必要である。しかし、分かっている自分がわざわざ他の人のために説明ストーリーを記述することはしない。もしも記述してくれたならば、このストーリーはその人の知識をベースに説明したストーリーとなる。ゆえに他者にはストーリーが一部分、理解できないこともある。そのような場合は、その箇所を人に質問し、理解することになる。

システムに期待していること

それは、ある人の仕事の結論を、その理由をグラフや表や文書や絵を用いて説明することが手間なく行える必要がある。人が頭の中で作ったストーリーが結論を書いた文書に関係して手間なく作られると良いのである。


 そして、それを共有し、分からない人の質問と回答を自由にこ記述できるようにすることで、説明のストーリーが膨らみのある全体的な知識にすることができるのである。人の思考プロセスの記述をすることで、知識の記録が実現できているということである。

読み手が書き手と同じ理解ができること

他の人が作成した一つファイルとして独立した文書は自分が思考していることとは異なるものである。そのためにベースとなる知識が共有されなければ納得できないことになる。この理解度の差は、企業における意思決定に大きな問題である。理解の差を埋めるために、また別な資料を作る無駄をしている。知識の不足した管理者による正しくない結論になってしまうこともある。

CKWEB2が実現している便利さについて


 これを防ぐには、デジタル化された情報に対して、簡単な工夫をすれば良い。それは、表や絵やグラフや数字や文書など、いろいろなアプリで、いろいろな拡張子でも見ている目は画像になり同じフォーマットである。したがって、全ての文書はイメージデータに変換し、原本との区別と改竄を避けつつ、ckweb2 による特徴点記録法を用いることで解決できるようになる。


 帳票、フォーマット、形式ということを考えないことが必要だ。人の思考に元々は存在しないことであり、創造性の邪魔になるように思えてならない。紙に自由記述しながら、仕事ができるようにならないものかと考えたのである。

製造業のものづくり知識の記録構造と検索性

情報探索の入口は分かりやすいビジュアルな抽象化モデル(絵)である必要がある。その絵は実際の具体的なものであるが、そのものが何かを知ることが目的ではなく、その絵から自分が探したいことの分野を区別することが目的である。絵が増えたら見つけにくいので上位概念的なまとめた絵を登録する事が重要である。


 例えば、子供向け図鑑の目次の絵のような大分類がよいだろう。この大分類は、個人のメモを記録するならば、自分が関心のある分野を自分が想像できる絵ならなんでも良い。要は、自分が間違えることなく、その内容を管理できれば良いのである。これは容易なことである。


 一方、仕事のためのメモを記録するには、仕事がどのような分野であるかが分かる絵を入口に配置する必要がある。企業の中で共有するのであるから、誰でもその絵を見て、中にどのような情報が記録されているかが分かる必要がある。より分かり安く間違えないために、テキストで文言を絵の中に記入しても良い。


 例えば、製品を開発して販売する企業であれば、設計、製造、販売などのイメージがつく絵が良いだろう。設計でも複数のカテゴリの製品を設計する企業ならば、カテゴリA、カテゴリB、カテゴリCの区別のつく絵でも良い。製造が複数の地域にある場合は工場a、工場bなどの絵で良い。変化の可能性のある組織の名称を用いずに、一般的な呼び方である組織名称を用いることが必要である。工場名称などは滅多に変更しないだろうし、県の形のイメージに工場がある絵を用いれば、誰でも区別つくであろう。


 企業の中のある組織の企業人のメモは、やはり自分の担当分野を明示できる絵を情報探索の入口にする。この絵も誰が見ても内容が想像できるものであることが必要だ。非常口のサインのようにものを想像すると良い。


 このように入口を表す明確な絵を取り決めて用いることが情報蓄積の第一歩である。情報は粒度も分野も異なるもので、それにもれなく分類を決めようとすると逆に分類からはみ出す情報が出てきてしまう。私達のホルダー名称の不思議な命名は、変化する分類と仕事の内容によっては複雑化されたことを表している。そこまでの分類を決めるのは統一的で遵守できる範囲を超えてしまうので、全号で説明したように失敗してしまうのである。


 では、大分類の中にどんな絵を配置するのかと言えば、それは、その組織における最終アウトプット文書のイメージ図を用いるのが良い。設計の最終アウトプットイメージ図は部品表と製品の設計図と日程表である。それ以外にあるものは最終アウトプットを作成するための、文書である。部品表と設計図と日程表の3つの絵にメモを記述するのである。それぞれの絵には、気がついた時に複数のテーマの特徴点を追加していくのである。既にテーマが登録されているならば、その点に更に追記するだけである。テキストと参照文書を添付するだけなのでシンプルである。


 製造側は、何をどの様なプロセスや日程で行うべきかを書いた標準日程表、生産ラインの全体図、製品の全体構成図などが検索の入口モデルにすると良い。その中に業務日程詳細図、加工プロセスの詳細図、部品図などをモデル登録する。全体図にも詳細図のどのモデルにも特徴点登録できる。詳細図の中にも特徴点登録できる。それぞれの特徴点には参照モデル登録できる。モデル登録したモデルは他のモデルのどこにでも親子関係を定義できる。このようにすることで、製品構造と工程と生産計画を関係づけて記録することができるようになる。


 ここで登録する情報は技術的思考を記録することであり、関係者の意見を記録することである。また、その文言を全文検索対象にする事で、改めてタグを付与せずに、もれなく検索できるようにすることにある。


 モデルの親子関係は詳細を図で説明する時に必要であり、参照図はより横断的な知識共有により決定合意の速度を高めることにある。
 親子関係を後で付加できることは、思いついた時に追加できる自由さのためである。誰でも完全なる網羅的登録を最初からできるのではないから。


 モデル図を的確にたどり、必要なモデルを見つける方法は、モデルのネットワーク図の見せ方が重要である。言葉を知らない場合のビジュアルな図の探索発見方法と対象の検索言葉を知っている場合のなどの全文検索が重要である。        絵の中に特徴点を記述することは、技術情報が必ずその絵の中にあることを意味していることを保証している。絵に特徴点を登録しなければ会話が登録できないようにできている。


つまり絵と会話は分離されることがない。
 絵を見つければ技術情報を見つけることができる。また、言葉を知っていれば、見たこともない技術情報を絵を指し示して理解することができる。
 このよう情報を知る目次的な機能としても役に立ち、真の図面などは、この後ろに続いて他の固有システムを操作して知ることができる。


 一方親子関係の中あるいはそれを超えた関係の中で付与された特徴点はどのように振る舞う必要があるのか?
 親の会話テーマが子供の会話テーマと親子の関係テーマであるかは難しい。
 1つの目的の為に、複数のテーマを検討する場合には、関係を定義できる。親のテーマがいつ子供のモデルのテーマがその親子関係として認識されるかはわからない。親のテーマがいつまで親のテーマでありつづけるかは確かではない、その時の親のテーマにしただけのことである。このような方法で、日常的なメモを後で検索しやすくすることができるのである。

メモのツールの不便さを解消して、自分の知識の記録をする方法

メモアプリの使い方と問題点

これまで、いろいろなITツールを使ってメモを書いてきた。どれも満足のできないやり方であった。その失敗例を紹介したい。
 メモをスマホの良くあるメモアプリを使って記録した。これは、日付もタイトルも自由入力であり何でも書ける自由度が高いアプリであった。メモを全文検索もできるので、数文字の入力で候補が絞られるので便利であった。しかし、問題は、メモを分類できないことであった。分類機能は必要である。KJ法のように。
 ある時から、新聞の電子版を購読し始めた。毎日必ず読んでいて、その時に知ったことをアプリに保存を始めた。その理由は、それまでのメモアプリでは、新聞の記事内の写真が保存できなかったからだ。この時から新聞記事が、分類をつけて記録できるようになり今でも継続している。しかしこのアプリで困ったことは、自分の意見や考えを、その記事について記録が見えやすい場所に書き加えれないことであった。記事のタイトル欄に付け加えて、意見を書き込んでいるが、その意見は元々の記事のタイトルがどのような文であったのかが全く分からないので困ってしまった。Webの記事も同じ問題がある。

メールやチャットの問題点

次はメールでの配信文書の記録。メールで届く内容で、イベントの日時案内、情報の提供、知り合いからのメールに記録したい事が多い。その中でメール文中にURLが記載された記事がキチンと記録できない。URLを開いて、中身が記憶にだけあって、もう一度見たいと思った場合は、URLをお気に入りに入れていた。しかしこの操作は時としてやり忘れ、頭の中で、あの人のメールに案内されていたように思えるという薄い記憶を頼りに、受信メール一覧の中を探し回る。本当にストレスの高い行為である。お気に入りも、雑然としてゴミになってきている。


 更にメールは、何回かのやりとりしたことが見つけにくい。差出人名で探すのが一番だと思っているが、次に、その中から該当のメールを見つける事がストレスである。件名が、同じものがいくつもあり、これは、実は、返信の際に件名との無関係な内容を含めてやりとりするからである。もはや、一件づつ開いて読むしかないという原始人のやり方に戻っている事が腹立たしくなる。
 以上がテキストをメインとするメモアプリを使っての課題である。

文書作成ソフトの問題点

自分で書いた報告書など一つのテーマに関して、まとめた文書は、報告後は自分のPCに保存され、後にクラウドの有料サーバに保存するように変更した。しかし、これはアプリ依存した文書を保存するので、アプリ横断的な検索を行ったとしても、ファイル名しか対象とされない。この場合もいろいろ考えたことがファイルの中に閉じこめられてしまい、ファイルを開かなければ欲しかった考えを見つける事ができない。同じくストレスのある作業となっている。更に、クラウドサービス会社によっては、MacとWindowsのファイルは共存できないなど、困った問題がある。

必要なことは色々なアプリやサーバにあるメモを一体として扱える

自分のためのメモもあれば、会社でのメモもある。これらのでメモは、タイミングが来るまで、思考を暖め、個人の記録として分けて保有したかった。ところが、この区別が、明確に出来なくなってきたのであった。
 メモは次第に合流し、また、分岐して異なる目的の中で扱われる。その間に新しい発見があり、そのことの説明にも用いられることになる。メモを探すことができないことが問題である。それも思い出せないメモをである。
 結局、いろいろなアプリやサービスが氾濫してしまった今日では、どこにでもつながる入口と仮想的に集合されたイメージによるメモ環境が必要だと考えたのである。

製造業での技術の蓄積検索の問題点と解決法

創造性に使われるKJ法のプロセスを残せていない。

商業用途の検索は仕事には使えない。時間の無駄であるが、他に代替方法がないから、やむを得ず使うしかない。使わないよりも探す時間は短くて済むからだ。それでも、別な方法がないのだろうか?といつも思っていた。
 昔、川喜田二郎先生が考案したKJ法であるが、企業の中でも、今でも使われている。一つのテーマについて、多くの意見を出し合い、その結果をいくつかのグループに層別し、テーマについての結論を見つける手法である。
 この結果は報告記録されるが、そのカードは輪ゴムで束ね、いつしか捨てられてしまう。そして、いつかまた同じようなテーマを違うメンバーがKJ法で行うことになる。思い出す行為は何回も繰り返えされるのである。このストレスは大変なものだ。
 環境の変化や技術の変化で、同じテーマであっても、異なる結論がまとめられることもある。しかし、記入したカードの8割が過去と同じであり、10人が半日かけて40時間の工数を使ったならば、過去のカードを利用できる場合には、10人で1時間で結論が出せる可能性がある。
 チームでアイデアを出し合い際でも、最後に残った結果以外は破棄されてしまう。
 或いは、原価低減活動におけるものづくりのコストを減らすアイデアも、効果の大きなアイデアだけが採用されて、他のアイデアは捨てられてしまう。原価低減活動は、実際のものを見ながら行うことが多い。この場合、形やサイズを変更すれば安くると分かっても、生産設備の改造ができないので、そのアイデアは却下となることもある。

特徴点記述法のメリット


 ものができてしまった後の原価低減は難しい。本来、この原価低減アイデアは、次の製品設計で織り込まなければいけないアイデアである。しかし、チームが異なる、しばらく開発の計画がなければ、忘れ去られてしまう。このようなせっかくのアイデアが企業の中で継承されないことが多いと思う。
 このようなメモはどこに記録できるだろうか?PCでテキスト作成ツールでメモを書いても、社内で共有は難しい。ファイルの置き場のフォルダ階層を、探しすのは面倒であるから守られない。個人のフォルダにファイルを保存するくらいしかやらないだろう。
 どこに置かれていても、原価低減アイデアが繭の糸のように引き出すことができなければならない。このようなことが可能になるのが、特徴点記録法なのである。