事例とプラクティスの対応 - アジャイル型開発におけるプラクティス活用事例調査

ラクティスの対応」を使ってその事例で活用しているプラクティスを参照されたい。

4.1. 事例(0): A 社

事例プロフィール

A社事例(1)と同様に広告配信システムの開発であるが、広告の集め方が異なる点と、

高速かつスケーラブルなサーバクラスタ、

無停止で安全な保守を実現すべく、関与人数が多くなっている。

自分達に必要なことを行っているだけで、

「アジャイル型開発を実施している」という認識はなく、プラクティスとして必要なものを掻い摘まんで実施している状況であった。

プロジェクトではなく自社サービスとして開発を行っているため、「自分達のサービス」という意識が強い。

Webサービス開発ではあるが、早期リリースよりも安定したシステムの提供を重視しており、保守性を重んじている。

事例タイプ自社サービス開発会社タイプサービス事業者システムタイプ広告配信システム

プロジェクト工数

20人月（初期リリースまで）

以降も継続中

プロジェクト期間

6ヶ月（初期リリースまで）

以降も継続中（2年経過）

プロジェクト関与者人数

開発チームは8名

（開発以外を含めると20名）

開発言語 Java, PHP, Perl

開発拠点同一拠点

開発手法 Scrum+XP

成功度 4：まだ開発途中だ

が、うまくいきそうな見込みはある表4 A社事例(0) プロパティ

使用プラクティス群

技術プラクティスを中心に、手法にとらわれず、その時に必要なものを採用している。

特徴的なプラクティス

 日次ミーティング

 タスクをチケットとして登録し、それを見ながら実施。夕方開催している。

 組織に合わせたアジャイルスタイル

 マネージャ（予算責任)とディレクター

（要件責任)と開発の三者の役割分担、必要なプラクティスのみ実施

 コマンド化されたデプロイ手順を準備。

Jenkinsなどのツールに依存させない

うまくいかなかったプラクティス

 リリース計画ミーティング

 3ヶ月の大きな目標は共有しているが、

その先は変わっていくので厳密にはしていない。

 ペアプログラミング

 開発者によりエディタ、キーボードの好みが違いペアプログラミングしづらかった。

 受入テスト

 検収環境で確認しOKを貰う程度。受入テストを自動化しようと試みたがツールが不安定でうまくいかなかった。

 集団によるオーナーシップ

 システム規模が大きくエンジニアも多いためなんとなく担当が決まっていため、

集団によるオーナーシップを実現するに至らなかった。

契約形態との関係

自社サービスのため契約は発生せずチーム編成・チームメンバ研修との関係

メンバーはすべて社内で調達した。特に研修は実施しておらず、自主的な学習に任せている。

実施しており、誘致した研修に社員が参加することで新しい技術の習得などを促進している。

また、社内でのフォーマル/インフォーマルな技術勉強会が活発に行われている。参加率はフォーマルな勉強会は6割くらい、インフォーマルな勉強会は2割くらいの人が参加している。

組織の人事考課の評価項目に、技術スキルへの取組が含まれている。仕事で作ったものを評価面談時にデモをしてエンジニアから評価される。

技術力を高める仕組みを組織的に整えている。

使用ツール

構成管理

git

IDE / エディタ

Eclipse、商用IDE、 Emacs

ビルド Make, Maven

CI Jenkins

チケット管理

商用統合開発管理システム

その他 -

表5 A社事例(0)の使用ツール

4.2. 事例(1): A 社

事例プロフィール

広告配信のためのプラットフォーム開発プロジェクトの事例である。開発メンバーは 1名でセールス担当と事業マネージャの3 名で進めている。事業の発案や予算コントロールはマネージャが行い、セールスは広告代理店との折衝やお金の調整を行っている。サービスのビジョンを３人で話し合いながら進めていった。開発者も広告代理店に同行し、できるだけ一緒に動いている。

「計画通り作る」のではなく「どうビジネスを始めていけるか」というビジネスゴールを最重視して開発を進めている。

組織的にエンジニアの技術スキルを重視しており、技術スキルの取組がエンジニアの人事考課に評価項目に入っていたり、エンジニア同士のインフォーマルな勉強会の頻繁な開催が実施されるなど、組織的に技術力の向上を支援している。

事例タイプ自社サービス開発会社タイプサービス事業者システムタイプ広告配信システムプロジェクト工

数 -

プロジェクト期

間 -

プロジェクト関与者人数

開発1名、セールス 1名、事業マネージャ1名

開発言語 Web部分はRuby、広告部分はFlash (ActionScript)

開発拠点同一拠点

開発手法 Scrum+XP

成功度 -

表6 A社事例(1) プロパティ

使用プラクティス群

スクラムやXPをベースにしているものの、

手法に囚われずに必要なプラクティスを選択している。特に技術的なプラクティスを重要視して実践していた。

プロセスに関するプラクティスも実施はしているが、技術的プラクティスだけで実施が手一杯であり、実施の優先度も下がっているため、プロセスに関して深く実践したり改善したりはできていなかった。

特徴的なプラクティス

 イテレーション計画ミーティング

 タスクレベルの詳細な計画は作らずユーザーストーリーレベルの見積による計画をしていた。

 プランニングポーカー

 ストーリーサイズは倍か半分かぐらいのざっくりとした規模で見積した。

 スプリントバックログ

 最初は付箋で実施していたが、マネージャの出張が多いためチケットシステムを使うようにしたが一度頓挫した。現在は再度チケット管理システムを利用しはじめている。

 ユニットテストの自動化

 サーバ側の自動化と、ローカル側の実行の両方を実施している。

 ユニットテストが常に成功であることを維持するので精一杯だった。

 リファクタリング

 非常に重視しており、日常的に、手を抜かずに実施していた。

 集団によるオーナーシップ

 プロジェクト内外にソースコードを閲覧可能にしており、プロジェクト外部の人からレビューや修正パッチが送られてくることもある。

 コーディング規約

 「Rubyらしいコードを書くように」とだけしている。

うまくいかなかったプラクティス

 リリース計画ミーティング

 計画通りに行うことではなく、ビジネスとして始めていけるかをゴールに設定していた。そのためリリース計画を重視していない。

 タイムボックス

 厳密に実施していない。そのためイテレーション中に割り込みがあっても作業を受け付けるようにしている。

 ふりかえり

 実施結果をふりかえるだけで、問題や改善の深堀はしていない。

 ファシリテータ

 結果的には実施していない。ただ意見として挙がったのは、最初はファシリテータの存在、その価値を理解していなかったが、実際に開発を進めていく上で、後になってミーティングの進行などでファシリテータの有り難さに気づいた。

 バーンダウンチャート

 利用していたが、更新を怠ってから段々風化して利用をやめた。

 スプリントレビュー

 事業マネージャやセールス担当には、機能ができた時点で随時レビューしてもらっているため、定期的なイベントとしての「レビュー」タイミングは不要であった。

 インセプションデッキ

 書いてはみたが、そこで終わってしまった。

 共通の部屋

 各自の席は近くだが、チーム毎に集まって座っているわけではない。

 持続可能なペース

 持続可能なペースを尊重しながらも必要な場合は休日出勤も厭わない。

 受入テスト

 受け入れ項目は「広告がでているか」というレベルで手動確認に留まる。

契約形態との関係

自社サービスのため開発についての契約は存在しない

チーム編成・チームメンバ研修との関係

開発者は１人のため、特に研修は行われてはいない。組織としてインフォーマルに技術者同士の交流を持ち、技術的スキルを向上させる機会が多かった。

使用ツール

構成管理

git

IDE / エディタ

NetBeans

ビルド Make, Maven

CI Jenkins、Guard¹⁴

チケット管理

付箋

商用統合開発管理システム

その他インテグレーション環境をクラウドサービス上に仮想環境を構築しその上で実現

表7 A社事例(1)の使用ツール

14 https://github.com/guard/guard

4.3. 事例(2): B 社

自社サービスをアジャイルで開発する事例である。案件に応じて開発手法を選択するのではなく、アジャイル型開発ができる案件を選んでいる。

事業部としてアジャイル型開発に取り組んでいる。アジャイル型開発は、成果物を見ながらフィードバックしていくため、経営層にも注目を浴びている。アジャイル型開発を社内で目立たせるために、受託開発ではなく自主開発を選んでいる。

当事例は、スマートフォン向けのメールクライアントを提供する。チームでサービスを検討しながら実施している。

事例タイプ自社サービス開発会社タイプサービス事業者システムタイプスマートフォン用

クライアントプロジェクト工

数 24人月

プロジェクト期

間 6ヶ月

プロジェクト

関与者人数 4人

開発言語 Java

開発拠点同一拠点で同一フロア

開発手法 Scrum+XP

成功度 4: かなりの部分でうまくいった表8 B社事例(2) プロパティ

使用プラクティス群

アジャイル型開発にフォーカスし、スクラ

ム + XPで実施している。

教科書通りのプラクティスの実施というよりも、自分達の現場の状況に合うように、

独自の工夫をしているものが多かった。

またチームはプロダクトオーナーはいるものの、開発者がかなりの部分でプロダクトオーナー的な責務を支援しており、一般的なスクラムよりも、プロダクトオーナーと開発者の境界はゆるくなっている。

特徴的なプラクティス

 イテレーション計画ミーティング

 プロダクトオーナーが多忙なため、チームメンバーが交代でプロダクトオーナーの責務をサポートしながら実施している。

ユーザーストーリーやペルソナ／シナリオ法、インセプションデッキなどを試している。優先順位付けもチーム内で行っている。

 イテレーション

 最初は二週間であったが、ビジネス的にスピード感が足りず一週間に変更した。

その結果サービス企画へのフィードバックも迅速にできた。

 イテレーション計画ミーティング

 タスクを洗い出す際には、全員でタスクを出すのではなく、ストーリーごとに人が分かれ、分担してタスクを洗い出し、

最後に集まって過不足タスクをチェックすことで時間短縮した。

 プロダクトバックログ（優先順位付け）

 プロダクトオーナーが多忙なため、チームメンバーが交代でプロダクトオーナーの責務をサポートしながら実施している。

優先順位付けも開発者が行っている。

 アジャイルコーチ

 社内のアジャイルコーチを中心として、

各チームのスクラムマスターが集まって

「スクラムマスター道場」と呼ばれる勉強会を開催している。

 日次ミーティング

 朝だけでなく、夕方も実施している。朝はプロダクトオーナーも含めてチーム全員で実施し、夕方は開発者のみ集まり問技術的問題点を解決するために実施している。

 ふりかえり

 KPTを中心に実施している。活気を維持するために、笑いが起こるような話題を意図的に含めていた。

 バーンダウンチャート

 メンバーがもちまわりで記録して日次ミーティング（朝）で確認している。

ドキュメント内アジャイル型開発におけるプラクティス活用事例調査 (ページ 134-200)