ARC 調査報告
  • レポート
  • 議事録
  • ダイジェスト
  • レポート

    概要

    ソフトウェア開発を効率化する手法として、
    「アジャイル・ソフトウェア開発(以下、アジャイル開発)」が提唱されています。

    弊社では、アジャイル開発の手法と効果の調査・研究を目的として、
    1ヶ月間の仮想プロジェクトを立ち上げました。

    この文書は、アジャイル開発手法の調査・研究の結果についてまとめています。

    プロジェクト概要

    仮想プロジェクトとして「飲食店向け注文システム」を開発テーマとしました。

    また、アジャイル開発が採用されやすい分野を表す 「ARC」というキーワードがあります。
    「ARC」とは、3つの技術の頭文字を取ったものです。

    • A (Agile アジャイル)
    • R (Ruby / Rails)
    • C (Cloud クラウド)

    このプロジェクトでは、採用技術に「ARC」を選択しました。

    チーム規模と役割

    プロジェクトの規模をお客様役(1人)と、開発者役(2人)の3人と想定して実施しました。
    それぞれの役割は以下のような形です。

    • お客様 (プロダクトオーナー)
    • メイン開発者 (スクラムマスター / プログラマ)
    • デザイナー

    調査・研究対象としたアジャイル開発手法

    本プロジェクトで調査・研究対象とした手法を列挙します。

    • インセプションデッキ
    • スプリント
      • スプリント計画 ( スプリント開始時での見積 )
      • スプリントレビュー ( スプリント終了後のアプリ動作レビュー )
    • スタンドアップミーティング
    • ユーザーストーリー
      • Pivotal Tracker (ユーザーストーリー 管理・編集ツール)
      • ストーリーマッピング

    プロジェクトの進行

    仮想プロジェクト開発の進行について、以下にまとめました。

    議事録 に詳細な議事録を記載しております。

    11月05日 要件連絡

    お客様から本プロジェクトについて、要件が連絡されてきました。

    メイン開発者が別プロジェクトで作業中のため、最初の打ち合わせは 11月10日に行われることとなりました。

    11月10日 打ち合わせ(1)

    最初の打ち合わせとなります。この打ち合わせでは、「インセプションデッキ」を作成することになります。

    11月11日 打ち合わせ(2)

    2回目の打ち合わせとなります。

    この打ち合わせでは、「メイン開発者」が初回の打ち合わせから導出した「ユーザーストーリー」をもとに、機能の優先度や不要な機能の取捨選択を行います。

    11月14日 第1回スプリントレビュー

    打ち合わせから導出した最低限の機能を実装したバージョンを、お客様にご確認いただきました。

    下記3つの機能を実装しました。

    • 「管理者」がメニューを入力できる
    • 「客」が注文を入力できる
    • 「バックヤード」が入力された注文を確認できる

    11月20日 打ち合わせ(4)

    システムに必要な機能や画面の構成について、チームの合意を形成するため、詳細を打ち合わせました。
    「ブック」「カテゴリ」「レコメンド」の機能を実装することとなり、それぞれの機能の役割、画面構成について合意を形成しました。

    また、ここまでで作成してきた「ユーザーストーリー」が乱雑な状態となり、見通しが利かなくなってきたため、
    「ユーザーマッピング」の手法を採用して「ユーザーストーリー」を整理することとしました。

    11月21日 打ち合わせ(5)

    「ユーザーマッピング」手法で整理した資料で、「ユーザーストーリー」の優先度を決定しました。

    11月26日 第2回スプリントレビュー

    下記機能を実装したバージョンを、お客様にご確認いただきました。

    • Android 上でのデザインへ変更
    • ブック機能
    • レコメンド機能

    12月02日 第3回スプリントレビュー

    下記機能を実装したバージョンを、お客様にご確認いただきました。

    • レコメンド詳細化
    • 詳細を1画面表示
    • 1商品に複数画像登録
    • ブック別の値段設定

      また、この日のレビューでは、メニュー画面のデザインを本格的に行うにあたり、よりイメージしやくする目的で、
      モデルとなってもらう店舗を探し、協力してもらうこととなりました。

    12月09日 第4回スプリントレビュー

    下記を実装したバージョンを、お客様にご確認いただきました。

    • モデル店舗を決定、取材、メニュー作成
    • デザインの作成・実装

    アジャイル開発手法・評価一覧

    採用したアジャイル開発手法についての評価を表にまとめました。

    手法 評価 概要
    インセプションデッキ ★★★ インセプションデッキとは、プロジェクトの全体像を端的に伝えるためのドキュメントです。こちらのサイトで、詳しく解説が行われていますので、ご参照ください。ネスケラボ
    スプリント ★★☆ アジャイル開発の基本的な手法で、1週間~1ヶ月ほどの時間で区切り、その期間を1スプリントと呼びます
    スプリント計画 ★★☆ 1スプリントの間に開発する内容について優先度をつけて選択し、コミットメントします。
    スプリントレビュー ★★★ 1スプリントの間に開発した機能を、お客様に披露し、機能や画面についての意見を伺います。
    スタンドアップミーティング ★★★ 毎日15分程度を目安に、「1.前日の作業」「2.今日の作業」「3.気になること」を報告します
    ユーザーストーリー ★☆☆ お客様が機能の価値を判断できる単位で、機能を分割して列挙します。この分割単位で見積を行い全体の作業量見積と、作業進捗の管理を行います
    Pivotal Tracker ★☆☆ ユーザーストーリー 管理・編集ツールです。
    ストーリーマッピング ★★☆ ユーザーストーリーを、グルーピングするための手法です

    インセプションデッキ・考察

    概要

    インセプションデッキとは、プロジェクトの全体像を端的に伝えるためのドキュメントです。こちらのサイトで、詳しく解説が行われていますので、ご参照ください。ネスケラボ

    評価 ★★★

    プロジェクトの立ち上げ期に、全体像・背景・目的をチームで共有するために非常に有効な手法です。

    11/10 の議事録に詳細を記載しています。

    スプリント・考察

    概要

    アジャイル開発の基本的な手法で、1週間~1ヶ月ほどの時間で区切り、その期間を1スプリントと呼びます

    評価 ★★☆

    開発期間が決まることにより、開発のリズムが作られます。また、スプリントレビューを実施するための区切りとしても利用されるため有効な手法です。

    スプリント計画・考察

    概要

    1スプリントの間に開発する内容について優先度をつけて選択し、コミットメントします。

    評価 ★★☆

    ユーザーストーリーと組み合わせて計画を立てていましたが、開発期間の終盤には、この文書を保守する時間が取れなくなってしまいました。

    スプリント計画に代わり、スプリントレビューの議事録を作業のベースとする形に移行せざるを得ませんでした。

    スプリントレビュー・考察

    概要

    1スプリントの間に開発した機能を、お客様に披露し、機能や画面についての意見を伺います。

    評価 ★★★

    お客様のフィードバックを得るために、必ず必要な手法です。

    ただし、全てのスプリント終了時には必ずやると決めてしまうと、
    リファクタリングや、環境整備等、機能にかかわらない作業や、ある程度の期間が必要な機能の実装の際に問題になることが考えられます。
    スプリントの開始時に、柔軟に決める形としておくことができると、よりよいと考えます。

    スタンドアップミーティング・考察

    概要

    毎日15分程度を目安に、「1.前日の作業」「2.今日の作業」「3.気になること」を報告します

    評価 ★★★

    チームで集まるのは15分で区切り、「気になること」について話し合いが必要なら、別途、そのまま打ち合わせる形としました。
    こうすることで、「気になること」が翌日には解決できるという状態は、開発に好影響となると考えます。

    ユーザーストーリー・考察

    概要

    お客様が機能の価値を判断できる単位で、機能を分割して列挙します。この分割単位で見積を行い全体の作業量見積と、作業進捗の管理を行います

    評価 ★☆☆

    提唱されているポストイットを使用した方法は、ある程度のスペースが必要であり、
    持ち運びも出来ないため、今回はPC上で取り扱えるツールを使用しての評価となります。

    プロジェクトの初期に、「ストーリーマッピング」とあわせて必要な機能を列挙するには、よい手法だと考えます。

    ですが、ユーザーストーリーで、「見積」から「作業進捗の管理」まで行うのは、適切な手法とはいえません。

    管理ツールが発達してくると、状況は変わるかも知れませんが、最後までこの手法を実践するには相応の経験が必要になると思います。

    問題と感じた点は、下記になります。

    • 優先度順のみで一覧表示されると、作業全体像を見渡せない(作業の抜けがわからない)。
    • ストーリーマッピングなどの手法を使って管理しないと、乱雑となりすぎて作業の全体像が見渡せなくなってしまう。
    • 分割するサイズや、機能に属さないタスクなどの扱いをどうするべきか 等

    全体の見積を求められる場合は、最初に「ユーザーストーリー」を列挙した時点で、
    既存の「詳細見積」を算出する手法を採用するべきです。

    Pivotal Tracker・考察

    概要

    ユーザーストーリー 管理・編集ツールです。

    評価 ★☆☆

    アジャイル開発を実践している会社で評価が高かったため、取り入れてみました。

    ユーザーストーリーが、優先度順のみで一覧表示されてしまうので、プロジェクト全体が見渡せなくなり、使用を停止しました。

    もう少し、ユーザーストーリーが少ない状態で管理しきれる経験をつめば、採用できるのかもしれません。

    ストーリーマッピング・考察

    概要

    ユーザーストーリーを、グルーピングするための手法です

    評価 ★★☆

    プロジェクトの途中で、全体をグルーピングするために1度取り入れました。

    「ユーザーストーリー」を整理するために有効な手段だと考えられます。
    プロジェクトの初期に取り入れるべき手法だと考えます。