PHPのアップデートができる状態ではないから、困っているんだよ。
もし、PHP 5系システムの
保守運用で、お困りでしたら。
もし、こんなお困りごとでしたら、お役に立てるかもしれません。
- レンタルサーバ会社から「PHP 5やCentOS 5が近々、利用不可になる」と通知が来た。
強制的なサーバ更新で、システムが動かなくなるのでは・・・。
- SSL（HTTPS）に切り替えたいが、サーバやミドルウェアが古く対応できない。
古いOS/Apache/OpenSSLのままでは、最新の証明書やプロトコルに非対応で、セキュア通信への切り替えができず困っている。
- Composerなどパッケージ管理ツールが使えず、ライブラリの依存関係が複雑。
手作業でパッチ適用するにも影響範囲が読めず、下手に触れない状態になっている。
- 引き継ぎ資料が無く、コードを直したら、他に何が起きるか分からない。
前任者も退職してしまい、「下手に触って500エラーが出たらどうしよう…」 という恐怖で、現状放置せざるを得ない。
- アプリのコードやフレームワークが古く、改修・移行の予算も時間もない。
レガシーな作りのため他社からは「全面リプレース」を提案されてしまい、部分的な修正で何とかしたいのに実現方法がわからない。
- ひとまず現行サイトのミラーを作って延命したい。
将来的な全面刷新までは、最低限のコストで動かし続けたい。
- 原因不明の500エラーが発生し、利用者から問い合わせが来る。
エラーが出てもログの見方も分からず、再起動してごまかす日々…。
ご存知の通り、アップデート対応やリプレース対応はした方が当然良いです。ですが、時間も予算もない中、何とかしないといけないとお悩みかと思います。
当社では、現行システムを可能な限り活かしつつ、延命措置ならびに、最新環境を踏み台にすることで、「安心して使い続けられる状態」を実現します。
完璧を目指しすぎず（＝過度なコストを掛けず）、まず稼働させ、脆弱性を埋め、パフォーマンスを改善し、少しずつでも、モダン化できればと考えています。
上記のお困りごとに対する解決策
レンタルサーバ会社から「PHP 5やCentOS 5が近々、利用不可になる」と通知が来た。
やること
- 本番と同等の環境を ミラー（検証）として先に構築し、サーバ会社の更新後に起きる不具合を「事前に」再現できる状態にします。
- その上で、更新で止まりやすいポイント（PHPバージョン差／拡張モジュール差／設定差）を 差分表で、洗い出して対応順を決めます。
狙い
- 「更新当日に賭ける」状態をやめ、止まる箇所を、前もって潰します。
SSL（HTTPS）に対応したいが、サーバやミドルウェアが古く対応できない。
やること
- まず「そのサーバが TLS1.2 以上で通信できるか」を確認し、条件を満たせない場合は 入口（HTTPS終端）を別に用意します。
（例：手前に中継を置いて外向きはHTTPS、古い本体へは内部通信でつなぐ） - 証明書を入れただけで止まりがちなポイント（混在コンテンツ／リダイレクト／外部連携）を洗い出し、必要箇所だけ直します。
狙い
- アプリを大改造せず、まず「ブラウザで警告が出ない／外部サービスと通信できる」状態にします。
Composerなどパッケージ管理ツールが使えず、ライブラリの依存関係が複雑。
やること
- Composer有無に関わらず、使っているライブラリを棚卸しします。（どのフォルダが何のためにあるか、どこで呼ばれているか）
- 変更が怖い共通部（autoload相当、共通関数、テンプレート共通、DB接続）を特定し、触る前にミラーで試せる運用にします。
狙い
- 「触れない状態」から、「触っても戻せる状態」へ持っていきます。
引き継ぎ資料が無く、コードを直したら、他に何が起きるか分からない。
やること
- まず「この画面はどのファイル群が動いているか」を追えるように、最低限の図（処理の入口・共通部・DB）を作ります。
- 変更は必ずミラーで試し、問題なければ本番へ。
- 「本番で初めて試す」を禁止します。
狙い
- 「どこを触っても壊れる」状態を、段階的に解消します。
アプリのコードやフレームワークが古く、改修・移行の予算も時間もない。
やること
- まず“入口”から優先順位を付けます（ログイン、検索、決済、ダウンロード、バッチなど）。
- その入口に紐づく共通処理（DB、認証、メール、ファイル、テンプレート）を特定し、直す範囲を小さく切って対応します。
- 「全部きれいに」ではなく、止まるところ・事故るところから順に直します。
狙い
- 予算内で「今月困ってること」を確実に減らします。
ひとまず、現行サイトのミラーを作って延命したい。
やること
- 本番コピーのミラーを作り、そこで HTTPS対応／500エラー調査／小改修を回せるようにします。
- 「緊急対応の窓口」と「毎月やる改善（小さく）」を分けて、月15時間の範囲で回します。
狙い
- 大きく作り直さず、刷新までの「つなぎ期間」を安全に確保します。
原因不明の500エラーが発生し、利用者から問い合わせが来る。
やること
- まず、どのログを見るべきかを固定します（Webサーバ／PHP／アプリ）。
- 出ていない場合は「出る設定」にします。
- 「いつ・どの操作で・どの入力で落ちるか」を切り分けて、落ちる1点を再現できる形にします。
- 原因が分かったら、再発しないように 例外処理・入力チェック・リソース不足（メモリ/タイムアウト）の対策を入れます。
狙い
- 再起動頼みをやめて、「同じ問い合わせが来ない」状態にします。
当サポートの特徴
当社には、PHP 5時代から現場を知るエンジニアが在籍しており、古いシステム特有の「困った」を解決するノウハウがあります。ここでは当サポートの主な特徴をご紹介します。
PHP 5とPHP 7/8の違いと、移行時の注意点
PHPは、バージョン7で、大規模な変更が行われ、古いコードのままでは動かない場合があります。下表に、PHP 5からPHP 7/8への主な変更点とその影響をまとめました。（全面リプレースではなく）レガシーシステム移行の際には、これらのポイントを、丁寧に洗い出し対応する必要があります。
| 変更点 | PHP 5まで | PHP 7/8以降 | 移行時の対応策 |
|---|---|---|---|
| データベース拡張 | MySQL拡張 mysql_* 関数による接続 | 廃止（使用不可）PDO/MySQLi拡張を使用 | PDOやMySQLiに置き換え（SQL文や引数の違いに注意） |
| 正規表現関数 | ereg() / split() など旧関数を使用 | 廃止（提供終了）preg_match() 等を使用 | PCRE正規表現関数へ書き換え（パターン記法の変更点に留意） |
| ループ処理構文 | each() 関数＋list()で配列走査 | 非推奨（PHP 7で削除）foreach や他の方法を使用 | foreach文等に変更（例: each() の代替として current()＋next()を利用） |
| コンストラクタ記法 | クラス名と同名の関数でコンストラクタ定義 | 非対応（PHP 7で無効化）__construct() に統一 | 全クラスのコンストラクタを __construct に変更（旧記法は動作しない） |
| 参照渡しの構文 | $obj =& new ClassName() のような記法 | 非対応（PHP 7で削除）&なしでインスタンス化 | &を削除（通常の $obj = new ClassName() に修正） |
| エラー処理の厳格化 | 一部の軽微な不具合は Warning 止まりで実行継続 | 厳格な型チェックとエラー制御同じ不具合でFatalエラーに | エラーログを確認し、不備な箇所を修正（Noticeレベルでも見逃さず対処） |
※この他にも、PHP 7以降では予約語の追加（例：StringやIntをクラス名に使用不可）や、preg_replace('/.../e')修飾子の廃止など、多数の変更があります。当社では、公式移行ガイドラインに沿ってコード全体をチェックし、不明点は動作検証しながら、安全に移行作業を進めます。
短時間での問題箇所の特定・修正
「どこを直せばいいか分からない…」という場合でもご安心ください。当社ではレガシーコード解析の経験豊富なエンジニアが、問題の原因箇所をスピーディーに洗い出します。
具体的には、コード全体を走査する自動チェックツールや独自のノウハウを用いて、PHP 7/8で動かなくなる箇所やバグの温床になっている部分をリストアップします。実際、移行時にはPHP 5のコードをスキャンして非対応の文法（PHP4形式のコンストラクタや削除関数など）を洗い出す専門ツールも活用可能です。こうした下準備により、修正が必要なポイントを短時間で特定し、的確に対処できます。
また、原因不明の500エラーなどもサーバーログやソースコードから突き止め、「エラーが出たら即復旧」という体制を構築。問題発生時には速やかに原因箇所を改修し、ダウンタイムを最小限に抑えます。
バッチ処理・大量データ・文字化けへの対応
レガシーシステムでは、日次バッチや大量データの処理で、思わぬ負荷や不具合が生じがち。例えば「一度に大量のレコードを処理するとメモリ不足で落ちる」「大容量CSVをインポートしたら途中で止まる」といったケースです。
当社ではこれらに対し、メモリ使用量や処理アルゴリズムを最適化して、バッチ処理を安定化させます。不要な全件読み込みを避けて、分割処理やストリーミング処理を導入し、長時間実行されるスクリプトの負荷を軽減します。
文字化けの問題もお任せください。PHP4/5時代のシステムでは、Shift-JISとUTF-8の混在などで「？？？」と文字が乱れる現象が起きることがあります。こうした場合、データベースとアプリの文字コードを統一し、適切なエンコーディング変換処理を挿入することで解決可能。例えば、表示乱れを起こしていたメール送信機能をUTF-8対応に修正し、正常な日本語メールが送信できるよう改善した例もあります。
このように、大量データ処理や文字コード問題といった現場特有の課題にも、豊富な知見を活かして対応いたします。ユーザーにとって快適で分かりやすい出力結果となるよう細部まで調整し、レガシーシステムでも、最新のシステムと遜色ない使用感を目指します。
Linux／Apacheなど、サーバ環境のトラブル調査・対処
システムの不具合原因は、アプリケーションコードだけとは限りません。当社は、サーバOSやミドルウェアの知見も豊富で、環境面からトラブルの原因を突き止めることが可能。例えば「Apacheの設定ミスで特定ディレクトリだけ動作していなかった」「OSのライブラリ互換性問題でHTTPS通信が失敗していた」など、サーバ環境由来の不具合も包括的に調査・解決します。
古いCentOSやApache 2.2系の設定から最新環境への移行に際し、設定ファイル（httpd.confやphp.ini）の差分を比較し、最適な形に再構築します。必要に応じて、新サーバー環境を構築し、現行システムを丸ごと移行して動作検証を行うことで、本番切替時のリスクを最小化します。
また、サーバのリソース監視やログ監視の仕組みも整備し、潜在的な問題を早期に検知できるようにします。プロセスが高負荷で落ちてしまう場合は、原因となるスクリプトやクエリを洗い出し、インフラ面・コード面双方から根本解決を図ります。Linuxコマンドラインでの調査や、Apacheモジュールの挙動解析など、普段、表に出ない部分もしっかり対応できるのが当社の強みです。
サービス内容・料金
「当サポート」は、お客様のレガシーPHPシステムを対象に、保守・改善対応を継続的に行うサービスです。
メインコンテンツについて
当サービスのメインは「延命」です。
今ある仕組みをできるだけ活かし、止めずに運用を続けられる状態へ整えます。
もし、一部のバージョンアップ対応（移行）ではなく、全面リプレースをご希望の場合、下記の通り、PHP 5系（PHP 5.6） → PHP 7.4 → PHP 8.4の順番で、段階的に、対応（移行）します。
バージョンアップ対応について
フェーズ１（目安1～2ヶ月）
準備
- バックアップ：コード、DB、設定ファイル、.htaccessなど
- Dockerで環境構築（PHP 5.6、7.4、8.4）
- 依存関係の棚卸し（Composer有・無）
- エラー表示を最大化させ、現状エラーの把握
- 総合（E2E）テストの自動化（必要に応じて）
フェーズ２（目安3～6ヶ月）
PHP 5.6 → 7.4 への移行
- 非推奨から、推奨の書き方へ
→ PDO/mysqli、preg 系、foreach、無名関数、型宣言、Null 合体演算子、配列の短縮構文 - メール送信処理や、通知機能、ダウンロード機能から、エラー（Notice/Warning）を一つずつ潰す。
- WordPressを使っている場合（プラグインに注意）：3系/4系 → 5系
- jQueryを使っている場合：Ajaxのレスポンス形式、JSONの文字コード、HTML生成ロジックを確認
- CakePHPを使っている場合：1系/2系 → 3系/4系に。
- Laravelを使っている場合：4系/5系 → 6系/8系に。
- EC-CUBEを使っている場合：2系/3系（Smarty） → 2.25系（Smarty）、もしくは、4.2系(Symfony5/Twig)へ
- 負荷テスト（必要に応じて）
フェーズ３（目安1～3ヶ月）
PHP 7.4 → 8.4への移行
- 非推奨から、推奨の書き方へ
- WordPressを使っている場合（プラグインに注意）：5系 → 6系
- CakePHPを使っている場合：3系/4系 → 5系に。
- Laravelを使っている場合：6系/7系/8系 → 11系/12系に。
→ vendor依存、Symfonyバージョン、型宣言の厳格化 - EC-CUBEを使っている場合：4.2系 → 4.3系（Symfony 6）へ
- 負荷テスト（必要に応じて）
- 注意ポイント：緩い比較の厳格化、関数の厳格な型チェック
保守対応メニュー（主な30項目）
当サポートで実施できる主な作業項目を一覧にしました。古いシステムの延命に必要となる対応を網羅しています。この他にも「こんなことはできる？」といったご要望があれば、お気軽にご相談ください。
| No. | 保守対応項目 | 内容の例・補足 |
|---|---|---|
| 1 | SSL証明書導入・HTTPS化 | 古いサーバーへのSSL証明書適用、リダイレクト設定等 |
| 2 | サーバー移行（新環境構築） | 老朽化したOSから最新OSへサイトを移設 |
| 3 | OS/ミドルウェア更新 | 例：CentOS 5 → 7更新、Apache/PHPアップグレード |
| 4 | PHP設定最適化 | php.iniの設定調整（タイムアウトやメモリ上限の見直し） |
| 5 | DBアップグレード・移行 | 旧MySQLからのデータ移行、文字コードUTF-8化など |
| 6 | テスト環境ミラー構築 | 検証用に本番コピーを設置、動作テストを安全に実施 |
| 7 | バックアップ体制構築 | データベース定期バックアップ、復旧手順の整備 |
| 8 | 監視設定とアラート通知 | サーバ死活監視、エラーログ監視と管理者への通知 |
| 9 | ログ解析と緊急対応 | 500エラー発生時の原因究明、必要箇所の緊急修正 |
| 10 | TLS/暗号化プロトコル更新 | 古いSSL/TLSバージョンの無効化、OpenSSLライブラリ更新 |
| 11 | PHP互換性チェック | PHP 7/8で動かすためのコード非互換箇所の洗い出し |
| 12 | 非推奨関数の置換 | mysql_*関数など廃止機能を新しい手法に変更 |
| 13 | 古い構文の書き換え | each関数ループやPHP4式コンストラクタの修正 |
| 14 | エラー制御の見直し | Warning止まりの処理を適切にエラーハンドリング |
| 15 | 改修影響範囲の調査 | 変更による副作用が出そうな箇所を事前に特定・検証 |
| No. | 保守対応項目 | 内容の例・補足 |
|---|---|---|
| 16 | コード簡易ドキュメント化 | ソースを読み解き、簡単な仕様書・処理フローを作成 |
| 17 | 既存バグ修正 | 現状顕在化している不具合の原因調査・改修 |
| 18 | 機能追加・変更対応 | 管理画面項目の追加、出力帳票レイアウト変更など |
| 19 | バッチ処理の改善 | 長時間バッチの分割実行化、メモリリーク対策 |
| 20 | 大量データ処理の負荷対策 | 大規模CSVインポート処理のチューニング、逐次処理化 |
| 21 | 文字化け問題の解消 | 文字コード不統一による表示乱れを修正（UTF-8統一等） |
| 22 | 外部API連携の更新 | 他社サービスのAPI変更に伴う呼出し方法の修正 |
| 23 | パフォーマンスチューニング | 遅いSQLクエリの改善（インデックス追加・SQL修正） |
| 24 | キャッシュ導入による高速化 | 必要に応じOPcache/APCu等を有効活用し応答速度改善 |
| 25 | 古いFWのアップデート対応 | 例：CakePHP 2系を3系へ移行、ライブラリ差し替え |
| 26 | ライブラリ依存関係整理 | Composer導入支援、手動インストールライブラリの整理 |
| 27 | 簡易な脆弱性修正 | SQLインジェクション対策など明白なセキュリティ欠陥の是正 |
| 28 | 未使用機能の無効化 | 使われていないモジュールを停止・削除してリスク低減 |
| 29 | システム健全性診断 | 現行システムの問題点を調査報告（継続利用の可否判断に） |
| 30 | 技術相談・運用支援 | 担当者様からのご質問に回答、運用上のアドバイス提供 |
料金について
提供形態
月額契約
料金
月6万3000円（税別）
対応時間
月10時間相当
※契約はいつでも解消できます。当月中に、翌月は不要とおっしゃってください。
保守事例紹介
当社が実際に手掛けたレガシーシステム延命の事例を3つご紹介します。実名は控えていますが、同様の課題に直面したお客様が当サポートによって問題を解決したケースです。
A社の場合
老朽化した受発注システムのサーバ移行と延命対応
受発注管理システム（CentOS 5上でPHP 5.2＋独自フレームワーク動作）について、ご相談を受けました。開発を担当していた会社が既に撤退しており、社内に詳しいエンジニアも不在。更にレンタルサーバのPHP 5提供終了が迫り「システムが止まってしまうのでは」と大きな不安を抱えている状況でした。
担当者様は「とにかく現行のまま動かせればよいので、低コストで何とかしたい…」というご要望で、まずは新サーバーへの緊急避難的なミラーリングをご希望されました。当社では、ヒアリング後速やかにNDAを締結し、ソースコードとサーバ環境を診断。その結果、大きな改修をせずともPHP 5.6環境上で動かせる見込みを立て、最新OS上に、PHP 5系の動作環境を再現しました。
現行サーバーの老朽化もあり、新サーバーへアプリケーション一式をまるごとコピーして動作検証を実施。いくつかPHPバージョン差異によるWarningが出たものの致命的なエラーはなく、設定調整でクリアできるレベルでした。これにより、本番サイトをほぼそのまま新環境へ移行し、並行してHTTPS化も実施。従来はHTTPアクセスのみだったため、証明書導入とリダイレクト設定を行い、無事に常時SSL対応も完了しました。
主な対応
- ドキュメントが存在しない機能仕様をソースコードから解析し可視化（特に、複雑な権限制御部分は詳細に調査）
- 新サーバー環境（CentOS 7/PHP 5.6互換モード）を構築し、既存サイトを丸ごとコピーして検証
- HTTPS対応： SSL証明書を導入し、Apacheのバーチャルホスト設定をHTTPS用に調整
- 定期メール送信機能の不具合を修正（エラーで送れていなかった月次報告メールを正常化）
- 金額計算ロジックのバグ修正（総額表示が稀にズレる問題を解消）
- CSVエクスポート時の文字化け対策（SJISで出力していた部分をUTF-8+BOMに変更しExcelで読めるよう対応）
新環境への移行後は、安定稼働を確認しつつ、月数時間のスポット保守で様子を見ています。将来的な全面リプレースまでの「つなぎ期間」を安全かつ安価に確保できたと、お客様にも大変喜んでいただきました。
B社の場合
PHP 5アプリのPHP 8対応と長期保守への移行
会員向けポータルサイトをPHP 5.3＋CakePHP 2系で運用していましたが、ホスティング会社から「PHP 5サポート終了とサーバ刷新」の通達がありました。自社内にPHPに詳しい技術者はおらず、当初は「この機会にシステムを作り直すしかないか…」と検討されていたとのこと。しかし、見積もりの結果、再開発には多大な費用・時間がかかることが判明。そこで代替案として、当社にご相談があり、既存システムをアップデートして延命するプランを提案いたしました。
まずは、現行ソースをお預かりし調査したところ、ビジネスロジック自体は堅実に作られており、コードの非互換部分さえ直せば、最新PHPでも十分動くことが分かりました。そこでステージング環境で、PHP 8.0上での動作テストを実施し、発生したエラーを洗い出し。前述のような各種非推奨関数の置き換えや、CakePHP独自実装部分の修正（例えば、一部プラグインがPHP 8未対応だったため代替実装）を行い、PHP 8環境で、全機能が正常に動作することを確認しました。並行して、サーバOSも最新のLTS版に更新し、本番サイトをまるごと移行しました。
主な対応
- PHPコードの互換性改修： 古いコンストラクタ記法や削除された関数を全て修正し、エラーや警告が出ないことを確認
- フレームワーク周辺のアップデート： CakePHP 2系のままPHP 8対応するため、一部ライブラリを差し替え（利用中の認証ライブラリを現行版に変更する等）
- セキュリティ強化： PHPアップデートに伴い、hash関数や暗号化処理を見直し。パスワードハッシュをより安全なアルゴリズムに変更し、管理画面ログインに二段階認証を導入。
- コンテンツ更新支援： サイト内の定期コンテンツ（ニュースや画像）の差し替え作業を支援し、運用フローをドキュメント化。
移行後、システムはPHP 8.0 + 最新OS上で安定稼働しています。お客様からは「最小限の改修で、最新環境に追従でき、大幅なコスト削減になった」と評価いただき、引き続き、月次保守（15時間プラン）で新機能追加や小改善の要望にもタイムリーに対応しています。
C社の場合
レガシーシステムの延命 vs. 新システム移行の検討と最適解の選択
C社は、情報メディアサイトを約10年間運用してきましたが、システムがPHP 5＋独自CMSで老朽化していたため、「この際、WordPressなどのプラットフォームに乗り換えようか」と検討していました。ただ、大量の既存データ（コンテンツ情報や会員データ）の移行や、新システムへの再適応に不安もあり、当社に現行システムの診断をご依頼いただきました。
調査の結果、現行システムは確かに古いものの、安定して動作しており、データ構造も整っていることが判明。機能面でも大幅な追加要求はなく、「大掛かりな移行をしなくても、今の仕組みを活かした方がメリットが大きい」という結論に至りました。お客様と協議の上、新システムへのリプレースを一旦見送り、現行システムを延命しつつ、必要な改良を加える方針となりました。
主な対応
- 段階的なアップデート計画の策定： まずは、PHPと主要ライブラリを最新互換版へアップデートし、その後、不要機能の削減やコードリファクタリングを行う工程で合意
- 不要機能の整理： 過去に使われていたが、現在は不要となっていたモジュールを無効化し、コードとUIを簡素化（将来のメンテナンス性向上と不具合発生リスク低減）
- UIデザインのリニューアル： システム内部を変えず、フロントエンドのHTML/CSSだけ刷新することで、ユーザー印象を一新。スマホ対応も実現し、ユーザビリティ向上。
- 性能面の強化： ページ表示が遅い箇所にページャーを導入し、大量データを扱う画面でもサクサク閲覧できるよう改善。合わせてページキャッシュを設置し、サーバ負荷を軽減。
結果として、現行システムの延命が最善策となり、お客様はデータ移行や新システム習熟のコストを負担せずに済みました。その後も必要に応じて小規模改修を重ね、現在も十分実用に耐えるサイトとして稼働中です。「レガシー = すぐ捨てるべきではないと分かった。柔軟に提案してもらえて助かった」と嬉しいお言葉をいただいております。
お問い合わせ
PHP 5系システムの延命サポート（保守運用）についてのご相談・お問い合わせは、以下より、お気軽にお寄せください。
お分かりになる範囲で、現在のシステム環境を、教えてください。
※NDA（秘密保持契約）締結後でも可能です。
サーバOS、データベース、プログラム言語、フレームワーク、プラグイン、ミドルウェア、および、各バージョン。ドキュメント書類の有無など。
まずは、現状のお困りごとをぜひ、お聞かせください。
その上で、（お化粧せずに）、当社で、できること・できないことの、
すり合わせをさせてください。
まずは、小さなところから、ご一緒できれば光栄です。
会社概要
株式会社ドリーム・シアター
IT／AI × エンジニア教育 × 人材紹介
・Webシステム開発 （PHP5系～TypeScriptモダン開発～AI連携まで）
・クラウドサーバ設計／構築
・就職／転職のための無料ITスクール「MINARAI（ミナライ）」 ※旧・無料PHPスクール
・人材紹介会社SaaS「決まるキャリアbase」
・RAG構築・改善、データ整備
・AI面接対策サービス「SHITATE_AGE（シタテアゲ）」
※有料職業紹介事業許可番号：13-ユ-305399
※労働者派遣事業許可番号：派13-316812
※BHAG：IT／AI＋セールスライティング＋会計＋英語を、実務で学ぶ専門学校の設立（理論＋実践×3倍の職業訓練学校)
住所：〒170-0014 東京都豊島区池袋1-16-17 カワムラビル3F-A
TEL：090-3509-3242（留守電いただければ、24時間以内に折り返し致します）
メール： info@dt30.net
代表者紹介
中田斉道（なかた・せいどう）
人材紹介23年、ITエンジニア教育18年、Webシステム開発15年
大学卒業後、経営コンサルティング会社にて、セールス・マーケティング専門の人材紹介事業の立ち上げに参画（IT/Web業界担当）。新人賞受賞（2004年）。2005年8月、最年少マネージャー（当時）として昇進。
その後、同企業にて、ITコンサルティング事業を立ち上げる。2010年12月に起業し、現在は、Webシステム開発と、人材紹介（Webエンジニア／ITコンサルタント）を行う。
●出身地： 兵庫県加古川市（母親の旧姓は加古さん）
●現住所： 東京都北区在住（私・妻・長女10歳・次女8歳）
●出身校： 加古川東高校（新聞部）、東京理科大学 基礎工学部（ロック研究会をクビに→ジャズ研究会へ）
●趣味： 世界遺産巡り(現在26ヶ国)、プログレ・メタル演奏（担当：ドラム）
●モットー： 苦労/困難/失敗/敗北/挫折/喪失/孤独/逆境は、過去の固定概念を手放すチャンス！
●StrengthsFinder： 最上志向、原点思考、包含、コミュニケーション