【実録！社内SE】とある情シスが内製で手掛けた構築・移行案件の苦労話

今回の記事では、私が今の会社に転職してきて手掛けた様々なシステム構築や移行案件の概要を色々と紹介していこうと思います。

事業会社の情報システム部門ではよくある話ですが、自社内にITの価値や作業の難易度を適切に理解する人がおらず、情報システム部門が苦労しながら構築したシステムや完遂した作業に対して、その苦労や価値に見合う評価をしてもらえないことは多々あります。

私自身もやはり同じような不満を抱えており、今の会社に入社してからも様々なシステム構築案件を手掛けてきましたが、その苦労や成果はあまり理解してもらえません。
それ自体は仕方がないことだと思いますが、それでもたまには誰かにほめてもらいたい、「スゴイ！」と言ってもらいたい気持ちはあります。

そこで、ブログの記事で自身が手掛けたシステム構築案件や移行案件を紹介して、インターネットの住人達に褒めてもらおうと思った次第です。

 

これまで手掛けたシステム構築案件など

当項では、冒頭で記載したように、過去のシステム構築案件を色々と紹介していこうと思います。
因みに、この記事で紹介する様々な案件は、基本的に私が一人ですべての工程の作業を行っています。

また、案件によっては、完了後に当ブログ内の記事として紹介しているケースも多々あるため、そのような案件については、記事のリンクも掲載していきます。

 

自社の基幹サーバー群をVMware ESXiに移行

私が入社して最初に任せられたのはこの案件です。
そもそも、情報システム部門で中途採用をおこなうにあたり、この案件に対応できそうな技術力のある人を前提に人材を探していたようです。

入社当時は、自社の基幹システムやグループウェア、その他の業務システム用のサーバーは、NTTコミュニケーションズ(以降NTTコム)のIaaSで稼働していましたが、そのIaaSがサービスを終了することになり、移行先として選定されたのが、IIJの「GIOインフラストラクチャーP2」というサービスでした。

NTTコムのIaaSは、専用のWebコントロールパネルがあり、そのなかでサーバーなど仮想マシンのインスタンスを作成したり、仮想ネットワークを構築して利用するサービスでした。
IIJのサービスはもっとシンプルで、「IIJのDC内にESXiをインストールしたサーバーとデータストア用の共有ストレージ、専用のネットワークを用意するから好きに構築してね！」というものです。

本来はIaaSからの移行なので、AmazonのAWSやMicrosoftのAzureなど有名どころへ切り替えるという発想になりますが、とある制約により一般的なIaaSへの移行ができませんでした。
その制約とは、「移行対象のサーバー群にWindows 2000 Serverが含まれている」という点です。
そのWindows 2000 Server は基幹系Webシステムのアプリケーションサーバーとして稼働していたため、今回の移行をきっかけに廃止！という訳にもいきません。

こんなレガシーOSを使わせてくれるIaaSなんてありません。
かといって、今更物理サーバーに戻すこともできません。

そこで移行先のプラットフォームとして選ばれたのが、VMware ESXiです。
多くの人は知らないと思いますが、割と最近までESXiではWindows2000をサポートしていました。

現在ブロードコムが公開しているゲストOSサポート表を見ると、ESXi 7.0 までしか遡れないため確認はできませんが、確か ESXi 6.0 か 6.5ぐらいまではサポート対象に含まれていたと記憶しています。

よって、Windows 2000 Server を仮想マシンで稼働させるには、ESXi を利用するしかないことがわかりました。
但し、完全にオンプレ環境でESXiの仮想基盤を作成しようとすると、冗長化されたホスト用筐体の調達や共有ストレージの調達、それらの構築も必要です。
また、VMware vSphere(ESXiを含む製品スイート)のライセンス購入も必要になります。
膨大なコストと技術力が必要になります。

それらの諸々の問題を解決してくれたのが、IIJのサービスでした。

ここまでがサーバー移行が必要になった経緯と、移行先選定おける選定条件の説明です。

余談ですが、最初に構築してから、その後ESXiのバージョンアップを2回ほど実施し、現在はESXi 7.0.3の環境で運用していますが、Windows 2000 Serverは元気に稼働しています。
サポート自体はされていませんが、意外と普通に使用できて問題も発生しません。
ESXiは優秀だと思います。

 

この案件で大変だったところ

当時を振り返ると、我ながら頑張ったなと思っています。

私自身、昔はSIerで顧客が契約しているデータセンターのサーバーやネットワーク機器の構築や運用もやっており、プロマネとしてそういったプロジェクトの管理などもしていたため、サーバー構築やネットワーク設計における基本的な知識は持っていました。

また、転職前は別の事業会社の情シスとして、Hyper-Vを使用した仮想環境で仮想サーバーを運用していたため、仮想マシンの扱いもある程度は理解していましたが、前職で使用していたHyper-Vはシステム会社が構築した環境を運用していただけであり、ESXiを1から構築したこともありませんでした。

また、自社にもESXiの構築方法について教えてくれる人はおらず、またその構築を支援してくれる外部のSIerもいませんでした。
よって、VMwareの公式ドキュメントを調べながら、独学でESXiを構築しました。

因みに、このIIJのサービスでは、ESXiのホストは冗長化のために2台提供されていたのですが、当時はホスト1台のみに環境を構築して、サーバー群を移行して稼働させるところまでが精いっぱいの状況であり、クラスタを作成しホスト2台で冗長構成を組むというあるべき状態にできたのは、環境を構築して運用を開始し、それから数年経った後でした。

尚、このESXi環境に移行するサーバー群は、すべてVPN経由でアクセスされるものばかりではなく、インターネットからアクセスさせる公開系サーバーも複数ありました。

よって、IIJのサービスとして提供されるネットワーク、ESXiの仮想ネットワークを利用しつつ、ESXiの仮想マシンとして導入した仮想ルーターでパケットフィルタリングやNATなども適切に設定してあげる必要がありました。

この辺りのネットワーク設計についても、過去に経験はありますが、コンフィグを作成するなどの実作業はそれほど経験がなかったため、クセのあるルーターだったたこともあり、大変苦労をしました。

また、この案件で大変なのは、ESXiの環境構築やネットワーク構築だけではなく、NTTコムのIaaSからサーバー群を移行する必要があり、それも大掛かりな作業です。

稼働するプラットフォームが異なる以上、仮想マシンのディスクイメージを作成して移行先環境にデプロイするといった方式の移行はできません。
移行対象のサーバーごとでESXi上に空の仮想ディスクを作成し、そのディスクに対してOSのインストールメディアでOSをインストールしていきます。

OSをインストールしたら、次は現行サーバーと同じ設定をいれていきます。
RDBMSやWebサーバーなどのミドルウェアも同様に同じ環境で再構築し、データベースに対して日々発生する更新内容や、様々なファイルの変更については、移行先サーバーに対して同期を取るバッチ処理を作成、常に同じ環境が維持されるような仕組みも作りました。

現行の環境を手作業で移行するためには、対象のRDBMSに対する知識も必要ですし、Windows系のWebサーバーならIIS、LinuxならApacheなどに関する知識も必要です。
仮想基盤の構築については未経験でしたが、個々のサーバーの構築については、過去に色々と経験をしていたため、比較的スムーズに構築ができたと思います。

 

この案件で得た知識や経験

やはり一番大きいのは、ESXiの構築に必要な知識や経験を得たことです。

最近では、VMware社がブロードコム社に買収され、vSphereのライセンスをこれまでの買い切りからサブスク形態に変更したことにより、ユーザーは利用費用が大きく値上がりし「脱VMware」という風潮が広がっています。

それでも、幾つかある主要なハイパーバイザ製品のなかでは、ESXiの安定性や機能は特出しており、利用しているユーザーも多く、ESXiの構築経験はITエンジニアとして大きな価値だと言えます。

また、いったん構築が完了した後は、その構築した環境を運用をしていくことになりますが、仮想マシンが増えて、データストアの容量が足りなくなればデータストアを追加し、その際には「Storage vMotion」の機能を利用して、無停止で仮想ディスクが配置されたデータストアを移動させることになります。

また、負荷分散の目的や、ホストのメンテナンスのために、仮想マシンを停止することなく別のESXiホストに移動させる場合は、「vMotion」を使用します。
こういった各機能は、運用しながら覚えていきました。

構築中は大変でしたが、振り返って見ると、この経験は非常に有益だったと思います。

また、結果的にESXiについて多少詳しくなったこともあり、当ブログでも幾つか記事を書いています。

記事を作成した当時に使用していたESXiのバージョンを元にした内容のため、今ではかなり内容が古くなってしまっているものも多々あります。
できればリライトしたいところですが、それも結構大変なので、どうしようかなと考えています。

 

SQL Server 2000 から 2017 への移行

私が今の会社に入って驚いたのは、前項でも記載したように、未だにWindows 2000 Serverが現役で稼働していることとともに、SQL Server 2000 も基幹のデータベースとして使用されていたことです。

SQL Server 2000 は、私が大昔にSIerをやっていた頃でも殆ど見かけないバージョンであったため、それをまた運用することになるとは夢にも思いませんでした。

但し、当然私はSQL Server も2000のまま使い続けるつもりもなく、そもそも、そのSQL Server 2000 を稼働させていたのは Windows Server 2003 だったこともあり、早々にマイグレーションの計画を立てて移行を進めました。
因みに、この案件を実施したのは2020年の前半頃です。

 

この案件で大変だったところ

SQL Server を始めとしたMicrosoftのミドルウェア製品では、「互換性レベル」という基準があり、各バージョン間の機能互換を定義しています。

詳しくは以下のリンク先をご参照ください。

ALTER DATABASE 互換性レベル (Transact-SQL) - SQL Server

指定したバージョンのデータベース エンジンと互換性があるように、Transact-SQL およびクエリ処理の動作を設定します。

learn.microsoft.com

このリンク先に書かれているように、SQL Server 2000 の「既定の互換性レベル」及び「サポートされている互換性レベル」は共に 80 です。
SQL Server 2017 の「サポートされている互換性レベル」の最も小さい値は 100 です。
ということは、2000 と 2017 のバージョン間では互換性がありません。

互換性がないバージョン間でのマイグレーションにおいて最も影響があるのは、移行元インスタンスから出力したデータベースのバックアップを、移行先インスタンス側でそのままリストアすることができない部分です。

移行元のインスタンスでデータをいったんcsvなどテキストベースに変換し、それを移行先で取り込むことであればできるでしょうが、それではデータの欠損や意図しない変換が起こる可能性もあり、また移行作業も非常に煩雑になるため現実的ではありません。

インスタンス内の個々のデータベースをまるっと移行先で取り込む方式が最も安全であり、合理的です。

それをするためには、両バージョン共通の互換性レベルを有する中間バージョンのSQL Server を用意して、そのインスタンスを中継してデータを移行することが必要になります。

その中継用のSQL Server のバージョンは SQL Server 2008 又は、SQL Server 2008 R2 です。
このバージョンであれば、互換性レベル80と100に対応しています。

私がこの作業に着手するタイミングでは、マイクロソフトは SQL Server 2008 の評価版インストーラーを公開していたため、その評価版を使用して中継用のインスタンスを作ることができましたが、当案件が完了してしばらくしたら、Microsoftは評価版の公開をやめていました。
作業に着手するタイミングが少しでも遅ければ、SQL Server 2008 の調達が困難になったかも知れません。

また、SQL Server 2008 をインストールできるOSも限られており、SQL Server 2008 が対応しているOS は、Windows Serverの場合、Windows Server 2012 又は、Windows Server 2012 R2 です。
こちらも同様に評価版のインストーラーをMicrosoftのサイトからダウンロードして、中継用環境を構築しました。

中継用環境や移行先の環境を構築しただけでは作業は終わりません。
データベースサーバーのマイグレーションで最も重要なのは、データの移行作業です。

手作業でやることもできますが、新しい移行先の環境と移行したデータを使用して、社内の各システムが正常に動作するかのテストなども必要になることから、できればデータ移行作業自体も自動化し、毎日新しいデータが移行先にも入っている状態にしておきたいところです。

よって、移行元のSQL Server 2000 からデータベースのエクスポート、中継用サーバーではデータベースのインポート及びエクスポート、移行先のSQL Server 2017 ではデータベースのインポート、各サーバー間でバックアップファイルの転送といったすべての処理を自動化させておくことになります。

それをするためには、SQL Serverのジョブ機能を活用したり、batファイルにコマンドを書いてタスクスケジューラーなどから実行させるといった作り込みが必要です。

この案件を完了させた後に、この作業が誰かの参考になればとい思い、当ブログの記事としてまとめています。
当時の私の作業内容をほぼそのまま記事にしているため、よければご一読ください。

後は、SQL Server 2017 を新しいサーバー環境に新規構築することになるため、SQL Server自体のインストールや、インストールにおけるパラメーター設計なども必要になります。
基幹のデータベースであるため、ここも適切に設定しておかないと、ピーク時の処理を捌けなくなり、社内全体の業務が止まりかねません。

SQL Server はSIer時代から関わることが多かったため、パフォーマンス関連の基本的な知識はあり、SQL Server 2017 の環境構築で大きく困ることはありませんでした。

後、SQL Server 2000 から 2017 へのバージョンアップであり、互換性レベルを跨ぐ移行であるため、SQL Server 自体の内部仕様も色々と変更されています。

例えば、互換性レベルが変わったことにより、ストアドプロシージャなどで使用されるTransact-SQL(T-SQL)で一部の仕様が廃止されていたりします。

他にも色々な変更があるため、可能であれば、SQL Server 2017 の環境を参照して、社内で使用しているすべてのシステムのすべての機能でテストをするのが望ましいのですが、それをするだけの労力もコストも掛けられないため、現実的には難しいです。

よって、ある程度のシステムテストで妥協し、実際に本番環境の切り替えを実施した後で、SQL Server のバージョン変更に起因していると思われる問題が発生したら、その都度調べて対応していくという方針を取らざるを得ないのですが、それは非常に不安です。

困ったときにベンダーに泣きつけるならいいですが、内製オンリーで開発しているシステムや、過去に外注で開発し、今はその会社と取り引きもなくなり、泣きつく先のないシステムもあります。
そのため、本番環境の切り替え前も不安ですし、切り替えた後も、数カ月は心配でしかたがなかったです。

 

この案件で得た知識や経験

この案件をやるまで、商用環境のSQL Server のマイグレーションにおいて、すべての工程を私自身で実施したことはありませんでした。
また、互換性レベルを跨ぐバージョンアップであり、通常のマイグレーションよりも面倒な分、非常に勉強になりました。

また、Microsoft製品において、サポート期間や互換性レベルを考慮して適切な時期にリプレイスやマイグレーションをしていく限り、移行は比較的容易におこなえるようになっており、そのサイクルを逸脱すると、途端に移行が困難になることも身に染みて理解ができました。

 

ADのDCをWindows 2000 ServerからWindowsServer 2019へ移行

これもレガシーな環境からの移行案件です。

企業のPC管理、ユーザーアカウント管理において、ActiveDirectory(以降AD)を導入しているか否かで、システム管理者の手間は大きく差が出ます。

ADを導入していない企業の場合、PCのログインユーザーは端末内にしか情報を持たず、システム管理者が一元的に管理することは困難です。
また、ファイルサーバー内の各共有フォルダに対するアクセス権の管理も非常に面倒になります。

入社時にADは導入されていると聞き、そこは一安心しましたが、そのADのドメインコントローラー(以下DC)はWindows 2000 Server で稼働していることが分かり驚愕しました。

逆に言えば、20年前に発売されたサーバーOSが現代でもそれなりに安定して稼働している事実に直面することで、Windows 2000 のアーキテクチャって優秀だったんだなと気付かされました。

とは言え、このDCは前項で紹介したESXiの仮想基盤で稼働しているわけではなく、本社内のサーバールームに設置された物理筐体で稼働しています。
筐体が故障した際には、前任者が部品取り用の筐体からパーツを移植しつつだましだまし使用している代物であり、いつ使えなくなるかはわからない状態でした。

本来DCは、そのネットワーク内のDNSサーバーであり、個々のユーザーの認証情報を保持し、共有フォルダなどネットワーク資源のアクセス管理も行い、端末の時刻同期にも使用され、グループポリシーの管理にも利用し、非常に重要な役割を持ちます。

よってDCが障害で止まってしまうと大変であり、古い筐体を使い続けるリスクは非常に大きいと言えます。
また、筐体が故障した場合に、前任者のように部品取り筐体からパートを入れ替えて修理するといった泥臭い対応もしたくないため、さっさと新しい筐体とOSを調達し、DCを最新の環境に移行することにしました。

 

この案件で大変だったところ

前項のSQL Serverの移行でもそうでしたが、DCでもWindows Serverのバージョンごとで互換性レベルが決まっています。
尚、DCの場合は「互換性レベル」という名称ではなく「機能レベル」と呼びます。

今回のWindows 2000 Server から Windows Server 2019 への移行では、やはり互換はありません。
よって、SQL Server のケースと同様に、互いに対応した機能レベルを包括する中継用サーバーを用意し、その中継用サーバーを経由して、DCの各種機能や設定を移行することになります。

SQL Server の場合は、中継用サーバーを使用して中継をさせるのは、各データベースのダンプファイルのみであり、現行の互換性レベルへ変換するためには、中継用サーバー側でデータベースのインポートとエクスポートをするだけです。
中継用サーバー環境さえ用意できれば、互換性レベルを跨ぐ変換は容易と言えます。

今回のDCに関しては、そんな単純な作業では済みませんでした。
移行に必要だった作業の流れはざっくりと説明すると以下です。

当時の大変だったこれらの作業を世の中に公開すれば、誰かの役に立つこともあるかもしれないと思い、記事にしたのが以下のリンク先です。
記事を書くのも大変でしたが。
興味があればご一読ください。

因みに、SQL Server のときもそうですが、Microsoftの製品は、互換を保証している範囲のバージョン間で移行をする場合は、移行用のツールを用意してくれていたり、移行用の機能が実装されていて簡単に移行できるようになっています。
DCの場合で言えば、移行先の新しいバージョンのWindow ServerをDCに昇格させ、FSMOの役割を移譲し、旧DCを停止させたうえで「機能レベル」の設定を変更するだけです。

そもそも、稼働しているサーバー筐体が古くなればハードウェア保守が切れるなど別の要因もあり、適切な時期に新しいバージョンに移行していくべきものです。
そのサイクルから逸脱することで、こんなに大変な作業が必要になるんだなということを痛感させられた案件でした。

あと、移行作業も大変ですが、新しいDCに切り替えた後に問題が起こらないことを事前に検証する必要もありましたが、特殊な環境下での移行作業ということもあり、充分には行えませんでした。

本番切り替え時においては、日中でユーザーがPCを使用している真っ最中の時間に、旧DCの筐体に挿さっているLANケーブルを抜いて、旧DCと同じIPアドレスを振った新DCの筐体にLANケーブルを挿し直すという荒業で無理やり切り替えています。

本来であれば、唐突にDCが別のインスタンスに変わることになり、ケルベロス認証でやり取りされるチケットの情報や、認証以外の様々な情報で不整合が発生し問題が起きそうなものですが、意外と目に見える問題は起こらず、静かに切り替えが完了しました。

元々旧DCは、ユーザーの認証情報の管理や、グループを作成してファイルサーバーなどのアクセス権の管理程度でしか使用しておらず、GPOも殆ど作られていませんでした。
このように、旧DCでは最低限の機能しか使っていなかったのが、結果的に上手くいった要因かもしれません。

但し、例えばADではクライアントがDCと通信できない場合に、ローカルで保持する認証情報を使用して認証を行うなどの代替処理が動きます。
表面上は問題がないように見えても、実はこのような代替処理で正常に動いているように見えているだけという可能性もあり、その場合は後から時限的に問題が露呈することになります。
よって、やはりSQL Serverのときと同様に、切り替えを行ったあとも、数カ月は不安を抱えながら運用していました。

 

この案件で得た知識や経験

最近ではテレワークの浸透などにより、従来のADメインのユーザーアカウント管理では対応しきれなくなってきており、「Microsoft Entra ID」などのクラウドベースのサービスに移行された企業も増えているかと思います。

また、クラウドと併用して従来のオンプレADを運用している企業も多く、オンプレのみという企業もやはり多くおります。
情シスとして「Active Directory」は今でも必須の知識であり、必須の運用経験だと考えています。

今回のイレギュラーな移行作業を行うことにより、Active Directoryやドメインコントローラーの深い部分の仕様や機能を意識することになり、大変勉強になりました。
また、互換が保証されたバージョン間の移行であれば、怖いと感じることも無くサクッとできるようになったと思います。
貴重な経験でした。

 

レガシーなグループウェアをガルーン(オンプレ)に移行

またレガシーな環境からの移行案件ですが、私が入社したころは、非常にマイナーなグループウェア製品を利用しており、且つその製品は20年近く前の製品でもあることから使い勝手も悪く、機能も少なく、この時代によくこんなグループウェアで満足できているなと驚きました。

そもそも社内の人たちの多くはそのグループウェアしか知らないわけで、他社の製品や最新の製品と比較することもできない以上、この使い勝手や個々の機能を当然のように受け入れており、現代のグループウェアについての知識や利用経験もある私からしたらとても不憫に思え、何としてもグループウェアをもっと使い勝手のよい製品に入れ替えてあげようと強く思いました。

また、このグループウェアはオンプレ用の製品であり、自前のサーバーで稼働していたのですが、そのサーバーも例のごとく古く、Windows Server 2003 でした。
更に言えば、まだローカルネットワーク内のみでの利用であれば許容もできなくないのですが、グローバルIPを持ち、インターネットからのアクセスもさせていたこともあり、セキュリティ上でも大きなリスクになっていました。

このように色々と問題が多かったグループウェアでしたが、企業においてグループウェアは社内の情報共有や社員間のコミュニケーションの基盤になるシステムでもあり、別の製品に入れ替える話をなかなか進めることができず、その案件を実際に着手して進めることができたのは、私が入社して3年程度経過したあとでした。

グループウェア製品の選定についても振り返ります。
先ず、グループウェアは様々な製品があります。
有名なところでは、「Microsoft 365」「Google Workspase」「サイボウズ Office」「desknet’s NEO」などなど。

個々のグループウェア製品の提供形態と大きく分けると、クラウド型とオンプレ型があり、最近ではクラウド型が主流です。
クラウド型であれば、自前のサーバーは不要であり、ユーザー数毎の月額課金制が一般的です。
オンプレ型であれば、サーバーを用意する必要があり、導入時に初期費用が発生し、ユーザー数に応じて年間の利用費用やサポート費用などが発生します。

昔からある製品の場合は、オンプレ型とクラウド型の両方を提供している製品もありますが、最近ではクラウド型のみしか提供していない製品の方が多いです。

サーバーの構築や運用経験のある技術者が社内に居ない場合や、サーバーを自社で管理したくない場合は、クラウド型を選定することになります。
また、サーバーの構築や運用スキルのある技術者が居たり、構築や運用を外部のシステム会社に委託でき、且つサーバーを自社で管理したい場合はオンプレ型を選定します。
当社の場合は、私がサーバーの構築や運用が可能なため、オンプレ型の導入が可能です。

尚、一般的には、サーバーの維持管理費用は別として、グループウェア製品を利用する費用だけでいえば、オンプレ型製品の方が割安です。

古いグループウェアから新しいグループウェアに切り替えるにあたり、クラウド製品の場合、毎月定額の利用料がネックになります。
ユーザー数が数十や2～3百程度であれば、それほど大きい金額に感じませんが、これが千ユーザー単位の場合、実際には一人当たりの利用費用は変わらないにしても、ぱっと見の利用費用のインパクトがだいぶ違ってきます。
よって、オンプレ製品の方が導入費用の面で社内稟議を得やすい面があります。

当社の場合、当記事で紹介したESXiの仮想基盤があるため、そこに新しく仮想マシンを作り、グループウェア用の環境を用意することが可能です。

尚、純粋なグループウェア製品であれば基本的な機能はどこの製品も同じですが、各製品はグループウェアとして標準的な機能とは別に、製品独自の機能を実装し、それを付加価値としてアピールしています。

後、「Microsoft 365」や「Google Workspase」などは、狭義のグループウェアというより、MicrosoftやGoogleのスイート製品です。
TeamsやGmailなどと連携したり統合して管理できるようなるのが魅力であり、純粋なグループウェアとしての機能は簡素だったり、管理者がカスタマイズして作ることが前提だったりします。
そのため、ユーザーとして利用する場合も、ある程度のITリテラシーが求められます。

当社の場合は、OA事務などパソコン操作をメインとした業務をする従業員より、営業系業務のようにパソコンの操作は限定的な利用に留まる従業員の方が圧倒的に多く、社内のITリテラシーはかなり低い状態でした。

また、昔から使用していたグループウェアも、ログインするとトップ画面に様々な情報を表示するタイプのUIであり、グループウェアを新しい製品に切り替えるにしても、外資系製品のように簡素なUIやシンプルな機能の製品ではなく、ログイン後のトップページに、カレンダーのスケジュールや掲示板がドーン！と表示され、痒いところまで手の届く日本企業的なグループウェアでないと導入は難しいと考えていました。

あと、他にもグループウェアの選定において欠かせない要件もありました。

私は情シスであり、社内のアカウント管理もしています。

社内では複数のシステムやサービスが稼働しており、IDaasやSSOなどのモダンな仕組みはなく、各システムやサービスごとに個別でアカウント管理をしています。

よって、新しく製品を導入するということは、管理するべきアカウントも増えることになり、我々情シスの業務も増えることになります。
しかし、情シスの人員やリソースは有限であり、社内が便利になる代わりに情シスの業務が増えるというトレードオフなシステム導入は私のポリシーに反するのでやりたくありません。

せっかく新しいグループウェアを導入するのであれば、そのアカウント管理業務の改善に繋げられることができる製品が望ましいです。
そのために必要な機能としては、製品のアカウント情報の登録や変更などを外部のプログラムから実行できるようにするための「WebAPI」機能です。

私は多少のプログラミングもできるため、対象のグループウェア製品にアカウント管理用のWebAPIが提供されていれば、基幹システムの社員マスタと連携し、グループウェアのアカウント登録を自動化させることができます。

殆どのグループウェア製品では、アカウントを一括登録するためにCSVデータの取り込み機能は持っていますが、アカウント登録のできるWebAPIを提供している製品はそれほど多くはないです。
このWebAPIの機能有無についても欠かせない要件の一つでした。

これらをまとめると、グループウェアに必要な要件は以下となりました。

これらの要件を満たすグループウェア製品として、サイボウズ社の「ガルーン」ぐらいしか見当たらなかったのと、私が以前勤めていた会社で、「サイボウズ Office」を使用していた関係で、使い勝手なども理解していたことから、最終的に「ガルーン」を選定しました。

 

この案件で大変だったところ

元々使用していた製品は20年前のグループウェアであり、明らかに使い勝手も悪く機能も足りていないのですが、当項の始めに書いたように、そのような感想を持てるのは、あくまで私が他社の製品を利用した経験があるからであって、他社の製品を知らない多くの従業員に対してその不便さを認識してもらい、グループウェアが新しくなることで便利になるという意義付けをして入れ替えの必要性を理解してもらうことは意外と難しいです。

グループウェアの切り替えについて経営陣に話をしても、「特に不便さは感じていない」という返答をもらっていました。

よって、導入費用の決裁を得るにあたり、一番アピールしたポイントは以下です。

要するに、「対象の製品が古過ぎるからトラブっても我々情シスは復旧を保証しませんよ」という論点で入れ替えの必要性を説明しました。
例えるならグループウェアの持続的な利用を人質に取り、新しい製品への入れ替えを交渉したことになります。

経営陣からしたら、グループウェアを新しくすることで従業員の業務が便利になるという点はそれほど重要ではないのですが、グループウェアが使えなくなるという点については問題だと認識しており、そのように脅されたら承諾せざるを得ないでしょう。

このように、経営陣も使用するシステムであり、長年慣れ親しんでそれほど不便を感じていなかったものに対して、それを新しくするための費用を承認させるという部分がまず大変な点でした。

次に大変だったのは、元々使用していたグループウェアを前提に作られた社内業務の調整です。
長年同じグループウェアを使用していれば、そのグループウェアの機能に合わせて社内の業務や運用ルールも作られていきます。
旧グループウェアと同じ機能や類似した機能はガルーンにもありますが、まったく同じではなく多少の違いはあります。

社内のユーザー全員がガルーンの機能に業務を合わせてくれれば問題ないのですが、その変更を素直に受け入れてくれない人は多くいます。
よって、そのようなケースの場合、その人たちの希望に沿うように、ガルーンにカスタマイズを施したり、ガルーンの機能のなかで対応することを諦めて別のプログラムを用意するなど、手間の掛かる交渉や対応が必要でした。

あと、細かいところだと、旧グループウェアでは、特定の部署や特定の拠点の共有アカウントを作成し、従業員個々のアカウントとは使い分けて利用されていました。

部署内や拠点メンバー内で情報を共有しながら他部署とやり取りをしたり、データを受け渡しするといった場合、共有アカウントがあると確かに便利ですが、共有アカウントはセキュリティ上問題があります。

共有アカウントでログインされると、実際にそのアカウントで誰が操作をしたのかが分からなくなり、トラブルが起きたい際の責任の所在が曖昧になります。

また、共有アカウント使用者の一人が、共有アカウントを使用する必要がない部署に移動したとしても、過去に使用していた共有アカウントにログインすることができてしまいますし、そもそも従業員が退職した場合に、共有アカウントのパスワードを変更するなどのメンテナンスしているなら別ですが、現実的にそのような運用を徹底するのは難しく、その結果、退職者であっても共有アカウントにログインできてしまうという危険な状態が起こります。

これらのセキュリティ上のリスクや問題点があるため、ガルーンの導入ではすべての共有アカウントを廃止しました。
但し、当然それに対する反発があり、廃止されると業務ができないという訴えに対して、廃止の必要性を説明し、代替方法を検討して提案するといった対応も非常に大変でした。

グループウェアは自社内の情報共有やコミュニケーションを円滑するためのアプリケーションであり、グループウェアが変わることにより、その情報共有のやり方が変わり、コミュニケーションの取り方や取る対象が変わることになります。
それに対してコンセンサスを取っていくのが大変であり、技術的な苦労よりも、社内の対人的な調整による苦労の方が大きかったです。

尚、ガルーンの導入に伴い、ガルーンに用意されているWebAPIを利用して、アカウントを自動で作成するバッチ処理を作成して大元の人事データと連携させたりする作り込みを行いましたが、そのあたりの実装は比較的苦労することなく行えました。

ガルーンのAPIに関しては、当ブログでも記事で紹介しているので、よければご一読ください。

 

この案件で得た知識や経験

ガルーンの導入では、先ずサーバー環境の構築は私がすべて実施しており、技術的に難しい内容は特にありませんでしたが、良い経験になりました。

また、ガルーンをインストールした後に実施したガルーン内の環境構築については、情シスメンバーで分担しながら進めたのですが、メンバーがそれぞれの役割で協力し合い進めることができ、部署内の一体感に繋がったのでそれも良かったなと。
あと、20年使用したグループウェアを刷新することで、グループウェアを起点とした社内の様々な業務の棚卸や見直しに繋がり、社内業務の効率化や改善に役立ったと感じます。

また、WebAPIを利用することで、ガルーン内の様々な操作や登録を外部のプログラムから実行させることができるため、情シスが担当しているガルーンのアカウント管理にまつわる作業の多くを自動化、無人化することができて、我々情シスの業務負荷軽減にも寄与してくれました。

更にガルーンではPHPやJavaScript、HTMLなどを利用して色々なカスタマイズができ、システム管理者の立場でどんなカスタマイズをしようかと考えるのも楽しいです。

オンプレ版のガルーンならではの裏技ですが、オンプレ版ガルーンであれば、インストール時にMySQLの管理者ユーザーの認証情報の設定も行うため、その認証情報を使用することで、データベースのデータを参照することが可能です。
データを直接書き変えてしまうとデータの不整合などを発生させてしまう恐れもありできませんが、いざという時に内部のデータを確認できるという点は地味に助かっています。

 

オンプレFAXサーバーをFAX送信SaaSに移行

これもレガシー環境からの移行案件です。

当社では、オンプレのWindows Server 2003 で稼働しているFAX送信用サーバーがありました。
基幹システムにて随時生成される発注データをExcel形式の注文書ファイルとして出力し、それをFAXサーバーが読み込み、対象の取引先に自動でFAXを送信する仕組みです。

当社ではEDIも導入しており、FAXを使用して発注を行う件数も年々減っていますが、取引先の環境によってはFAXでしか受け付けしてもらえないケースもあり、注文書を自動的にFAX送信するシステム自体を廃止することは困難です。

意識の高いIT業界の人は、FAXという古い技術を目の敵にしますが、世の中の中小企業や個人経営の商店なんかでは、デジタル化したところで規模が小さすぎてたいして効率化には繋がらないですし、デジタル化に掛けるお金などありません。
よって、FAXは今後も細々と使われ続けることでしょう。

尚、このFAXサーバーですが、昔は一日に大量のFAXを送信していたようで、モデムが複数接続されていたのですが、この辺の技術は私もあまり詳しくないですし、今後勉強して詳しくなる気も無かったので、このレガシーなFAXサーバーをどのように廃止させるかを密かに検討していきました。

FAX送信してくれるクラウドサービスもあるだろうと思い、ネットで調べるとやはり当たり前のように様々なサービスが存在しており、これらのサービスから最適なものを選定する必要があります。
しかし、インターネットで検索して、各サービス元に直接問合せをして詳しい話を聞いたり、料金や仕様を確認していくのも手間なので、こういった時は取引先の販社に声を掛けて提案してもらうのが効率的です。

今回FAX送信SaaSを選定するにあたり、提示した要件は以下です。

最も重要な要件は「API」です。

元々のFAXサーバーでは、基幹システムの処理のなかで、注文書をExcel形式で共有フォルダに出力までしています。
FAXサーバー側では、大昔にシステム開発会社がスクラッチで作成したWindowsアプリケーション(VB6)を常時起動しておきます。
そのアプリケーションが共有フォルダを常時監視し、所定のExcelファイルが存在していれば、ファイルを開き、特定のセルの値を読み取りつつ、Windows標準の「FAXコンソール」に送信先FAX番号や送信する帳票を渡してFAXを送信する仕組みです。

FAX送信SaaSに切り替えるにあたって私が想定していたのは、基幹システムの現行処理は一切手を加えず、それ以降の処理をSaaSと連携させる方式です。

具体的には、FAXサーバー内で常時起動させていたアプリケーションを廃止し、C#でコンソールアプリケーションを作成し、そのC#製のプログラムでは、FAXコンソールではなくSaaSのAPIと連携させるように変更し、SaaSに送信先FAX番号や帳票データを渡します。

参考として、SaaS移行前と移行後のシステム構成図を以下で掲載しておきます。

よって、前提としてSaaSがAPIを提供していることが必須であり、且つ、提供しているAPIが扱いやすく、機能に不足がないことも重要でした。

後、要件で記載した「管理画面」については、運用を担当部署に移管するために必要でした。
FAXは相手側の状況により送信が失敗することが多々あります。
送信に失敗した場合は、一定時間をおいて再送信し、それを一定回数切替しても失敗し続けた場合は、送信先の状況が一時的に受信できない状態ではなく、FAX機の故障や回線の障害により恒常的にFAXが受信できない状況である可能性もあり、個別に人が対応する必要があります。

SaaSに管理画面があり、その画面から送信履歴の確認や送信に失敗したFAXデータの再送が行えるようになっていれば、我々情シスが個々の対応をすることなく、取引先と交渉したり取引先との発注業務に関わっている担当部署の従業員に運用を任せることができるようになります。
情シスはあくまでSaaSにFAX送信対象のデータを渡すところまでを管轄し、そこから先は他部署に運用を委ねます。

後、FAX送信SaaSは、一般的にFAX送信数で課金される料金体系です。
1ページの送信あたりの単価はサービス元によって結構異なります。
なるべく安価なサービスを選定できるのが望ましいです。

あと、FAXを送る先は取引先です。
SaaSでトラブルがあった場合に、取引先にも迷惑を掛けることになるため、ある程度規模が大きく信頼のおけるサービス事業者が提供しているSaaSを選定するべきです。

これらの要件を踏まえて、最終的に導入を決定したのは、NTTコミュニケーションズの「BizFAX」でした。
管理画面のUIは今どきではないのですが、必要な機能はすべてあり、送信単価も交渉して調整していただけました。

因みに、内製で作り直したC#製のプログラムでは、常時起動させてリアルタイムで共有フォルダを監視するのではなく、タスクスケジューラーで30分ごとに定時実行され、その時にまとめて処理をするように変更しました。

旧アプリケーションはしっかりとしたUIを持っており、その画面内でFAXの送信履歴を確認できたり、エラーが出た場合に再送信が行えるような機能を持っていましたが、SaaS内に同様の管理画面もあり、アプリケーション側で持たせていたリッチな機能はすべて廃止しました。

 

この案件で大変だったところ

この案件では、SaaSのAPIと連携させる処理を内製で開発することになります。
この案件に限らず他のサービスでも同様ですが、新しく利用するサービスのAPIを使用する場合、そのAPIをエラーなく実行できるようになるまでが一番苦労します。

APIを提供しているサービスでは、そのAPIを利用する開発者向けにAPIの仕様書を用意しています。
その仕様書では、APIの認証方法や、各メソッドのURIやパラメーター、レスポンス内容などの仕様、呼び出し時のサンプルコードなどが解説されており、その記述内容の細かさや分かりやすさなどはサービス元によって差があります。

提供される導入サポートの質にも差があり、特にAPIに関しては、回答をする側でもプログラミングに関する知識が求められる内容が多くなるため、APIに関連する質問については限定的な回答しかもらえなかったり、そもそもAPIについては質問を受け付けないサービスもあったりします。

その点、今回の「BizFAX」は、サポートが手厚かったためとても助かりましたが、それでもAPIをエラーなく実行させるまでは苦労しました。

APIでは、サービス元が要求するリクエスト内容通りにパラメーターを渡す必要がありますが、サービス元によって当然そのリクエストで使用するフォーマットが異なります。
特に今回では物理的なファイルのアップロードも必要になりますが、httpの通信でファイルを送る場合、一般的には「multipart/form-data」を利用する方法と、「Base64エンコード」を利用する方法があります。

「multipart/form-data」形式だと、APIのパラメーターをバウンダリ文字列で区切り、各パラメーターと値をリクエストボディに入れます。
「Base64エンコード」形式だと、ファイルをBase64のバイナリ文字列に変換してリクエストボディに埋め込みます。

どちらの方式でファイルをアップロードできるかは、APIの仕様によって異なります。
因みに、BizFAXは「multipart/form-data」形式でした。

毎回新しいサービスのAPIを始めて試す際には、APIの仕様書どおりにリクエストボディを作ってAPIに渡しているつもりなのにエラーが返ってきて、「仕様書の記述内容の解釈が違うかも」とか「プログラム上のリクエストの作り方を間違えているかも」などと想像しながら、試行錯誤を重ねていきます。
一度成功してしまえば、それ以降はそのサービスのAPIで困ることはないのですが、そこまでが辛いです。

このBizFAXでもそこがやはり一番大変だったのと、後はFAXを実際に送信することになるため、誤って変なところFAXを送ってしまわないように慎重に実装や検証をする必要があり、万が一ミスったときは大事になりかねないため、そのプレッシャーも大きかったです。

 

この案件で得た知識や経験

技術的にはこの案件で新しく知識を得たり、新しい技術が身に付いたといったことはありませんでしたが、自社のシステム構成で言えば、FAXサーバーというレガシーな環境を廃止することができたのは非常に大きかったです。

また、今回はFAXサーバーを介して実施していた取引先への発注処理をSaaSに移行しましたが、別にこの業務に限らず、FAX送信SaaSを利用できるようになったことで、FAX用の物理的な設備も不要になり、インターネットに繋がる環境であれば、どんな帳票でもAPIを利用してFAX送信することができるようになりました。

FAXを使った業務を持続することの良し悪しはありますが、このSaaSを利用することで物理的な制約無くFAXを送信したり、送信処理自体を自動化できるようになったため、機会があれば他でも活用できたらと思っています。

 

その他の手掛けた案件概要

記事の文字数が多くなってしまいましたが、まだ他にも色々と紹介したい案件があるため、当項では、記事内でまだ紹介していない案件についても、簡単に紹介していきます。

 

LANSCOPE(オンプレ版)の導入

以前勤めていた会社では、社内のPCはIT資産管理ツールの「LANSCOPE」で管理していました。

その会社が情シス1社目ということもあり、ある程度の規模の会社では、社内のPCは何らかの管理ツールを導入して管理しているのだろうと思っていましたが、今の会社ではIT資産管理ツールが一切導入されていませんでした。

会社の規模自体は以前勤めていた会社より大きいですし、PCも1000台以上はあったのですが、PC購入時にExcelベースの管理台帳に記録を残す程度の簡易的な管理業務しかしておりませんでした。
当然その台数のPCをExcelの台帳で管理し切れるわけがなく、誰がどこでどのPCを使用しているかも正確には答えられず、また、現在社内で何台のPCが稼働しているのかもわからないといった悲惨な状況でした。

適切に管理ができていなかったのは、OA機器の管理を情シスではなく、別のバックオフィス部署でやっていたせいもあるかと思いますが、流石にこの状態では従業員がPCを無断で自宅に持って帰り、自分の物にしてしまっていたりフリマで売り払っていても気付けません。

また、個々のPCの情報が何もわからないので、社内にはWindowsのどのバージョンが何台あり、サポート切れに伴い何台入れ替えないといけないのかも分からず、よくこんな状態で社内システムの運用ができていたなと驚きました。

よって入社後の早い段階で「IT資産管理ツール」の導入を提案しましたが、入社直後の新人が問題を指摘したところで聞いてもらえるわけがなく、結局「IT資産管理ツール」の導入を進めることができるようになったのは、私が情シスの部署長になってからでした。

「IT資産管理ツール」は様々なベンダーが製品を提供しており、当初は機器管理業務のモダン化も視野に入れて、MicrosoftのIntuneなども検討しましたが、当時はWindowsのHomeとProが混在していた環境だったこともあり、IntuneはHomeだと機能が制限されるため、候補の製品から外しました。
そうなると、私が運用した経験のある「LANSCOPE」を導入するのが一番無難と考え、LANSCOPEを導入することにしました。

因みに、結構知らない人も多いかと思いますが、LANSCOEPを利用し、インターネット越しに端末を管理したい場合はLANSCOPEのクラウド版を利用する必要があるというイメージを持たれがちですが、実はオンプレ版でもインターネット越しで端末を管理させることができます。

オンプレ版ではLANSCOPEのサーバーソフトをサーバーにインストールしますが、そのインストーラーのなかで、インストール環境の設定を「イントラネット」か「クラウド/NAT」で選択するのですが、「クラウド/NAT」を指定し、且つ対象のサーバーにグローバルIPを割当てインターネット上に公開することで、インターネットを介して、LANSCOPEの管理サーバーとクライアントは通信が可能になります。
「クラウド/NAT」設定の場合は、若干機能に制約が発生しますが、当社の場合はその制約により運用に支障をきたすこともなかったため、「クラウド/NAT」設定で構築、運用しています。

当ブログでは、LANSCOPE自体の構築について記事は作成していませんが、LANSCOPEのオンプレミス版で利用できるAPIの使い方については記事で紹介させていただきました。
もし興味があればご一読ください。

 

iPadやiPhoneの管理にADE(旧DEP)を導入

当社の従業員は、PC以外にiPadも業務システムを利用するために使用しており、数百台のiPadが稼働しています。
また、従業員に貸与している携帯電話はiPhoneです。

これらのデバイスの社内で導入にするにあたり、割と初期の頃からMDMは導入されておりました。
その後、iPhoneやiPadを提供してくれていたキャリアからの提案もあり、ABM(Apple Businness Manager)に登録しました。

ABMに登録することにより、自社のiPadなどのデバイスで使用するアプリを「購入済みアプリ」として登録しておくことができるようになり、各アプリをMDMを介してリモートでインストール(サイレントインストールは不可)できるようになります。

また、個々のデバイス用にAppleIDを作成したり紐付ける運用が不要になり、これらのメリットだけでも、多くのiPadを管理する組織にとっては管理業務の効率化に繋がります。

尚、これらのAppleデバイスは情シスではなく別の部署で管理しており、MDMの導入やABMの登録もその部署で実施し、管理の効率化へ向けた努力は見受けられましたが、MDMを使いこなしているとは言えない状態でした。

ABMの導入までできているなら、あと少しでモダンな管理環境が作れるため、私が更にADE(旧DEP)でデバイスを管理できるようにする環境の構築を進めることにしました。

まず、ABMとMDMが連携するように設定したうえで、デバイスの調達元のキャリアに連絡し、新しく調達するデバイスはもちろんのこと、過去に調達したデバイスもすべてABMの管理デバイスとして反映されるように依頼をしました。
ABM側のデバイス情報に反映されれば、自動的にMDMにもデバイス情報が反映され、ADE対象端末としてデバイスを登録することができるようになります。

後は、MDM側で初回起動時にインストールされるプロファイルを新しく作成したり、そのプロファイルで業務に必要なすべてのアプリがインストールされるように設定を行い、最終的にはAppleデバイスのゼロタッチキッティングができるようになりました。

その時に作った記事が以下になります。

 

EdgeのIEモードを導入

当社では、クラシックASP＋VBScriptで稼働するWebベースの基幹システムがあります。

現在「Internet Explorer(以降IE)」は廃止されており、新しいWindows環境でIEは起動ができません。
Windowsの構成ファイルとしてIEの実行ファイル自体は残されていますが、その実行ファイルを起動しても、EdgeにリダイレクトされてEdgeが起動します。

古いWeb系の技術において、IEに依存しIEでしか動かないものは多くありました。
当社で使用しているクラシックASP(Active Server Pages)もその一つです。

正確に言えば、クラシックASPで作られたWebページだからIEでしか動かないというわけではありません。

そもそもクラシックASPはサーバーサイドの技術です。

よって、サーバー側がIISを使用し、且つクラシックASPでも動くようにIISを設定をすることで、クラシックASPで生成したWebページをブラウザに返すことができ、そのブラウザはIEではなくてもページを描写することができます。

IEの描写エンジンも独自仕様の部分も多く、IE以外のブラウザでページを表示した場合、レイアウトが崩れるなどの影響はありますが、ページが読み込めなくなるといったことはありません。

IEの廃止による影響を最も受けるのは、クラシックASPの標準スクリプトとして採用されていた「VBScript」を使用したブラウザ側の処理です。

IE以外のブラウザではVBScriptは動きません。
例えば、Webフォームにボタンを配置し、そのボタン押下時のイベントをVBScriptで実装した場合、IE以外のブラウザではVBScriptを解釈できないため、そのボタンを押下しても一切反応しません。

「VBScript」はブラウザ側のスクリプト言語としても利用できますが、Windows に搭載されている「Windows Script Host(WSH)」で読み込むこともでき、MS-DOSコマンドを使用したバッチ処理の代わりとしても使用することができました。
しかし、IEの廃止によりブラウザ側のスクリプト言語としての役割は既に終えており、Windows内で動作するスクリプト言語としての役割も終えることが決まっております。

「VBScript」の詳しい生い立ちやこれまでの経緯については以下のWikipediaの記事をご参照ください。

VBScript - Wikipedia

ja.wikipedia.org

これらのように、IEが使えなくなることで、クラシックASP＋VBScriptで実装されたWebシステムはすべて動かなくなるのですが、Microsoftはそういった古い技術に依存したシステムを使い続け、モダンな技術に移行することが困難なユーザーのために、Edgeに「IEモード」というIE互換機能を用意してくれています。

EdgeでIE用のWebページを読み込んでも、IE互換モードでEdgeが動作してくれる機能です。

当項の冒頭で記載しましたが、当社はIEが使えなくなると、基幹システムの役割を持つWebシステムが使えなくなってしまうため、「IEモード」対応は必須でした。

IEモードに対応させるには、Edgeのメニュー内の「Internet Explorerモードで再読み込みをする」から、毎回手動でIEモードでの再読み込みを実施する方法と、PC個別にEdgeの設定画面から対象のURLを登録して行う方法と、「Enterprise Site List」を使用して、IEモード対象のURLにアクセスした場合に、自動的にIEモードを有効にする方法があります。

企業が全社的に使用している業務システムでIEモードを使用する場合は、三つ目の「Enterprise Site List」を活用した方法を導入してあげないと非常に不便です。

「Enterprise Site List」を使用した方式であれば、ActiveDirectoryのGPOを利用して、管理下のPCに対して一括適用が可能です。
また、GPOが使用できない環境のPCであれば、レジストリを手動で登録することにより、「Enterprise Site List」を参照してIEモードの自動切り替えを制御する設定が可能です。

私がIEモード導入に向けて調べだした頃は、「Enterprise Site List」を使用したIEモードの設定方法について、インターネット上でも分かりやすい記事があまりなく、Microsoftが発信していた技術情報を調べながら、IEモードの仕様や「Enterprise Site List」との連携方法を確立していきました。

その後、それらの作業で得た知識や経験は必ず誰かの役に立つだろうと考えて、以下の記事を書きました。

尚、当記事を書いて1年ぐらいは、それほどアクセス数も増えなかったのですが、その後実際にIEのサポート終了が近付くにつれアクセス数がどんどん増えていき、サポート終了の1カ月前ぐらいにはアクセス数がすごいことになっていました。

因みにアクセス元に調べたところ、正確にはわからないのですが、大手のSIerからのアクセスも結構あったようなので、我々情シスが自社のレガシーシステムの延命において参考にされていた以外にも、SIerが顧客のシステムの延命で参考にしたケースもあるのかなと想像していました。
その意味では、IE依存のレガシーなシステムを使用していたり保守している人たちの助けになれたのではなかろうかと思っています。

 

TLS 1.0/1.1無効化に伴いリバースプロキシ構築

この案件もレガシーな環境の延命案件です。

当社ではインターネットに公開しているサーバーも幾つかあり、稼働しているサーバーのOSは、サポートが残っているものもあれば、前任が適切な時期の更改をしなかったことでサポートが切れてしまっているものもあります。
インターネットに更改しているサーバーの用途としては、Webサーバーやアプリケーションサーバーが主です。

これらのサーバーはレガシーな環境とはいえ、サーバー証明書を取得し、httpsで通信できるようにしてありました。

2022年2月頃、当社のコーポレートサイトをブラウザで表示しようとすると、「安全ではありません」と警告がでるようになったと社内から報告が来るようになりました。
原因を調べたところ、Google Chromeではバージョン 98 からTLS 1.0/1.1を無効化するようになったとのこと。

コーポレートサイトだけではなく、レガシーな環境で稼働している業務システムのアプリケーションサーバーでも同様の報告があり、急いで対応が必要になりました。

例えば、コーポレートサイトはCentOSで稼働しており、CentOSのバージョンは5.11でした。
某VPSで稼働していたのですが、このCentOSはコーポレートサイト以外にも幾つかのサイトを公開しつつ、Postfixが入っており、メールサーバーとしても使用されていました。
よって、この環境を別に環境にすぐに移行するのは困難です。

では、サーバー側のOpenSSLでTLS 1.2を使えるようにするだけ良いのではと思い、現状の環境を確認したところ、インストールされているOpenSSLのバージョンはTLS 1.2をサポートしておりませんでした。
TLS 1.2 を使用できるようにするにはOpenSSLのバージョンを上げないといけないが、CentOS 5 からだとyumでのバージョンアップは行えず、TLS 1.2 に対応したOpenSSLを取得して、ソースからインストールする必要がありました。

この辺りの作業は現行環境への影響が気になり、可能な限り避けたいと考えました。

そこで思い付いたのが、「リバースプロキシ」を使用する案です。

そもそも「リバースプロキシってなに？」と思った人もいるかもしれません。
参考までに「リバースプロキシ」についておさらいをしておこうと思います。

まず、IT業界で勤めている人であれば、「プロキシサーバー」が何なのかについては多くの人が答えられると思います。

「プロキシサーバー」とは、クライアントの代わりにWebサーバーにアクセスしてWebページを取得しクライアントにWebページを返すサーバーです。

一般的な用途だと、企業のネットワークにおけるDMZにプロキシサーバーを配置したうえで、社内のPCやタブレットはインターネット上のWebサイトへアクセスする際に、必ずプロキシサーバーを中継する構成を作ります。
このような構成におけるメリットは以下です。

• クライアントの情報がWebサーバーに渡らないことでセキュリティ上のリスクが軽減される
• Webの通信を集約することになり、アクセスログの管理が可能になる
• Webの通信の出口を一つにまとま、管理しやすいネットワーク構成になる
• プロキシのキャッシュ機能を使うことでページの読み込みが早くなる(キャッシュ機能を使う場合)

「プロキシサーバー」では、これらの役割があります。
上記の内容を踏まえてうえで、「リバースプロキシ」について説明していきます。

「リバースプロキシ」は、通常のプロキシサーバーと同じように、クライアントの代わりにWebページをクライアントに返しますが、処理の方向が言葉のとおり逆になります。

「リバースプロキシ」では、インターネット側のクライアントからアクセスされてきたWebページの要求をリバースプロキシサーバーで受け付けて、クライアントの代わりにWebサーバーにアクセスして、ページを取得し、ページをクライアントに返します。
「プロキシサーバー」は、内部(特定のクライアント) → 外部(不特定多数のWebサーバー) の通信の中継で使用されますが、「リバースプロキシ」では、外部(不特定多数のクライアント) → 内部(特定のWebサーバー)の通信を中継します。

今回のケースでは、Webサーバー自体はTLS 1.2 に対応できないのですが、リバースプロキシ側のサーバーは新しいOSを利用することで、新しいOpenSSLを使用することができるため、TLS 1.2 を有効にすることが可能です。

また、Webサイトで使用していたAレコードをこれまでのWebサーバーのIPアドレスではなく、新しく用意するリバースプロキシサーバーのIPアドレスにしてあげることで、インターネット上のクライアントはリバースプロキシサーバーと通信するようになり、クライアントとリバースプロキシ間ではTLS 1.2 で通信が確立できるようになります。
リバースプロキシとWebサーバーは暗号化のないhttpでも問題ありません(ネットワーク構成にも寄る)。

リバースプロキシを設置することで、WebサーバーのOpenSSLが古い場合や、OpenSSLが使えない場合でもTLS 1.2 以上の規格で通信をすることができるようになります。

また、リバースプロキシを導入することで、公開系Webサーバーを稼働させている環境であれば、以下のメリットがあります。

簡単ですが、これらが「リバースプロキシ」の特徴です。

当時、リバースプロキシに関する知識も多少はありましたが、実際に構築したことはなく、運用すらしたこともなかったのですが、私が思い付いた対策のなかで、リバースプロキシを構築して運用に載せるのが最良の案だったため、取り敢えずLinuxを用意して色々と調べながら構築しました。
幸い当初の想定通りリバースプロキシが機能してくれたので一安心でしたが、やはり情シスであっても、いざという時にLinuxを触れたほうが良いなと改めて思いました。

当時は3台程レガシーな環境のWebサーバーやアプリケーションサーバーがあり、リバースプロキシも2台ほど構築してTLS 1.2問題を回避したのですが、今は対象のレガシーなサーバー達も無事廃止、又はマイグレーションしてTLS 1.2 以上の環境にも対応できており、振り分け先だったサーバーのうち2台はリバースプロキシ自体不要になり、1台は、セキュリティ上都合が良かったので、引き続きリバースプロキシを有効にしたまま運用しています。

尚、当時このときの対応内容も記事にしています。
今では内容が古くなってしまったので、リライトしたいところですが、面倒なので書き直しはしないかも知れません。

 

自社の業務アプリケーションの開発

当項では特定の案件ではなく、都度行っている業務アプリケーションの内製について紹介します。

当社は自社の業務システムを外注して開発しているものもあれば、内製しているものもあります。
内製する業務システムのなかでも一番規模が大きいのは、前項でも紹介したクラシックASP製のWeb基幹系システムです。
これは大昔にSIerが構築し、その後運用や保守開発に関わっていたSIerの手を離れ、自社で保守開発を続けながら使い続けています。

頻繁ではないのですが、時々このシステムに対する改修依頼があり、都度対応をしています。
基本的に古いシステムであり、IEモードに依存するシステムでもあるため、新規画面の作成といった機能追加に関する要望は基本的に断り、別のシステムや業務で代替するように交渉しています。

20年以上前から稼働するシステムであり、クラシックASPのソースコードを見ると、大昔の日付のコメントが残されていたりして哀愁が漂います。
当時コードを書いていたプログラマも今は会社の役員になっていたり、又はすでに定年退職していて、毎日孫を愛でているんだろうかと思いを馳せます。

また、そのソースに現代の日付でコメントなどを書き足していくと、過去から脈々と受け継がれているこのレガシーなソースコードが神聖なもののように思えてきて、次の世代に引き継がなければという気になってきます(ダメ、ぜったい)。

このシステム以外にも全社的に利用する規模の大きい業務システムがいくつかあり、上記のシステム以外の大きめのシステムについては、外部のシステム開発会社に開発を委託しています。
当社の情シスは人数も少なく、且つ全社的に利用されるシステムにおいては、高い信頼性が求められるため、仮に技術があっても、小規模の情シスが片手間で開発するにはリスクが大きすぎます。

当社の情シスは業務アプリケーションの内製もする情シスですが、積極的に内製をする対象は、これらの主要な業務システム同士を繋ぐ処理やアプリケーション、主要な業務システムだけではカバーできない業務の効率化や自動化をするためのサブシステムなどです。

そのような目的でアプリケーションの内製をしているため、コードを書いたり機能を追加する機会の多い開発環境だとAccessです。

Accessは、ローカルにテーブルが作成できて、ODBCで様々なデータベースと接続することもでき、フォームが作成できて、データベースと連携する帳票機能もあります。
また、VBAを使用して適切に処理を実装することで、C#やJavaなどで作成したWindowsアプリケーションとも遜色ない業務アプリケーションが作れます。

内製対象として同様に多いのが、VBScriptやPowerShellなどのスクリプトを使用したバッチ処理(CUIアプリケーション)です。

主に夜間にタスクスケジューラーなどで自動実行されるようにしておき、データを一括で更新したり、必要なデータを作成したり、データの不備や異常をチェックして問題があれば通知させるような処理を実装させています。

場合によっては、C#などのビルドが必要な言語で作成する場合もありますが、それだと実行ファイルとソースコードが分離されてしまい、ソースコードが適切に管理されていない場合、いざという時にソースコードの確認ができなかったり、処理の修正ができないといった事態が起こり得ます。
よって、バッチ処理を作る場合、なるべくVBScriptやPowerShellのように、必要によって処理内容が簡単に確認できるスクリプト系の言語を使用するようにしています。

後、社内の要件によっては、どうしても新規でWebアプリケーションを作らないと要件を満たせないケースも時々あります。
その場合は、ASP.NET ＋ C# でWebアプリケーションを内製します。

このような開発の場合、フォーム数もなるべく少なくし、実装する機能も最低限でシンプルなものを作るようにしています。
前述したAccessなどで使われるVBAであれば、習得に必要な難易度も比較的低いため、保守を誰かに引き継ぐに場合でも引継ぎがし易いです。
また、VBScriptやPowerShellの場合は、画面のないCUIアプリケーションとして作成しており、画面のないプログラムも同様に引き継ぐのはそれほど難しくありません。

ASP.NET ＋ C# で作ったWebアプリケーションだと、誰かに引き継ぐにしても、多少のプログラミング経験が必要になり、引継ぎできる人材も限られてしまいます。
よって、ASP.NETやC#を使うようなケースでは、なるべく機能をシンプルにして、簡易的なアプリケーションに留めるようにしています。

但し、内製で開発をする場合、作っていて楽しいのはASP.NET ＋ C# や PHP などで作るWebアプリケーションだったりするので、作りたい気持ちもありつつ、かといって安易に作ってしまうと、後から足枷になりかねないという気持ちで葛藤します。

因みに、こういったWebアプリケーションは、作成したアプリをWebサーバーにデプロイし、インターネット上に公開し、httpsでアクセスさせる環境が用意してあるので、必要になればすぐに業務で利用できるようにはしてあります。

最近では、内製に力を入れる事業会社も増えてきていると思いますが、私も以前から内製は積極的にやるべきだと考えています。
ITと関係のない事業を営む企業であっても、自社内にアプリケーションの内製ができる技術者を雇用しておき、必要なときにすぐアプリケーションを開発して業務に活用するといった体制は、今後どんどん求められていくと思っています。

 

最後に

今回の記事では、私が情シスとして勤めている事業会社でこれまで対応してきたシステム構築や導入、システム移行案件を色々と紹介してみました。

本当は他にも紹介したい案件は色々とあるのですが、ブログの1ページの記事としては書き切れないですし、そもそもそこまで熱心に私の対応してきた案件を漏れなく知りたい！といった人もいないかと思うので、これぐらいの内容でおしまいにしようと思います。

振り返ってみると、レガシーな環境を新しい環境に移行する案件が多く、当社の場合は移行元の環境が極端に古いことで大掛かりな作業になっていますが、こういった案件自体は他社の情シスでも当たり前のように行っている内容です。
そう考えると、3万文字以上を費やして記事にするほどの内容でもなかったかなと思ったりもします。

とは言え、ここまで書いてしまったからには公開しないわけにはいかないですし、また、今回の記事で紹介した作業や案件の一つ一つは思い入れもあり、技術者として、情シスとして成長に繋がり、有益だったと考えています。

世の中には様々な企業があり、情報システム部門の役割や能力、業務内容も様々です。
あまり内製をせず、技術的な作業の多くを外部のベンダーやSIerに委託し、情シスの役割はベンダーコントロールといった企業も多いかと思います。
今回の記事で書いた案件のすべては私がほぼ一人で実施しており、そういった企業の情シスとは対極的とも言えます。

世の中には色んな情シスがあり、泥臭いSI(システムインテグレーション)を「やれやれ・・・」と言いながら喜んでやっている変わった情シスも居るんだなと知ってもらえればと思います。

ここまで長々と読んでいただきましてありがとうございました。
それでは皆さまごきげんよう！