「アジャイル開発」に先行して「アジャイル分析設計」を - 設計者の発言
ソフトウエア開発の世界でアジャイル手法が注目されている。「アジャイル」というのは「俊敏な、素早い」という意味の英単語(agile)で、「アジャイル開発」とは、 ユーザーからの要望にもとづいて素早く『動くソフトウエア』を組み立て、それを用いて要望をより具体化しつつソフトウエアに反映させる といった開発スタイルを意味する。 筆者自身もアジャイル開発には共感を覚える。ユーザーが事前に表明できるシステム要件は非常に限られたもので、それに頼って仕様を固めることには無理がある。どうしても、ユーザー要件を漸進的に具体化するための「動くソフトウエア」のような仕掛けが要る。 とはいうものの、その適用に関しては疑問もある。アジャイル開発では、小さなモジュール毎の「設計・構築・テスト・評価」の繰り返し（イテレーション）で作業が進むが、そもそもその「小さなモジュール」を切り出す根拠がよくわからない。この問題はシス
【連載◎開発現場から時代を眺める by arton】第2回
【連載◎開発現場から時代を眺める by arton】第2回 テスト駆動開発（TDD）が分かると従来の設計手法の問題が見えてくる（前編） 本稿では，テスト駆動開発（Test-driven Development――以降TDDと略す）について解説する。TDDは，その名の通りテストを主としてプログラムを開発する手法だ。ここで重要なのは，TDDはテスト手法ではないということだ。では何かと言えば，TDDはその名の通り開発手法なのだ。さらに正確に言えば，プログラムの開発工程を設計，実装，テストの3段階に分割した場合の最初の段階，すなわち設計を主眼とした開発手法なのである。その意味では設計手法と言い切ってもそれほど間違いではない。TDDによってプログラムの開発工程（設計，実装，テスト）がイテレーション（反復）される以上，最初に来る「設計」がTDDの主眼となることはある意味当然のことだ。 本稿の目的は，T
アジャイルプロセスにコーチング － ＠IT自分戦略研究所
コーチングやファシリテーションは、IT業界でも積極的に取り上げられ、活用している企業や個人も多い。そこで本連載では、コーチングやファシリテーションなどのヒューマンスキルを活用している人と、その事例を紹介していく。 今回はWebシステムの構築プロジェクトで、アジャイルプロセス（コミュニケーションを重視する開発プロセス）、コーチングなどを盛り込んだプロジェクトファシリテーション（参加者の協業の場作りに重点を置いた、プロジェクトの中でのファシリテーション）を実践した松本潤二氏の事例を紹介します。 本事例は、アッズーリが受託した案件で、Javaによる企業間取引のWebシステムです。要件定義からリリースまでの新規開発案件で、2005年4月から7月末までの4カ月間で行いました（その後も契約は継続中）。 納品までの1回のサイクル（以下、イテレーション）は2週間で、計画・開発・リリースを8回ほど繰り返しま
テストを金額にするといくら？ ― ＠IT
テスト駆動開発（Test Driven Development：TDD）。最近この言葉を聞く機会が多いと思いますが、実際のプロジェクトでTDDを取り入れているというケースはあまり聞きません。本稿は、テスト駆動開発に興味はあるけれど、いまだ導入に踏み切れないという開発者のために、その効用や実際の運用方法について、具体例を交えながら述べたいと思います。前半はテスト駆動開発の意義と、導入に当たっての説得材料について検討します。後半では実際にテスト駆動開発を進めるに当たって具体的にやるべきことについて、事例を踏まえながら説明していきます。 テスト駆動開発（TDD）とは テスト駆動開発は一般にエクストリーム・プログラミング（XP）の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なもの
アジャイル・エンタープライズ実現への道 － ＠IT情報マネジメント
「経営とITの融合」による「俊敏な経営」実現のために、KIU研究会ではロードマップを整備していく。今回はバージョン1としての5×5のマトリクスを公開する。（→記事要約<Page2>へ） 「生き残ったのは最も強い種ではない、最も賢い種でもない。変化に適応したものが生き残ったのだ」──ダーウィンの言葉として伝えられる、生物進化に関するこの金言は、かねてから企業がビジネス環境の変化に対応することの大切さを説くものとして用いられてきました。 企業を取り巻くビジネス環境変化のサイクルタイムの短期化がますます進んだことで、今日、環境変化の察知能力、環境変化に対する戦略や業務プロセスの迅速な対応能力が企業の生き残りに最も必要な経営要素になってきたといえるでしょう。 そうした中、企業の俊敏性（エンタープライズ・アジリティ）を支える仕組みとして、事業構造・組織・人財・業務プロセス・ITがそれぞれ相互補完する
オフショアでアジャイル開発の実際
JUDEはUMLツールとして無償版から始まり、有償版も出て広く使われてきているツールであるが、この製品開発がオフショア（中国）と日本とでアジャイルに実施されていることはそれほど知られていないと思う。今回はオフショア開発での話とJUDEプロダクト自身のアジャイルな一面を開発者自身に答えてもらう。 JUDEは、1999年から2000年に最初の「Jude梅」シリーズを公開し、その後一時開発を中断、2002年冬に「Jude竹」で復活し、2004年10月に無償版を「JUDE/Community」に名称変更した。その後、同11月に有償版である「JUDE/Professional」の販売を開始した。 JUDEはオフショアで開発をしている。加えて、JUDEという製品開発を進めるうえで、初めに定まり切らない仕様とその時々に出てくるさまざまなユーザーニーズに柔軟に迅速に対応していくために、結果としてアジャイル
ソフトウェアの良い設計を行うコツ（1/3） - ＠IT
ソフトウェア開発ではこれまで、設計の重要性が繰り返し提言されてきた。良い設計ができれば、仕様を満たして正しく動作するだけでなく、理解や変更がしやすく、さらに再利用しやすいシステムとなる。逆に、そのようなシステムが実現できているのなら、それは良い設計であったといえるだろう。 では、良い設計が実践できているかというと、できていないことの方が多いのではないだろうか。例えば以下のような状況を聞くことは決して少なくない。 良い設計が実践できていない例： 不具合を修正してリリースしたら、その影響によりほかの個所で不具合が発生し収束に時間がかかった ほぼ同じコードが複数個所に大量に存在するため、1つの目的の修正でも数多くの同じ修正が必要となった 修正した場所と本来関係ない個所で問題が発生してしまった 機能アップする場合、修正するより作り直す方が早かった それでは良い設計を実践し、このような状況に陥らない
分散ペアプロ(Remote Pair Programming)は可能か？～JUnit の開発はSkype/VNCで：An Agile Way：オルタナティブ・ブログ
分散ペアプロ(Remote Pair Programming)は可能か？～JUnit の開発はSkype/VNCで リモートでのペアプロは可能だろうか？YES。 実はJUDEの開発は、日本と中国での分散開発だ。ただし、完璧なペアプロではない。共通言語がお互い片言の英語、という状況であり、電話を使うのは返ってストレスになる。実際にはメッセンジャーを常時立ち上げて会話している。表示名を「名前（現在のタスク名）」とするなど、工夫をしてコミュニケーション効率を高めている。 最近のXP本家メーリングリストに、Kent Beck が投稿していた。 JUnit の開発は、コードの50%がペア。実際リモートペアプロなんだ。VNCとSkypeを使っている。 なるほど。Skype/VNCが使えるようになって、リモートペアプロの手段も現実的になってきたのだなぁ。 ちょっと、話題がずれるが、ペアプロの効用にはいろ
Rubyでアジャイルプロトタイピング（1） ― ＠IT
想定する読者はこういう人々 本連載では、新たなアプローチでプロトタイピングを行い、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案します。読者には、次のような方を想定しています。 上流工程に携わっているが、うまく進まず悩んでいる これから上流工程に挑戦しようとしている 下流工程でコスト、労力が増大してしまったが、その原因は上流工程にあったと感じている 上流工程の進め方について、新しいアプローチを模索している 本連載では、プロトタイピングに使用するツールとして、オブジェクト指向スクリプト言語であるRubyと、Ruby上に構築されたWebシステムフレームワークであるRuby On Rails（以下：RoR）についても説明し、実際に要件定義からプロトタイピングを作成してみるところまで行う予定です。 なお、Webシステムの開発を前提として解説を行いますが、クライアントサーバシ
アジャルーム配備の産総研入りたい! - 角谷HTML化計画 (2005-11-05)
■1 Agile Web Development with Rails(AWDwR)読書会＠東京 第0回 (あとで書く)書いた 昼前に妻と息子と近所の公園に出かけて、ベンチで昼ごはん。その後、妻子を公園に置き去りにして、Ruby業務チームの集まりへ。業務チームの集まり、といっても高橋さん(日本Rubyの会会長)とogino.さん(Rubyヲチャー)は業務チームだろうが基盤チームだろうと参加しているわけだが。ちなみに、基盤チームとか業務チームとかいうのは私の勝手な便宜上の分類。 「今後の進め方を決めよう」の会なのに30人も来ちゃうのがすごい。ポジションペーパー発表はdanさんのが印象に残った。「最後は君の強さと俊敏さが勝る」というフレーズは私もXP祭りのトークスで使ったので勝手に親近感。ここで「俊敏」という語を選んだ林完治の字幕センスに感謝したい。transcriptでは「they will
ユーザ要望の聞き取り方を学ぶー究極の目的とは？：An Agile Way：オルタナティブ・ブログ
ユーザ要望の聞き取りをする場合、利用者や利用場面を聞くことは重要だ。しかし、もっとも重要なことはなんだろう？それは、そのシステムを作る目的は何か、だ。要求開発でも言われているように、「正しくない要求を正しく実装しても意味がない」。そのシステムを作る目的をはっきりさせることが、要求を聞き取る場合に最も重要なことだと思う。 目的はいくつかある、というかもしれない。では、究極の目的はなんだろう。それを聞き出す、魔法の質問がある。 作ろうと思った動機はなんですか？ この質問は、ぼくが家をたてるときにミサワホーム福井支店の営業、大野尊言さんに聞かれて、感動したものだ。ぼくは家を建てるときに、自分でラフなRFPを書いて数社に提案をお願いしようとした。他のハウスメーカーや工務店が、予算、間取り、和洋、などを聞いてきたのに対して、大野さんは、この質問をした。「家を建てようと思った動機はなんですか？」 ぼく
ObjectClub - アジャイル勘違い集
やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。 アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。 そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。 さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。 アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、 メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。
Bridge Word
This shop will be powered by Are you the store owner? Log in here
arclamp.jp アークランプ: コモディティ化と人月
最近考えていることを独り言。ITにおけるコモディティ化の流れは、ここ最近のエントリで書いている。コモディティ化がおきると、価格競争に入りやすくなり、果てしない消耗戦が始まる。それでは、とても健全なビジネスを行うことは出来ない。 ビジネス単位の変化でコミディティ化を乗り切る、とはいうけれど 大きな話から入れば、ビジネスの世界ではコモディティ化を乗り切るための手法として、ビジネス対価の変革というのはよく議論されることである。ちょっと前の号になるがハーバードビジネスレビュー 2005年8月号の"「脱」コモディティ化の成長戦略"で論じられていたのが、UOB（unit of business：ビジネス単位）の変革だ。 例えば、セメント業界のセメックスは、販売するものを「生コンクリート」から「生コンクリートの配送」に変化させた。それは、顧客は必要なときに必要なだけの生コンが手に入ることを望んでいたこ
MAIL-FLEX The Internet Mail Service
【パスワード変更のお知らせ】 当サービスをご利用中の皆様に、パスワードの変更を行って頂きますよう、お願いしております。 ご連絡がつかなかった方、当サービスを一定期間ご利用になっておられない方については、当方にて パスワードの変更を行わせていただきました。 現在ご利用のパスワードで、ウェブメール、および、POP3接続にて、認証エラーとなった方はこちらをご覧ください。
テストの役割（進捗管理その２）：An Agile Way：オルタナティブ・ブログ
Alistair Cockburn は、ソフトウェア開発の「1個流し」(*1)と進捗管理について、おもしろい例を出している。次の問題を考えてみて欲しい。 ３０個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをすることに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、１ヵ月というデッドラインを守れるか。 ウォーターフォール的計画： １．最初の1週間で全部屋の掃除を行なう ２．次の1週間で全部屋の捨てるものと運ぶものを分類し、ステッカーを家具や備品に貼る ３．次の1週間で全部屋のダンボール箱詰めを行なう ４．次の1週間で全部屋のチェックを行なう ５．４週間あるので、４週間後には全部屋のチェックまで終わる 1個流し的（アジャイル的）計画： １．日割りで、１日に１つの部屋を、掃除、分類、箱詰め、チェックまで終える ２．
＊「ふっかつのじゅもんがちがいます。」 - ペアプロと上司でないマネージャはすっぱいブドウ
開発者が楽しく仕事できる環境とはを読んで。 ペアプロについて 以前いた会社を辞める前に、引継ぎとして（そして個人的な実験を兼ねて）ペアプロをしてみたことがある。確かに効率的だった。近藤さんのおっしゃるような効能を容易く体感できる。僕は何一つドキュメントを書かなかったが、しかしこの引継ぎは「xxx引継ぎ資料20050806.doc」なんていうWordファイルを書いてこれを元に1時間プレゼンして、このファイルをファイルサーバの奥深くに格納するよりもはるかに効果的だった。 ヒント：そういう引継ぎはやらないよりは幾分ましだが、せいぜい「話題の映画のあらすじを教えてもらったから世間話ができる」という程度のご利益しかない。大事なことはいつだって行間に書いてあるのだ。 ペアで作業を行うため仕事以外の事は一切できない（一人で作業しているとついついメールをチェックしたりウェブを見たりしてしまいます） 「これ
朝会を15分で終わらせるには理由がある
前回（第2回 「なにはともあれ、まずはチームビルディング」）はチームの基本的な作り方を解説しました。今回のテーマはチームの運営に不可欠な「会議」の上手な行い方です。 会議・会議・会議 プロジェクトにかかわる以上、会議は避けて通れません。特にリーダーなら、なおさらです。いままでは、どこかしら「関係ないや」と感じていた会議にも参加しなくてはいけません。会議にも大小さまざまありますが、今回はその中から、「朝会」「進捗（しんちょく）会」を取り上げて、それぞれの運営のコツをお話しします。 ・朝会 まずは小さな会議代表として、朝会です。朝会は、チームの状況をチーム内部で素早く共有することを目的とした、非常に短時間の会議です。最近何かと話題の朝会ですが、その理由として、「手軽に、すぐに始められる」「効果が見えやすい」「ソフトウェア開発チーム以外にも有効」などがあるでしょう。以下、概要だけ説明します。 朝
Team Room
by William Pietri XPをこれから始めてみようと思っている人達は、開発部屋がどんな状態か興味を持っているはずです。(XPを知らない人は、この資料の後ろの方の用語集にある簡単な説明を見てください。) ここでは、５人で九ヶ月かけたプロジェクトで撮影した写真を説明していきます。 私達の顧客の機密に関わる部分は写真をぼかしてあります。 質問や、もっと良い方法などの情報は筆者まで。 概要 最初の写真では、開発部屋におけるおもな機材に番号をふってみました。自然光を取入れ、机は木製にし、高い天井の部屋を選んだことで快適な労働環境を実現しています。 写真からもわかるように、最も広い壁側にはプロジェクトに関する様々な情報が掲示されています。 顧客 写真には写っていませんが左側には顧客(Product Manager)が座ります 開発中のストーリ その週に開発するストーリが詳細記述と共に掲示さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.ogis-swe.jp/process/am-res/am/index.html