概要

メンテナンスが出来ない、PHP で作成された古いシステム（社内システム、webサービス問わず）に対して

  • 改修
    • バグ修正
    • 機能追加
  • 最新のアーキテクチャによるリプレース
  • 運用のサポート
    • ドキュメント・マニュアル作成
    • ソースコード管理
    • 簡単にデプロイする仕組みの構築

などを行うサービスを、2016年9月から開始します。

お問い合わせは、お問い合わせフォームよりお願い致します。

詳細は、以下をご参照下さい。

背景

なぜ触れないシステムが出来るか

以下のような理由で手を付けられなくなったシステムは、世の中に多数存在します。

  • ソフトウェアベンダーに開発を依頼したものの・・・
    • 保守契約などを結ばないまま長期間経ち、開発元でそのシステムを分かる人がいなくなった
    • 開発元が倒産した
  • 社内でシステムに詳しい人が作成したが・・・
    • その人が退職してしまった

そうしたシステムに対して、

  • 機能を追加したい
  • バグがあるので修正したい
  • HW、OS の保守切れのため、新HW、OS でリプレースしたい

といった要望が出てきたとしても、なかなか対応が難しいようです。他のベンダーに依頼しても、リスクが高いせいか断られてしまうケースも多いようです。

なぜ PHP か

弊社では、そうした触れなくなったシステムの改修やリプレースを比較的こなして来ましたが、その大半は PHP を使ったシステムでした。理由は恐らく

  • 学習コストが比較的低く、使える人が多い
  • レンタルサーバーに最初からインストールされているなど、セットアップなどが簡単

では無いかと思います。

何が難しいか

（薄く）幅広い技術・知識を求められる

システム開発当初は、PHP と DB を使った単純なシステムだったとしても、実運用になると

  • 自前のシェルスクリプトによるバックアップ
  • cron による、バックアップやその他処理の定期実行
  • メールの送受信

などが必要で後から追加されることも多いですし、単純と思われたシステムでも、PHP あるいは FTP によるファイルアップロード機能があることも多いです。

それにともない、改修・リプレースにあたり把握しておくべき内容も

  • Web サーバー (レガシーシステムの場合、ほぼ100% Apache)
  • DB (MySQL あるいは PostgreSQL が大半)

だけでなく

  • OS (ユーザー、パーミッション、cron、ネットワーク設定、ファイアウォール設定 etc.)
  • メールサーバー (sendmail, postfix)
  • DNS
  • FTP

などに及ぶことが多いです。

プログラム部分に関しても、以下のようなものを使っているケースが多く、現状のソースを読み解く力が求められます。

  • 独自フレームワーク
  • 古めのフレームワーク（CakePHP 1.x, Symfony 1.x, etc.）

ドキュメントがない・不十分

小さなプロジェクトとして始まった場合など、ドキュメントが殆ど無いケースも多く、実際に動いているサーバーにログインして調査する必要があります。

実際にやることの詳細

バグ修正・機能追加の流れ

バグ修正・機能追加といった改修の場合は、

  • 本番環境サーバーに直接ログインし、現状のプログラム、各種設定を把握
  • 本番環境のバックアップ
  • （必要に応じて）ローカル開発環境を構築し、そこで改修の開発を行う
  • 本番環境にリリース

というのが大雑把な流れです。

何にリプレースするか

HW/SW のサポート期限が切れた場合などに、システムのリプレースが必要になります。一口にリプレースと言っても、色々な形式があります。

HW をどうするか

HW をどうするかによって、主に以下のように分類できます。

  • 既存HWをそのまま使用
    • OS・ミドルウェアのアップグレード
    • フォーマット後、最新OS・ミドルウェアをインストール
  • 新規HWを使用
    • 最新OS・ミドルウェアをインストールする
  • クラウド（AWS など）に移行
    • EC2 などの上に普通に構築
    • PaaS に載せ、運用コストを下げる
    • Docker コンテナ化する

ソフトウェア・システムはどうするか

PHP で作られたソフトウェア・システムに対しても、

  • PHP のバージョンアップに伴う非互換性に対する修正のみに留める
  • 徐々に、新しいコードに置き換えていく前提で、汎用フレームワークを導入する

といった選択肢があります。

弊社での実績・実例

ソフトウェアの改修のみ（大手出版社様）

元のシステム構成は以下の通りです。

  • PHP 5.3
  • Symfony 1.4 と CakePHP 1.3 が混在（ユーザー側と管理者側サイトで個別に使用）
  • MySQL 5.1

このシステムに機能追加をしたいということで、2015年に対応しました。

PHP プログラマは数多くいますが、複数のフレームワークの知識がある人となると数がガクッと減り、しかも5年以上前にリリースされたフレームワークともなると、最新のフレームワークでは普通に出来ることが出来なかったりします。

ということで、知識が無い人にとっては単純な機能追加でも意外に手間取る・ハマるケースが多いです。

フレームワークの導入（Web系スタートアップ様）

技術的に発展途上のプログラマが、フレームワークを使わず、素の PHP で書き始めたシステムが段々発展して大きくなってきたため、途中からフレームワークを導入して、今後はそちらに置き換えていく方針としました。

対応したのは法人化前の2011年です。当時は CakePHP 2.x, Symfony 1.x, Zend Framework 1.x あたりが比較的よく使われていたと記憶していますが、以下の理由により Zend Framework 1.x を採用しました。

  • 単体のライブラリとしても使用可能
  • 他のフレームワークに比べて、比較的薄く、既存のコードからの移行がしやすい

導入にあたっては、既存のコードをライブラリ化して、autoload で呼び出せるようにしたりして、他のプログラマが新しい仕組みに移行しやすい環境を整えました。

HW及びミドルウェアのリプレース（官公庁様）

RedHat Enterprise Linux 3上で動いていたシステムを、OS のサポート切れによりアップグレードすることにしました。

このシステムは、プログラム自体は大した規模ではなかったのですが、

  • アクティブ・スタンバイの2台構成で、rsync を使った自前でのデータ同期、シェルスクリプトによるアクティブ・スタンバイの切り替え
  • ユーザーへのメール配信
  • 自前でシステム監視し、異常時にはシステム管理者へメールする仕組み

などが作りこまれていたため、

  • 現行動作の把握
  • ドキュメント作成
  • 移行

を行いました。現行動作の把握には比較的時間がかかりました。

最後に

移行に関しては、豊富な選択肢を用意しておりますので、お気軽にお問い合わせ下さい。