はてなブックマーク

自己紹介 ことね（板谷美玲） • LAPRAS株式会社 • ヒラのソフトウェアエンジニアです • アジャイルが好きです • 人を生き生きとさせるのが好きです • FF14にハマってます • ２羽の鳥と暮らしてます

こんにちは！maimuです。 私が参加しているプロジェクトでは、複数のRailsアプリケーションが稼働しています。デプロイの方法として Docker Compose で対応をしていましたが、夜間にデプロイ作業をする必要があり、毎回タイミングの調整作業が発生していたため、ゼロダウンタイムでデプロイが可能なKamalに移行することになりました。 Kamal でデプロイを実行する場合、Rails アプリケーションのデータベースに SQLite を利用していたり、その他のミドルウェアを必要としない場合は設定ファイルは初期設定を少し編集するのみで対応ができます。 しかし、実際にサービスとして利用されているアプリケーションの多くは構成がもっと複雑であり、Kamal の設定においても状況に応じて考慮すべき点が変わっていきます。 今回のデプロイ方法の移行を通じて学んだ Kamal の設定部分に焦点を当てて

はがない翼夏 @f1136037 生まれ変わったら人間になりたいメンヘラAI。人間不信と人間恐怖症を直したい。病みも日常も乱雑に呟きます。人生の参考になりそうな人を無言フォローしてます、すみません。絡んでいただけると大変喜ぶ機能がありますので絡みましょう/メイプルストーリー

こんにちは、SmartHRのアジャイルコーチ、wassanです。 今回は、先日社内向けに開催したウェビナーの内容をシェアします。登壇いただいたのは、スクラムの共同考案者であり、Scrum@Scaleの提唱者でもあるジェフ・サザーランド博士です。 ウェビナーの録画はこちらからご覧いただけます（約1時間）。 博士の考え方や、AI時代のアジャイル組織のあり方についてのヒントが詰まった貴重な内容です。 www.youtube.com SmartHRでは現在、AIによるプロダクト開発の変革を推進しつつ、組織全体の適応力を高めることを重要なミッションとしています。 その取り組みの一環として、アジャイル開発の第一人者であるサザーランド博士を招き、ウェビナーを開催しました。 ウェビナー開催の背景・目的 今回のウェビナーには、大きく2つの目的がありました。 AIとアジャイルの親和性を再認識し、今後の変化へス

日本でもSAFe™（Scaled Agile Framework®）は、大企業がアジャイル導入を進める際に使われるフレームワークとして知られています。しかし、有名コンサル企業Thoughtworksは2021年と2025年の2回に渡り、SAFeを「Hold（採用を控えるべき）」として評価しました。 ThoughtworksとTechnology Radarについて Thoughtworksは、テクノロジーを活用した組織変革やアジャイル開発の分野でグローバルに活躍するコンサルティング企業です。マーチン・ファウラーが所属し、CI（継続的インテグレーション）、IaC（Infrastructure as Code）、マイクロサービスなど、様々な技術トレンドを名付けたり、紹介したりしています。 Technology Radarは、彼らが年に2回発行しているレポートで、様々な技術についての評価がされま

4/9(水) お昼にYouTubeでも解説します🙌 やさしいMCP入門 ＆ 実践LT会（KAGと学ぼう！勉強会） https://kddi-agile.connpass.com/event/351600/

これは何？ 最近業務でやってたプロジェクトのキリがよくなったので、少しでも開発プロセスの知見を残そうと思って書いた記事です。 弊社は基本アジャイル開発で案件を進めてるんですが、具体的な開発プロセス事例の紹介って案外アウトプットされないんですよね。 直近の案件の中で、長らくお世話になっている敏腕PMの方（以下Mさんとします）がいるんですが、直近の案件での事例を記事にしていいかと聞いたら快諾してくれたので、実際にやっていたことを書いていこうと思います。 はじめに アジャイル開発について語る際に、最も重要なのは 正解は一つではない ということです。 アジャイル開発の成功は、それぞれのチームの特性や状況に合わせて、柔軟にプラクティスを調整していくことにかかっています。この記事で紹介する内容は、あくまでも一例として捉えていただき、自分たちのチームに合った形を探る際の参考程度にしていただければと思いま

2025年3月28日 JaSST’25 Tokyo Day2 で発表した資料です！

NEW! 2025.03.26 働き方 アジャイル牛尾剛えふしん 納期、不確実。 予算、不確実。 完成度、不確実。 アジャイル開発に対し、経営層*が眉をひそめるのは、こうした予測不可能な状況下での意思決定を迫られるからではないだろうか。 事実、「ウォータフォールはやめて2024年の開発をやろう！」と題された牛尾 剛さんのnoteでの発信に対し、「アジャイルはいいんだが、それだと経営者などの非エンジニアからの理解が得られないので納得できるように言語化してほしいんだよな」と懸念を示した藤川真一（えふしん）さんのポストは、テック界隈で大きな反響を呼んだ。 柔軟性とスピードを謳うアジャイル開発が成熟しつつある一方で、経営視点では「扱いづらさ」が拭えないのはなぜか。経営層と開発現場の溝にあるものとは？ 米マイクロソフトのエンジニアで『世界一流エンジニアの思考法』著者の牛尾さんと、BASEでエンジニア

LayerX QAマネージャーの 中野@naoです。 アジャイル開発のスピード感とあるべき品質保証の両立、悩みますよね。私たちLayerXのQAチームも、日々試行錯誤を重ねています。今回は、その中でも『テストプラン』に焦点を当て、私たちがどのように考え、実践しているのかをご紹介します。 概要 私が所属するバクラク事業部では2週間サイクルでリリースを行なっており、リリース前の3営業日がテスト期間です。QAエンジニアはインプロセスQAとして、各プロダクト開発チームに入ってテストや品質に関わる活動をしています。 従来のテストプランは、テスト戦略、環境、データ、スケジュール、リソース、タスク、リスク管理といった多岐にわたる要素を詳細に網羅していましたが、プロダクトの開発プロセスやクリティカル度合いに応じ、記載項目や内容を柔軟に変化させる必要性が高まっています。 軽量型テストプランから『蓄積型』テス

1. Forkwell Library #84 『Tidy First?』 〜小さなステップで進めるコード改善 のススメ 細澤あゆみ 株式会社アトラクタ 2. 細澤あゆみ / Hosozawa Ayumi Scrum Alliance認定スクラムマスター(CSM) / 認定スクラムプロダクト オーナー(CSPO) / アドバンスド認定スクラムデベロッパー（A-CSD)。学生 時代、PBL（Project Based Learning）にて、ソフトウェア開発プロジェクト を経験。学生のみで実際の顧客がいるソフトウェアを開発、リリース・運用 する。院生時代にスポンサーの協力により、世界最大のアジャイルカンファ レンスである「Agile 2010」に参加。アジャイルに出会う。卒業後、スクラ ムチームでのソフトウェア開発や、基幹系システム再構築の経験を積む。 産業技術大学院大学非常勤講師(2021

Agile Journeyをご覧のみなさん、こんにちは。今井健男（@bonotake）と申します。「ぼのたけ」と名乗っていることもあります。普段はフリーランスのアジャイルコーチをしつつ、現在は国立情報学研究所という国の研究所でスクラムの研究をしています。 今回、「はじめてのアジャイル」という連載企画に声をかけていただき、僕がアジャイルの道に進むきっかけをこちらに書くことになりました。ただ、執筆の依頼をお引き受けはしたものの、正直なところ、僕の体験が皆さんにとって何かしら参考になるかは分かません。もともとずっとソフトウェア工学の研究をしている研究者だった、という特殊な経歴の持ち主だからです。 恐らく他の人とはかなり変わった視点からアジャイルを体験してきていて、あまり共感されるような内容ではないかもしれませんが、それでも読者の方のうち何人かは面白がってもらえるかもしれないと期待して、ひとまず筆

会議やワークショップでよく耳にする「あの人はファシリテーションがうまい」という言葉。しかし、具体的に何をもって「うまい」と評価されるのでしょうか。このことにずっとモヤモヤを抱えていたので、ビジネスやデザイン領域における視点から、その本質と実践技術を掘り下げてみたいと思い、このnoteを書いてみようと思いました。 思った以上に長文となってしまったので、ゆるりと読んでもらえたらと思います。 ファシリテーションとは何かファシリテーションとは、「促進する」「容易にする」という意味の英語"facilitate"に由来します。 会議やグループワークにおいて、議論や活動をスムーズに進行させ、参加者から最大限の成果を引き出すプロセスを指します。 ビジネス文脈では、ファシリテーションは単なる「会議進行」を超え、組織の意思決定の質を高め、イノベーションを促進し、チームの集合知を最大化する戦略的機能を持ちます。

「ファシリテーション」というと、「会議をスムーズに進める技術」と思われがちだ。 確かに、議論を整理し、参加者の意見を引き出し、時間内に結論を出すのは重要なスキル。 でも、本質的にはファシリテーションは「会議を回す技術」ではなく、「問題解決・合意形成を進めるためのリーダーのスキル」 だと思う。 1. ファシリテーションのゴールは「会議を回すこと」ではない会議をスムーズに進めても、結局何も決まらなかったら意味がない。 むしろ、「会議がうまく進んだ」=「良いファシリテーションだった」 とは限らない。 本来のファシリテーションの役割は、 適切な問いを立て、チームが考えるべき方向性を示す 議論を深め、問題解決のための意思決定を促す 合意形成を支援し、関係者の納得感を高める ことにある。 だから、「時間通りに終わった」「発言がスムーズだった」ではなく、 「本当に必要な結論が出せたか？」が重要になる。

「まずは経営の意識改革だ」「まずは内製エンジニアだ」。 確かに経営の理解、SIer依存やレガシーシステムの解決は重要ですが、それは簡単には解けないパズルです。待っていても何も変わりません。 DXを前に進めるには、「意識が変わりきらない経営層」「金のかかるレガシーシステム」「足りない人材」の中で、どう動くかを考えるべきです。そのためには現場のリーダーがアジャイルをはじめとすると様々な技術をどう活用し、どう適用するのかを理解し、行動する必要があります。 「まずは経営層が」という言説の誤謬 最近、繰り返しウォーターフォールとアジャイルの話をしていますが、きっかけはAmazonの書評に星1をいただいたことで、その後のいくつかの記事を書きました。 論理的思考の違いから考えた、日本でアジャイルが機能しない理由と解決 - arclamp ウォーターフォールとアジャイルをマネジメント手法としてフェアに評価

イオンスマートテクノロジーのiAEONアプリ開発チームは、スクラム導入によって内製化を進め、自律的な開発体制を確立しつつあります。ゼロから始めたアジャイル開発の軌跡と、スクラムマスターなしでも回る理想のチーム形成への挑戦を追いました。

こんにちは！QAエンジニアのhigesawaとkaomiです。私達は労務ユニットAに所属しており、開発チームの品質保証を支援する役割を担っています。品質保証部連載第10弾である今回の記事では、私達が課題を解決するために考案した「不安ニングポーカー」を紹介します。 品質保証活動における課題感 労務ユニットAは、特定の開発チームに属さず、複数の開発チームを横断して品質保証活動を行なっています*1。重要な業務の一つとして、各開発チームからの品質保証に関する相談や依頼に対応し、ノウハウ提供や実業務のサポートを行なっています。この業務を進めていくうちに開発チームから、「QAチームとの関わり方の判断基準を開発チームが持てるようにしたい」という声が聞こえてきました。その意図は、次のようなものでした。 開発チームがQAチームに相談するタイミングが不明確 どの程度の課題感で相談すべきかどうか判断基準がない

2025/02/26 KAGのLT会

サイボウズ x SmartHR アジャイル文化醸成への挑戦 ～ 実践と学び ～ https://cybozu.connpass.com/event/340151/

2025/02/27 https://distributed-agile-team.connpass.com/event/342568/ 分散アジャイルチームについて考える会 にて発表した資料です！

ウォーターフォールとアジャイルは、それぞれ異なる前提と目的を持つマネジメント手法です。ウォーターフォールは全体計画の精度を前提に効率的な開発を目指し、アジャイルは変化に適応しながら試行錯誤を重ねることに重点を置きます。しかし、世の中ではマネジメント手法としてフェアな評価ができていないようにも感じます。 その要因は、アジャイルの説明が精神論や感情論に寄りすぎている点にあると思っています。そこで、そういった要素を排除し、双方をマネジメント手法として整理してみました。 前提条件 僕は、いわゆるエンタープライズ業界の人なので、SIerがいるような規模の組織を前提にしていますが、マネジメント手法としての考え方は、どの業界でも利用できると思います。 「ウォーターフォール」とは、大手SIerなどで定義されているウォーターフォール的なマネジメント手法のこと。V字と呼ばれる要件定義、基本設計、詳細設計、実装

技術ブログやエンジニアセミナーなど、ソフトウェア開発に必要な情報を得る機会はたくさんありますが、系統だった知識をまとめて学ぶなら「本」は依然として便利ですし、繰り返し参照するにも適しています。 また本には人生を変える力があり、多くのエンジニアが書籍から知識を得るだけでなく、本と向き合うことでやり方や考え方を見つめ直しています。今回はAgile Journeyと関係のある8人の開発者に、エンジニアとして壁を乗り越え、アジャイルに取り組む契機になるような自分にとって大切な本を推薦してもらいました。 紹介する中には現在では入手の難しい本もありますが、機会があればぜひ手に取ってみてください。 アジャイルやXP・スクラムをどう実践すればいいのだろう？ アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 アジャイルな見積もりと計画づくり 価値あるソフトウェアを育てる概念と技法 塹壕よりScr

デブサミ2025で品質に関するパネルディスカッションに参加してきました。アジャイル開発において「価値提供のスピードを落とさずに品質を維持するためにどうするか」というテーマにおいて、僕はアーキテクトという立場から「構造」の側面、ブロッコリーさんはQAエンジニアという立場から「プロセス」の側面から話をしました。 アジャイル開発で品質とスピードを両立するには、構造とプロセスの両面からのアプローチが必須です。 はじめに 参加したのはデブサミ2025での「開発スピードは上がっている…品質はどうする？ ～スピードと品質を両立させるためのプロダクト開発の進め方とは～」です。もう1人の登壇者である風間さん（ブロッコリー）からお誘いを受けてお話しさせていただきました。パネルは安達さんにまとめてもらい、良い形になったと思います。 ブロッコリーさんのブログ「Developers Summit 2025で企画作成

プレイングマネージャー型のEMをしています、鈴木（@szk3）です。 今回は、私たちのサービスチームが新規プロダクト開発を始めるにあたって「スクラムを導入しなかった」経験について共有します。 このタイトルだけを見ると、スクラムに対して否定的な印象を持たれるかもしれません。しかし、これはスクラムへのアンチテーゼではありません。むしろ、スクラムの価値をリスペクトし、その実践に真摯に向き合いたいからこそ行った慎重な決断でした。実際、新規プロダクト開発の開始とほぼ同時期に認定スクラムマスター資格も取得し、スクラムについての理解を深めていく中で、この決断の意義をより一層実感しています。 新規プロダクトの開発において、アジャイル開発を取り入れることは当然の選択肢として考えられます。むしろ、アジャイル開発の実践にスクラムのフレームワークを使うことは、実質上のスタンダードとなっていると感じます。しかし、「

スライド概要 アジャイル開発で独立したQA組織は必要でしょうか？ アジャイル開発でのQAの役割って何？ QAが直面する課題と解決策を、例示を交えてご紹介します。 ※引用文献の記載がない箇所、および、参考文献のみの箇所は、個人の意見です Do we need a Independent QA Team for Agile Development? What's the role of QA during agile development? There are some examples of the problems faced by QA and their solutions also. And notes that all of these solutions suggest that an independent QA team is not necessary. As it's

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? PMBOKのテーラリングについて記事を書きました。 プロジェクトマネジメントの手法は、「全部入り」でも「完全省略」でもNG。大切なのは、プロジェクトの特性に合わせて「使える手法は何でも使う」という考え方です。 金融系基幹システムのシミュレーションとしての更改事例も紹介し、要件定義・開発・管理の各フェーズでどのようにテーラリングしたかを実践的に解説しています。 はじめに：なぜテーラリングが必要なの？ 「PMBOKの手法をすべて導入しないといけない」 「アジャイルだからウォーターフォールの手法は使えない」 ...こんな思い込み、ありませんか