ITエンジニアの権限が分離できていないことも，正しい財務報告を阻害する大きなリスクとなる。例えば，現金相当の「ポイント」を扱うアプリケーションの開発と運用が同じ人物だったとすると，自分のアカウントのポイントを不正に増やすことができてしまう。

　ITエンジニアの権限が分離できていないことも，正しい財務報告を阻害する大きなリスクとなる。例えば，現金相当の「ポイント」を扱うアプリケーションの開発と運用が同じ人物だったとすると，自分のアカウントのポイントを不正に増やすといったことができてしまう。開発と運用の権限を1人のエンジニアが持っていると，自分に都合のいいようにプログラムを書き換えて，それを本番プログラムに適用させることが可能になるからだ。

開発者が本番DBに触るのはダメ

　とはいえ，アプリケーションごとに開発と運用を明確に分けていないケースは多いと思われる。特に，少ない人数で運営しているシステム部門では，適切に権限を分けることは容易ではない。そのような状況にいるITエンジニアには，ワーナーミュージック・ジャパンの取り組みが参考になる。同社は8人（開発担当5人，運用担当3人）のITエンジニアで，工夫を凝らして権限分離を実現した。

　同社はこれまで，アプリケーション開発とデータベース管理を同じ社員が担当していた（図4(1)）。機能追加作業やパフォーマンス向上作業を考えると，兼任していた方が，作業効率が高いからだった。米SOX法への対応において，この兼任を解消し，権限分離をする必要に迫られた。ワーナーミュージック・ジャパンの藤野氏は，「アプリケーション開発者が，本番環境のDBを操作できると，財務諸表にかかわるデータを修正できる可能性があったからだ」と説明する。

図4●ワーナーミュージック・ジャパンが考えた権限分離の例 アプリケーションの開発者とDB管理者が同じ担当者だったため，権限分離ができておらず，財務データの変更に気づけない恐れがあった。開発とDB管理のたすき掛けを考えたが，共通DBなどがあり，うまくいかなかった。そこで運用担当者へDB管理スキルを移転することで乗り切ることにした [画像のクリックで拡大表示]

たすき掛け案に死角あり

　システム部員を増やす余裕はなかった。そこで藤野氏が当初考えたのが，“たすき掛け案”による権限の分離だった（図4(2)）。たすき掛けとは，例えばA氏はシステム1の開発とデータベース2の管理を担当。逆にB氏は，システム2の開発とデータベース1の管理を手掛けるといったものだ。この方法についてガートナージャパンの松原氏は，「開発と運用が分離できていれば，たすき掛けは権限分離で有効な手段になる」と説明する。

　藤野氏は5人の開発担当者をたすき掛けの考えで，アプリケーションごとに開発とDB管理に割り振っていった。しかし予想外の問題が発生した。「どれだけ工夫を凝らしてたすき掛けにしても，アプリケーション開発とDB管理が重なってしまう」（藤野氏）のだ。それは，複数のシステムから参照や更新される共通DBだった（図4(2')）。

　たすき掛け案ではダメだと判断した藤野氏は，全アプリケーションのDB管理を運用担当者に任せようと考えた（図4(3)）。5人の開発担当は開発案件が多いこともあり，開発に専念させることにした。ただしDB管理を任せるといっても，同社の運用担当者はハード寄りのスキルが中心なので，すぐにできるものではなかった。そこで藤野氏は，DB管理マニュアルを改めて作成した。

　以前からDB管理のマニュアルは存在していたが，「あくまでも大まかな流れが書いてあるものだったので，読めば作業できるというものではなかった。今回作成したマニュアルは，履歴管理のバージョンの付け方まで説明した詳細なもの」（藤野氏）だという。このマニュアルにより，これまで属人的だったDB管理を標準化できた。異動や退職で担当者が変わっても，業務に支障がでない体制になったという。