どもども、Kemmyです。
システム開発の上流工程に「要件定義」という工程があります。
今回は失敗しない要件定義の進め方を説明します。
目次
要件定義とは
要件定義はシステム開発の最初の工程になります。
ユーザー企業の要望を調査・分析してシステムによって実現すべき機能を確定させていく工程です。
要件には、機能要件と非機能要件が存在します。
機能要件
機能要件は、ユーザーの要求を満たすためにシステムが実現しなければならない要件を指します。
非機能要件
非機能要件は、「機能要件以外のすべての要件」です。
非機能要件は、事業要件、業務要件、システム要件を設定（設計･実装）する際に発生する運用要件、移行要件、性能要件、セキュリティ要件、機密保護対策の要件などの機能以外の要件を指します。
非機能要件は、機能を実現（設計･実装）するためのインフラ（環境基盤）と考える事ができます。
また、非機能要件は極端な言い方をすれば「なくても良いが、なければ実用とならない機能」といえます。例えば、セキュリティ要件は実装されていなくても機能の実現を阻害することはありません。
また、性能要件も設定されていなくても実装や稼働を阻害しません。ただし、そのためにオンラインのレスポンスに数分を要したり、企業情報や従業員情報、顧客情報が簡単に盗まれては「システムに対する評価」は著しく低下します。
場合によっては「欠陥システム」の烙印を捺されてしまいます。さらに、 注意しなくてはならない事があります。これら非機能要件は実現の度合いによっては、開発コストを大きく押し上げる要因になります。
そのため、どの程度で実現するのか充分な裏付けのある検討･設計が必要になります。
ポイント
システムの要件定義では、システム化の範囲と、機能要件、非機能要件を明確化することです。
要件定義の進め方
具体的にはユーザー企業の経営者、情報システム担当者、業務担当者にシステム導入の目的・期間・予算を確認しながら、「要件の整理」「要件の調査・分析」「システム化の検討」「合意・承認」という作業を行います。
業務要件の整理/顧客へヒアリング
顧客へヒアリングし、業務要件の整理を行います。
「どんなシステムを作りたいか？」といった聞き方ではなく、「何に困っているか？」を確認することが大事です。
困っていることをシステム化して解決することが一番の業務改善になります。
要件定義を担当するには、どのようなことに困っていて、何を解決したいのかを具体的に聞き出せる力が必要になります。
また、現行システムを新しいシステムに置き換える場合は、旧システムについても理解が必要で、多岐に渡る事前調査が必要です。
要求の分析・システム化検討
ユーザーの要求、要望をヒアリングし、具体的に掘り下げることができたら、要求を分析しシステム化を検討していきます。
分析には機能情報関連図、業務流れ図、ER図などを用いて可視化していきます。
その結果、実際はシステムを開発しなくても良い場合や、業務フローを少し見直すだけで良い場合があるかもしれません。
やっぱり新たなシステムを開発するのが最適だ、という結論に至ってから、新たなシステムにどういった機能を持たせるのかを検討します。
そして、要件定義書に分析・検討した結果をまとめていきます。
要件の合意
作成した要件定義書を元にユーザー企業と合意します。合意と承認無しに要件定義を終え、設計・開発を進めるのはトラブルの元になります。
機能要件は当たり前ですが非機能要件も必ず合意を取るようにしてください。
後続工程に進むほど、要件不備による手戻りは工数負担が非常に大きいため、一つずつ合意と承認を取ることが重要です。
要件定義の成果物
作成する成果物は企業やシステム化の内容によって違いがあります。代表的な成果物は以下になります。
業務要件定義
・業務機能概要定義
・業務運用要件
・システム間インタフェース概要
・概念ＥＲ図
・ユースケース・エンティティマトリクス
・業務用語定義
下記、成果物をサンプルつきでまとめているページが参考になります。
超上流から攻めるIT化の事例集：要件定義：IPA 独立行政法人 情報処理推進機構
要件定義で失敗しないために
それでは良い要件定義書を作るうえで、気を付けないといけない勘所を紹介します。
ユーザーの要求のままシステム化しないこと
ユーザーはシステムのプロではありません。いまの業務の改善点をどのようにシステム化すれば解決するのか分かりません。はやりのAIやRPAを使えばできるんじゃないといった感じで話をされることもあります。これは仕方がないことです。
要件通りのシステムを作ったとしても、業務が改善されなかったら本末転倒です。だれも喜ばないシステムを作ることはやってはいけません。
ユーザーの問題ではなくシステムのプロとして、ユーザーを導くことができないといけないと考えています。
ユーザーが抱えているぼんやりした要望・課題・問題からいかに最適なシステム化を定義できるかを意識してください。
作成した要件定義書で設計が可能か考える
要件定義で、全ての要件を確定させたと思っていても、意外と要件が漏れていることがあります。
漏れがあると次工程以降で手戻りになります。工程が進むほど手戻りの手間が大きくなります。
要件定義の時に設計する視点から、要件定義の内容に過不足がないかを確認すると、抜け漏れに気づきやすいです。
要件の主要部分が決まっていない状態で次工程に進まない
要件定義のスケジュール期間内に、要件が決まらないことがあります。
本来であれば、要件定義の期間内に要件を全て決めるべきなのですが、ユーザーの都合により決まらないといったことが多くあります。
ただ開発側からすると、稼働までのスケジュールも決まっており、スケジュールが遅延するわけにもいかないため、未決の要件があっても次工程に進む必要もでてきます。
この場合、未決の要件の内容が重要です。
要件の枝葉部分（例えば特定の画面に表示する項目が1つ決まっていないなど）であれば問題ありませんが、システム全体に影響するような主要な要件が決定していない時は、絶対に次工程に進まずに、主要部分の要件を確定させることに注力してください。
現行と同じであっても、要件に落とし込むこと
よくあるのが、その機能は現行と同じでとユーザーが言うことがあります。
そして、要件定義書に要件は記載せず、現行通りの一文で済ますことがあります。
ただし、深く検討せずに、現行と同じと定義してしまうと、後続の工程で、実は現行と同じではダメだったということが結構でてきます。
要件定義の段階で気づくためにも、要件に落とし込んで、現行と同じでよいのか、しっかりと検討するスキームを作る必要があります。
最後に
いかがでしたでしょうか。
要件定義の理解は深まりましたでしょうか。
要件定義が超重要な工程であることは分かっていただけたかと思います。
ユーザー企業も巨額の予算を投じてシステム化をするのですから、喜ばれるシステムを作りたいですよね。
それでは要件定義を制して、システム開発を制しましょう！
ではでは、Kemmyでした。
