まとめました。 ・「納品のない受託開発」から受託開発のビジネスモデルを考える ・Agile459 #19 二大アジャイリストに聞く「アジャイルを越えてこれからの業界・エンジニアの生き方とは?」 開催日:2013/11/8(金) 開催場所:愛媛県松山市男女共同参画推進センター 続きを読む

永和システムマネジメントさんのご厚意により、去る 3 月に Agile Japan 2012 での基調講演を提供するために来日された Jonathan Rasmusson さんに対するインタビューを実施させて頂きました。 Jonathan さんは、「アジャイルサムライ」というアジャイル開発の入門書の著者です。 「アジャイルサムライ」は日本で空前のブームを巻き起こしており、現在日本の各地で勉強会(道場)が開催されています。 インタビューでは、以下の 4 つの分野に渡り、Jonathan さんに質問をしました。 1. Jonathanさんのこれまでの経歴 2. アジャイル開発一般 3. アジャイルサムライ 4. プライベートな生活 今月と来月の 2 回に渡り、Jonathan さんへの突撃インタビューの結果をお届けします。 1. Jonathanさんのこれまでの経歴について -- 今日は、イン
「アジャイル開発を、お客さまに導入してもらうにはどうすればいいですか?」 そんな相談を受けることがあります。私はどんな優れた提案も相手にニーズがなければ通らないことを知っています。喉が渇いていない人に水を売ろうとしても売れないのです。そもそも提案する前に、まずはニーズに気付いてもらう必要があります。そして、そのお客さまは、本当にアジャイル開発に対するニーズがあるのでしょうか。 私の考えるアジャイル開発の本質は「アジャイル開発では当初に想定した機能を”全部”つくらない」ことだと考えています。(参考記事:アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは) この「全てを作らないことで、変化に対して柔軟に開発していく」というソリューションを求めるニーズがあるのであれば、アジャイル開発のメリットを伝えれば採用されることでしょうし、そういうニーズがなければ、何を言っても受け入れられま
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発(内製)が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
請け負い開発でアジャイルのマネジメントやってます。アジャイルはとても忙しいという実感してることをとりとめもなく。 ムービングターゲットを追うこと自体がとても体力がいります。 アジャイルでやるってことは、動くゴールを追うことです。 当然、止まったゴールを追うよりも体力がいります。 体力とは、お金と技術と要員数です。 アジャイルは価値がありますが体力がいります。 マネジメントは予定の策定、実績の分析に頭を使います。 常に新しい予定を立てており、実績の分析も必要です。 次の一手を考えるために前回の分析をしますが、時間はありません。 分析の甘い1手を打ってしまって結局無駄になることもしばしば。 次のイテレーションで何を優先事項とするか?を素早く決めないと空回りするのです。 開発チームも大変ですが、要望側も大忙しです。 その覚悟が要望側にないと大変です。 終わりを作らないと終わりません。 要件って尽
2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。 対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-menRead less
プログラミングとRubyと家族と自分 / Programming, Ruby, Family and Myself なぜ、何のためにプログラミングをするのか。ひとそれぞれ理由はたくさんあり、仕事やお金や趣味のためとは限りません。Ruby on Railsによる家計簿ソフトウェアの開発を通して、自分が使うソフトウェアを自分でプロデュースすること、プログラミングがいかに直接的に家族と自分をハッピーにしてくれたかについて、率直に話したいと思います。 Why are you programming? For what? Programmers have their own reasons to make software. I believe that programming should not be only for work, or as a hobby. I would like to t
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました(これまでの記事一覧)。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか? 1週間? 1ヶ月? 1年? 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
はじめに アジャイル開発に興味を持っている人に取っては「まだ読んでなかったの?」といった感じかもしれませんが、先日書籍「アジャイルサムライ」を借りたので、ざっくりと読んでみました。 今回のエントリは読んでみた感想に加えて、ソニックガーデンでの開発スタイルとの比較をしてみたいと思います。 アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本(ソフトカバー)購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見る とりあえず最初から読んでみた 1章の内容はアジャイル開発の基礎知識が中心で、読みながら「うん、まあそうだよねえ」と思いました。 14ページの挿絵にある「やり方がたった1つなんてことはないんだ!」「君自身が編み出
ウォーターフォールモデルで成功する会社は、僕は天才型企業だと思う。 意外に感じるかもしれない。「天才こそアジャイルだろ!」ってなるんじゃないかとおもう。 でも、最近経験しているいろいろなことが集約されて、天才はウォーターフォール。努力が必要な人はアジャイルと感じる。 いきなり余談からはいるが、僕らの東京事務所は渋谷のヒカリエの向かいにあって、事務所の窓から神々しいまでのヒカリエの姿が見える。 しかしながら、僕らの事務所は窮屈でお世辞にも奇麗とはいいがたいビルだ。 ヒカリエのまぶしさをこのところ目の当たりにしながら、思いを馳せることがたくさんある。 よくわからない事を言ってるのは承知でいうけど ヒカリエ=計画主義=天才型=ウォーターフォールなんだ。 もう一つ余談は、「すべては一杯のコーヒーから」というタリーズコーヒーの経営者の自伝書を読んでいて共感することにある。 すべては一杯のコーヒーから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く