This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか?」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか? そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
2021 / 2020 / 2019 JavaScriptライブラリのトレンドを紹介しているbestofjs.orgが、2020年に最もホットであったJavaScriptライブラリのランキングを発表しました。 選考基準は現在のスター数ではなく、『2020年の一年間で増えたスターの数』です。 過去流行っていたけど落ち目となった技術は出てこないので、最近注目されている技術がわかります。 ちなみに2016年の総合ランキング1位はVue.js、2017年の総合ランキング1位はVue.js、2018年の総合ランキング1位はVue.js、2019年の総合ランキング1位はVue.jsです。 以下は2020年のランキング、2020 JavaScript Rising Starsの日本語訳です。 JavaScript ライジングスター 2020 5回目のJavaScript ライジングスターにようこそ! こ
EngineeringBuilding On-Call Culture at GitHubGitHub’s engineering group moved from a monolithic, hero-based on-call rotation to a more balanced on-call culture in order to increase our on-call expertise and improve the experience for our customers. As GitHub grows in size and our product offerings grow in number and complexity, we need to constantly evolve our on-call strategy so we can continue t
I have been studying up on, working with, and implementing microservice architectures (MSA) for the last few years. One thing that struck me the other day is that I work with the microservices in MSAs as if they are loosely coupled and can be formed to work cohesively. Ok that works. However, in my brain at least, each microservice is on its own with that application architecture. If I reuse a mic
今でこそクラウドやアレクサ、ビデオやミュージックといった多角的なビジネスを展開するアマゾンだが、もともとはオンラインの小売りであり、依然としてそれはビジネスの大きな部分を占めている。オンラインのコンシューマービジネスは、感謝祭時期のBlack FridayとCyber Mondayに照準を絞って(今はPrime Dayもあるが)、仕入れや配送センター及び実際の配送キャパシティの増強など、数か月前から準備に取り掛かり、その集大成としてこのPeak Periodを執行し、そして12月後半にはオフィスががらがらになる、というのが伝統芸である。9月後半か10月前半くらいになると、既に青色吐息の社員を見かけることも少なくない(そんな社員のためにお菓子やらが夕方になるとカートで運ばれてくる。残念ながら今年はなかったが)。 アマゾンの強さの一つの理由は、私はこうしたピークシーズンに向けた過酷なOpera
Paul Graham のエッセイを読んで、自分なりにまとめたものです。今でも見返すと示唆があるので、読みやすくなるようブログでも書いておくことにしました。Paul Graham のエッセイの翻訳はこちらでリストになっています。ぜひ原文も当たってください(文末に参照先を書いています)。 昔書いたスライドからの転載です。 Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham からのアドバイス) from Takaaki Umada www.slideshare.net 原則 Make something people want 「人々の欲しいと思うものを作ろう」 スタートアップにとって一番難しいのは、人々の欲しいと思うものを作れるかどうかである(二番目は資金調達)。人々の欲しいと思うものを作れるま
こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口(@hgsgtk)です。 昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 少人数でのアジャイル開発への取り組み実例 (一歩目の踏みだし方) | 詳説 | July Tech Festa 2020 登壇レポート アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。 一般的なアジャイ
2020年2月から開始した47機関のチーム移籍活動は、デロイトトーマツコンサルティング合同会社(以下DTC)への移籍という形をもって終了となりました。
『プロダクトマネジメント』原題: Escaping The Build Trap を読みました。 良書でした。同時にビルドトラップを生み出す組織構造にも興味が沸いてきました。 翻訳は安心と信頼の Ryuzee さん。 -> Ryuzee.com プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける 作者:Melissa Perri 発売日: 2020/10/26 メディア: 単行本(ソフトカバー) 原題にも書かれている ”ビルドトラップ” とは、プロダクトを作ることが目的化している状態のこと。 一見プロダクトを作るということは正しいように見える。だってプロダクトで儲けてるんだし。 でもビジネスの目的はプロダクトを作ることではなく儲けること。 儲けるということは顧客が対価を支払うということになる。 ここでプロダクトが差し出す対価とは顧客の問題がプロダクトによって解決され流ことにな
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
もう10年以上も前のことだが、新入社員の採用面接でお会いした、忘れられない一人の女子学生がいる。 彼女はノックもせずいきなり部屋に入ると、何も言わず席に座り、下を向いてそのまま固まってしまった。 最終の役員面接となると、やはり緊張で上手く話せなくなってしまう学生もいるので、その事自体は珍しいことではない。 しかし彼女は余りにも極端だった。 「こんにちは。今日は面接に来てくださってありがとうございます。よろしくお願いします。」 「・・・」 「緊張する必要なんか、全くありません。少しお話をお聞きすることはできそうですか?」 「・・・」 わずかに見える鼻の頭や耳まで真っ赤になってしまっていて、今にも泣き出しそうだ。 顔を上げられず、小さく固まってしまった肩が震えている。 もはや面接どこではない空気感だ。 とはいえ彼女もここまで試験を進み、しかも履歴書からもとても優秀な学生であることは十分わかる。
なぜSpotifyはOKRをやめた?アジャイル組織に最適な目標管理「Spotify Rhythm」とは こんにちは、加藤章太朗(@katoshow)です。 前回のnoteでは、自律分散型の組織の1形態である「アジャイル組織」について説明しました。 今回は、アジャイル組織の代表Spotifyが採用する目標管理のフレームワーク(戦略フレームワーク)についてお伝えします。 Spotifyでは、2014年まではOKRを採用していました。Googleなどで大きな成果を上げたOKRは、日本でも昨今導入が進んでいます。しかし、SpotifyはOKRをやめ、Spotify Rhythm(スポティファイリズム)という独自の目標管理フレームワーク(戦略フレームワーク)に移行しました。 SpotifyがなぜOKRをやめたのか?そしてSpotify Rhythmとはどのようなものか?について説明していきます。 ※
最近読んだ「プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける」という本から、ビルドトラップに思い当たる節があったので少し当時のことを思い出してみました。 ビルドトラップとは、機能を作ることばかりに集中してしまう状態のことで、本書の冒頭ではこのように説明されています。 ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。私が人生で一番ビルドトラップの深いところにはまっていたのは、2社目に転職したばかりの頃でした。そしてその時の記憶を紐解くと、設定されていたKPIのせいでビルドトラップから逃れられなくなっていたのだと気づきました。 悪いKPIの王道私の当時の担当プロダクトは、当時所属していた会社の公式アプリでした。私が入社した2013年の時点で、数百万のダウンロードがありました。 モバイルアプリの典型的な悪いKPIの代
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く