要件定義を使うシステム開発における、最重要ポイントUXと有名なシステム開発法のアジャイル開発と要件定義の関係について記載しました。もし要件定義を精錬する#1 を未読の方がいましたら、そちらを先にご覧ください。

UXの観点

システムを開発する際に考慮すべきポイントにUXという考えがあります。UXはユーザーエクスペリエンスの略であり、UIの概念よりも広い意味を持ちます。つまりユーザーの体験や満足といった全体を意識することを意味します。では、体験をデザインするとはどういうことでしょうか。また、要件定義においては、どのようなことを意識する必要があるのでしょうか。具体的には、「情報システムを含むサービス(該当の製品)が、どのようにふるまい、動作し、人と触れ合うか」を、システム開発の立場から明確にすることになります。昨今、UXの観点から商品やサービスの価値を評価する動きがあります。サービスの価値はイコール、ビジネスの価値を意味します。ビジネスを支援する情報システムも例外ではありません。特に不特定多数のお客様の日にふれ、操作してもらう必要のあるコンシューマー向けシステムにおいては顕著です。コンシューマー向けシステムの場合、UXの価値イコールンステムの価値と見なされる機会が増えました。「楽しさ」「心地よさ」がシステム価値を左右するのです。エンタープライズ系システムにおいては、エンドューザーの想定がたやすいため、コンシューマー向けシステムほど意識する必要はありませんが、社内の業務担当者の置かれた状況を考慮してユーザーシナリオを分析することは、ますます重要になってきています。また前述した通り、昨今のコンシューマー向けシステムとエンタープライズ系システムの融合により、UXを無視する訳にはいかなくなりました。エンタープライズ系システム第でも、UXの観点はますます大事になってきています。つまり、システム形態にかかわらず、開発プロジェクトの早期、上流工程においてUXを意識する必要が高まっているのです。要求から要件を明確化する要件定義において、開発対象のシステムをUXの観点から見直すことにより、方向性が明確になります。極論かもしれませんが、UXからユーザーシナリオ(プロセス)を抽出し、データとの整合性がとれる仕組みこそ、ユーザーにとって納得性が高い(つまり合意しやすい)システムなのです。それを実現するような、開発者とユーザーが並走できる開発体制と開発工程が求められます。

UXの観点から要件定義でやっておくべきこと

UXとは「モノ」ではなく「コト」のデザインであるという人もいます。UXはUI、ユーザービリティを含む広い概念でもあります。UXを想定して「快適な」UIを作り上げていく道筋を明確にするのです。 あくまでUXからユーザーシナリオを導き出してUI を想定していきます。 決して逆ではありません。また、UXはシステムを利用しているそのときだけの価値を対象としているわけではありません。システムの使用前後も体験に含まれます。いやむしろ、システムはほんの一部である、と考えた方がよいかもしれません。

システム使用前後、つまり ECサイトで購入する場合であれば、購入前購入後のUXを考慮した上で、該当システムのUIに落とし込む必要があることを意味します。そのためには、後述する「ペルソナ」を、きちんと作成して検討する必要があります。エンタープライズ系システムにおいても、業務従事者がシステム使用前.後にどのような行為を行うかを考慮します。UXを基に、後述するプロセスモデルとしての業務フローを考える場合、例えば、「注文」であれば、注文前,注文後まで考え、必要な業務プロセスをあぶり出すことがセオリーです。要件定義では、いきなりUIの検討に入るのではなく、先にUXを考え抜く必要があります。業務フローを考えるときも、システム使用前後のフローを包括すべきです。このことは、UXを実現するためのプロセスモデル(楽務フロー)から、プロセス定義(5W2H)へ落とし込み、5W2Hを満たす機能とUIを得ることと同義です。

ペルソナ

ペルソナとはサービスを利用する典型的ユーザーの人物像を具体的に描き表したものです。ペルソナはできるだけ事実に基づいた情報を基に作り、想定ユーザーの顔が想像できるレベルまで持っていきます。要件定義は、開発対象のシステムの方向性と範囲を明確化することにほかなりません。 UXを意識することで、より方向性と範囲が明確になってきます。
要件定義におけるUXの重要性UXからユーザーシナリオの大枠を導き出し、業務プロセスの固まりである業務フローを作成します。業務フローから個々の業務プロセスを抽出し、業務プロセスにとって必要なUI 機能を洗い出すことが可能になるのです。つまりUXを明確にすることにより、必要な UI機能が明確になるのです。
アジャイル型開発における要件定義
昨今、ユーザー要求を迅速にシステムへ反映するためにアジャイル型開発を選択するプロジェクトが増えています。これは迅速性に欠ける(と思われている)ウォーターフォール型開発へのアンチテーゼかもしれません。「ウォーターフォールだろうがアジャイルだろうが、要件定義で行うべき作業は基本的に変わらない」。「要件定義で行うべき作業の内容は、開発手法ではなく、プロジェクトの考え方や状況による」です。「アジャイルでは設計しない」という声を聞きますが、間違いです。ドキュメントの作成を目的としないだけであって、アジャイルでも設計は行います。要件定義についても同様です。だた「要件」といっても、個々の詳細な仕様まで要件として明確化することは、アジャイルの精神に反しますし、そもそもアジャイルを適用した意味もなくなってしまいます。それでも、方向性·目的·概要は早期に明確にする必要があります。これはどんな開発手法を用いようが不変です。アジャイル型開発では、要件定義·設計·実装テストを同じメンバーが担当することが多いので、次工程の担当者に引き継ぐドキュメントが不要なだけです。アジャイル型開発を採用する場合も、特にエンタープライズ系システムとの融合を前提とした場合は、方向性·目的·概要までを要件定義フェーズで捉えた上で、要件の詳細化·設計,製造フェーズをアジャイル型で実捨するのがよいでしょう。つまり機能分割可能なレベルに落とし込む作業は、前もって行う必要があるわけです。最初から何がなんでもアジャイルでやろうとすると、プロジェクトが収束しなくなる恐れがどうしても高まります。エンタープライズ系システムへの影響や、他システムとの連携を全く考慮しないで済む場合を除き、要件定義で行うべきことをきちんと押さえておくことがプロジェクトの成功につながります。

アジャイルだろうと「要件定義は必要」

アジャイル型開発でも、要件定義の重要性は変わりません、必要というスタンスです。アジャイルは新しい価値を生み出すものと言われます。「要件は固まらないもの」、「真の要求はアジャイルで設計とともに」とはいえ、最低限の要件(方向性·制約)の明確化は必要です。業務の現場、特にWebが絡むような日進月歩のエリアでは、要件の変化を受け入れないわけにはいきません。アジャイル型開発を採用した場合、動いているシステムを見ながらなら、具体的なイメージを持って要件を提示できる可能性が大きいので、ある程度の仕様が固まった時点であれば、開発を開始することは可能です。そのためには、繰り返しの前に、要件定義で大枠をしっかりと掴み、設計から実装工程でブレを生じさせないことが大切です。また、これは要件定義工程以降の話になりますが、新規開発においてアジャイル型開発を適用した場合は、修正(仕様変更)もアジャイルで行うことになります。つまりシステムライフサイクル全般でアジャイルである必要かあるのです。そのためには、開発手法の話に終わらず、長期にわたる組織論に踏み込む必要が生じます。

 

【広告】Librus Tech Communityのお知らせ

Librus株式会社が運営する、システムエンジニアやプロジェクトマネージャーの方向けに展開するコミュニティにぜひご参加ください。「互いに助け合い、学び合う空間」をコンセプトに、システム開発に関するセミナーや勉強会をはじめ、案件や転職先のご紹介、相談対応も行います。エンジニア初心者の方や起業、現在フリーランスをされている方、フリーランスを目指している方も大歓迎です。

▼Slackコミュニティ入会フォーム
https://forms.gle/1D5duKwVJhm1vFb18