「アジャイル嫌い」はもうやめよう
「アジャイルはプログラマ向けの方法論にすぎない」「大規模プロジェクトは結局ウォーターフォールでしょう」――。エンタープライズ分野のITエンジニアの中には、いまだに開発方法論の「アジャイル」に対してネガティブな印象を持つ人が多い。かくいう記者も、どちらかと言えばそうだった。しかし「アジャイル嫌い」は、もうやめたほうがよさそうだ。 こう感じたのは、日経SYSTEMSの2015年9月号の特集1でアジャイルを取り上げたときである。アジャイルは、少しずつ作ってリリースすることで、要求リスクや技術リスクを軽減する開発方法論。そもそもこのアジャイルに対して否定的になるのは、大きく二つの理由があったからだ。 一つは、アジャイルではユーザーが主導して開発を進める必要があること。日本ではユーザーが一括して開発を委託するケースが多く、開発者の大半はベンダーに属している。そのためユーザーとの距離が遠く、アジャイル
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
いいアジャイルは死んだアジャイルだけだ - 勘と経験と読経
大手ベンダーがアジャイル検定を始めるようで、これについてはいろいろな意見が出ているようだ。「これはアジャイルじゃない」というような意見もあるようだけれども、「いいアジャイル」も「悪いアジャイル」も無いと思う。むしろ「いいアジャイルは死んだアジャイルだけだ」と考えている。釣り気味のタイトルだけれども。 もし、ファストフードのような開発をアジャイル開発と呼ぶのであれば、私の中で「アジャイル」は死んだも同然です。言葉の定義なんて変わるものだし、正しい定義を振りかざしても仕方がないのはわかっていますが、バズワード化するというのは、こういうことですね。 「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change! アジャイル開発は、官僚主義的な計画駆動型のソフトウェア開発へのカウンターカルチャー的な側面があると思っている。これが一般化
DeclineAndFallOfAgile - アジャイルの衰退と凋落
DeclineAndFallOfAgile - アジャイルの衰退と凋落 目次 この文書について アジャイルの衰退と凋落 最近の状況 Scrum の役割 Scrum の誤用 君のやりかたは間違っている 真っ最中での失敗 アジャイルの衰退と凋落 この文書について "The Decline and Fall of Agile" の日本語訳です http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... James Shore アジャイル運動の衰退や凋落について話すのはおかしなことだ. 今やとても人気があるものなのだから. けれど本当のところ, ここ数年のアジャイル運動は、衰退の途にあると私は思う. 最近の状況 自分の商売がここ数年で変化していることに私は気がついた.
アジャイル宣言の葛藤
アジャイル宣言の話の続きです。「アジャイル宣言の背後にある原則」の何が自分の心の中で消化できていない部分を書きます。 以下、ソフトウェア開発者を一般化したように書きますが、言うまでもなく世の中には多様な開発者がいます。簡単に一般化できるものではないことは理解しています。ただ、ある一定の傾向があると思っているだけです。いちいち例外もあります、とは断りませんが、例外があるのは当然です。 さて、ある種の人たちには、開発者は顧客視点が欠けている、という題目が信じられています。 これは必ずしも真実とは異なります。 ソフトウェア開発の過程で技術的好奇心が顧客視点を上回る場面があるのは否定しません。使う人の気持ちより作る楽しさに目を奪われることがあるのも否定しません。しかし純粋に技術的好奇心だけで開発が終始するプロジェクトは、ソフトウェア開発としては稀です。利用者がいる前提で作るソフトウェアで、使う人の
SIがアジャイルやってよくならない点 - @ledsun blog
SIでアジャイルをやるとハイブリッドアジャイルやWater Scrum Fallになります。しかし以下の4点は解決はしません。SIのビジネスモデルでアジャイルが無理なのではなく、「期間と機能を固定して受注する」と変えられない点です。 営業中は、システム担当者は動くシステムを見れない*1。営業マンは見たことないシステムを想像しながら見積もるという高度なヒアリング技術が必要なまま。 開発会社とシステム担当者間で落とす機能を合意しても、「偉い」ユーザーの一声で落とした機能が復活する。多層構造*2による意思決定の遅さは残ったまま。 予算の見積もりは超過方向にしかブレない*3。（予算）見積もりのバッファ問題は残ったまま。 チームメンバによってベロシティ（開発速度）が２〜３倍は変わる。しかし単価はそれほど（４０万〜８０万）変わらない。 アジャイルといっても現時点でのSIのビジネス面へのインパクトは「少
3人以上ペアでやるとミスが多くなる - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
アジャイルのレイヤ 〜 アジャイルを整理し直して理解する - kuranukiの日記
【アジャイル】という言葉は、システム開発の世界ではかなり一般的な言葉になりつつあります。大手のSIerの経営者までが当たり前のように使うようになったことは、ある意味で感慨深いものです。しかし、言葉としてメジャーになりつつある一方で、その言葉の本当の実体を理解しないで誤解したまま使っているケースが多くあるように思います。アジャイルで開発すれば「速い・安い・旨い」が手に入るという誤解や、プログラミング工程だけで使う手法だという誤解、朝会やふりかえりをすることがアジャイルだという誤解、などなど。どれも、完全な誤解という訳ではなく、あながち間違いでもないところが、さらなる混乱を産んでいるように感じます。 最近では、アジャイルの事例も多く出てきたように思いますが、それらの事例も具体的にどういったことを実践したからアジャイルだったかと問われるとそこに明確な答えは無いように思えます。アジャイルとは何か、
アジャイルが語る。価値あるソフトウエアを届けるために必要な12の価値観 - 基本へ帰ろう
私は日頃から「価値あるソフトウェアを提供したい」「開発スピードを向上したい」「顧客も開発者も幸せな環境を作りたい」、そう思いながら開発を行なっています。それらを達成するために必要だと感じているのが、”顧客とプロジェクトメンバー全員”で「価値観（大切だと思うこと）を共有して納得すること」だと思っています。極端な話ですが、もし顧客が「予算も仕様も開発期間も開発メンバーも固定だ。遅れたら土日祝日を使って取り戻せ。残業代はもちろん支払わないぞ。そしてソフトウェアが役に立たなかったら買い取ってもらうからな。フハハハハ！」という価値観をもった顧客と契約（約束）できるでしょうか？価値観というのはとても大切なのです。 私はアジャイルについて、以前から興味を持っています。例えば下記のエントリーがその現れです。 RubyKaigi2010で「本当のアジャイル」を学んだ - 基本へ帰ろう アジャイルな見積りと計
IPA「アジャイル開発向け契約モデル」実証実験参加企業の募集
2011年6月27日 更新 2011年6月6日 公開 独立行政法人情報処理推進機構 ソフトウェア・エンジニアリング・センター 概要 IPA/SECでは、アジャイル開発を中心とする非ウォーターフォール型開発の普及のための活動に取り組んできました。この度、「非ウォーターフォール型開発WG活動報告書」の2つのモデル契約の契約書案の妥当性検証を行うため、実証実験への参加企業を募集します。 1. 実証実験参加企業の募集の目的 ウォーターフォール型でないソフトウェア開発手法、すなわちアジャイル開発など、「非ウォーターフォール型」の開発手法は、日本国内のソフトウェア開発においても、WebアプリケーションやWebサービス開発などを中心に広がり、競争力のある製品およびサービス開発、顧客ニーズへの迅速な対応、開発者・技術者のモチベーション向上等に成果を上げております。 IPA/SECでは、3年前より「非ウォー
スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法
スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法：スクラム提唱者が教える、チームの不幸を減らす方法（1/2 ページ） スクラム提唱者のジェフ･サザーランド氏を講師に招いた、日本初の「スクラムアライアンス認定プロダクトオーナー研修 レポート」レポート。チームも顧客も不幸な状態をなくす方法は実にシンプルだ。 2011年はアジャイル実践者にとって歴史的な年となった デスマーチ続きでリリースは遅延、チームはプレッシャーを受けてマネージャはてんてこ舞い、顧客も不幸……そんな状態を良い方向に転換する方法はたった2つである――「スクラム」提唱者の1人である、ジェフ・サザーランド氏の言葉です。 1月11日と12日、サザーランド氏による日本初のスクラムアライアンス認定プロダクトオーナー研修（Certified Scrum Product Owner 研修、以下CSPO研修）が開催されました。翌日
アジャイル開発 基本のキ - ヲトナ.backtrace
今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基本のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル
「アート・オブ・アジャイルデベロップメントへの道」へ行ってきた - 虎塚
木曜の夜、平鍋健児さん、木下史彦さんと岡島幸男さん（id:HappymanOkajima）のトークセッション「アート・オブ・アジャイルデベロップメントへの道」へ行ってきました。 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE) 作者: James Shore,Shane Warden,木下史彦(監訳),平鍋健児(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2009/02/18メディア: 大型本購入: 18人 クリック: 336回この商品を含むブログ (100件) を見る アジャイルを仕事で実践する方々のお話を聞けて、とても面白かった。復習がてら、ノートと記憶から抜粋してまとめてみました。参加しなかった知人にいつか読んでもらうことを想定して書いたら、長くなってしまいましたが。 導入 開始前
［覆面座談会］はびこる失敗アジャイル
アジャイルの適用が進む一方、失敗プロジェクトが増えている。アジャイル開発の経験が豊富な3人に、現場の様子を語ってもらった。いったいどんな失敗が起きているのか。（聞き手は日経SYSTEMS記者、池上俊也） 記者：最近、業務システムの開発にアジャイルを適用する事例が増えてきました。アジャイル開発の経験が豊富な皆さんは、こうした状況をどのようにご覧になりますか。 Aさん：以前は若い開発者が中心となって、Webシステムの開発でアジャイルを採用するケースが多かったと思います。しかし最近は、ちょっと違う。開発会社のトップや、ユーザー企業の担当者がアジャイル開発の採用を求め、トップダウン的に取り組むケースが多いようです。それもこれまでウォーターフォール型を適用していた業務システムのプロジェクトに適用する事例が目立ちます。 Bさん：より速く、より安くシステムを開発する手法として、アジャイルが広く認知された
現場の成功テクニック［コミュニケーション編、マネジメント編］
今回は、コミュニケーションとマネジメントに関する現場の成功テクニックを見ていく。また、記事の最後には、アジャイル常識度テストを掲載したので、ぜひ挑戦してみてほしい。 コミュニケーション編：座席を一変、昼会・夕会で補う メンバー同士がギクシャクする、ユーザーの協力を得られない、必要な情報を共有できない──。コミュニケーションの失敗は、こんな具合に表れる。もちろんウォーターフォール型でも見られることだが、報告や連絡、相談のほとんどを対面で行うアジャイルは、こうした失敗が発生しやすい。 座席レイアウト一つで円滑に クラウドサービスの開発でアジャイルを適用するユーフィットの林 伸哉氏（ソリューションビジネス事業部 ソリューション企画部 ナレジオン推進室 室長）は、メンバー間のコミュニケーションを円滑にしたいと考えていた。当時、各メンバーは向かい合わせに座っていたが、隣の人としか会話をしない。テスタ
新しい契約形態での受託開発サービス ｜ 永和システムマネジメント
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から アジャイル開発手法として知られるXPやスクラムは、国内で徐々に浸透し始めています。しかしアジャイルをさらに推し進めて企業レベルでアジャイルを活用したり、あるいは企業自身がビジネスをアジャイルに回すためにはどうすればよいのでしょうか。 4月9日と10日の2日間開催されたイベント「Agile Japan 2010」。2日目の基調講演に登壇したAlan Shalloway氏は「アジャイルの現状と未来、次に来るもの。〜リーン開発への展望〜」（What Is Next In the Agile World）と題し、企業をマネジメントする視点からのアジャイルについて講演を行いました。 Shalloway氏の講演は、アジャイルについてよく言われる「プロジェクトではうまくいくが、会社レベルで展開し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「高校生になって初めてスクラムを始めました」～「ストーリー」で何を作るかまとめよう
Blogger