今年初開催となる名古屋支社の楽天テクノロジーカンファレンスに行ってきた！面白かったー！今、帰りの新幹線。僕は何かあったときに助けてねってくらいでいたんだけど、何もすることなかったし、みんな楽しんでたし、ピザとチョコとビールとチョコおいしかったし最高だったなー！スタッフのみんなも、来てくださったみなさんも、素敵でした！お疲れ様でした！ さて。そんな中、「名古屋に行くよー！」って言ってたら、なんと、きょんさんが遊びに来てくれて。しかも僕の相談に乗ってくれたのでした。幸せすぎた。ので、そのおすそ分け。 僕の相談？ こんな話: どんな風に開発してる？ どこまで自動化してる？ TDDやってる？ 知識の共有をどんな風にしてる？ ドキュメントは書いてる？ どんな風に開発してる？ スクラムって最大30日で1スプリントとかいうよね。僕のチームはそれよりは短くて10営業日で1スプリントが多いかな。でも、まだ慣
スクラムを始めたチームで、どんなメトリクスを使って何が起きたか、実話に基づいてお話しします。 Regional Scrum Gathering Tokyo 2016での講演資料です。
「達人プログラマー」が新装版になり、記念にと一冊いただいた。世間話がてら「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: 良くなったと感じていること サービス開発の体制 技術基盤への投資 採用活動 情シスの整備 エンジニアの働く環境 それぞれについて サービス開発の体制 抱えていた課題 マーケティングとエンジニアとの間のコミュニケーションが上手くいかず、開発速度やサービスの意思決定のボトルネックになっていることがあった みんなで話して決める等、それぞれの役割が曖昧なままで開発を進める
システム屋ってのはさ、ソリューション屋なわけですよ。ソリューションってのは問題解決なわけで、一番の問題というのは現実の壁をどうやって乗り越えるかだけど、その壁は実は迂回可能な場合に本当に壁を乗り越えなければならないかを考えるのも問題解決屋の考えるべきことなんだよね。 んで、 先日ブログを書いたら大いに炎上した。いろんな方がいろんなブログを書かれていたようだ。しかし、私は一切読んでいない。なぜならそこに関心がないからだ。ウォータフォール vs アジャイルの比較は私の関心ではなく、私の関心は「どうやったらソフトウェアに関する新しい考えや技術が、日本でも早く導入されるようになるか」だからだ。人生は短い。自分の時間配分は自分で決めているので 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない - メソッド屋のブログ ってのは別に個人の自由なんでどうぞって思うけれども、少
先日ブログを書いたら大いに炎上した。いろんな方がいろんなブログを書かれていたようだ。しかし、私は一切読んでいない。なぜならそこに関心がないからだ。ウォータフォール vs アジャイルの比較は私の関心ではなく、私の関心は「どうやったらソフトウェアに関する新しい考えや技術が、日本でも早く導入されるようになるか」だからだ。人生は短い。自分の時間配分は自分で決めているので 申し訳ないが、今後も読まないだろう。自分の人生は自分で決めるのだから。 simplearchitect.hatenablog.com 実は、この炎上の過程でいろんな仮説を考えることができた。なぜ、日本のソフトウェア産業は、海外に大きく後れを取ってしまっているのか？どうすれば、進化する手助けができるのだろうか？ 自分の現在の仮説はマインドセット、つまり「考え方」が根本的な原因ではないか？という気がしてきた。 私が最近研究しているのは
初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。 togetter.com 今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです（資料の後半に細かいメモ書きがあります）。 そもそもウォータフォールは必要なのか？ とはいえ、ウォータフォールを採用しなくてはならない状況は？ なぜ、アジャイルを採用できないのか？ チームは重要だけど、どういうメンバーがいいのか？ アジャイルとはいえPM的な人が必要になることってあるよね？ アジャイルの立ち上げってどうするのがいいの？ 偶然、牛尾さんの 私は間違
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？ 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
2016年になってもアジャイルはテストをしないとか、計画を立てないとか、1日10回デプロイするための技法といった誤解が広まっているのは残念すぎる。 まず、ITのビジネス価値を最大化するという視点が必要なはず。事業の売上や費用を改善するためにシステムを活用するのであって、システムを作ること自体は目的にならない。 事業を取り巻く環境は変化が速いので、ITもそれに合わせて変えていく必要がある。1年後にシステムが完成したら事業環境が変化していて役に立たないかもしれない。投資が無駄になるリスクを抑えるために、数週間で軌道修正を繰り返す。 だから、事業環境の変化にITを対応させるためにアジャイルが必要、という話の流れになるはず。システムを作るためにアジャイルが必要とはならない。事業上の必要性からアジャイルを選択する。 ここまできて初めて、ITのビジネス価値を最大化するためにスプリントや自動デプロイとい
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
東京海上日動火災保険はディー・エヌ・エー（DeNA）のカーシェアリングサービス「Anyca（エニカ）」向けに、1日単位で加入できる自動車保険の提供を開始した。東京海上日動の基幹システムと外部のネットサービスを接続するという、同社にとって初の試み。ネットと保険という異文化企業同士で議論を戦わせた。 Anycaは自動車の所有者（オーナー）と利用者（ドライバー）をマッチングするサービス（写真1）。東京海上日動はAnycaの利用者を想定して、加入手続きの手間を既存の保険よりも7割以上減らし、スマートフォンから簡単に実行できるようにした。2015年9月、Anycaの開始と同時に保険の提供を始めた。 Anyca向け保険のためのシステム開発では老舗の大企業と新興ネット企業で「文化」が異なり、調整に苦労した。 東京海上日動は「1日自動車保険」の基幹システムを改修するとともに、DeNAのシステムとの連携機能
こんにちは。らくからちゃです。 さて、サラリーマンをしていると、『他所の会社の仕組みってどうなっているんだろう？』と気になることが有ります。大抵、自社の謎ルールを発見したときですが・・・。ただ、聞いてみると、会社間の違いが見えてきて面白いものです。え！お前んとこそんな近距離で出張手当もらえんの！？とかね。 今週のテーマは夏の人事だそうですが、何度かご紹介させて頂いた、『残業しない会社』の友人氏も7月1日付で『常務執行役員 国際化担当』から『執行役員兼システム事業本部長』に転身されたそうです。 『やだよー、ほとんどスタッフ系だったから、ライン系とかむいてないよぅ(´Д⊂ 』と愚痴られておりましたが、しっかり働いてくれればよいかと思います。 そういや、以前書いた記事の中で、こんなコメントを貰いました。 id:diamond523 これはもう残業云々というレベルの話じゃないな。いや残業の有無はそ
ここ1年ほど、コンシューマー向けのWebサービス開発のプロジェクトに参画できました。タイミングとしては、フロント側のミニマム版の先行リリースが済んだところから、バックオフィス側を含めた当初予定の機能一式が揃うまで（いわば「Ver.1.0」といったところ）です。その後の継続的エンハンスにも引き続き携わっています。 このプロジェクトでは“本物”の「スクラム」を実施していました。アジャイル手法をほんとうに実践している現場の経験は初めてでした。 当初は本当に戸惑いました。 自分が“普通の”エンタープライズ・システム開発でPMを務めるようなときは、Unified Processの「アーキテクチャー・セントリック」や「リスク・ドリブン」を意識しつつ、要件たる機能セットの全体を明らかにして、スコープ管理を重視したスタイルで進めます。今回のプロジェクトでは、スクラムとして「バックログ」としてタスクが列挙さ
今日（2015-04-25）は福知山線の脱線事故から 10 年目の 4 月 25 日。つまり、まさーるさんこと石井勝さんが亡くなられてからも 10 年になる。 まさーるさんは、一言でいえば 1990 年代後半から 2000 年代前半の日本におけるオブジェクト指向プログラミング、自動テストとテスト駆動開発、そしてアジャイルソフトウェア開発の啓蒙において大きな役割を果たされた方だ。もしも 10 年前の福知山線に乗っていなければ、いまでも日本を代表するプログラマの一人だったのではないかと思う。 まさーるさんの残した足跡は、様々なところに見いだすことができる。 Java プログラマであれば、 Quick JUnit という Eclipse プラグインを使ったことがある方が多いのではないかと思う。 Quick JUnit はテストコードとテスト対象コードの間をショートカットで行き来できる便利なプラグ
発端は確か一昨年のCROSSで、@hsbtさん、稲尾さんの間で話が盛り上がったのが最初だったと記憶しているから、あれから約2年、強力なメンバーで共同執筆した『スクラム実践入門──成果を生み出すアジャイルな開発プロセス』が、いよいよ3/18に刊行される。 追記: 3/18に発売されました。 Amazonのリンクは以下。電子書籍をご希望の方は、版元のサイトで発売と同時に販売されるはずなので、そちらをお待ちください。 スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治出版社/メーカー: 技術評論社発売日: 2015/03/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る スクラムに関する類書は既にたくさん出ているし、それぞれに素晴らしい本ばかりで、いまさら屋上
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
