上司交代

（よみうりランドジュエルミネーション・噴水ショーより　　　　12月19日撮影）

 

　山梨工場勤務から1年ほどで上司の課長が交代となりました。新しい課長は購買部門内ではなく、他部門からでした。

　このため、購買業務の手続きについては、私が教える立場となりました。もっとも、新しい上司は室伏さんと言いましたが、この室伏さん、私の社会人人生では、仕事上の先生の一人として、尊敬する存在となりました。

　上司は、元は設計部門に所属し、見積業務を担当していました。ここで言う見積とは、製品の原価を算定する業務をさしています。会社としての利益計画の基となる原価を算定する重要な業務です。
　部品費や組立費用などを集計することで、一つの製品の原価が計算されることになります。このため、購買部門と見積部門は仕事上の繋がりがあり、見積部門からは部品単価の問合せがありますし、購買部門も新規の購入部品については、事前に見積部門に予定価格を聞いておいて価格交渉の参考にもします。交渉で予定価格を下回れない場合は、見積部門の承認が必要にもなりました。

　本社の資材部にいた時に当時の室伏さんとのやり取りが多かったのですが、特に、「原価低減プロジェクト」が出来、二人がそのメンバーに入った時には原価算定の方法など詳しく教えていただきました。
　すでにご紹介の生産管理マニュアルにも「原価管理」の説明がありますが、この内容のかなりの部分は、この時の室伏さんからの教育の結果でもあるわけです。

　それと、上司になってから教えられたことは「仕事は誠実に！」ということです。
　上司と部下としての山梨工場での直接の関係は、結果として1年だけだったのですが、その間に忘れられないことが一つあるのです。それは外注との関係でした。

　ある外注からの納入部品に不良が発生したのです。組立時にその部品が割れるという不良です。しかし、納入部品を図面と照合すると図面の指示どおりです。したがって、図面上は不良ではないのです。
　このため、外注より再納入させ、テストしてみましたが、やはり組立で割れてしまったのです。
　こうなると、外注は力関係でどうしても、不利になります。社内の各部門からは購買に圧力がかかります。「外注先」の変更要求があったのです。私もしかたがないと思っていました。
　しかし、新上司の対応は違っていました。「図面どおり出来ているので不良ではない」と突っぱねたのです。これも、後のテストで分かったことですが、図面指定の材料に問題があったのです。材料変更で問題は解決したのです。
　さらに、上司は社内稟議を書いて、不良となった部品代も外注での在庫分も含めて買い取る処理をしたのです。
　今の時代なら、下請法の厳しく適用される事案ですが、もう40年近い昔のこと、まだまだ下請けいじめが当たり前の時代でしたから、他の上司なら、なあなあで済ませてしまった事案だった気がします。

　「誠実な仕事」、その後の私はそうできたかは甚だ疑問ですが、何か問題があると、同じような事案ではなくてもこのことを思い出すようにしていました。

 

　

（おわり）

 

 

コンピュータ学習3

（よみうりランドジュエルミネーション・噴水ショーより　　　　12月19日撮影）

 

　システム作りのためのコンピュータ室通いが半年ほど続きました。
　当然毎日、一日中ということではありませんし、それなりのシステムで、しかも全くの初心者ですから時間がかかったのは当然です。

　時間はかかりましたが、一番良かったことは、単なるプログラミングの勉強というのではなく、システムの構想から、プログラミング、テスト、結果の検証と一貫したシステムの作成方法を勉強できたことです。
　事実、この後、コンピュータを利用した多くのシステム作りにかかわることになりますが、プログラミングをしたのは唯一この時だけでした。それと、プログラミングといっても、標準言語を勉強したわけではなく、ホストコンピュータに付属する簡易言語を利用したもので、汎用性のあるものではなかったのです。

　ただ、このコンピュータ学習は、私の仕事の原点になることとなりました。

　プログラミングもまともにできないのに、いつの間にか、「あいつはコンピュータに詳しいらしい」との評価になっていたのです。おそらく、システム完成から半年ほどの時に、社内の事務合理化の特別表彰があり、その最優秀賞を貰ったことが要因かと思います。
　先にお話ししたように、山梨での2年間の業務の後、購買部門を離れることになりますが、その後は、問題をかかえる部門の修繕屋役とでも言うことか、他部門に転籍となることとなりました。それも、この時のコンピュータ学習が元となったものです。
　そして、その後、IT企業に転職することになりますが、その原点もここにあったことになります。

　ところで、完成したシステムはどうなったかというと、結果的には本格的な利用は出来ませんでした。出来たのは一覧表ですから、カードの代用とするのは運用が難しかったのです。ただ、一覧表ですから、単価を調べる時など、カードを探すより、手元の置いて確認が出来るため、補助資料として活用することになりました。
　本来的には、オンラインの画面検索・ワークフローシステムが必要ですが、当時は端末が個人どころか、部門にもない時代でした。データ処理も紙テープ、プログラミング結果も紙テープに打ち込んでいた時代ですから、一覧表を出すのが精いっぱいでした。

　それでも、半年間はとても楽しかったです。夏休みには毎日会社に出かけていました。盆地で蒸し暑い山梨、冷房の効いたコンピュータ室は快適でした。山梨の2年間で一番の思い出かもしれません。

 

 

（コンピュータ学習：終わり）

 

 

 

　

 

 

コンピュータ学習2

（よみうりランドジュエルミネーション・噴水ショーより　　　　12月19日撮影）

 

　山梨工場赴任当時は時別な担当もなかったため、まずはこの伝票処理の混乱のコントロールの担当を自発的に始めました。そんなわけで、コンピュータ室への出入りも多くなり、情報管理部門の担当者とも自然に親しくなりました。

　そんな折、情報管理部門の責任者から、プログラムの勉強を勧められたのです。コンピュータには全く興味がなかったのですが、基礎を知ったら、事務の合理化にも多少役立つのではとのことで、コンピュータ学習がスタートすることとなりました。

　その学習法ですが、コンピュータの仕組みやプログラミング言語を学習するというより、具体的な業務システムを作ってみる、という方法をとりました。そこで、対象を「単価カード」のシステム化としました。

　単価カードとは購入品目ごとの購入単価の来歴が記入された帳票のことです。特定の品目を発注する都度、そのカードに発注単価と数量、発注先を手書き記入して来歴を管理しているものです。

　このカードは、購買部門にとっては非常に大事な帳票ですが、管理の手間も大変です。
　その手順は次のとおりです。

• 購買の依頼が購入依頼部門から「購買依頼票」として来ると、その依頼票の品目番号を見て、単価カードの保存されている引出しから、その品目のカードを取り出します。
• カードにある過去の発注先と単価を見て、前回どおりの条件で妥当か判断して、依頼票に単価と発注先を記入します。（通常、「前値参照」と言って前回と同一条件で処理します。）
• 上司の決裁を受けた伝票と単価カードが戻ってきますので、伝教はコンピュータ処理に回し、単価カードは元の引出しに戻します。戻す時に、次回取り出すとき困らないように、品目番号順になるように注意して戻します。

　以上の手順です。

　この単価カードのコンピュータ化、つまりは品目ごとの来歴（価格、発注先、発注日、数量など）を管理するシステムを作ろう、というわけです。

　そこで、システム化の概要を以下のとおり構想しました。

　① 利用するデータ：過去の発注データの累積ファイル

　② ①より、品目をキーとして、必要データを抽出しファイルを作る

　③ ②のファイルより、単価履歴の一覧表をプリントする。
  （今なら画面検索のシステムを作ることになるのですが、当時はまだ端末が事務所にはない時代だったため、最終的にはプリントアウトして見るしか方法がなかったのです。）

　そして、いよいよシステム作りがスタートしました。

 

（「コンピュータ学習」つづく）

 

 

 

 

 

 

山梨工場時代：コンピュータ学習1

（神代植物公園の大温室にて　　　　8月22日撮影）

 

 

　調達部門で重要な仕事の事務処理があります。いかに安く、必要な時に、必要な品質の物を購入するかが調達部門の仕事ですが、そのためには、まずは注文を取引先に伝える必要があります。

　急ぐ時はまずは電話注文ですが、通常は注文伝票を取引先に郵送などで届けることで行われます。そのための事務処理が注文伝票の作成事務です。そのためには、コンピュータでの処理が必要になるというわけです。

　私の会社では、私が入社した1970年初頭頃から、このコンピュータによる注文伝票の作成処理がスタートしたばかりでした。今のように、個々人にパソコンがある時代ではありません。コンピュータ部門にあった大型のコンピュータで注文伝票の作成処理するのですが、次のような手順で行われていました。

①まずは、担当者がコンピュータ処理するための元伝票を上司の承認を得て作成します。

②その伝教の内容をパンチャーがデータ入力します。その結果データ入力結果の紙テープが作成されます。（紙テープ？、何それ？でしょうが、当時はデータは紙テープに穴をあけて作成していたのです。）

③入力結果の紙テープをコンピュータ室に持っていって、データの読み取り処理します。その結果、入力規則に沿わないデータはエラーリストが出力されます。

④そのエラーリストを見て、元の紙テープの入力ミス部分を探して、紙テープを補修、正しいデータを再パンチします。そして、再びコンピュータ室でデータの読み取り処理をします。

⑤データが正常に読み取られると、注文データの処理結果の一覧表が担当者ごとに出力されます。

⑥その一覧表を担当者が元伝票と照合して、入力ミスが無いか（特に、注文品名、納期、数量、単価）をチェックします。その結果、入力ミスがあると、その内容を一覧表に記入、パンチャーに届けます。

⑦パンチャーは入力ミス内容を確認、紙テープのミス部分を探して、修正パンチします。

⑧担当分全部の修正が終わると、再びコンピュータ室で、紙テープの読み取り処理をし、注文データの処理結果の一覧表が再出力されます。

⑨最後にコンピュータ担当の責任者が、修正依頼の元一覧と再処理一覧を照合し、正しく修正されたことを確認し、コンピュータ室に正規の発注処理の依頼をします。

⑩以上の結果、やっと注文書が作成されます。

 

　と、まあ、大変な事務処理が当時は行われていたのです。今はどうかというと、定期的に注文される通常品は、内部での確認作業はありますが、ほぼ自動で取引先にWeb対応で行われています。

　調達部門での事務処理はもう一つあって、それは、購入結果により支払いの元データを作成する作業です。専門用語では「検収処理」と言います。
　検収処理は、検査合格結果により納入伝票が、調達部門に届くため、それを発注処理と同じようにデータ作成して、コンピュータ処理することになります。

　

　と、だいぶ長くなりました。タイトルの「コンピュータ学習」の話までたどり着いていませんが、本日はここまでとします。

 

（「コンピュータ学習」つづく）

 

 

 

山梨工場時代：山梨工場調度課

（神代植物公園の大温室にて　　　　8月22日撮影）

 

 

　出勤日は覚えていませんが、1976年の10月上旬に山梨工場調度課に初出勤しました。

　4年半の社会人経験がありますから、新入社員のようなドキドキの初出勤ではなかったと思います。残念ながらその日のことは何も覚えていません。
　それと、転勤といっても、全く何も知らないところに転勤したわけではなかったからだと思います。というのも、同じ調達部門ということで、同課には定期的に打合せに行っていて、課長をはじめ主だった人とは顔なじみだったからだと思います。

　詳しくは覚えていませんが、課員は安田課長をはじめ10名ほどでした。思いだせるのは男性が6名（安田課長、土屋、三枝、川手、沢田、私）女性５名（竹内、名取、名取、岩間、？）でした。それと、詳しく思い出せないですが、2，3年前から始まった注文伝票のコンピュータ処理のための、データ入力のパンチャーの女性が別に数名いた気がします。

　私の担当は当面特にありませんでした。当時起こっていたトラブル内容は覚えていませんが、ともかく問題点の発見とその対策が私の任務ということでの赴任したので、課長の補佐的な仕事でした。
　安田課長とは、本社時代に、課長が別工場の調度課の担当で仕事上のやり取りがあって、馴染があり、「自由にやっていいから」と任せていてくれました。

　ということで、赴任当時は調度課での皆さんの仕事の内容をざっと覚えることに努めたのですが、見えてきたのは、データ入力の際の入力ミスのトラブルでした。それと、加工外注といって、図面にもとづいて外部の業者に部品を発注する業務で、品質不良などのトラブルが多いことでした。

　そんなこともあって、まずはこれらの問題に手を付けることとしました。

 

本日はここまでです。次回はコンピュータのお話です。