Ruby on Rails によるシステム開発をモデリングで効率的に行う

• 概要編
• 分析・設計編（ユースケース図とユースケース記述）
• 分析・設計編（フィーチャモデリング）
• 分析・設計編（フィーチャと解決領域のマッチング）
• 分析・設計編（ER 図）
• 分析・設計編（ER 図の実践）
• 実装編（モデルを実装に落とし込む）
• まとめ

どうも、あかさたです。前回は、Ruby on Rails を使った開発を効率化するためにモデリングを混ぜた開発プロセスが有効という話をしました。今回からは、実際にソフトウェアを開発します。本記事では、「何を作るのか」に注目しながらユースケースを作成します。

何を作るのか？

Rails ではおなじみのテーマである、ブログを開発します。しかし、全くの架空の事例だと面白くないので、実際の事例をデフォルメした架空の案件を立ち上げることにします。事例は八角研究所のこのブログにしましょう。このブログは、WordPress で作成されていますが、このブログを独自に開発するという案件を想定してみます。

八角研究所は受託開発・開発支援業務を主体にしている IT 関連企業です。社員は 2007 年 10 月時点で 5 名。これまで、八角研究所では求人媒体を使わずに、それぞれの社員の人脈でメンバーを募ってきました。これから会社を成長軌道に乗せるために、会社制度の見直し、求人媒体の活用など新しい試みを始めました。その一環として、ブランディング強化のために、技術情報を発信するブログを立ち上げることになりました。

ブログの特色を出すために、社内だけではなく社外からもライターを起用して、幅広い情報を安定して提供します。ただし、社外から無秩序に記事を募集するわけではなく、数名のライターに八角研究所が依頼します。ライターおよびブログ管理担当者の負担を減らすために、記事はウェブ上で作成できるようにします。記事の公開ペースが偏らないように、ライターが書いた記事はいったんブログシステム上に貯めて、ブログ管理担当者がタイミングを見計らって公開します。八角研究所という名前を広めることが目的なので、ユーザーは、ログインなどを行わなくても、自由に記事を閲覧できるようにします。

実際には「検索」「RSS」「コメント」「トラックバック」などの要求もあったので、実際の事例から見るとかなり要求を端折りましたが、この事例をケーススタディとして、開発を進めていくことにしましょう。前回紹介した開発の流れに従って、まずはユースケース図とユースケース記述を作成します。

ユースケース図とユースケース記述とは？

ユースケース図とは、システムの利用者とシステムが提供するサービスの関係を記述したものです。システムの利用者を「アクター」、サービスを「ユースケース」と呼びます。例としては、アクター「ブログ購読者」とユースケース「ブログ記事を購読する」などが挙げられます。（厳密に言うと、ユースケース図はシステムの内部と外部を記述するための図です。たとえば、システムが Google Maps API を利用している場合、Google Maps API もアクターとして認識されます。）

ユースケース記述とは、アクターとユースケースのやり取りを記述したドキュメントを指します。UML のアクティビティ図やフローチャートを使っても構いませんが、フリーフォーマットの文章やイベントフローでも構いません。本記事では、フリーフォーマットの文章と、イベントフローという形式で記述します。並行して画面のプロトタイプを作成する場合が多いです。

ユースケース図とユースケース記述を作成することによって、何を作ればいいのか把握することができます。ユースケースの漏れ抜けがあるとあとあと大変です。早めに Fix しましょう。目安としては、画面プロトタイプを作り終わるまでにユースケース記述は完成していなくても、ユースケースは抜き出し終わっている必要があります。

アクターとユースケースの列挙

ケーススタディの記述からアクターとユースケースを列挙します。この時点で、システムを開発する上であいまいな点が判明します。その場合は、要求の出し手（お客さま）に確認しながら、情報を補っていくようにしましょう。このコミュニケーションが一番大切で、この工程の成果物はそれに準ずると考えてください。

システムにとって、「誰が使うのか」は重要な話題です。上記のケーススタディでは、「ライター」「ブログ管理担当者」「ユーザー（ブログ購読者）」がシステムの利用者として登場しました。記事のレビューが必要なら、レビュー担当者が出てくるかもしれません（レビュー担当者が承認しないと公開できないとか）し、アクターの認識は要求の漏れ抜けを発見する上で重要です。

上記のケーススタディから、ユースケースとしては、「ブログ記事を投稿する」「ブログ記事を公開する」「ブログ記事を閲覧する」が読み取れます。「ログインする」や「ライターを登録する」なども読み取れます。「当然こういう機能はあるものだろう」という思い込みは危険なのでユースケースは網羅するようにしましょう。ここでは、「ブログ記事を投稿する」「ブログ記事を公開する」「ブログ記事を閲覧する」のユースケースを作成します。