はじめまして、ケイトと申します。2人の娘を持つ三十路ＳＥでございます。
STSには4年前に中途入社して、それ以来、主に業務システム開発を担当しており、現在もとあるシステムの開発プロジェクトにリーダーとして携わっております。そんな私から、今回はシステム開発を成功させるために一番重要と言っても過言ではない「要件定義」についてお話したいと思います。
そもそも要件定義って？
要件定義とはそもそも何か、簡単に言うと、「システム（ソフトウェア）開発において、システムに必要な機能や性能を決める作業」です。
一般的にシステム開発は
のような工程で進むことが多く、要件定義はその一番始めの作業ということになります。新しいシステムを開発するということは、何かしらの課題をシステムによって解決したいからだと思います。課題は企業毎にさまざまですが、
- ・手作業でやっている◯◯の作業を簡単にしたい。（効率化・時短）
- ・間違いを減らしたい。（品質向上）
- ・点在する情報をまとめてわかりやすく参照したい。（データの有効活用）
- ・顧客に自社サービスを効率よく提供したい。（サービス向上）
のような内容があると思います。
上記のような課題を解決するためにシステム開発を開始するわけですが、どのようなものを作ればそれが達成できるのか、ゴールを決めなければスタートもできません。
例えば、みなさんも料理をされるときには料理の種類、使う材料、作る量、必要な食器、食べる人などをはじめに考えるのではないでしょうか。システム開発もそれと同じです。
まずはお客様と開発会社（SIer）が話し合い、作りたいシステムのイメージを共有・整理します。具体的に話し合う内容としては、
- ・使い方（業務上どのように利用するか）
- ・機能（システムでできること）
- ・性能（処理の速さや同時に使える人の数）
などです。
最終的には、整理した内容をもとに、業務フローや業務シナリオを作成し、ユーザと認識の齟齬がないことを確認して要件定義は完了となります。一見簡単なように思える要件定義ですが、実はここでのミスが後の工程に大きく影響を及ぼすことが多く、システム開発の成功を左右する一番重要な工程なのです。
要件定義の掟
私もこれまで様々なプロジェクトを通して、要件定義を経験しました。失敗もたくさんしてきましたが、その中で学んだ要件定義の大事なポイントについて皆さんにご紹介したいと思います。
掟その1：多忙でも準備に妥協することなかれ
お客様の中から、システム構築に必要な業務知識を持つ方がプロジェクト担当となり、その方と打合せを繰り返しながら、要件定義を進めていくことになります。私のお客様の多くは通常の業務と兼任でシステム開発の要件定義に参加されていました。システム開発の担当者に選ばれる方ですので、重要なポジションにつかれており、他の方にお仕事を移譲できずに多忙となる場合が多いです。
要件定義中は現状の運用の整理や課題の分析、ユーザへのヒアリング等を行うことになり、お客様担当者にも多くの作業が発生します。担当者が多忙のため、これらの作業を十分に行えないまま、スケジュールを守ることを優先して検討を進めたために最終的に実際の運用では利用されない機能が作成されてしまうこともありました。
そうならないために、「情報収集」に妥協しないことが重要です。情報を集めるためにはお客様の協力が不可欠です。開発者側だけでどうこうできる問題ではありません。
多忙で十分な情報収集ができていないのであれば、お客様のプロジェクトの担当者以外も巻き込んで、タスクの調整や体制の追加・変更を検討します。時には勇気を持ってスケジュール延期をご提案することも必要です。
掟その2：スコープを広げすぎることなかれ
業務システムを作る場合、既存システムから完全に乗り換えるか、新しいシステムが既存システムと連携しながら動くことになります。しかし、すでに使われているシステムを活かしつつ、足りない部分を開発することのほうが圧倒的に多いため、既存システムの考慮は必要不可欠と言ってもいいでしょう。
要件定義を行う中で、この既存システムとの役割分担を明確にしておくことが非常に重要になってきます。これまで通りのシステムでこれまで通りにやる部分と、新しいシステムで行う部分を初めに明確にしておかないと検討中にプロジェクトのスコープ（範囲）がブレてきてしまいます。お客様は「せっかく新しいシステムを作るのだから、あの機能も、この機能も入れたい！」となりやすいのですが、そうやって機能を増やしていくと、想定していた予算やスケジュールでは対応できなくなっていきます。その調整が顧客と開発者でうまくできないでいると、プロジェクトはデスマーチと化すのです。。。
要件定義では、常に「本当に必要なものはなにか」を考え、時には諦めることも必要です。必要と思って焦って検討して、作ってみたら使い物にならなかったでは元も子もありません。まずは新システムで運用をはじめて、そこから発生した具体的な課題から追加機能を検討するのも一つの手です。そのようなご提案をするのも我々の大切な役割です。
掟その3：資料化を疎かにすることなかれ
当たり前のことかもしれませんが、なかなか難しいのが資料作成です。要件定義ではお客様との打合せが相当数必要となります。その中で決定される重要な事項も数多くあり、それらは議事録や別途資料にまとめられる必要があります。
打合せをこなすことに注力しすぎて、議事録作成や資料化はないがしろにされがちですが、要件定義時の成果物は後の工程での大切な「指標」となりますのできっちり作成して、最後にお客様にも承認を頂く必要があります。また、決定事項だけでなく、お客様の要求事項を残しておくことも重要です。要求事項とはお客様の考える現状の課題と理想の状態・結果を指します。「◯◯の運用ができること」という大きなものから、「◯◯機能で□□が参照できること」というような細かいものまであります。
私の経験したプロジェクトでも、後々の工程で課題が発生した際に、仕様を決めた経緯を確認するために作成した資料を確認することが多くありました。要求事項はヒアリングして開発者側で作成することも可能ですが、やはりお客様に作成頂くことで、俗に言う「言った言わない」問題を防ぐことができます。それなりに時間を要する作業ですので、お客様側にもそのような作業が発生することをお伝えし、余裕のあるスケジュールで要件定義が行えるように計画を立てることが理想です。
最後に
「全員が幸せになれるにはどうしたらいいか」
を常に考えることです。
お客様のシステムを利用される方々はもちろんですが、開発者側のメンバーも得るものがあって、プロジェクトに参画してよかったと思ってもらえるようにすることが理想です。今後も様々なプロジェクトを通して要件定義やプロジェクト管理のテクニックを磨き、
「誰もが幸せになれるシステム」
を安定的に世に送り出せるよう精進したいと思います！
それでは！