前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳

こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張

全てはこのツイートから始まった tokorotenさんのツイートの「大本営」という部分。 「我々は勝っている、我々は価値がある」という常勝の発表を社内向けに繰り返す上層部というニュアンスで大本営が使われているように見えます。 そもそもなぜ「大本営」なる組織が必要になるのでしょうか？ 体感では40人程度の組織までは、大本営なしでも組織は機能します。 ところが100人を超えたあたりで抽象的な問題を扱い、非抽象的な問題に転換するための組織である「大本営」が設立されます。 この記事で書きたいこと なぜ大企業で「大本営」が必要とされるのか？ また「大本営」が「大本営」であるがゆえになぜ途中でつまづくのか？ という話を書いていきたいと思います。 そもそもなぜ「大本営」が存在するのか？ はいここから私の仮説。 大体こちらの通り、一般の人は抽象度が高い問題を抽象度が高いまま扱うことができません。 ではどう

いきなり1,000行越えの差分のあるPRのレビューを依頼するのは今すぐやめろ。何年前の開発スタイルだよ 今回語りたいこと PR/リリース単位の違いの変化を時代と共に語るというのが主旨です この記事を書いた意図 最近開発速度を上げたい的なお話が多く、その際に何回も同じ話を説明することになっているので改めてここに書いておこうと思います。 もう少し膨らまして講義としてまとめた上で、オンボーディング研修の受講動画にしたいですね。 変化をざっくり言うと リリースされる単位は時代が下るごとに細かいサイズでリリースする方向に変化しています。 近年だと平均差分の中央値は（差分行数で比較した場合で）一桁台とかありますね。 古代、いにしえの時代 少数の大企業だけが使える「基幹系業務システム」というピラミッドみたいな代物を、SEという大工のような人たちを多数抱えたごく少数の「大規模SIer」という集団だけが造れ

前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。

はじめに 恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした なぜうまくいかないのか？ これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。 よくあるエンジニア組織の構造 大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています この組織構造の問題点 スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。 スクラムマスターの最も重要な職務である「観察」が行えなくなります。 スクラムマスター自身が観察を行わない場合、各メ

はじめに すまんタイトルは釣りだ。めっちゃ煽った 前提 SaaS企業の内製開発 数十億円調達済みの大きめな会社 スクラム開発をしている 相談者は社内受託感が強まっているのがご不満 ある日相談された 「壁の向こうから締切とプロジェクトが降ってくる」 「プロジェクトが降ってくるのはいいとして、着手前に密室でマネージャーだけで 勘と経験と度胸 ベースで完了目標の日付を決めるのはやめてほしい」 「ほぼ間違いなく、完了目標の日付をオーバーしてしまう。守れない日付をほぼ「締切」として指定しないで欲しい」 「期間とスコープを指定されるのは社内受託感が強い」 という相談を受けました。 前提として SaaSの内製開発をしているWeb企業である スクラム開発をしている 中期的な完了予定の予測を出すことはできない。まだスクラムチームはそのレベルにない 結論から言おう さて僕からの答えはこれです 正確にいうとマネ

最初に タイトルは煽りで釣りです。ごめんね。 この記事の結論を先に書くと タイトルは釣り スクラムチームは導入当初はスムーズに成功できるように感じる。しかし途中でどこに進むべきかの方角を見失い、迷走してスクラムバットに陥る スクラムに求める効能はベロシティの安定が必須なものが多いのに、ベロシティの安定を意識すらしないままスクラムをやるので、迷走に陥る じゃあどうしてそうなってしまう？という話を個人の経験をもとに書いていこうと思います。 前提として この記事を書いた人はWebサービスの内製開発をしているアプリケーションエンジニアだったので、基本的に内製開発のWebサービスでのスクラム導入について語ります なぜこの記事を書いたか やっとむさんのツイートを見て思いつきました。 スクラムの導入をしたいというチームは数多く見ますが、かなり中途半端なところでスクラムのレベルアップをやめて、小手先の「改

これを読んで欲しい人のターゲット像や前提について Web版開発の話をしています ITのソフトウェアエンジニアの話をしています ある程度チームのやり方に対して影響を与えられる権限がある人 マネージャーかメンバーかはあまり気にしないです 「発言するのは自由だが聞き流されるだけ」ならこの記事を読む意味はないです ある程度裁量権があり、ビジネスサイドとも話ができるチームのメンバーを想定しています 作業の流れの前提について チケットがあって 作業者がそれを取って（自分で取るのか他人にアサインされるのかは問わない） PullRequestの形でレビュー依頼をかけてレビュワーがレビューする OKならmergeしてそのうち本番デプロイ 間にQAが入るかもしれないけどそこは問わない 手が遅いとは何か？ ある作業者のサイクルタイムが他の作業者に比べて長いこと 100の大きさの作業があるチケットを渡した際に、ほ