業務と要件のミッシングリンク、あるいは仕様変更が永遠に繰り返される訳
»
要件定義が終わったはずなのに、仕様が凍結されたはずなのに、後から後から変更が繰り返されるシステム構築プロジェクトはよくある。変更が入ると一度作ったものを壊して作りなおす訳だから、時間もお金もかかる。
ユーザーのコスト意識がなかったり、単にSEのウデが悪くて設計にミスが多かったり、原因は色々あるだろう。
数ある原因の中でも、「やっぱココが出来てないからだよなぁ」という箇所が分かった気がする。これまで多くのシステム構築プロジェクトに携わってきて、本当にココが原因で起きている失敗が多いのだ。
★業務とシステム要件の狭間で
話の前提として、システム構築の流れをざっと振り返る。会社やプロジェクトごとにドキュメントの呼び方などには細かい差異があると思う。
1)今後こういう業務にしたい、を明確にする⇒通常、業務フローなどで表現される2)だから、こういうシステムが欲しい、を明確にする⇒通常、機能要件定義書で表現される3)システムはこういう風に動いて欲しい、を明確にする⇒通常、外部設計書（概要設計書）で表現される4)システムをこの様にして実装する、を明確にする⇒通常、内部設計書（詳細設計書）で表現される
以前に書いたように、1)や2)を決めるのは業務担当者（ユーザー）の責任だし、3)や4)はシステム開発担当者（ベンダー）の責任となる。もちろん、双方がお互いの仕事を円滑に進むように協力したり、時には指導することも必要だ。
で、今日問題にしたい断絶は、1)と2)の狭間にある。
断絶を埋めるためには、ピースが必要となる。僕の考えでは、こんな資料を作ることが鍵になる。
業務としてやりたいこと1)を、
きちんと2)に翻訳するために、
網羅的にパターン化して整理した資料
これを今、仮に「業務パターン」と名付けよう。
★業務パターンとして整理が必要なこと
業務パターンはその名の通り、「行われる業務をパターン化して整理したもの」である。分かりにくいと思うので、多くの人に馴染みがありそうな人事業務の例を出そう。
これは人事発令業務のパターンを整理した表（の、ごく一部の抜粋版）である。
発令とは「4/1付で営業1課課長に任ずる」というやつですね。異動・出向・昇格など、所属組織や役職の変更を会社から社員に正式に申し渡す行為である。
一方、人事システムの観点から見ると発令とは「社員の人事情報を書き換えること」に他ならない。
この表は、どういう発令では、社員のどの情報を書き換えても良いのか？を示している。黄色くした箇所を見て欲しい。「異動」では「現所属組織」を変えて良いが、「現所属会社」までは変えてはいけない。一方「出向」では「現所属会社」も変更できる。
会社が変わることを出向というのだから当然だ。だが、「海外赴任」の時に「現所属会社」を変えて良いのかどうかは、少し悩ましい。海外現地法人への出向をどう考えるか？を議論しなければならないからだ。
だからこの表を元に、人事発令業務の担当者の皆さんと「このセルは◯か×か」について、色々な側面から検討することになる。
業務を実際にやっている人は、「どんな業務をやっているか」について、順を追って語ることはできる。
だが、あの表くらい網羅的に「業務がどうあるべきか」を整理しなければ、システムをキッチリと完成させることはできない。
そして表なしで、完全に網羅的に語りまくれる人はいない。
「聞かれれば答えられるが、ゼロから網羅的には話せない」
という状態なのだ。
この表はゆくゆく、発令の入力画面一つ一つ（異動用の画面、出向用の画面・・）を設計するときの重要なインプットとなる。「異動の時には現所属会社を変更できないようにしておく」という機能要件を表しているからだ。
逆に言えば、この表で表現されている事を隅々までキッチリと議論しておかないと、画面一つ一つの動き方を決める時に、毎回考えなければならない。
毎回個別に考えていたのでは当然ミスが増えるし、ミスっていることに気づきにくい。結果として、後になって「異動の時に、現所属会社が変更出来ちゃうと困るので、直して下さい！」という、手戻りが起こるのだ。
それを「要件変更」と呼ぶ事もあるし、「設計ミスの修正」と呼ぶ事もあるのだが、余計な仕事が増えることには変わりない。
★何を業務パターンとして整理すべきか？
「どんなプロジェクトでも整理が必要な、必殺の業務パターン」というものは存在しない。業務によって、必要な整理が変わってくる。
参考までに今まで作ってきた例を挙げてみると・・
・商品種別と販売期間と販売チャネルの組み合わせパターン
・出荷方式と売上計上の組み合わせパターン
・申請の承認プロセスと権限階層のパターン
・休暇の取得パターン
などなど、実に様々である。
「このシステムを作るにあたって、どんな切り口で業務パターンを整理すればいいのか？」というのは、とても難しい問題だ。
例えば過去に人事システムの構築経験があれば、先ほど説明した「発令と情報項目の関係を整理するべき」という事を、知識として知っている。Excelのフォーマットも持っているだろう。これは初めて人事システムの構築に取り組む人に比べて、大きなアドバンテージになる。
以前、特許庁のプロジェクトが頓挫して話題になった。内部事情には詳しくないが、特許庁の基幹システムの様な他に例のないシステムを作ることの難しさは想像できる。今まで書いてきた文脈で言えば、「このシステムを作る時に、どのような切り口で業務パターンを整理すればいいのか？」を誰も知らないのだ。
誰かがCoolな切り口を思いつかない限り、カチッとした要件定義は中々できない。
僕自身の話をするならば、初めて取り組む業務であったとしても、「このプロジェクトでは、こんな業務パターンの整理が必要」ということが直感的に分かる事が多い。システム構築に関して僕が他人よりも優れた箇所があるとすれば、ここだと思う（例えばコーディング能力などは大したことがない）。上記の表も、初めて人事システムを構築した時に、誰に教わるともなく「だって必要でしょ」と言いながらたたき台を作ったのを覚えている。
★誰が業務パターンを整理すべきか？
業務パターンの資料を元に「何が業務として正しいか」を決めるのは、業務の担当者である。上記の表の◯か×かを選択する役割だ。
だが、悩ましい事に「この表で整理しましょう」と提案するのは、たいていの場合、システム開発の経験者にしかできない。ああいう形でパターンを整理することに慣れているのは、システム屋さんの方だからだ（パターン整理は、システムエンジニアリングの基本である）。
もちろん、システム開発経験がなくても「こんな表で業務を整理してみたよ」とサラリと作ってくれる業務担当者もなかにはいる。でも滅多にいない。
一方、システム開発者の方では「業務を決めるのはユーザーの仕事でしょ」と考えている事がほとんどで、「この表で整理しましょう」は、やっぱり滅多に聞かれない。
このねじれの関係（中身を決めるのはユーザーだがフォーマットを提案するのはシステム開発者）のおかげで、業務パターンがエアポケットに落ち込むことが大変多い。
ないと絶対に上手くいかない資料が、構造的に作られにくいのだ。
だから、いつまで経っても仕様変更が止まらないプロジェクトは、後を絶たない。
もし、業務パターンを整理する必要性を感じたら、あなたがどんな立場であろうと、自分でやりましょう。
必要性は気づいた人にしか分からないし、やれば絶対に後で楽できますから。
※このところ何回か「要件定義」について書きました。
関連記事のリンクをまとめておきます。
⇒懐かしの、第1回投稿・・。
SpecialPR