イリジウムのおかげです。メーカーからみると悪魔の囁きのようだったイリジウム電話である。ニーズは確かにあるのだがメーカーの皮算用から見れば無いのに等しいのかもしれない。無いのに等しいようなユーザーに身内がいた。実兄は、昆虫標本商を営んでいるのだ。東南アジア地区でのPHSの基地局が蟻に襲撃占拠されるなどの事件ではお世話になったが、その後、例によって音沙汰がなかった。

正月の実家訪問で数年振りに、その実兄と会った。最近標本商以外に新たな商売をはじめたそうである。生きている昆虫、とくに甲虫類の斡旋ができるように法律が改正されたそうでこの商売を始めているようだ。南米の奥地から、モンゴル高地や東南アジアの島々に派遣している採集人とよばれる人々との連絡にはイリジウム電話が有効であるようだ。

DIMEに出てきそうなどこかの冒険先生みたいな輩が身内にいたとは灯台もとくらしという奴である。さて、くだんのイリジウムがモンゴルにあると何が起こるのか、・・・・・。実は、用も無いのに電話をかけてくるのである。「新種の蝶がつかまった」というような嬉しい電話ならともかく、「今日は収穫が無かった」という電話が入ってくるようになった。

続きを読む →

近頃タクシーに乗ることが増えた。師走に限らないのだが、初芝通信そばの某メーカーに通うことが増えたためである。初芝時代に開発した無線機が搭載されているタクシーに出会うと懐かしい仲間に出会った気がする。幾つかの交通手段があるのだがいずれの駅からもそこそこ同じ程度のタクシー料金となる。先日は、初芝の裏を抜けて鴨居駅まで歩いた。ボーナスが出た街には賑わいがあるようにも思える。

外資系にいると日常が日米の文化の狭間に悩むことがおおい。サンクスギビングに続いてクリスマス休暇である。よりによってこうした時期と日本の御客様の開発支援が重なってしまう。お客様の問い合わせが堆積していく。電子メールによる照会システムの入力がキューのままになってしまう。ジョブ割付が自動化されていないためでもある。感極まって、西海岸まで訪れるお客様も出現するが、クリスマス休暇の直前に訪問しても技術者はすでに休暇に入っている。人によってはそのまま年越しの休暇に入る人もいる・・・。

のんびりしていると思う反面、年の瀬の挨拶が日本で始まる頃にクリスマス休暇明けのメンバー達は、30日まで出社して仕事を続ける。日本オフィスは時差もあって二日早く休みに入る。年明けは、日本は5日くらいが良いところだが向こうは2日からは始まる。平均すればどちらも同じだろう。仕事を頼みたいときに向こうが休んでいると腹が立つのは情けないことだ。マイペースの気持ちをもう少し来年は取り入れたいものだ。2000年問題の年の瀬であり、システム対応のお客様もいらっしゃり麻雀卓を囲んでのんびりと会社で過ごす役員の方もいるらしい。

はじめて、コミケに出かけた。文学オタクのコーナーもあるようだった。アーサーランサムの同好会があるときき出かけたのだが見つけることができた。英国で書かれたこの冒険小説は、私の文章に影響を多大に与えている。来年は、英語の語彙をもっと増やしたいと思い、この昔読んだ冒険小説を原書で読むことにした。文書をよみつつ心躍らす領域にまで達したいと思う年の瀬である。

朝の暖房が有難くなってきた・・・冬・・・である。

コミュニケーションが会社の成否を左右する・・・そんな時代である。転職してきた、この会社にはオリジナルのEmailシステムがある。だからといってうまくシステムが回っているとは思えないが。会社の組織がフラットであるが故に、うまく活かせる場面が多いことは確かである。日常的に動作しつづけるEmailシステムが重要でありEmailが停止したら会社にきても仕事が出来ない・・・それは事実である。こうしたシステムではセキュリティとリモートアクセスの両輪が必要である。無論リモートアクセスには、フリーダイヤルも必要なことである。

初芝時代には考えても歩調も含めて出来なかった環境ではあるが、会社の規模から考えるとIT行政のための事業部の体制などの比率はかなり高いといえる。ここまでの比率をキープすることを是とすれば、会社の仕組みは変貌できるのだろう。昨今、人余りが取り沙汰されていてある電機メーカーでは10000人の余剰人員が出ている反面、人不足が解消できないというジレンマであるという。働く場所に関連して職場を選択しているからだ。希望の職種が希望の場所で手に入らなければ解決できないのだという。こうした人達の活用が図れるのもITを事業として、電算事務の延長でしか捉えていないことから考えていない故の結果なのだろうか。

そうした会社を横目に見ながら古巣である大阪地区の近傍の顧客支援に飛んだ。どこの会社でもお客様のお怒りはいつも決まって「すぐに飛んで来い」である。といってサンドバッグになる為だけに行っても何の解決にもならない。彼らは愚痴をいうのではなくて解決を求めているからだ。こうした実務を通じて自分自身の対面耐久力を養ったりするのはOJTの一環であろうが、未経験の人材を遭遇させるには厳しい環境である。こうした支援人材を増やしたいと思う反面、達観した優秀な人材に遭遇しないかぎりは望めないと諦観したりもする。

日本各地で開発している顧客サポートをしていくのは、楽しいとも言える。セミナーで顔つなぎした人と実際に出荷間際でトラブル修正に追われている場面で遭遇すると、またその人の懐の広さに出会えたりもするし、逆の場合もある。セミナーで事細かな執拗な質問を投げていたYさんとの出会いはそうした中で前者である。彼は、顧客先に関係会社から派遣されている位置付けでリーダーなのかトラブル集約担当なのか構成管理担当なのか所在曖昧なままに仕事に埋没していた。

昔の仕事でいえばレベル1である。冬モデルの出荷の風景にしてはあまりに完成度が低い風景である。「飛んでこい」というお怒りの電話の状況とそれまでの問い合わせのEmailなどの数があまりにも不一致な状況である。件のY氏の話を聞くと、「来てくれたんですか・・・」あとは堰を切ったように質問が飛び出してきた。何故こうなっていたのか・・・・。

問い合わせをEmailでするシステムを構築していたのだが、契約先である顧客のメールドメインを基に問い合わせを受付するようになっていたのである。ところがソフトウェアをまとめる役目のリーダーはプロパーではなく少し違うメールアドレスのドメインであった。こうしたことから、Y氏は長らくこのソフトの技術契約をした会社のサポートシステムは何の返事もくれないと思いこんでいたようだった。無論リーダーであるサブコンのY氏より上は突然課長職だったりするので彼らがだす質問には回答がきていたりするのも知っていた。システムの説明が不充分だったりしたのも悪循環を引き起こしていた。

同様な支援で開発していると聞く他社の技術力について思いを馳せたりしつつの仕事だったようだ。派遣先の上司にお願いして質問を出すというのは、「自分の不得手な点の質問をお願いする」ということでもありよりマイナス効果となっていたようだった。自力で解決しつつの模索をしつつ進めてきたが最後に破綻したというのが実情である。

日常的な対応をしていなかった顧客先で出荷が控えているからと無理に対応を求められても、より溝が広がったりする。他社の同様な製品の性能との差が鮮明になると判らないなり同様の結果を求めるというのが管理職の常だ。しかし自分達の実力以上のことを求めてもより深みにはまりうまくいかないのも常である。

問い合わせになれていないメンバーからは抽象的な質問や具体データに基づかない感覚的な質問を投げかけ、さらに言葉の壁がそこに大きな影を投げかける。ちなみに大阪弁の問題ではない。エモーショナルな感覚の人達の息せき切った曖昧な質問を時差のある言葉の違う設計した人達が回答をしても中々繋がらない。

コミュニケーションを良くする端末の開発には、ベースに良いコミュニケーション環境が必要である。こうした環境で生み出される端末のUIに良いものが出来てくる気がしない。ステップバイステップで解決していくしかない。エモーショナルな彼らに合わせて現場に出向き、深夜に回答をして信頼を得たりという地道な取り組みが必要である。

せめてもの幸いは、彼らの要望が2週間前でなかったことだ。サンクスギビングの期間とぶち当たると人種不信に陥るのは必至だ。お盆の季節に問い合わせを依頼するのと一緒なのだが文化圏が異なると問題になってしまうわけだ。中々相手の立場に立った考えが出来ないのは同一の文化圏でも大変なので、余計に大変なのである。

しかし、うまく利用している顧客からみると相互に無茶な残業をしたりでクリアするでなく必要な情報やノウハウを時間を超えてうまく利用しているのである。とかきつつもレスポンスの為に時折電話に手をやるのだが、ついに相手のYさんは帰宅してしまったようだ。こちらではこれから起きてくるアメリカのメンバーに情報を伝えて引き継いで明日の朝に期待するとしよう。

秋から、すぐそこの冬へ　寒くなってまいりました。

最近の組み込み業界では、技術の空洞化が著しい。そういったことがメーカーを離れて良くわかってきた。溜池テレグラムの威光もあって、W-CDMAはきっと離陸するのだろう。実際設計する人々の顔が見えないメーカーが増えているような気がする。不満を持ちやりたいことを掲げてやらせてくれる会社に意気を感じて転職するのも良いだろう。実際やりたい事が終わるまでは会社にいられるというような会社方針を打ち出している会社はあるようだ。他方、大学を出ても就職先がない。不景気だという。設計方針を誤って出したばかりの端末が、設計期間を見誤り春モデルを最近出荷開始したある会社は新製品なのに最初から1000円で、カメラ屋でディスカウントになっている。「ハードの設計は完了したがソフトの目処はたたない」

そんな風景を見つつ一生懸命やった仕事が方針の誤りで残念な結果になっているという事態なのだ。サポートをしているとメーカーの出来や風土などもよくわかる。大学で予備校の先生を呼んで補習をしている大学があるそうな。大学がそうならば、会社もおなじなのだろう。デジタルの端末を開発して結果として出てくるアナログの音の評価の支援がある。実際にイヤホン端子から取り出して録音したWAVファイルが添付されて解析してほしいという。凄い時代だ。こうした添付ファイルが処理できる人の手に渡って解析されて対策が打たれていく。時間を超える経度による時差が活躍している。小さな時差では、打ち合わせでひいきのチームの会話に終始して優勝できなくて残念でしたねなどという会話が必要になる。移動する新幹線の時間を活用できるのだろうか。

会社を辞めてみると、いろいろな立場の人と忌憚無い会話をできたりする時間が出来る。会社という枠をはずしてみると素敵な人が多いことに気がつく。会社の仕組みがカースト制のように思えてみたりする。カースト制の歴史をもつ人達と暮らしてフラットな組織で自由に活動していくのが当たり前になったことから、18歳で中国から渡米して25歳の今上級技術者として会社の製品の先端を牽引している人たちがいる。私の上司も私よりも若い。事業部長も同様だ。だが、気持ちでは負けていない。若いが年寄臭い日常をしいてしまうのは会社組織の性ではないだろうか。

続きを読む →

はじめに
C3POとは、6809用に開発されたMicroCをベースにして日立のHD6301/6303にカスタマイズとチューニングを行った組み込み目的のCコンパイラです。現在ＤＯＳで動作するバイナリ-とソースコードとマニュアルなどがあります。開発の機会を与えてくださった、前職場の上司ならびに、快く端末開発の過程で付き合ってくれた仲間達、また没頭を許してくれた細君に感謝いたします。このコンパイラは、現在の状況で使う価値があるかといえば・・・？ということだと思います。まあ、まだチップとして６３０Ｘシリーズがあればフリーのコンパイラとしての価値があるのかもしれません。注意を加えるならば、このコンパイラはアセンブラソースコードを吐くタイプのコンパイラであってクロスアセンブラが必要になります。当時のクロスアセンブラの文法には準じたコードが出ますし、またその部分もコードが独立していますのでカスタマイズは可能です。ソースコードですのでご参照いただければ明白です。

開発されたのは、1984年12月が最初の版のリリースでした。1988年頃までは実務と趣味でメンテナンスをしてきたと思います。

アーカイブ(LZH形式です)

• 実行ファイル一式
•  ソースファイル一式
• マニュアル一式(但し,P1EXE形式です)
•  ライブラリソース一式

目的と開発の背景
このコンパイラの開発目的は次のようなものでした

• 組み込み開発で適用可能なコンパイラが欲しかった
• C言語を勉強する必要があった
• アセンブラでのプログラミングノウハウをコンパイラにカプセル化したかった

今ならば、GCCも有りますし、昨今の溢れかえったＦｌａｓｈサイズなどからこだわりはなくなってしまったようですが、開発当時(1984)の組み込み開発事情を考えていただければまともに使えるコンパイラとは当時の8080用に開発されたLSI-Cだったかと思います。無論6809用であればMicroCはエレガントなコードを生成してくれました。コンピュータとしてのアーキテクチャが綺麗だったこともあります。しかし、私の暮らしていた組み込みの世界では、アーキテクチャよりも消費電力や多機能が搭載されていたマイクロコントローラという概念でかのモトローラと特許係争にまで陥ったほどのベストセラーになった日立の８ビットコントローラが厳然としたデファクトとしてありました。このＣＰＵで16kBを越す大規模なソフトウェア開発の効率を上げたいというのが当時の背景でありました。

アセンブラベースで8kBぐらいの容量でメモリーダイヤル搭載の自動車電話を開発していた時代なのです。当時のアセンブラベースでICEと睨めっこしつつの開発というのは、現在のCベースで10MBを越すアプリケーション開発をしている状況から考えると稚拙に思われるかもしれません。せいぜい開発人数も3人で半年位かけて開発しているわけで8KBのコードですとアセンブラソースコードで9000行クラスでしょう。そうなると開発規模は、一人あたりの生産性は300ライン/月くらいだといわれていた時代でもあります。いまは、ベースとなるソースコードがCになって同様の数字なのでしょうか。アセンブラで記述するということによる問題点は相当の熟練を要するというのが背景にあります。スタック操作を誤れば簡単に暴走できますし、そうしたことからリアルタイムトレースといったツールや方法の必要論がまかり通っていました。

続きを読む →