要件やシステム化の範囲はどうやって決めるのか？：美人弁護士 有栖川塔子のIT事件簿（12）（2/2 ページ）
システム化の範囲を定義するときに、業務の目的を実現するための「方針」に着目すると、合目的性の高いシステム作りができます。
じゃあ質問です。システム化の範囲や要件って、どこから導出されるべきだと思う？
答えはシステム化の目的！ それを達成するためにシステムを作るんだから。今回の在庫管理システムだったら、「在庫管理業務の省力化・生産性向上」かな。
ブブー。正解だけど、不十分。それだけだと要件やシステム化範囲を定義するにはボンヤリし過ぎて、直接の結び付きが分かりにくいんじゃない？
うーん、そうだね。そういえば、開発中にはだんだん、目的のことを意識しなくなってしまうよね。
アタシが見た要件定義書は、目的ではなく、それを実現するための方針に着目※1してたわ。一郎のとこのプロジェクトでは、目的を達成するための方針にはどんな物があったの？
こんな感じかな。
- 在庫管理作業の手順を簡素化する
- 定型的な作業や時間のかかる作業を機械化して高速化する
- PCに習熟していない人でも可能な操作にする
これを行うことで、省力化、生産性向上を実現するのが最終目的だよ。
業務プロセスを見たり、ヒアリングしたりしていったん抽出した要件を、この「方針」と結び付けて検証するのよ。
「方針と要件のトレーサビリティ」ってこと？
そうね。例えば、今回ユーザーから上がってきた要件のうち、
- 多数の在庫を一度に引き当てしたい
- 引き当ての振り向けを自動で行えるようにしたい
の2つは、方針の2番目「定型的な作業や時間のかかる作業を機械化して高速化する」というところにつながるでしょ？ だからこれらは必要な要件としてシステム化範囲の中に入れることになるのよ。
なるほど。目的と違って、方針と要件の関連は具体的だね。
でしょ？ でも大切なのはこの次よ。今度は、逆に方針を達成するためにできることはこれだけかって考えるの。この例で言えば、「定型的な作業」や「時間のかかる作業」は、他にも無いかってね。プロセスの確認やヒアリングをしながら、逆の方向でも考えるのよ。※2
そうか！ そうしたら、ユーザーも気付いていないけれど目的達成のために必要な要件が出てくるかもしれないね。
今回のシステムで、何か思い付くことある？
引き当てのときの承認だね。引き当て承認用の書類を紙に出力して、倉庫と本社にいる承認者の印鑑をもらっているのを電子化できないかな。ここに時間がかかっていたのでは、いくら引き当てを自動化しても目的を達成しないもの。
そうやって、方針から逆引きすると出しやすいでしょう？
そうだね。確かに「定型的な作業や時間のかかる作業」が他にもあるんじゃないかって考えたら、自然に出てきたよ。
目的達成のための方針から要件候補を搾り出して、この方針を達成するためにできることはこれだけだってなったら、自然とシステム化範囲が決まるでしょう？
確かに、業務プロセスに枠線を引くだけ※3では、こういうところは見逃すね。
漁に例えれば、プロセスに線を引く方法は網を使うのと同じかしら。全体をガサっと獲れて効果的だけど、モレも出る。方針との結び付けや逆引きは、一本釣り。これはと思った魚に狙いを付けるから確実性が高いのよ。両方を組み合わせることで、要件の網羅性と開発範囲が決まってくるわ。
わー、塔子って漁のことも詳しいんだあ。すごいねえ。
感心するポイントが違う！ もちろん、既存システムの更改でこれをやっても骨折り損になるけれど、新システム構築、特に今までシステム化していない業務を対象にするときには効果的よ。
今回の在庫管理は、業務としては珍しくないけれど、お客さんにとっては初めてシステム化する対象だから、やった方がいいかもしれないね。勉強になった。ありがとう。早速帰って方針と要件を見比べてみるよ。何かモレが見つかるかもしれないな。そうだ、お礼に今度、タマモンのバスタオルを持ってくるよ。
いらん！
じゃあ、釣り竿とか。
それも、いらん！！！
じゃ、じゃあ。今度、一緒に食事でも……。
えっ!?（ポッ）
今回のPOINT
- システム化の方針と要件を双方向に見直すことは、モレのない要件とシステム化範囲を定義するために有効
原作者より
要件定義は、不完全で整合性のないニーズを正確で実現可能な要件にしていくという難しい作業であり、だからこそ、成功すればユーザーから厚い信頼を得るチャンスでもあります。
「何をすればいいんですか？」と受け身の姿勢にならず、自発的に問題を見つけ、対応する要件を提案する。「言われたからやりました」「言われてないから知りません」ではなく、新業務のあるべき姿を理解し、何としてもそれを実現するという姿勢を持ち続ける。ここがOne of themの作業者に終わるか、信頼されるパートナーになるかの分かれ道だと、私は考えています。
塔子「のび太がジャイアンに勝ったのは、殴られても殴られても、逃げずに挑み続けたときだけよ」
※1 システム開発の目的と方針は混同されがち。目的はシステム導入によって享受すべきメリット（“コスト削減”や“新規顧客獲得”）を表すもので、具体的な業務イメージと結び付けにくいのに対し、本文中にあるような方針は、業務のどこがどのように変わるのか定義しやすく、システム開発のスタートとするのに適している。
※2 ボトムアップで「必要か」を検証し、トップダウンで「十分か」を検証する。赤や青は信号機に「必要」な色だが、紫は不要なので除外する。一方、信号の働きを時系列で考えると、黄色も加えれば「十分」であることが分かる。
※3 業務フロー図の一部を線で囲みシステム化範囲を表す方法も視認性が高く有効。方針からの機能導出と併せて行うと、相互チェックにもなって機能のモレを防ぐ確率が高まる。
書籍紹介
細川義洋著
日本実業出版社 2100円（税込み）
約7割が失敗するといわれるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。
細川義洋
東京地方裁判所 民事調停委員（IT事件担当） 兼 IT専門委員 東京高等裁判所 IT専門委員
NECソフトにて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムにてシステム開発・運用の品質向上を中心に、多くのITベンダー及びITユーザー企業に対するプロセス改善コンサルティング業務を行う。
2007年、世界的にも稀有な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。
- 要件やシステム化の範囲はどうやって決めるのか？
- 業務要件のモレを無くすためにマークすべき人とは？
- もしも要件定義の無いシステム開発の担当になったら
- もし要件定義担当者とベンダーが「グル」だったら？
- 修正の影響範囲が分からない？ そんなの徹夜でおやりなさい
- その性能要件は消滅しました（えっ！？）
- 要件が決まるまで、テコでも動きません！
- パッケージソフト導入の「お・と・し・あ・な」
- 排他制御でアイタタタ！―― パッケージソフトの落とし穴
- 要件定義を決めるのはベンダーの仕事でしょ？
- そもそも要件定義って何なのよ
- IT訴訟弁護士「塔子」参上！
- 登場人物紹介 有賀一郎
- 登場人物紹介 西園寺彩音
- 登場人物紹介 成兼章介
- 登場人物紹介 有栖川塔子
- 登場人物紹介 全員
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
ベンダーよ、シェルパの屍を越えていけ 〜 細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」
リスペクトなきプロジェクトには死が待っている――山本一郎さん（やまもといちろう a.k.a.切込隊長）と、東京地方裁判所 民事調停委員 細川義洋さんによるDevelopers Summit 2014の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた。
美人弁護士 有栖川塔子のIT事件簿 登場人物紹介
塔子、彩音、イチロに章介。登場人物のプロフィール。- 美人弁護士 有栖川塔子のIT事件簿 バックナンバー一覧
要件定義が固まっていない、途中で追加や変更が頻発して大混乱――開発プロジェクトで起こりがちなトラブル事例の対応法を、IT訴訟専門の美人弁護士「塔子」がビシビシと伝授します。