開発仕様を確認して

製品開発プロジェクトの発起人はマーケティングで、プロジェクトの総責任者の立場いる。マーケティング部隊の分掌と市場投入に必須の品質保証(日本語がズレている)について簡単に説明しておく。
営業部隊からの要求と市場調査から次世代の製品開発の検討が始まる。新製品開発の全責任をプロダクトマーケティングが負う。開発された製品の市場投入から営業部隊や代理店への製品トレーニングなど販売に関する全ての活動はコマーシャルマーケティングの責任になる。コマーシャルマーケティングの配下に二つの実務部隊がいる。一つはコマーシャルコミュニケーションズで、カタログ作成から展示会や広告宣伝などの実作業を担当する。もう一つがテクニカルライターと呼ばれる組織で、製品の一部であるユーザーズマニュアルを作成する。日本支社は高々百五十人の所帯で、技術部がプロダクトマーケティングの業務を兼任していた。

物としての製品とユーザーズマニュアルがセットになって製品(商品)がある。マニュアルは製品の一部で、物としての製品が出来上がったときには、マニュアルも出来上がっていなければならない。物が出来上がってもマニュアルがなければ、販売できないどころか品質保証の検証プロセスにすら入れない。
マニュアルに記載された通りに物としての製品が機能すること、さらに製品としての安全性をアメリカ本社の製品事業部のQuality Assurance(QA)部隊が確認する。QA部隊の担当者は開発の初期段階からミーティングに出席して、どのような製品が開発されてゆくのかつぶさに見ている。製品の機能と安全性の確認をするには、出来上がってくる製品を知り過ぎているという問題が起きる。知らなければチェックできないが、知り過ぎていれば、マニュアルの記載に読み間違えかねない不備があっても、読みこなしてしまう。そのため、似たような製品を使っている人をパートタイムで雇ってくる。評価の過程でQA部隊が問題に気が付いて、マーケティングに改善要求をだしてくる。QA部隊は社長直轄の組織で、製品が所望の機能と性能を発揮し、安全であることを確認しない限り、製品販売を許可しない。一途であることが要求される人たちで、確かに融通の利かない石頭が多い。

ユーザーズマニュアルは四種類あった。パートプログラム作成マニュアル、ロジック制御作成マニュアル、(工作機械との)結合説明書に保守説明書。合計ページ数が四千ページは軽く超える。工作機械とCNCの知識のある人をあちこちの部隊から一年借りてきて、プロジェクトチームを作った。コマーシャルマーケティングの日常業務から距離を空けて、マニュアル作成にとりかかった。
マニュアルは小説ではない。プロダクトマーケティングがエンジニアリング部隊に発行した開発要求仕様書(Product Development Request、略してPDR)と、それを受けてエンジニアリング部隊がマーケティングの承認を求めるために発行した開発仕様書(Functional Spec、略してFS)を基に書き上げる。PDRはまだしも、FSは開発するものの視点で書かれている。それをベースにCNCを使う側−工作機械メーカとその客先の視点でユーザーズマニュアルが書かれる。

PDFとFSを参照しながら、マニュアルの章どりから始めた。これを説明するには、あれが説明されていなければならない。あれを説明するにはこれが。。。大きなポストイットに書かれなければならない主要項目を書いて、その項目に下に何を説明するかをならべてゆく。ポストイットを大きな壁に貼り付けて、四人でああだのこうだの言いながら、大まかな章どりが決まる。書いている途中で、これを説明するには、あれが説明されていなければということに気付いて、章どりの変更が頻繁に起きる。
工作機械に関する知識とCNCを扱ってきた経験から、章どりの大まかな構成は分かっている。分かってはいるが、いざ書きだすと、あれこれ変更がでるのには、正直驚いた。何気なく使っているマニュアルなのだが、改めて全体構成から考えると、結構難しい。

章どりが大まかに決まったところで、四人で作業を分担して図や表も作成しながらマニュアルの本文を書き始めて、とんでもないことに気が付いた。PDFもFSも正式書類の体裁はなしているが、内容がはっきりしない、明らかに間違っている、機能が足りない、なんだか分からない機能がある。このままPDFとFSに忠実に従ってマニュアルを書き上げたとしても、製品としては使い物にならない。
マニュアルを書くより、PDFとFSに書かれている内容の確認が主な作業になってしまった。それこそ一ページにいくつも怪しい記述がある。あまりに確認しなければならないことが多すぎる。マニュアル作成を中断して仕様確認と変更や訂正の作業をするように社長から指示がでた。コマーシャルマーケティングの人間がプロダクトマーケティングも兼任しろというのはいいが、それをすれば、今まで技術部の担当者とソフトウェアエンジニアリング部が二年以上かけてやってきたことが、稚拙というのか、仕事になっていなかったことを証明することになる。

マーケティング部の人間なのだが、実質は、技術部のマネージャとして駐在していたアメリカ人の配下のような立場になっていた。技術部とマーケティング内部のことはなんとでなるが、問題はソフトウェアエンジニアリング部との関係にあった。天下りの通産官僚に率いられたソフトウェアエンジニアリング部隊は、マネージメントもなければエンジニアもいないのも同然だった。ソフトウェアエンジニアと自称しているのもいれば、そうなりたいと思っているものいたが、開発言語としてのC言語をちょっとかじった程度かそれに毛の生えた人たちの寄せ集め部隊だった。

言ってみれば、英文文法と英単語は知ってますという程度で、書かなければならない文章(制御対象)に関する知識がない。ましてや制御対象は、日常生活で見ることのない工作機械。工場見学に行ったところで、見ただけで理解できるようなものではない。公園で手漕ぎボートしか乗ったことのない人たちが、巡洋艦や潜水艦の設計を任されたようなもので、開発仕様書は仕様書の体をなしているだけで、書いている本人が何をいっているのか分かっていない。中身があやしいというより、そんなものを作ったら、プラモデルじゃあるまいし、まず船として機能しない。

仕事でまともにエネルギーを使える環境にないと人間関係が歪む。ソフトウェアエンジニアリング部は十五人かそこらの組織なのに、そんな小さな所帯で二つの派閥に分かれて、いがみ合っていた。能力のない二人のマネージャが権力を振り回す。振り回される権力のどちらの者かをはっきりしないと、居場所がない。それを統括する元通産官僚は予算獲得と組織を拡大さえすれば、獲得した予算を使いたいように使って部隊は成長してゆけるという典型的なお役所の考えしかない。学生時代から還暦近くまで人様の税金を食い物にしてきたゴクツブシのなれの果てだった。
民間企業に天下って、何もしなければ無能であることが露見しなかっただろうに、二年以上かけて開発プロジェクトという名のもとに億単位の金をどぶに捨てた。若い者にはゆっくりと勉強する環境を提供しなきゃなどとうそぶいて、なにかにつけ権限を振り回してちょっかいだしてくる。ちょっかいから身をかわしながら、エンジニア擬きの人たちがしでかしたことの後始末とやり直しに走り回ることになった。

日米の親会社の思惑と野心、その野心を梃子にして日本支社で始めたプロジェクトが頓挫した。やり直すにしても、政治がらみの泥沼になるのは分かっている。関われば大けがをしかねない。よほどのお人よしかバカでもなければ、そんな仕事を引き受けやしない。
2016/5/8