『チーム開発実践入門』という本を書きました - ikeike443のブログ
2年くらい前に技術評論社さんから「チーム開発に役立つツールや方法論をまとめた本を書かないか」とお声がけいただきました。 それから構想1年（ぼんやりしてた）、執筆に1年かけて（週末がなくなった）、ようやく4月16日に発売できそうなところまで来ました。 今印刷所でゴインゴイン刷っていると思います。 技術評論社さんのページを見てもらうと、表紙画像もアップされてますね。 http://gihyo.jp/book/2014/978-4-7741-6428-1 Amazonさんにもページができていますが、まだ表画像はアップされてません。 チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus) 作者: 池田尚史,藤倉和明,井上史彰出版社/メーカー: 技術評論社発売日: 2014/04/16メディア: 単行本（ソフトカバー）この商品を含むブログを見る 目次もま
「お前らのアジャイルは間違っている」と彼は言った
少し前にマネージャ層にアジャイル開発事例を話す機会がありました。皆さん「アジャイル」という言葉に抵抗があるようです。さてさてどうやって伝えたらいいものか。発表資料を作りながら悩んだことをここに書いておこうを思います。 アジャイルを語ると胡散臭い 前にもちょっと書いたんですが、アジャイル開発を話す人は胡散臭いです。 たとえば、アジャイルサムライの著者をお呼びしてトレーニングをしたときに思ったんですが、本のファン以外の人にトレーニングの価値を伝えにくかった感触がありました。おそらく「有識者」と名乗る見ず知らずの人（しかも外国人）の話を「信じてください」には無理があるんでしょう。 そのほかにも、別の誰かの話をしだす人は胡散臭いです（海外では〜、○○社では〜、書籍には〜）。これはリーンソフトウェア開発の提唱者メアリー・ポッペンディークさんの本が顕著です。すぐに3Mの話をしだすし具体的な要素が少ない
Developers Summit 2014 で「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」という内容で発表してきました - sifue's blog
あまりにタイトルが長すぎるだろうと各所から突っ込まれ、あまりにも詰め込んだ内容で発表してしまったとちょっと反省しています。 お話としては、現在ニコニコ生放送の内部をPHPからScalaへ書きなおしているよ、というお話でした。 発表内容はこちら。 Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」 from Yoshimura Soichiro これらの内容は、これからScalaを使ってWebサイトを構築、運営してみようとしているリーダーさん向けに書いたものとなっています。Play2/Scalaやドメイン駆動設計、またスクラム開発の導入への足がかりにの情報となっていれば幸いです。 こんな雪の中わざわざ聞きに来てくださった皆様、そしてこの書き直しを着想するにあたってお世話になった特にじゅんいちかと
ITの地殻変動はどこで起きているのか～アーキテクチャ設計技術にクラウドが必須になった時代 - プログラマの思索
2014年になって、ITの地殻変動がどこに起こっているのか、を考えてみる。 ＃ラフなメモ書き。 【1】最近感じることは、Webアプリをプログラミングするアプリケーションエンジニアよりも、サーバー基盤を構築するインフラエンジニアの方が目立つというか輝いて見える時が多い。 何故なのだろう？ また、先月の日経BP主催のITアーキテクト カンファレンスでは、エンタープライズシステムの構築に携わるITアーキテクトを対象にしているが、その内容はすべて、クラウドがキーワードだった。 DOAやOOAは全く含まれていない点が衝撃だった。 ITアーキテクト カンファレンス 2013 最近の流れを見ると、アーキテクチャ設計の技術では、DOAやOOAは既に古い技術であり、クラウドが席巻しているように見える。 【2】最近のバズワードである「クラウド」には、否定的な意見を持つ人も多い。 ITの歴史の延長線上にあるだけ
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
「Team Geek」Google流 チームのつくりかた | Act as Professional
本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。 本書はピープルウエアのようにマネージャーがチームを成功させるための本ではりません。実際にソフトウェアを創り出すプログラマのための1冊です。著者の2人は実際にGoogleでチームをリードしています。そして、オープンソースソフトウェアの世界で活躍するスーパープログラマ達が本書の推薦の言葉を寄せているのがとても印象的で期待を膨らませてくれました。 翻訳者はあのリーダブル・コードを翻訳された角さんです。リーダブル・コードがコードの書き方の基本を教えてくれたのならば、Team Geekはチームで効果的かつ効率的に開発するために必要なことを教えてくれます。 いつやるか。今でしょ。 という表現も使われている。押さえるところを押さえている。さすがである。
スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!
2013/3/9 NADECで講演した内容です。 都合上、やったみた結果の一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
ITの地殻変動はどこで起きているのか？～アジャイルへの流れと設計技法の違和感 - プログラマの思索
第50回SEA関西プロセス分科会の放談会で話しながら、2012年末時点で、ITの地殻変動がどこに起こっているのか？を考えてみた。 ＃ラフなメモ書き。 【1】日本のSIもアジャイル開発を最近は積極的に取り入れようとする流れがある。 2000年代前半、XPをコミュニティ中心で実践したものの、日本のIT業界のメインストリームにならなかった頃に比べると隔世の感がある。 ニュース - NTTデータと楽天が共同でアジャイル教育コース作成、両社で180人育成へ：ITpro その理由は、欧米を中心にScrumを中心としたアジャイル開発が主流になったため、日本でも従来のウォーターフォール型開発にこだわらず、最新の開発プロセスを取り入れようとしたいからだろう。 だから、アジャイル開発が日本のソフトウェア開発の現場に合っているかどうかは、過去の経緯からして、まだ未知数の段階だろうと思う。 でも、リーマン・ショッ
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
歴史から考えるアーキテクチャとマネジメント - arclamp
ソフトウェアアーキテクチャとプロジェクトマネジメントは相互に絡み合う要素です。この関係性を歴史の流れから考えていくと面白い推測が成り立ちます。 アーキテクチャの歴史 「アーキテクチャとは」というのに定まった定義はありませんが、大枠では「システムの目的や環境を前提とし、様々な利害関係者の関心事を整合させた、システムの構成や構造」のことです。 これはもちろん「あるべき姿」です。完成されたシステムには必ず構成や構造がありますが、それが「システムの目的や環境、あるいは様々な利害関係者の関心事」と完全に合致しているとは限りません。 （ソフトウェア）アーキテクチャという言葉、あるいは（ソフトウェア）アーキテクトという用語は2000年前後から一般的になってきました。逆にいえば当時は「システムの構造や構成」と「システムの目的や環境、あるいは様々な利害関係者の関心事」の不一致があったということでしょう。 で
ストーリーポイントの見積りは何故時間の見積りより良いのか
みなさんこんにちは。@ryuzeeです。 よく聞かれるネタではあるのですが、スクラムの父ジェフ・サザーランド氏がストーリーポイントの見積りがなぜ時間の見積りよりも良いかについて過去にブログに書かれたものを意訳・抜粋にて紹介します。 以下の訳文は原文にしたがって、CC BY-NC-SAとします。 原文はこちら 左図: 不確実性コーン 右図: マイクロソフトによるストーリーポイント見積りの正確性 ストーリーポイントを使うとより正確な見積りを得られ、計画の時間を劇的に減らすことができ、リリース日をより正確に予測できるようになり、チームのパフォーマンスの改善の助けになる。 時間を使った見積りは、よくない見積りとなり、システムに大量のムダを生み出し、プロダクトオーナーのリリース計画の妨げとなり、どのプロセス改善が本当に役立っているのかチームがわからなくなる。 新たな興味深い調査結果が公開された。 ス
アジャイルテストを、壮絶に、考えてみた
短い期間でリリースを続け、得られるフィードバックに対応しながら開発を続けていく。 こういったやり方を続けていくと、従来のやり方ではうまくいかないところが出てくるものです。最近は「テスト」が「なんだかうまくいかないなー」という感じになってきたので、とりあえずいろいろ考えてみました。 現在、本を読んだりしてテストを再勉強しているのですが、従来型の開発方法ベースのものばかりで、それはそれでいいんですけど、ちょっと自分の状況に合わない。だから、自分で色々考えながら試行錯誤しているところです。
あなたの現場を「アジャイル」に変えたいとき、たどる道筋は2つある
国内でのアジャイル開発の普及と共に、アジャイルという言葉が指す内容にも広がりがでてきました。同じ「アジャイル」という言葉を用いたとしても、それが何を指すのかを注意深く理解する必要が出てきたといってもいいでしょう。 そんな現状を、アジャイル開発の第一人者である平鍋健児氏がブログ「An Agile Way」にポストしたエントリ「アジャイルの「ライトウィング」と「レフトウィング」」で、非常に分かりやすい図と共に整理しています。以下に許可を得てその主な部分を転載します。 アジャイルの「ライトウィング」と「レフトウィング」 アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人
Agile in a nutshell
© Copyright 2009, Rasmusson Software Consulting Jonathan Rasmusson http://agilewarrior.wordpress.com/ Japanese Translation: Kakutani Shintaro (2010-10-21) Original Slides: http://agilewarrior.wordpress.com/presentations/ © Copyright 2009, Rasmusson Software Consulting Changing requirements Adaptive plans Iterative development The Waterfall Horror Feature Show © Copyright 2009, Rasmusson Software C
ソフトウェア開発における多能工の問題 - 勘と経験と読経
ソフトウェア開発の現場では、特定作業に特化した専門家による分業開発から、個々人が幅広い作業をこなす多能工による開発といった方向に変わりつつある。アジャイル開発プロセスそもそも多能工を前提としている。また、全般的なソフトウェア開発プロジェクトが大規模より中小規模・短工期にシフトしていることが、専門家(単能工)による開発を難しくしつつある状況も、開発エンジニアの多能工化を後押ししている。しかし、多能工によるソフトウェア開発はベストプラクティスかというと、そうではないと思う。多能工アプローチの問題点について考察して望まないと、思わぬところから足をすくわれる事がある。 なぜ多能工なのか？専門家(単能工)はなぜだめなのか？ ファクトリー型アプローチは一時期流行し、いまなお一定の価値をもってはいるが、ほとんどのアプリケーション・ソフトウェアの開発には、現在これよりも有効な手法が存在している。 ソフトウ
楽天テクノロジーカンファレンス 2009 私的不完全議事録 【rtc2009】 - 酒と蕎麦と IT と
10 月 24 日に、品川シーサイド楽天タワーにて開催された「楽天テクノロジーカンファレンス 2009 〜集まれ! モノヅクリスト〜」に出席してきました。いつものように、可能な限り議事録を取りましたので、ここに公開します。 拾えなかった発言、うまくまとめられなかったので省略した部分などはたくさんあります。不正確な内容や事実と反する記述、誤字脱字などがありましたら、この記事のコメント欄やブックマークコメントにて教えていただければと思います。 また、このような有意義なカンファレンスを開催してくださった楽天株式会社の開発部の皆さんに、この場を借りてお礼を申し上げます。ありがとうございました。 目次 基調講演 (三木谷 浩史氏) 特別講演: 楽天の中のわたしと勉強会 (よしおか ひろたか氏) 日本最大の Rails サイト、クックパッドのものづくり (橋本 健太氏) 楽天市場を取り巻く状況と開発
ソフトウェアをつくるための３つの役割〜アジャイルに外部設計は必要か | Social Change!
ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。 ソフトウェアをつくる上で「やるべきこと」は何か ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。 最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。 一人で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルにおけるソフトウェアアーキテクチャ図とNoUML
クライアントの要望にこたえるWebサービス開発 ～「らせん型ワークフロー」のススメ～
