【資料公開】目標設定の基本
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
【資料公開】エンジニアリングマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。 内容に関するご意見やフィードバックは、Twitter: @ryuzee までお知らせください。 スライドを見て興味を持たれた方は、ぜひ書籍『エンジニアリングマネージャーのしごと』を読んでいただければと思います。 それでは。 エンジニアリングマネージャー
【資料公開】スプリントプランニング Deep Dive
みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに
【資料公開】プロダクトバックログ Deep Dive
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 今年もスクラム実践者の祭典であるRegional Scrum Gathering Tokyoが、2022年1月5日〜7日までの3日間開催されました。 このイベントで「プロダクトバックログ Deep Dive」というタイトルで発表しましたので、資料を公開します。 スクラムガイドでも、プロダクトバックログという単語の登場回数は非常に多く、それだけ重要だということが分かります。 一方で網羅的にまとまっている資料が日本語ではあまり存在しなさそうなので、今回用意してみました。 内容については、過去にこのブログで説明している箇所も多数ありますが、1箇所にまとめたことに意義があるということでご了承ください。 みなさんのお役に立てば幸いです。 内容に関するご意見やフィードバックは、T
大規模アジャイルフレームワークの紹介
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
【資料公開】レガシーコードからの脱却
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
【資料公開】Effective Retrospective (効果的なふりかえり)
みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔
採用とか退職とか評価に関するよもやま話
こんにちは。@ryuzeeです。 以前に、採用プロセスを真剣に考えろという話を書きましたが、ちょっと関連する話を書こうと思います。 採用に関するメトリクスを取ろう採用プロセスに真面目に取り組んでいる会社ならやっていると思われますが、採用活動をするにあたってはメトリクスを取ることが望ましいです。特に成長中の組織でたくさんの人を採用したい場合や、ある一定規模の組織でそれは顕著です。取るべきメトリクスには以下のようなものがあるはずです。 総応募者数採用媒体別応募者数エージェント別紹介者数社員の紹介によって応募が来た数自社の採用サイトから応募が来た数各属性で書類選考を通った数各属性で一次面接を通った数各属性で二次面接を通った数 (ここは各社によって何回面接があるか違いますが…)各属性で最終面接を通った数 (同上)プロセスの途中で辞退した数オファーを出した数オファーを受けた数オファーを辞退した数各採
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
DockerのCentOSベースイメージを簡単に作る方法
みなさんこんにちは。@ryuzeeです。 ググるとたくさん出てくるテーマでアレなんですが、これが楽かなと思う方法をご紹介します。 全体像イメージを作る環境自体はVagrant上の仮想マシンを利用する。作成しようとしているOSにあわせておくと良い(バージョンが違っても大丈夫)仮想マシン自体のセットアップはもちろんのこと、Dockerのイメージを作るところまでVagrantのFile ProvisionerとShell Provisonerを使って何度でも同じことができるようにするFile Provisionerはepelのレポジトリを有効にするためだけに使っており、Shell Provisonerでイメージの作成をする作業手順今回作成するのはCentOSのイメージですが、このルートイメージを作成するためにfebootstrapを使います。febootstrapは標準のyumレポジトリには含ま
Packer + Serverspecでテスト済み仮想マシンイメージを自動で生成する
みなさんこんにちは。@ryuzeeです。 Packerを使うと、VagrantやVMware、Amazon EC2用のAMIなどなどのさまざまな仮想マシンのテンプレートを簡単に作成することができるのはご存知の通りです。 一方で作成した仮想マシンのテンプレートが必要な要件を満たしているかどうかは、仮想マシンのテンプレートを作るたびに検査しなければなりません。 ここでは、PackerとServerspecを組み合わせて、仮想マシンのテンプレートを作成する際に、テストも併せておこなう方法について解説します。 前提今回仮想マシンのテンプレートを作成するにあたっては以下の方式で行ないます。 Packer 0.7.2Packerでの仮想マシンの設定ではChef-SoloのProvisionerを利用CookbookはBerkshelfを使って管理する作るテンプレートはDocker用のもの(但し他のもの
5分で分かるDockerのキホン
全国100万人のImmutable Infrastructure職人のみなさんこんにちは。 もう誰も彼もがDockerなので、あんまりブログに書こうという気にもならなかったのですが、知り合いからリクエストを貰ったので、5分くらいで分かるようにかいつまんで概略を説明します。 Dockerとは詳しくは本家サイト見ればだいたい分かる。仮想化技術コンテナ単位でパッケージングVirtualBoxとかと違って高速、オーバーヘッドが少ない。chrootに近い。LXCには依存しなくなっているコンテナごとにIDが振られるコンテナは差分保存なのでロールバックも簡単一回作ればどこでも動く。JavaっぽいDockerfileでコンテナを作成するDockerfileの1行ごとにコンテナIDがフラれる動作環境Linux Kernel 3.8以降 64bit OSMacの場合はVirtualBoxの中で動かす形になる→
Sensuを使って自由度の高い監視システムの構築を行う方法
SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります（公式サイトの記述を整理） シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象）を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubでホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens
DevOpsに関する12のアンチパターン
みなさんこんにちは。@ryuzeeです。 DevOpsGuysというサイトのTwelve DevOps Anti-Patternsという記事が秀逸です。 作者の方に許可を頂き翻訳しましたので公開します。 原文も軽妙なタッチで読みやすいと思いますのでぜひご参照ください。 また本文で様々なスライドや資料へのリンクがありますので、そちらも見ていただくと理解が深まるんじゃないかと思います！ えっとDevOpsを始めたいのかな？おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。 古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。 パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避ける
Vagrant1.1 + vagrant-awsで複数インスタンスを作る方法
※2013/5更新：最新のvagrant-awsの仕様にあわせて修正 Vagrant(1.1)でvagrant-awsを使ってEC2に複数インスタンスをまとめて作ることが可能です。やり方は通常のMultiVMの場合と同じです。 以下は冗長ですが、サンプルのソースです。WebサーバとDBサーバのインスタンスを起動し、それぞれChefサーバに接続してそれぞれ設定されたロールの通りにセットアップします。なお、vagrant-awsをまだインストールしていない場合は vagrant plugin install vagrant-aws としてください。 ちなみに以下のままだと色々問題がありますが、それは後ほど説明します。 # -*- mode: ruby -*- # vi: set ft=ruby : Vagrant.configure("2") do |config| # 共通設定 box_na
foodcriticでChefのcookbookの書き方をチェックする方法
foodcriticはChefのcookbookのためのlintツールで、http://acrmp.github.com/foodcritic/ で公開されています。 cookbookは長い間環境を維持していくために使われるため、可読性が高く誰でも分かるように書いておくことが望ましいのは言うまでもありません。このツールでは標準で45個のルールにしたがってcookbookをチェックすることができます。もちろん自分でルールを新たに追加していくことも可能です。 インストール動作させるには、ruby 1.9.2以降が必要です。インストールはgemでさくっと入ります。gem install foodcritic 実行方法実行方法も簡単です。引数にcookbookの名前を指定すればOKです。foodcritic php その他の実行オプションとしては以下があります。 foodcritic [cookb
書評 入門Chef Solo - Infrastructure as Code
伊藤直也さんがChef Soloの本を書かれたということで早速購入してみました。最近流行りのAmazon Kindle ダイレクト・パブリッシング（KDP）を使って出版されてます。 Chefは結構巨大な仕掛けになっており、はじめて取り組む人はどこから手をつけて良いのか分かりにくかったりします。日本語のリソースは今まではSoftware Designで並河さんらが書いた特集くらいだったと思いますし、色々やろうとするとopscodeのサイトの膨大なリファレンスを読まないといけない状況でした。 この本では、Chefの基本を、Chef Soloを使ったやり方を通じて、平易な日本語で説明しており、とっかかりとして非常に良い本です。簡潔にまとまっているのでとりあえず通読するなら1時間くらいでしょう。書いてある内容は、VagrantやAWSを使えば簡単に試すことが出来ます（オンプレじゃこうはいかない）。
opscodeのphpのcookbookを解説してみる
みなさんお料理頑張ってますか？僕は毎日cookbookのrecipeみながらkitchenでknife使ってChef気分です(意味不明)。 今日はopscodeが提供しているphpのcookbookをみて中身を解説したいと思います。 コードはここです。https://github.com/opscode-cookbooks/php(なお、build-essentialとxmlとmysqlのcookbookに依存性がありますので、それぞれ入手してください) この記事の目的は、標準的なcookbookの構成の把握とopscodeでのcookbookの作り方の紹介とそれを利用したカスタマイズ方法を紹介することです。 ディレクトリ構成まずソースコードのディレクトリ構成をみてみます。当たり前ですが通常のcookbookのディレクトリ構成と同じです。├── CHANGELOG.md ├── CONTR
test-kitchenを使ってChefのレシピを複数環境でテストする方法
test-kitchenはopscodeが提供するChefのレシピをテストするための仕掛けで、Vagrantを使って複数のOSやOSのバージョンを立ち上げレシピをテストすることができる。(Vagrant以外も使える) テストはminitestやcucumberなどを使って記述する。 テストの流れは以下のようになる。 設定ファイルに記載されたOSをVagrantで起動する（既にOSが起動している場合はそのまま利用する。ひな形となるbaseboxが存在しない場合は、設定ファイルに記載された入手元からbaseboxをダウンロードする）Vagrant側とレシピが共用され、レシピが実行されるレシピ実行後、テストが実行されるテストが終了すると、OSの設定が複数あれば次のOSを使ってテストするでは早速設定を行なってみよう。まず１つのレシピをテストする場合だ。 1つのレシピをテストする場合まずトップディレ
ChefのrecipeをJenkinsで継続的インテグレーションする方法
環境構築の自動化のツールとして一番注目されているのがChefです。 Recipeと呼ばれるインストールや設定のためのスクリプトを書いておき、それを使って新しいサーバを速攻で作ったり、Chef Serverを使えば複数のサーバ群に対して環境を一定に保つことが可能です。 ChefのRecipeは単なるrubyのスクリプトです。そしてrecipeでよく起こる問題として以下のようなものがあります。 外部サイトからtarballを取得してインストールしているような場合に、配布元の移転や、新バージョンの公開と旧バージョンの配布停止によって、recipeがコケるphpでよく使われるライブラリの配布形態であるpearのチャンネル情報が追加になったりURLが変更になる。インストールすれるパッケージがバージョンアップされ、依存関係が増えたりする。上記のようなことがあるので、recipeを定常的に動作確認してい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
