顧客場所 米国 作業場所 米国／日本 エンドユーザ 、 化学製品会社 システム 製品開発 大規模ウエブサイト管理 業務 大規模サイトシステム。 管理インターフェイスとＧＵＩライブラリ。 カテゴリー継承、自動レイアウト機能など。 期間 1997 人数（MAX人） 6 規模(人月) 36 担当 PM、SS、SE、PG、日本オフショア管理 言語 php、Perl、Java、Javascript テクノロジー／ライブラリ Applet インフラ／OS Apache、PostgreSQL、Linux Nの所属する部の部長に化学製品会社紹介を受けました。 ケミカルズ、と名の付く会社は、常に新たな素材を開発、試験していますが、ホームページを構築するにあたって、こんな素材が欲しいという問い合わせができる仕組みがほしいということでした。そこで、問い合わせで化学式を書き、送ることができるようにすることにしました。その他、２０００ほどある化学系の製品のカタログウエブで公開し、またお客様が管理可能なシステムを構築することを依頼されました。 化学式の描画機能は、Javaアプレットで開発することにして、日本の仲間に依頼しました。 私はアメリカにおり、OSSを中心にウエブ系のシステムをいくつか構築していましたが、日本のかっての仲間たちはまだオープン系の仕事が未経験だったので、将来のために何かプロジェクトを欲しいと言われていたのです。わたしのほうではカタログシステムを開発することにして、まずはJavaアプレットを作ってもらうことにしました。私にとって初めて他に依頼する経験となり、また同時に初めてのオフショアプロジェクトとなりました。 アプレットは、化学式に必要な亀の子のポリゴンやラインをスタンプ形式で書けるようにし、またテキストを任意の場所に書けるようにしました。カタログはPHPで構築しました。階層的な製品構成と各ケミカル製品のモデル設計し、ページ構成もモデル化、データをDBに格納する編集管理ツールを作りました。パンくずリストも自動化しました。いまのWordpressと少し似たシステムです。このシステムは、このあと幾つかのプロジェクトで成長させ使い回しをしました。 オフショア開発サービス オフショア開発ならオフショア開発.jp.netまで。
学事管理１
作業場所 米国 作業場所 米国 エンドユーザ 高等学校 システム 学事管理 業務 高校向け学事管理システム。 学籍情報、スケジュール、履修、出席、成績、ＶＩＳＡステータス管理など 期間 1995 チーム（MAX人） 1 規模(人月) 20 担当 すべての工程 言語 C テクノロジー／ライブラリ Cause (手続き記述型開発ツール) インフラ／OS Mac OS わたしにとって、早期にこの仕事を受注できたのは、大変幸運でした。その後長きにわたってお付き合いさせていただき、１０年ものあいだ二代をまたがって私の開発したシステムが稼働したことで、大きな経験と自信を得たと思います。 経緯 当時、お客様に出入りしていたハードウエア業者さんと知り合った事です。彼に頼み込み学校に紹介していただき、ヒヤリング。提案をしましたら幸い信頼を得ることができたのです。彼には紹介料として見積もりの一割を分けました。営業を雇ったと思えば安いものです。しかし、彼はその後まもなく日本に帰国してしまい、このビジネスの関係は一回きりとなってしまいました。しかし、お客様とは永きに渡ってお付き合いさせていただくことが出来ました。 目的 その高校は私立で、フレキシブルな独自のカリキュラムを持っており、当時は最もシェアを持っていたOsirusというパッケージ製品を使っていましたが、それでは管理出来ずに困っておられました。 通常、アメリカの公立高校では、非常に簡単にスケジュールを組めるような科目選択となっているのですが、その高校では選択科目が豊富で組み合わせの自由度も高く、大学同様のフレキシブルな管理が必要だったのです。 また、1教科に複数の教師がつく事もあり、単位も成績評価も大学並みの内容でした。 生徒さんも大変だったと思いますが、その成績を計算して出すのですから責任重大です。 設計 学校には生徒の出席と成績に対して、様々な角度からの取り扱いが発生します。私は既存システムのデータ項目を確認してから、コースは時限単位まで、教師は月単位まで担当を正規化、まずどのような要件にも耐えるようにER図をざくっと設計してから要件詳細をヒヤリングし始めました。そのことにより、少なくとも設計上はどのような要件にも対応できるはずです。そして、要件がこれ以上でなくなったあとで、速度改善が必要な箇所は正規化を崩したりして調整しました。 このシステムは５年後にリニューアルすることになるのですが、最初はクラサバで構築しました。学校では事務室はMacintoshを使用していました。そのためCAUSEシステムを使用して開発することにしました。 CAUSEシステムの場合、DBはBtreeベースの独自DBです。サーバモジュールを介してアクセスできます。比較的安価に複雑な処理を行うシステムをMacintosh上で構築できたとおもいます。速度はそれほど悪くないのですが、SQLを使用できないことから、多数のレコードに同時処理を加える事ができないこと、また複雑な検索条件に対して少々コードが複雑になりすぎるきらいがありました。 当時、その事務室は新たに入ってきた事務員が多く、男女入り混じり国籍も多様でした。学校というところはドラマが多い職場です。事務、教師、生徒、父兄と登場人物も多様で、いつもなにかしら小さな事件が起きます。事務室ではボス以下その対応に常に追われ、全員で協力して対処していました。そのためみな仲良くなり、ボスの人柄もありよく一緒に食事をしたり呑みに行ったりしたのがとても楽しい思い出です。
メールオーダー
顧客 米国 作業場所 米国 エンドユーザ 名簿業者 システム 名簿管理 業務 名簿管理システム。 名寄せ、住所履歴管理、日本人名パターン認識、NCOA住所サービス連携 期間 1996 チーム（MAX人） 1 規模(人月) 10 担当 営業、PM、SS、SE、PG 言語 C テクノロジー／ライブラリ Cause (手続き記述型開発ツール) インフラ／OS Mac OS 経緯 ある日系のツアーガイド会社様から、日系のビジネス書籍のメールオーダーを始めるのでシステムを作って欲しいとの依頼を受けました。あわせて全米の日本人のリストの制作、管理を依頼されました。 目的 この企画には日本の大手出版会社様がパートナーとなっていました。全米の日系人にビジネス書籍を販売しようというものです。わたしも要件を伺うミーティングに日本に飛びましたが、それが渡米して初めてのビジネストリップでした。 当時はインターネットも普及していなかったため、企業が一般のユーザにリーチするにはメールでパンフレットや申込書を送ることが有効でした。切手の費用が莫大にかかりますが、５％の購買を目安に儲けを組み立てるのです。メールオーダー請負のサービスも数多くあった時代です。対象が絞れていれば非常に有効な手段ですし、米国内の場合は全国区の日系の新聞がありませんので、数少ない手段の一つでもありました。 設計 まず、全米の日本人のリストをつくる事が大きな工数を占めます。その会社はできるかぎりの日系人会やその他名簿を集めていました。私は名簿の内容を入力するための簡単なアプリを作成しその会社の方に打ち込んでもらいました。そういった名簿に乗っている人はなんらかの会に入っている、ビジネスマンが多く潜在的に有望な顧客です。しかし数千名しかあつまらず、メールオーダーのビジネスとしては数が足りませんでした。 当時はおおらかな時代で、全米の電話帳の内容がCDで販売されていました。またそのデータは全て検索、出力可能でした。わたしはそこから名前を頼りに日本人を抽出することにしました。上記で作成した名簿から日本人の名前のパターンを抽出し、フィルターを作成して日本人と思われるレコードを拾います。部分一致で検索させ、その他のバリエーションを加えながら１０万人程度の日本人（とおもわれる）名簿を作成しました。 あとはメール内容の印刷や、その結果の管理となりますので、そんなに難しい話ではありません。その会社ではMacintoshを使用していたので、AppleTalkでネットワークを構成し、FileMakerで商品となる書籍の管理、宛名などの印刷と、オーダーが来たら入力、シッピング、トラッキング管理のシステムを構築しました。 運用 名簿というものは、適時メンテナンスが必要です。最初の名簿でメールを出してみると、２０％ものメールが返送されてきました。大体は引越し先の情報がついていましたので、それを入力し再送します。しかし、引越し先が日本であったり、不明なものも多くありました。これは切手代を考えると大きな痛手です。そこで、NCOAというアメリカ合衆国郵便公社（United States Postal Service, USPS）の住所変更情報サービスを利用しました。 定形のフォーマットで名前、住所を送るとその人がそこに住んでいるのか、あるいは引っ越したのか、その引越し先などの情報付きでデータを送り返してくれます。その利用により、メールの精度を上げることが可能になりました。 その後 システムが運用稼働し始めた後、わたしは社長や、社長のビジネスパートナーにCMS機能のプレゼンをしました。当時、CMSという言葉が米国の業界雑誌ではあちこち見られるようになっていた頃です。おそらく今ですと、本業の旅行業に紐付けたり、様々な展開も考えられるので興味を持たれたと思いますが、当時はその概念が受け入れられず採用とはなりませんでした。
メインフレームCOBOL
顧客 日本 実装 日本 エンドユーザ 電力、運送、公共、アパレル システム 設備管理／工事管理／戸籍管理／アパレル商品管理 業務 メインフレーム、ＣＯＢＯＬでのシステム開発に従事 期間 1984/6 – 1986/5 担当 SE、PG 言語 ＣＯＢＯＬ インフラ／OS メインフレーム 私のIT業界デビューは、新橋の電力会社でした。 出来高契約で入った会社でCOBOLの教科書を渡され、一週間ほど自主勉強した後、ふたつばかり実地の仕事ですがごく小さなプログラムをテスト的に書きました。実際に自分でコーディングしたものが動いているものを見ることは出来ない時代ですので、書いたはいいがそれがどう使われるのか見当がつきませんでした。それでも上司が、まあいいだろうということでひと月ほどして現場に出ることになりました。 新人プログラマにとってまず最初に感動する出来事は、お客様の環境の中で、自分の作ったプログラムが実際に稼働しているところを見た時でしょう。当時の不便な開発プロセスでも、今の便利な世の中でもそれは変わらないと思います。 当時はGUIがありませんから、ダム端末といって黒い背景に緑の字のモニターにキャラクター文字をつかって画面を描画していました。画面の描画部分をひとつ作成するだけで数週間かかったものですが、いまだとコーディングだけですと１〜２時間でおわるような作業です。まずそういった画面まわりを覚え、そのあとユーティリティなどの小さな仕事を受け持ちました。ちょっとした日付の計算や文字列の処理などして返すメソッドですが、これも当時はひとつのまとまった仕事として切りだされてましたので、世の中の景気がよかったんでしょう。 上司は当時３０前半の脂の乗り切った年代で話し好きの優しい人で、私を現場で観察しながら様々なアドバイスをしてくれる人でした。そのため特に問題なくひと通りの仕事ができるようになりました。 ３ヶ月ほどして慣れてくると、DBのインデックス構築などある程度頭をつかうタスクを割り振られるようになり、そして詳細設計を任されるようになりました。ひとつの思い出としては、単体テストの確認方法です。その現場では、単体テストを通すのをモニターし、コードの分岐をどれだけ通っているかを計測していました。当時は８０％とおればOKでした。その時は便利なエクセルも無い時代なので、TD表という言葉も知りませんでしたが紙に表を書いて分岐をとおるデータを考えたものです。 業務領域としては、工事監理、設備管理といったエネルギー系特有のものですが、当時日本で最大のシステムだったということです。その商流のグループで良かったと今でも思うのは「わからないことはいつでもどこでも聞くのが正しい」という文化だったことです。どんないじわるな人でも、仕事上の質問には丁寧に応えてくれました。昨今は、初心者が質問してもそんなことはネットで調べろ！と皮肉っぽく、あるいはあからさまに罵詈雑言を浴びせるのが一般的なようですが、教えることも勉強、あるいは確認になるので違和感を感じます。 さて、わたしは渡航費用を貯めるために無我夢中で仕事にとりくんで一年立ちました。そのころは次のステップとして本格的にSEの領域にはいっていましたが、渡航の予定も迫ってきたのでとにかく効率良く仕事をこなそうと考え始めました。とりあえずシステムにはINとOUTがあること、INのチェックをしてちょっとした計算をして返せばよい、といった大雑把な捉え方をして自分のテンプレートをつくり効率をあげ、常に２〜３のプログラムを並行して担当させてもらうようになりました。さらに渡米前には一日４時間と開発の仕事を区切り、現場では２つの端末を専有して二人前の分量を上げるような生活をしていました。 まあ、単なるPGとしてはそれでいけましたが、会社はもっと上のレベルで貢献して欲しいと思っていたと思いますので、そこは申し訳ないことをしたと思っています。しかし、渡米後自分で業務を請け負うようになって、技術のフィードバックという形でその会社には恩返しさせてもらいました。
