タグ

ふつうの開発に関するkiwofusiのブックマーク (36)

  • 日本のアジャイルムーブメントに、何が起きていたのか、何が起きているのか

    記事は、InfoQに掲載された平鍋健児氏の記事「What has happened and is happening in Japan’s Agile movement」を、InfoQ Japanの許可を得て翻訳、転載したものです) この10年の私のアジャイル人生でもっとも誇らしい出来事と言えば、Agile2008で「Gordon Pask Award」を受賞したことでした。振り返れば、私が初めて参加したアジャイル関連のイベントは、ソルトレークシティで行われた「Agile Development Conference 2003」で、そこで私は賞をもらったことを思い出します。それは「Thank-you-very-much-for-coming-all-the-way-from-Japan Award」(わざわざ遠い日からようこそいらっしゃいましたで賞)でした。 この記事では、私は「Go

    日本のアジャイルムーブメントに、何が起きていたのか、何が起きているのか
  • 『アジャイルサムライ』の書影と主な目次が出てこないから自分で貼るよ - 角谷HTML化計画(2011-07-02)

    ■1 『アジャイルサムライ』の書影と主な目次が出てこないから自分で貼るよ あわせて読みたい: 「アジャイル開発のディケイドと"The Agile Samurai"」 6/30正午付近に脱稿したら7/1に印刷入稿されたので(青焼の確認がまだあるけど)、いよいよひと区切り。このまま大きな事故がなければ、RubyKaigi 2011の頃には書店に並ぶはず(前日が書店搬入日の予定)。RubyKaigi初日が正式発売日なるスケジュールでオーム社開発局をはじめとした関係各社の総力戦である(RubyKaigi2011会場で先行発売とかそんなリードタイムではないのだ!!)。 でも残念ながら、すてきな三にんぐみのRails3についての素晴しい書籍と違ってまだAmazon.co.jpにレコードはない。版元のサイトにはエントリはあるけど書影もないし目次も企画書段階のときのまま。オーム社eStore(β)にも商品

  • 株式会社マジカジャパンの羽生章洋が書いてるブログ:受託開発と商売と - livedoor Blog(ブログ)

    厄年も明けた今、SIという商売から少し距離を置いて色んなことをやっています。そう言いながら、今週は沖縄に来て要件定義の講習とか、そんな話をやってたりもするんですが。 そうやって離れてみて感じる、SIあるいは受託開発というものについて感じることが色々とあるので、雑多に思いつくままに書いてみます。結論を先に書くと、やれること一杯あるし明るい未来は十分あるよ、です。 さて、そういう立場で世の中を見ると、いやいや結構まだまだ売れる商品がたくさんあります。ネットを挟んだあちら側とこちら側なんて話も一時期流行りましたけど、こちら側、例えば品なんかでも面白いように売れる商品があります。こういうのは売るのが楽しいです。お客様が目の前で喜んでくれますし。他にも色々と改めて感じ入ることがいっぱいです。そういうのは、やっぱり元の商材がいいんです。良い商品というものについて、私なりに最近パラメータが見えつつあり

  • DevLOVE 20100407 木下史彦さん「アジャイルアンチパターン ...」 (1/4)

    「Change The Future 僕らの開発がアジャイルであるために」の木下さんの講演です。正式タイトルは、「アジャイルアンチパターン ~私がアジャイルの1周目で学んだこととXPの次の10年~」です。

    DevLOVE 20100407 木下史彦さん「アジャイルアンチパターン ...」 (1/4)
  • fkino diary(2010-04-09)

    _ アジャイルは終わっていなかった Agile Japan 2010にボランティアスタッフとして参加しています。今年のAgile Japanに参加して、感極まったことがあります。 もう時効だと思うので、ここに書きます。一昨年 (2008年) のクリスマスイブの日、平鍋さんと四ッ谷で飲んでいました (ヒント: 『』の監訳者まえがき)。 帰りの中央線で平鍋さんとふたりになって、平鍋さんがふと「日ではアジャイルは受け入れられないんじゃないか」というようなことをおっしゃったんです。「これだけやってきてこの結果だから、もう少しやってだめだったら、もうアジャイルって言うのをやめようと思っている」と。 そのとき私は思いました。日におけるアジャイルのムーブメントに幕が引かれようとしていると。アジャイルは一夜の夢で終わってしまうと。 平鍋さんは付け加えて、少し考えていることがあるとおっしゃいました。それ

    fkino diary(2010-04-09)
  • fkino diary(2010-02-06)

    _ XP祭り関西2010「アジャイルアンチパターン 〜私がアジャイルの1周目で学んだこととXPの次の10年〜」 XP祭り関西2010で講演してきました。 昨年のXP祭り関西は平鍋さんの講演の時間を半分もらって飛び入りでしゃべったのと、LTに応募して出させてもらったのですが、今年は細谷さんに声をかけていただき、呼んでいただけたのが嬉しかったです。 結論めいた話は特になくて、「日XPユーザグループ関西」なのでXPの実践者の人たちと共有して議論していきたいと思っている話題をしゃべりました。 全体を通して「XP is about social change.」の今の私なりの理解を話したつもり。 聞いていただいたみなさん、スタッフのみなさん、ありがとうございました。 資料をSlideshareにあげました。

  • fkino diary(2011-02-18)

    _ デブサミ2011で『これからの「アジャイル」の話をしよう』という講演をしました まず、会場やUst*1で聞いてくださったみなさん、ありがとうございました。 当日の様子は下の方にスライドとTogetter、それから写真を貼ってありますので、それでだいたい分かると思います。 ここではあの発表に至った経緯を少し書いておきたいと思います。 アジャイル中堅への道 例の新しい契約形態での受託開発サービスを発表した日に岩切さんからTwitterで連絡が来たのがはじまりです。翌日、岩切さん、t-wada、papandaがわざわざうちの会社に来てくれました。実はそのときは、私は新しいサービスを発表した直後で、これからどうなるのか・どんな反響があるのか・仕事はとれるのかと、すごく不安でした。そういった中、3人が来てくれたのはとても嬉しかったです。こう言ってはおこがましいかもしれませんが、まるで旧い友人が応

    fkino diary(2011-02-18)
  • これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル

    Austin 7 friction damper Ptfe 19.5 mm 1 to 5 turns of preloadAdrian Ward

    これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル
  • DIARY SYSTEM Ver.4 - Developers Summit 2011(デブサミ)に参加してきた

  • Stargazer : Hacking the Stars: ソフトウェア開発、ウェブサービス開発、そしてドッグフード

    ソフトウェア開発における概念でドッグフードというものがあります。残念ながら Wikipedia には英語の記事しかありませんが、これを簡単に説明すると自分たちが作ったものを世に出す前に自分たちで使ってみる (ってみる) という概念です。ここで重要なのは、自分たちというのは開発者たちだけではなく、なるべく社内で広く使ってもらうという事です。言うまでもなく、ウェブサービスもソフトウェアですし、人が使うモノを作っている時点で適用される概念です。米国のソフトウェア企業では製品の公開前によく使われている手法のようです。 ここで紹介できる私の人生における実例を語ると昔話になりますが、私が株式会社ミクシィで働いていた頃、 mixi Echo (現 mixi Voice) というサービスを作りました。これは世間的に昔ほど日記を書かなくなったという声を身内やウェブ上で耳や目に入り、それが時代の流れであれば

  • IPA「アジャイル開発向け契約モデル」実証実験参加企業の募集

    2011年6月27日 更新 2011年6月6日 公開 独立行政法人情報処理推進機構 ソフトウェア・エンジニアリング・センター 概要 IPA/SECでは、アジャイル開発を中心とする非ウォーターフォール型開発の普及のための活動に取り組んできました。この度、「非ウォーターフォール型開発WG活動報告書」の2つのモデル契約の契約書案の妥当性検証を行うため、実証実験への参加企業を募集します。 1. 実証実験参加企業の募集の目的 ウォーターフォール型でないソフトウェア開発手法、すなわちアジャイル開発など、「非ウォーターフォール型」の開発手法は、日国内のソフトウェア開発においても、WebアプリケーションやWebサービス開発などを中心に広がり、競争力のある製品およびサービス開発、顧客ニーズへの迅速な対応、開発者・技術者のモチベーション向上等に成果を上げております。 IPA/SECでは、3年前より「非ウォー

  • 「アート・オブ・アジャイルデベロップメントへの道」へ行ってきた - 虎塚

    木曜の夜、平鍋健児さん、木下史彦さんと岡島幸男さん(id:HappymanOkajima)のトークセッション「アート・オブ・アジャイルデベロップメントへの道」へ行ってきました。 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE) 作者: James Shore,Shane Warden,木下史彦(監訳),平鍋健児(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2009/02/18メディア: 大型購入: 18人 クリック: 336回この商品を含むブログ (100件) を見る アジャイル仕事で実践する方々のお話を聞けて、とても面白かった。復習がてら、ノートと記憶から抜粋してまとめてみました。参加しなかった知人にいつか読んでもらうことを想定して書いたら、長くなってしまいましたが。 導入 開始前

    「アート・オブ・アジャイルデベロップメントへの道」へ行ってきた - 虎塚
  • 「受託開発とエンジニアの幸せ」にいってきた - 廻る技術の覗き穴

    ジュンク堂の池袋店で開催されたトークセッション(http://kakutani.com/20080424.html#p01)と、その後の懇親会に参加してきました。 面白かった。酔っぱらいながら感想書く。 トークセッション 岡島さんが新人に教えている3つのプロフェッショナルの条件ってのが良かった(うろ覚えなので若干言葉が違っていると思いますが)。こういうことが言えるリーダについていきたいし、なりたい。 社会との接点を持とう 他人の仕事をリスペクトしよう コストに見合った成果を出そう 皆さん寝る時間を削ってを書いているとか。僕もいつかは書きたいと思っているので参考にw 永和の人は普通の人たちだけど、そこに文化があるからアジャイルのような新しいやり方が根付いていくんだよという話が印象的だった。ギークみたいな人たちが必須というわけじゃないんですよね。僕は今まさに会社で勉強会やったりアジャイルやっ

    「受託開発とエンジニアの幸せ」にいってきた - 廻る技術の覗き穴
  • アジャイルと受託開発の溝はきっと埋まる - GoTheDistance

    以前、僕はアジャイルって受託開発との相性が最悪な気がする - GoTheDistanceというエントリを書きました。 工程が分断されてしまう開発方式を採用している場合は、よりリアルにシステムのビジネス上の価値を表現して伝えることができるアジャイルのメリットが活かせそうに無いというのが骨子。今でもその思いは変わりませんが、逆に言えば工程分断を脱却して企画から実装まで回せる体制になれば可能性はある、とも思っていました。 そんな中、永和システムマネジメント社様が口火を切られまして、アジャイルのメリットを全面的に押し出したビジネスモデルを発表されました。あくまでトライアルという位置づけですが、この話題は定期的に取り上げたい。 骨子としては、この3つ。 初期費用0円(リリースまでの費用は開発側が負う) 月々15万〜150万の定額制 解約は自由だが成果物は全部引き取り。データだけ提供。 うん、どう考え

    アジャイルと受託開発の溝はきっと埋まる - GoTheDistance
  • [覆面座談会]はびこる失敗アジャイル

    アジャイルの適用が進む一方、失敗プロジェクトが増えている。アジャイル開発の経験が豊富な3人に、現場の様子を語ってもらった。いったいどんな失敗が起きているのか。(聞き手は日経SYSTEMS記者、池上俊也) 記者:最近、業務システムの開発にアジャイルを適用する事例が増えてきました。アジャイル開発の経験が豊富な皆さんは、こうした状況をどのようにご覧になりますか。 Aさん:以前は若い開発者が中心となって、Webシステムの開発でアジャイルを採用するケースが多かったと思います。しかし最近は、ちょっと違う。開発会社のトップや、ユーザー企業の担当者がアジャイル開発の採用を求め、トップダウン的に取り組むケースが多いようです。それもこれまでウォーターフォール型を適用していた業務システムのプロジェクトに適用する事例が目立ちます。 Bさん:より速く、より安くシステムを開発する手法として、アジャイルが広く認知された

    [覆面座談会]はびこる失敗アジャイル
  • この業界が変わるわけがないと、言う人はまだいるだろうか。 - The Dragon Scroll

    社内で、アジャイルプラクティスの読書会を開いている。 今日は、その第四回。 アジャイルプラクティスをみんなで読んでいて、感じるのは、 現場には現場のプラクティスが既にあるということ。 その知恵を共有することで、新たな気づきを生むことができる。 Aという現場で抱えている問題は、すでにBという現場で解決を している。でも、それをシェアするようなタイミングも場も 無いから、同じような問題をそれぞれが解決している。 もっと、もっと、組織の壁は越えていい。 さて、この視点を広げてみたらどうだろうと思った。 つまり、社内でやっただけでも、我々は、前進することが できた。 では、会社の壁を越えて、そんな場を作り出すことができたら、どうか。 AというSIerとBというSIerは同じ悩みを抱えているかもしれない。 しかし、CというSIerはそれを既に解決しているかもしれない。 会社という壁を乗り越えたとき、

    この業界が変わるわけがないと、言う人はまだいるだろうか。 - The Dragon Scroll
  • アジャイルプラクティスは2回、奇跡を起こす。 - The Dragon Scroll

    東京に出てきて、初めて参加したXP祭り2006。 そもそも、私は、XPというのは、開発者の自己満足だと思っていた。 開発を楽しいものとしたいのは分かる。そうありたいと思う。 しかし、それだけでは何か置き去りにしてはいないかと感じていた。 最初、XP祭り2006は、私のその思いを拭い去るどころか その疑念を助長させた。 流れるような関西弁を操る、fkinoさんの話を聞くまでは。 fkinoさんは、 「開発者が楽しいだけでは、XPごっご」、 そして「顧客重要」と言った。 この日、直接会話することはなかったが、fkinoという名前は 深く脳裏に刻まれることになった。 やがて、私は、XPJUGの門を叩くことになる。 2007年2月15日。 この日が、自分にとっては何の日だったか。 思えば、この日こそが、この日以降の自分の行動の原点となったんだ。 私の大切なデブサミを台無しにしてくれた、セッション、

    アジャイルプラクティスは2回、奇跡を起こす。 - The Dragon Scroll
  • 1年経った今も、自分にとって大切な一冊に変わりなかった。 - The Dragon Scroll

    酒を飲んでいると、先輩が一冊のを取り出した*1。とても気に入られたようで、そのを、 後輩たちに、回し読みさせているという。ご人も、このの著者の、他のにも手を広げるという。 私は、そのを1年ぶりに手を取って、頁を捲ってみた。次の日、自分の棚から取り出し、再読した。 一気呵成に。新たにメモを取り、そして、また棚に戻した。 この1年間、無意識のうちに、このに書かれていることを自分は体現していた気がした。 そののことは、このブログでもエントリをしていた。ちょうど、1年前のことだった。 変わるまで、あきらめない。 - papandaDiary - Be just and fear not. 1年経った今も、自分にとって大切な一冊に変わりなかった。そのことを確認した。 受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ) 作者

    1年経った今も、自分にとって大切な一冊に変わりなかった。 - The Dragon Scroll
  • SIerのジレンマ - The Dragon Scroll

    経済環境悪化の影響はIT業界には遅れてやってくると言います。ユーザ企業のシステムに対する投資 マインドが低下することは、SIビジネスが縮小することに他なりません。 こういう状況下でSIerはどのような戦略を取るべきなのでしょうか。 とにかくどのような案件でも受注し、リソースの空いている稼動を無くす行動を取るべきなのでしょうか。 それとも、リソースの余裕を、仕組み化に当て、新しい仕掛けを行っていくべきなのでしょうか。 ここで、SIerはジレンマに陥ることになります。 人月ビジネスなので、リソースの空きは、そのまま売上の減少に直結します。一方、仕組み化や仕掛けに 投資ができなければ、競争力がつきません。生産性が向上していくかは、運任せです。 ジレンマから脱却するためにはどうしたら良いのでしょうか。 私が取っている選択肢は、組織に提案することです。 もちろん、仕組み化、仕掛けに対する投資のお願い

    SIerのジレンマ - The Dragon Scroll
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して