はじめに
一次請けであれ二次請けであれ、または準委任であれ、省庁系システムの開発は、初めて経験するものには戸惑いを与えます。金融系システムや流通系システムなどを経験した技術者にとって、知っておかないとうまく事が運ばないことがあるので注意が必要となってきます。技術面は後ほど紹介することとして、著者が4回の省庁系システム開発で学んだことは次の点です。
- 誤字・脱字を侮るな
- コミュニケーションルートを確保せよ
- 受領資料の意味を熟考せよ
- 査読すべき資料を早急に収集せよ
- 省庁の影にコンサルタントの気配あり
- 自社に馴染んだ開発手法に持ち込め
今回から、今までのシリーズに加え、新たに「技術編」を設け、技術の面から見た省庁系システムを実装する上で役立つ情報を紹介していきます。
まずは技術編第1回目として、「オープンソースで構築」について解説していきたいと思います。
これまでの連載
- 初めての省庁系システム開発（第1回）～誤字・脱字を侮るな～
- 初めての省庁系システム開発（第2回）～コミュニケーションルートを確保せよ～
- 初めての省庁系システム開発（第3回）～受領資料の意味を熟考せよ～
時代の流れでしょうか？
当シリーズでは実装コードがないため、せめて省庁系システムを実装する上で役立つ情報を提供したいという目的で、「技術編」を設けました。第1回目はオープンソースを使える楽しさや省庁系システムではJavaやXMLを使った方が現時点ではスムーズな開発が行えることを紹介します。
ちなみに第2回では「認証基盤でつまづくな」、第3回では「セキュリティは政府機関の統一基準に従え」について触れる予定です。
こんな文書が公表されています
経済産業省から「情報システム調達のための技術参照モデル（TRM）」（以下、TRMと呼びます）という文書が公表されています。TRMは非常に重要な意味を持っているため、筆者の採用した技術を紹介した後、詳細に触れたいと思います。筆者個人の経験ではなく、TRMについて知りたい方は「自由に技術は選べるものなのか」の章を読んでください。
オープンソース採用は楽
本編の第3回「受領資料の意味を熟考せよ」でも触れたように、ガイドラインには玉虫色の表現があるため解釈に困るのですが、要は長い期間使用でき、そのシェアが大きくかつオープンソースであることが望ましいと受け取れました（この解釈は筆者のプロジェクトでも意見が分かれたので私個人の解釈とします）。
ということで、オープンソース大好き人間が多い筆者のプロジェクトでは、OSにはLinux、DBにはMySQL、言語はオープンソースではないですがJavaを採用し、のびのびと開発することに決定しました。もちろん、監視ツールやバックアップ・リカバリツールに関しては商用の方が安定しているということで、それぞれベンダーを選定し使用することに決定しました。
第1Linuxブーム（LinuxでXウィンドウが表示できれば満足）という世代の私にとっては、感無量の世界でした。こんなに安くシステムを構築できるなんて、長年汎用機でCOBOLのプログラミングをしていた筆者には言い表せないほどの感動がありました。
話は脱線しますが、1990年代のLinuxはXウィンドウを立ち上げるのが一苦労だったのです。C言語に疎い筆者はネットで世界を駆け巡り、Cで書かれたデバイスドライバをコンパイル・インストールしXウィンドウを表示させたという感動が今でもあります。ちなみにXウィンドウを立ち上げたにも関わらず、コマンドラインで、sed、awk、Perl、Pythonを独学しました。Pythonでいろいろなツールを作成しては周りに配布していました。COBOLしか知らなかった人間にとっては別世界の出来事でした。Javaが登場すると噂で聞いた時には、恥ずかしながら胸がときめいたくらいです。
なぜ言語にJavaを採用したか？
では、オープンソースで固めるはずのシステムにJavaを採用したかということになりますが、これは省庁特有のシステムの制約によるものです。これは省庁がJavaを推奨しているためではありません。省庁では本人認証を行うのに、ID・パスワード方式のほかに「政府認証基盤（GPKI）」や「公的個人認証サービス（JPKI）」を使用しています（「認証基盤については当シリーズの他の回で紹介します）。これらのサービスが提供しているAPIがJavaだからです。両者とも、PKI（public key infrastructure：公開鍵基盤）だと考えてもらって結構です。
省庁では、捺印の代わりに電子署名を用いていますが、暗号化された電子署名の公開鍵が電子証明書に添えられており、それを使用しての復号となります。このあたりのことは巷に参考書があるので参照ください。その証明書の正当性をGPKIやJPKIが行ってくれるのです。
余計なお世話ですが、非常に重要です
インターネットを経由してくる利用者がいるシステムでは、そのインターフェースはXMLが適していると考えられます。
- 個別業務システム間あるいは個別業務システムと共通基盤システム間のインターフェイスはXMLが推奨しており、クライアントとサーバ間もXML化することが望まれる。
- 法改正に耐えうるものでなければなりません。省庁系システムは法改正の影響を受けやすいため、それに柔軟に対応できるものでなければなりません。
- XMLであればXSLTを利用することで、一括して法改正に沿ったデータ移行が可能となります。筆者自身、XML関連に強いということもあり、プロジェクト・リーダとして当初入ったのですが、教育期間もないということで、プロジェクト・リーダを他のメンバに任せ、ひたすらXSLTを書きまくった記憶があります。再帰関数を作れる技術者であれば、相当難しい移行に思えるものでも、大きな問題とはなりにくいと筆者は感じました。
- 画面自体をHTMLとして作成するのであれば、システムに入力されるXMLからXSLTを使って、容易に作成できます。また、法改正で画面変更が発生した場合でも、新しく移行したXMLからXSLTを使用してHTMLを作成することで対応できます。従って、XMLの移行は工程の最初の方で設計・実装するのが望ましいでしょう。
その他の技術
その他の技術として、O/RマッピングはHibernate、DIコンテナはSpringなど自由に決定できます。お分かりのとおり、実装部分に実績のない製品を採用しない限り省庁が干渉することはありません。他には、Struts、Axis2なども採用しました。開発ツールにはXMLを簡単に作れるものを準備しておくとベターです。
以上、一部ではありますが筆者が関わったプロジェクトのシステム構成を紹介しました。次ページでは、今後システムを構築する場合に採用すべき技術の指針となるTRMについて紹介します。
