必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。 自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。 shimobayashi.hatenablog.com 本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。 どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはす
アジャイルを展開していくうえで、現場の開発チームがどう振る舞えばいいかは具体的なテクニックがあるのですが、「偉い人」がどう振る舞うべきかについての情報が少ない気がしたので整理します。なお、僕の元ツイートはこちらからの一連です。 アジャイルを推進している偉い人の中にはスプリントレビューに出るなど、マイクロマネジメントになりがちな人がいる。理由を聞いたら「成果物が、普通に考えたらそうならないでしょ、みたいなものを作るから目を離せない」という。進言したのは「それはチームに考えさせてないからですよ」（続— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2023年2月4日 前提 偉い人、とは 偉い人は関わりすぎてはいけない なぜ、チームは普通に考えないのか 偉い人が関わらないのもダメ 偉い人は適切に関わる 追記 前提 この議論において「そもそも、偉い人やPOやエンジニアに
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
最初に タイトルは煽りで釣りです。ごめんね。 この記事の結論を先に書くと タイトルは釣り スクラムチームは導入当初はスムーズに成功できるように感じる。しかし途中でどこに進むべきかの方角を見失い、迷走してスクラムバットに陥る スクラムに求める効能はベロシティの安定が必須なものが多いのに、ベロシティの安定を意識すらしないままスクラムをやるので、迷走に陥る じゃあどうしてそうなってしまう？という話を個人の経験をもとに書いていこうと思います。 前提として この記事を書いた人はWebサービスの内製開発をしているアプリケーションエンジニアだったので、基本的に内製開発のWebサービスでのスクラム導入について語ります なぜこの記事を書いたか やっとむさんのツイートを見て思いつきました。 スクラムの導入をしたいというチームは数多く見ますが、かなり中途半端なところでスクラムのレベルアップをやめて、小手先の「改
東京都は、都政の構造改革「シン・トセイ」を進める中で、確認と改善のプロセスを絶えず繰り返す「アジャイル」を改革実践のキーワードの一つとしています。 これを都庁内にしっかりと定着させていくため、2022年度から、デジタルサービスの「アジャイル型開発（※）」に取り組んでいます。 この度、これまでの実践の様子や職員たちの気づきなどを記録した「アジャイル型開発プレイブック（※）」を公開しました。ぜひご覧ください！ （※）アジャイル型開発とは、 「顧客にとってより良いものにするために、見直しすることを躊躇しない開発手法のこと。 またそのマインドセット、および価値観のこと。」とされており、 システムの世界では、「迅速かつ柔軟に」開発ができる手法として注目されています。
Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について - yigarashiのブログ
ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。 デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性
【16-E-4】残業ゼロで開発スピードが10倍に！もう元の開発体制には戻れないデンソー流のアジャイル開発Developers Summit
ご好評いただいた本連載も今回で最終回。いつもとは趣向とは変え、竹馬氏がこれまでのインタビューを振り返りながら、未来への展望を綴ります。 一皮むけば高度なコンピュータサイエンスが 今まではインタビュアーとして抑えた感じでやってきましたが、今回は自分のブログ「mizchi's blog」の読者はご存じのような、いつもの感じで行きます。 この連載インタビュー企画の依頼を受けたときの個人的な狙いとして、技術評論社の名前を使って、いつもは会いづらい人に会いに行く口実を作ろう、ということを考えていました。その目的はほぼ達成できたので、関係者諸氏には、とても感謝しています。 ……という個人的なテーマとは別に、僕自身が本連載を通して一貫して表明したい課題感があり、それは「高度なコンピュータサイエンス／プログラミングスキルの現場適用の難しさ」というものです。 僕自身、大学でコンピュータサイエンスを修めたわけ
本田技研工業のマネジャー松本芳宏氏と、同じく本田技研工業でスクラムマスターを務める船戸康弘氏は2019年7月に開催された「Agile Japan 2019」で「ユーザーと共創する 本当に欲しかったサービス～製造業がアジャイルを取り入れた事例～」と題するセッションを通じて、小さく試し、失敗しながら改善に取り組み、現場の役に立つITを、アジャイルを通じて実現した例を紹介した。 「『ホンダさんは自由に新しいことができてうらやましい。うちみたいな固い会社じゃ、とても無理です』といわれることがあるが、現実にはいろんな衝突を経て新しいことに挑戦している」と松本氏は話す。 松本氏らは生産本部の下で、情報システムの運用に当たるIT部門とは別の立場でデジタル化に取り組んでいる。ダッシュボードによる「業務の見える化」の実現やIoT（モノのインターネット）センサーを活用したデータ収集など「現場の困り事、悩み事解
デブサミ2021の登壇内容 チーム開発における原則としてScrumは浸透しつつあります。一方で個人単位の行動管理・タイムマネジメントについては方法論が確立されていない状況があります。今回は、Scrumの原則を個人単位の行動管理に適用した上で、実装事例としてNotionを活用した方法を紹介します。
【資料公開】プロダクトバックログ Deep Dive
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 今年もスクラム実践者の祭典であるRegional Scrum Gathering Tokyoが、2022年1月5日〜7日までの3日間開催されました。 このイベントで「プロダクトバックログ Deep Dive」というタイトルで発表しましたので、資料を公開します。 スクラムガイドでも、プロダクトバックログという単語の登場回数は非常に多く、それだけ重要だということが分かります。 一方で網羅的にまとまっている資料が日本語ではあまり存在しなさそうなので、今回用意してみました。 内容については、過去にこのブログで説明している箇所も多数ありますが、1箇所にまとめたことに意義があるということでご了承ください。 みなさんのお役に立てば幸いです。 内容に関するご意見やフィードバックは、T
書評 『Agile Testing Condensed Japanese Edition』 〜アジャイルテストの一冊目として最適〜｜hgsgtk
Janet GregoryとLisa Crispinによる2019年9月発行の書籍『Agile Testing Condensed』の日本語翻訳版です。アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています！ Janet氏とLisa氏といえばAgile Testing DaysのYouTubeチャネルでも頻繁に登場しAgile Testingについてわかりやすい解説をしてくださってる 本書は訳者まえがきにあるが、著者たちの3冊の本（『Agile Testing: A Practical Guide for Testers and Agile Teams』、『More Agile Testing: Learning Journeys for the Whole Team』そして『Agile Testing Condensed: A Brief Introduction』
ほぼノー知識でスクラム開発の現場に乗り込んで失敗した話を書き記します。 「なぜスクラムは上手くいかないのか」「スクラム開発のアンチパターン」などチームにフォーカスした記事はあれど、個人にフォーカスした失敗談が見当たらなかったので書こうと思いました。 はじめに 大前提として、その現場が悪かったとかスクラム開発が悪いとかそういったネガティブキャンペーンをするつもりではありません。 ウォーターフォールと比較して、継続的にプロダクトを作って完成に近づけていくスクラムのメリットは十分理解しているつもりです。 その中で自分が「あ、無理かも」と感じてしまった理由を記して同じ立場に立ってしまった人の救いになれればいいなと思い記します。 概要 AWSを基盤とするインフラ開発の現場Joinし、スクラムメンバーとしてプロダクトを開発する役目を受けました。 結論から言うと2週間のスプリントでベロシティを上げること
「スクラムフェス仙台」は初心者からエキスパートまでさまざまな参加者が集い、学び、楽しむことができるアジャイルコミュニティの祭典です。ここで登壇したのは、kyon_mm（きょん）氏。スペシャリストになれなくても成長する方法について話しました。全3回。1回目は、kyon_mm氏が勉強に目覚めたきっかけと、転職後に味わった絶望について。 デロイトトーマツコンサルティング合同会社・執行役員のkyon_mm氏 kyon_mm氏：kyon（きょん）と申します。私はソフトウェア開発やアジャイルコーチなど、いろいろな文脈で仕事をしてきたのですが、今日はそこにおけるスキルアップや、学習の仕方をテーマに話していこうかと思っています。 今日の話のベースになっているのは、2015年に仙台で開かれた「レッツゴーデベロッパー」というイベントで話した、「ザ・ジェネラリスト」というものです。「ザ」と付けたのが本当にヤバい
「アジャイル開発ってのに取り組むことになったんだけど、何を読んだらいいの？」という質問を受けたので答えてみた | DevelopersIO
事業開発部の塩谷 (@kwappa) です。 いきなり家庭の私事で恐縮なのですが、今朝出がけに妻からタイトルのような質問を受けました。 そのまま「Slackにリンク投げといてね！」と言い残して出て行ったので（我が家では家庭の連絡にSlackを使っています）、やっきになってぺたぺた貼ったリンクをご紹介しようと思います。 といっても、アジャイル開発の経験がある方ならお馴染みのものばかりです。「あーなるほど」と納得していただけたら幸いですし、「これも読んどけ！」という推薦もお待ちしています。 「まずはこれを10回読む」 …と最初に貼ったのが「アジャイルソフトウェア開発宣言」 (Agile Manifesto)です。すべての始まりですから、ここを読まなければ始まりません。ほんとうは「100回読む」と書きたかったのですが、のっけからハードルは上がるし感じ悪いしなので自重しておきました。 しかし、表面
この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識） 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
退職エントリを書くつもりはあまり無かったけど、はてブに退職エントリが多くあがっていて書く気力が高まったので書いてみた。 DMMに入社した理由 去年の5月に入社しました。 大きな企業の便利な社内ツール・サービスを見たい 色んな種類のサービスの裏側を見たい Railsアプリをゼロから作る機会 仕事で rails new できる プロジェクト初期からレビューできる あたりに魅力を感じて内定を承諾した。 DMMでやっていたこと とあるサービスのリプレイス案件*1のサーバサイドエンジニアを担当していた。 既存のデプロイ方法の修正 AWSのアーキテクチャ設計 APIや管理画面をRailsで実装 RubyやRailsに関するレビュー（他メンバーがあまりRailsに慣れていなかった） Terraformを使ったインフラ業 死活監視の設定 タスク管理 この案件、入社して2ヶ月でデスマの気配を感じていた。 自
FigmaとNotionでUML・経理処理・デザインまでAll in oneな仕様書を書いて、更新・共有を楽にしてる話 - Qiita
前提としての情報 単に「Figmaで要件定義のためのUMLも、外部設計のためのデザインも、内部設計のためのERDも全部つくるよ〜〜」という話をすると、ERD書くならデザインツールなんて使わないで、DBMSから自動生成できるツールとか使った方がいいじゃん、みたいな疑問が出るのは重々承知なので、そもそもこの形式に落ち着いた前提事項を書いておきたいと思います。 ご興味がなければ読み飛ばしてください。 筆者の仕事範囲 さて、冒頭で「事業会社でデザイナーとPMの狭間みたいな仕事をしてます」と書きました。キャリアの背景的には受託のPMっぽい仕事（厳密には違うんですが、本旨ではないので割愛します）→事業会社のインハウスデザイナー→現職という感じで、外渉から手を動かす所まで、必要ならなんでもします。 ざっくりいうと、機能の起案をして、経理などの関連部署に相談して、WBS引いて、UML書いて、画面遷移図書い
TL;DR : ひとことでいうと 決定事項になる前に早めに巻き込もう 巻き込むときは、 その意図や相手に期待することを伝えよう 特性を理解して、ちょっとした工夫（最初の一声はチャットなどの非同期コミュニケーションを使う、etc）をしよう たまに遭遇するシーン ソフトウェアプロダクトの企画（プロダクトデザイン、プロダクト設計）を行う人や組織が、 企画の要件や仕様をかっちりと固めてから、エンジニアに渡したほうがいい 、と思っているシーンを見聞きすることがあります。 「重厚なウォーターフォールプロセスを採用しているから」という場合もあると思いますが、 軽量なプロセス下にある Web サービス企業でも、企画と開発で役割分担をしている場合は（程度の大小はあれど）起こってしまう と思っていて、今回はそういったケースを想定しています。 特に、以下のような思いがあるからそうしている、というケースを話題に上
東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた - Agile Journey
「初！都庁職員、アジャイル型開発に参加する」 東京都デジタルサービス局デジタルサービス推進部の公式note（2023年1月公開）には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。 これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では？ 東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。 コロナ禍で浮き彫りになった、「迅速」の重要性 「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発
Scrum Fest Sapporo 2021でプレゼンしました。 私達の愛したDDDを取り戻すための苦悩と挑戦について紹介します。本作品はマリリン・マンソン Rock is dead オマージュ作品となっております。 DDDはその構造上、デザイン思考やリーンスタートアップやディスカバリーといったものを考慮しておらず、デリバリーフェーズを意識した手法になっているのですけど、これはチーム開発のボトルネックを生み出す原因になりがちではないでしょうか？ デリバリーにおいてはドメインを語れる人がいく人かおり、それをベースにそこそこの規模のシステム設計やアプリケーション設計をしていく。その過程でDDDを実践したという経験がつくわけですが、その人に対して、新規事業であったり、若々しい状態の事業のサポートをお願いすると、劣化したDDDのような設計をベースに進めつつ、現場のプログラマーを説得する行為に走る
【資料公開】スプリントプランニング Deep Dive
みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに
株式会社ドリコム 知的ヘンタイ六番勝負「第四戦 LT王者決定戦」 http://recruit.drecom.co.jp/event/event4.htmlRead less
ソフトウエア開発力のさらなる強化へ 及川卓也氏・吉羽龍太郎氏・和田卓人氏がNTT Comの社外技術顧問に就任 - Shines｜ドコモビジネス｜NTTコミュニケーションズ
事業共創プログラム OPEN HUB for Smart World 未来をひらく「コンセプトと社会実装」の実験場 OPEN HUB for Smart Worldは、社会課題を解決し、わたしたちが豊かで幸せになる未来を実現するための新たなコンセプトを創り、社会実装を目指す事業共創の場です
15分以上のデイリースクラム 今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。 デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。 だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。 どうして？ 理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。 プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。 そんな感じ
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
2022年度リクルート エンジニアコース新人研修の講義資料です
【2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何？ 誰向けの記事？ 自己紹介 前提：「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析（プレモーテム） 死亡前死因分析とは？ どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか？ 注意点 まとめ 最後に はじめに これは何？ スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事？ スクラム最初の壁であるベロシティの安定化
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
プロダクト作りにはさまざまな「罠」がある。機能の開発とリリースに集中してしまい、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況のことを「ビルドトラップ」と言い、プロダクトを開発する組織において陥りやすい「罠」の一つだ。なぜこの問題が起こるのか。どうすれば、本質的なプロダクト作りに立ち戻れるのか。『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』の訳者であり、アジャイル開発や組織改革のトレーニングなどを行う専門家、吉羽龍太郎氏が語った。 大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師と
ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA #Forkwell_Library
アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース
アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？ そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
Broken Ownership
Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,
これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏（以下、高橋）：じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏（以下、高木）：ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう（笑）。 高橋：まず、日本人がすごくリファクタリングが嫌いな
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
平尾誠@ARUTEGA.Inc @Makopontass コーディングを外に出すことが増えてきた。 やはり経験値が少ない人の品質管理は大変だと感じつつも、しぶとくピクセルパーフェクトを狙ってくる方に仕事を任せてよかった。 この再現性への執着心がないと伸び代を感じれない。 2020-09-20 00:34:07 吉本 集 / aru inc. @tsuDoi220 いやー、実際そうなんですよねー。 ピクセルパーフェクトに、そもそも拘っていない人に、仕事お願いしたくない。テクニックどうこうより、全然こっちのほうが大事。ほんとに。 後、速度とちゃんと納期守ること。 当たり前のようだけど、意外とね、、、 twitter.com/makopontass/st… 2020-09-20 00:45:27
プロダクトオーナーが最低限守るべき10のこと
みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数です。チェックリストに100個の項目があっても覚えられません。プロダクトバックログに100個の項目があった場合、覚えているのは先頭の方と、気になる項目だけになるでしょう
IT業界の「多重下請け地獄」が横行し続ける真の理由
新型コロナウイルスの感染拡大や、政府による緊急事態宣言などの影響を受けて、多くの企業が中途採用の求人を減らし始めている。IT業界でも今後エンジニアの中途採用の規模縮小が心配される。業界で常態化している多重下請け構造のもとで、業務委託や派遣社員のエンジニアの人数を減らす企業が増えていくことも十分考えられる。 業界の多重下請け構造にはさまざまな問題があるとして、構造改革に取り組んでいるのが、東京都渋谷区に本社がある情報戦略テクノロジーだ。企業の事業部門と直接ビジネスをする「0次請け」と、エンジニアのスキルシートの統一化を進めている。 同社の高井淳社長は、IT業界の1次請けから3次請けまでのビジネスを経験。「構造改革をしなければ日本のソフトウェア開発の技術向上も、エンジニアの育成もできない」と訴える。日本のIT業界の課題と、高井社長が取り組む改革についてのインタビューを前後編の2回にわたってお伝
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームトポロジー を読んだ - 下林明正のブログ
アジャイルで「偉い人」はどう振る舞うべきか - arclamp
だからお前のチームはスクラム導入で満足して、いつまでたっても生産性が上がらないんだよ
「アジャイル型開発プレイブック」を公開しました –
ベロシティを上手く使って 技術的負債を計画的に解消する
最終回 今生きるプログラマーが、この仕事をあこがれのものにする | gihyo.jp
「俺たちが必死で稼いだ1円、1秒をITに使わせない」とまで言われた ホンダの挑戦
Atomic Scrum 個人の生産性を最大化する方法
スクラム開発の現場にJoinして失敗した俺が悪い話 - Qiita
「プログラマーとして食っていける気がしない」 圧倒的実力差に絶望も味わった、きょん氏のキャリア変遷
Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
DMMを退職しました - アジャイルSEの憂鬱
プロダクト企画にエンジニアを早めに巻き込む（嫌がられずに協力を得る方法） - ykmc09 blog
DDD is dead. God is in Twitter #scrumsapporo
Webアプリケーションは難しい
毎朝15分以上のデイリースクラムをしてる - Mitsuyuki.Shiiba
スプリントの属人性を減らしたらベロシティが安定した話 - Commune Engineer Blog
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
(翻訳) ストーリーポイント再考 - forest book
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
Agile and Requirement : アジャイルな要件定義について考える
スクラムにおける朝会の目的は進捗共有ではないよという話 - Qiita
「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方
チームのベロシティを上げる vs. 安定させる - yigarashiのブログ
ピクセルパーフェクトは必要なのか？ HTMLコーダーの考え方まとめ