システム開発における「要件定義」についていろいろ調べていると、書籍やネットの記事で異口同音に「まず、最初にシステム化企画書が必要です。」と書かれています。しかし、浅学ながら筆者が触れた範囲では、「では、どのような調査を行ってシステム化企画書を書くのか」を具体的に説明して下さっている資料には出会ったことがありません。
いろいろな場所で「要件定義はユーザの責任」と言われながら、現実問題としてユーザによる要件定義が出来ずにいる大きな理由の一つではないでしょうか。
以下に「PM＋BAの実践講座（株式会社アイ・ティ・イノベーションのブログ2011.2.8）」の一節をご紹介します。
このシステム企画書が無いままＩＴプロジェクトを実施すると、多くの場合、要件定義フェーズにおいて、仕様を定めるための基本方針がユーザ個人の属人的な思いに委ねられてしまいます。その結果、要件定義は終わらず、ＩＴプロジェクトは迷走してしまいます。
では「ＩＴ構想・企画」では、どのようなことを実施したら良いのでしょうか？
そのことに関し弊社では、システム企画書としてまとめる内容は、次のようなレベルが必要であると考えています。
・ 発注側企業において投資判断として社内決裁で出来るレベル
・ また同内容を基にして、システム開発部門もしくは開発ベンダーに対し、ＲＦＰとして提示出来るレベル
そのプロセスのイメージは次のとおりです。
ここで最も重要なことは“Ｗｈｙ”、つまり何のためにこの企画を計画し実施する必要があるのかを明確にすることです。
その定義を行うためには、その企業のビジョンや経営戦略に基づくトップダウンからの要求である“1.1ビジネスの方向性を理解する”こと。そして現状およびその課題を確認するボトムアップからの要求である“1.2現行の業務・システムを把握する”こと。この両方から、現状（As-Is）と将来（To-Be）を定義し、そのギャップである要求を洗い出し・整理する“1.3業務・システムの要求を概括する”ことを行うことで、“Why”を明確にします。
この記事における「ＩＴ構想・企画プロセス図」における第1ステップは以下の通りになっています。（上記記事の太字の部分をご参照ください。）
１．要求の取りまとめ
１．１ビジネスの方向性を理解する（トップダウン(経営)の視点）
１．２現行の業務・システムを把握する（ボトムアップ(現場)の視点）
１．３システムの要求を概括する（１．１と１．２の統合）
ほんの3行からなるＴｏ－Ｄｏなのですが、調査・検討する領域は非常に広く、作業も大変ですし、さらに「脳みそ」をフル回転させないと成果に結びつかない内容です。
では、この難題にどう挑めばよいのか考えてみたいと思います。
「システム化企画書」にしろ「要件定義」にしろ、この分野の情報は殆どがシステム屋さんによって書かれています。そしてシステム屋さんにとっては「システム化企画書」が出来てからが自分たちの仕事になるので、この企画書については情報を発信してくれていません。
一部「要求開発アライアンス」という活動をなさっているメンバーが経営レベルから参画する
Openthology手法による「要求開発」を提唱しておられますが、ユーザにはちょっと手に余るように感じられます。
システム屋さんにとっては「システム開発」ありきの議論になっていますが、ユーザ出身の筆者としては「業務」に着目したいと思います。次の図をご覧ください。
企業活動は、大きく眺めるとこの図のように５つのパーツから成り立っています。
1. 諸規定・制度
2. 組織・分掌
3. 業務プロセス・業務ルール
4. 人材・スキル
5. ＩＴシステム
企業がシステムを開発しようとしていると言うことは、何かの環境変化が起きていると言うことになります。環境変化に直面した場合、企業の採るべき態度は、この５つのパーツそれぞれについて「採用すべき変化・革新」を検討し１～４の実態を十分に把握した上で、５．ＩＴシステムに手をつけるのです。（現代では、殆どのケースで何らかのＩＴが必要ではあると思いますが。）
各項目ごとに見て行きましょう。
1.
諸規定・制度
規定・制度について組織運営上の阻害要因となる項目をあげてみると以下のような状況が考えられます。組織が上手く回っていないと思われた時には諸規定・制度も再検討しなければなりません。（ThinkIT
第３回：規定・制度、組織・機構を改革する みずほ情報総研 片田 保より抜粋）
l 決裁権限が状況によって変わってしまうなど、曖昧な運用が行われている
l 決定関与者が多く、意思決定ルートが複雑である
l 紙文書のみを対象とし、電子データによる処理を認めていない
l 回覧・決裁文書の分類が不明瞭である（決裁ルート、保存・管理ルールが曖昧になっている）
l 人が介在して処理することを前提とした事務処理規定となっている（担当者の配属が前提となっている）
l 業務の括り方（単位）が組織ごとに異なるうえに細かすぎ、現状の組織ありきの事務処理になっている
l 情報管理やセキュリティに関する諸規定がない
l 業務プロセスにおけるリスク管理が不十分である
l 従前に捉われすぎた管理によって組織や働き方が硬直している
l リモート勤務等による処理が不明瞭である
2.
組織・分掌
社内組織を理解することにはいくつかの目的があります。
特に、プロジェクトの責任者に任命されたリーダーが社内の「組織力学」を理解した上で活動することが必要なのです。
(1) まず、課題解決を必要としてる組織が、どのような構造になっていて、その課題はどの部門が関連しているのか、ステークホルダーを洗い出す際に重要になります。
(2) プロジェクト・オーナーや、開発予算権限者の認識
(3) 特に、事業部制組織やマトリクス型組織では、システムをどこまで標準化・共通化するかするのかを判断することはかなりハードルが高い判断となります。
(4) システムの検討をしようとしてる「あなた」は、どこの組織に属し「誰の」指揮下でこのプロジェクトをしようとしているのかを知る。
(5) この、組織の「力学」を判断できるのは肌感覚を持っているその企業のユーザ（社員）であり、外部のコンサルタントには殆ど関与できない領域になると考えられます。
(6) 上記(1)～(6)は、組織の外観からのポイントでしたが、組織の内部に対する検討ポイントもあります。
l 組織構成上の問題は発生していないか？
l 組織の管理のレベルが低く、組織の分掌が明確でない。
l 人材が足りず必要な業務に担当者がアサインされていない。
l 「部」や「課」等のレベルでサイロ化が発生している。
l 特定業務が属人化していて、業務の偏りが起きている。
l 業務ノウハウの若手への移転が進んでいない。
l 担当者が定められた業務をルール通り行っていない。
システム開発が必要だと見込まれる課題を抱えた組織に、こうした問題が発生している場合では、システムを検討する以前に現状の問題を解決し、現状において業務を最適化することが必要なことは申し上げるまでもないと思います。求めるシステムも変わってくる可能性があります。
また、組織構成上の問題は、気づくことが困難な場合が多く組織間のコンフリクトに結び付く場合もあるので注意が必要です。
以下に組織・分掌に関わる問題を解決した事例を紹介します。
（出典：ビジネスプロセスの教科書 山本政樹著 を筆者が要約加工）
ここに、ある問題を抱えた会社があります。会社の名前は L T N社とします。
L T N社は数十万人に及ぶ会員にインターネツト接続サービスを提供しています。L T N社は代理店からの電話等による問合せに対応する「代理店支援センター」機能をアウトソースしていました。
問題の内容は「代理店支援センターの運営を委託しているアウトソーシングベンダーの品質が低くて悩んでいます。代理店や、代理店を管轄する営業部からの苦情が一向に減らないのです。以前からベンダーには改善要望を出しているのですが、一向に改善の兆しがありません。」と、言うものでした。
L T N社としては、これらの原因は代理店支援センターを運営するベンダーのオペレータ教育が足りず、応対品質 (お客様に対する対応の丁寧さや正確さ )が下がっていることにあると考えているようでした。
図１が調査した時点での組織体制です。（筆者が加工作成）
図１
そこで、ビジネスアナリシスを実施して原因を探ってみました。
その結果分かったことは・・・
1. 「代理店支援サポートセンター」は、同じコールセンター業務と言うことで「ユーザーサポート部」に所属していた。
2. 「代理店支援サポートセンター」が「ユーザーサポート部」に所属していたため、営業部からの情報はすべて「ユーザーサポート部」経由となっていたため、タイムリーに伝達されていなかったり、連絡が漏れることも発生していた。
3. 「代理店支援サポートセンター」から営業部への問合せも「ユーザーサポート部」経由となっており、最終回答を得るために時間がかかっていた。
4. 「代理店支援サポートセンター」が「ユーザーサポート部」においては、本来業務ではなく、また、人数も少なかったためサポートが疎かになっていた。
などでした。そこで、ビジネスアナリシスの結果を反映して組織の見直しを行い、図２のように、「代理店支援サポートセンター」を「営業部」直轄の組織体制に変更して問題を解決することが出来ました。
図２が見直し後の組織体制です。（筆者が作成）
図２
このケースに見られるように「組織・分掌」に関わることは、一旦決められてしまうとそれが「前提条件」となってしまい、問題の原因となっていることに発想が及ばないことがよく起こります。また、こうした場合、諸規定・制度も変更することが必要となるため、改革のハードルが高くなります。また、この例のようにアウトソースしている業務の場合には平素の情報交換が希薄になりやすく注意が必要です。
今回は、ここまでとして、次回は「業務プロセス・業務ルール」「人材・スキル」及び「ＩＴシステム」についてお伝えしたいと思います。