作業場所 米国 作業場所 米国 エンドユーザ 高等学校  システム 学事管理 業務 高校向け学事管理システム。 学籍情報、スケジュール、履修、出席、成績、ＶＩＳＡステータス管理など 期間 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という言葉が米国の業界雑誌ではあちこち見られるようになっていた頃です。おそらく今ですと、本業の旅行業に紐付けたり、様々な展開も考えられるので興味を持たれたと思いますが、当時はその概念が受け入れられず採用とはなりませんでした。