【資料公開】スプリントプランニング Deep Dive
みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに
追記: 振り返りを書いてみました～ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性／可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性／可変性分析 共通性／可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題領域にある概念を見つける（共通性の分析） その流動的要素を洗い出す（可変性の分析） 流動的要素を見ながら、その概念が持つ責務を果たすための抽象的側面（≒インタフェース）を導く 各流動的要素の実装上の観点から、インタフェースが適切かどうかを見極め、補正する オ
モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD
メルカリの社内技術研修 ”DevDojo”の研修資料を公開します！ | メルカリエンジニアリング
この記事は、Mercari Advent Calendar 2022 の23日目の記事になります。 こんにちは！メルカリ Engineering Office チームの@aisakaです。 メルカリのエンジニア組織は、メンバーが相互に学び合い、メンバー自身が自走し、成長できる組織を目指し、「互いに学び合い、成長し合う文化」の醸成を行っています。 こうしたメルカリの「互いに学び合い、成長し合う文化」を体現する仕組みの一つが、社内技術研修「DevDojo」シリーズです。この度、一部のDevDojoシリーズを外部公開することになりましたので、今日のブログではDevDojoとその内容をご紹介します。 DevDojo page in Engineering Website 技術研修DevDojoとは DevDojoは技術開発を学ぶ場として、「Development」と「Dojo(道場)」をかけ合わせ
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
2022年度リクルート エンジニアコース新人研修の講義資料です
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
プロダクト作りにはさまざまな「罠」がある。機能の開発とリリースに集中してしまい、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況のことを「ビルドトラップ」と言い、プロダクトを開発する組織において陥りやすい「罠」の一つだ。なぜこの問題が起こるのか。どうすれば、本質的なプロダクト作りに立ち戻れるのか。『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』の訳者であり、アジャイル開発や組織改革のトレーニングなどを行う専門家、吉羽龍太郎氏が語った。 大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師と
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏（以下、高橋）：じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏（以下、高木）：ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう（笑）。 高橋：まず、日本人がすごくリファクタリングが嫌いな
「このシステムを作ったのは誰だ！ 出て来い！」 そんな切ない怒りの声がIT職場に響き渡る。 前任者、あるいは委託先が作った画面やシステムを変更・移行することになった。ところがあまりにも個性あふれる作りで、しかもドキュメントが残されておらず、どこからどう手をつけていいのか分からない。運用保守担当者は途方に暮れる。 ITシステムの「作り逃げ」は闇の深い問題である。過去に「作り逃げ」されたシステムは、現在の担当者の時間とモチベーションを奪う。いわば「未来の時間泥棒」だ。今回は罪深き「作り逃げ」の問題にメスを入れる。 後のことを考えず構築されたシステムで運用保守担当者が苦労する 筆者にも経験がある。以下のようなシステムを目にしてぼうぜんとしたことが……。 設計書が残されていない（あるいは更新されていない） コーディングが雑（あるいは個性的過ぎる） 他システムとの依存関係が不明 データを変更／抽出で
プロダクトオーナーが最低限守るべき10のこと
みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数です。チェックリストに100個の項目があっても覚えられません。プロダクトバックログに100個の項目があった場合、覚えているのは先頭の方と、気になる項目だけになるでしょう
トヨタはハードウェアアジャイルをどう強みにしているか？ 自動車開発におけるスクラムとモブの実践 - Agile Journey
アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS（トヨタ生産方式）」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。 一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品（ユニット）のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。 そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024（Regional Scrum Gathering T
リクルートでは、エンジニアのパフォーマンスを最大化させるために、開発組織をバリューチェーンとして捉えています。 ツリー構造組織ではないワンチームの開発組織は実際、社内でどのように機能しているのでしょうか。今回は、リクルートが提供するプロダクトの一つである『Airワーク 採用管理』の開発事例を参考に深堀りします。 サービス開発を進めるなかで、190画面もの規模の開発をなんと4カ月で完遂させたというこの事例では、BA、アーキテクト、開発マネジメントがそれぞれ八面六臂の活躍を見せ、圧倒的な「開発速度」を実現させました。 後編では、アーキテクトの西村祐樹さん、開発マネジメントの朴永喆さん、BA（ビジネスアナリスト）の竹下由美さんの御三方を交えて、その裏側をお伺いします。 （前・後編の後編です） ※この記事は株式会社リクルートによるSponsoredContentです。 「ブルックスの法則」を乗り越
講師をつとめる研修の終わりに、参加者からの質問というか相談に答えるようにしている。先日の研修で、ある受講者から「職場の開発をアジャイルにしていきたいがどうしたら良いか」というよくある相談が寄せられた。実はこの手の相談はやりとりに手間がかかる。相手の置いている前提、置かれている状況を的確に把握しなければならない。 私「なぜ、アジャイルに取り組みたいのですか」 まず、狙いを聞かねばならない。Start With Why。ここが分からないと何を聞いて答えても的外れにしかならない。ここで、いきなり「見える化から取り組むといいですよ」「もちろんスクラムですね」と、手段を提示しはじめるような相手だと、相談するのはやめたほうが良い。 受講者「スピード感のある開発をしないといけないと思っています。ユーザーの声を聞いて、それを実装していけるように」 私「なるほど、"何をつくるべきか分からない" ソフトウェア
アジャイル、とりわけスクラム開発をやるときに立ち向かわなければならない壁の話 - freee Developers Hub
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
新型コロナウイルスの接触確認アプリ「COCOA（ココア）」が機能しなかった問題は日本の役所の旧弊を浮き彫りにした。最たる例が金額や仕様に厳格であるがゆえに硬直的な公共調達だ。IT（情報技術）の世界で普及しつつある機動的な開発手法との相性が決定的に悪かった。デジタル時代に対応した行政のアップデートが改めて問われる。スマートフォンのアプリなどは、短いサイクルで機能変更や改修を繰り返すアジャイル開発
今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。 うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ) 前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、
この記事は datatech-jp Advent Calendar 2023 3日目の記事です。 背景・趣旨 筆者（@yuzutas0）は風音屋（@Kazaneya_PR）という会社を経営しており、データ職種の採用・育成に関心を持っています。 複数企業で少ない専門家を奪い合って疲弊するような採用活動ではなく、マーケット全体がより豊かになるような動き方はできないだろうかと模索しています。 1つの実験として、MENTAで「第2新卒が3ヶ月でデータ職種への転職を目指す講座」というトレーニングを提供し、ありがたいことに30名以上の方々に受講いただきました。 ちなみにこの講座は今では風音屋の社内研修になっています。 MENTAの受講者が30名を突破しました🎉 卒業生が風音屋に入社したり、スキルアップして「社内で提案が通るようになった」「現職で活躍できるようになった」という感想もいただいています。
「なんちゃってスクラム」に気づくためのコツ
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、開発手法として、スクラム開発に取り組んでいます。 今回は、「なんちゃってスクラム」に気づくためのコツ、というトピックで話していきたいと思います。 自分自身数年にわたり、他社の方から「スクラム開発やってる？」と聞かれたときに、「なんちゃってスクラムですかねぇ」と言い続けてきました。長らく「なんちゃって」状態だったのですが、最近個人的にそれを脱するタイミングを味わったので、その話をさせてください。 ※ そもそもスクラム開発をよく知らないという方にもわかるように、適宜スクラム開発自体の説明もしていきます。 この記事の対象読者 現在進行形で、スクラム開発をやっているが、なんか違いそうと感じている方 (前職などで)1度スクラム開発をやった経験はあるが、いまいち
なぜリモートでも完全にペアプロで開発するのか？ XPのプラクティスをどこまでも徹底するユーザベースの挑戦を恐れない開発文化 - はてなニュース
ステイホーム期間が続き、開発者がオフィスで顔を突き合わせることも少なくなっています。そんなリモートワークが既定となった状況下でも、ユーザベースのB2B SaaS事業では開発に関わる全てを徹底してペアプログラミングで行っています。 その根幹には、XP（eXtreme Programming）のプロセスを推進することで開発効率を向上させる意図があり、それが多種多様なプログラミング言語やマイクロフロントエンドといった目新しい技術を恐れることなく積極的に採用する開発文化を生み、ひいてはシェアドリーダーシップによる自己組織化されたチームのあり方につながっています。 わずか10人程度だったエンジニア組織を4年で10倍の規模に拡大し、さらに組織と事業の成長を目指すCTOの林尚之さん、スペシャリストとしてFellowの肩書を持つ板倉大輔さん、入社2年目のエンジニア片山景太さんの3人にお話をうかがいました。
1. アジャイルについて マネージャーが知るべき 97 のこと 株式会社アトラクタ 取締役CTOアジャイルコーチ 吉羽龍太郎 (@ryuzee) 2. イントロダクション 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
Miklosは、18年以上のキャリアをもつUXデザイナーのリーダーであり、プロダクトデザインのストラテジストでもあります。フルスペクトルのプロダクトデザイナーとして、ユーザーのニーズ、ビジネス目標、テクニカル面での実現可能性などを考慮しながら、ユーザーの要求を満たし、利益をもたらすプロダクトデザインを目指しています。 UXデザイナーはさまざまなシーンでその活躍が期待されています。たとえば最小限のドキュメントを用いて作業を進めるチーム、リーンスタートアップやアジャイル開発を求められる環境、外部企業とコンサルティング契約を結ぶ場合、または厳しいドキュメント要件を持つ大企業や政府機関のコンサルティング業務など、さまざまな環境が挙げられます。 関わり方や環境の性質（およびそれをすべて結び付けるもの）に関係なく、UXの専門家はデザインに関するアイデア、研究結果、プロジェクトのコンテキストを効果的にさ
日本人はなぜ「マスク」と「PPAP」をやめられないのか：あなたは大丈夫？ 電子メールのセキュリティ対策（1/3 ページ） 2万社以上にセキュリティ対策を強化したメールサービスを提供しているサイバーソリューションズ（東京都港区）のシニアエンジニア 高橋長裕氏が、電子メールのセキュリティ対策について解説する本連載。今回のテーマは「脱PPAP」についてです。 PPAPとは「パスワード付きZIPファイルとパスワードを同じ経路で送信する方法」のこと。「（P）パスワード付きZIP暗号化ファイルを送り、（P）パスワードを送る、（A）暗号化 （P）プロトコル」の頭文字からなる造語で、元JIPDECで現PPAP総研代表の大泰司章氏が命名し、問題提起したのが始まりだといわれています。 政府がPPAP廃止を宣言してから3年。いまだにパスワード付きZIPファイルを送ってくる企業が少なくありません。なぜ日本企業はP
ソフトウェアテストはなぜやるのか誰がやるのかについて考えてみる / why who testing
アジャイル開発研修の中で、ソフトウェアテストってなぜやるの？誰がやるの？って話をしたときの資料です。
あの「日経電子版開発チーム」が内製化とアジャイル開発の成功から6年がたった “その後” を語る！ | Backlogブログ
2013年に「日経電子版」のソフトウェア開発を内製化し、アジャイル開発に切り替えた、日本経済新聞社。開発サイクルはもちろんチームの抜本的な改革は、多くの注目を浴び、400以上のはてなブックマーク数を獲得しました。 アクティブユーザーを1.9倍増にした内製化の成功をきっかけに、2017年には日経電子版のコンテンツの表示速度を改善する「爆速電子版」プロジェクトを実施し、業界最速のスピードを実現しました。 内製化やアジャイル開発の開始から6年が経過し、日経では開発部門だけでなく、全社的な組織改革に着手しています。そこで、同社の現役プロダクトマネージャーに、日経が挑戦する開発の現場の“いま”についてお伺いしました。 ■自己紹介（右から） 情報サービスユニット 斎藤祐也（さいとう・ゆうや）さん デジタル編成ユニット プロダクトマネージャー武市大志（たけいち・たいし）さん デジタル編成ユニット 西馬一
イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。 仕事を終わらせるために 仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。 予想以上に仕様が複雑になった 予想以上に調査に時間がかかった 予想以上にはまってしまった これはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、 予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする 予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す 予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずける というように、終わらないと気がついた時点で調
2020/5/13追記 オブジェクト指向と哲学の関係について書いた記事ではないです。せっかくだしQiitaっぽいタイトルつけようと思ったら結果的に釣りっぽくなってしまった 概要 オブジェクト指向とは何か？ということを真面目に調べていくと、オブジェクト指向には二種類ある、という話に突き当たる。sumim氏のQuora回答などを参照。 Smalltalkの設計者アラン・ケイによる、メッセージング重視のオブジェクト指向 C++の設計者ストラウストラップによる、クラス重視のオブジェクト指向 今回はこの前者のオブジェクト指向について、アラン・ケイの書きものを読んで調べた結果をまとめ、コメントを付す。 参考文献は最後にまとめて出す。参照元は「（AOO）」のように略記で示す。 アラン・ケイのオブジェクト指向 OOPは私にとって、メッセージング、状態処理の局所的な保持・保護と隠蔽、そしてあらゆる事象の徹底
Python初心者から2年間で読んだ中でオススメの技術書35冊を読むべき順番に並べた - 仮想サーファーの日常
Pythonの学習を始めて3年間でたくさんの技術書を読んできましたが、自分の技術力のレベルによって読みたい本が変わってしまうので、どの技術書を読めばいいのかがわからなくて本選びに相当な時間をかけたと思います。 今回は、これからプログラミング言語Pythonを学習しようとしている方、Pythonの基礎は勉強したけどもっと踏み込んで学びたい方向けに、ぼくが読んだPythonの技術書の中でこれは読んでよかった！という本を読みたい順番に紹介していきます。 この記事の対象読者 未経験からPythonを学習しようとしていて、どの技術書で学習を進めるべきか悩んでいる方 Pythonは少し学習したことあるけど、実践的なWebアプリケーションを開発するときに参考になる技術書を知りたい方 Pythonを活用したWebアプリケーションエンジニアになるために必要な知識やスキルを知りたい方 Pythonエンジニアと
「アジャイルソフトウェア開発という概念」の源流は日本なのか 〜『日本企業はなぜ「強み」を捨てるのか 』を読んで〜 - bonotakeの日記
夜中におもむろに書評を書き出す第2段。 日本企業はなぜ「強み」を捨てるのか～増補改訂版『日本“式”経営の逆襲』～ (光文社新書) 作者:岩尾 俊兵光文社Amazon この本自体はとても面白いし首肯できる部分も多いが、1箇所だけイチャモンをつけたい。 そもそもアジャイルソフトウェア開発という概念自体、マニフェスト（注：アジャイルソフトウェア開発宣言のこと）の発表よりも3年早く、1998年に日本の研究者から提案されている。 南山大学の青山幹雄教授による一連の研究である。 （同書より引用） ここで紹介されている「1998年」の「提案」とは、おそらくICSE1998で青山先生が発表した論文 "Agile Software Process and Its Experience" のことだろうと思う。Agile Software Process（ASP）という、実際に富士通の社内で実践されたソフトウェ
受託開発におけるアジャイルに限界を感じた私が、「納品のない受託開発」を始めるまで - 倉貫義人の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。株式会社ソニックガーデンの代表をしている倉貫義人と申します。 私はもともと大手システム会社でプログラマとして働いていました。そのとき出会ったアジャイル開発に魅了され、これこそ自分にとって理想の姿であると確信し、それ以来アジャイル開発を広めるための様々な活動を社内外で行ってきました。 最終的に、本当に自分の理想とするソフトウェア開発と、それを実現する組織をつくるためには、自ら会社を経営する立場になるしかないと考え、起業することになりました。そうしてできたのが株式会社ソニックガーデンです。 ソニックガーデンでは「納品のない受託開発」というサービスを提供しています。従来的な受託開発から、そもそものビジネスモデルを見直したことで、今では「アジャイル開発」を意識せずとも、自然とそれに取り組める組織として機能しています。 思い返すと、私のアジャ
AWS Dev Day 2023 Tokyoの登壇資料です。
モブプログラミングで「一緒に働く」を戦略的に仕事に取り入れよう - Agile Journey
みなさん、こんにちは。「制御不能なアジャイルモンスター」こと及部敬雄（@TAKAKING22）です。私は現在、 Silver Bullet Club というソフトウェア開発チームに所属していますが、チームでは2017年5月にモブプログラミングを採り入れ、現在も継続しています。こうした経験のなかで得られたモブプログラミングに関する知見を、書籍、記事、コミュニティ活動などを通して発信してきました。また、アジャイルコーチとしてチームや組織へのモブプログラミングの導入支援もしています。 本稿では、モブプログラミングを実際の現場で活用する際に直面しがちな悩みポイントを抑えつつ、個人やチーム、そして組織がモブプログラミングとどう向き合っていけばよいのかについて、ご紹介します。 モブプログラミングとは モブプログラミングの流れ なぜモブプログラミングが必要なのか 分担作業とモブプログラミングの比較 2つ
イーサリアムの開発エネルギーの凄さと他分野での再現性｜中村 龍矢 | LayerX 事業部執行役員 AI・LLM事業部長
（みんな思い思いのツイートをしてましたが、私は本プロジェクトの実質PMのDanny Ryanの長年の思いが詰まった下記のツイートが気に入りました。バランスの取れたリーダーであり、フランクで良い人でした。） PoS移行の大変さを要約すると、 ・失敗したら数十兆円吹き飛ぶ可能性があり、世界中に迷惑をかけるどころではない ・完全にパブリックなネットワークであり、世界中のハッカーから常に攻撃対象（攻撃すると儲かるため） ・使われている技術は全くもって枯れておらず、実装以前に理論研究段階から必要 ・基礎研究を終えて本格的に始動してから5年近くかかった という感じです。（ここで終わりではなく、他にも色々な技術的アップデートが予定されています。）私がEthereumの研究や開発をしていたのは2018-2020年の短い時間でしたが、一部だけでも関わることができたのは貴重な体験でした。 私はEthereum
【2024年】ITエンジニア本大賞まとめ
アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 チーム・組織にプラクティスを導入し、根付かせるために！ 116の手法を一冊にまとめた“実践”の手引き チームでのアジャイル開発には、開発技術やツールなどの「技術プラクティス」の活用が重要です。 プラクティスはそれぞれの目的や役割を意識することで効果を発揮します。しかし、目まぐるしく状況が変化する開発では、当初の目的を忘れて、プラクティスに取り組むこと自体が目的化してしまうチームも少なくありません。 本書は、チーム・組織でアジャイル開発に取り組んできた著者が、プラクティスの効果的な選択・活用のしかたについて、自らの実践経験に基づいてまとめたガイドブックです。 架空の開発現場を舞台にしたマンガとともに、チーム開発の様々なシーンで役立てられるプラクティスを、幅広くかつわかりやすく解説しています。開発現場に備えておけば、
Re:Backlogs というプロジェクト管理(タスク管理)ツールを OSS としてリリースしました - saino.me (kaishuu0123)
自分の Qiita 記事からブログへの転載です。そこそこいいものが作れたなぁと思っています (∩´∀｀)∩ qiita.com 読み方: Re:Backlogs (リ・バックログ) https://github.com/kaishuu0123/rebacklogs 2019/12/23: 使い方の記事を書きました。 Re:Backlogs の使い方を Twitter もどきアプリの開発を例に紹介します 画面紹介 マスターバックログ カンバン (Kanban) プロジェクト設定画面 説明 セットアップ方法 開発動機 ソースコード 使っている技術 実装してて楽しかったところ Drag & Drop による操作と、バックエンドのソート順保持 見やすい色を自動的に決めるアルゴリズム webpacker でのパフォーマンスチューニング 開発者なりにユーザビリティを考えること 最後に 2019/01/
実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example
ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス
AWS×コンテナで基本的なDevSecOpsアーキテクチャをデザインしたお話 - How elegant the tech world is...!
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは？ DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
2010年代に日本のインターネットでいろんな事業をいい感じにやってきた会社から2020年代へのヒントをもらえる本を作った - golden-luckyの日記
半年ぶりの新刊です。『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』です。紙とPDFがセットになった直販サイトはこちら。 Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち（紙書籍＋電子書籍） https://www.lambdanote.com/products/engineers-in-voyage さて、今回の新刊、いろいろ疑問を呼ぶタイトルかもしれません。 「なぜ VOYAGE GROUP？」 「なぜ t_wada？」 「なぜ宇宙船？」 「答えは本書で！」と言って済ませることもできるのですが、ここで少し「個人的」なふりかえりをして何となく答えた気分になっておこうと思います。 なぜ VOYAGE GROUP？ なぜ t_wada？ なぜ宇宙船？ で、結局のところどういう本なの？ 気合い入ってます なぜ VOYAGE G
スライド概要 スクラムフェス大阪2024の登壇資料です。 スクラムマスターとして、あるチームでエンジニアとQAの間に見えない壁があり、それが崩れるまでを眺めた。しかし、チームは時間をかけて壁を崩すことができ、その結果、よりユーザーと価値に向き合えるようになった。チームの状況は、初めてアジャイル開発やスクラムに触れるメンバーが多くいたよくあるプロダクトチームであった。スクラムマスターは、なぜ壁崩せたのか、なぜ見ていられたのかを語る。この物語は、あなたのチームでも起きうることであり、アジャイル開発に取り組む上での示唆になるはずです。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向プログラミングは終わった - Qiita
(翻訳) ストーリーポイント再考 - forest book
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方
システムの「作り逃げ」を許すな、運用保守を担う技術者の時間が奪われる
目的に合わせて開発戦略が変わる。リクルートの開発組織が実現する、専門性のコラボレーションとは - はてなニュース
人の相談になんてのるな。｜市谷 聡啓 (papanda)
「アジャイル開発」阻む役所の流儀 COCOA失敗招く - 日本経済新聞
仕事納めとスクラムの話 - imog
データ職種の課題図書リストを作りたい - 下町柚子黄昏記 by @yuzutas0
アジャイルについてマネージャーが知るべき97のこと
UXデザイナーが創り出して活用する10の成果物
日本人はなぜ「マスク」と「PPAP」をやめられないのか
「終わらなかったから次のスプリントにまわそう」なんてありえない
「アラン・ケイの」オブジェクト指向とは何だったか？元哲学者のエンジニアがまとめてみた - Qiita
アジャイル開発は本当に必要なのか、何を解決するのか
エンジニアとQAの壁が崩れていくのを眺めていた #scrumosaka | ドクセル