【資料公開】カイゼンの基本みなさんこんにちは。@ryuzeeです。 2016年9月16日に行われたDevelopers Summit 関西で表題のテーマで登壇してきましたので資料を公開します。 カイゼンについては1日のトレーニングコース（バリューストリームマップ作成含む）を[@haradakiro](https://twitter.com/haradakiro)と提供していますのでご興味のある方は[ご連絡](https://www.ryuzee.com/contact.php)ください。
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
デプロイ自動化を進めるためのチェックリスト | Ryuzee.com
いままで色々なところで言ってきたことをだらだらとまとめてみました。 計画および準備段階要求される品質の定義をおこなうDevとOpsの双方で情報が共有されるようにするいつデプロイを開始するのかを明らかにするデプロイの際にインフラを変更する必要はあるのかを明らかにするデプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)ブランチ戦略、マージ戦略を決める継続的インテグレーションの戦略を決めるログの出力戦略を決めるビルドとリリースの自動化人的要素を減らす繰り返し可能にする自動作業と手作業を混ぜないビルドを自動化する誰のマシンでもビルドできるようにするユニットテスト、結合テスト、UIテストなどテストを自動化する本番にデプロイする際にコードを書換えなければならないといった実装を避ける毎回デプロイプロセスを設計するのではなく、毎回同じ方法でデプロイする毎回同じ方法が難しければ2パター
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
開発をより良くしたい人が読んでおくべき10冊
アジャイルな開発の導入支援の現場や色々な勉強会でよく「どんな本を読んだら良いですか」と聞かれたりします。 何のために本を読んで勉強するかは人それぞれですし、自分のおかれたコンテキストでどの本が役にたつかは分からないですが、以下にあげた本は個人的に強くオススメできる本です。人に聞くのも大事だし自分で試行錯誤するのも大事だけど、本を読んで体系的に学んだり先人の知恵を学ぶことは続けたほうが良い。 プロダクティブ・プログラマ -プログラマのための生産性向上術どうやったら自分自身の生産性を高くすることができるのか。PCの使いこなしから始まり、自動化やバージョン管理等にも触れている プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)著者／訳者：Neal Ford、島田 浩二 (監訳)、夏目 大出版社：オライリージャパン発売日：2009-04-27単行
Vagrantで簡単仮想マシン構築
VagrantはOracle VirtualBoxを利用した仮想マシンをコマンドラインから作成してくれるソフトウェアだ。 設定ファイルをRubyで書くことができ、Chef等とも連携できるので、開発環境をコマンドライン一発で作成することができる。更にはCapistranoと組み合わせてアプリケーションのデプロイも一括で行うことで完全自動でいつでもテスト環境をつくれたりもする。 仮想マシンを捨ててしまってもいつでも再構築できること、誰のところにでもすぐ同じ状態に展開できることは開発を進める上で非常にメリットがある。 以下ではまずはVagrantを利用した簡単な仮想マシン構築の手順を説明する（本当に説明したい内容はもっと違う話なのだが追って別のエントリで書いていくことにする） Oracle VirtualBoxのインストールhttps://www.virtualbox.org/にアクセスし左ナビ
継続的インテグレーションアンチパターン
みなさんこんにちは。@ryuzeeです。 なんとなく書きためておいた継続的インテグレーションのアンチパターンをいくつか紹介します（結構ラフなメモ書き）。 頻繁にSCMにコミットしないテストコードを書かないテストコードと製品コードを同時にコミットしない定時ビルドのみでコミットビルドがない・夜間ビルドしかない帰り際にコミットしてそのままCIの結果を見ずに帰るCIでテストを通すために手作業の準備が必要メインラインのみで大きなブランチをCI対象にしていない様々な種類のテストをまとめて行っているビルドの失敗に気付かないビルドに失敗しても放置しているビルドの失敗に気づいても、修正コード以外のコードをコミットする何も変更していないのにビルドが落ちたり落ちなかったりする頻繁にビルドが失敗しているので、失敗するのが普通だと思うCIからの通知メッセージが大量すぎるCIが落ちても何も通知しないCIサーバのリソー
翻訳 アジャイル関連書籍ベスト100(2011年度版)
NOOP.NLというサイトで、今年もTop 100 Agile Books (Edition 2011)ということでアジャイル関連書籍のトップ100のリストが出ていたので、日本語訳されている本のリンクを追加してみました。 大きなトピックスとしては、日本でも勉強会が同時に多数開催されるなどアジャイルに関心がある人達の間で大きなムーブメントを起こしているアジャイルサムライがいきなり9位に登場していることだと思います。 一方で昨年から邦訳された本がアジャイルサムライ以外に増えていないところは悲しいところではありますが、現在いくつかの書籍について翻訳されている方がいらっしゃるので出版に期待です。 2010年度版はこちら The Art of Unit Testing: With Examples in .Net 前年度：5位 Roy Osherove 2009 Agile Estimating a
今すぐフォローすべきAgile界のスーパーエンジニア
たまには便乗してみるよ。 Agile界のすごい人＝スーパーエンジニアと呼ぶのかは疑問もあるけど。とりあえず対象は日本語のつぶやきをする人です。他にも沢山すごい方はいらっしゃるので流量が多めの方を恣意的に選択してます。(○○さんがいない、といって怒らないでください) 平鍋健児さん (@hiranabe) いわずと知れた第一人者。みんな本を読んでるはず 角谷信太郎さん（@kakutani） RubyとXP。アジャイルな見積もりと計画づくりやアジャイルプラクティス 和田卓人さん（@t_wada） TDD。プログラマが知るべき97のこと 倉貫義人さん（@kuranuki） XP。YouRoom等のサービスを社内ベンチャーで開発 林栄一さん（@essence_s） NLPやファシリテーションを使ったAgile導入。すくすくスクラム名づけ親 西村直人さん（@nawoto） アジャイルコーチ。スクラム道
より良いテスト駆動開発を行うためのチートシートの紹介
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろう
自動テストのfixtureを効率的に管理する方法
みなさんこんにちは。@ryuzeeです。 僕がやっている案件(PHP)はもともとテストコードのないレガシーなプロジェクトで、それを改善するためにずっと動作を確認するための結合レベルの自動テストを増やしてきました。 そんな中で、僕のところではどうやってテスト用のfixtureを管理しているか事例として紹介したいと思います。 最初にコアとなるfixtureを用意するみんながたくさんテストを作る前にコアとなるテスト用のfixtureは用意しておきます。 さもないと、みんなが好き勝手にfixtureを作ってしまい、あっという間に混乱に陥ります。 プログラム本体と同様に、DRYの原則で、同じようなテストデータを繰り返し作ってしまうようなことは避けるべきです。 最悪なパターンは、開発機や本番機のデータを引っこ抜いてきて、それをそのままテストデータとしてごっそり使う方法です。 流石に居ないと思いたいです
テスト自動化について5分で分かるまとめ
みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つであるこのプラクティスのみで１冊の本が書けるくらい奥が深い基本的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保
Webアプリでのメール送信テストにはRadish使うといい
一週間以上ブログへのPostが滞っていたのだが、やはり日々の仕事に追われた状況になるとinputしないので、outputできないんだよね。 ということで今日は過去のネタを書くよ。 Webアプリでメールを送信するケースは良くあるんだけど、テストは結構やりづらい。 よくある失敗パターンは下記みたいな感じ。年に数回こういうことするなーって会社でアナウンスされたりする。 大量送信のテストで社内ネットワーク止めた 携帯キャリア宛てに大量のメール送ってSpam扱いされた 自分のメールボックスに大量のテストメールが来て受信に死ぬほど時間がかかる 間違って本物の顧客のテストメール送ってしまった 送信元アドレスも送信先アドレスもダミーなものを使ってインターネット上にメール投げた で、こういう失敗って、環境の作り方で十分保護できる。僕のやっているパターンを書いておく。 Radishで開発端末にSMTPを立てて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
