プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から
IPAによる海外でのアジャイル開発についての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）」を紹介した昨日の記事「海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言」は、とても多くの読者に読んでいただき、ツイッターやブックマークなどでもコメントが多数寄せられました。 そうした反響の中で、この調査報告の作成に関わったアジャイル開発の第一人者である平鍋健児氏から「資料の付録にある海外でのインタビューが興味深いので注目してほしい」というメールをいただきました。 インタビューの中で「日本国内に限らず、海外でもアジャイル型開発の普及が進みにくい領域がある」という点を指摘部分は、アジャイル開発がどう位置づけられているのかをあらためて浮き彫りにしているように思います。主に、「リーンソフトウェア開発」シリ
IPA、「海外における非ウォーターフォール型開発の拡大」に関する分析結果を発表 | スラド デベロッパー
システム開発と言えばいまだウォーターフォールが多い日本だが、IPAが6月11日、海外でのアジャイル型開発の拡大を分析した報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書」を発表した。 この調査は日本のソフトウェア産業の強化を目的とし、欧米におけるアジャイル型開発の普及要因を明らかにすることを意図して行われたもの。アジャイルが普及している各国ごとの要因として、米国では「ユーザ企業にIT技術者が多く、内製化率が高い」、ブラジルでは「米国からのオフショア・受託開発が多く、また国内でもアジャイルにおける成功例が認知されている」、デンマークでは「政府調達においてアジャイルが推奨されている」といった点が上げられており、またIT技術者の評価が高く流動性も高いため、知識が業界内を伝播しているといった分析がなされている。 一方、こういったアジャイルが普及している国においても「I
海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言
海外ではなぜアジャイル型開発が普及しているのか、IPA（独立行政法人情報処理推進機構）が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカはアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日本のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル
継続的デリバリーの8つの原則
継続的デリバリーの8つの原則1. ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。このことは2つめの原則にたどり着く。 2. 全てを自動化する！手動のデプロイは決して繰り返し可能で信頼性が高いことには成り得ない。 あなたは繰り返し行う全てのタスクを自動化することについて本気で投資する必要がある。そしてこうすることによって信頼性に繋がっていくのだ。 3. なにか難しかったり苦痛なことがあったら、それを何度もやってみる表面的には、ばかげた話のように聞こえるかもしれない。しかし基本的にこれが意味していることは、苦痛であることを頻繁に行うことは、あなたがそれを改善し、多分自動化する方向に導いてくれるはずだ。そして最終的には苦痛がなくなり容易に行うことができるようになるだろう。 データベースのスキーマをデプロイすることを例にとってみてみよう。もしこれがトリッキー
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
日本のゲーム業界が改善すべき10のポイントとは？ 気鋭のクリエイターが語る、KONAMIと米マイクロソフトの日々でわかったこと【CEDEC 2011】 - ファミ通.com
日本のゲーム業界が改善すべき10のポイントとは？ 気鋭のクリエイターが語る、KONAMIと米マイクロソフトの日々でわかったこと【CEDEC 2011】 2011年9月6日〜8日の3日間、神奈川県のパシフィコ横浜・国際会議センターにて、ゲーム開発者の技術交流などを目的としたCEDEC（コンピュータエンターテインメントデベロッパーズカンファレンス） 2011が開催されている。開催初日には、ライアン・ペイトン氏による“僕の海外ゲーム開発ストーリー＋＋”が行われた。かつてKONAMI小島プロダクションで『メタルギア ソリッド 4』の開発に携わり、3年前に米国マイクロソフト本社に入社後は『Halo（ヘイロー）』シリーズに関わったライアン・ペイトン氏は、日本語も堪能で大の日本通として知られる。海外の開発スタイルを体験したライアンは、日本の開発環境との違いに気付き、「日本のクリエイターに海外開発との違い
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
アジャイル開発向け顧客チェックリスト - GeekFactory
大企業, SIerただ僕が顧客ならば動くソフトウェアを確認しながらウチの業務プロセスにフィットするかを確かめながら進めたいと強く思うので、そのメリットを価値に変えるストーリーがあればいいと思うんだけど、自分たちの手でシステムを進化させる文化が根付いていない所には｢なにそれ？おいしいの？｣という響かない提案になると非常に思うので、やっぱ内製だろって思ってしまう今日この頃です。http://d.hatena.ne.jp/gothedistance/20100212/1265907956id:gothedistanceさんの釣り力には本当に感嘆します。タイトルにアジャイル開発とか入れておきながら、結論は内製で締めています。読者を流行語でget()して自分の論説にforward()するとは、実に素晴らしいエンターテイメントです。と、無茶いってごめんなさい。アジャイル開発の本質は顧客が主体性を持つこ
Agileなプロセスと受託開発は本当に相性が悪いのか？
アジャイルって受託開発との相性が最悪な気がするより。釣りっぽい記事な気もするんだけど。 SIerから見たアジャイル 工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。 要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。 今の日本のSIerのモデルは“まだ"建設業みたいな多重階層の構造であることは間違いない。 収益性については、一次受けのSIerは少ない要員で沢山のプロジェクトを外注使って
Agile 2011 Conference : リーンスタートアップに対応する「リーンUX」製品開発を体感するチュートリアル - kawaguti’s diary
先月の Agile 2011 Conference の報告のシリーズを EnterpriseZine で連載させていただきました。この日記では Agile UX 番外編として２つほど紹介してみます。 UXを用いた製品の要件定義に関するセッションを２つ紹介 アジャイル開発では、顧客や利用者との頻繁なコミュニケーションを重視します。実際に動くソフトウェアやプロトタイプをなるべく早い段階で提供し、手遅れになる前に見当違いを修正し、潜在的なニーズを少しでも汲み取ることを目指します Agile 2011 Conferenceでは、利用者を観察し彼らとの共同作業を学ぶための場として「User Experience＆Interaction Design（ユーザエクスペリエンス＆インタラクションデザイン）」と「Working with Customers（顧客との協同作業）」の2つのトラックが用意され、実
スクラムを1枚で説明する資料7選
みなさんこんにちは。@ryuzeeです。 スクラムを1枚の絵で説明する資料はいろいろ出回っているので、整理をしてみました。 どれもちょっとずつ内容が異なったりしているので比較してみると面白いです。 是非自分用のものを作ってみると良いのではないでしょうか。 http://www.axosoft.com/ontime/videos/scrum/#scrum-diagramCC-3.0のライセンスで公開されている。ダウンロードは前述のページの下部から可能です。 The War Room - Does your Scrum room have the best Scrum image?Free Intro To Scrum Wallpaperマイク・コーン氏のスクラムの説明資料の中の絵を格好良くしたもの。CC-2.5ライセンス。 SCRUM PosterCC BY-NC-ND 3.0ライセンス.
【資料公開】アジャイルな開発からアジャイルな組織へ
みなさんこんにちは。@ryuzeeです。 2012年3月16日に実施されたAgile Japanの大阪メイン会場に登壇させていただきました。 発表の資料を以下に公開します。 会場の外まで立ち見が溢れるくらいの多くの方にお越しいただき感謝するとともに、ご不便をおかけした方にはお詫びしたいと思います。 僕が話した内容は、実は単に実際の現場で、現場を良くしたいと思っている皆さんの胸のうちを代弁しただけです。 アジャイルという単語、スクラムやXPといった手法の名前自体の認知度があがって、ともすればこれらを導入すれば全てうまくいくんだ、と誤解を生んでいるのではないかと感じています。 でも手法は手法でしかなく（したがってスクラムやXPを導入しているからといって自分たちのアジャイル度合いが高いとは限らない）、目的に応じてそれにあった方法、自分たちがゴールを達成するのに最適だと思う方法を脳みそ振り絞って考
トヨタ生産方式と医療～改善事例
『物の置き場の固定化』→２Ｓの観点より、スペースを有効活用するために、棚や引出しを全て点検し、不要な物には、「赤色の付箋紙」を張り付け、準備室から撤去した。また、棚に保管する物は、表からすべて見える位置に置き、物品名の表示をした。さらに、回診車の定数を最小化するために同様の対応をした。 『書類の整理』→２Ｓの観点より書類の整理に取組んだ。大分類としてマニュアル類と記録類に分ける。マニュアル類にも、病院全体や看護部共通のもの、スタッフステーション独自のものがあるので、それぞれに分類しナンバリングのうえファイリングをした。
リーン・ソフトウェア開発と、アジャイルチームの先の話。組織のアジリティへ - kawaguti’s diary
４月にリーン・ソフトウェア開発の提唱者、メアリー・ポッペンディークさんと、パートナーでありソフトウェア技術者でもありプロ級の写真家でもあるトム・ポッペンディークさんの夫妻をお迎えして、(たぶん)日本初の有償研修をオーガナイズします(会社として)。 メアリー・ポッペンディーク「Leaders' Workshop (リーダーのためのワークショップ)」 4月9日〜10日 (同時通訳付き) 研修ハイライト => PDF リーン・ソフトウェア開発の「リーン」は、トヨタ自動車の生産方式を研究した北米の科学者がつけた名称です。リーンは贅肉(ムダ)が取れた状態をさすそうです。日本では工場における「ムダとり」の活動が有名です。メアリー・ポッペンディークさんは、トヨタ生産方式やその成立に大きな影響を及ぼしたデミング博士の手法を研究し、ソフトウェア開発の分野でそれを活かせるよう、３冊の本にまとめています。 リー
バリューストリーム・マップ（ばりゅーすとりーむ・まっぷ）
リーン生産方式やリーンソフトウェア開発において、生産や物流、ソフトウェア開発などの工程を改善する際に、現状を把握し将来のあるべき姿を明確にするために作成されるプロセス図のこと。もともとはトヨタ生産方式における手法で、トヨタ自動車では「物と情報の流れ図」という。 バリューストリーム・マップは、特定の製品（製品ファミリー）が原材料が加工されて顧客の手に渡るまでの全工程の経路と、各工程がどこからの指示で実施されるのかを示したものである。描く場合は改善対象となる工程だけでなく、前後のつながりが分かるように1次仕入先から納入先（顧客）までのすべてを工程順に左から右に並べる。工程はボックス状に表し、工程名とその稼働時間、および生産リードタイムを付記する。そして、それら工程に対する引き取りや仕掛け指示の情報発生源を示し、同時に情報伝達手段や頻度を記載する。 バリューストリーム・マップを作成することによっ
【資料公開】バーンダウンチャート虎の巻
みなさんこんにちは。@ryuzeeです。 2010/12/22に永和システムマネジメントさんで実施したスクラム道.02でバーンダウンチャートについてお話させていただきました。 その際の資料を公開します。 スクラムではバーンダウンチャートを使うことが定義されていますが、バーンダウンチャートもツールなので、それをどう使うか、というのを考える事は非常に大事だよ、ということ、改善に使うべきであるということ、形状等を見ればチームの自己組織化レベルまで推察することができるよ、指標を追加するとさらに色々なことが分かるよ、といった話をしてます。 日本ではバーンダウンチャートについてこの話をしている人はまだほとんどいないはずです。 感想を聞かせていただければ幸いです。
[Agile]インセプションデッキ日本語版 | Ryuzee.com
インセプションデッキって何？って人はThe Agile Samuraiを読むと良い。 The Agile Samuraiの日本語版は@kakutaniさんや@nawotoさんが頑張ってらっしゃるので、期待して待っていよう。 簡単にいうと、インセプションデッキは10個の質問から構成されていて、プロジェクトを始めるにあたって、その質問に答えることによって、プロジェクトの全体像やこれからの方向性等を明らかにしてくれるツールだ。(逆に答えられないとするとその時点で結構ヤバイということでもある)。そしてプロジェクト期間中は見えるところに貼っておき、何か変更があれば随時更新していく。 詳細は本の著者であるジョナサンのサイトのThe Agile Inception Deckを見て欲しい。 公開されているインセプションデッキのテンプレートを日本語化してみた。 以下からダウンロードできる。ライセンスはC
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
富士通におけるアジャイル開発への取組み
バリューストリームマッピングはソフトウェア開発でも有効か？
バーンダウンチャートを解読する
