「アジャイル開発は、実は本を読んで理解するのがとても難しい」。9月4日に、有志によるアジャイル開発のイベントの基調講演「アジャイル開発の現在・過去・未来」の中で、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏はこう発言しました。 本を読んで理解するのが難しいのだとすると、アジャイル開発はどのようにして学んでいくのがいいのでしょうか？ 平鍋さんが伝えようとしたことを詳しく聞くために、メールインタビューをしました。 自分で考えることが本質 先日のXP祭りで平鍋さんの講演を聞いたとき、「アジャイルは人づてに伝わっていく」という部分が印象に残りました。また、「アジャイルは、実は本を読んで理解するのがとても難しい」ともおっしゃっていました。とはいえ、アジャイル開発を本や講演などから学び始める人も多いはずです。そういう方々にアジャイルをどう学ぶのがいいのか、というアドバイスを届け
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
Rubykaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。私もRubyに大変お世話になっていますので、少しでも私に出来ることはないかと思い、個人スポンサーとなって参加させて頂きました。そしてこのブログを残します。 本当のアジャイル 私がRubyKaigi2010に参加して一番痛感したことは、「今までの私はアジャイルをやっていなかったこと。むしろウォーターフォールに近いことをやっていた」と思い知らされたことです。 ウォーターフォールを御存知ですか？半年や１年の開発見積りを行い、それに従って開発を進めるが、見積りが合わなくなり（大抵は見積が足りない）、しかし見積は変えず、デスマーチと呼ばれる慢性的な長時間残業を行うようになり、自分への投資（技術の学習等）を行う時間を犠牲にする開発体
まだ開発が始まっていないプロジェクトがアジャイルのスイート・スポットだと主張する人も多いでしょう。しかし、私の意見は違います。私はいつも既存にシステムの方が簡単にアジャイルを適用できるということを見てきました。重要なのは、今では新しいプロジェクトでも既存のシステムでもアジャイルで開発するための十分な経験が蓄積されているということです。 アジャイルのスイート・スポットの中だけでアジャイルが実践されるわけではありません。アジャイルについての素晴らしい知識が存在するのがスイート・スポットなのです。このスイート・スポットには好循環が存在します。すなわち、多くの経験が多くの成功をもたらし、その成功がまた経験を得る機会を生み出します。 エンジニアリングの実践 チームはアジャイルの導入をどこから始めるべきかという問いに対して私の答えはいつも同じです。すなわち品質です。もしチームがイテレーションの終わりに
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。 IPAが公開している研究報告は、RubyやRailsやアジャイル開発などの昨今の話題を日本のIT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。 運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。 気になる文言をメモ。 【元ネタ】 情報処理推進機構：ソフトウェアエンジニアリング 調査報告書[1.68MB] 研究会報告書[924KB] 成果概要資料[702KB] ・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、こ
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
現在のような形のウォーターフォールモデルがソフトウェアの開発手法として広まったのは、米国防総省が1980年代に定めた調達標準としてウォーターフォールモデルを（それも各フェーズにフィードバックのない一方通行的なウォーターフォールモデルを）採用したためだといわれています。 その米国防総省がようやく、アジャイル開発手法を本格的に取り入れようとしていると、米Excella Consultingに所属し、Project Management Institute（PMI）などの活動を行っているJesse Fewell氏がブログのエントリ「Defense Procurement Goes Agile」で伝え、アジャイルに興味のある人たちのあいだで話題になっています。 Fewell氏のエントリは、米国防総省のCIOオフィスに勤務するDon Johnson氏が行ったプレゼンテーションが基になっています。その
Home » headline, プロジェクト・マネジメントを考える。 アジャイルは二度死ぬ(Agile Only Live Twice)その１：トム・デマルコ氏の蹉跌とその誤謬 アジャイルの隆盛 WEBの世界の中で、日々ITに関する情報を集めていると、アジャイル開発がシステム開発の完全なる主流になった気になってしまいます。偏った情報収集をしているせいだ、といわれればそれまでですが、WEB/ベンチャー業界・SIer業界・企業IT部門/IT子会社界・オープンソース界全てを通じて、Blogなどで声の大きい方々は多かれ少なかれ『アジャイル』という考えに肩入れしているように感じられます。 当然、世の中の流れが全てそうなっているかというと、そういうわけでは無さそうです。WEB/ベンチャー業界や、オープンソース界では、ほぼメインストリームとなっていると思いますが、SIer業界・企業IT部門/IT子会
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
生活面の指導を兼ねた学力向上策に、富山県が取り組む。 「それではペア学習を始めます」。教師のかけ声で隣同士の児童が向き合い、まず「よろしくお願いします」とあいさつした。 射水（いみず）市立作道（つくりみち）小学校３年生の国語の授業で、教室中に、考えを説明し合う児童の声が響いた。教科書の中の物語から、主人公のいる場所や気持ちなどの描写をしている部分を読み取る。 「ペア学習」は今年度から国語と算数を中心に全学年で取り組まれている。国語では主に読解、算数では、文章題を解く際、どの計算式が一番簡単でわかりやすいか、お互いに話し合わせたりする。相手に説明することで、自分の考えを明確にし、相手の考えと比較することで、学習に深みを持たせる。ただ発表し合うのではなく、自分の考えをノートにまとめてから相手に伝え、互いの考えの比較もノートにまとめる。 これを１年間近く続けてきて、書く力が向上しただけでなく、人
「戦略的思考のなんとか」みたいな本は、ほとんど戦争の本ではなくてビジネスの本です。 軍事→ビジネス→その他の組織 という経路で導入された考え方のなんと多いことか。 そもそも、官僚制というやり方自体が、だいたいはこの経路で一般化したものでしょう。 形式的で恒常的な規則に基づいて運営される。 上意下達の指揮命令系統を持つ。 一定の資格・資質を持った者を採用し、組織への貢献度に応じて地位、報償が与えられる。 職務が専門的に分化され、各セクションが協力して組織を運営していく分業の形態をとる。 20世紀は「官僚制の世紀」です。ほとんどあらゆる組織がこの原則で運営され、この方法が社会の常識となっています。 もちろん、それは20世紀の環境ではうまくいったから広まったのですが、この限界と弊害もいろんな所に見られるようになっています。21世紀はこれを解体、止揚していくことが、社会のさまざまな局面において必要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
