システムアーキテクト資格の論文を書いてみる

来月に受ける予定にしているSA資格ですが、午後2の論文についてそろそろ準備しておかないといけないので、まずは一本書いてみることにしました。

自分自身の経験に基づいて書くことができればベストなのですが、論文に書けるような性質の業務を普段からやっているわけではないので、１００％知識と想像だけで書いてしまう作戦でいきます。
何かネタはないかと書店で探してみたところ、日経SYSTEMSの記事をまとめたムックがあったので、そこに掲載されていた開発事例をヒントにして書いてみることにしました。

【ICタグを利用した書類管理システムの導入について】

【ア−１】システムの概要
　A社は、個人保険や団体保険などを扱う国内の生命保険会社である。
A社の団体保険制度に加入している顧客企業は全国に5万社ほどあり、それら顧客企業に関する契約内容や資産管理を扱うシステムが、今回の開発対象となる。
A社の団体保険管理システムでは既に、Webベースのシステムが稼働している。全国３００箇所の支店に配備されているクライアントPC約3,000台と本店のWebサーバーで構成されたシステムである。
開発言語はJavaで、クライアントPC側ではWebブラウザ上で動作するアプレットが、Webサーバ側ではJ2EEコンテナ上で動作するサーブレットが稼働している。

【アー２】システムの目的／特徴
　今回、A社内部で、事務担当者間での書類回覧に関する事務フローの再構築を実施することになった。
A社では現在、事務書類の担当者間での回覧を手作業で行っており、複雑な事務フローの場合には、回覧ルートなどについて有識者が個別に指示を出す必要があった。
今回の事務フロー再構築で、それらの問題点を見直すと共に、情報システム側でも新たにICタグを使用した書類管理システムを導入することになった。
具体的には、回覧される書類に対して個別のICタグを添付し、それを各担当者のPCに接続されたICタグリーダから読み込ませ、その情報をサーバーで管理する。これにより、規定の事務フローに沿った回覧指示が自動的に行われることになり、また事務作業の進捗状況についても責任者がリアルタイムで把握することができる。

私は、SIベンダーであるB社に所属するシステムアーキテクトであり、A社の情報システム部門や業務部門と調整を行いながら、グランドデザインに携わる立場として、このプロジェクトに参加した。

【イー１】課題
　プロジェクト開始当初は、このシステムの実現にあたって、A社の情報システム部門と業務部門からそれぞれ相反する要望が提示されていた。

まず、情報システム部門からは、既存のWebベースのシステムを利用して実現したいという要望が挙っていた。
その理由は、全国の支店に配備されているクライアントPC約3,000台に対するプログラムの運用保守が、今後も容易にできるからである。

また詳細なヒアリングを実施したところ、PCとサーバー間の通信の際に、A社が確立しているEAに基づく社内標準であるHTTP/HTTPSプロトコルを採用することができる点も挙げられていた。
それに対して、業務部門からの要望は、市販のICタグ管理に対応したパッケージを利用し、クライアントサーバー構成のシステムにするというものであった。この場合、クライアントPCとサーバーには独自のパッケージをインストールし、両者はパッケージ独自のプロトコルで通信を行うことになる。
パッケージを利用したい理由をヒアリングしてみたところ、オーダーメイドで実現するよりも遥かに短期かつ低コストで実現できるからというものであった。

これら相反する２つの要望を適材適所の観点から調整し、実現する案として、私は次に述べる内容をA社に提示した。

【イー２】解決策
　「クライアントPCから読み取ったICタグの内容を、サーバー側でモニタリングする処理」については、市販のパッケージを利用したクライアントサーバー構成とする。
それ以外の業務処理については現状通り、Webブラウザ上のアプレットとWebサーバー上のサーブレットで処理させることにする。
今回新たに利用するパッケージに含まれるサーバーと、既存のWebサーバーとの間で同期処理が必要になるが、その通信部分には、独自の通信用ミドルウェアを新たに開発し、使用する。
以上のような案をA社に提示したところ、A社のシステム担当者／業務担当者の双方から同意を得ることができ、インフラ面についてはこの案を前提として、詳細なデザインに入ることになった。

書類管理システムをWebベースで実現する案についても検討してみたが、以下の理由から採用を見送ることとなった。
一般的なWebブラウザでは、セキュリティ上の制約から、JavaアプレットからクライアントPCのローカルデータにアクセスすることはできない。
このことは、クライアントPCから読み取ったICタグの内容をWebブラウザから扱うことは、かなり特殊なプログラムを開発しない限り、困難であることを意味している。
今回のプロジェクトに調達できるリソースを自社のプロジェクトマネージャーと調整した結果、この案については厳しいと判断した。

【ウー１】評価
　新規システムをパッケージ利用とし、それ以外のシステムはWebベースとすることで、A社のシステム部門および業務部門の担当者の要望を満たすことができ、双方から高い評価を得ることができた。
「クライアントPCから読み取ったICタグの内容を、サーバー側でモニタリングする処理」については、今後仕様変更が発生することは考えにくい。よって、この部分のみを切り出してパッケージ利用とすることで、システム全体の保守性が下がることはないと考えられる。
逆に、Webシステム側では、処理をサーバー側に集約する構造となる為、将来的に機能変更などに関する保守作業が容易になるだろう。
また、JavaアプレットからクライアントPCにアクセスするプログラムを開発する必要がなくなったことで、開発工数を削減することができたと同時に、A社内のセキュリティ標準に従ったシステム設計とすることができた。

【ウー２】改善策
今回のプロジェクトでは、書類管理システムのサーバーと既存のWebサーバー間の同期処理に、独自の通信用ミドルウェアを新たに開発した。
これを今後、A社内部で標準化し、将来的に同様のシステム追加案件が発生した場合に利用できるようにしておく必要がある。
具体的には、利用しやすいAPIの設計や、マニュアルの整備などが挙げられるだろう。

これまで述べてきたように、システムアーキテクトには、複数の相反する要望を適材適所の観点から調整し、将来的な保守性や社内標準を考慮した上で、システムデザインする力が求められていると私は考える。
ー以上ー

これで大体２５００字あります。字数的にはこんなものなんでしょうが、テキストエディタ使用で４時間くらいかかってしまいました。
本番は手書きで２時間であることを考慮すると、うーん、これはかなり苦戦を強いられそうですね。

内容については、これは意図していたわけではないのですが、結果的に色んなテーマが含まれることになってしまいました。
「パッケージでいくのかオーダーメイドでいくのか？」
「データやプログラムを集中管理するのか分散管理するのか？」
「アーキテクチャやセキュリティに関する社内標準の問題」
などなど…普段あまり悩んだこともないような事で、悩んだフリをするのは難しいですね。

全て書き終えてから、改めて目を通してみると、やはり言葉が上滑りしているというか、深みが全くないような気がしますね。
プロジェクトの渦中にいた当事者にしか書けないような臨場感が皆無なのは、これは仕方ないのでしょうか。
採点官は論文を読むプロなので、そのあたりのことは一瞬で見抜かれてしまうのでしょうが、それでも「こいつは経験はなくても、よくわかっているな」と思わせるのが目標です。

本番までにもう少し悪あがきをしてみるつもりです。