アジャイル開発とクラウド（SaaS）利用の位置づけ、SIerの生きる道
早口の関西弁でつっこみまくって笑いを誘い、でも最後にアジャイル開発とクラウド利用の棲み分けについて「なるほど」と思わせる素敵なライトニングトークのビデオを見つけました。 それはPublickeyでも何度か紹介している9月4日に行われたイベント「XP祭り2010」での、市谷聡啓氏によるライトニングトーク「始まらなかったAgileの話をしよう」です。 アジャイル開発、セールスナントカに敗退す ライトニングトークのあらすじを紹介しましょう。市谷氏がある海岸沿いのSIerにいたころの話。 お客様から「特定の期間しか使わない。できるだけ早く利用したい。ただし仕様は変わる可能性がある」というシステム開発案件の依頼を受け、「これはアジャイルしかないだろう」とお客様に提案。 市谷氏はこの提案で「勝利を確信したなと」。 「ところがこいつが出てきたんですね、黒船ですわ」と思わぬ競合が出現。「具体的に言うとセー
Agileの現状に対する漠然とした不安 - masayang's diary
去年のAgile2009では漠然としか感じていなかったのだけど、今年のAgile2010ではその不安がより確実になってきた。去年はCode Smellのたとえで言えば「どこかでタバコ吸ってる人がいるな」くらいの感覚だったのが、今年は「同じ部屋でタバコ吸ってるバカがいるぞ」、みたいな。 ただしCode Smellみたいなものなので、何かおかしいぞ、という程度の感覚でしかないのも事実である。 その漠然とした不安を抱かせる要因は何かというと「Agileのコモディティ化」なのであります。 自己紹介に「Certified Scrum Masterです」と説明を入れたり、「アナーターハーCSMデースカァー？」みたいな質問をしてきたりする人が今年は昨年よりも確実に目立つ。 あるいは...「わが社は自分では作りません。計画管理と実装は、コントラクタ(契約ベースで請け負う別会社)に任せてます。」みたいな丸投
じゃあ見積りもアジャイルでやりましょう！:グロースハッカー研究所
はじめに断っておきますが今回の記事は私の持論ではなく、私の会社のS氏が普段主張してる意見を私の言葉で書いたものです。 お客様はアジャイルがお好き 私はWebアプリケーションの構築を生業としていますが、Webアプリケーションの特性上、よく「アジャイルで開発して欲しい」という要望を受けます。顧客もアジャイルの定義を正確に知っているわけではないと思いますが、アジャイルの具体的な手法として XPがあり、XPは短期のリリースサイクルを繰り返すことで顧客の要求を柔軟に吸収できる開発手法であるという理解はあるようです。これは正確な定義とは異なりますが、アジャイルとXPについて概ね正しい理解だと思います。アジャイル開発について詳しくはウィキペディアをご覧下さい。 顧客から「アジャイルで開発して下さい」と頼まれた時の私の切り返しは、「じゃあ見積りもアジャイルでやりましょう」というものです。アジャイルのメリッ
古い発想の経営トップ - masayang's diary
ITPro: 若い時にプログラムを書こう，必ず人生の豊かさにつながる 経営トップから「ウォーターフォール型開発」「分業制度」という発想が抜けないから、こういう「昭和時代体質」が延々と生き残ることになる。 悲劇といえば悲劇。 古い発想のままでいるということが理解できてないあたりは、喜劇的ですらある。 私どもの過去の開発実績の平均値を取ると、機能拡張のような案件を除く、ごく普通の開発の場合、開発工数の比率は、要件定義と設計が3、製造が4、試験（テスト）が3です。 今言っているのは、もっと自動化を進めて、4から2まできた製造のところをもう半分減らして1にしたい、ということ。そうすると3、4、3が3、1、1ぐらいでいけるのではないか。合計で5ですから半減、つまり倍速達成となる。 Agile化でフェーズ分割＋分業のオーバーヘッドをなくせば全体で4、下手したら2で済むかもしれない、なんてことは異次元の
「アート・オブ・アジャイルデベロップメントへの道」へ行ってきた - 虎塚
木曜の夜、平鍋健児さん、木下史彦さんと岡島幸男さん（id:HappymanOkajima）のトークセッション「アート・オブ・アジャイルデベロップメントへの道」へ行ってきました。 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE) 作者: James Shore,Shane Warden,木下史彦(監訳),平鍋健児(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2009/02/18メディア: 大型本購入: 18人 クリック: 336回この商品を含むブログ (100件) を見る アジャイルを仕事で実践する方々のお話を聞けて、とても面白かった。復習がてら、ノートと記憶から抜粋してまとめてみました。参加しなかった知人にいつか読んでもらうことを想定して書いたら、長くなってしまいましたが。 導入 開始前
agile＋オフショアは非常に困難。 - プログラマーm-matsuokaの生存記録
http://d.hatena.ne.jp/nanoha3/20090305/1236232630 →今までコーディングにオフショア使ってたため、従業員にコーディングのスキルが育たなかった。ところでagile＋オフショアは無理な組み合わせ？ 非常に困難。 なぜなら、オフショア側からのフィードバックを受け取るのが難しいから。 オフショア側のコーディングミスや仕様理解の誤りなどのフィードバックを受け取ることが難しいため、そのフィードバックをもとにした改良も困難になる。 こちらの仕様や要求の変更をオフショア側に伝えるのも難しい。 （厳密な仕様を作って伝えるくらいなら、こちらでコードを書いた方が早いと思う） コーディングスキルが無ければ、オフショア側が作ったコードの品質もチェックできないだろうし。 ビデオ会議やメールで、相手の理解度のチェックや、こちらの仕様を理解させるのは非道く疲れることですし（
大規模プロジェクトでagileやった結果がこのざまだよ - World Digger
知り合いのIT会社のすんげー偉い人の話を聞いたのでmemo 問題になったら消します。 【状況】 ・某大企業でのとある大規模プロジェクトをagileでやった。開発人数は50〜80人。 ・クリティカルでないシステムだったため、SI側/会社側もagileでやることをOKした。 →クリティカルなシステム（例えば携帯電話会社の料金システムのような、カットオーバー日をずらせないシステム）をagileでやるのは、先が読めないからいかんとのこと。 【問題発生】 /結局SI側もクライアント側もあまりagileを理解してなかった系 ・今までウォーターフォール開発の進捗管理になれていた役員（意志決定者）が、プロジェクト開始後しばらくしても収束することのない将来予測に(((( ；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ！→怖いからやめた。 ・必要とされるスキルに対して、個人のスキルが足りないケースが多かった。 →今
アジャイルで不幸にした業界、法令工学を応用することで、幸せになれれば。。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） いいけどね！ せっかくコメント無視、匿名で書いているんだから、 もっと、世間から、反発されるけど、大事なことを、たまには、書いてみたいと思う。 最近、IT業界って、暗いとおもいませんか？ 村上企画官のおことばを待つこともなく、７Kとか１０Kとか、まったくもって、暗い、イメージの悪い業界になってしまったと思います。 こうなった原因の多くは、アジャイルという名のもとに行われる、仕様の五月雨式変更にあるとおもいます。 ウォーターフォールだった、８０年代後半、９０年代前半は、後工程で仕様変更が原則できないため、どの仕様変更を（例外的に）あえてするか、それをした場合にどれほどのインパクトがあるかを計算してから、行われました。つまり、要求仕様が管理されていました。 さらに、テストに関しても、
ペアで働くと効率4倍 (ビジネス基礎体力)：NBonline(日経ビジネス オンライン)
「ペアプログラミング」と呼ばれる手法で、伊藤さんらプログラマーの間ではよく知られている。仕事の効率は「4倍、5倍にもなる」というのが実感だ。誰でも1人の時はついついメールをチェックしたり、ウェブサイトを見たりして、さぼってしまいがち。でも他人が横で見ているとさぼれないため、100％仕事に集中できる。 例えば数カ月前に作ったプログラムを見直して修正を加えるなど、あまり気が進まない作業をする際、伊藤さんはペアプログラミングをよく利用している。 メリットは「速さ」だけではない。仕事の質も向上する。横で見ている人がミスを指摘するので、間違いが起こりにくい。また、1人の時なら使わない、新しい技術を使おうという誘因が働く。「人が見ていると格好いいところを見せたいと思うから」と伊藤さんは言う。 伊藤さんは「仕事のエンジンがかかるのが遅い方」と自認している。自分を鼓舞して仕事にすぐ取りかかるために、ペアプ
アジャイルだとリファクタリングが必要な理由＆アジャイルする意味をなくす営業・ＰＭの態度 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） アジャイルが使われる多くの理由は、「仕様が固められない」という部分が多いと思う。 あ、あとは、できるのを見ないと怖いとか。。 っていうことで、アジャイルではじめる場合、初めから「共通部分を抜き出して」ということをやれないケースもあるし、やると危険なケースがおおい。 話が進んでいったら、「ぜんぜん共通じゃないじゃーん！！」っていうことになり、その部分を作り直しとなったりするから。 オブジェクト指向な人は、「そーいう部分のために、派生があるんです」というとおもうけど、派生する意味ないくらい、共通じゃない（見た目は共通だけど、中身は共通じゃない）というケースがあるので、やっぱ、オブジェクト指向を採用しても、共通化すると、作り直しになってしまったりする。 てなわけで、いったん全体を作って
開発の速度を上げるには、きれいなテストデータの入手と、スナップショット。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 開発上、とくにテストファーストでアジャイルっぽくやる場合、 テストケースすべてのテストデータができていると、やりやすい。 よく、アジャイルな人は、事前、事後、不変条件をチェックするけど、 バグ発見の立場から言うと、そのレベルでは、みつけにくくって、コーディングの なかで、適当なブレークポイントで、値をダンプ（スナップショットする） だから、スナップショットも適切にできて、きれいにテストデータができていると、 開発は早い。そのための、テストデータ加工ツールや、スナップショットツールを、 火を吹く前につくっておくことが、重要だよね。
Rubyでアジャイルプロトタイピング（2） ― ＠IT
本記事はRoRを使ってプロトタイプを作成し、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案する連載「アジャイルプロトタイピング with Rails」の第2回目です。連載第1回「Ruby on Railsで行うプロトタイピング」は、プロトタイプを作成することの有用性と現状のプロトタイプ作成がどのような問題点を持っているか、RoRを使用してプロトタイプを作成することでどのようなメリットがもたらされるかについて解説しました。連載第2回目は、RoRを使ううえで欠かせないRubyについて解説します。 Ruby入門者にはこれらの書籍をお勧めします 本連載の2回目は、まだまだ知名度が低いRubyに対して読者の方にイメージをつかんでもらうことを目的としています。ですので、この記事を通読してもRubyができるようになるわけでは（当然）ありません。今回の記事を通読していただいたうえで
ＰＨＰ等で画面とプログラムの分離＆アジャイルっぽく開発（テストファースト、ユニットテスト）の例 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 前のブログで、Ｗｅｂにおける画面とプログラムの分離方法の、問題がある方法についてかきましたけど、それで、具体的にはどうなるのか？という話と、これによって、アジャイルっぽくやると（テストファーストとかユニットテストとか）、どうなるかのお話です。 なお、このあとに紹介予定のカオル姫方式でも、アジャイルっぽくできます。 で、まず、具体例。 ここでは、以下のサイトで、ボタンを押して、gamen1.php画面にいくとします。 ＜HTML＞ ＜HEAD＞＜TITLE＞てすとだぴょん＜/TITLE＞＜/HEAD＞ ＜BODY＞ ＜Form action="gamen1.php "method="post"＞ Name: ＜input type="text" name="username"＞＜b
テストの役割（進捗管理その２）：An Agile Way：オルタナティブ・ブログ
Alistair Cockburn は、ソフトウェア開発の「1個流し」(*1)と進捗管理について、おもしろい例を出している。次の問題を考えてみて欲しい。 ３０個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをすることに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、１ヵ月というデッドラインを守れるか。 ウォーターフォール的計画： １．最初の1週間で全部屋の掃除を行なう ２．次の1週間で全部屋の捨てるものと運ぶものを分類し、ステッカーを家具や備品に貼る ３．次の1週間で全部屋のダンボール箱詰めを行なう ４．次の1週間で全部屋のチェックを行なう ５．４週間あるので、４週間後には全部屋のチェックまで終わる 1個流し的（アジャイル的）計画： １．日割りで、１日に１つの部屋を、掃除、分類、箱詰め、チェックまで終える ２．
Rubyでアジャイルプロトタイピング（1） ― ＠IT
想定する読者はこういう人々 本連載では、新たなアプローチでプロトタイピングを行い、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案します。読者には、次のような方を想定しています。 上流工程に携わっているが、うまく進まず悩んでいる これから上流工程に挑戦しようとしている 下流工程でコスト、労力が増大してしまったが、その原因は上流工程にあったと感じている 上流工程の進め方について、新しいアプローチを模索している 本連載では、プロトタイピングに使用するツールとして、オブジェクト指向スクリプト言語であるRubyと、Ruby上に構築されたWebシステムフレームワークであるRuby On Rails（以下：RoR）についても説明し、実際に要件定義からプロトタイピングを作成してみるところまで行う予定です。 なお、Webシステムの開発を前提として解説を行いますが、クライアントサーバシ
Team Room
by William Pietri XPをこれから始めてみようと思っている人達は、開発部屋がどんな状態か興味を持っているはずです。(XPを知らない人は、この資料の後ろの方の用語集にある簡単な説明を見てください。) ここでは、５人で九ヶ月かけたプロジェクトで撮影した写真を説明していきます。 私達の顧客の機密に関わる部分は写真をぼかしてあります。 質問や、もっと良い方法などの情報は筆者まで。 概要 最初の写真では、開発部屋におけるおもな機材に番号をふってみました。自然光を取入れ、机は木製にし、高い天井の部屋を選んだことで快適な労働環境を実現しています。 写真からもわかるように、最も広い壁側にはプロジェクトに関する様々な情報が掲示されています。 顧客 写真には写っていませんが左側には顧客(Product Manager)が座ります 開発中のストーリ その週に開発するストーリが詳細記述と共に掲示さ
アジャルーム配備の産総研入りたい! - 角谷HTML化計画 (2005-11-05)
■1 Agile Web Development with Rails(AWDwR)読書会＠東京 第0回 (あとで書く)書いた 昼前に妻と息子と近所の公園に出かけて、ベンチで昼ごはん。その後、妻子を公園に置き去りにして、Ruby業務チームの集まりへ。業務チームの集まり、といっても高橋さん(日本Rubyの会会長)とogino.さん(Rubyヲチャー)は業務チームだろうが基盤チームだろうと参加しているわけだが。ちなみに、基盤チームとか業務チームとかいうのは私の勝手な便宜上の分類。 「今後の進め方を決めよう」の会なのに30人も来ちゃうのがすごい。ポジションペーパー発表はdanさんのが印象に残った。「最後は君の強さと俊敏さが勝る」というフレーズは私もXP祭りのトークスで使ったので勝手に親近感。ここで「俊敏」という語を選んだ林完治の字幕センスに感謝したい。transcriptでは「they will
ObjectClub - アジャイル勘違い集
やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。 アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。 そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。 さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。 アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、 メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。
Ａｇｉｌｅに計画はいらないか？！：An Agile Way：オルタナティブ・ブログ
アジャイル、って「オヤジ語」に直すと、ＰＤＣＡなんです。Ｐｌａｎ－Ｄｏ－Ｃｈｅｃｋ－Ａｃｔｉｏｎ。上司に「アジャイルでやりましょう」というと煙たがられる（あるいは理解されない）場合は、「ＰＤＣＡをちゃんと回したいんです」と言ってみよう。「おお、君もようやく一人前になったな」と褒められること、請け合いです。 計画をつくるということ↓ http://d.hatena.ne.jp/kuranuki/20050728 そういう意味で、計画は大事。しかし、計画と言う言葉は、後で変更しづらい、あるいは、計画通りにやることが正しい、という「間違った」イメージを作ります。APMでは、構想とよび、計画作りのフェーズを構想フェーズ、としています（Vsion と Envision Phase です）。 構想⇒思索⇒探索⇒適応 ↑－－－－－↓ というループ。 実は、トヨタ生産方式では、「進捗管理」は、「計画と実績
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.ogis-swe.jp/process/am-res/am/artifacts/sequenceDiagram.html