 |
1. 申請者が承認者を選ぶことで，業務の流れと承認ルートを一致させた 2. グループ会社を含め1人に一つの新IDを実現するための調整作業が難航した 3. FeliCaカードを使って，扱いやすく安全なID認証の仕組みを導入した |
 |
「どう考えても，こうするよりほかに手立ては無い」「どうしたら，業務部門やグループ企業の理解を得られるのか」──。
2007年春，工作機械メーカーのアマダでは，社内システムへのログイン用IDを申請・認証するシステムの構築が始まっていた。しかしプロジェクト内のリーダーの1人，大野 実氏（ICTシステム部 オープンシステムグループ リーダー）は，頭を抱えていた。使いやすく，セキュリティ・レベルも高いIDシステムを作ろうと意気込んだものの「一般的なID管理の仕組みでシステム化したのでは実態と合わない。組織間の調整も多すぎる」（大野氏）と感じていたからだ。開発メンバーは何度も挫折しそうになっていた。以下，それらの問題をどう解決し，構築を成し遂げたのか，同社の軌跡を見ていこう。
初期コンセプトを全面見直しせよ
同社のID管理の課題を整理すると四つある（図1）。（1）IDを申請して取得する処理がシステム化されていない，（2）業務システムごとに異なるIDが発行される，（3）海外から業務システムを使えない場合がある，（4）利用者のID管理に甘さが目立つ，である。
IDシステムの構築を主導したのは，同社のホスト・アプリケーションを再構築するプロジェクトで基盤を担当した大野氏のグループ。Webシステム向けのユーザー認証機構を中核に，まずは（1）を解決すべく，ID申請システムの開発に取り組んだ。
しかし開発の初期段階で，いきなり大きな壁にぶちあたった。グループ・リーダー会議の席で，「システムのコンセプトが却下され，全面見直しになってしまった」（大野氏）のだ。
大野氏が提案したのは，組織図に基づき申請内容を上司が承認する，一般的なワークフローだった（図2上）。組織図で上司に当たる者が，承認者として機械的に決まる仕組みである。しかし「臨時の社内プロジェクトなど，組織図と業務の流れが一致しない場合に，承認者が可否判断を下せない」「人事データの更新が遅れると，実態に沿った承認者を指定できない」といった問題が指摘された。
これらの問題を解消するため，大野氏のグループはID管理製品や他社事例について調査した。しかし，解決の糸口が見つからない。数日後，「現場の状況を最もよく分かっているのは申請者本人だ。申請者が承認者を選ぶ方法なら，実情に合う承認フローの仕組みを実現できるはずだ」（ICTシステム部長 武尾 清氏）との助言を受けて，発想を変えることにした。つまり，組織図ではなく，申請者自身が業務の流れに沿った承認者を指定し，承認依頼通知メールを送るようにしたのだ（図2下）。こうすれば「承認者も可否判断が下せるし，人事データの同期が遅れても問題ない」（大野氏）。
独自な仕組みだけに，市販のID管理製品は使えず自社で開発するしかない。テスト段階では，使い勝手の悪さが指摘され，権限の追加・変更と削除を色分けする修正があった。2007年秋，ID申請システムがようやく稼働開始した。
