今年初開催となる名古屋支社の楽天テクノロジーカンファレンスに行ってきた！面白かったー！今、帰りの新幹線。僕は何かあったときに助けてねってくらいでいたんだけど、何もすることなかったし、みんな楽しんでたし、ピザとチョコとビールとチョコおいしかったし最高だったなー！スタッフのみんなも、来てくださったみなさんも、素敵でした！お疲れ様でした！ さて。そんな中、「名古屋に行くよー！」って言ってたら、なんと、きょんさんが遊びに来てくれて。しかも僕の相談に乗ってくれたのでした。幸せすぎた。ので、そのおすそ分け。 僕の相談？ こんな話: どんな風に開発してる？ どこまで自動化してる？ TDDやってる？ 知識の共有をどんな風にしてる？ ドキュメントは書いてる？ どんな風に開発してる？ スクラムって最大30日で1スプリントとかいうよね。僕のチームはそれよりは短くて10営業日で1スプリントが多いかな。でも、まだ慣
「達人プログラマー」が新装版になり、記念にと一冊いただいた。世間話がてら「Dave Thomas にはこういう本をまた一冊書いて欲しいですね」と伝えたら、Dave Thomas が出版業から引退したことを教わり、新しい話は新しい人が書くべきではと指摘される。別の読者からも今の時代にあわせた達人プログラマを読みたいという感想があったそうな。 原書の Pragmatic Programmer が出版されたのは 1999 年。XP Explained や Refactoring も同じ年に出版されている。Agile movement 元年と呼べなくもない。Pragmatic Programmer 自体は agility そのものに関する本ではない。とはいえ Dave Thomas は “Manifesto for Agile Software Development” 発起人の一人でもあるから、
概要 最近いろいろな方（社内、社外含め）に、エンジニアチームどうですか？良くなってますか？という質問を頂きます naoya さんってどうなんですか？やっぱりすごいですか？とも その度に「良くなってますよー」と返事をするのですが、肌感としてはあるもののしっかり言語化できていない そこで、naoya さんがCTOとして今年の春に一休に来てからをちょっと振り返ってみた 振り返ってみるとたった4ヶ月ということに驚いています :eyes: 良くなったと感じていること サービス開発の体制 技術基盤への投資 採用活動 情シスの整備 エンジニアの働く環境 それぞれについて サービス開発の体制 抱えていた課題 マーケティングとエンジニアとの間のコミュニケーションが上手くいかず、開発速度やサービスの意思決定のボトルネックになっていることがあった みんなで話して決める等、それぞれの役割が曖昧なままで開発を進める
東京海上日動火災保険はディー・エヌ・エー（DeNA）のカーシェアリングサービス「Anyca（エニカ）」向けに、1日単位で加入できる自動車保険の提供を開始した。東京海上日動の基幹システムと外部のネットサービスを接続するという、同社にとって初の試み。ネットと保険という異文化企業同士で議論を戦わせた。 Anycaは自動車の所有者（オーナー）と利用者（ドライバー）をマッチングするサービス（写真1）。東京海上日動はAnycaの利用者を想定して、加入手続きの手間を既存の保険よりも7割以上減らし、スマートフォンから簡単に実行できるようにした。2015年9月、Anycaの開始と同時に保険の提供を始めた。 Anyca向け保険のためのシステム開発では老舗の大企業と新興ネット企業で「文化」が異なり、調整に苦労した。 東京海上日動は「1日自動車保険」の基幹システムを改修するとともに、DeNAのシステムとの連携機能
ここ1年ほど、コンシューマー向けのWebサービス開発のプロジェクトに参画できました。タイミングとしては、フロント側のミニマム版の先行リリースが済んだところから、バックオフィス側を含めた当初予定の機能一式が揃うまで（いわば「Ver.1.0」といったところ）です。その後の継続的エンハンスにも引き続き携わっています。 このプロジェクトでは“本物”の「スクラム」を実施していました。アジャイル手法をほんとうに実践している現場の経験は初めてでした。 当初は本当に戸惑いました。 自分が“普通の”エンタープライズ・システム開発でPMを務めるようなときは、Unified Processの「アーキテクチャー・セントリック」や「リスク・ドリブン」を意識しつつ、要件たる機能セットの全体を明らかにして、スコープ管理を重視したスタイルで進めます。今回のプロジェクトでは、スクラムとして「バックログ」としてタスクが列挙さ
発端は確か一昨年のCROSSで、@hsbtさん、稲尾さんの間で話が盛り上がったのが最初だったと記憶しているから、あれから約2年、強力なメンバーで共同執筆した『スクラム実践入門──成果を生み出すアジャイルな開発プロセス』が、いよいよ3/18に刊行される。 追記: 3/18に発売されました。 Amazonのリンクは以下。電子書籍をご希望の方は、版元のサイトで発売と同時に販売されるはずなので、そちらをお待ちください。 スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治出版社/メーカー: 技術評論社発売日: 2015/03/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る スクラムに関する類書は既にたくさん出ているし、それぞれに素晴らしい本ばかりで、いまさら屋上
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
〜新しい契約形態での受託開発サービス立ち上げ 1,396日間の記録〜 2010年11月に「価値創造契約」を発表してから4年。数案件を実施し、さまざまな経験をしてきました。その貴重なエピソードを発表します。 @XP祭り2014
先日参加してきた Agile2014 の、社内向けレポートを公開しても良いことになったので、共有させていただきます。 Agile2014 Report: As a Speaker and a Reporter of the latest Agile in the world from Hiroyuki Ito 本当は帰国時（8/4）の飛行機の中で書き終えており、帰国次第即公開しようとしたのですが、社内手続きなどの都合で公開が遅れていました。 また、公開まで期間が空いたので、レポートを書いた当時は理解できなかった点についてもある程度理解が追いつくようになったのですが、帰国時の雰囲気をそのまま伝えたいと考えたため、あえて追加修正をしないでの公開とさせていただきました。 英語で書いたということもありますが、説明足らずの部分も多々ありますので、可能な範囲で追加説明をしてみようと思います。 ３つのト
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
訳出が待望されていた『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』が刊行されたので、さっそく購入して読みました。 この本は、ひとことでいうと組織変革を試みるひとへの手引です。組織には歴史や慣性などもあって、ただ意欲のまま無手勝流に変革に臨んだところで、きっとうまくいかないことでしょう。そこで、先人の知恵を集積したものとして紹介されるのがパターンです。プログラマにとってのデザインパターンが、ソフトウェア設計という困難な仕事に道標を与えるように、この本で紹介されているパターンたちもまた、組織変革にとって役立つことでしょう。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者: 川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,古家朝子,安井力,山口鉄平,米沢仁,角征典出版社/メーカー: 丸善出版発
Agile2010のリサーチセッションで、アジャイルソフトウェア開発におけるレビューをテーマに発表をしている方がいらっしゃいました（資料はこちら）。発表者はMario Bernhartさんだったと思うのですが、彼は発表の中で、Continuous Changeset-Based Review（CCBR）という言葉を使っており、開発の最後でレビューに時間をかけるのではなく、コミットごと（Changesetベース）のレビューという戦略を考え、CCBRを実践するためのツールとしてReviewClipseを紹介していました。 開発におけるレビューのコストは大きいと思います。アジャイル開発だけでなく、通常の開発もサポートする効率的なレビューツールを探してみました。 Mylyn Reviews (ReviewClipse) BernhartさんおすすめのReviewClipseはMylyn Revie
SIerがオワコンだったり新人SEが絶望する今日この頃。組織を憂う前に自分が技術者として終らないようにするほうがよっぽど建設的だと思っている。ひとこと「勉強しよう」というのは簡単。それよりも先に、職業倫理について考えてみるのはどうだろう。 職業がプロとして成熟した証の一つは、倫理規定または職業上の行為の水準が存在することである。 ソフトウエア開発プロフェッショナル 第20章 専門的職業の倫理規定（P239） マコネルの会社のエンジニアが最初に学ぶこと コンストラックスは、Code Completeで有名なスティーブ・マコネルの会社である。同社の専門技術者育成プログラムがソフトウエア開発プロフェッショナルに紹介されていて興味深い。英語版は以下からダウンロードできるようだ。 Construx Professional Development for Software Organizations
5年ほど前に「1日中ペアプロしかしないガチペアプロ」のエントリを書き、 その後も社内でも社外の開発合宿等でも 数えきれないほどのペアプロを行ったり見たりしてきたが その中で新たに気づくこともあったので、 エントリを書こうと思う。 ペアプロは、ドライバーとナビゲーターとが 二人三脚で一つのソフトウェアを作り上げたり、 磨き上げたりしていく行為だ。 二人で作業するので、ペアプロとは会話する行為でもある。 そして忘れてはならないのは、 ペアプロでの会話は聞こえている ということだ。 バグ修正やリファクタリングの際、 既存のコードを洗練させる前向きな目的で 「この箇所、ちょっとわかりにくいね。これだとバグが出やすいよね」 「ここは本当はこういう風に書いた方がきれいだね」 「この命名は誤解を招く可能性があるから、名前を変更しよう」 というような会話をすることがある。 さらに、名前から想像しにくい動き
［CEDEC 2012］「ドラゴンクエストX」における開発進捗管理法とは？ セッション「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」レポート ライター：大陸新秩序 2012年8月20日から22日にかけて，神奈川県内のパシフィコ横浜にてCEDEC 2012が開催されている。本稿では，開催初日に行われたセッションから「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」の模様をレポートしよう。 「ドラゴンクエストX 目覚めし五つの種族 オンライン」公式サイト スクウェア・エニックス 開発部 ドラゴンクエストＸ デザインセクションマネージャー 荒木竜馬氏 本セッションの講師を務めたのは，スクウェア・エニックス 開発部 ドラゴンクエストX デザインセクションマネージャー 荒木竜馬氏だ。荒木氏は，「ドラゴンクエスト」シリーズや「FINA
こんなエントリを書いて早4ヶ月。 なんでアジャイルに取り組みたいか - kaji_3's blog BtoBで対価を頂いてアジャイル開発として遂行した案件が先日終わったのでKPT形式でふりかえります。 前提 期間一ヶ月半 Scrumを参考にしてプロジェクト運用 イベント用WEBアプリケーション 案件の内容をぼかして書いているので、一部整合性の合わない記述があるかも知れませんがご了承ください。 Keep 高い顧客満足度 プロダクトオーナーから「自分たちの意志が反映できた物を作ることができた」とコメントを頂きました。フィードバックから実際のものができるまでのスプリントという考えについても好評でした。顧客の社風として良い物を最後まで模索するという考えがあるとのことで、仕様凍結後の変化は、仕様変更として好まれないウォーターフォールには不満があったとのことでした。 育つシステム 当初想定されていたシ
2012年7月18日(水)に行われたAgile Conference Tokyo 2012に登壇してきました。 30分という短い時間(予定通りの長さで延長したわけではありません！)の中で駆け足でAgile開発から継続的デリバリー、継続的フィードバックやALMへの流れ、なぜテスト自動化が求められるのかといった話と、それに絡めたツール導入の方向性の話をしたつもりです。(もうちょっと笑いを誘える流れにしたかったのですが固くてスイマセン) 当日の参加者の方の多くがAgile開発未経験ということで、Agileに関して銀の弾丸を期待していたり色眼鏡で見られていたりする方もいるかもしれませんが、Agileな開発のやり方や各種ツールは目的達成のための道具でしかありません。 全てのプロジェクトをAgileでやるべきだとも思わないし、Agileでやったからといってうまくいくかの保証もない。ツールも同じで高いお
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
