プリウス開発に見るアジャイル開発要素と今時の進め方：続編 / The Agile Development Elements and Current Approach as Seen in Prius Development: Sequel
弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっている所まで整理できたので解説します。更に、変化の時代、環境変化に対し、ハードウェア開発をどう進めるべきか？ いまどきの取り組みを現場の開発者たちの声と共にお届けいたします。本内容は、スクフェス三河「初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について」の続編という位置付けになります。 / We will introduce passionate and occasionally candid discussions by the developers of our lege
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 本記事ではほぼ90分におよぶセッションの内容を、前編、後編（1）、後編（2）の3本に分けて紹介します（この記事は後編（1）です）。 前編では、子供の頃からプロ
Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ
VTeacher所属のSatomiです。 ※ 本家Miroさんからコメントをいただいたので掲載します！ ミロジャパン高山です。本記事ではMiroについてご紹介頂き誠にありがとうございます。大変参考になります。もし本記事の趣旨にあっていればですが、以下の２つのテンプレートを日本語対応をしましたので、よろしければ、リンクを付与頂けますと嬉しいです。 スクラムボード：https://miro.com/ja/online-scrum-agile-tool/ マインドマップ：https://miro.com/ja/mind-map/ 或る日突然、「100万円のプロモーション予算がついたから急いで作って」と頼まれました。 ※ちなみにプロモーション予算（100万円）に人件費は含まれないそうです。 そして、偉い人から下の画像が送られてきました。 （「4月1日に夢を語る」という PR TIMES の企画だそ
若手から見たリモートワーク時代のチームビルディング | BLOG - DeNA Engineering
2020 年 4 月にコロナの影響による緊急事態宣言が発令されて久しい今日この頃ですが、多くの会社でリモートワークが余儀なくされ働き方が大きく変わりました。 DeNA がリモートワーク可能な体制へと迅速に切り替えていく中で、私自身リモートワークによる業務が9割以上を占めました。私や私の所属するチームだけでなく日本中でも働くことに対する考え方が大きく変わるタイミングだったのではないでしょうか。（DeNAでは緊急事態宣言が発令される前には全社的にリモートワークがすでに可能なレベルにまで整備され、とてもスピーディーにリモートワークへと移行できました。制度や勤務体制など様々な整備をしてくださったことにとても感謝しています。） その中で、私たちがチームのコミュニケーションや課題を改善するためにどう工夫したのかをお伝えすることで読んでくださる方のチームのチームビルディングの一助にして欲しいと願っていま
2023年1月11日より開催された「Regional Scrum Gathering Tokyo 2023」の登壇資料です。 https://2023.scrumgatheringtokyo.org/index.html ----- Visionalのエンジニアリングに関する最新情報はTwitter、ブログで発信しています！📣 ▼Visional Engineering Blog https://engineering.visional.inc/blog/ ▼VISIONAL ENGINEERING Twitter https://twitter.com/VISIONAL_ENG
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
2022/08/04 開発PM勉強会vol.13の登壇資料です。
Cloud Festa 2021 Winter 「デザイナー、データサイエンティスト、 クラウドエンジニア、で実現する共創の世界」 Tsuyoshi Hirayama
すべての社会人に知ってほしい仕事の基礎としてのアジャイル/スクラムの話 / Agile as a work foundation
アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではないでしょうか。 スクラムマスターとして、開発に限らず組織の全員が、アジャイル/スクラムの原則を理解して、実践できるよう支援することは重要な活動です。サイボウズでは、数年前から新卒の全社員（＋希望者は誰でも）向けの基礎研修としてアジャイル/スクラムの話をインプットしています。 こちらのセッションでは、サイボウズ社内で実施している研修（講義）を社外向けに再編成したものをお届けします。アジャイルやスクラムの考え方をベースに、エンジニアに限らず、チームワークを高め、成果を届ける仕事の進め方の基礎となる
弊社は未だにメインフレームの相手をしてCOBOLを書いているような、低技術力・プロマネ力偏重のSIer。 20代の若手SE(笑)である僕自身もウォーターフォールの経験しかなく、社内の99%も同じ。 最近興味があって近くにいる人とアジャイル開発の勉強をしていており、ジェフ・サザーランドの著書ほか何冊か本を読んだ、というだけのただのエンジニアワナビー。 最近近所で絵に描いたようなアジャイル失敗例があって、ちょっと誰かに聞いてほしくて書いてる。 この度、既存システムを刷新するプロジェクト（たぶん１億以上５億未満）をアジャイル開発でやることになり、先月くらいに最初のスプリントがスタートした。 アジャイル導入にはおそらく特に動機がなく、お客さんの偉い人たちが ・最近アジャイル？流行ってるんでしょ ・無限に要件変更できるんでしょ ・アジャイルにすると早く安くできるんでしょ などと仰せになった結果だと聞
2022/9/17 Scrum Fest Mikawaのだらトラックで発表したスライドです。 https://confengine.com/conferences/scrum-fest-mikawa-2022/proposal/17149
はじめに 恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした なぜうまくいかないのか？ これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。 よくあるエンジニア組織の構造 大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています この組織構造の問題点 スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。 スクラムマスターの最も重要な職務である「観察」が行えなくなります。 スクラムマスター自身が観察を行わない場合、各メ
【資料公開】レガシーコードからの脱却
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
スプリント1を始める前にどんな準備をするか
みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。 本稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察してい
フロントエンドと自分のキャリア形成について。このスキルツリーとセットで見るといいかもです。 https://whimsical.com/oPYtoDPyho6uWK1gDmD9e
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（前編）。JaSST'22 Tokyo基調講演
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（前編）。JaSST'22 Tokyo基調講演 Jonathan Rasmusson（ジョナサン・ラスムッソン）氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。 日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」（オーム社,2011）や「初めての自動テスト」（オライリー,2021）、「ユニコーン企業のひみつ」（オライリー,2017）の著者としても有名です。 そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」（JaSST'22 Tokyo）の基調講演に登壇しました。
私はこれまで６年間日本で働いてきましたが、昨年11月にプロフェッショナル・スクラム・トレーナーになってから、日本のスクラムやアジャイル開発の現状と今後の展望についてよく質問を受けるようになりました。そうした質問に触発されて私自身もこのテーマについて掘り下げて調べたり考えたりするようになりましたので、この記事にまとめました。（English version here） スクラムとアジャイル開発の現状 1986年、当時 一橋大学教授であった野中郁次郎氏と同大学の竹内弘高氏は「The New New Product Development Game」(Harvard Business Review) という非常に有名な研究論文を発表しました(1)。この論文は日本企業による新製品開発プロジェクトの成功事例を紹介すると共に、これらのプロジェクトに共通する特徴として「自己組織化されたチーム」「開発フェ
忙しい人向けダイジェストをこちらに用意しました。 https://www.agile-studio.jp/post/agile-contracts
差し込みの多いプロダクト開発のスケジュールの精度を上げるためにはバーンアップチャートがおすすめです - スタディサプリ Product Team Blog
こんにちは。 今回は差し込みの多いプロダクト開発におけるスケジュール精度の上げ方として、バーンアップチャートの利用をおすすめしたいと思います。 どんな人に読んでほしいか Product GrowthやEnhancementに携わっているけど、やることが多くて思ったように進捗が管理できない人 ↑のようなProduct Manager(PdM)やProject Manager(PjM)とのコミュニケーションが多いけど、期待に対してうまく動いてくれないことをもどかしく思ってる方 TL;DR 3ヶ月や6ヶ月程度でタイムボックスを切りましょう タイムボックスの中でやりたいことを全部リストアップして見積もりをしましょう 終わったタスクのcloseと新規タスクのリストアップを繰り返すと、自然と「やりたいことが全部できるのかどうか」が見える化します バーンアップチャートとは 下記のようなものです。 図中の
アジャイル手法提唱者が涙ぐんだ「日本発の論文」 | Japan Innovation Review powered by JBpress
新しいソフトウェア開発方法論「アジャイル開発」の一手法である「スクラム」の源流は、日本発の論文にあった。その論文著者の一人、野中郁次郎氏（一橋大学名誉教授、中小企業大学校総長）が語る「アジャイルの真髄」とは何か。（JBpress） 新しいソフトウェア開発手法として、さらに組織変革やビジネスの革新手法として注目を集めている「アジャイル」。「スクラム」はその中で最も普及している具体手法である。その「スクラム」提唱者の一人ジェフ・サザーランド氏が着想を得る原点となったのが、日本企業におけるイノベーションの成功要因を研究した日本発の論文なのだ。 サザーランド氏が、その論文を竹内弘高氏（現ハーバード・ビジネス・スクール教授）とともに執筆した野中郁次郎氏に実際に対面したのは、「スクラム」を提唱してから時間が経った2011年だった。サザーランド氏が着想を得た論文の中核部分は何か、またどのような経緯で対面
2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て
テストの自動化とテスト駆動開発
組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ～テスト駆動開発について～ 4.深めつつ広げる鍵 ～ペアプログラミングについて～ 5.見る夢について
「テストコードを書く？書かない？」ソフトウェアテストのいろんな疑問をテストのプロに聞いてみた - エンジニアHub｜Webエンジニアのキャリアを考える！
「テストコードを書く？書かない？」ソフトウェアテストのいろんな疑問をテストのプロに聞いてみた ソフトウェアテストはソフトの品質を高めるためには、欠かせない工程です。では、テスト・品質保証のプロたちは、どんなことに気をつけて、ソフトウェアテストを実践しているのでしょうか。仕様やスケジュール、テストの設計まで、テストにまつわる疑問を、ソフトウェアの品質保証・テストに特化した企業、SHIFT社のお二人にぶつけてみました。 ソフトウェアへのバグの混入を防ぎ、ソフトウェアの品質を高めるためにはテストの工程が不可欠であり、「どうすれば良いテストを実施できるか」というノウハウもまた非常に重要です。では、テストを突き詰めて追求する、スペシャリストのノウハウとは。 今回はソフトウェアの品質保証・テストに特化した企業であり、テストを前提としたアジャイル体制構築のコンサルティングにも専門性を持つ、株式会社SHI
デンキヤギという会社で『2時間スプリント』が定着してきたので、その話でも書きます。 2時間スプリント？ みなさん、すでにスクラムで開発してますよね！ ぶっちゃけ、スクラムがよくわかってなくても、とりあえずスプリントと称して開発のメリハリをつけるために、1週間なり2週間なりで区間を区切って開発をしていくのは、普通にやってるんじゃないかと思います。 2時間スプリントとは、その期間を2時間にするという話です。 スプリントを超短期サイクルにすること自体は、47機関の人たちがオリジナルだという認識です。このあたりに本家の情報がまとまっています。 kyon-mm.hatenablog.com 2018年に実際に47機関の人たちのチームに入って1時間スプリントで働くという機会があって、それ経て、デンキヤギでもパクって導入しています。本家ではのちのち15分スプリントになっていったらしいんですが、うちはうち
RSGT2020が1/8~10に開催された。 昨年は楽しかったの一言に尽きたが、今年はとにかく考えさせられた。 というのも、私にとってここ2~3年のテーマだった、Agile × マネージャーというドンピシャなキーノートがSahotaさんよりあったためだ。 confengine.com 本記事では、このキーノートに焦点をあてる。 マネージャーを否定してはいけない Sahotaさんのセッションで最も印象に残った言葉が、「組織を変革させるとき、誰も取りこぼしてはいけない」というものだ。 私がBas(LeSSの提唱者)の認定スクラムマスターの研修に参加したとき、どんな役割を今やってますか？と質問された。 私はそのときScrumを推進する人ではあったが、Scrum Masterではなかった。なぜなら、私の行う役割にはエンジニアの評価やエンジニアの採用も入っていたからだ。 そのときはEngineeri
あなたのチームがいくつも未着手の仕事を抱えているとき、どのようにそれらに着手し、そして完了させていったら良いでしょうか？ アジャイルには「始めるのをやめよう。終わらせることを始めよう。」という言葉があります。Tebiki株式会社では、この考え方を基本として、 デスクレスワーカーのための現場教育SaaS「tebiki」を開発しています。 この記事では、新しい仕事を「始める」ことを優先する場合と、仕掛り中の仕事を「終わらせる」ことを優先する場合の比較をしながら、かつては「始める」ことを優先していた Tebiki社が「終わらせる」ことを重視するように変わっていった事例を紹介したいと思います。 仕事が「終わる」とはまず前提として、仕事が「終わる」とは、どういうことでしょうか？たいていの仕事では、まず必要な作業を計画し、それを実行することでその仕事を進めるはずです。 それでは、計画していた作業をひと
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ アジャイルコーチの荒瀬です。 ヤフー、および関連会社のアジャイル開発支援や研修を担当しています。 今回はヤフーのスクラム実践者の学習方法についてお話しします。 イベントや研修の中で、スクラムの勉強方法をいろいろな方から質問されることが多かったので、記事にするとより多くの人の役に立つのではないかと思い執筆することにしました。 また、せっかく書くのであれば、ヤフーの中にいるさまざまなスクラム実践者の話も交えると、経験年数別に、より参考になりそうな書籍、セミナーや研修を紹介できるのではないかと考え、ヤフーのスクラム経験者にも協力いただいています。 スクラムを始めた頃の自身のことを考えながら、こういう記事があるといいのにと思
リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する
社内システムを外注する際のポイント
私分かりませんから全てお願いしますは止めろコンサルも込なら良いが大体は要件定義からだ。つまりお前らは要求定義は出来ている前提だ。なんも分からないから経営層や現場との橋渡しのみなら邪魔だから今すぐSE名乗るの止めて仕事辞めて田舎で畑耕せ。 自社の業務は理解しておけAccessやFilemakerで弄れる程度でSE名乗るならせめて自社業務の流れや種類は把握しておけ。何聞いても現場に確認しますじゃ時間かかるんだよ。なんなら分かるんだ？別に業務フロー寄越せとか言ってないぞ。 要求を理解しておけ割とマジで自分が経営層から何をシステム化してほしいのか分かってない奴が多い。体感5割以上。最近じゃインボイス対応。インボイス対応してください言われて現状や影響箇所は何をしたいか聞いたら「さぁ？」って言う。じゃ、何しにきた。挙句に「そのやり方も提案するのがシステム会社でしょ！」とキレる役職者まで。コンサルは契約
大規模アジャイルフレームワークの紹介
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 Read less
限界集落化するIT業界？ - Qiita
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 － 調査報告書：みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか？ このグラフに当てはまっているでしょうか？ もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer
Developers Summit 2021 Summer［A-1］アジリティを支える品質特性 講演日時: 2021年07月30日（金） 10:00 ～ 10:45 概要: ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏にソフトウェアエンジニアリングを進める力は企業の競争力の源泉となりました。本セッションでは、そのような競争力あるソフトウェアを開発し続ける力を構成する要素を、品質特性等の側面から掘り下げていきたいと考えています。
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
こちらのエントリを読んでいたら、なるほどとてもわかるとなった。そしてこの問題については何らかの解を持っておくべきだと思ったため、ちゃんと考えることにしたのがこのエントリの趣旨である。 上述のエントリには、ソフトウェア開発者がスケジュールのコミットメントを求められた場合、精緻にスケジューリングするためのタスクやスケジュールに余裕を持たせるためのバッファを積むしかなくなり、結果としてソフトウェア開発が遅くなってしまうという話が書かれている。 ソフトウェア開発を実際に行ったことがある人であればこの話には凡そ同意できるとは思うが、それ以外の人には理解に苦しむ話となる。 それゆえに、現代においても「この機能はいつまでにリリースするの？出来なかったらどうするの？」といった質問が横行し、それに対して特に意味のないスケジュールを答えるという虚無の応答が多くのチームでいまも行われている。 ビジネスサイドの仕
このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな（主に単価的な意味で）と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
なぜ変化を起こすのが難しいのか？ - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
Regional Scrum Gathering℠ Tokyo 2023 のクロージングキーノートの資料です。 https://2023.scrumgatheringtokyo.org/index.html
創業105年の星野リゾートでは、他社と差別化を図るために、多くのシステムを独自に作っていたが、旅館運営企業を生業であったため、ほぼ全てのシステムを外部に発注していました。 そのため、近年の技術の進化やビジネスの展開にシステムが追いつかず、システムが企業のボトルネックになっていました。 本セッションでは、非IT企業である星野リゾートが、システム開発の内製化を目指し、どのように毎週リリースするチームを一から構築したのかお話いたします。Read less
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクト開発でドキュメントを書かないとどうなるか
「急いで作って！」と言われたとき、私がまずやること→Miroだけでスクラム
「エセ自己組織化」症候群から脱却し、約束を守るプロフェッショナルなアジャイルチームになるには -アジャイル時代のマネジメント進化論- / #RSGT2023
本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
チームで盛り上げる ファシリテーション
開発速度が速い #とは（LayerX社内資料）
旧来型SIerである弊社でアジャイル（スクラム）が上手く行っていない
デイリースクラムいらなくなくなくなーい！？
日本のソフトウェア企業でよく見るエンジニア組織の構造と、近年推奨されるエンジニア組織の構造について
「たかがJavaScript」のその先 #TECHPLAY
なぜアジャイルは日本で広がらないのか？現状に関する考察と将来の展望
アジャイルと契約 / Agile Contracts
マイクロサービスに次に来るかもしれない言葉について - arclamp
『2時間スプリント』とフルリモートワークなシステム開発 - terurouメモ
マネージャーを否定しない組織をつくる - Unknown Error
始めるのをやめよう。終わらせることを始めよう。
ヤフーのスクラム開発実践者の経験年数ごとの学習方法の紹介
リーダブルコード by DDD / Readable Code by DDD
それはYAGNIか? それとも思考停止か?
スケジュールの見積もりを適当に答えたらコミットメントにされる問題について｜きゅーい / koyo
スクラムでベロシティを安定化するにはどうしたらよいか - 貳佰伍拾陸夜日記
スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている｜s_semiya
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方