
■ 開発環境
開発するプログラムの作成は自社内で行ってもらう事になったのですが、問題は環境の準備です。
物理的な面については、旧マシン室(数年前にIDCに移動したので現在は空き部屋)を使うことにしました。多少の問題はありますが、机、椅子、パソコンもあるし、元がマシン室だけあって空調やLAN環境も整備されているし、プリンタも設置されているので問題なさそうです。
後はソフト面なのですが、こいつが悩みました。
■ セキュリティ
勤め先では、外部の方に与えるセキュリティ標準というのが存在しません。というか、自社開発しかしていなかったので必要がなかったんですよね。ってことで、一から考えなければなりません。
まずインターネットについては、開放することにしました。WEBフィルタリングサーバを通す仕組みになっているので、使用状況の監視が可能だからです。プリンタについても、印刷ログの取得は可能なので開放します。
少し考えて、ActiveDirectoryへのユーザー追加は見送りました。今回開発対象になる基幹システムは、完全に独立したシステムになっているので、ActiveDirectoryに参加しなくても支障はないと思ったのです。ってことで、パソコンにはWorkGroupでログインしてもらう事にしました。
ただ、ファイルサーバはActiveDirectoryと連携しているので、ActiveDirectoryに参加しないということは、ファイルサーバを見る事が出来ません。これでは、データ共有に支障が発生します。そこで、NASを用意してファイルサーバーの代替とすることにしました。
■ 情報共有
NASで情報を共有するのは良いのですが、こいつはファイルサーバと違ってバックアップを取っている訳ではないので壊れた時に復旧する手段がありません。そこで、NASについては純粋な作業場所として使う方針としました。
具体的には、こうです。
A:私
B:開発者
① Aは、ファイルサーバに必要な資料(仕様書など)を保存
② Aは、①からNASに開発に必要な資料をコピー
③ Bは、開発したソースやテスト資料等をNASに保存
④ Aは、NASに保存されたソースやテスト資料をファイルサーバにコピー
ちと煩雑ですが、共有する必要がある資料は限定されると思われたので、問題ないと思ったんです。
・・・思ったんですよ。
■ 失敗事例
結果、失敗しました。
最初の開発段階では上手くいったのですが、開発作業の後半になるにつれて管理が難しくなって行きました。色々と事情はあるのですが、要するにファイルサーバとNASのどちらが正なのか、っていう切り分けが難しくなっていったんですね。仕様変更、障害、進捗、etc・・・まぁ、思っていた以上に共有すべき物が色々あった訳です。
こんな事なら、素直にActiveDirectoryにユーザーを追加して権限を与えれば良かったです。ついでに、グループウェアにもユーザーを作って(グループウェアはActiveDirectoryと非連携)社内での情報共有を出来るようにするべきでした。
■ 後書き
実は、こうなることは最初から分かっていました(思った以上に大変だっただけです)。では何故今回のような手を打ったかというと、ActiveDirectoryやグループウェアの管理者が私ではないので折衝が面倒だったからです。
別に、社内手続き(伺い書とか)が面倒って訳ではないです。そういう手続き以前の問題として、出来ない(訳の分からない)理由を並べて抵抗する姿が目に浮かんだんですよね。
・・・疲れる。
前回:子会社との合併に伴うシステム移行 No11 既存機能の流用
次回:子会社との合併に伴うシステム移行 No12 開発環境
投稿記事の一覧:http://harikofu.web.fc2.com/
--- blog end ---
スポンサードリンク


