業務部門へのシステム開放とITガバナンスはどう両立？：業務アプリ運用で泣かない（2）

社内SaaS／クラウド環境への移行で、一部の業務アプリケーション構築などのプロセスを業務部門に委譲できることは分かった。だけど、ITガバナンスがうまく効かなくなるのでは……？どうすれば両立できる？

» 2013年03月04日 18時00分公開

[田澤久，株式会社テラスカイ]

ITガバナンスの確保

　第1回で紹介した「業務担当側に開発権限を解放する」としても、ITシステムとしてのガバナンスを確保する必要がある。そのためには、開発作業を進める上での規定が必要であり、その規定通りの運用が為されているかをモニタリングする必要がある。

　守るべき規定と、運用においては利用者側とITシステム部門の役割の明確化、作業の流れ、承認ポイント、実データを扱う際の注意事項など、具体的な開発内容に踏み込んだ取り決めが必要だ。これは利用部門だけでもITシステム部門だけでも決められるものではない。

　もう少し踏み込んでみたい。実際に、どんな開発作業を利用者側に解放できるのか？また、解放できない開発作業とは、どんなものなのか？

　開発対象となるアプリケーションとセキュリティの観点から、筆者はその切り分けを以下のように分類した。

　上図のLayer1～2が利用ユーザー部門に、Layer3がITシステム部門に相当する。

　画面、フローの開発は、Layer1～2で完結できる仕組みとする。その上で、オブジェクト（データベース・テーブル）に手を加えるような、他の利用者に影響がある開発に関しては、ITシステム部門の承認を必須とする、もしくはITシステム部門で開発を担当するという仕組みが考えられる。

画面開発の流れ例（Layer1, 2で完結）

　利用部門では、突発的なキャンペーンなども適宜行われており、その時にのみ使用する項目を入力できる画面、レポート機能などが必要になる。また、この手のものは、一時的に利用したら、後はもう使わないということも多い。このような細かいものの開発を、都度ITシステム部門に依頼していては、タイムリーな提供は望めないし、ITシステム部門としても、フォローし切れない案件となる。

　繰り替えしになるが、そのような事情から、いままでは「データをエクセルでダウンロードできるようにしておいたので、あとは手元で処理してください」ということになっていた。

　しかし、ツールとルールが提供されることによって、安心して便利な画面を開発できるようになる。

データベース・テーブルへの項目追加が必要な画面開発の流れ例（Layer3の承認が必要）

　オブジェクト、データベーステーブルへの変更が伴うような開発の場合は、IT部門によるチェックが必要になる。利用側は、オブジェクトを変更してしまうと、どの範囲にまで影響が及ぶかといったことは分からない。そこは、IT専門性が問われる判断になる。よって、レビューおよび承認と、本番環境への適用は、IT部門の担当作業となる。

　いまのクラウド・ツールでは、デプロイの権限管理まで設定できるものは見当たらないが、近い将来、デプロイの範囲と担当者を結び付けて管理できるツールが登場することが予想される。

実際に取り組み始めている企業がある

　ハードルが高い取り組みではあるが、実際に実現しようとしている企業もある。実名は伏せておくが、その企業の開発部は、売りのシステム開発が中心の業務となっており、事業部の業務を支援するような守り側のシステムの開発は後手に回ってしまっている。

　そこで、事業部自らがSalesforceを導入し、開発部には軽微な管理と、エラー監視程度を任せ、事業部門で業務のあり方、必要なITシステムを作り始めている。専門的な内容に関しては、研修を受け、専門家のアドバイスをもらいながら進めるなど、一般の開発部、SI会社がやるような手段も取り込みながら、ITシステムを上手に使った業務改善を実施し始めている。