【資料公開】目標設定の基本
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
新規事業とアジャイル
みなさんこんにちは。@ryuzeeです。 新刊『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』が10月26日に発売になりますので、よろしくお願いします。 先日、プライベートで新規事業とアジャイルに関する短いセッションをしましたので、そのときの資料を共有します （本当は1時間かかるものをかなり縮めたダイジェスト版です）。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）何が分からないのかすら分からないこともある。過度に詳細な計画にしない適切な問題を扱っているか、顧客はいるかが重要顧客が関心を持つのは、自分の課題の解決であり、ソリューションそのものではない仮説と検証の繰り返し急いでたくさん作らない。機能の多さは成功につながらない投資モデルを変える(100打数10安打1ホームランなら上等)アジャイルとはフィードバックサイクルの集合体最初から人が多すぎると
プロダクトオーナーが最低限守るべき10のこと
みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数です。チェックリストに100個の項目があっても覚えられません。プロダクトバックログに100個の項目があった場合、覚えているのは先頭の方と、気になる項目だけになるでしょう
スプリントレビューの進め方
1. スプリントレビューの目的まず最初にスプリントレビューの目的を再確認しておきましょう。 スクラムガイドの2020年版では、スプリントレビューを以下のように定義しています。 スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。 スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。 スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。 この情報に基づいて、参加者は次にやるべきことに協力して取り組む。 新たな機会に見合うようにプロダクトバックログを調整することもある。 スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。 ざっくりまとめる
プロダクトバックログ項目の明確化の必要性 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 プロダクトバックログ項目からタスクにうまく分割できないので、あればそのコツが知りたいと@riskriskさんからリクエストを頂いたので解説したいと思います。 まずは以下の図を見てください。 これはスクラムにおいて、プロダクトバックログからスプリントバックログへの流れを会議体とともに示したものです（パワーポイント版はこちら）。 実はほぼこの中に全て答えがあります。 まずプロダクトバックログ項目（ストーリーなど）からタスクにうまく落とせない場合は、以下のようなことが原因として考えられます。 そもそもなんのためにそのプロダクトバックログ項目があるのか分からないプロダクトバックログ項目の内容が曖昧または抽象的すぎて、作るべきものが分からない。または人によって著しく成果物のイメージが異なるプロダクトバックログ項目に受け入れ条件がないため、何ができたらそのバッ
【書籍発売のお知らせ】レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
著者／訳者：David Scott Bernstein、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士出版社：オライリージャパン発売日：2019-09-18単行本（ソフトカバー）：300ページISBN-13：9784873118864ASIN：4873118867 本書は、David Scott Bernstein氏の『Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software』の全訳です。 著者のDavidはMicrosoftやIBMを含むさまざまな企業での開発経験をバックグラウンドに持つ、特にアジャイル開発における開発者向けの教育に情熱を注いでいる独立のトレーナー/コンサルタントです。 日本にも、2019年のDevOpsDays Tokyoでの基調講演やScrum Allianc
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
オープンソースのAPI Gateway「Kong」
全国100万人のモノリシック巨大アプリケーションに苦しむみなさんこんにちは。 世の中猫も杓子もマイクロサービスだ!!とかAPIだ!!とか言っていますが、実際にマイクロサービス環境にしようとすると、どのようにしてAPIのサービスを取りまとめるかが課題になります。 一般的には以下のようなやり方になります。 複数のサービスに分散しているAPIを統合するゲートウェイを用意するそのゲートウェイでは以下のようなことをおこなうクライアントからのアクセスのシングルエンドポイントの役目を果たすAPIの実体へのルーティング認証アクセス記録の収集スロットリング(過度なアクセスの抑止)実体がダウンしている場合のデグレーションこのようなAPIゲートウェイの機能は既にAWSではAmazon API Gatewayとして提供されていますが、オープンソースでもいくつかのプロダクトがあります。今回はそのうち一番開発が活発そ
Hashicorpの新プロダクト「Otto」を試してみた
全国1000万人の大トロ好きのみなさんこんにちは。 Hashicorpから新たにOttoと呼ばれるプロダクトがリリースされました。 OttoはVagrantの後継となるもので、開発からデプロイまで一気通貫で行うことができるソリューションでマイクロサービスでの活用も考慮されて作られているということで早速試してみました。 軽く触った印象としては、Vagrant、Packer、Terraform、ConsulなどいままでHashicorpが提供してきたツールを組み合わせて一気通貫で操作できるようになった、と考えるとわかりやすそうです。 インストール https://ottoproject.io/downloads.html にアクセスして自分の環境にあったバイナリをダウンロードして展開します。展開したら実行できるようにPATHに追加します。 僕の場合はアーカイブを~/tools/otto/に配置
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 on AWSな話
全国2000人のSensuファンのみなさん、こんにちは。 ということで、すでにご存知の方も多いような気もしますが、6月20日(金)にJAWSUG東京第22回勉強会で話してきたので、スライド晒しておきます。 ちなみにこのスライドには書いてないけど、覚えておくと得かもしれないこととして SensuではClient側からServer側にKeepaliveの通知を送り続け、一定時間この通知がこない場合はServer側で死活監視エラーとみなすようになっている。したがって各サーバの時間はntpとかでちゃんと合わせておかないといけないCommunity Pluginを使うのはOKだが、レポジトリが大きすぎかつ若干取り扱いが雑なので、ChefのCookbookでremote_fileとかで自動で取ってくるようにすると、たまにハマるかもしれない。一度ローカルにコピーして安定版を自分でアップロードするようにし
継続的デリバリーとは何か？
みなさんこんにちは。@ryuzeeです。 継続的デリバリー（Continuous Delivery）の定義を改めて整理してみました。 まず1つめの定義は以下の通りです。 Continuous DeliveryとはリリースのスケジュールをIT部門が握るのではなく、ビジネス部門が握るということだ。 Continuous Deliveryを実装するということは、全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じて、秒とか分の時間で利用者にリリース可能である、ということだ。 Jez Humble Continuous Deliveryとは何か？ユーザーとプロジェクトチーム（顧客やプロダクトオーナーも含む）の間に固いフィードバックループを作ることは、結局のところ、試験的な変更や新し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
