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

内容 大手派遣会社仕事情報モバイルサイト開発
期間 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（●●さん）は占いプログラマーといった感で、開発チームでは「●●さん、占い師になれるよね。というか、すでに占い師だよね。自分でサイト作ればいいのに。」とよく話してました。