仕様はどうして決まらないのか？：情シス部門の地位向上（4）（2/3 ページ）

[營田（つくた）茂生，＠IT]

業務仕様を決めるための関係作り

　章題を「業務仕様を決めるための関係作り」とし、あえて「体制作り」としませんでした。これは、「プロジェクト体制」→「プロジェクト・オーナーから与えられるもの」という範囲だけではなく、永続的かつプロジェクト計画で捕捉できないすき間を埋める仕事が含まれるという思いからです。

　ITシステム化に当たっては、業務要件・業務仕様を決めるときがポイントです。それまでITシステム化されていない業務が対象の場合もあれば、すでにITシステム化されていてリニューアルする場合もあるでしょう。いずれの場合も、業務を担当する各部門／部署と、ITシステム化に当たっての要求・仕様を共同で決めることになります。幾つかのポイントがありますが、今回は重要な3つを挙げます。

（1）業務オーナーを決めろ

　1つの部署で完結する業務はほとんどなく、図2のバリューチェーン・モデルのように、多くの部門／部署にまたがって処理されていきます。ここで問題になるのが、「誰が決めるのか」「擦り合わないときどうするのか」です。業務オーナー部門が決まっていなければ、なかなか業務要件・業務仕様は決まりません。エンドユーザー部門だけを集めても、それぞれ相反する要求でまとまらない可能性があります。

　複数の部門／部署にまたがって処理されるとはいえ、その業務（あるいは事業）をやりたい部門／部署や、業務の結果に責任を持つ部門／部署があります。そのような部署をオーナー（部門）部署として決め、業務要件・業務仕様策定の中核を担ってもらう必要があります。本来は、ITシステム化のプロジェクトが発足した段階で業務オーナー部署が決まっているべきですが、決まっていない場合は情シス部門主導で指名し、取りまとめてもらうようにコントロールしましょう。なお、業務オーナー部署を決めるには、その業務のステークホルダーが分かっていて、最もオーナーにふさわしい部署に話を持っていくべきで、ステークホルダー間の関係性を無視してお願いしてもうまくいきません。

　図3に業務処理の流れと業務オーナー部署の例を示しました。業務オーナーは、その業務の起点となる部署（図3では部署A）か、最終的に承認を行う部署（図3では部署F）などが適しています。その業務をやりたい部署か、その業務の責任を負う部署と言い換えていいかもしれません。

図3 業務処理の流れ

（2）ステークホルダーの整理

　業務要件・業務仕様を決めるとき「ステークホルダー」を整理しておく必要があります。上に書いた業務オーナー部署を決めるためにも必要です。

　本来であれば、職務分掌（SoD: Segregation of Duties）が決まっていて、すべて文書化されていれば問題ありません。しかし、日本の企業では長期雇用を前提とした組織運営を行っており、文書化する文化ではありません。ある日突然担当者が代わって、その日から即戦力として働いてもらうのであれば、SoDの決定と文書化は必須です。日本の場合はそこまでドラスティックに担当者が入れ替わることがないので、文書化する文化が育たなかったのだと思います。

　SoDの決定とその文書化がなされていない場合は、関係者一同が分かるように、業務内容を洗い出した必要十分な資料を作ることになります。誰が作るかという問題は置いておきますが、このステークホルダーを整理するための資料を作るために、関係の各部門／各部署からヒアリングすることで、その業務の仕組みやそれぞれの部門／部署のかかわり方が理解できます。できれば、資料の作成を買って出ることで業務力のアップを図ることができます。

（3）whatとhowの分離

　何を作るのかというwhatと、どのように作るのかというhowの分離を常に頭に置いておかなければなりません。

　エンドユーザー部門／オーナー部門とも、長らくITシステムを使ってきた担当者が業務要件・業務仕様を策定する場に出てくることが多くあると思います。この時、常に頭に置いておく必要があるのがwhatとhowの分離です。

　業務要件・業務仕様を策定しているときに、何を作るのかということを聞いているはずなのに、なぜかその中に「どう作られるべきか」などのhow情報が含まれてきます。エンハンスの場合にはそれほど問題となりませんが、新しいインフラ・アーキテクチャを前提としたリニューアル・プロジェクトなどの場合には、そのhow部分まで業務要件・業務仕様として受け取ってしまうと、足かせとなって実装できない業務要件・業務仕様となってしまいます。

　本当に＜何をすべきか＞というwhatにフォーカスすることが重要です。

　逆のケースもあります。利用者は、ITシステムのインフラやアーキテクチャに、行動が制約されることを望んでいません。例えば、すべて「紙」で業務が組まれていた時には全く制約がなく実現できていたことが、ITシステム化をした途端、「できません」「手順が複雑」では本末転倒です。ある程度は、how（どう作るか：インフラやアーキテクチャ依存の部分）は前提としつつも、何かブレークスルーできる可能性もあるので、howを主張し過ぎないように留意する必要があります。