テーマは「実行環境と開発環境の棲み分け」です。
業務システムの作成を請け負っている会社(ソフト開発企業)を例として検証してみます。
パッケージを開発し販売している会社もありますが、今回はパッケージでもカストマイズを行っている、顧客ごとに新規で開発を行っている会社を例とします。
これらの会社は複数の顧客の業務システムを取り扱っています。ゆえに社内環境は顧客毎に棲み分けされています。それらはサーバー機器の中で明確に区別し保管され、セキュリティについても顧客単位に関係者のみアクセスできるようになっています。
一旦、顧客の運用が開始されると後は、問い合わせ・調査に利用するだけなので環境としては一つで良いことになります。（実行環境と開発環境が同一環境）
只、業務システムは顧客からの改造要求により常に改変されています。この場合、ソフト開発企業では一般的にどのような環境、管理をしているかを見てみます。
１．棲み分けされている領域
１．１．実際に顧客のサーバーに格納されている領域（外部環境）
厳密にはプログラムのソースコードは保管されていません。
(以下は社内の領域)
１．２．顧客の業務システムが最新状態で保管されている領域
①プログラムの追加・修正・削除はできません。
②データ(テーブル)のレイアウト変更はできません。
③プログラムを起動し処理を行うことはできません。
注)バックアップとして保管しています。
１．３．顧客の業務システムの改修または改造を行うための領域
上記①②③全てが可能です。
改修または改造が顧客に納品され一定期間何もなければ、１．２．の領域へ反映されます。
２． 実行環境と開発環境
前述１．を実行環境と開発環境に棲み分けした場合、以下が想定できます。
【実行環境】 １．１．実際に顧客のサーバーに格納されている領域
・顧客(又は自社)の実データが格納されている。
【資産環境】 １．２．顧客の業務システムが最新状態で保管されている領域
・テストデータが格納されている。
【開発環境】 １．３．顧客の業務システムの改修または改造を行うための領域
・テストデータが格納されている。
自社で開発する企業は、実行環境と資産環境は、同一環境で良いのではと思われるかもしれません。特にFileMakerはプログラムのソースと実行ファイルの区別がないため棲み分けする意味がないように思われますが、あえて区別して管理すべきと思います。
実行環境に対して、システムの改修・改造を適用する場合は十分な事前テストを経てから行いますが、仮に適用後に不具合が発生した場合に緊急措置として前の状態に戻すことがあります。この場合、資産環境から実行環境へ実データ以外を戻すことになります。
注)改造・改修したものを開発環境から実行環境へ適用する時も同じです。
今回の改修・改造がデータ(テーブル)のレイアウト変更を含む場合、通常それらは項目(列)を追加する形でのレイアウト変更とし、データ(テーブル)レイアウトが最新の状態であっても、プログラム(レイアウト、スクリプト)を前の状態に戻し、運用に影響が出ない改修・改造を行います。
☞ 業務システムの改修・改造の中でデータ(テーブル)のレイアウト変更がある場合、 既存の項目に対する変更はせず、新たに項目を追加し対応することが鉄則となります。
改修・改造したものを開発環境から実行環境へ適用した瞬間、資産環境のみ他の環境と差異が発生します。一定期間に何もトラブル等が発生しなかった時点で、開発環境から資産環境へ改修・改造を適用し、この時点で同じ状態になるよう運用します。
３．FileMakerの分離
実行環境、資産環境、開発環境に、業務システムを棲み分けする目的・用途について見てきました。
もう一つの重要な要素として、FileMakerでの分離があります。
(ネットで有用な事例等がありますので詳細はそれらを参照してください。)
FileMakerではない環境の場合、例えばデータベースはOracle、プログラムは、VB.Netなどでは、元々データベースとプログラムは分離されています。
プログラムの改修・改造したものを実行環境へ適用する場合、改修・改造したプログラムのみを実行環境へ複写します。
テーブルをレイアウト変更した場合は、実行環境のデータベースに対して、項目(列)の 追加を実施します。この時、追加した項目(列)に対して予め決まった値を設定する項目(列)、デフォルト値を設定するだけで良い項目(列)などがあります。
前者の場合、前もってSQL文にてそれら項目(列)に値をセットするよう作成しておきます。
後者の場合は項目(列)を追加する際にデフォルト制約にて設定します。
項目(列)を追加する場合も前もってSQL文(厳密にはDDL文)を作成しておきます。これらの作業は手順書(兼、チェック表)を事前に作成し実行環境に対して一つ一つ確実に実行し、完了の都度、☑を記入していきます。
<手順書の例>
No 手続き名 SQL文 ☑ 実施者 備考
--- ---------------------------- --------------- ---- --------- ----------
01 テーブルに列を追加 All Alter01 ▢
02 コンバージョン AllConv01 ▢
03 ・
これらの作業はFileMakerでも同様に発生します。
但し、FileMakerがデータとデータ以外(レイアウト、スクリプトなど)に分離されておらず、一つのファイルで利用していると大変な時間と労力およびリスクが伴う作業を行うことになってしまいます。
・実行環境を停止し、FileMakerのファイルをバックアップする。
・実データを全てエクスポートして外部ファイルとして保存する。
・開発環境のテーブルのレコードを全て削除した後に、エクスポートした外部ファイルから、該当のテーブルへインポートする。
・開発環境のFileMakerのファイルを実行環境へ複写する。
上記は一つの例ですが、業務システムで取扱うテーブルの数には違いがありますが、一般的な流通業の場合、Oracleのテーブル数として少なくとも100から200ぐらいは存在します。（製造業になると３倍以上）
エクスポート、インポートをスクリプトで作成し自動的に実施させることも考えられます(不具合がないことが必須)が、それらを実行するには前もってテストを実施し、確実に実行できることを担保しておく必要があります。
但し、通常ではこのように自動的にエクスポート、インポートにてデータを操作することは行いません。テーブルのレイアウト変更を実行環境へ適用する場合は確実に一つ一つの作業を実施し、結果を確認して次の作業を行うことが最善の方法です。何故なら、上記下線のスクリプトは今回の改修・改造するプログラムと同じ扱いであり、事前のテストで合格しても実際の運用になった時に、不具合が発生しないことを１００％保証することはできません。
かつ、実データを一括して操作するため、途中でエラー等の問題が発生した場合、移行作業自体に致命的な支障(日程、コスト)が出ます。最悪の場合、業務を停止することにもなりかねません。
すみません、ブログの制約（本文は30000文字まで）エラーとなり全てをアップできませんでした。近々に、続きをご紹介しようと思います。
以上です。
