タイム・コンサルタントの日誌から

時間を可視化するために

ガントチャートの「イナズマ線」については、ご存じの方も多いと思う。スケジュール計画を立て、工程表をガントチャートの形で図にしたら、あとは一定期間ごとに、そこに各作業の進捗状況を書き込むのである。

下図は4つのアクティビティからなる簡単なプロジェクトの例だ。企画調査とコンセプト検討は、第4週から始めて6週で終わり、予算確認とレポート作成は7週からはじめて9週の初めに完了する計画だった。ところで、現在は第7週の初めだが、コンセプト検討がまだ終わっていない。事情で着手が1週遅れたからだった。一方、予算確認は1週先行して、すでに完了している。

言葉にするとこんなゴチャゴチャした記述になるが、イナズマ線で描けば明快だ。イナズマ線は、各アクティビティの進捗率にしたがって、50%進捗ならば、作業を表すバーの真ん中に点を、67%ならば作業バーの2/3の場所に点を打ち、それらの点を、縦に線でつなげるのである。このとき、すでに完了したアクティビティについては、100%の点ではなく、現在日付のところに点を打つ。

こうすると縦にジグザグの、稻妻に似た線ができるので、イナズマ線という（英語では単純にProgress lineとよぶことが多い）。イナズマ線が、現在日付（Time now）よりも左に凹んでいるアクティビティは、遅れを意味し、右に出っ張っている部分は、予定よりも先に進んでいることを示している。こうすると問題発生部分が目に見えやすくなるので、定期的なプロジェクトの進捗ミーティングなどで、問題解決に向けた話し合いができる。

作業の進捗というのは、はたの目に見えにくいものだ。だが進捗が遅れると、納期に影響する。だからガントチャートのイナズマ線は、時間を可視化する工夫だと言える。いや、むしろイナズマ線を引かないガントチャートなど、実際の役にはほとんど立たないと言ってもいい。もちろんイナズマ線を「読む」ことのできないプロジェクト・マネージャーは、プロマネの名に値しない。

もともとモノや人は目に見え、五感で知ることがたやすい。他方、時間は目に見えない。でも時間的な制約や納期をもつ仕事は多い。だから、動きや働き、過程や進捗などを、なんらかの位置に変換して、時間を可視化するための工夫が必要になるのである。

ところで、この『進捗の可視化』を、工場における組立工程にうまく応用している例を、見たことがある。数年前、日立製作所の大みか工場を、ご厚意で見学させていただいた。この工場は、電力制御システムなどを製造しており、金属製のキャビネットの中に、電子回路や電源装置、そしてケーブルなどを組み付けていく。細かな部品が多い上に、毎回個別に受注して設計するタイプの製品なので、納期管理も難しい。

ちなみに以前、本サイトでは生産方式を「フローライン型」「フローショップ型」「ジョブショップ型」「セル型」の4種類に分類した。だが、実は第5の種類として、

　「ドック型」

というのがある。これは、製造対象のワークが工場の中を移動するのではなく、同じ位置にずっと置かれたまま、加工作業や組立作業を行うタイプである。造船業のドックなどが、その典型で、船はドックの中で次第に完成形になっていく。航空機などもそうだ。

大みか工場のような、比較的大きく重量もある制御盤などの工場でも、ふつうは組立エリアにキャビネットの箱を据え付けて、その中に部品を組み付けていく。つまり「ドック型」生産方式なのである。しかし、なにせ箱の内部に組み付けていくのだから、外から見ても作業の進捗度が見えにくい。

ところが、この工場では、キャビネットを固定位置に据え付けてはいなかった。キャビネットを移動可能なキャスター台の上に置いて、そこで組み立てていく。そして、組立作業の進み具合に応じて、キャスター台の位置を、組立エリアの出口（出荷口）に少しずつ、移動させていくのである。そのためにキャスターにはたしか、移動用のガイドワイヤーがつなげられていたと記憶する。

こうすると、組立エリアの中のどの位置にあるかを見ると、その組立の進捗度がすぐに分かる。ちょうど、ガントチャートのイナズマ線をひく位置のようなものだ。わたしが見たのは少し前で、今もやられているかどうかは不明だが、とても巧みな、面白い工夫だと思った。さすがは日本企業で唯一、世界経済フォーラムWEFの選定するスマート工場（”Lighthouse”）に認定されるだけのことはある。

もっともこのやり方は、組立エリアにそれなりに広い面積を必要とするので、どこの工場でもすぐに真似できる方法ではない。それに本物の船だったら、それこそドックの中を移動する訳にもいかないので、対象が限られているのも事実だ。だが、面白い工夫であることにかわりはない。

わたしは、自分のエンジニアリングの業務にこれを応用したらどうなるかと、夢想してみた。工場づくりのエンジニアリングの仕事は、3D-CADを使って設計するのが基本である。そして、この3D-CADの進捗状況が分かりにくい。社内では3D modelの完成度について、標準的なメジャーメントの取り決めがある。だが、それでも分かりにくいのである。それは3D-CADがコンピュータの「サイバー空間」にあって、目に見えにくいからだ。

そこで、3D-CADのデータが集約される部門の担当者、つまりプラント系なら配管設計、建屋系なら建築設計の担当者が、少しずつ、席を移動していくのはどうだろうか。

「うーん、中村君は出口に近い、あの位置か。北米向けの案件は順調に進んでいるようだな」

「おや、伊藤君は先月からずっと、あの席のままじゃないか。中東向けの案件は設計で問題が生じているらしい」

と、すごく話が分かりやすくなるのではないか・・

だが、わたしはこの「妙案」を、会社に提出することはしなかった。まず、そんな風に人がまばらに座るような、贅沢なオフィススペースの使い方は、とてもできない。だがそれ以前に、3D-CADの完成の遅れは、その担当者自体の問題と言うよりも、その担当者（設計データを集約してCADにインプットする役割）に対する、上流側各部門の遅れが影響しているはずだからだ。

下流側の結果で問題を検知しても遅すぎる。その上流側も遅れを「見える化」しなければ、素早い打ち手はとれない。だが、上流側設計部門の全てのオフィスを、同じように「位置ずらし方式」レイアウトにするなど、経営から見たら論外であろう。

んじゃあ、人が物理的に場所をずらす代わりに、デジタル画面に進捗を表示したらどうなの？　そう。もちろん、それくらいは取り組んでいるのだ。設計業務の進捗をEVMS的に定量化し、くどいくらいの頻度で測り、レポーティングする仕組みは、社内にできあがっている。グラフにもなっている。だが、それでもプロジェクトに遅れが発生するのは、なぜなのか？

それは、稼働や進捗率の可視化だけでは、ある問題をタイムリーに把握できないからだ。それは、手待ちの発生である。

（この項つづく）

＜関連エントリ＞

　(2021-05-15)

モノの「作り方を管理する」システムとは （そしてMESに関するシンポジウムのご案内：10月7日AM）

別段、料理が趣味という訳ではないが、ときおり必要に応じて、自分で作る。得意料理は（やや平凡ながら）カレーである。といっても、スパイスを混ぜるところから始める、それなりに本格的なインドカレーだ。じつは若い頃、留学生寮に住んでいた時に、知人のインド人の奥さんに教えてもらったのだ。

以来、アレンジは時によって変化しつつも、作り方はずっと頭の中にある。材料や配合はほぼすべて、目分量。それでもなんとか仕上がる。

ところで最近、チキン・ビリヤニというインド料理専用の、スパイス・ミックスを入手した。簡単に言うと、カレー風味の炊き込みご飯である。しかし、作り方を知らない。そこでスパイスの箱についていた、小さな文字の読みにくい英語レシピに従い、一応忠実に作ってみた。材料もきちんとレシピ通りの量で、調味料の配合には計量スプーンを用い、牛乳や水も、ちゃんとカップで計る。

出来上がりの味は、まあ、家族から苦情が出ない程度には、まとまった。ただお米の料理なので、火加減や水加減が難しいなあ。それが感想である。

「レシピ」recipeとは、モノづくりとしての料理の作業手順＝『作り方』を示した情報である。レシピには普通、まず「材料表」がついている。製造業の用語で言えば、BOM（部品表）に相当する。そして、材料の下準備、カット、加熱調理、味付け、仕上げ、盛り付けなどの手順が並ぶ。それぞれの作業ステップでは、何がインプットの材料で、どんな調理器具（製造業で言えば機械やツール）を使い、何分間・何度で加熱すべし、といった作業の詳細スペックが並ぶ。

さて、世の中の普通の生産管理システムは、BOM（部品表）データをマスタとして保持しており、製品の需要量から、部品展開して、製造工程や資材購買の指図（オーダー）を生成する機能を持っている。さらに、ここに在庫引当と正味所要量の計算、そしてタイム・バケットと標準リードタイムといった時間軸の計算機能まで加われば、いわゆるMRP（Material Requirement Planning）システムになる。SAPなど、大手ERPパッケージも、生産管理の根幹に、このMRPを発展させたロジックを内蔵している。

ところで、上述のレシピ情報は、生産管理システムの中に、登録・維持されているだろうか？　おそらく、NOだろう。元々のMRPの概念は、構造型部品表（M-BOM）までは含んでいた。その中には、子の部品がいかなる工順を経て、親である製品になるか、まではモデル化されている。だが、それがどんなフライパン、いや機械設備を使うのか、何度に昇温して何分間保つのか、なんてことは、MRPの対象外なのだ。

じゃあ、現場の機械の中に、レシピ情報は格納されているのか。それはちょっと違う。焼成炉の中に材料を仕込んで、何度に昇温し何分間維持するか。そういった制御は、手で毎回設定する設備もあるだろうし、あるいは機側盤にコントローラー（PLC）が内蔵されていて、プログラムが保持されている場合もある。

とはいえ、それは、焼成炉という機械単体の手順に過ぎない。レシピとは、複数の材料と、中間製品と、最終製品全体を含み、さらに手作業を含む様々な設備や機械を、カバーしていなければならない。それは、単体の機械の制御システムの範囲を超えるものだ。

生産管理システムの中には、ない。現場の制御システムの中にも、ない。では、レシピ情報は、一体どこに保持されているのか？

答えはおそらく、「作業する人の頭の中にある」、が圧倒的多数であろう。つまり、わたしのインドカレー状態である。わたしのインドカレーは、わたしが作る限り、ちゃんとした味（＝品質）で仕上がる。作る時間（＝製造リードタイム）も、ほぼ見えている。コストもまあ、材料代と手間賃の合計だから、だいたいの範囲にはいっている。

レシピ（＝詳細な「作り方」）は、製造業の三大指標である、QCD（品質・コスト・納期）を、実質的に支配するのだ。そしてレシピが、誰かさんの頭の中に留まっている限り、仕事の成果は、やる人に依存する。その人の習熟度に、依存する。

そこで会社では、新入社員に対して、OJT教育に時間を掛けて、頭の中に叩き込む。そのため、終身雇用のような、人の定着率が高くなる人事制度をとる。こういう論理で、昭和の高度成長期は会社が動いていた。

残念ながら今は、その前提条件が崩れている。現実の日本の工場を見ると、外国人だらけだ。彼らが学んだことを、そのまま一生、その工場で活かし続けてくれるとは、誰も信じていない。また、日本のマザー工場でできていることを、そのまま海外工場に移植しても、日本のような品質の出来上がりは無理だ。つまり、今や日本の工場の多くは、持続可能（サスティナブル）でもないし、拡大可能（スケーラブル）でもない状態にあるのだ。

レシピは、人の頭の中にある。つまり、レシピは熟練工の暗黙知である、と。本当だろうか？　レシピというのは、実はきちんとした形式と論理構造が決まったデータではないか。つまり、本来的に形式知であるはずのものである。それを「暗黙知」の状態に落としていたのは、何かの仕組みが足りなかったせいではないか。

実は、そのレシピを登録し維持し、画面や帳票に出力し、人間や機械に落とし込み、さらに実際その通りに進められているかをモニタリングするのが、MES=Manufacturing Execution Systemなのである。これを「製造実行システム」と直訳したのは、致し方ないかもしれないが、内容がちょっと分かりにくい。そこで最近では、MOM=Manufacturing Operation Management（製造マネジメント）システム、という言葉も登場した。ただ、まだMESという用語もかなりの業種で残っている。

ちなみにモノの「作り方」を示す、レシピという用語は、化学工業（とくにバッチプラント）の分野では使われるが、それ以外のディスクリート系（加工組立系）では、あまり聞かない。これに対応する概念は、SOP=Standard Operation Procedure（標準作業手順書）である。このSOPは、その背後に、BOP=Bill of Processes（工程表）があり、BOPはさらに遡ると、M-BOM（製造部品表）を骨組みにして構築される。

MESとは何なのか、MESがあると何がうれしいのかというと、まず第一に、レシピ/SOP（＝形式知化された「作り方」）をベースに、誰もが一定品質で、製造作業を進められるようになる。これによって、工場が持続可能で拡大可能になる。経営面からすると、これが最重要であろう。

また工場で製造マネジメントに従事しているミドル層にとっては、MESが上位（本社系）の基準生産計画と、現場の機械制御や人への指示と状態把握とを、半自動でつないでくれる点に、有難さがある。とくに、現場の状態を今までよりもリアルタイムに、かつ正確に捉えられるようになる。ロットトレースとか、オーダーの進捗確認・納期回答なども、ずっとやりやすくなるし、個別の原価把握も正確になる。

そして現場にとっては、SOP・レシピに準じた、より正確な指示が降りてきて、非熟練者でも作業がしやすくなるし、機械と連動してくれれば、より自動化も進みやすいことになる。3K職場が、少しでも楽になる。

（さらに、もう少しMES周辺に詳しい人なら、SOP/レシピの管理だけじゃなく、保全管理のCMMSとか、製造履歴データ保管のHistorianとか、ラボ情報のためのLIMSとかも、MESの領域じゃないか、と指摘されるだろう。まさにそのとおりである。これらも「製造マネジメント」の仕事の一部だからだ）

もちろん、MESを活用した「スマートな工場」を実現するには、いろいろと乗り越えるべき課題もありそうだ。具体的には、どんな業界でどんな先行事例があるのか、知りたい。そもそも日本では、どんなMESパッケージソフトウェアが売られていて、どんな機能があるのか。こういった情報が、今は極めて欠けている。

そこで、（ここからお知らせになるのですが）、エンジニアリング協会「次世代スマート工場のエンジニアリング研究会」では、今年度の活動の柱の一つとして、

　「製造実行システムMESのの現在と将来」　　　10月7日 AM（9:00-12:00）

と第するシンポジウムを企画している（現時点ではオンライン形式を想定）。参加費は無償である。

MESは次世代スマート工場に必須の要素ながら、我が国では過去20年間、ごく一部の業界のみの利用に留まってきた。だが今や、IoT技術の普及と、製造業におけるDXの動きとともに、最近ニーズが高まりつつある。ただ、MESの製品や活用事例に関する情報は、極めて限られた状態にある。わたしが共著者の一人として書いた「MES入門」（工業調査会）は、2000年発行で絶版だが、今でも高価な値段で取引されている。

そこで研究会では、内外の有力MESベンダー各社にお声がけし、半日をかけて、各社製品の特徴や、活用事例などを紹介いただく場とし、全体を通したQ&Aセッションも実施することになった。

参加を希望される方は、エンジニアリング協会のこちらのページから申込みいただきたい。

https://www.enaa.or.jp/seminar/52299

参加企業と詳しいアジェンダについては、上記ページで追って公開する予定である。工場のデジタル化や自動化などに関心のある諸賢のご参加を期待する。

・・うむ、お知らせなので、なんだか文体が固くなってきたぞ。皆さん、お暇だったら、来てよね。いや、お暇かどうかはともかく、こうしたオンラインセミナーは現在、非常に多数企画されていると承知している。ただ、当研究会は、MESに関わるユーザーもベンダーも会員であり、ある意味「チーム・オブ・ライバルズ」として、中立な立場から、このシンポジウムを企画している。その点では、ユニークな試みと信じている。

どうか関心ある大勢の方のご来聴を賜らんことを。

佐藤知一＠日揮ホールディングス（株）

「プロジェクト＆プログラム・アナリシス研究部会」（10月1日＋9月23日）開催のお知らせ

「プロジェクト＆プログラム・アナリシス研究部会」の2021年第4回会合を開催いたします（オンライン形式）。

「データは新しい石油である」（Data is the new oil）という言葉があります。データは発掘されるのを待っており、そこから新しい豊かな価値が取り出されるのだ、との意味で使われており、おそらく産油国アメリカ発の言い方なのでしょう。

もしもデータが石油なら、発掘するだけじゃなく、蒸留し精製しないと使えないはずです。多種多様な混合物であり、除去すべき不純物もかなり含まれている点で、データと石油は共通しているからです。精製は原理的にはシンプルでも、かなりのエネルギーと手数がかかります（石油工学の教訓）。セキュリティと安全性にも、十分注意しなければなりません。

多量のデータから意味を抽出するための方法論が、データサイエンスです。データサイエンスは、深層学習を主体とするAIの発展と歩調を合わせて、2010年代から急速に普及発展してきました。これからも社会的需要は拡大し、データサイエンティストは独立した職能として、あるいは業界として確立していくと思われます。

今回は、日本ソーシャルデータサイエンス学会の中心メンバーである、静岡理工科大学の水野信也教授をお招きして、その活用事例と、人材育成についてお話しいただきます。

データサイエンスは、わたし達が過去の事実や経験から学ぶ能力を、飛躍的に高めてくれます。それはITのみならず、さまざまな分野におけるプロジェクト・マネジメントのあり方にも影響を及ぼさずにはいないでしょう。

と同時に、「データは取って集めてみたけれど、どう活用すれば良いか分からない」といった現場の悩みを抱えている方々にも、大きなヒントを与えてくれると思います。データ活用に関心のある大勢の方のご参加をお待ちしております。

＜記＞

■日時：2021年10月1日（金）　18:30～20:30

■講演タイトル：

「データサイエンスの活用例とその課題」

■概要：

データサイエンスは、データを介して各部門のハブとなり、組織の課題解決の推進役を期待されています。

本講演では、今まで関わってきたデータサイエンスの活用例を紹介するとともに、その時感じた課題も示します。

また今後データサイエンスとどのように関わっていくかを人材育成面も含めてお話します。

■講師：静岡理工科大学情報学部コンピュータシステム学科 　水野信也 教授

　

■講師略歴：

2008年3月 静岡大学大学院 理工学研究科システム科学専攻後期博士課程修了

現在、静岡理工科大学情報学部コンピュータシステム学科 教授

情報教育研究センターセンター長兼務

その他、静岡大学 情報基盤センター 客員教授、順天堂大学 大学院医学研究科データサイエンス 客員教授

確率過程をベースとして、実社会モデルに数理モデルを適用して、評価、最適化、シミュレーションを実施しています。

数学、情報基盤、データの３つを連携したデータサイエンス領域での研究活動を行なっています。

リサーチマップ： https://researchmap.jp/smzn

■参加希望者は、三好副幹事までご連絡ください。後ほどオンライン会議のリンクをお送りいたします。

■参加費用：無料。

　ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（¥1,000）は免除されます。

　

-----

なお、あわせて、研究部会の「PM教育分科会」開催（9月23日午後）のお知らせです。

PM教育分科会では数年前から、紙のカードと模造紙を活用して、プロジェクトの全体像を理解するタイプの研修プログラムを開発してきました。しかしコロナ禍の影響で、顔を合わせたグループ演習が困難な時期が続いたため、オンライン時代に向いた研修方法の検討を行ってきました。

また、あわせてカリキュラム内容も見直し、失敗事例のふりかえり分析を行った上で、新規プロジェクトのリスク・アセスメントを実施するという項目をつけ加えました。

今回、その内覧をかねたトライアル研修を、リアル・ミーティングの形で試行します。

■日時：2021年9月23日（祝）　13:00-16:00

■場所：田町キャンパスイノベーションセンター　オープンスペース

参加を希望される方は、佐藤までご連絡ください。直前のご案内になり恐縮ですが、PM教育にご興味のある方のご来訪をお待ちしております。

佐藤知一＠日揮ホールディングス（株）

『非定型的なデータ』と賢く付き合う法

「吾輩は猫である。名前はまだ無い。どこで生れたかとんと見当がつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している」・・ご存知、夏目漱石の「吾輩は猫である」の冒頭の文章だ。

典型的に、不定形な文章だ。センテンスの長さも不統一。主語もあったり省略されたり。内容も事実なんだか、印象はなんだか判然としない。前回の記事に書いた区別にしたがえば、これは不定型な情報である。

ところでこの文章、15文字ずつ切り揃えたら、どうなるだろうか。

「吾輩は猫である。名前はまだ無い。」

「どこで生れたかとんと見当がつかぬ」

「。何でも薄暗いじめじめした所でニ」

たまたま、センテンスの切れ目に当たることもある。そうでないこともある。だがとにかく、長さだけは定型化・規格化されている。

長さが規格化されていると、機械式処理には好都合だ。つまり、データになる。なんなら末尾に誤り訂正のための符号を付加しても良い。あるいは連番を含む、定型化されたヘッダを最初につけても良い。そうすれば保存や転送に、便利であろう。

実際、わたし達が電話で喋る音声は、こんなふうに処理されている。マイクで拾った音声の強弱は、二値化され、一種のパケットとしてネットワーク間を転送されて、話し相手の受話器に届く。大変立派なデータ処理である。そしてデジタル交換機は、計算機そのものだ。

ハードディスクだって、原理的には同様に処理されている。わたし達がワープロや表計算ソフトで作る電子ファイルは、長さも内容もまちまちだが、符号化され規格化されて、データとして、磁気的な記憶装置に書き込まれる。とても便利だ。

ただしこの便利さには、ちょっとだけ問題がある。わたし達はしょっちゅう、その大事な電子ファイルを、ハードディスクの中から探し出すのに時間を浪費している。一説によればホワイトカラーは、年に150時間くらい、探し物をしていると言う。つまり、ほとんど勤務時間の1割を、探し物に使っていることになる。

ハードディスクは、ワープロ文書や表計算ファイルなどが、雑然と同居した押し入れ状態になりがちだ。私を含めて、多くの人が、フォルダーを切って整理を試みている。だが、なかなからちがあかない。ひどい場合は、二度とアクセスしないゴミ溜め同然になってしまう。

「データレイク」と言う概念がある。データウエアハウスから派生した概念だ。データウェアハウスとは、業務システムのデータベースの内容を逐一、記録・蓄積していく仕組みである。基本的に、一旦格納したら、内部ではデータを変更しない。更新処理もまた、トランザクションの一種として、追記していく。

データレイクと言うのは、データウェアハウスに似ているが、さらにビデオカメラの画像や、音声や、文章や、センサーからの経時的データなど、非定型的なデータをも流し込む蓄積場所を呼ぶ。

え、非定型的なデータ?　それって形容矛盾ではないのか?　前回の記事では、定型化された符号の並びをデータと呼ぶ、と書いていたではないか。

その通りだ。そこで、混乱を避けるために、規格化・定型化には、「低密度な定型化」と「高密度な定型化」の2種類がある、と考えることにしよう。

低密度な（＝ローレベルの）定型化とは何か。

それは冒頭に示した夏目漱石の文章の例のように、インプットを、決まった長さに切りそろえた、符号（ビット）の集合にすることだ（多少のヘッダやチェックディジット等は付加されるかもしれない）。あるいは、不定型な長さだが、境界が明確に指定されている符号（ビット）の集合にする場合もあるだろう。ハードディスクの中のファイルは、その典型だ。

低密度な定型化は、音声や画像、ビデオなど、センサーで拾った外界からの信号を「データ化」し、電子的な蓄積・転送を可能にしてくれた。

「電話」はかつて、アナログの電気通信だった。2台の電話機の間を、微弱な電流が流れて、音声を伝達した。しかしデジタル技術の普及と共に、音声を二値符号のパケットに変換し、ネットワーク通信化した。おかげで雑音に影響されにくくなった（そのかわり、蓄積転送メカニズムのために、少しだけ遅延時間＝レイテンシが長くなった）。

レコードや磁気テープも、昔はアナログの物理的記録だった。それがCDやDATなどでデジタル化され、データ化された。ビデオも同様。ビデオテープからDVDに進化した。複製や転送が、非常に高速にできるようになった。それは新しい、コンテンツ配信産業を生んだ。素晴らしいことだ。

だが、低密度なローレベルの定型化は、私たちが普段オフィスで行う仕事を、どれだけ楽にしてくれただろうか?

前回の記事で触れた、米国の国勢調査を思い出してほしい。5千万枚の手書きの調査票の代わりに、5千万枚のデジカメの写真を受け取ったとしても、せいぜい保管場所が節約できるのと、虫食いで劣化する心配がなくなる程度のものだ。人口集計のためには、人間がいちいち写真を開けて、中の文字や数字を読み取らなければいけない。

低密度な非定型的データは、何といっても、ボリュームが大きい。文字で表せばせいぜい数10 KBで済む調査票だって、デジカメの写真にしたらすぐ数MBになってしまう。資源の浪費である。

もちろん現代のAI技術に裏付けされた、パターン認識や文字読み取り機能などを活用すれば、国勢調査用紙の画像から、文字を抽出することだって可能だろう。そうすれば、紙を読んでキーボードから入力するような、ひどく単調な仕事は機械に任せることができる。ただしそれは、低密度なデータを、高密度な定型的データに転換しているのである。

では、高密度な（ハイレベルの）定型化とは何か。それは情報を分節化し、構造化し、コード化したものだ。音楽という情報を、録音しDVD化したものが、ローレベルな定型化だとすれば、ハイレベルな定型化とは、たとるならば、楽譜にすることである。

高密度な定型化データは、情報の抽象度が高い。それゆえ、検索が速く、正確になる。それも、分節化された情報（属性）単位で検索が可能である。また、そのデータを受け取ったら、機械的な処理が展開可能である。もう一つ、他のデータとつながりが取りやすい。

音楽の例でいうと、楽譜データだったら例えば第二楽章のバイオリンの最初の旋律を検索することも容易だし、電子楽譜を与えれば、自動的に音源を動かして楽曲を再生することだって可能である。DVDの録音データでは、そうはいかない。

あるいは、国勢調査データで、州の欄に”IL"という符号があったら、それは「イリノイ州」を見出しとする台帳データとつなげることができる。データを分節化し、またつなげる（関係づける）ことで、非常に自在な集計や処理を行うことができる。

わたし達のオフィス業務とは、つまるところ情報の処理である。インプットの情報があり、わたし達の頭の中で様々な処理や加工を行い、そして何らかの情報として、他の部署や外の企業に受け渡す。

様々な現場業務だって、相当程度の情報処理を必要とする。医療現場であれ、物流現場であれ、製造現場であれ、目の前の状況を判断し、インプットとなる指示や診断などの情報をもとに、必要な作業を行い、そして大抵の場合は、何らかの記録、伝票あるいは日報をつける。そうしたアウトプットは、また別の部門の仕事のインプットとなる場合が多い。

これを高速に回すためには、情報を電子的な処理に適した形、つまり高密度な定型化データにする必要がある。 今、世間が注目している『デジタル化』とは、組織の情報処理能力を、人間の頭数に依存しない形で、高速化し、スケールアウトすることを目的としている。そのためには、高密度な定型化データが必須なのだ。

前回も説明したように、Excelファイルは、電子ファイルの形をしているが、内容は非定型である場合がほとんどだ。つまり、低密度なデータに過ぎないのである。実際、わたし達が顧客から注文書を受け取る時、ファックスで受け取るのと、メールに添付されたExcelファイルで受け取るのとで、何か大きな違いがあるだろうか。どちらにしても、わたし達が行や欄の見出しから意味を読み取って、受注受付システムか何かに、一つ一つ入力しなくてはいけない。

低密度なデータは、符号（ビット）列で内容を検索する事はできる。しかし符号が指し示すコンテンツ内容の「意味」にしたがって、賢く検索・処理することができない。

・・では、低密度な、非定型的データと賢く付き合うにはどうしたら良いか?

答えは簡単である。非定型的なデータに関するデータ、「メタデータ」を付加することだ。

たとえば図書館を思い出してほしい。書架に並んでいる本は、それぞれが不定型な情報コンテンツだ。ハードディスクに並んでいる電子ファイルと、本質的にはかわりがない。だが、図書館では、蔵書に関する図書カードを作成し、本に関する情報を定型化して書き込み、整理している。図書カードは、紙であって電子化されていないが、立派な定型化データだ。そして本に関するメタデータである。

図書館の価値の半分は、この図書カードにある。そうでなければ、どうやって何万冊もの本の中から、必要なものを探せるだろうか？　

同じように、電子的なコンテンツ・ファイルには、属性を示すメタデータが必要なのだ。5千万枚のデジカメ写真も同様に、メタデータを必要とする。

Windowsをはじめ、たいていのOSは、電子ファイルに対して、最低限の属性データないしメタデータを持っている。例えば、作成したユーザ名、名称、作成日のタイムスタンプ、最終更新のためのスタンプ等だ。そこで、これまでユーザは、ファイル名称に、何らかの定型的なルールを持ち込んで、メタデータ的な属性を情報を何とか表現しようと工夫してきた。

世の中で売っているコンテンツ・マネジメント・システムとか、文書管理システムといったパッケージソフトは、このOSの限界を超えるために、コンテンツファイルに対して、後付けで定型化したメタデータを付与して、検索と整理を助けてくれる。またアクセス権やバージョン履歴、ワークフローなどの機能を提供している。

ただし、データに関するデータ、メタデータの付加には、人間の入力作業が必要だ。そしてしばしばここが、ボトルネックになりやすい。文字認識や画像認識は、少しは助けてくれるが、ユーザの作業を全面的に免除してはくれない。メタデータは、使用する目的に応じて、決める必要があるからだ。AIは、個別のExcelファイルを我々が、「どんな目的で」使おうとしているかまでは、（今のところは）推測できない。

たまたまわたしは、冒頭の夏目漱石の文章を、「青空文庫」の中から見つけてきた。先人の残した書籍コンテンツを、一つひとつ手入力して電子化しているボランティアの努力には、頭が下がる。たしかに、非定型な文章という情報を、電子化することには、それなりに意義があるだろう。

だが、もう一つ価値があるのは、青空文庫が、ちゃんと著者やタイトル等のメタデータを、きちんと整備してくれていることである。メタデータという水先案内がなければ、わたし達は非定型なデータの湖（レイク）で、泥沼に足を取られて、情報過多におぼれるばかりだからである。

＜関連エントリ＞

　 (2021-08-31)

情報の電子化はデジタル化か？

読者諸賢は、『EDP』という言葉をご存知だろうか？　Electronic Data Processingの略だ。電子的データ処理。つまり、コンピュータを使ってデータを処理することを意味する。それって・・当たり前じゃないか。何が新しいの？　ようするにIT＝情報技術のことじゃないの。

左様でござる。3文字略語を大量に消費し続けるIT産業において、EDPという言葉は四半世紀以前に陳腐化し、すでに死語となった。この言葉は、実は1960年代に、メインフレーム（汎用コンピュータ）が世の中に登場した頃、一緒に出てきた概念なのである。メインフレームという呼び方自体、その頃は、なかったはずだ。だって、対比すべきパソコンもオフコンも存在しなかったのだから。いや、コンピュータ自体、皆が「電子計算機」と呼んでいた時代であった、とも聞く。

ところで、EDP＝「電子的データ処理」という言葉は、案外、含蓄が深いんじゃないかと、最近思うようになった。なぜか？　実は、この言葉は、「機械的データ処理」Mechanical Data Processingの対比概念として、（例によってアメリカで）登場してきたと思われるのだ。

機械的データ処理とは、どんなものか。その技術は、米国におけるセンサス（国勢調査）に由来する。

御存知の通り、米国ではあらゆる局面での意思決定において、客観的情報を体系的に収集し、分析した上で決断する、という思考と行動習慣を持っている。彼らは国政を決める際にも、同じアプローチを取る。すなわち、人口調査である。広大な国土をカバーし、開拓民が移動する社会において、彼らは国勢調査を憲法で義務付けた。

第1回は、1790年、つまり米国が独立を達成し、ワシントンが第1代大統領に就任した翌年だった。客観的な数値情報に、彼らがどれだけ重きをおいているか、分かると思う。そして以来、10年ごとに実施してきている。

当時は、紙とペンの時代である。独立時の米国の人口は、約400万人だった。集計作業がいかに大変だったか、想像に難くない。でも彼らは、それを必要な作業と考え、続けていった。センサスを開始してから100年後、19世紀末には、米国の人口は5千万人に達する。

5千万レコードの集計を、手作業かよ。皆さんはそう思われただろう。そのとおり。だから、ここで重要な技術革新が現れる。その立役者は、Herman Hollerith（ハーマン・ホレリス）という技術者だった。彼は、その少し前に、フランスの発明家Jacquard（ジャカール）が作った、ジャカード織機という機械にヒントを得て、「パンチカード」を考案する。

（参考：小暮仁「パンチカードシステムの歴史」 にホレリスの穿孔機やタビュレーターの写真がのっている）

ホレリスのパンチカードは、サイズがドル紙幣と同じだった。そして、そこに、英数字に対応する、12個の穴の位置をコード化した。この文字コードを、ホレリス・コードと呼ぶ。彼がパンチカードの文字の桁数を80桁と決めたので、以来、コンピュータの画面も長らく、横が80文字が標準だった。

そして彼は、パンチカードの穴の位置を機械的に検出する仕組みを持つ、リレー方式の電動作表機械（タビュレーター）を製作する。この機械にパンチカードを束にしてかけると、集計表ができるのである。これこそまさに、「機械式データ処理」だった。ホレリスのタビュレーターは、それまで7年かかった国勢調査の集計を、3年間に短縮した。まさにイノベーションである。

ちなみにホレリスは国勢調査職員だったが、数年後に会社を設立する。パンチカード・システムの有用性を、民間企業も認識し、ビジネスチャンスが広がったからだ。彼の会社はその後、タイムカードの会社などと合併し、1911年に「国際事務機会社」International Business Machineという社名になる。これがIBMである。

IBMは、電子計算機なるものが登場する前は、機械式データ処理マシンの最大手だったのだ。

技術者ホレリスの名前は後の時代にも、FORTRAN言語のH変換などに残った。初期のFORTRANでは、英文字の印刷出力に、11HHELLO WORLDなどと指定していた。11という桁数のあとのHが、ホレリス変換を意味する。

（ちなみに余計な話だが、ホレリスは国勢調査局と関係がこじれ、政府側はパワーズという技術者に、印刷機能付きのタビュレーターを開発させる。パワーズも後にすかさず会社を設立し、レミントンランド社に吸収されたりして、のちのUNISYS社になる）

文字コード、カードサイズ、穿孔機、集計機ーーここまで定型化されているので、ある意味、機械的処理を電子化していくのは、単に技術とコストだけの問題だった。UNISYS社は1951年、UNIVAC 1という世界初の商用電子計算機を発売する。1台で、100万ドル。もちろん最初の顧客は、国勢調査局である。

これが、電子的データ処理＝EDP産業の、始まりだった。

さて。わたしは以前（と、いっても11年も前の話だが）、「『ＩＴって、何？』質問2：　ＩＴを理解している人を見分けるにはどうしたらいいの？」 という記事の中で、データと情報の違いについて、説明した。簡単にまとめると、次のようになる。

「情報」：人間にとって意味をもたらすもの

「データ」：数字や文字の規格化・定型化された並び

念のため、JISの定義では、情報とは「事実、事象、事物、過程、着想等の対象物に関して知り得た事であって、概念を含み、一定の文脈中で特定の意味を持つもの」であり、データは「情報の表現であって、伝達解釈又は処理に適するように形式化され、再度情報として解釈できるもの」（データに対する処理は人間が行っても良いし、自動的手段で行っても良い）となっている。だから上記の定義は、ある意味、世の中の標準的な定義である。

そして、IT＝情報技術とは、この「情報」と「データ」の間のサイクルを回す技術なのだ。ちょうど、ホレリスのパンチカードが、調査で入手した情報を定型化してデータ化し、機械的に処理し、結果を集計表という人間に理解可能な形に表示することで、人間に意味をもたらしているように。

図を見てほしい。上側は、人間の仕事の世界である。そこでは情報が取り扱われる。ただし、情報はそのままでは、大量・高速な処理や、検索に向かない。人間は、これを定型化することで、機械が処理しやすい形に入力する。つまりデータ化する訳である。

下側は機械の仕事の領域で、人間から受け取ったデータを処理し、蓄積・転送・検索・計算などを行う。そして、結果を、人間に理解できるよう出力する。出てきた出力は、人間が意味を汲み取って、さらなる仕事に役立てる。

このサイクルでボトルネックになりやすいのは、人間による情報のデータ化の部分だ。キーボードからの入力もかったるい作業だが、とくに、「定型化」の部分が問題になる。ここの意識が、わたし達の社会では特に、弱いのである。

たとえば、手書きのメモがある。これを、スマホのカメラで撮って、写真アプリに保存すれば、それは「電子データ」になったと考える人が、世の中には非常に多い。では仮に、ホレリスの時代にデジカメがあったとして、5000万件の国勢調査ヒアリング用紙を、5000万枚の電子的な写真データにしたら、彼の集計の仕事は助かっただろうか？　そんなことはあるまい。

記録媒体が紙から、どこぞの電子媒体になったとしても、それは決して、IT的な意味での「データ」にはならないのである。なぜか。IT的な意味でのデータとは、

・機械的に到達（検索）可能であり、

・それをインプットとして、機械的な処理や判断が可能なもの

を指すからだ。

そういう意味で、Excelの表の上の数字だって、データかどうかは微妙である。複数のシートに渡って、何かを集計しようと思ったときのことを考えればいい。表がきちんと形式化されていれば、同じ$B$56といったセル位置をたどって、合計することができる。だが、ほとんどの表は、人間が、列や行の見出しを読まないと、欲しい値の位置がわからないのだ。

あるいは、CAD図面などもそうだ。図面の右側に、よくNote欄があって、いろいろな設計技術者の注釈が書いてある。あれは、たしかにCADサーバのどこかに、電子的に保管されている。しかし、"No pocket"などといった記述をコンピュータが読み取って、それで具体的に何か処理できるだろうか？　おそらく、できまい。だとしたら、少なくともこの部分は、読み手の人間にとっては情報であるが、計算機にとってデータではないのだ。

わたし達の社会には、おかしな誤解が蔓延している。情報を電子化したら、それはデジタル化だと思っている。まあ、たしかに2 bitの組合せで内部表現されているから、ミクロにはデジタルかもしれない。しかし、DXなる流行語を皆が語る今日、目指しているのは、仕事に役立つような「データ化」であろう。そのためには、定型化とか、標準化とか、はっきりいって日本企業がすごく不得意な作業が、必須なのである。

そしてまた、データとは数値的・客観的なもの、という理解（誤解?）も、蔓延している。データに基づく経営、とか。じゃあ情報に基づく経営は、定性的・主観的なのだろうか？　話している人は、そういうつもりではないのだ。おそらく経営判断は、個人の主観や印象によるのではなく、客観的・数値的な情報に基づいて行うべきだ、と言いたいのだろう。

そう。それならば、たしかに同意できる。18世紀末のアメリカ人たちも、そう信じていた。そして彼らは、とてもプラクティカルな人々だった。だからこそ彼らは、機械的データ処理を通じて、新しい巨大な産業と文明を生み出せたのである。

＜参考エントリ＞

　→「データと情報はこう違う」 (2012-07-24)

　→「『ＩＴって、何？』質問2：　ＩＴを理解している人を見分けるにはどうしたらいいの？ 」(2010-10-07)