今度連絡しますから31
＜書き始めて＞ユーザーズマニュアルは四種類。パートプログラム作成マニュアル、工作機械のロジック制御(通称内臓PLC)作成マニュアル、工作機械とCNCの結合説明書に保守説明書。合計ページ数が四千ページは軽く超える。書かなければならない内容は、確認しなければならないにしてもわかっている。ページ数が多いだけの力仕事だと高をくくっていた。自分で書くのなら、なんということでもないことが、チームでとなると話が違う。書き始めるまでそこに気がつかなかった。
いつ抜けられるか心配だったが、片岡も蔦谷も抱えていた仕事を簡単に放り投げてきた。宮本は予想に反して、なかなか抜けれらなかったが、当分先になるだろうと思っていた檜山が一番先にきた。
去年入った檜山は専攻は機械工学だったから、工作機械がなんなのかぐらいはわかっている。基礎がないわけではないが、あるといえるほどのものでもなし、ましてやCNCの知識は入社時に表面的な話を聞いたことがあるだけだった。もっとも将来を嘱望されていた一人で、檜山になら片岡も蔦谷も教える労をいとまない。そうはいっても二人が合流してくる一週間のうちに、できるだけ檜山にCNCの概略を理解してもらっておいたほうがいい。
日本製のCNCは散々使ってきたが、自社のCNCは使ったことがない。基本は同じなのに、使い勝手は日本のものとかなり違う。日本のものなら、装置を目の前にすれば、マニュアルなど見ることもなく使えるが、自社のとなるとマニュアルを見ながら一つひとつ機能を確認するかのような使い方しかできない。そんなのがトレーナーでは、あまりに効率が悪い。
「村田さん、ごめん、忙しいところ申し訳ないんだけど、うちのCNCの使い方をざっと教えてもらえないかな。マニュアル読めばいいんだけど、一つひとつ読んで実行してたんじゃ時間ばっかりくって……」
村田の日程をあらかじめ事務の女性とジョンソンに確認してから頼んだ。誰でもそうだろうが、手に余る仕事をかかえて四苦八苦しているところに雑用のようなことを頼まれると、普段ならなんでもなく受けてくれる人でも無碍もなく断ってくる。同じ人なのに状況しだいで別人のようになる。目的達成のためには押し切らなければならないこともあるが、人の協力が得られなければ先に進まないことが多い。協力を得るためには、協力しえるときに、無理しなくても協力できることまでに抑えて、その上で相手の自尊心をくすぐればいい。そうすれば、たとえ渋い顔をしても受けてくれる。
「えー、また何、あんな古い機種の使い方なんか、いまさら、なんで」
十年以上前にリリースしたCNCで、輸入機に付いてきたものの修理依頼はあっても、日本では売れたことがない。何かあったら村田か宮本に任せればいいしで、誰もいまさら勉強しようなどとは思わない。そんな古いものでも、CNCとは何ぞやということと基本的な機能を知るのが目的なら十分使える。
「ほら、こんどチームでアルファのマニュアル書かなきゃなんないんだけど、オレも檜山もうちのCNCを知らないからさ」
「でも日本のCNCとは違うよ」
「うん、でも座標系やGコード体系は一応国際標準もあるし、Mコードも似たようなもんだし、Sコードだって同じでしょう。カスタムマクロはちょっと違うかな。でもピッチエラー補正なんか、基本はどれも同じじゃない」
「まあ、そういわれれば……」
「忙しいところ悪いんだけど、檜山と二人でいじり回して自習できるところまで、案内してくんないかな」
「片岡さんかツタやんに頼めばいいんだけど、二人とも引継ぎで手をあけられないし。宮本さんって手もあるんだけど、どうせ教えてもらうなら、やっぱり村田さんからが一番だから……」
何をいまさらという顔だったのが、まんざらでもない顔になって、机の引き出しをあけて資料を探し始めた。
「じゃあ、オレ先にラボにいって、CNCの電源入れて様子をみてみるから」
自分ではなんでもやれるのに、人に教えるとなると要を得ない人がいる。村田はその典型で、無口でもないし偏屈でもない、親切ないい人なんだが、しばし聞いたことをこっちの言い方で訊き返して確認しないと、何を言っているのかわからないことがある。
CNCはちゃんと動いている。村田の机に戻ったら、時の経過を感じさせる資料を出して待っていた。それは、村田が自分の整理のためにつくった操作虎の巻のような資料とサーボシステムの概要を説明した資料だった。表紙は痛んでいるし、紙も黄ばんでいる。どうみても四、五年ではない。もっと前の資料にしか見えない。こんな簡便な資料があったとは知らなかった。
「なによ、村田さん、こんないい資料があったんだ」
冗談としか聞こえない口調で言った。
「まったく、こんないい資料があるなら、早くだしてくれればいいのに。もったいなからって隠してたんじゃないの……」
当たらずとも遠からずなのだろう。ちょっときまり悪そうな顔をして笑っていた。その気持ちもわかる。いくつもの英語の資料をひっくり返しながら、操作に必要なところだけを書き出して整理したもので、それは村田の資産といっていい。でも、みんなが村田がしたようにゼロから始めたら、とんでもない時間がかかるし、ほとんどの人は村田のレベルに到達しえない。個人の資産と鷹揚に次の人に渡せば、前任者が到達したあたりから、次の人がスタートして、前任者が到達したとろを超えていける。個人の資産を寛容に分け与える文化のない組織は成長できない。
あまりの資料に檜山も驚いて、二人で、ついでだからと五人分のコピーをとった。
ラボにいって、コピーを片手に、装置を前にして村田の説明を聞いていった。自分ではわかりすぎるほどわかってる。ちょっと話してはポンポンポンとキーを押して、とてもついていけない。
「村田さん、ちょっと待って」
一瞬何を言われたのかわからない顔をしたが、すぐにわかったのだろう。
「ごめんごめん、そうだよな。オレが操作してもしょうがないんだよな」
「じゃあ、こうしようか。オレが説明して、檜山が操作する。もしわからないことがあったら、操作の前でも後でもかまわないから訊いてくれれば……」
そこは村田、資料を見ながら話を聞いてもピンとこないことが多い。それでもたぶんこういうことだろうと、操作すればCNCは動く。動かなければ、あれっ、こうかもしれないと、ちょっと違う操作を二度三度すれば動く。動けば、こういう説明だったのかとわかる。CNCが村田の説明を補ってくれた。
操作してわかるものは簡単で、問題はその操作がどういう処理をされているのかにある。それを知るには資料を見ながらの説明しかない。檜山と二人で村田の話を聞きながら、コピーした資料に書き込みをしていった。大まかわかってしまえば、あとは独習でいけるところまでいけばいい。そこで出てきた質問を整理して村田に確認してを繰り返した。二人で資料を見ながら、ああだのこうだのいいながらCNCを三日も弄り回して、まあこんなところだろうというところまできた。後はその都度、三人の誰かに訊けばいい。
マニュアルは小説ではない。プロダクトマーケティングがソフトウェアエンジニアリングに発行した開発要求仕様書(Product Development Request、略してPDR)とそれに対するソフトウェアエンジニアリングがマーケティングの承認を求めるために発行した開発仕様確認書(Functional Spec、略してFS)を基に書き上げる。PDRもFSも、当然の話だが、開発者の視点で書かれている。それをCNCを使う側の視点でユーザーズマニュアルを書かなければならない。
PDFとFSの記述にあれっと思いながらマニュアルの章どりをはじめた。これを説明するには、あれが説明されていなければならない。あれを説明するにはこれが……。大きなポストイットに書かれなければならない表題を書いて、その下で説明することを別のポストイットに書いて、節から章、その内訳へとポストイットに書いては会議室の壁に貼っていった。四人でああだのこうだの言いながら、こっちのポストイットをあっちの章に貼り替えて、追加がでてくれば書いて貼ってを繰り返して大まかな章どりを決めていった。大まかにしかできないが、大まかでいい。いくら几帳面に決めたところで、書いている途中で、これを説明するには、あれが説明されていなければということがでてくる。
章どりが大まかに決まったところで、四人で作業を分担して図と表も作成しながらマニュアルの本文を書き始めて、とんでもないことに気が付いた。PDFもFSも正式書類の体はなしているが、マニュアルを書きはじめたら、内容がはっきりしない、明らかに間違っている、機能が足りない、なんだか分からない機能がある。このままPDFとFSに忠実に従ってマニュアルを書き上げたとしても、製品としては使い物にならない。
マニュアルを書くより、PDFとFSに書かれている内容の確認が主な作業になってしまった。それこそ一ページにいくつも怪しい記述がある。あまりに確認しなければならないことが多すぎて、マニュアル作成どころではなくなった。片岡がいらいらして言い出した。
「藤澤さん、こんなPDFとFSからじゃマニュアルなんか書けっこないですよ。どっちもなにいっているのかわからないし、こんなんで開発したら、まともなCNCなんかできっこない。もう、マニュアルって話じゃなくて、開発をどうするかってことですよ。どうすんですか」
片岡に言われて、自分のなかで、何をいまさらと思った。そんなこと始める前からわかってたことじゃないか。なんの説明もしないでチームを作って、みんなに申し訳なかった。でも、書かないわけにはいかない。ちょっと考えて思い切って提案した。
「みんなが言っていることはわかる。でも計画通り製品が出来上がってくるという前提で、マニュアルはマニュアルで進めなきゃならない。書けないと放り出すわけにもいかないし……。そこでだ、CNCはこういうもんだという視点でマニュアルを書いちゃおう」
そんな馬鹿なというのか、乱暴な話はないだろうとみんな唖然としていた。あまりのことに誰もなにも言わない。
「みんな知ってるだろうけど、PDFを書いたのは村田さんで、それをオレが英語に訳した。日本語から直訳したらとてもじゃないけど意味が通らない。で、やりすぎを承知で意訳した。仕様書だから簡潔な英語で書かれている。その英語を基に、CNCはこうでなきゃならないってマニュアルを書いちゃおう」
三人とも、そんなのありかよって顔をしていた。
「みんな知ってると思うけど、今その英語の翻訳を基にソフトウェアエンジニアリングにPDFの変更を出し続けてる。そんなものって連中は大騒ぎしているけど、開発しなけりゃならない仕様は翻訳に書いてある。それに合わせるようにしてるから、そっちからマニュアルを書き起こそう。心配しなくていい。責任はオレがとる」
檜山に手伝ってもらって翻訳をコピーした。英文を一目みて、みんな英文というだけで腰が引けてる。外資にいると多かれ少なかれ英文アレルギーになってしまう。でもその英文はこっちが書いた英文で、日本人にはわかりやすい。
「英文からなんてって思ってんだろうけど、ちょっと読んでみてくれないかな。アメリカ人の英語じゃない。オレの英語だから構文は簡単だし、とっつきにくいにしてもすぐ慣れるから……」
三人が黙って読み始めて、面食らっていたのが、自信というほどでもないにしても、これならなんとか読めると思い出したのだろう、さっきまでとは顔つきが違う。
英語ではあっても、わけのわからないPDFはFSよりはるかに扱いやすいのに気がついて、これなら書けると誰もが思いだした。蔦谷が言った。
「なんだよ、藤澤さん。こんなのあるんなら最初からこっちをだしてくればいいじゃないの。これと章どりを比べて、さっさと始めようや。みんなでやれば、なんとでもなるって」
何かあるたびに、片岡と蔦谷が確認をしていた。そこに時たま宮本が顔をだして、四人で世間話のような丁々発止になった。これはCNCに限らずPLCでも他の製品でも日常的に起きていたが、用語の統一にはことのほか時間がかかった。日常の業務では、統一なんかなくても、お互いに何を言っているのかわかっているから問題にはならないが、正式書類のマニュアルでは、社としての統一をとらなければならない。後ろで聞いていた檜山は、最初何が違って何を言い合っているのか見当がつかないでいた。
技術の実務部隊は同業他社や客の立場の企業からの転職組で、前職で得た経験と、業務を通して得た知識を持ちこんでいた。それを期待されての採用なのだが、残念ながら、培った個別の知識を汎用の知識に昇華するまでの能力はない。同業各社で、似たような技術基盤の上で似たような製品を扱ってきたのだから、共通の技術基盤で共通の言葉で知識を共有できると誰しも思う。ところが各社各様に歴史もあれば技術開発の経緯も違う。汎用化するには個々の独自知識を体得するのに必要な能力とは違う能力が要求される。個々の知識を融合して共通理解を作る難しさは遭遇した人でないと分からない。企業合併の度に似たようなことが起きていると思うが、企業の内部のことで、なかなか外部には漏れ聞こえてこない。
日本企業同士でも言葉の違いなどから意思の疎通に齟齬をきたす。そこにアメリカの技術用語が横たわっているから達が悪い。同じことにいくつもの用語が飛び交う。それでも日本語と英語が一対一で対応していればまだいい。日本のメーカのこの機能は自社製品では、この機能とあの機能のこの部分をこういうふうに設定して、この部分をこう使えばいいというのもあれば、日本のメーカのこの機能は、あの機能の一部を使えば十分というのもある。
歴史なのか文化なのか、それとも、ただ地理的に近いからなのか分からないが、日本企業の製品はどれもこれも似たような、穿った見方をすればお互いに真似でもしあっているのではというほど似ている。それにひきかえ、アメリカの製品もヨーロッパの製品も、しばし匂い立つような個性がある。わが社のこれというコンセプトというのか主張がある。使い方次第では日本の製品より優れた能力を持っているのだが、それは使い方を熟知しての話で、似たような製品に慣れ親しんできた日本の技術屋には難しい。
技術の実務部隊の人たちは、それぞれ持ち寄った各社各様の言い方で言っても、その時々の話の流れから、相手が何を言っているのかほぼ間違いなく見当がつく。言葉がいい加減であっても、勘違いすることはまずないが、そばで聞いている商社上がりの部課長連中や新卒には分からない。
CNC(Computerized Numerical Controller)の原点復帰は、用語の不統一が招く混乱のいい例だろう。電源投入後、一般的には工作機械の全ての制御軸を「機械原点」に移動する。電源を入れただけでは、制御装置は制御軸がどこにあろうが、あったところを機械原点と判断する。判断するのはいいが、それでは、それぞれの制御軸が機械的にどこにあるのか分からない。
いい比喩が見つからないのだが、次のように考えれば分かりやすいかもしれない。朝起きて、東京駅を起点として作成された新幹線の運行システムの電源を入れたとしよう。品川駅の車庫に入っている車両を一度東京駅まで戻して、ここが運行の起点(機械原点)であることを運行システムに教えないと、システムは品川駅にある車両が東京駅にあるものとして稼動し始める。品川駅を東京駅と理解して、車両は東京駅から品川駅に向かっているつもりで品川駅から新横浜駅に向かうことになる。
システムに機械原点を教える作業を、日本では次の言葉で表している。1）原点復帰(機械屋の言葉)、2）ゼロリターン(機械屋の言葉)、3)リファレンス点復帰(制御屋の言葉)。アメリカでは一般に「機械原点」をHomeと呼んで、そこに制御軸を移動することをHomingと呼んでいる。なかにはHomeをOriginと呼ぶメーカもある。
これだけでも知らない人が混乱するには十分なのに、原点には少なくとも二種類あるから性質が悪い。「機械原点」と加工プログラムを作成する際に設定する座標系のゼロ点――「プログラム原点」がある。加工プログラムによっては、その「プログラム原点」をいくつも設定することすらある。一つのことがいくつもの言葉で言い表され、どれもが話の視点や使い方で違う。技術に興味のない、あるいは技術的なことに対して当事者意識のない人たちは、言葉として聞いたことがあるというまでで終わる。言葉として知っているだけで、それが何を意味しているのか説明できるまでの理解には至らない。
片岡と蔦谷の言い合いは、典型的な親しい男同士の会話で、知らない人が聞いたら、喧嘩でもしているようにしか聞こえない。 それを毎日聞きながら、檜山がCNCのなんたるかを拾っていった。宮本が二ヶ月も遅れてきたときには、もう檜山も混じって四人で言い合っていっていた。
チームは機能し始めたが、問題はあいもかわらず転がり込んでくるクレーム処理だった。アプリケーションエンジニアリングには貴重な戦力を借りている負い目がある。占有した会議室にはいても、マニュアルから離れてクレーム処理をしていることが多かった。文体や用語の統一さえできてしまえば、細かなことに口を出さずにチームの自立性に任せてしまったほうがいい。
片岡と蔦谷がちょっとしたことで競り合いになったとき、檜山の存在がバッファーになってくれた。チームリーダーからの圧力より後輩に見られている、後輩を指導しなければという気持ちが二人をいい意味で抑えていた。
傍からみれば男同士の遠慮のない馬鹿話をしているように見えたのだろう。ソフトウェアエンジニアの何人かは質問といいながら来だしたと思ったら、お前の席はあっちだといいたくなるほど頻繁に来た。片岡と蔦谷が冗談半分に、
「お前、Functional Specに何か書いてんだ。いくら読んだって、あんなものわかりっこないじゃねぇか。お前たちのだらしのないFunctional Specのせいでオレたちが苦労してんの、わかってんのか。今度焼肉屋でビール三本だな」
同期の檜山が笑って聞いていたら、
「おい、檜山、同期のよしみだ、ちょっと指導してやれ」
原田さんは、当初チームとして成り立つのか心配して頻繁に顔をだしてくれた。書式も用語も決まって作業が軌道に乗り出してからも、毎日のようにコーヒー片手に来てくれた。日本的な煩雑な作業に疲れて気分転換もあってのことだったろう。いくらもたたないうちに、とりとめのない世間話のなかに、それまでとは違う気持ちがあることに片岡と蔦谷も気がついた。居酒屋で聞いた「このチームに村田さんが入ってないことが……。もったいないな、せっかくの機会なのに」の「村田」が「原田」に代わっていた。チャレンジという希望が心配を生んで、心配が杞憂だったことがはっきりしたとたん、チャレンジの当事者になりえない自分をどうしたものかと悩んでいるように見えた。片岡も蔦谷も口にはださなかったが、原田さんに申し訳ないと思いだした。なんともいえない負い目を感じながら、それまで以上に原田さんと一緒にでかけた。
ごちゃごちゃしながら、誰が管理しているわけでもなければ、引っ張ってるということでもない。毎日のように喧嘩のような言い合いをしながら、目的に向かって自立的に動いていくチームが出来上がっていた。マニュアル以上のものが生まれようとしていたところで、まさか原田さんがいなくなるとは思いもよらなかった。
2018/8/19