連載「エンジニアを導く、新しい学びのロードマップ」
この連載では、エンジニアの学び支援する方々（企業の教育部門や高等教育機関）へ向けて、未来をつくるエンジニアの学びについて情報を提供します。テクノロジーを使いこなせる人材を育成するために必要なモノ・コトは何かを考え、新しい潮流を踏まえて整理を試みます。
＊過去の記事一覧はこちら
今回は、ITシステム開発における問題の要因になりやすい“要求”に焦点を当て、要求の漏れが発生してしまうケースや、要求の抜け漏れを防ぐために必要なことなど、「要求定義」という重要な仕事を取り上げます。
要求の抜け漏れが発生するワケ
エンジニアとの会話で多く耳にするのは、お客様とのゴタゴタに関する話です。進捗会議や問題対応で起きる衝突のようなゴタゴタの話はあとを絶ちません。お客様あっての仕事なので、衝突という表現が適切な状況にはならないように努めているので、ゴタゴタという表現が適していると思います。進捗会議や問題対応時に露呈してくる問題の多くは、要求の認識違い、もしくは曖昧さ、そもそも要求が定義されていないといったことが原因です。ITシステム開発における問題が混入するのは上流工程が多いのは、よく知られている事実です。また特に要求に起因する問題は、問題の発生数だけでなく手戻りなど問題の影響度が大きくなります。
ではなぜ、要求の抜け漏れが発生してしまうのでしょうか。例えば、システム性能に関する問題の場合、要求の抜け漏れが発生する要因に、性能要件を設定していなかったり、表現や定義が曖昧であったりします。特に新規開発や未経験のシステムの場合、先行する事例がなく、このような項目の漏れや表現不備が発生しやすくなります。
曖昧な表現であれば、システム設計段階で具体的にすることができます。無茶な性能要件も、実現困難である可能性を考え、議論の対象になります。一方で、未設定の場合には、お客様もシステム設計側も留意すること自体が抜けてしまう可能性が高くなります。システム構成やプログラム実装に関する問題は、システム開発側で解決可能ですが、要求に関する課題はシステム開発側だけでは解決が難しいことが多いのです。
要求定義に欠かせない「機能要件」「非機能要件」
このような要求の抜け漏れを防ぐために、網羅的に要件を定義する必要があります。
ソフトウェアの要求に関しては、ソフトウェア工学にて先人の知恵がありますので、参考にしてください。
網羅的に要件を定義する際に参考になるのが「非機能要件」です。非機能要件でわかりやすく具体的な情報が、IPA情報処理推進機構から情報提供されています。※１
非機能要件を全て網羅し、具体的に定義することを考えますが、実際にはシステム的に関係ない項目については、関係ないと判断した理由も記載しておくと後々のゴタゴタ解消に役立つと考えます。まずは全てをチェックし、検討が必要な項目をシステム開発者も含めて検討します。
非機能要件ではなく、本来の「機能要件」はどうでしょうか。IT化する業務やシステムについて具備すべき機能を、外部のシステムやアクターとの関係や手順、保持したりやり取りしたりする情報を定義しないとなりません。世の中には多様な業務やシステムが存在し、そのITシステムの実現方法は多岐に渡り、標準的な機能要件のリストを作成することは現実的ではありません。ITシステムが対象とする業務に関しては、発注者であるお客様が精通しているのは前提条件と言えます。これをドメイン知識と言ったりします。SIerやSES（System Engineering Service）で開発を担う場合、システム開発側が業務に精通していることが理想的ですが、業務の用語、前提条件、当たり前など、ベースが異なることも多々あります。最近では、B2BやB2Cで、ITサービスを提供する会社も増えてきており、そのITサービスは「システム＝業務＝ビジネス」となります。システムの出来がビジネスに直結するので、自社で要件を細かく定義しなくても、PoCやプロトタイプなどで形にして確認ができます。また、細かいイテレーションで問題を解決することで、システムの品質や性能を高めることも可能になります。
お客様と開発担当者の共同作業で生み出す要求仕様書
最近、SIerなど受託開発やSESでの開発の担当者が、自社でITサービスを提供する会社に転職することを見聞きします。自社でITサービスを提供する会社は、ITエンジニアの待遇が良く、多くの求人があるのも事実です。しかし、そもそもお客様の要望に対して要求定義できずに、自社のITサービスを定義し開発出来るか疑問です。この「要求定義」という仕事こそ、ソフトウェア開発における源流であり、これが出来ないことにはプログラミングは出来てもソフトウェア開発は出来ないのではと思ってしまいます。
今一度、要求定義のスキルを見つめ直し、お客様の要求を「抽出」「分析」「定義」することに挑戦してください。最低限のコミュニケーションスキルは必要ですが、この作業の成果はお客様とITシステム開発担当者の共同作業です。このお客様との共同作業で生み出された要求仕様書は、それ以降のソフトウェア開発における基準文書となり、両者のコミュニケーションのベースになります。それ以降に発生する問題は、お客様は悪いとか、ソフトウェア開発者が悪いとかではなく、共に作った「要求仕様書」に問題があるので、それの修正やその他対応をすると考えるのです。そう考える雰囲気ができれば、お客様と開発者が協力して、システムをリリースすることができると考えます。
参考リンク
エンジニア育成担当者向けセミナー開催中
