情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
あなたの現場を「アジャイル」に変えたいとき、たどる道筋は2つある
国内でのアジャイル開発の普及と共に、アジャイルという言葉が指す内容にも広がりがでてきました。同じ「アジャイル」という言葉を用いたとしても、それが何を指すのかを注意深く理解する必要が出てきたといってもいいでしょう。 そんな現状を、アジャイル開発の第一人者である平鍋健児氏がブログ「An Agile Way」にポストしたエントリ「アジャイルの「ライトウィング」と「レフトウィング」」で、非常に分かりやすい図と共に整理しています。以下に許可を得てその主な部分を転載します。 アジャイルの「ライトウィング」と「レフトウィング」 アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人
永和流プロジェクト運営術 - スクラムとは？
スクラムとは？ 段階かつ反復型（インクリメンタル ＆ イテレーティブ）のアジャイルソフトウェア開発手法の１つです。他のアジャイル手法と比べ、プロジェクト運営活動のみをシンプルに定義していることが特徴です。 ロール スクラムチーム テスター、プログラマー、データベースエンジニア、ユーザビリティ専門家、ドメイン専門家、ビジネスアナリスト等の役割の人々を まとめてチームとスクラムでは呼びます。 ひとまとめにチームと呼ぶのは、共通のゴールである価値のあるソフトウェアをつくるために、それぞれの専門家が密に協力することを強調しているためです。 プロダクトオーナー 機能(フィーチャ)を取りまとめ、優先度を最終決定する権限と責任を持つ人です。優先度の高い順に並べた機能リストであるプロダクトバックログを管理します。 スクラムマスター プロジェクトを円滑に進めることに責任を持つ人です。プロジェクト初期は、スク
Ruby x Agile version:β - Rubyとアジャイルでふつうのシステム開発を実現する永和システムマネジメントのWebサイト
よくある質問 よくある質問では「Ruby x Agile」に関してお客様から寄せられた質問の中でも特に多く寄せられる質問を掲載しています。 Q1. ドキュメントは書くのでしょうか？ ドキュメントは書きます。下記の図のように、開発サイクルをまわして機能を追加するたびに必要なドキュメントを追加したり既存のドキュメントを修正していきます。ドキュメントも開発の一部として扱うので、「○○のドキュメントを書く」などというバックログを作って優先度を付けて対応しています。 Q2. 行き当たりばったりにやっていて、本当に期間内に納品できるんでしょうか？ 行き当たりばったりにやっているわけではありません。計画を立てて進めています。しかも一度計画を立てて終わりではなく毎週計画をしています。くりかえし計画することでチームの開発速度に基づいた現実的な計画を立てることができます。また、早い段階で計画と実績のずれを知る
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
カジュアル・プログラミング : 小野和俊のブログ
ちょっと前のエントリになるけれど、新しくソフトウェアを作っていくときのスタイルとして、 伊藤さんのこのエントリにはとても共感できる。共感度120%。 DataSpider を最初に開発したときにも、 1年半くらい前に Galapagos 開発チームでミーティングツールを開発したときにも、 同じような感じだった。 スタイルは言語を越えて共通なんじゃないかな。 完成した時に提供できるであろうサプライズにワクワクしながら、 作って、使ってみて、少し考えて変えてみてまた使ってみて、という風に、 手触りを確認しながらソフトウェアを開発していくのは本当に楽しい。 議事録を書く代わりにプログラムを書く。 こんな感じかな？と話しながらお互いにその場で作って見せ合いながら議論を進める。 ブログに書いているだけで、そういう風に開発している時のことを考えて胸が高鳴る。 カジュアル・プログラミング。 発散か収束か
Niko-Niko Calendar にこにこカレンダーのコミュニティ、blog で実験 (^_^)：An Agile Way：オルタナティブ・ブログ
坂田さんやヤマモトさんがやっている「ニコニコカレンダー」という今日の自分のムードの見える化手法がある。 http://www.geocities.jp/nikonikocalendar/index_ja.html チームの壁にこれを貼って、今のチームムードを全員でフィードバックする。ちょっとうまくリーダーに報告できないような「こころもち」も、これなら気軽に伝えられる気がする。略して「ニコカレ」。命名者は、 “つらい気持ちの人も、体調の悪い人も、変化のない毎日の人も、シールを貼っていくうちにこのカレンダーがニコニコマークでいっぱいになればいいなぁ、という気持ちでニコニコカレンダーとつけました。” という。mixi にも、「ニコニコカレンダー愛好会」というコミュニティがある。 ところで、「ブログ」というメディアを使って、「世界ニコカレ」の実験をしてみたい。ブログエントリの「題名」の最後に、自分
Team Room
by William Pietri XPをこれから始めてみようと思っている人達は、開発部屋がどんな状態か興味を持っているはずです。(XPを知らない人は、この資料の後ろの方の用語集にある簡単な説明を見てください。) ここでは、５人で九ヶ月かけたプロジェクトで撮影した写真を説明していきます。 私達の顧客の機密に関わる部分は写真をぼかしてあります。 質問や、もっと良い方法などの情報は筆者まで。 概要 最初の写真では、開発部屋におけるおもな機材に番号をふってみました。自然光を取入れ、机は木製にし、高い天井の部屋を選んだことで快適な労働環境を実現しています。 写真からもわかるように、最も広い壁側にはプロジェクトに関する様々な情報が掲示されています。 顧客 写真には写っていませんが左側には顧客(Product Manager)が座ります 開発中のストーリ その週に開発するストーリが詳細記述と共に掲示さ
- オブLOVE ワールドカフェ
オブLOVEワールドカフェにてみなさんに書き込んでいただいた模造紙は、言葉のみあり、マインドマップあり、イラストあり。そんな形式にとらわれない模造紙から、参加者の皆さんの様々な気づき、想いが見て取れました。 ここでは、その模造紙を無作為に10枚ご紹介します。
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
誰がアジャイルを「殺す」のか？, 『Rubyist Magazine 0012号』リリース - 角谷HTML化計画(2005-12-23)
■1 誰がアジャイルを「殺す」のか？ そのリストには自らが関わるプロセスの「軽量化」のエクスキューズに利用する、スケジューリング(プランニングではない)やドキュメントが嫌いだったり苦手だったりする開発者をはじめ、様ざまなものを挙げることができる。個人的にはこのリストに「魂に響かない翻訳」を加えたい。判型が既存のXPシリーズと同じ(原書より一回り小さい)なのは携帯しやすいので嬉しい。 PofEAA第9回では勝手に第23章をサマるよ。 2005/12/28追記 言い訳がましく補足しておくと、いまのところ翻訳はそんなに悪いとは思ってません。試しに第23章を全文自分で訳してみて痛感したのだが、(勿論)私の負け。ただ、この翻訳には原著を読んだときのような、心が震える感じを受けない。本書は、アジャイル開発に興味があるすべての人にとって、とてもとてもとてもとてもとてもとてもとてもとても大事な一冊だと思っ
ObjectClub - 「プロジェクト成功させる7つのカギ」
『プロジェクト成功のカギ～現場からの声に耳をすませ～』 現在、ソフトウェア開発現場の問題とはなんだろう？ プロジェクトの成功とエンジニアとしてのやりがいは、両立できるのだろうか？ プロジェクトファシリテーションを素材として、現在の参加者の 問題と状況を、ワールドカフェ形式 で一気に共有しようというアンビエントな試み。 1989年東京大学工学部卒業後、3次元CAD、リアルタイムシステム、 UMLエディタJUDEなどの開発を経て、現在(株)永和システムマネジメン トにてオブジェクト指向とアジャイル開発を研究、実践。 オブジェクト倶楽部主宰、アジャイルプロセス協議会副会長、 XPJUGアドバイザリ。翻訳『リーンソフトウェア開発』、 『アジャイルプロジェクトマネジメント』など多数。 「ハート駆動型コミュニケーション」をモットーに、 人に感動を与えられるコンサルタントを目指している。
Rubyでアジャイルプロトタイピング（1） ― ＠IT
想定する読者はこういう人々 本連載では、新たなアプローチでプロトタイピングを行い、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案します。読者には、次のような方を想定しています。 上流工程に携わっているが、うまく進まず悩んでいる これから上流工程に挑戦しようとしている 下流工程でコスト、労力が増大してしまったが、その原因は上流工程にあったと感じている 上流工程の進め方について、新しいアプローチを模索している 本連載では、プロトタイピングに使用するツールとして、オブジェクト指向スクリプト言語であるRubyと、Ruby上に構築されたWebシステムフレームワークであるRuby On Rails（以下：RoR）についても説明し、実際に要件定義からプロトタイピングを作成してみるところまで行う予定です。 なお、Webシステムの開発を前提として解説を行いますが、クライアントサーバシ
- XFD TOP
アイディアの箇条書き、XFD 導入奮闘日記、何でもお待ちしています！ こんなネタ持ってるよ！という方、editors at ObjectClub.jp までご連絡ください。 なお、貴社名掲載の可否、掲載するお名前（ペンネーム、匿名可）を一緒にご連絡ください。 プロジェクトステータスやメトリクスは、目に見えにくい。見えないからこそ難しい。そんな悩みを解決してくれるのが、XFD(eXtreme Feedback Device)です。目に見えて、楽しい、ユニークな装置。目に付いて、絶対見落とさないような装置を指します。安上がりならなおよろし。 XFD に関する文献：Pragmatic Project Automation 元チーム角谷XFD担当 芦沢嘉典 さん ・XFDコレクション 2004年冬(PDF 284KB) ＜2004年オブジェクト倶楽部クリスマスイベント ライトニングトークス発表資料
アジャイル開発におけるプロセスの洗練
プロジェクト概要 このプロジェクトではWebを使った業務アプリケーションを開発した。期間は6カ月、初めは10人でスタートし、ピーク時の人数は17、8人だった。若手が中心で、アジャイル開発が初めてのメンバーがほとんどである。プラットフォームはJ2EE、OSはLinux、データベースはOracle、アプリケーション・サーバはTomcat。StrutsとHibernateとSpringフレームワークを使用している。HibernateとSpringに関しては社内で調査していたので、技術者はそろっていた状態だった。 実践したプラクティス このプロジェクトではXPやスクラムといった既存のプロセスを意識せず、自分たちなりにアジリティを持って開発していくにはどうすればいいかということを考え、プロジェクト前にプロセスの組み立てを行った。イテレーションは2週間で、以下のようなプラクティスを実践した。XPに含ま
発注者はアジャイル開発をこうみている ― ＠IT
メンバーの特徴はアジャイル開発に積極的な人物が多いということ、プロジェクトへの途中加入が多いということ、開発者だけではなく、発注者の猪狩氏が含まれていることである。アジャイル開発は開発者側から語られることが多いが、発注者からはどのように見えるのだろうか。今回はその辺りに注目してインタビューを読み進めてもらいたい。 プロジェクト対象 ワークフローを管理する製品の開発がプロジェクト全体の目的である。このチームは製品の基盤となるエンジン部分をJ2EEで開発している。開発チームは4人体制である。 利用ツール ―― 「開発にはどのようなツールを利用しましたか？」 角谷 「統合開発環境（IDE）はEclipseですね。それとORマッパーの機能もあるので、Jude（永和システムマネジメントが開発したモデリング支援ツール）を拡張して使っていました。ほかに使ったといえばホワイトボードと、後はXPカードですね
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発の繰り返し単位（イテレーション）ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる（ぼくは「ふりかえり」という言葉が好きだ）。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT（ケプト）と呼ぶ（Keep/Problem/Try）。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが３つのセクションに分かれており、Keep（このまま続けること）、Problem（問題点）、Try（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
開発者が楽しく仕事できる環境とは:近藤淳也の新ネットコミュニティ論 - CNET Japan
立って会議をするだけでなく、はてな社内では他にも色々なことを試みています。その中でも、開発者が楽しく仕事ができるように、という観点でいくつか紹介してみたいと思います。 まずはペアプログラミング。これは、2人1組になってプログラムの開発を行うスタイルで、XP（エクストリームプログラミング）のプラクティスの一つとしても提唱されているものです。 2人でプログラムを開発するというのは、1人がプログラムを書き、もう一人が横からそれを見ている、という方法です。この方法を聞くと、1人がそれぞれの作業を行うよりも作業量が2分の1になってしまいそうな気がするものですが、実際はそれぞれが別々の作業をするよりも効率が上がる、という興味深い逆説的な現象が発生します。 ペアプログラミングの様子。こういうときはなぜかコーラが似合います。 なぜ2人1組でプログラミングをする方が1人ずつでやるよりも効率が上がるのでしょう
偉くない管理職
CNET Japan : ［近藤淳也の新ネットコミュニティ論］ 開発者が楽しく仕事できる環境とは http://blog.japan.cnet.com/kondo/archives/002275.html はてな近藤さんのブログは、最近いちばん更新が楽しみなブログのひとつだが、この最新エントリは特に面白い。 ＸＰのペアプロも、開発合宿も、残業しないメリハリ流も、「絵に描く」のはかんたんだが、はてなではちゃんと実践していて、効果をあげているというんだからスゴイ。 しかしそれにも増して、「偉くない管理職」というのが、個人的にはツボにハマった。 ＜人を管理する仕事は上司の仕事であり、社員は上司の管理の下で業務にいそしむ、といった上下関係ではなく、例えば開発者が「この案件を10日後に完成したいので工程管理をして欲しい」と若い社員に管理をお願いする、といったものです。実際に最近では、新しく入った社員
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
