第63回例会報告

活動報告, 研究会

第63回例会報告

一般的にはシステムの老朽化に伴いシステムを新しくするが、札幌市の状況は一風変わった目的のもとにシステムを刷新した。かつて情報システム部門は発注者として本来行うべき役割と真剣に向き合わねばならない状況であった。具体的には、システム開発ベンダーからの問合せ対にして、情報システム部門が答えられずに業務部門へ丸投げしていた。逆に業務部門からIT部門にシステム関連の問い合わせが生じた時には、IT部門は答えられない為にベンダーに丸投げした体質に染まっていた。客観的に見ると情報システム部門は、伝書鳩のように中間に入り繋いでいるだけの存在であった。この情況を脱却すべく幾つかの大きな目標を掲げた。まずは、様々なドキュメントを自ら作成して細部に至るまで理解をすること。そうすることで業務部門やベンダーからの質問に答えられ、真の発注者としての役割を全うできる組織に生まれ変わることが一番の大きな目的として掲げた。つまり、ベンダー丸投げ依存の脱却が真の目的であった。

プロジェクトを開始する前の企画段階として関係者が集まり、言葉の定義や意味、そして共通認識を培うことを最初に行った。実際に定義した点は大きく分けて以下の２つである。１．発注者主導とは何か、２．委託管理とは何かを定義をした後に、今回のプロジェクトの中で中心的な考えとなる『備える』ことを定義した。備えるとは以下の3つに構成される。

1.やり方、2始まり、3これから

備える

旧システムはかつて職員がCOBOLでメンテナンスをしていたが、最終的には外部委託に切り替えた。しかしながらコスト面で大きな問題を抱えていた。例えば帳票1文字変更するだけで100万円掛かることに参加者も驚きを隠せなかった。このように運用保守に関して膨大なメンテナンスコストが掛かるため、市民サービス向上に至ることは無く、ITが足を引っ張ることが多く見受けられた。更によくある話として、設計書は存在するが差分の設計書をかき集めたとしても全て揃わず、結局はソースコードを見てメンテナンスを行うことになる。このような課題満載の状態から実現したいことを以下の様に掲げた。

1.業務と機能の関係がわかること。

2.影響範囲を特定し易くすること。

3.情報システム部門が全てを理解すること。

4.開発ベンダー以外の会社に変更しても対応できること。これは市長の強い要望として開発した会社以外も運用保守段階で入札形式により自由に企業を変えて継続できることを目的とした。

上記の目的を達成すべく検討した結果『AIST包括フレームワーク』を採用した。一番の理由として、独立行政法人が中立的な立場として開発したことでベンダーロックインを排除する事ができるというのが決定的要因となった。『AIST包括フレームワーク』とはプロセス標準、成果物標準、基盤フレームワークから構成されている。プロセス標準としては、要件分析工程、基本分析工程、開発工程においての標準化を実現できる特徴がある。2つ目の成果物標準としては、業務フロー、ユースケースを標準化できる。最後に基盤フレームワークは、ソフトウェアを構築するにあたり部品の作成管理を行うことと、共通認証認可機能を提供している。過去において開発会社が運用保守を継続的に行い、開発会社の人員を運用保守要員として常駐させるケースが多く見受けられたが、システムを構築する工程において全ての作業、成果物等を標準化できるため、開発会社が作成したソフトウェアを別の運用保守会社が維持管理を行うことが可能となる。

なぜ発注者が理解することが大切なのか

システム再構築を行うに伴い発注者自身が細部に渡るまで理解をしなければならないのかが見えてきた。１つは、特定のベンダーに依存すると他のベンダーはできなくなる。これは、やり方を標準化させることでマルチベンダー化が可能になる。２つ目は、やり方を絞ることでベンダーに依存することを防ぐことが出来る。また、札幌市職員の定期的な人事異動がある為、人に依存することなく組織として対応できるために特に有効と判断した考えが『グラスボックス』である。これは、標準化された上流工程ドキュメントを誰もが理解できることで、開発が正しくできているか、機能は正しく実装されているのかを確認できるものである。つまり、情報システム部門でも標準化されたドキュメントを『グラスボックス』化することで理解し、業務とベンダーと話ができ、発注者としての役割を全うすることに繋がる。メリットとして、業務フローをベースにして何を達成したいのかを業務部門と話し合うことで、余計な機能が膨らむことなく機能数、コストを抑えた開発に踏み切ることができた。また、メンテナンス面でのメリットとして、影響範囲となるユースケース、業務フローを特定することが出来る。更には、制度改正が明確に決まらない段階でも、影響を与える可能性のある場所を事前に確認することができる。

開発して見えて来たこと。

準備活動は情報システムが中心となり実施することでモチベーションが上がり、作成した後に振り返りの活動が生まれて改善意識と前向きな方向性に向かうことができた。成功したことを振り返ると情報システム内に自信が徐々に芽生え、言葉を伝える時に明らかに説得力が増したと実感している。ドキュメントはプロジェクト管理事例集にノウハウとして溜め込むことの重要性に気付き、個人の暗黙知も出来る限りドキュメントにして組織に残す方向性で進めている。大きな理由として人事異動は3〜5年の間に必ず生じるため対策として実施している。もし、ノウハウを組織に貯めずに放置するなら人に依存してしまい、人とノウハウも共に移動してしまうことになる。そのために、『グラスボックス』という考え方で情報システム部門という組織として今後も継続的に受け継がれ、発注者主導のシステムを維持管理することができるであろう。