「聖火台のあるオリンピック競技場」の作り方：「訴えてやる！」の前に読む IT訴訟徹底解説（25）（3/3 ページ）

東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「聖火台のないオリンピック競技場」を題材に、システム開発における抜け漏れのない要件定義手法を解説する。

[ITプロセスコンサルタント細川義洋，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

要件の抜け漏れを防ぐ「机上シミュレーション」

　聖火台の件もそうだが、重要な決定事項の抜け漏れが発覚した際に議論に上るのは、担当者の無責任さを断罪する一種の「精神論」や、役割や責任の分担がどうであったかという「組織論」だ。

　しかし私は、原因をそこに求めたところで、問題の再発は防げないと思う。どんなに責任感を強く持っていても、抜け漏れや間違い、勘違いから人間は逃れられない。完璧な組織を作っても、中の人間が役割や責任を正しく理解していないこともある。人間が人間である以上、ミスは発生し得ることなのだ。

　先の裁判例でも、性能要件や排他制御をどちらが決めるのか忘れていたなど、客観的に見れば稚拙と言わざるを得ない点があった。しかし人間とは、ときにこうしたことをやってしまう稚拙な存在なのだ。では、どうすれば良かったのだろうか。

　筆者がオススメするのは「机上シミュレーション」だ。

　要件定義の際にプロジェクトに関係する皆が集まって、システムが本稼働した後の業務の流れや、その際のユーザー社員たちの振る舞いをシミュレーションし、「ITを使った新業務（ToBe）」を検証するのだ。

　そうすれば、「決まっていない要件」や「忘れられていた事柄」に気付く確率は、ぐんと高まるのではないだろうか。

リアルな想像で要件漏れを防ぐ

　ベンダーも、通常はシステムへの同時アクセス数や排他制御を気にするし、ユーザーにも聞いているはずだ。しかし、これから作ろうとしているシステムが使われる業務現場の光景やそこで働く人の心情まではなかなか推察できない。

　そこで有効なのが、「シナリオ作成」だ。

　AM9:00。ユーザーがPCを立ち上げると、夜中に寄せられた多くの注文がたまっている。その数は数十件に上り、周りを見ると、同僚のPCにも多数の注文情報が入っている。

　商品は翌日までにお客さまの元に届けなければならないから、11:00までには、全ての引き当てを完了させなければならない。今から2時間弱は、数百件のアクセスが販売管理システムと商品マスターに集中することになる

　こうしたシナリオをユーザーが説明すれば、「何人ものオペレーター」が「11:00までに」「われ先にと」引き当て入力をする光景やその重要さ、オペレーターの焦る気持ちまでベンダーも推測できるだろう。

　そうすれば、仕様書に性能要件が抜けていたことに気付き、「その日の注文を、その日のうちに処理できればいいだろう」と思い込んでしまうような間違いも防げたかもしれない。

　しかし、自分で行うわけではない業務を想像するのには、限界がある。そこでやっていただきたいのが、「シナリオの確認」だ。「ベンダーの技術者」「ユーザーのシステム担当者」、そして「ユーザーのオペレーター」が一堂に会し、システム化対象業務の流れをシミュレーションしながら、問題がないことを確認する、いわゆる「要件の妥当性確認」だ。

ウチは四半期毎に大々的な商品入れ替えを行います

では、新システムでもこの時期は、商品マスターの洗い替えをするのですね

ちょっと待って。さっき商品マスターを触っているときには、他の処理が止まるって言ったよね。この時期に、注文処理が止まっちゃうのはマズイよ

ああ、そうですね。それでは、排他機能について、もう一度考え直します

　こんな会話の中から、それまで気付かなかった要件や変更要望が出てくる。こうしたことを、全てのシステム化対象業務について行えば、業務に重大な影響を与える要件漏れの危険は、極小化できるハズだ。仮に納期に追われていたとしても、「『目的』を実現できないシステム」だけは避けなければならない。

　恐らく聖火台の件は、こうしたプロセスを踏まなかったのではないだろうか。

　2020年8月、オリンピックの開会式。各国の選手が入場し、五輪旗と日の丸が掲揚される中、聖火ランナーがトーチを掲げて入場する――そんな場面を、五輪の組織委員会、文部科学省、競技場の設計者、開会式の演出家が、一堂に会してシミュレーションしてみれば、聖火ランナーがどこに向かって走れば良いのか、そもそも、それは誰が検討すべきなのかが決められていないことに、すぐに気付いたはずだろう。