サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Kent Beck氏がスタートアップのイベントに登壇し、素晴らしい講演をしたビデオを友人のタイムラインから見つけました。Startup Lessons Learnd: Kent Beck talks beyond agileprogrammingアジャイルマニュフェストは10年が経過して、誰かの為にソフトウェアを作っていた時代から、スタートアップの時代に移行し、内容が一部古くなっていました。ところがこの講演でKentBeck氏は、それに対する素晴らしい回答をしてくれています。この内容が2010に行われているとは驚きです。
アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法 Mike Cohn, 安井 力（訳）, 角谷信太郎（訳） マイナビ出版 3,168円 (2,880円+税) ソフトウェア開発の難題である見積りと計画づくりを「アジャイル」にすることで、開発の現実に即した、誤差の少ない計画づくりができるようになる。その技法を、分かりやすく説いた1冊。 関連サイト本書の関連ページが用意されています。アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法｜マイナビブックス内容紹介「イントロダクション」より本書のタイトルを「アジャイルプロジェクトの見積りと計画づくり」とすることもできた。だが実際には「アジャイルな見積りと計画づくり」というタイトルになっている。2つの違いは些細に見えるかもしれないが、そうではない。採用した現在のタイトルは、見積りや計画づくりといったプロセスを
組織パターン (Object Oriented SELECTION) 作者: James O. Coplien,Neil B.Harrison,ジェームス・コプリエン,ニール・ハリソン,和智右桂出版社/メーカー: 翔泳社発売日: 2013/08/06メディア: 大型本この商品を含むブログ (15件) を見る 2013-10-30、コプリエンの研修にレポータ枠として参加しました。がんばってレポートします。本来は組織パターン (Object Oriented SELECTION)を読んだ人、組織パターンやScrumの好きな人、そしてコプリエンファンの人が参加する研修だと思いますが、どれにも該当しないままでの参加となりました。 会場入り 9:45。6Fにつくと喫煙所に角谷さん(id:kakutani)を発見。朝からついてる感じです。会場に入ると裸足のコプリエンと三人の通訳、TAの皆さんが準備し
An analysis of chinese tourists’ experiences in Milan and Florence
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。 そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。 さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、 メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。
「Lean Startup」の方法論を実践している企業がある。レシピ共有・検索サービスを提供するクックパッドだ。 全社員がリース氏の著書を入社前に読むクックパッドでは、新入社員に対してエリック・リース氏の「Lean Startup」を入社前に読むことを推奨している。もし入社前に読むことができなかったときには、入社後の2日を同書を読む時間にあてることができる。さらに、先輩社員が同社での活用方法をレクチャーしたり、全体会議で成果を報告したりというほどの入れ込みぶりだ。 同社の取り組みは、佐野陽光社長が「自分の言いたかったことが、うまくまとまっている」という理由から社員に薦めたことが発端。社長が普段から繰り返し話している内容に近いという理由もあり、社員の多くが「引き込まれるように」（石田忠司Happy Author部副部長）同書を読み込んだ。それだけでなく、新サービスの開発陣がその方法論を実践
昭和アジャイルライダーの解説 昭和ライダーとアジャイルマニフェストのメンバのマッピングの解説。 まあ、興味のある人だけ読んでおくれ。 Bob Martinが新しい方法論をまとめようと思い立ちました（一号ライダー）。 最初に声をかけたのは、Alistair Cockburnです（二号ライダー）。この2人で話し合った結果、一箇所に集まって議論しようということになりました。 開催場所はスノーバードに決まりました。ホテルを予約するときに3人の書名が必要になりました。そこでお願いしたのが、Jim Highsmithです（V3）。 1人だけ科学者っぽい人がいます。シュレイヤー／メラー法のSteve Mellorです。もちろん、ライダーマンです。 Ward & Kentはペアにしたいと思いました。この2人といえばxUnit。XライダーとZXに割り当てました（年下のKentがZX）。# 武器を使うのもこの
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか？」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
Posted by: Tom Loosemore - former Deputy Director,Government Digital Service, Posted on: 31 January 2012 - Categories: GDS team,GOV.UK A few minutes ago we released the firstphase of the beta test ofGOV.UK - the next step on the journey towards a singledomain for centralgovernment. As Mike Bracken, HMG Executive Director for Digital said, our aim is to deliversimpler, clearer, faster servic
クラウド上でRubyを使って開発し、成果物はオープンソースとして公開。開発プロセスにはアジャイル開発を採用し、毎日スタンドアップミーティングを実施。まるでベンチャー企業が新サービスを開発するようなスタイルを採用しているのが、英国政府のポータル「Gov.uk」の開発チーム。 Welcome toGOV.UK Beta (Test) -simpler, clearer, faster access to UKgovernment services and informationGov.ukは、英国政府の情報とサービスを利用するためのポータルサイトとして開発が進んでおり、現在β版が公開されています。グーグルのプロジェクトのようにGov.ukは作られているGov.ukがどのように開発されているのか、ブログGovernment Digital Serviceにポストされたエントリ「Int
二つの札幌でのイベントについて書きたいと思います。JavaFesta 札幌に参加しました。アジャイル札幌で囲まれました。ｗJavaFesta 札幌は、これまで３回(もしかしたら４回?)呼んで頂き、プロジェクトファシリテーション、マインドマップとソフトウェアのビジュアル表現、などを話しましたが、今回はガチでアジャイル開発について話ました。過去は、アジャイルの認知が国内で進んでいないこともあり、分かりやすい内容にしましたが、今年はアジャイルが本筋だと思ったからです。 内容はこちらです。 資料：アジャイル開発の現在・過去・未来 ～今を知り、源流を訪ね、先を見据える 講演ビデオアジャイルのビジネス環境からの必然性（仕様を決めて作ると65%が無駄）、アジャイルの意味（ビジネス目的と開発のミッションとリスクの整合）、リーン、TPS、アジャイル、XP、Scrumの歴史的関係、そして今話題のKan
アジャイルのプラクティスを、もう一度解説して行きたいと思います。できるだけ、日本の文脈にあった内容を加えて、実践できるように。また、野中先生に後でコメントを頂く予定。 ペア・プログラミング 文字通り、2人一組になってペアでプログラミングを行う。XPでの１つのプラクティスに挙げられており、１台のPCを交互に使って行うのが基本形。昨今ではデュアルディスプレーを使ったり、ネットワークと画面共有を使ったりして遠隔地で実践しているチームもある。 コーディングは単純作業ではない。１つ１つの変数や操作の名前を決めることや、その構造、アルゴリズムにいたるまで、多くの設計判断が入り込む、クリエイティブな活動である。また、ミスが起こりやすい作業でもある。刑事やパイロット、スキューバダイビングなど、リスクが高い作業はペアで行うことは現実の世界にはたくさんある。二人でプログラミングを行うことで、リアルタイムにレビ
第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント: 平鍋健児, 野中郁次郎: 本
