今度連絡しますから29(改版1)
＜遅れ？できるかでしょう＞プロダクトマーケティングを兼任させられるまでは、責任はユーザーズマニュアルまでだった。マニュアルは、ページ数をみれば四、五千ページになるが、それなりの能力の工数を確保できれば、いつでも作れる。そこに他人事でしかなかった開発の責任が重くのしかかってきた。
ソフトウェアエンジニアに多くを望む気はない。最低限でいい、なんとか市場で受け入れてもらえる製品さえできてくれば、あとはどうにでもなる。客先のニッチな要望を取りいれて機能を追加して一軒一軒取り込んでゆけば、ビジネスといえる規模にならないにしても、売ったという実績は残せる。問題は使えるプラットフォームが作れるかにあった。
村田さんと同席しては同じでも、ウォークスルーへの参加の仕方が今までとは違う。もうオブザーバーとして聞き流しているわけにはいかない。仕様書はいくらしっかり書いたところで、開発者は意図的にこうも読めると、自分の都合のいい読み方に流れる。ソフトウェアエンジニアから、認められない機能の説明がでてくれば、開発要求仕様を改版してでも要求を明確にしなければならない。日本語の開発要求仕様が不明瞭であろうがなかろうが、市場で受け入れられない機能は認められない。好き嫌いの話ではない。市場で受け入れられるものを開発するのが目的で、それ以外は目的を達成するための手段か、副次的なもの、あるいは枝葉末節と切り捨てるしかない。
ウォークスルーがそれまで形だけのものから中身がありすぎるものに変わった。ゴタゴタは避けたかったが、開発の責任を負うとなるとゴタゴタを恐れているわけにはいかない。ソフトウェアエンジニアが、タクスの機能を説明するたびに、変更を要求した。それはほぼ全てのタスクにわたるもので、ソフトウェアエンジニアが食ってかかってきた。
「藤澤さんが言っていること、開発要求仕様書にないですよ。ないんだからないのは当たり前の話で、オレの問題でもないし、責任でもないです」
まったくいい年をして小学生が「習ってません」というのとなにもかわらない。
「誰の責任という話をしているつもりはない。こうしなければCNCとして機能しないから、こうして欲しいとお願いしてるだけで、それ以上でも以下でもない。もし、このまま開発したら、最終段階で今お願いしている機能に作り直すことになる。それをわかっていて、今のまま作り続けるのか。今作り直した方が楽だろう」
ソフトウェアエンジニアが村田さんとこっちを見比べている。村田さんがテクニカルライターになったかのように、うつむいたままで何も言わない。村田さんには申し訳ないが、使い物にならないものを作ると言われて、「はい、どうぞ」とは言えない。
三人目のソフトウェアエンジニアの説明を聞いていて、このままウォークスルーを続けてもしょうがないと思った。
「うーん、どうしようか……」
こんなもの作ってどうするのという代物にしても、本人にしてみれば一所懸命(？)やってるのだろうし、なんと言っていいもかわからなかった。どこを訂正してくれではどうにもならない。破棄して勉強しなおせということなのだが、まさかそうとも言えない。
「みなさんには、申し訳ないけど、今日はここでウォークスルーを止めにしませんか。ジョンソンに言って、マーケティングの資料を配布してから……。今日は金曜日だから……。そうだな、準備にちょっとかかるから、来週の水曜日か木曜日には資料を配布します。来週のウォークスルーで、配布した資料をどう扱うかを話し合うことで……」
うんでもなきゃすんでもない。誰も何も言わない。自分たちがしてきたことが、「ままごと」に過ぎないことぐらい理解する知能はある。ただそれを指摘されて、受け入れられる人はなかなかいない。自分の仕事に自信をもってしかるべき人なら、これはしょうがないと認めることもあるだろうが、立場だけで何もない人は認めたが最後、立場もなくなることを恐れて抵抗してくる。抵抗されようが何されようが、目的のためにはそんなこと気はしてはいられない。
「反対意見もないようですから、今日はここまでで終わりにしましょう」
と言って、会議室を出てしまった。ドアを閉めて新鮮な空気を求めているかのように深く息をした。誰かが何か言い出すのを待つべきだったかもしれないと反省ともつかないことを思った。でも言い出したら、どうなるのか怖かった。無言のうちに出てしまった方がいいと考える余裕などなかった。ただ無言の会議室にいたくなかった。ウォークスルーにいた人たちの問題ではない。それは組織の、マネージメントの問題なのだが、いつでもどこでも問題は担当者個人の問題になってしまうというのか、されてしまう。
村田さんは残って、ソフトウェアエンジニアの文句を一人で受けていたのだろうが、それはそれでいい。そのくらいの責任はあるだろうって思おうとした。
「ジョンソン、PDRの英文翻訳を貸してくれないか。コピーしてソフトウェアエンジニアの配布したいんだけど」
日本人とよりジョンソンと話をしている方が精神的な負担が少ない。ロジックのぶつかり合いはあっても、それはロジックの話で、議論であって、個人と個人のぶつかり合いにはならない。
「いいけど、あいつら英語わからないぞ」
「わかってるって。でも先週かな、もうちょっと前だったか、偉そうにソフトウェアは英語で書かなければならないし、オレたちソフトウェアエンジニアは英語もできるんだって言ってたぜ」
ジョンソンが何を馬鹿なことを言ってんだと笑いながら、皮肉っぽく、
「そりゃ、タクスだとか、エラーだとか、ファイルだのコマンドだのがわかるってことだろう。だいいち、あいつら、コマンドをちょっと知ってるだけだ。ソフトウェアのソの字がわかってんのは高橋と加藤ぐらいで、あとはWould-beの連中じゃないか」
Would-be、そのまま訳せば、ソフトウェアエンジニア志望ということなのだが、｢もどき｣と言っても世辞になる。口の悪いジョンソンにしては、ずいぶん優しいことを言うじゃないかと思いながら、
「お前は知ってんだろうけど、村田が書いた日本語のPDRを訳したのはオレだ。村田の日本語がどの程度のものかもわかってるだろう。とてもじゃないが読めた代物じゃない。オレの常識で意訳した。直訳したら、読める英文にならない」
ジョンソンは日本語がわからない。それがゴタゴタの原因の一つであることは、ジョンソンも馬鹿じゃなし、後ろめたさがある。 なにが言いたいんだ、という顔をしていた。
「ウォークスルーで誰も彼もが日本語のPDRにかかれている通りに開発しているのに、オレがでてきて、開発要求を変更してるって文句をいってやがる。PDRを自分の知識でどこまできちんと読めるかってのが仕事のはじまりだ。少々抜けたPDRでも、補ってきちんと理解して、市場で受け入れてもらえる機能を開発するのがエンジニアの仕事だろう」
やわらかく「だろう」とはいったが、同意なんかいりゃしない。ShallよりきついWillで、shallのように強制されてのことではなく、自らの意思でそうしなきゃならない。
「ただの外注の翻訳屋がだ、時間もないところで、バタバタしながら日本語の原稿を読みきって、そこそこまともな英語のPDRを書き上げた。エンジニアじゃない。社内の人間でもない外注の翻訳屋がだぞ。なんで、外注の翻訳屋ができて、よくわからないってんならいつでも訊きにいける、社員のエンジニアにはできないんだ」
「日本語のPDRは確かに問題が多い。それは認める。でもだ、言ってることはわかるだろう。てめえたちの知識のなさが招いたことを、人様のせいにするんじゃねぇっての。それを言わなきゃならないときになったってこった」
「おい、他人ごとじゃないだろう、ジョンソン」ってのもあって、言っていて段々腹が立ってきた。
「好きとか嫌いとかとう話じゃない。市場に受けいれてもらえる製品が欲しいというだけだ。使い物にならない機能を説明されて、はい、いいですよって言えるか」
マーケティングの女性に頼んで、英語のPDRのコピーをとった。資料配布の目的を説明したカバーレターをつけて、ソフトウェアエンジニアリングに持っていった。十項目に箇条書きした。
1) 開発要求仕様書の英訳です。
2) 外注の翻訳者が、一昨年の年末に急遽翻訳したものです。
3) 外注の翻訳者は、日本語の開発要求仕様書の記載について質問する時間がありませんでした。
4) ジョンソンが不在だったため、ブラウンが代理で翻訳をチェックして事業部に提出されています。
5) ご担当されている機能の日本語の開発要求仕様書と翻訳と比較してください。
日本語では意味がはっきりしない箇所でも訳文にははっきり書かれています。
6） 比較して頂ければおわかりいただけるように、外注の翻訳者が機械の動作も考えて、CNCの機能を理解して意訳しています。
7） ソフトウェアエンジニアであれば、一外注の翻訳者が意訳した程度のことは十分理解できるはずでしょうし、それを求められるでしょう。日本語の開発要求仕様書が不明瞭な場合は、外注の翻訳者とは違って、いつでも確認できるお立場にいらっしゃる。
8） ソフトウェアは英語で書かなければならない。そのためもあってソフトウェアエンジニアは英語にも堪能であるとお聞きして ます。翻訳は簡潔な英語で書かれていますから、判読に困るようなことでもないでしょう。
9） 英訳で求められている機能を実現した処理を組み込んだFunctional Specが書きあがったら、ウォークスルーを再開しましょ う。
10）和文、英文にかかわらず機能について疑問があれば、いつでも訊いてください。プロダクトマーケティングとして最善を尽くす所存です。
何も特別なことはない。市場に受け入れてもらえる製品を開発するために、こんなことまでしなければならないとしてしたことだが、大騒ぎになるのはわかっている。このドタバタ喜劇を自分だけで楽しむのはもったいない。マーケティングの女性二人に、カバーレターを見せて簡単に状況を説明した。
「ちょっとやばいけど、ごちゃごちゃやるしかなくなった。ソフトウェアエンジニアリングが制御対象も知らずに適当なソフトウェアの開発を進めているから、矯正しなきゃならなくなった。加瀬も黙っちゃいないだろうし、大騒ぎになるから、横で楽しんだらいい」
二人と同期入社の、それも仲のいい女性がソフトウェアエンジニアリングで事務をしていた。二人に話せば、女性同士のネットワークでソフトウェアエンジニアリングで起きていることが情報として流れくる。
「それって、この間、村田さんから引き継いで騒いでいるヤツですよね」
「ヤツっていわれるとちょっと困るんだけど、アルファの開発の責任を押し付けられたからさ。ユーザーズマニュアルならいつでも作ってやるけど、ソフトウェアの開発だから、あいつらにやらせなきゃならないんだけど、できっこない。保証してやる。でも、できないとオレの責任になるし、どうしたもんかなって。冗談じゃないよ。船が沈没するときになって、あんたが船長だって言われたようなもんで、船と心中する気はないけど……」
「そうですよ。加瀬さんなんかえばり散らしてさ。ソフトの連中だって、毎日遊んでるようなもんらしいですよ。だって何もわかってないんだから」
「あたしの方がコンピュータのことよっぽど知ってるかも。学校でコンピュータクラブで、これでも簡単なソフト組んだことあるんですよ。まあ、学園祭のゲームですけどね」
「そうだよ、xxxちゃんの方が知ってるよ。あいつら会社にでてきて、できることといったら、ビデオゲームぐらいしかないじゃない。あとはカラオケいって酒飲んでしかないもんねー」
二人で吐き出すように悪口というのか陰口がとまらない。
去年入社した男性社員でそこそこ使い物になりそうなのはアプリケーションエンジニアリングがとってしまって、残ったのがまとめてソフトウェアエンジニアリングに回されていた。同期入社だけに気にもなるんだろう。なんでもよく知っているのにびっくりした。女性同士のネットワークには恐ろしいものがある。
一人がなんだこれという顔をしてカバーレターを見ていた。
「これ書いたの藤澤さん？」
「変なところでへりくだる癖があるのは知ってるけど、この文章、いつもの藤澤さんの文章じゃない。なんか変じゃない、ほらyyyちゃん」 カバーレターを渡して、二人でみながら、
「誰が書いたの？村田さんはこんな文章書けっこないし」
翻訳をしていたこともあって、言葉の使い方にはうるさかった。英語からの翻訳だと、どうしてもバタ臭い日本語になってしまう。 読んでもらえる日本語にするには、物が主語になる英語のバタ臭さを抜いて、読み手を主語にしてちょっと味噌味を利かさなければならない。そんなたとえを何度か聞いていたからだろう、わざとバタ臭くした日本語に気がついた。
「後ろに英語の原文がありそうな感じがあるだろう。そこに気がつくか、ちょっとテストしてみようと思って、わざとそんな文章にしたんだ」
「えぇ、英文もあるんですか」
「あるよ。ほら」
といってみせた。会社の英語の定型カバーレターには宛先を書くところがある。そこにはTo： Persons、CC: Johnsonと書いてある。
「あれ、部長に入れなくていいんですか」
「プロダクトマーケティングやれって言ってきたのは、パーソンズで、荒川さんは何もからんでない。変に入れたら、ゴタゴタに巻き込むようで……、入れないほうがいいだろうって思って……」
二人で妙に納得して、
「そうだよね。荒川さんに入れても、しょうがないし。どっちでもいいんじゃない」
「で、そのテストってなに、なんのテストをしようっての」
「あいつら、変な日本語をみて、もしかしたら英文があるんじゃないかと思うかなって、そのくらい気がつけよって……」
「まあ、気がついての話だけど、誰にその英文を出してると思うかな」
「なに、藤澤さん、もしかして先にパーソンズに出してるの？」
「当たり前じゃないの。そもそもがパーソンズの指示で始まったことだぜ。もしパーソンズが何か言ってきたら、内容を変更しなければならないかもしれないじゃないか。あまり変なこと言ってきたら、じゃあ、プロダクトマーケッティング兼任は辞めさせてもらいますって言うから。切り札はこっちが持ってる。何も言ってこないから、OKってことだろう」
「加瀬が怒って、間違いなくパーソンズに文句を言いに行く。ただパーソンズも知っていると思って行くのと、知らないでじゃ、準備も違うだろう。パーソンズはこの件について知ってるってわかってて行けよってことだ。だってそうだろう、パーソンズは加瀬が来ることを予想して待ってるんだから。親切だろう。でも加瀬は、へりくだった文章に腹を立てるだけで、頭に血が上って気がつかないだろうな。行った後で気がつくだろうけど、後の祭りだ」
「勢いよく出ていったはいいが、パーソンズに切り返されて、すごすご帰ってくる。それをみて、あの連中はなんて思うんかな。気になるだろう？」
二人してにやついていた。今日中にも同期の女性にソフトウェアエンジニアリングの騒ぎを訊きにいく。
もう加瀬はパーソンズのところに行ってるだろうから、二人に話してもかまわない。こんな遊びでもしなきゃ、やってられない。
速報が女性同士のネットワークで入ってきた。
加瀬はカンカンに怒ってる。パーソンズに担当を村田に戻せって言いにいった。社長秘書からアプリケーションエンジニアリングの女性経由でパーソンズの対応の話が流れてきた。パーソンズは加瀬が怒ってくることを待ち構えていたかのように、加瀬を叱ったという。フジサワさんのカバーレターはプロジェクトを推進しようとしてのことで、新任プロダクトマーケティングマネージャとしてはしなければならないことをしただけで、ソフトウェアエンジニアリングもしなければならないことをしてください。最後は仕事をしてくださいで終わったみたいだったと言って来た。
横柄でわがままな加瀬に負けず劣らずのソフトウェアエンジニアリングの連中には、ソフトウェアエンジニアリングの事務の女性ですら反感を持っていた。毎日のようにゴシップのような話まで含めて流れてくる。このままいけば崩壊しかけないというより、とっくに崩壊していた。
高橋と加藤はもう何年も口もきかないほどいがみ合ってきた。二人そろって事業部への出張というわけにはいかないから、交代でどちらかが行って、技術を習得して新しい情報を持ち帰ってくるのだが、留守番していた相手には教えない。ソフトウェアエンジニアリングに配属されると、早々にどっちの派閥に入るかを決めなければならない。派閥に入らなければ仕事をしていく最低限の情報すら得られない。どちらかの派閥に入って、もう一つの派閥と知識や情報の隠しあい、足の引っ張り合いが仕事になっていた。二人とも似たような年で、どっちも同じ格のマネージャ、誰も管理しない野放し状態のところに加瀬がきて、外見は落ち着いたように見えてはいたが、陰にこもっただけで、何が変わったわけでもない。
アメリカの事業部と合弁会社の担当事業部が半年ごとにプロジェクトミーティングを開いていた。テクニカルライターなら出ていくことはないが、プロダクトマーケティングとなると出ないわけにはいかない。事業部から四人来ていたが、何度も来て、通いなれているのだろう、日本支社の誰の手を煩わせることなく名古屋キャッスルホテルに直行していた。ミーティングの前の晩に合流した。長旅の疲れなどどこにもみえない。開発には責任のないアドバイザーの立場だから、気楽な出張だったのだろう。
挨拶も早々にミーティングが始まった。合弁相手が用意した進捗状況一覧表の厚さに驚いた。A3に印刷された表にはAction itemとでも呼ぶのか課題が隙間なく書かれていた。Action Plan、対策とか処理に相当することと、誰がいつまでにと、こと細かに書かれていた。まさか、これだけの量を一つひとつ確認していくのかと腰が引けた。
今までも何回も似たようなことをしてきているのだろう、日本の会社によくある月例営業会議ほどの気負いもなく、一ページ目の一番上にあるAction Itemからするっと始まった。
合弁先の営業課長がAction itemごとに担当者に状況報告を求めて、解決していればAction itemを削除する。しばしいくつも のAction itemが相互に関係していて、あっちのページをみて、こっちのページをみて、報告者が何人もいる。Action item がAction itemを生んで、どっちが主でどれが従なのか、関連はするものの、どちらも独立したAction itemなのか、担当者間で も調整しきれていないのが露呈することも多かった。それというのも、プロジェクトが遅れに遅れて、進捗を見ようにも見通しが 悪くなりすぎてしまっていたからで、経緯に詳しい担当者でも迷子になった。
二ページ目に入ったときには、助かったと思うようになっていた。プロダクトマーティングを兼任しろと言われれば、普通、即開発計画と進捗を確認する。遅れがでててれば、なんらかの対策をと思う。常識で考えればしなければならないことなのだが、しようとは思わなかった。問題としえる程度の遅れなら対策も講じられるし、講じなければとあれこれ考もする。もし問題としえる程度を極端に超えすぎていたら？とったところで焼け石に水にもならない対策？そんなこと、考えたところで何の意味があるとも思えなかった。
二三ヶ月や半年の遅れ、あるいは一年の遅れでもいい、遅れてでも製品ができてくる可能性があるのなら、遅れを気にする。問題は、どのくらいの遅れで製品がでてくるのかにではなく、製品がでてくるかにあった。
合弁会社は品質管理では世界でももっともうるさい会社の子会社で、なにか問題があれば口癖のように「歯止め」という言葉がでてきた。同じ、あるいは似たような問題が二度と発生しないようにという姿勢は評価するが、すべてのことをunder control――自らの制御下におけるわけではない。月ロケットを打ち上げるにも予算の制限がある。日常の生産活動に使用するものには厳しい予算制限がつきもので、原因究明と対策にかけられる金も時間も限られている。たとえ無尽蔵の金と時間をかけたところで、事故は必ず起きる。起きれば、「歯止め」を杓子定規に関係者(外注)に押し付ける。その「歯止め」を言葉のあやとして使って実務レベルを酷使し続ける。それはもう企業のDNAとでも呼んでもいい、企業文化にまでなっていた。
そんな文化の合弁相手とにわかソフトウェアエンジニア連中のプロジェクトミーティング。進捗一覧には一年以上前、なかには二年前に作業を完了していなければならないものが、まさかそんなにというほど残っていた。
必要とするすべての情報――ハードウェアの設計基準と検査基準や検査方法、使用してきた装置からなにからなにまでアメリカの親会社が日本の合弁企業に提供していた。そこにはハードウェアならアメリカより日本の企業の方が上手に小型に廉価に開発、設計、製造できるだろうというアメリカの会社の日本メーカに対する過度な評価があった。ましてや相手は、世界に冠たる日本の自動車産業の雄といわれるメーカの子会社。期待しすぎるなと言える人がいたとしても、言ったところで誰にも聞いちゃもらえなかったろう。
ハードウェアもソフトウェアも、ほとんどの項目で一年から一年半は遅れていた。そこまで遅れると、遅れの少ない方が優位にたつという五十歩百歩の違いで、明るい顔になったり渋い顔になったりの三日間だった。
遅れついでで、もう二三年かけてでも開発を続けるか、それとも断念するかというところもまで来ているのに、五十五十の対等出資の合弁会社の悪弊で、都合の悪いことを自分から言い出すのをためらったまま時間だけが過ぎていった。
なんでもそうだが、はじめるのは簡単だが、辞める、引くというのは勇気がいるし、人も組織も痛む。その後の処置や処分まで考えると、はじめるよりはるかに難しい。さりとて、はじめる前から失敗したときのことを周到に準備してとはいかない。はじめて、やりながら軌道修正をはかりつつ、時には目標地点の変更までしなければならないこともある。そこまでの自由とそれを裏付ける自信がある組織や人はなかなかいない。
2019/4/28