【資料公開】プロダクトマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか？」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい
【資料公開】目標設定の基本
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
【資料公開】30分で分かった気になるチームトポロジー
みなさんこんにちは。@ryuzeeです。 2022年3月16日に「チームトポロジーを成功させる実践方法の探求」というイベントで登壇した際の資料を公開します。 セッション内容は、書籍の内容をかいつまんでまとめたものになっており、とりあえずチーム内や社内でチームトポロジーの概要をさくっと押さえるのに使える資料になっていると思います。 スライドを見て興味を持った場合は、是非書籍をご覧ください。紙とKindle版の双方が発売されています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632
【資料公開】マネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました（笑）。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。
【資料公開】エンジニアリングマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。 内容に関するご意見やフィードバックは、Twitter: @ryuzee までお知らせください。 スライドを見て興味を持たれた方は、ぜひ書籍『エンジニアリングマネージャーのしごと』を読んでいただければと思います。 それでは。 エンジニアリングマネージャー
基礎からわかる内製化
みなさんこんにちは。@ryuzeeです。 2022年7月6-7日のGoogle Cloud 内製化 Dayの1日目で光栄にも特別講演をさせていただきました。 資料については、イベントページにすでに掲載されていますのでご案内します（このページにアクセスして、「公開資料」の下にある「特別講演」をクリックしてください）。 なぜ内製か？ 今の世の中はソフトウェアが企業の競争力の源泉になっていますが、そこで必要なのは、「素早く」「頻繁に」「安定的に」価値を届けること、つまり安定した「価値のフロー」の実現です。 ソフトウェアの構築は知的労働であり、実際の作り手はチームです（マネージャーや管理者、経営者ではありません）。 したがって、企業としては、安定した「価値のフロー」を実現できるチームを手にいれる必要があります。 安定したフローを実現するためには、専任が必要です。複数のプロダクトやプロジェクトを同時
要件定義や設計だけを行うスプリント、テストだけを行うスプリントというのはダメですか？
新規プロダクトの場合は、最初のスプリントの開始前に、スプリント0と呼ばれる助走期間をとってビジョンを明確化したり、初期の要件を収集したり、アーキテクチャを検討したりすることがあります。これについては時間を限定して実施する分には構いません。準備不足で決まっていないままに進めると、スプリントが空回りするためです。 一方で、通常のスプリントに入った場合には、「動作するソフトウェア」が完成しないスプリント、特に設計だけのスプリントは絶対に避けなければいけません。このようにしてしまうと、後続のスプリントの計画が自動的に決まってしまうのと、動作するソフトウェアの製造量の予測ができなくなるからです（設計のベロシティとは何？ということです）。 もちろん何も要件が決まっていないと開発できないのも事実なので、次のスプリントで作るものの要件については前のスプリント完了までに決っている必要がありますが、このとき大
新規事業とアジャイル
みなさんこんにちは。@ryuzeeです。 新刊『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』が10月26日に発売になりますので、よろしくお願いします。 先日、プライベートで新規事業とアジャイルに関する短いセッションをしましたので、そのときの資料を共有します （本当は1時間かかるものをかなり縮めたダイジェスト版です）。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）何が分からないのかすら分からないこともある。過度に詳細な計画にしない適切な問題を扱っているか、顧客はいるかが重要顧客が関心を持つのは、自分の課題の解決であり、ソリューションそのものではない仮説と検証の繰り返し急いでたくさん作らない。機能の多さは成功につながらない投資モデルを変える(100打数10安打1ホームランなら上等)アジャイルとはフィードバックサイクルの集合体最初から人が多すぎると
スクラムが失敗する理由を5つの観点で見てみる
みなさんこんにちは。@ryuzeeです。 Joseph Pelrine氏とJiri Lundak氏の「Why Scrum Projects Fail」が良い記事なので抜粋・意訳にてご紹介します。 アジャイルやスクラムの導入支援をしていると必然的に組織改革や人事改革にたどりつくことが多いのですが、その理由は以下の失敗の理由を見れば明らかです。 もちろん以下のどれにも該当しない現場は滅多にお目にかかれず、少なからず失敗の原因になりうる要因が存在しています。 問題はその要因を「決まってしまっている仕方のないもの」として諦めるか、「カイゼンを繰り返してより良くしていく」活動をするかにかかっています。 感情面個人の対立混乱規律がない破壊的な振る舞い無気力恐れ支配反感・嫌悪過剰な優越感無視立場を決めるぬるま湯無関心文化的側面マイクロマネジメントミニウォーターフォール責任追及詳細な報告チームの決定を覆す
スクラムイベントに出席しない優秀で不可欠な（？）エンジニアをどう扱うか
みなさんこんにちは。@ryuzeeです。 スクラムマスター用のロールプレイのお題をTwitterに書いたら、多くの方から「自分ならこうする」という案を頂いたので共有します。 今回のお題は、以下のものです。 あなたならどうするシリーズw 『あるメンバーはデイリースクラムの時間に出社せず、ほかのイベントでも内職したり別のミーティングでどこかに行ってしまうことがしばしばです。一方で技術的には非常に優秀で、現在の速度で開発する上では不可欠な存在です。スクラムマスターとしてどうしますか？』 — Ryutaro YOSHIBA (@ryuzee) January 1, 2019その他のお題はこちらにあるので、チームで自由に遊んでみてください。 あらかじめ言っておきますが、どの対応が正解というのはありません。 これは、あくまでロールプレイなので、色々なオプションを考えておいて、実際にそのような状況に遭遇
スキルマップ作成のすすめ
チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果：スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます
Scrumプロジェクト開始のベストプラクティス #RSGT2018
みなさんこんにちは。@ryuzeeです。 2018年1月11日から13日まで開催されているRegional Scrum Gathering Tokyo 2018で登壇いたしましたので、資料を公開します。 今回は、実際にスプリント1を開始する前にどのような準備をしておけばよいかがテーマです。 スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。またスプリント中の次以降のスプリントの準備としてプロダクトバックログのリファインメントを実施します。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。 では、これらはどこから出てくるのか、どのように作っていけば良いのか、という話になります。 資
スプリントの期間を長くしたいと思ったら...
みなさんこんにちは。@ryuzeeです。 元記事はLichard Lawrence氏のWhy Longer Sprints Probably Won’t Helpです。 良記事でしたので抜粋・意訳にてご紹介します。 本文に入る前に若干前提事項を補足しておきます。 以下で言っている「スプリント期間を伸ばす」というのは、あるスプリントだけの期間を伸ばすのではなく、スプリントのサイズ自体を変えることです（例：2週間スプリント→4週間スプリント）タイムボックスであることに意味があるので、ご存知の通り「あと1日あれば終わる」とか言ってスプリント期間を延長することは許されませんそしてスプリントの期間は原則固定なので、今回は2週間、次回は4週間、その次は1週間、というのも無しです。ただし変化への対応はもちろん大事。今回はその点に関するお話です コーチとしてよく、「スプリント期間が短すぎるので、XからYに
Impediments（障害事項）への対応
みなさんこんにちは。@ryuzeeです。 Impediment（障害事項・妨害事項）について、海外で良い記事がいくつかあったのでご紹介しましょう。 Recognizing ImpedimentsThe biggest impedimentImpedimentとはスクラムでよく使う単語で、プロジェクトを進めていく上での障害や妨害になる事項のことです。 人的なもの、プロダクトに関するものなど全てを含みます。 例えば以下のようなものが一例になります。 未完了なままの作業情報の不足繰り返しの作業待ち依存先の欠如割り込みバグ官僚主義間違った、もしくは不明瞭なコミュニケーション意思決定がなされない間違った推定時間がたりないパーツがないよく知らない新しい技術 などなど、ほかにもたくさんあります。 当然のことながら、これらの障害事項を把握することは大事ですし、日々の活動の中で優先順位をつけて改善していかな
プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話
みなさんこんにちは。@ryuzeeです。 プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。 プロダクトバックログでよく起こる問題プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。 単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。 選択したプロダクトバックログアイテムの中身に対してプロダクトオーナーと開発チームの理解が違ってしまうそのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必要が出てきてしまい、場合によっては本来の要求が別のものであることが判明するもしくは色々会話をしていたら、当初の想定以上に規模が大きいこ
こんなスクラムには気をつけろ!?
こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで十分だと思っている全体の要件やアーキテクチャを考えずいきなりコードを書く予定できることなのに、「アジャイルだから」と予定しないドキュメントを書かない文化や考え方を変える
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
AWSを退職します
私事ですが、AWS(Amazon Data Services Japan)を10月31日付けで退職いたします。本日が最終出社日でした。 入社したのが2013年4月1日ですので、在籍期間は2年7ヶ月ということになります。 前回転職した時に知り合いはみんなもって半年とか1年と言ってくれたのですが、その期待は裏切ることが出来ました。 在籍期間中は非常に多くの方にお世話になりましたこと厚く御礼申し上げます。 AWSでやったこと 思い返せばAWSで仕事をすることになったのはひょんなキッカケでした。 2012年10月にアジャイル関連の講演をするために、札幌のJava Festa 2012というイベントにお邪魔させていただきました。 その講演会場の控室にいたところ、当時すでにAWSで仕事をしていた旧知の玉川憲さん(いま飛ぶ鳥を落とす勢いのSORACOMの代表ですね)から、日本でAWSのコンサルティング部
Vagrant Fabricで簡単プロビジョニング
全国1億2000万人のVagrantユーザーのみなさんこんばんは。 最近Vagrantの話を書こうとしても、みんな先にかかれてしまうので困っていたのですが、今日はPython製のデプロイツールであるFabricとVagrantを組み合わせて簡単にプロビジョニングする方法を紹介します。 インストール前述の通り、FabricはPython製のデプロイツールで、SSHで対象先に接続してコマンドを発行したりSFTPしてファイルを配置したりといったことが簡単にできるツールです。Rubyでよく使われるCapistranoと同系統のツールです。 インストールは接続先のマシンではなく、接続元のマシンに行います。環境によって様々な方法がありますが、おおよそ以下のどれかでインストールできます。Ubuntuを使っている場合 sudo apt-get install fabric 既にpythonがインストールさ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
