【資料公開】Effective Retrospective (効果的なふりかえり)
みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔
【資料公開】スクラムの落とし穴 #RSGT2017
みなさんこんにちは。@ryuzeeです。 2017年1月12日〜13日にかけてスクラムのイベントであるRegional Scrum Gathering Tokyo 2017が開催されました。 その中でスクラムでよく起こる問題やその原因・対策に関するセッションを行いましたので資料を公開いたします。 アジャイルなやり方でプロジェクトをやろうとしたときの「あるある」な失敗をまとめたものとなっていますので、いま何となく上手く行っていない気がする方はセルフチェックとしてもご利用いただけるのではないかと思います。内容に関するご質問やご要望がありましたら是非Twitterなどで気軽にお寄せください。 それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔泳社発売日：2020-05-2
プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話
みなさんこんにちは。@ryuzeeです。 プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。 プロダクトバックログでよく起こる問題プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。 単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。 選択したプロダクトバックログアイテムの中身に対してプロダクトオーナーと開発チームの理解が違ってしまうそのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必要が出てきてしまい、場合によっては本来の要求が別のものであることが判明するもしくは色々会話をしていたら、当初の想定以上に規模が大きいこ
テストエンジニアの面接の際にするとよい20の質問
みなさんこんにちは。@ryuzeeです。 DZoneという海外のサイトで “The 20 Best Software Tester Interview Questions” (テストエンジニアの採用面接の際にすると良い20個の質問)がまとまっていたので紹介します。 ここにあがっている質問を必ずすべきかという話ではありませんし、完全な網羅性があるわけでもありません(カバレッジの話やブラックボックス・ホワイトボックスの話のような基礎的な質問も入っていないです)。 一方で、ある程度の規模になった組織においては、採用面接の質を向上させるために自分たちの組織で共通の質問集のようなものを用意しておくのはベストプラクティスの1つと言えます。 もちろん一度作ったらそれで終わりではなく、新しい質問を追加したり、いろいろな候補者から期待と違う回答があった場合には質問自体を見直すといったことも必要になってきます
Amazon Elasticsearch Serviceを使ったログ収集基盤の構成を考えてみた
みなさんこんにちは。@ryuzeeです。 6月10日にAmazon Web Services企業導入ガイドブックが発売になっていますのでよろしくお願いします。 さて今回はAWS上でログ収集と分析をする際に、Amazon Elasticsearch Serviceを使う前提とした場合だとどのような構成案がありそうかいくつか考えてみたのでご紹介します。 なお、検討の材料にしている全体の構成としては、複数のVPC(またはAWSアカウント)があって、さらにオンプレ側とDirect ConnectやInternet VPNで接続しているような、よくあるそれなりの規模の構成になります。 各VPCの中には複数のサブネットがあり、そのうちのいくつかはプライベートサブネットに分かれているものとします(個人的にはインターネットゲートウェイの有無しか違いがないので、プライベートサブネットあまり作りたくない)。
発売のお知らせ：アジャイルコーチの道具箱 - 見える化の実例集
こんにちは。@ryuzeeです。 既にご存知の方も多いと思いますが、昨日4月13日に新刊の「アジャイルコーチの道具箱 - 見える化の実例集」(Jimmy Janlén著、原田騎郎・吉羽龍太郎・川口恭伸・高江洲睦・佐藤竜也訳)が発売になりましたのでお知らせです。なお、こちらの書籍はLeanpubでの電子書籍(PDF)形式のみでの販売です。 本書の内容と特徴は以下のとおりです。 本書は、仕事の見える化を進める際に役立つ方法を図と説明つきで96パターン紹介する書籍です。全体で124ページで、各パターンを1ページあたり1つずつ紹介しています。通読するというよりはパラパラと見ながら気になるパターンを探すとよいと思います「見えないものは改善できない」というのがカンバンなどの見える化に共通する基本的な考えです。そして見えるようにした後の課題として、どうやってもっと分かりやすくするか、どうやって毎日維持す
物理カンバンを作るときに用意しておきたい道具10選
みなさんこんにちは。@ryuzeeです。 今日は物理カンバンを作るときに役立つ道具を10種類紹介します。なお、実際のカンバンの例については、拙訳：アジャイルコーチの道具箱 – 見える化の実例集も参照してみてください。 1. 付箋紙 (3Mの強粘着を強く推奨) 当然のことながら物理カンバンを作るときに一番よく使うのが付箋紙です。 剥がれてなくなってしまってはまずいので強粘着を使うようにしてください。おすすめは当然のことながら3Mのものです。 なお、余談ですが、3Mの付箋紙だけを「ポスト・イット」と呼びます。 サイズは自分のボードに合わせれば良いのですが、よく使われるのは、75ミリの正方形です。なお、パックで買うと色々な色が含まれていますが、勿体無いからといって全色を闇雲に使わないようにします。 一般的には通常のタスクを黄色に、緊急をピンクに、といった形で色別に用途を定義しておいてください。で
【資料公開】Chef ベーシックトレーニング
みなさんこんにちは。@ryuzeeです。 これから新たにChefを学ぶ人向けに非常に基本的なトレーニングの資料を作ったので公開します。 資料の構成は以下のとおりです。 まずDevOpsの文脈から自動化が必要な背景を説明Infrastructure as Codeについての利点を説明ChefのアーキテクチャChefの用語解説Vagrantで仮想マシンを2台使った一番単純なハンズオン(boxも用意済み)Serverspecを使ったCookbookのテストの書き方(VirtualBoxの仮想マシンの中でDockerを使っています)その他なお、2-3時間でさくっと触りながら全体像を掴むことを目的にしているので、網羅性はありません。 ハンズオン用のVagrantのboxには、あらかじめ、Chef DK(Development Kit)、Dockerなどが含まれており、すぐに触れると思います(ただしb
RACIマトリクスを使ってスクラムでの責任分担を見える化する
こんにちは。@ryuzeeです。 開発プロジェクトを進めるときには、ご存知の通り多くの人が関わります。一方で以前から何度か書いているようにいきなり人が集まっただけの段階だと、まだ組織やチームとしてはうまく機能せずさまざまな混乱が起こることになります。 たとえばスクラムを採用した場合で、かつスクラムに関する経験があまりない状況の場合、それぞれが持つロールを十分に果たせなかったり、そもそもどんな責任を持つべきなのかも分からずに声の大きい人の言いなりになったり、上司や外部からのコントロールを受けすぎてしまったりといった混乱も起こります。 そこで、初期の形成期や混乱期を早めに終わらせるために、それぞれの役割が持つ責任を見える化するのをお勧めします。（混乱した現場でこれをやると、想像以上に全員の認識が違うことがよく分かります） 以下の表はRACI（レイシー）マトリクスと呼ばれるものです。縦軸にタスク
採用とか退職とか評価に関するよもやま話
こんにちは。@ryuzeeです。 以前に、採用プロセスを真剣に考えろという話を書きましたが、ちょっと関連する話を書こうと思います。 採用に関するメトリクスを取ろう採用プロセスに真面目に取り組んでいる会社ならやっていると思われますが、採用活動をするにあたってはメトリクスを取ることが望ましいです。特に成長中の組織でたくさんの人を採用したい場合や、ある一定規模の組織でそれは顕著です。取るべきメトリクスには以下のようなものがあるはずです。 総応募者数採用媒体別応募者数エージェント別紹介者数社員の紹介によって応募が来た数自社の採用サイトから応募が来た数各属性で書類選考を通った数各属性で一次面接を通った数各属性で二次面接を通った数 (ここは各社によって何回面接があるか違いますが…)各属性で最終面接を通った数 (同上)プロセスの途中で辞退した数オファーを出した数オファーを受けた数オファーを辞退した数各採
こんなスクラムには気をつけろ!?
こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで十分だと思っている全体の要件やアーキテクチャを考えずいきなりコードを書く予定できることなのに、「アジャイルだから」と予定しないドキュメントを書かない文化や考え方を変える
チームにスキルが足りない!? その時どうする?
こんにちは。ryuzeeです。 先日、スキルマップ作成のすすめという記事を書きましたが、それに関してオンライン上で色々議論になりました。 せっかくですので、その内容を共有します。 まず、おさらいですが、スキルマップとは以下のようなものです。横軸にプロジェクトで必要となる技術、縦軸に名前を入れます。 それぞれの記号は、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というのを指していますがこれはチーム次第です。 このスキルマップを作ることで、「スキルの見える化」「リスクの見える化」「学習速度の向上」が期待できます。 さて、議論になったのは、以下の話です。 チームに足りないスキルセットがあることがわかって、でも期間的にそれを埋めてる余裕がない場合どうする？ スキルの話なのかヒトの話なのか。ジャッジメントしなければならないのは誰なのか。 端的に
【資料公開】DevOpsの基本
こんにちは。@ryuzeeです。 営業でDevOpsの基本の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日本語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の「個別プロセス」の話でしかないので、物理的に一日に10回デプロイボタンが押せても、意思決定から価値化までの時間は長い、ということがありえます。 Build・Measure・Learnの
スキルマップ作成のすすめ
チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果：スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます
人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあらわしたものです。 これによると、チームは以下のようなステップを経て変遷していきます。 形成期とりあえず人が集められた段階でお互いのことを知らない。なぜ集められたのか、自
クラウドエンジニア採用のTIPS
人材流動性の高まりのまっただなかにいる@ryuzeeです。こんにちは。 AWSの中の人がクラウドのエンジニアを採用するにあたっての質問集や見るべきポイントを紹介していたのでご紹介します。 Hiring a Cloud Engineer? Questions to Ask and What You Should Hear これからクラウドベンダーに転職したい人や、クラウドベンダーの中で採用を担当している人はみておくと良いかもしれませんね。 以下参考までに勝手訳です。 クラウドエンジニアを雇いたい場合の質問と聞くべきポイントこのブログポストでは、あなたのスタートアップやスモールビジネスの助けになる経験豊富なクラウドエンジニアを採用する際のTIPSを紹介する。 ここでいう「クラウドエンジニア」とはポジションの説明や肩書ではなく、質や長所を表す言葉として使っている。 この手の人をCTOで雇うか一エ
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】カイゼンの基本
【資料公開】カンバンのキホン
