�A応募集計・調整システム
応募データをデータベースに蓄積し、これを所属部門別、キャリア別に集する。また、受講者の調整やその結果を電子メールで連絡するシステム。

�A訂正連絡システム
変更登録の完了後、人事部から変更情報の確認情報が電子メールで変更される。

�A電子掲示板機能
特定グループまたは特定部門等に公開された電子掲示板機能の提供

�Bセキュリティ機能
部門別、職能別、職位別セキュリティレベルの設定とデータセキュリティの確保　

(２)エ．ルーチンワーク(定型でも可)

(３)オ．定型業務である反面、正確性と迅速性を要求されるから。

(２)対象作業は現場での迅速な判断が要求される業務であるほか標準化が可能であるため。

１．情報リテラシーの問題
　もともと技術者の航空管制技術官であるので、ＵＮＩＸ，ラポート、アシストカルクといったソフトへの慣熟は比較的短時間ですんだ。しかしながら、従来なれ親しんでいたウインドウズ系のアプリケーションが利用できれば、もっと効率的に導入できたと考えられる。また、既存の点検記録簿、機器操作手順書といったドキュメントを直接的に移植できたと思われる。しかしながら導入時期には、ネットワーク機能を強化したＯＳとしてＵＮＩＸを選択せざるを得なかった。端末のハングアップ時の対応などＯＳ操作の必要時のため、メーカによる研修を実施することで対応した。

２．情報量と検索機能の問題
　非定型情報をインデックスを付けてファイル化することで、有効な情報として活用できるようになった。しかし導入後数年でそのインデックスにレコード件数が数万件にのぼった。そのため、端末からキー入力して当該情報ファイルが取り出されるまで数分を要するようになった。サーバと端末間の回線速度、端末装置の性能向上などが解決策として上げられるが、費用の問題もある。

３．情報の存在価値
　航空保安施設は、空港事務所(管制塔)にあるのではなく、多くは滑走路の近くに設置されている。障害発生時には、滑走路近くの局舎から情報参照することが可能となれば、参照情報の価値は高まる。現在では、空港管制塔の端末から参照するに止まっているが、空港保安施設の監視用の光ファイバが、布設済みであり、ノート型パソコンと光モデムの導入でモバイルコンピューティングが可能となり、情報の存在価値を高めることができる。

４．機器付属図書の電子メディアによる提供
　障害対応記録、障害原因分析記録の作成に当たって、図による記述が多くなる。これは電子機器の故障状況の説明であるから当然である。これらの図は、多くは航空保安無線施設の納入時に添付される取扱説明書、回路図面、電子デバイスカタログといったドキュメントに記載されていることがほとんどである。現在これらのドキュメントは紙ベースで提供されている。記録作成に引用するためには、事務用パソコンのｽｷｬﾅで読みとり、図形の加工、ファイルの変換、フロッピーディスクによる移植、ラポートへの貼り付けという手順をふんでいる。これらのドキュメントが電子メディアで提供されれば、容易に引用できるメリットがある。

(１)決裁期間の短縮
　導入後３カ月で、決裁期間は電子印鑑導入前は４．５日であったものが、３．２にみじかくなった。これは課内の文書番号を記録する起案簿に記載された起案日と課長決裁日の記載、電子印鑑ソフトに使われている印鑑捺印時間のデータを比較した結果である。

(２)事務の効率化
　課内においては文書作成用にワープロが使用されるようになって８年が経過しており、起案に必要なフォーマットはすでに電子データとして共有ファイルに登録されていた。起案文書は従来それらに必要事項を記入して作成してプリントアウト後決裁にまわしていたが、電子印鑑を用いた決裁文書ファイルを作成するときもそのまま電子データが利用できた。そのため、決裁者の机上が出張時に決裁文書であふれるという不具合はなくなった。しかしまだパイロット導入のため、他部局らの回付決裁文書は従来どおり決裁者の机上で止まっていた。

(３)文書の修正の迅速化
　稟議の過程で起案文書に赤字で修正がはいることがある。修正に当たっては文書管理規則では起案者が決裁者に呼ばれ、説明を受けた後修正し再度既決者に回付し再決裁を受けることが定められていた。しかし、慣例的に決裁者の修正後、上位の決裁者に続けて決裁を受けることが通例化していた。電子決済の導入後、修正者は、電子ファイル上で文字を直接修正し、上位の決裁者に回付することになった。このため、従来修正印を使用してどこをだれが修正したのかはっきりしていたものが、わからなくなってしまった。そのため、急遽コメント管理ファイルを連動した。このファイルは修正者と修正内容が決裁文書ファイルからペーストでき、かつ修正者のサインがでフォルトされているというもので、最終決裁者までだれが修正したのかはっきりわかるようにした。このコメント管理システムは、従来決裁者と起案者が双方とも在席していないと修正の意図が双方に伝わらず意志決定できないという欠点を補う効果もあった。起案者が不在時でも決裁者がコメントを付して起案者に返付することですむことになった。

(１)外部機関情報の非電子化
　起案文書の作成時には、国、府県、隣接自治体からの文書をもとに、実施計画を企画し文書化する作業が大半を占める。そのさい、外部機関の情報は電子化されていないものがおおく、従来参考資料として添付していたものであるが、電子決裁においてはイメージスキャナで電子ファイル化するなどの必要性が生じる。
　その場合、�@ファイルサイズが大きくなるため、サーバの性能や、アプリケーションの性能に問題がある、�A調達部門に提出する物品購入要求書でさえもカタログの当該頁をスキャナで読み込むなど無駄が生じる。この問題の対策には、国の機関のインターネット情報を利用し電子化した情報を入手し添付ファイルとする。購入用カタログのようにデータベース化が可能なものについてはその規格を引数とすれば、形状写真は省略できるようにするなどの対策がある。

(２)全庁的な導入
　稟議文書のなかでとくに重要な案件は幹部へのレクチュアを行っている。また課内の決裁の場合は、比較的月次ミーティングなどで事前の意思統一ができているので稟議文書に質問があることは少ない。全庁に導入した場合、そのような人間的対応も決裁システムに代替させることができるか疑問である。また、現在情報処理機器に馴染みがうすく情報リテラシの問題もある。幹部付秘書がいちいちプリントアウトするといった状況になりかねない。そのようなマンマシン関係の問題は最後まで残る。

(３)モバイル化
　出張の多い職員は不在がちであるので、各自モバイルコンピュータを用いて出張先から携帯電話、公衆電話で庁内のネットワークに接続し、出張先から決裁、起案分の修正を行うことでさらなる効率化が考えられる。しかしながら、ハードウエアを整備するために費用がかかり、導入効果との関係は疑問である。

(４)情報公開条例への対応
　現在情報公開条例では、公開情報と非公開情報の区分がある。官庁意志決定の途中の情報は非公開情報である。たとえば、騒音測定装置の設置工事の入札予定価格は、課長決裁後、調達係が開封するまで封印され、起案文書に添付されている。複数のファイルを決裁文書として開封権限者をあらかじめファイルに対応するようにソフトウエアで対応することが考えられるが現在のソフトは一決裁一文書ファイルのシステムをとっており実現できない。また公開情報も電子ファイル化することで、情報公開請求時の検索が容易となる。全庁ネットワークになり外部から電話回線を使ってアクセスし決裁するシステムになった場合、外部侵入といったセキュリティに対する配慮も必要となる。

２．プロトタイプを用いた設計
　プロトタイプを用いてクライアント端末に、ファイル管理ソフト、ＥＵＣ系のアプリケーション、グループウエアとしてのメール管理ソフト、ホームページ作成ソフトをインストールした。この作業はプロジェクトメンバーが、情報処理部門の担当者の指導のもとに行った。またＦＴＰ操作も習熟した。表計算等のＥＵＣ系ソフトについては、メンバーの慣熟の程度に応じて操作慣熟することにした。また、ハードディスク、レーザープリンタといったハードウエアの管理についても習熟した。
　このことで、将来本格展開後各部門でのシステム管理者としての役割をになう人材が成長する元とすることができた。

３．問題点の進捗の確認
　メンバーがシステムの動作、系統について理解した後、システム運用の必要な要件を検討することにした。

(１)まず各部門でシステム化する情報の洗い出しを行った。情報の形式、情報量、参照頻度ネットワーク化する目的、各部門の業務との関連、部門間で情報を交換するときの条件について各部門において検討した。
(２)次に情報セキュリティについて洗い出した情報ごとに設定した。アクセス権限として従来のユーザ、グループ、管理者といった三段階の区分けが情報部門から提案されていた。この区分では業務上の組織と不一致であるという問題点も発見されたが、プロトタイプ段階ではこのまま試行を行った。
(３)テストデータの作成も各部門の代表者で行った。営業部門と経理部門では月末に大量のデータを交換することが予定されたので、負荷テストを意識して作成した。また、製造部門とのデータ交換はイリーガルデータ(ケタ落ち、特殊記号含みのコード)を排除できるようになっているかテストデータを作成した。
(４)ネットワーク本運用に際して、各部門で操作するシステムの説明(ＯＪＴ)は、プロジェクトのメンバーが行うことにした。そのための説明資料は情報処理部門が叩き台を作り、各部門共通の事情を盛り込むことにした。またプロトタイプの表計算データを個人所有のパソコンからフロッピーで持ち込んだところフォーマット形式が１．２Ｍ形式であったため読み出せないと言う現象が発生した。フロッピーの形式について説明するとともにウイルスについての脅威を強調し、各ユーザへの啓発を図った。
(５)市販のＥＵＣ系アプリケーションは、全社的に情報部門で一括購入し各部門で管理し、ネットワーク管理ソフトについては、情報処理部門からサーバを操作しリモートログインにより変更する方法で管理することになった。各メンバーは部門システムにおいて必要な操作を行うことにした。この方法もプロトタイプで実施できることを確認した。
(６)ホームページの作成については、経験者がいなかったのでシステムメーカーの実施する講座に参加することにした。これには宣伝部門と情報部門のメンバーが参加した。その後でプロトタイプ上でホームページのデモ版を作成し、メンバーに供覧した。以後宣伝部でホームページを利用した宣伝計画について詳細に検討する(アクセスしてくる消費者の階層、アクセス件数による宣伝効果、情報の内容)ことになった。人事部門から採用情報も載せて欲しいという要望があったが、就職活動シーズンまでに本運用が可能かどうか微妙な状況であった。また掲載情報については、宣伝部門からの要望、各部門からの要望いずれかの場合にも、相互の部門の責任者の承認を得るという手続きを確認した。

４．実施の効果
　以上のような、システム展開という段階において、開発段階と類似のプロトタイプ手法を用いて問題点を明確にし開発の方法を探っていくことにより各部門担当者の知識向上がはかられている。