要求分析と要件定義で必要な図や内容などを考えた

movee代表の小野寺です。 弊社はソフトウェア開発の要件定義や設計などを中心に支援している会社です。上流工程でよく混同されるのが要求分析と要件定義。似ている言葉だったりするのとプロジェクト次第で何を求められるかが異なるので正解というのはないかもしれませんが、弊社では以下のように考えています。

要求分析は非エンジニアが〇〇したいという要求を分析・定義したもの

要求分析は非エンジニアが〇〇したい、という要求を分析、定義したものだと考えています。具体的な納品物はユースケース図、アクティビティ図だと考えています。シーケンス図やクラス図、配置図などは具体的になりすぎますので要求分析では除きます。

要件定義はエンジニアがIT技術面からソフトウェアを動かす仕組みを定義したもの

要件定義はもう少し技術的な工程になります。エンジニアがIT技術面から新しく作るソフトウェアを定義するので少し専門的な内容になります。シーケンス図や配置図などが対象になると考えています。また機能だけでなく、非機能要件と言われるセキュリティやユーザビリティなどの部分についても技術的な視点から定義する必要があります。担保する範囲次第でソフトウェア開発の工数は大幅に変わるため、双方が気持ちよく開発を進めていくためには納得感を持って合意する必要があり、その合意は要件定義で行います。

「一流ファシリテーターの 空気を変えるすごいひと言」を購入したのでネタバレしないレベルの感想

movee代表の小野寺です。

弊社はソフトウェア開発の要件定義や設計などを中心に支援している会社です。

ただ、よく思うのは要件定義や設計ができたとしても「そもそも要件が洗い出せているのだろうか？」という疑問です。ユーザーの現状の不便なところや改善箇所をちゃんと吸いあげられていないと要件定義した時点でもう誤った方向に進んでいるんじゃないかと思います。

そのため、これからは要件洗い出しの打ち合わせや意見だしのミーティングにも積極的に参加させてもらうべきだなぁと考えています。

ユースケース図やシーケンス図を書く力は正しい要件を吸いあげられてこそ生きるはずなので。

とはいえ、ただ横に座ってメモを取るだけだと「なんだこいつは？」となりかねないのでせっかくならお客様の意見を出しやすい雰囲気を醸成するファシリテーション力を身につけてファシリテーターとして参加すればお客様も喜ばれるのではないか、と思いました。ファシリテートして意見をお出しできる役割になれば良いんじゃないかと。

ということで早速amazonで関連しそうな書籍を購入。

一流ファシリテーターの 空気を変えるすごいひと言――打ち合わせ、会議、面談、勉強会、雑談でも使える４３のフレーズ Kindle版

NTTでファシリテーターとしてあらゆる会議に出ていた人らしく、「ファシリテーターとは」、とか「ファシリテーション力とは」みたいな硬いお話よりもどちらかといえば

どのような言動や態度をすれば参加者の意見を引き出せるかというファシリテーターとしての振る舞い方に重点を置いた内容になっていました。1人で話しすぎる人の対処法やネガティブな発言をする場合の切り替え仕方など、とても参考になる内容だったので買って損はない書籍だと思います。

ぜひファシリテーターとして意見だしや会議に参加してほしい企業様がいればご連絡ください。

行動データ収集のデータベース選定を考えてみた

行動データとはユーザーの動きを数値化したデータを言います。 何時何分にログインしたか、ログイン後にどのような画面を閲覧したか、何秒ぐらいページに滞在したか、どのリンクを押したか、商品を購入したか、、、etcなどリストアップすればキリがないほどたくさんあります。 思いつく限りでざっと行動データをリストアップしてみました。 ECサイトやLPサイトをイメージして作成したので、一例としてとらえていただければと思います。

ユーザー行動データ

行動データは収集するだけではなくしっかりと分析することでソフトウェア改善や機能追加、施策立案に繋げられると思います。 ソフトウェア設計はどのレベルまで行動データを収集したいか、によって変わるのではないか、と考えています。 例えばページスクロールをしてトリガー地点を通過する度にデータ収集する、ようなリアルタイムに近い情報収集を実現したい場合は、素早いデータ書き込みが求められるため、DBはRDBよりもredisのようなインメモリーDBにして、随時書き込むような設計にした方が良いかなと考えています。redisはアクセス、書き込みが早いのでAIとかデータ分析の現場で使われているイメージです。 図でRDBの場合とredisの場合を比較してみます。 パターン１はよくある構成です。リアルタイム性の高いDB書き込みがなければRDBで良いのかなと思います。 一方でリアルタイム性も考慮して行動データを収集する場合はパターン２が良いのかなと考えています。ちなみに弊社でも自社サービスにはパターン2の方式を採用していてredisを使っています。

行動データをリアルタイムで収集する場合の配置図

ユーザー行動データ収集を最適化するにはDB選定や設計が大事になってきますのでとても奥が深いなぁと感じます。

ECサイトのログイン状況を可視化し、マーケティング活用する設計を考えた

ログイン状況をデータ保持すれば高頻度にログインするユーザーと低頻度にログインするユーザーが可視化できます。 一般的には高頻度ログインユーザー＝サービスを気に入ってくれているユーザーですので、より気に入ってもらうために高頻度ユーザーにだけクーポンを出す設計を考えました。ログイン情報はいわゆる行動データです。ユーザーの行動を可視化してマーケティングに活かしていきます。 ユースケース図はこんなイメージでしょうか。高頻度ログインユーザーはクーポンが閲覧できる、低頻度ログインユーザーはクーポンが閲覧不可です。

ユースケース図

次にアクティビティ図です。高頻度ログインユーザーの定義ですが、2日連続で前日ログイン日時から24時間以内にログインしているユーザーとします。また、クーポンが半永久的に使用可能なのも特別感がないので、クーポン有効期限はクーポン表示してから24時間以内とし、使える回数は1回とします。表示されたクーポンPOPUP画面に今から24時間以内とすれば、購買行動が駆り立てられるからです。

アクティビティ図

次にシーケンス図です。ログイン成功時に前々日、前日、今回のログイン日時を比較して24時間以内であればクーポンを発行します。クーポンは不正な利用を防ぐため、かつ特別感を出すためにユーザー単位で発行します。クーポン発行があったユーザーのみPOPUP画面が表示されますが、低頻度ログインユーザーはそのままトップページに遷移します。

シーケンス図

データベース設計はまだどちらが最適か、が分かりませんが２パターン出してみました。テーブルを１つ作成するパターンと２つ作成するパターンです。ユーザー毎にクーポンを発行するのであれば結局書き込みするのでレスポンス速度はあまり変わらないと感じているため、パターン1が優勢かなと思いつつ、アンチパターンになっていないかを精査する必要がありそうです。

ER図

以上、ECサイトのログイン状況を可視化し、マーケティング活用する設計を考えた、でした。要件の洗い出し（何を実現したいか？）から要件定義、設計までお悩みの企業様はお気軽にご連絡ください。行動データを加味した要件定義や設計などもできます。

アイデアからアクターとユースケース候補を見つける方法

ソフトウェア開発をする際にまずは要求を定義しますが、要求定義で必ず必要なUMLにユースケース図があります。しかしいきなりユースケース図を書こうと思ってもアクターが誰で、ユースケースが何か、をビシッと整理して書きあげるのは難しいです。そのため、まずはアイデアの整理から始めます。アクターとかユースケースを意識せずにシステムでやりたいことを書けるだけ書き出します。ちなみに自分が参考にしている書籍の１つ「UML入門」ではCRUD処理を１つずつ書くとユースケースが増えてしまって図が見えづらくなるため、CRUD処理は〇〇を管理するというユースケースで表します。やりたいことを完璧に書く必要はなく、必要となれば後から追記・修正します。後工程で変更になるケースはよくあるので現時点で思いつく範囲で洗い出せば良いと思います。 やりたいことを一通り書き出したら、その内容を整理します。誰が（アクターの候補）と何を（ユースケースの候補）の２つの箱を作り、書き出したアイデアを元に記載していきます。

アクターとユースケース候補を見つける

こちらもやりたいことが変更したら後工程で追記・修正します。 ちなみにシステム内で構築しないサービスを切り出したシステムもアクターになります。例えばメール送信は外部のメールシステムで行う場合はメールシステムもアクターになります。 やりたいことを整理できればユースケース図作成の準備は完了です。

弊社が考えるデータドリブン実現のソフトウェア設計とは

データドリブン（Data Driven）とは、売上データやマーケティングデータ、WEB解析データなど、データに基づいて判断・アクションすることです。（参考：

データドリブンとは？データドリブンを成功に導く全知識と6つのITツール | NTTコミュニケーションズ 法人のお客さま

） ソフトウェアをリリースする上でどの企業も「この機能はユーザーが嬉しいかな」とか、「ユーザーの滞在率を増やすにはどうすればいいかな」といった議論はなされているように思います。 ただ、このユーザー目線の判断ってとても難しいと感じております。 なぜなら新規開発時は実際のユーザーが喜ぶことは分からない（想像はできるけど）し、ユーザー毎に違うからです。そのため、初期リリースのユーザー目線設計は、言い方を変えると「自分がユーザーだったら..という視点で設計すること」、になると思います。 自分がこのソフトウェアを使う場合は◯◯機能が欲しいなぁとか。リリース前は誰も使っていないので自分がユーザー目線になって設計することになるでしょう。 しかしリリース後、ユーザーが使うようになった時には実際のユーザーは自分の感覚と違うはずです。もっと言えばAユーザー、Bユーザーでも違ってきます。 とても難しい問題です。AユーザーもBユーザーも喜んでくれるにはどうすればいいのか？

それはユーザーの声を聞くことだと考えています。ユーザーの声を聞く方法は２つあると思います。１つはアンケートを定期的に実施し、意見を吸い上げて機能に反映すること。もう１つはデータを把握し、声なき声を吸い上げて機能に反映することです。つまり、適切なデータを収集・分析することです。具体的な例を１つ挙げるとログ時間。一般的には今回ログイン時間を保存するだけだと思いますが、前々回ログイン時間と前回ログイン時間と今回ログイン時間をDB保存しておくとします。 あるユーザーの前々回ログイン時間と前回ログイン時間と今回ログイン時間の差が１日以内だとしたらそのユーザーはよく使ってくれているユーザーでしょう。反対に１週間以上の差があるとすればあまりソフトウェアを使ってくれていないユーザーでしょう。ログイン時間でユーザー毎のサービス定着度がある程度分かります。

ユーザー中心設計とは

同じユーザーとは言え、それぞれ行動が違うので取るべき施策も異なってくるでしょう。ユーザー行動を考慮したソフトウェア設計、DB設計をすればデータ収集・分析ができ、ユーザーに喜んでもらえる施策を打つことができます。弊社は、ユーザーの声（ヒヤリング、ユーザー行動）を適切に保存し、分析できる基盤を考慮したソフトウェア設計を実現し、ユーザーが望み、企業も喜ぶソフトウェアに昇華させていくことに貢献していきたいです。 勘や経験を根拠にした意見とデータを元にした意見を織り交ぜればより良い意思決定ができるのではないかと思っています。

ブログを書くにあたって

movee代表の小野寺です。 本日からデータドリブンを実現するソフトウェア設計に関するブログを書くことにしました。 元々hatenaブログは利用していて代表の私はこちらのブログを細々と書いていたのですが個人的な内容があったり、雑多な内容があったりしたのでもう少し内容を限定した、ちょっとビジネスライクなブログを作りたいなと思っていました。 そこで弊社が目指している設計だったり、データだったり、機能アイデアをこのブログで書いていこうと思います。 よければ読者になってくださいませー。