既存ウェブサイトへのアクセス制御機能の追加開発

内容 既存ウェブサイトへのアクセス制御機能の追加開発
期間 2008年6月
OS Linux
言語 PHP
アプリ Apache

あるウェブサイトを運営している制作会社から、サイトに会員制を導入するので特定のディレクトリ下のページを会員のみアクセス出来るようにして欲しいという依頼を受け、そのような機能の追加開発を行いました。
クライアントの都合でコストをかけられないため、簡易ですが十分な機能性のシステムを短期間で開発しました。

通常、ウェブサイトでアクセス制御を行うには、

  • ウェブフレームワークのアクセス制御機能を利用する
  • (ウェブフレームワークを利用していない場合は)ページの初期化ルーチンにアクセス制御の実装を追加する

と思います。
これはサイトがPHP/Perlなど動的ページで構成されている場合で、このサイトの場合、静的なHTMLだけで構成されていました。
本案件では工期・予算的にサイトの全面的な修正は無理なため、Apacheのベーシック認証を利用してはどうか?と提案しましたが、ベーシック認証のダイアログによるUIは嫌で、デザインされたページでログインフォームにIDとパスワードを入力するUIにしたいと言われました。
当該サイトのウェブサーバのシステム環境を調べると、共用レンタルサーバでしたが、PHPの利用及び.htaccessによる設定のオーバーライドは可能でした。
そこで、

  • ApacheのAddTypeで拡張子.htmlをPHPに関連付け、全てのHTMLページへのリクエストをPHPで処理させる
  • PHPのauto_prepend_file機能を使ってPHPによるアクセス制御処理を呼び出す
  • 未ログインのユーザはログインフォームページにリダイレクトし、ログインフォームからIDとパスワードによってログインする

というシステムを提案しました。
会員種別に応じたページだけ参照出来るようにするなどいくつかの要件を盛り込んだ上で、納品したシステムはPHPファイルが2つ、.htaccessファイルが2つ、ログインフォームページのサンプルHTMLファイルが1つでした。
既存のHTMLファイルは一切修正する必要がないようにしました。
新たにアクセス制御したいページが出来た場合でも、HTMLファイルは普通に作成し、そのファイルを置くディレクトリに.htaccessファイルをコピーするだけでよいので、追加開発を依頼する必要はありません。
手離れの良いシステムになったと思います。

この案件のクライアントは以前から知ってる会社で、最初にメールで連絡があり、何度かメール・電話のやり取りで要件定義した後、その日のうちにメールでPDFの発注書を送ってもらい、受注しました。
翌日、数時間かけてプログラムを作り、サーバ設定をし、プログラムはメールで納品しました。
予算の少ない小さなシステムだからどう作っても一緒という事はなく、大きなシステムとは違った工夫や手際の良さを発揮する余地があると思います。
大きなアクセスが見込めないサイト、運営にスキルのあるオペレーターがいるサイト、そういったサイトに過度の機能性を盛り込んでもコストが膨らむだけなわけでしで、必要にして十分なシステムを提案する事を心がけています。

大手派遣会社仕事情報モバイルサイト開発

内容 大手派遣会社仕事情報モバイルサイト開発
期間 2008年1月 – 2008年3月
OS Linux
言語 PHP
アプリ Apache, Oracle
フレームワーク 独自フレームワーク

大手人材派遣会社のモバイルサイトがリニューアルするに当たって、システム開発を行いました。

この案件の主な特徴は以下です。

  • XHTML採用により、表現力・機能性の高いデザインを実現
  • 所定フォーマットのテキストファイルを設置するだけで数画面からなる派遣登録フォームを動的に作成し、プログラミング技術のない担当者でもサイト更新が可能
  • 独自ウェブフレームワークを採用

この仕事で苦労したのは、エンドのクライアントとのやり取りでした。
この案件は、派遣会社であるエンドのクライアントが某ウェブ制作会社に制作を委託し、その制作会社が自分にシステム開発を再委託した、という構図でした。
クライアントとの打ち合わせをするのがウェブ制作会社のディレクターだけなので要件が自分まで上手く伝わらないという問題もありましたが、より困ったのがシステム環境の違いでした。
自分にはクライアントが管理する本番環境へのアクセス権がありませんでした。
開発はウェブ制作会社の提供する開発環境がで行ったのですが、OSはLinuxで本番環境のSolarisと違いました。
DBはウェブ制作会社にOracleのライセンスがない為、開発向けエディションであるOracle XEを自分でインストールしました。

そうした開発環境の制限の為、DBの文字コードが開発DBはUTF8、本番DBはSJISになったのですが、文字コードの違いの吸収はウェブサーバやDBサーバの機能を利用すれば良いのでそのような設定方法をクライアントのエンジニアに示すのですが、コンプライアントが厳しいというか、率直に言ってこちらの説明が理解出来ないようで、そうしてもらえない。
仕方ないので、文字コードの違いの吸収はPHPレベルで解消しました(毎回文字コード変換処理が走るので無駄な負荷が発生します)。
それ以外にもウェブサーバ・DBサーバの設定を変える(現在どのような設定になってるか教えてもらう)依頼は基本的にNGなため、そうしなくても済むように工夫する必要がありました。

また、この案件はPHP4だったのですが、PHP4の標準Oracleモジュールは非常に不安定で頻繁にシステムエラーを起こす為(PCサイトではエラー発生してもブラウザはスルーするので見過ごされてきたようですが、携帯の場合、携帯ブラウザがエラー画面を表示するので標準モジュールは使い物にならなかったです)、oci8モジュールが含まれるようにPHPをリコンパイルせねばならず、その指示書を書いて、クライアントの作業をサポートをしました。

以上のような理由で、開発自体は順調に進捗したのですが、それ以外の部分でひどく工期を取られました。
この案件で学んだ事は、開発環境の構築・システム要件の保証はよく検討して工数にプラスする事、でした。

ショッピングサイトのパフォーマンス改善開発

内容 ショッピングサイトのパフォーマンス改善開発
期間 2007年2月 − 2007年8月
OS Solaris
言語 PHP, JavaScript
アプリ Apache, Oracle

PC向けのショッピングサイトの開発に、プロジェクトマネージャ1名、プログラマ4名からなるチームにプログラマとして参加しました。

この案件は出自(?)が特殊でした。
クライアント(サイト運営者)が某大手独立系SIerに開発を依頼したものの、納期を過ぎても完成せず、その某SIerは自社開発を諦め、当時自分が参加していたウェブ制作会社に開発を再委託したというものでした。
自分達が委託を受けた時点で画面はだいたい出来ていて各画面の基本的な機能も実装されており、進捗率は高かったのですが、独自フレームワークを採用しており、そのシステム構造が驚く程複雑で設計が悪かったです。
新たな機能を実装しようとすると既存の処理に大量な修正が発生し、高い確率でデグレが発生しました。
すでに動いてる機能もパフォーマンスが低く、クライアントの要求性能を満たそうとすると、当該処理を大幅にリライトしなければなりませんした。
納期はすでに半年以上遅れてどうにもならない状態で、某SIerはギブアップし自分達が開発を引き継ぎました。

どのように設計が悪かったか説明すると、オブジェクト指向が過度だったと言えると思います。
リクエストの度にあらゆる(ビジネスモデリング的な意味での)オブジェクトが生成され、各オブジェクトが複雑に関連していました。
ウェブアプリケーションは、特にこの案件のようなショッピングサイトの場合、基本的に業務アプリケーション(DBアプリケーション)と見なせ、その為オブジェクト中心よりデータ中心でシステム設計をした方が良いと思います。(この辺の話はSE・PG入門「データ中心指向とオブジェクト指向」に詳しいです。)
ウェブでは複雑にオブジェクトを作っても保存する先はDBだからです。
もしオブジェクト指向ならORマッパーを使えばDAOが整理されると思うのですが、この案件のシステム設計ではSQLはDAO内で独自の生成処理を経ており、ちょっと検索項目を変更しようにも、生成処理内にあるSQLの断片(復元すると数十行になる)を追う必要がありました。
また、同じ目的と思われるが微妙に異なるSQLが別のメソッドに散在していて、SQLの記述自体もコピペの繰り返しで冗長化していて、という。
開発の長期化で担当者が変遷し、担当者毎に実装の癖、コーディングスタイルが違うというお決まりの問題もありました。

結局、半年ほどかけて、なんとかもう少しで完成という所まで持って行ったのですが、ある不可抗力な事情からリリース直前に開発が中止になってしまい、案件として強制終了しました。
自分達の会社には損害はなかったのですが、後味の悪い終わりで非常に残念な気持ちがしました。
このような案件は自分の経験でも今の所唯一で、こうなる前にもっとすべき判断があったなと思います。
個人としてはアンチパターン的に勉強になってのですが。

3キャリア携帯公式の占いサイト開発

内容 3キャリア携帯公式の占いサイト開発
期間 2006年1月 − 2006年4月
OS Linux
言語 PHP
アプリ Apache, MySQL
フレームワーク Maple

某ウェブ系受託開発会社にフルタイムで常駐し、携帯の公式サイトを開発しました。
PM1人PG4人くらいのチームにPGとして参加しました。
最近(現在2010年)では3G携帯のみ対象としてXHTMLを採用するケースが多いと思いますが、当時はまだ2G携帯のシェアも高く、クライアントの意向もあり、TABLEタグ非対応端末、白黒画像のみ表示可能な端末等の各種端末に対応させるため、非常に細かくコントローラ、テンプレートが分かれているサイトでした。
旧型端末が多数揃っており、別部署のテスト部隊によって細かく動作チェックを行っていましたが、そのチェックが厳しく、端末対応が大変な開発でした。

この会社は社員50人くらいのうちプログラマー(SE)が8割を占めてる感じでしたが、非常に質が高い人が集まっていたと思います。
自分はいろんな開発現場に入っており、その経験から言うと、会社の初期段階で起業メンバー数名だけの内は全員の質が高くても、会社の規模が大きくなり、10名、20名、30名と社員が増えてくるとその質は低下する事が多いように思います。
優秀なプログラマーはそう簡単に集まらないし、会社に以前からいて経験を積んだ優秀なプログラマーは辞めていなくなるからです。
受託開発をしている会社の場合、そういう循環になるような気がします。
と、思ってるんですが、この会社はそんな中、結構な数、高い質のプログラマーさんがいました。
正社員だけでなく、派遣や業務委託のスタッフもいて、いろんな所から上手く人材を集めていたようです。

ちなみに、この案件の占いサイト、某有名(らしい)占い師さんが監修していました(している事になってました)。
サイトオープン前後はその占い師さんは打ち合わせ等に参加していたようなのですが、新しい企画は開発チーム任せになっており、チームの中にその占い師さんの本を何冊も読破して占い理論を身につけたPGがおり、占いアルゴリズムが要求される処理はそのPGが担当していました。
業務システム系で簿記等の会計知識に特化した会計プログラマーっていると思いますが、そのPG(●●さん)は占いプログラマーといった感で、開発チームでは「●●さん、占い師になれるよね。というか、すでに占い師だよね。自分でサイト作ればいいのに。」とよく話してました。

新人プログラマー対象のウェブプログラミング講習

内容 新人プログラマー対象のウェブプログラミング講習
期間 2004年10月 − 2004年11月
OS Linux
言語 Perl, PHP, HTML(CSS), JavaScript
アプリ Apache, MySQL

あるウェブ系企業で、新入社員のプログラマーを対象としたウェブプログラミング講習の講師をしました。
期間は1ヶ月半ほどで毎日5時間ほどの授業で、講習後は簡単なウェブアプリが制作出来るレベルにして欲しいという事で、HTML、PHP/Perlプログミラミング、UNIX系OSサーバの基礎知識を教えました。
講習の大まかな内容は以下の通りです。

  • HTML/CSS(テーブルレイアウト、CSSレイアウト、論理的なマークアップなど)
  • JavaScript(入力値のチェック、ドロップメニューの作り方、セレクトタグジャンプなど)
  • Perl/PHP基礎(演算子 条件制御文 変数 関数の説明)
  • ウェブアプリの習作(掲示板などの作成を通して、データ加工や画面遷移の考え方について)
  • プログラミングの前提知識(ファイル・変数名の命名方、ファイル管理、コメントのつけ方)
  • UNIX系OSのサーバ管理・ネットワーク管理

参加した新入社員は6人いたのですが、Java経験者が1人いるだけで、他は趣味でHTMLを書いたことがある程度でした。
スタート時点での習熟レベルですでにバラツキがありますが、加えて学習スピードが各自違うので、全員に同じ内容で授業をすると、分かってる人は退屈に感じ、分からない人は分からないまま次に進んで身につかないという問題が起きました。
最初は市販のテキストをなぞる形式で授業を進めていたのですが、このような問題のため、各自に異なったプログラミング課題を出し、他の5人に課題を取り組ませつつ、1人のプログラムを添削指導するという形式に替えました。
6人いるとそれぞれ癖というか個性があります。
とにかく真面目に説明したことを一言一句メモしてる人、課題の内容を勝手に変えてプログラミングしようとする人、やる気がない人、やる気があっても出来ない人。
それぞれの人に合わせて対応するのが大変でした。

講習が終わって、会社の人事の人にレポートを提出したのですが、「この人はそのうち上手いプログラマーになると思います」と報告した人がいました。
講習前はまったくのプログラミング未経験者だったんですが、講習を始めてすぐに高い学習能力を感じました。
授業中の学習意欲が高く、いい質問が多かったです。
講習が終わった時点では6人の中で特別抜けてたわけではないのですが、これは放って置いてもすぐに成長するだろうなと予想しました。
そして、この仕事を終えて数年後、何気なくこの会社のホームページを見たら、その時の人がその会社のエースプログラマーみたいになっていて、社長賞をもらっている様子が掲載されていました。
やっぱりなと思った次第です。

別の会社ですが、高学歴な人がプログラマーで入社してすぐに辞めたりするのを見てます。
確かに高いレベルのプログラマーになるには数学などの能力が必要と思いますが、その段階に行く前に、プログラマー向きの能力というか、性格のようなものが求められると思います。
その人はそういう能力があったんだと思います。

有名検索エンジンポータルサイトのコンテンツ管理システムの開発

内容 有名検索エンジンポータルサイトのコンテンツ管理システムの開発
期間 2003年2月 − 2003年4月
OS Linux, Windows NT サーバ
言語 Perl, JSP, シェルスクリプト, HTML/CSS
アプリ Apache, IIS, PostgreSQL

某有名検索エンジンポータルサイトのトップページがリニューアルすることになり、そのトップページを運営スタッフが更新するためのコンテンツ管理システム(管理画面)を作って欲しいという依頼でした。
トップページはニュース・天気予報・占い・TV番組表・広告などたくさんのコンテンツから構成されており、それらのコンテンツはサイト内のコーナーとして独立したページ(ウェブサーバ)を持っています。

  • 各コーナーのページ(ウェブサーバ)からトップページ用のデータを抜き出すバッチプログラムを作り、
  • 集まったデータをトップページ担当スタッフが編集するための管理画面を作り、
  • 編集後のコンテンツを本番のトップページ用サーバにアップロードするシステム

を作りました。

内容としては以上ですが、設計前の説明で以下の制約を課せられました。

  • DBサーバを管理する人がいないから、PostgreSQLやMySQLなどのDBを使ってはいけない。
  • コンテンツ管理システムはLinuxで、トップページ用サーバは複数台のWindowsで動かし、それらの通信はFTPのみ。

アップロードシステムは、スケジュール指定出来る仕様になっており、DBを使うのがプログラミングする上で楽なわけですが、NGとのこと。
スタッフが手動でFTPすることも考慮する必要がありました。

考えた末、アップロード予定の日時を年月日時分で分割し、年月日時分をディレクトリ名にして階層的なディレクトリを作成し、そのディレクトリに(バッチプログラム及び管理画面で作られる)アップロード対象のコンテンツファイルを置くようにしました。
CRONで実行されるFTPアップロードプログラムはディレクトリをスキャンし、アップロードすべきファイルが見つかれば、全ウェブサーバにFTPアップロードする仕組みでした。
知らない人が見れば変わったことしてるなって感じですが、他にも事情があって、そういう設計にしました。

もともと3ヶ月くらい制作期間があったんですが、リニューアル後のトップページのデザインがギリギリまで決まらなかったり、各コーナー担当者にお願いしたデータ生成の仕様が上がってこなかったりで、実質、リニューアル前2週間ぐらいで一気にシステムを作り上げました。
リニューアルの日、リリース作業でも予期せぬ問題が起きたりで、この仕事の後は本当にくたくたになりました。

こんな事もありました。
この会社は母体が伝統的な大企業なので、労働組合が強く、その日もプログラムを書いていたら、17時(その会社の定時終業時間)に知らない社員の人がやってきて、「春闘だから、今日はこれまでだよ!さあ帰ろう!」って言われて、(1週間後にリリースで全然間に合ってないんですが…)涙目になるという出来事がありました。
ウェブ業界には定時なんてあってないようなものという認識がありますが、やはり天下の●●●は違うなと感心しました。

インターネット回線事業会社の社内ネットワークの構築管理

内容 インターネット回線事業会社の社内ネットワークの構築管理
期間 2001年12月 − 2002年12月
OS FreeBSD, Windows 2000 サーバ
言語 Perl, HTML/CSS
アプリ Apache, Postfix, BIND, PPML, AntiVir MailGate, Active Directory/DHCP/DNSなどWindowsサーバアプリ全般, RADIUS

某有名インターネット企業の関連会社で社内ネットワーク全般を担当しました。
この会社の業務はデータセンターでのインフラ構築でしたが、社内に大がかりなネットワークシステムがあり、その管理をしました。
社内サーバルームに5-6台のサーバラックがあり、サーバが20台くらい、大型のルータ、スイッチ、アプライアンスが多々ありました。
サーバの内訳は、ウェブサーバ・メールサーバが複数台の他、社員が社内LANにアクセスするためのダイヤルアップサーバとその管理のためのRADIUSサーバ、ウィルススキャンサーバなどでした。
ウィルススキャンを社内サーバで行うのは、当時としては珍しかったと思います。
社員は100人くらいでしたが、非常に人の出入りが激しく、様々な関係会社から社員が出向してきていました。
それらはすべてWindows2000サーバでドメイン管理していました。
それまではUNIX系OSしか経験がなかったのですが、ActiveDirectoryを利用したDNSやWINS、DHCPの管理は統合されていて便利で、オフィスサーバとしてはWindowsの方が使いやすいなと感じました。

この会社の社員は技術者の占める割合が大きく、管理職の人たちは日本のインターネット業界を創世したような人たちでした。
社内規則で終業時に日報を書いてメールで提出することになってたんですが、非常に提出率が悪い。
そこで技術部長さんが、日報の未提出者に提出を促すリマインダーメールを送信するバッチプログラムを書いてくれました。
このプログラム、ソースを見せてもらったんですが、200行くらいのawkで書いてあり、「awkでこんな長いプログラム見るの初めてだ!」と衝撃を受けました。
awkで書かれた業務プログラムに出会ったのはそれが最初で最後です。
その後、その技術部長さんにある仕事を頼まれ、Perlで書いて提出したら、「最近はPerlなんて流行ってるんだね」と、昔からUNIXを使ってる人にはPerlすら新参者の言語なのだと思い知らされました。

当時2002年。
会議室の大型プロジェクターで、みんなでワールドカップの日本戦を観たことが思い出です。

音楽情報サイト制作及び社内ネットワーク構築

内容 音楽情報サイト制作及び社内ネットワーク構築
期間 2000年12月 − 2001年12月
OS Linux, Solaris, Windows 2000 サーバ
言語 Perl, PHP, Java, シェルスクリプト
アプリ Apache, InpriseAppServer, IIS, BIND, Postfix, Windowsメディアサーバ, PostgreSQL, Oracle8i, Samba/Netatalk, FML, pcAnywhere
ハード Sun Enterprise220R, Compaq DL380, CISCO 2600/1600, Alteon AD3, Watchguard FireBox

某音楽系放送局のウェブサイトの運営会社で、サイト制作及び社内ネットワーク構築を担当しました。
アーティストの新譜のリリースなどに合わせて、サイトで特集を組み、プロモーションをするサイトでした。
親会社が音楽業界にコネクションがあり、ユーミンなどメジャーなアーティストも扱ってました。
で、今思えば、かなり先進的なサイトで、アーティスト本人のブログ、アーティストの愛用品のオークション、アーティスト参加のチャット大会などを行ってました。

特に売りだったのが、プロモーションビデオの配信でした。
今のようにYouTubeはなく、ネットで音楽を聴ける(見られる)のは貴重でした。
ライブ会場に行ってライブの模様を中継するライブストリーミングもよく行いました。
当時はライブ会場にインターネット回線はまずなく、ライブストリーミングが決まると、会場にNTTのISDNを何本か引いて(ADSLはまったく普及してない時期)、ISDN回線を束ねて帯域を増やし(CISCOの高いダイヤルアップルーターを使ってましたが、資料がなく、設定に苦労しました)、データセンターにあるWindowsメディアサーバに送信、そこでリアルタイムにエンコーディングして、ウェブサイトから配信していました。

ちなみに、データセンターは事情から大阪の堂島にあり、サーバ工事のために大阪にはよく行きました。
リモートからifconfigコマンド打ち間違えてアクセス不能で大阪に行ったり、Code Redが流行って大慌てで大阪に行ったりですとか。

以上のようなウェブサイトの運営が自分の主な仕事でしたが、他に社内ネットワークの構築も大きな仕事でした。
会社が引っ越して新しいオフィスに移るので、そこのネットワークを作ることになりました。
主な内容は以下です。

  • Linuxのルーター兼ファイヤウォールの設置
  • DMZに社外関係者向けサーバを設置
  • LAN内に社員向けのファイルサーバを設置
  • (デザイナーがコンテンツをアップロードできるように)ISDNでデータセンターのサーバに直結で転送出来るシステムの作成
  • 来客用のセグメントに無線LANアクセスポイントの設置

メインのインターネット回線は、引っ越し前のオフィスではOCNエコノミーという専用回線でしたが、(当時はOCNエコノミーは一般的だったのですが)128kbpsを共用という低速な回線なため、新しいオフィスでは今は亡き東京めたりっく通信からADSLを引きました。
ADSL開通工事の際は、めたりっく通信からエンジニアが二人も来てくれました。
無線LANも当時としては珍しかったと思います。
サーバの数は結構なものになり、かしめ工具でケーブルを何十本作って、誰もいないオフィスで一人で配線して回りました。
いよいよ引っ越しになり、自分の作ったネットワークが無事動いた時は大きな達成感がありました。

この会社ではいろいろと思い出深いことがありましたが、覚えていることをいくつか。
ある日、会社の営業の人が、このバンド、まだ無名だけど絶対流行るよとくれたデモCDがあって、聴いてみましたが、ボーカルの声が地味で(デモCDで録音が悪かったのかも知れません)、これは売れないだろうとCDはすぐにどこかに捨ててしまいました。
実は、それはバンプオブチキンの『天体観測』で、この後に大ヒットしたわけですが、あのデモCD取っておけば良かったと後悔しました。

ここの会社ではFMラジオを1日中流してあり、当時よくオンエアされていたのが、くるりの『ばらの花』でした。
これを聴きながら、サーバ作ったり、プログラム書いたりしてました。
この曲を聴くとと当時のことをしみじみ思い出します。

レンタルサーバでのサーバ構築管理

内容 レンタルサーバでのサーバ構築管理
期間 1999年11月 − 2000年12月
OS Solaris, Linux
言語 Perl, PHP, シェルスクリプト
アプリ Apache, BIND, Sendmail, PostgreSQL, Majordomo, Realサーバ, CyberCache
ハード Sun Enterprise450, Sun Ultra5/10

レンタルサーバ会社での勤務で、主な仕事はウェブサーバやメールサーバの構築でした。
技術者は自分を含めて3-4人、デザイナーが1人、総務が1人、社長が1人という会社でした。
ここのレンタルサーバはサーバがSolarisなのを売り物にしていて、当時、OSはSolais2.6、ハードはSun Enterprise 450やNetraもありましたが、台数が多かったのはUltra 5でした。

今だとUltra 5のようなワークステーションをサーバにするレンタルサーバ業者はないでしょうが(というよりもSolarisをウェブサーバにしてるところがない?)、当時はSolarisを安く動かせるということで、Ultra 5を使ってました。
会社にはUltra 5 が何台も積み上げられていて、週に何度も、マシンにOSをインストールして、ApacheやSendmailをインストールして、レンタルサーバの管理用のCGIをインストールして、それをデータセンターに設置しに行ってました。

sun ultra 5会社は大手町と神田の中間にあり、データセンターはKDD大手町ビル(当時はKDDとDDIは別会社)で、歩いて10分程度。
むき出しのUltra 5を手で持ってKDDビルまで歩いて行くんですが、Ultra 5は微妙に重く、途中の鎌倉橋あたりで必ず休憩をしてました。

KDD(KDDI)ビルは当時(も今も?)インターネットの中心で、自分たちがハウジングしてるラック以外には、誰でも知ってる某検索エンジンサイトなど錚々たる顔ぶれでしたが、セキュリティは非常に甘かったです。
本来は、事前に入館予定のFAXを送り、ビルに入る際に守衛さんに入館証を見せて入館するんですが、急いでる時は、「すいません、FAX送ってないんですが、緊急なんで!入館証は忘れました。」と言って名刺を見せるだけで入れました!

当時のインターネット業界はまだ牧歌的でした。
あれから10年。
何も変わってないような、すべてが変わってしまったような…。