1.業務システム開発に大事な要件定義とは

---

はじめに業務システム開発に大事な要件定義に関する基礎知識について簡単に説明します。

 

業務システム開発の流れ

 

 

上記が一般的な業務システム開発の大まかな流れです。

要件定義は業務システム開発の一番最初の工程であり、要件定義に問題があると、その後の工程に影響してしまう可能性が高くなります。

 

例えば、要件定義の段階でクライアントとの意志の疎通がしっかりとしていないことで要件定義に欠けている部分があったまま、本番環境への移行の段階で「伝えていた機能がない」ような状況になってしまうことが考えられます。

最悪の場合、賠償問題や責任問題に発展する可能性もあることから、要件定義は慎重かつ丁寧に、何よりもクライアントの要望を正確に汲み取って決めていく必要があります。

 

 

要件定義とは

要件定義とは業務システム開発の基盤や根幹となる情報を定めたものです。

業務システム開発は要件定義を元に機能の実装やクライアントが求めることを満たすのが基本であり、言い換えれば要件定義にないことを勝手に盛り込んだり、要件定義にあることが備わっていなければ、成果物として認められません。

 

成果物として認められないということは、報酬を受け取れない可能性があります。

同様に賠償問題に発展することになれば、多額の賠償金を支払う責任が生じます。

 

もちろん、契約次第、雇用関係次第でありますが、どのような立場においても要件定義を行うということに責任感を持っておく必要があります。

要件定義を簡単に説明するとすれば「クライアントの要求を精査し、課題や問題の解決策決めて、開発工程を定めること」と言えます。

 

クライアントの要求は納期、予算、機能、性能、デザイン、UIなどなど多岐に渡ることから、それらを全部満たす＝解決策を考えた上で、具体的な開発工程を前もって提示し、承認を受けることで、業務システム開発の次の工程に進むことができます。

 

 

 

 

2.要件定義で決めなければいけない要件

---

次に要件定義で決めなければならない要件について簡単に説明します。

 

業務要件（業務プロセスの整理）

業務要件は業務プロセスに洗い出しや整理、精査を行い、具体的な課題や問題を抽出し、具体的な課題や問題を解決するためには何が必要かを決定することを指します。

クライアント側からの要求が曖昧になることもあり、エンジニア側は曖昧な部分を排除し、可能な限り具体的な解決策を提示しなくてはなりません。

 

また、業務要件を正確なものにするためにも、実務に携わる人、もしくは現場を理解している人と綿密にコミュニケーションする必要があります。

トップダウンで話を進めてしまうと、現場や実務担当者に落とし込んだ時にトラブルが発生する可能性が高いからです。

 

同様に現場や実務を理解していない人と進めることで、かえって非効率になる、もしくは他の部門や部署、もしくは担当に負担の皺寄せが生じることもあります。

エンジニアの基本とも言える、無理や無駄、非効率排除を前提とするならば、クライアントの要求に答えつつ、現場の人間の声もしっかりと受け止めて業務要件をまとめるべきということです。

 

 

機能要件

機能要件とは業務システム開発で必ず実装する機能を決めることを指します。

言い換えれば、必要最低限、備えていなければならない機能です。業務要件を満たすための具体的な解決策を開発するための骨格に落とし込む作業と言えます。

 

例えば、ECサイトの構築であれば、カート機能、決済機能、会員登録機能、会員管理機能、メール自動応答機能などが思い浮かびます。

これらの一つでも欠けてしまうとクライアントの要求を満たすことができない、もしくは課題や問題を解決できない状況に陥ってしまう可能性が高いです

 

特にクライアント側はエンジニア側よりも具体的な機能や仕組みを完全には理解できないことから、必要な機能要件が揃っていなくてもOKのように感じることも考えられます。

結果、成果物が要件を満たしていないということを生み出してしまいがちです。

 

いわゆる「思っていたのと違う」ということにならないためにも、業務要件を満たしつつ、クライアントの要求に答えつつ、課題や問題を解決する機能を盛り込んでおくようにしましょう。

 

 

非機能要件

非機能要件とはクライアント側の要求の中でも、より曖昧なもの、または技術的にできるかわからないもの、コスト的に難しかったら諦めるものなどがあげられます。

これらは必ず実装しなければならない要件ではないにせよ、コストや納期、もしくは技術的リソースの状況に応じて対応するかを判断する必要があります。

 

非機能要件は必ずしも実装しなくても良いとは言え、実装できればクライアントからの評価があがります。

継続的な付き合いが生まれることで、エンジニア側の将来的な利益や売上につながることを考えると、可能であれば実装したいものとも言えます。

 

ただし、コストが合わない、納期的に無理、もしくは技術的リソースが足りないなどの状況で安易に実装しようとすると、必須である機能要件を満たせないような結果に陥りがちです。

コスト・納期・技術的リソースがある場合のみ、もしくはクライアント側が難しい、コストが高そう、納期が伸びそうと思っているだけでエンジニア側からすれば簡単かつすぐに終わるようなもののみ状況に応じて対応するのがおすすめえす。

 

 

 

3.要件定義の流れ

---

次に要件定義の大まかな流れを簡単に説明します。

 

システムを利用するユーザーの要求ヒアリング

まずはシステムを利用するユーザーの要求ヒアリングから始めましょう。

いわゆる実務担当者、現場で働く従業員や実務を理解している役職の人です。

 

業務プロセス、作業手順、権限の範囲、前後の流れなど、関連する業務、担当、部門や部署、顧客への対応、入力するデータ、データの加工方法、データの受け渡し方法など、次のシステム要件を定める段階で必要な情報を集めます。

 

また、デバイスのスペックやネットワーク周りの情報も集めておきましょう。

古すぎるOSやデバイスを使っていてパフォーマンスに余裕がない、またはセキュリティ性を確保できない場合は、それらの課題を先に解決してもらうべきです。

 

その他、要求ヒアリングによって情報を集めることは大切ですが、すべてを鵜呑みにしてはいけないということも覚えておきましょう。

エンジニアでないからこそ、自由な発想で困ったこと、悩んでいることを教えてくれる可能性がありますが、技術的に難しいこと、コストが合わないことまですべきではないと留意しておくべきです。

 

 

各要求をシステム要件へ

クライアントの要求、実務担当者や現場の担当者の持つ課題や問題の解決策が実現可能であるなら、次は各要求をシステム要件に落とし込む段階に移ります。

普段の業務や作業における課題や問題を一番近くで感じている人にヒアリングした結果に基づいて、エンジニアとして課題や問題の解決策を模索しつつ、実現可能なものを抽出します。

 

注意点としては、自分の能力を越えた解決策を妄想しないことです。同じく、解決できない課題に取り組みすぎることにも注意しましょう。

あくまでも実現可能なもの、最低限必須であることを抽出して、時には実現できないことは「技術的にできません」と断言する勇気を持つことが大切です。

 

前述した機能要件と非機能要件を意識しながら、開発の段階で可能となるもの、もしくは完全に開発に組み込まないことを明確にしておくと良いでしょう。

その他、技術的リソースがあり、現場の人間の声が正しい場合においても、予算・納期が伴わなければ実現できると言うべきではありません。できないことをできるというのはリスクであると理解すべきです。

 

 

システム要件定義書の作成

 

 

上記はシステム要件定義書に盛り込むべき内容の一例です。システム要件定義書を作成する時は専門用語を極力減らして、誰にでもわかる言葉・文章で作ることが大切です。

後々、言葉の意味がわからなかったり、勝手に誤解されていたりすると問題になることがあります。

 

作成したシステム要件定義書がクライアントの要求に応えているのか、課題や問題を網羅しているのか、コストに見合うのか、納期までの実現可能なのかを精査し、ある程度まとまったらクライアント側と協議を行いましょう。

その時点で意志の疎通が取れていない部分はないか、理解が浅いところがないか、満足できる機能が揃っているかチェックし、何度か改善しながら、クライアントとエンジニアの双方が合意できれば開発のスタートとなります。

 

 

 

4.要件定義に必要なスキル

---

次に要件定義に必要なスキルについて説明します。

 

要求を言語化できるコミュニケーションスキル

要求を言語化できるコミュニケーションスキルとは要求ヒアリングにおいて、クライアント側の意志を汲み取り、正確に本質を読み取ることを指します。

同様に曖昧になりがちな表現、または技術的に疎い場合の表現などから、課題や問題を読み取り、自分の技術的リソースで実現可能な解決策を提案できることも重要です。

 

また、専門用語に頼らず、クライアント側の業界や業種に合わせて、理解しやすく、誤解を生まない説明の仕方も大切です。

何を言っているかわからないけれど、エンジニアが言うんだから間違いない、相槌を打っておこうとなってしまうと、後々に問題になります。

 

聞いていたけど、思っていたのと違うというのはエンジニア側のリスクになるので注意しましょう。

 

その他にも機能要件、非機能要件など、技術的には実現可能でも、コストや納期の問題で難しい場合、または技術的に難しい場合にに丁寧に断れるスキルも必要です。

断りきれないことがエンジニア側のリスクになることを忘れてはいけません。

 

 

ドキュメンテーションスキル

ドキュメンテーションスキルとはクライアント側の要求を見たし、課題や問題を解決できる機能や要件をまとめて、開発する際のイメージを文書に落とし込むスキルを指します。

ただ文章に落とし込むのではなく、自分自身、もしくは他のメンバーが理解できることが前提です。

 

同時にエンジニアとして、システムを開発する段階で必要な情報を網羅しながら、要件を満たす条件などを明確にしましょう。

開発の段階では数値化されていないもの、範囲が明確でないものはプログラミングしにくくなります。

 

具体的にどのような機能なのか、どんなデータを入力し、どんなデータが出力されるのか、またはどのようなアルゴリズムで、どのような分岐があるのかなど自分自身、もしくは他のメンバーが見るだけで実装できるように情報を揃えておくことを意識してください。

ドキュメントの形式やフォーマットについても、読みやすく、わかりやすい心掛けましょう。

 

その他のデータやファイルにおいても、どこを参照すれば良いのかなど共有しやすいよう整理しておくことをおすすめします。

 

 

 

5.まとめ

---

今回は業務システム開発に大事な要件定義に関する基礎知識、要件定義で決めなけれなければならない要件、そして要件定期の流れと要件定義に必要なスキルについてお話しました。

要件定義は要点さえ理解しておけばそう難しいものではありません。

 

しかし、フリーランスエンジニアとして案件を受注する段階になった時、自分自身で要件定義を行い、クライアントの要求に応えることができなければ、成果物として認められないことで報酬が受け取れないリスクがあります。

同様に場合によっては賠償問題になるというリスクもありますし、継続的な受注も難しくなるでしょう。

 

要件定義の要点や基礎を押さえながら、自分一人でも要件定義をできるようにすること、自分の能力・スキル・経験に合わせて案件を受注することを前提とし、キャパシティを越える案件を無理に引き受けて、不要なリスクとならないよう注意してください。

もちろん、時にはチャレンジすることも大切です。スキルアップやキャリアアップしたい場合は積極的に足りない部分を補いながら、学びながら受注することでフリーランスエンジニアとしての成長につなげることをおすすめします。

 

最後までお読みいただきありがとうございました。

 

フリーランスエンジニア専門の求人・案件一括検索サイト「フリーランススタート」に少しでも興味がある方は是非ご登録ください。

 

なお、フリーランススタートはiOSアプリ版やAndroid版をリリースしています。

通勤しているエンジニア・デザイナーでちょっとしたスキマ時間で手軽にフリーランス求人・案件を検索したい、開発言語の単価が知りたい、フリーランスを将来的に検討している方などは是非インストールしてみてください。

 

フリーランススタートのアプリを有効活用して、フリーランスとして第一線で活躍しましょう！

 

フリーランススタート iOSアプリのインストールはこちらから→

 

フリーランススタート Androidアプリのインストールはこちらから→

 

 

本記事が皆様にとって少しでもお役に立てますと幸いです。