アジャイルなのに正せない？ 開発の行き詰まりを打破するポイントを市谷聡啓さんに聞く - Agile Journey
よりよいプロダクトを作り、高い価値を届けようと、アジャイル開発のアプローチで真剣に取り組んできたのに、「なんか違うよね」「それより、もっと早くリリースできないの」といった予想外のフィードバックに直面し、立ち止まってしまう──そんな現場は珍しくないのではないでしょうか。 20年以上にわたり現場と組織の両面からアジャイルを実践し、さまざまな現場を支援してきた市谷聡啓さんは、そんな行き詰まりの原因を、個々のスキルやプロダクトではなく、チームを取り巻く「構造」にあると分析しています。 こうした「構造」を捉えながらアジャイル開発を進めていくには、どんな取り組みが必要なのでしょうか。具体的なポイントを市谷さんに伺いました。 アジャイルが成熟してきたがゆえに直面する「構造」の問題 互いの「正義」が衝突し、「正す」ことができなくなる それぞれの立ち位置を整理し、方向性を可視化する 意見が衝突したら「アクシ
人事がアジャイルになったら、開発チームはもっと強くなるのか【アジャイル×人事座談会】 - Agile Journey
なぜ、人事も「アジャイル」なのか？ 人事の業務を可視化して協働関係をつくる 形や方法論から入らず、よりよい状態を模索する アジャイルの考え方は全ての正解としてとらえない方がいい 開発部門が人事と連携したいと思ったら、どうしたらいい？ 大切なのは人事と開発がお互いに理解しようとする姿勢 チームで成果を出す働き方を知る 人事と開発現場。どちらも「組織を良くしたい」という思いは同じはずなのに、なぜか歩み寄るきっかけがつかめない──そんな「すれ違い」を感じることはありませんか？ 実は、人事が抱えがちな業務をチームで分かち合い、現場との距離を縮めるヒントが、アジャイル開発の考え方にありました。 本記事では、エンジニアと人事、両方の視点を持つ3名を招き、現場での試行錯誤や具体的な工夫を語り合いました。 見えてきたのは、「専門用語を使わずに話す」「まずは互いの困りごとを共有する」といった、すぐにでも始め
リリース後のテスト活動とは？ フィーチャーフラグの活用と現場リサーチによるユーザー行動の観察 ─ 続・継続的テストモデル - Agile Journey
読者の皆さんには、手間暇かけて実装し、たくさんのケースでテストを実行し、やっとの思いでリリースした機能が顧客に受け入れられなかった経験はありませんか？ 開発チーム内で想定していた通りの機能を作ってリリースしたとしても、実際はユーザーに利用してもらえない事態になったとしたら、リリースした価値はないかもしれません。 もちろん、プロダクトがどのように利用されるかを、リリース前から全て想定できるわけではありません。そのため、リリース後にも継続的に確認することが大切です。 本記事では、Dan Ashby（@DanAshby04）が2016年に提唱した継続的テストモデル（Continuous Testing）の考え方を用いつつ、リリース後に行うシフトライトなテスト活動について解説していきます。 継続的テストモデルとシフトライトの活動について 小売りチェーン向けECシステムの店舗向けアプリで実践 ある機
開発規模が拡大してもアジャイルであり続けるための「組織やチームに対するコーチング」 ─ ログラス松岡幸一郎さんインタビュー - Agile Journey
新規プロダクト開発チームやスタートアップにおいて、アジャイルの経験を積んだエンジニアが初期メンバーにいれば自然と開発プロセスにアジャイルが取り入れられ、スムーズにプロダクト開発にフォーカスできることがあります。しかし開発組織が拡大して経験の浅いエンジニアが増えてくると、今度はアジャイルのマインドやプラクティスそのものの定着がしばしば課題となります。どうすれば組織が拡大してもアジャイルであり続けられるのか？ その実例や情報の共有はまだまだ足りていません。 ドメイン駆動設計（DDD）に関する情報発信でも知られるエンジニアの松岡幸一郎（@little_hand_s）さんは、そうした「組織を対象とした課題」の解決にフォーカスするため、システムコーチングという組織やチームに対するコーチング手法を取り入れました。個人に対するコーチングはかなり知られてきましたが、組織に対するコーチングについては耳慣れな
スクラムマスターの役割はスクラムを回すだけではない ─ Be Agileを志向するサイボウズの組織改編 - Agile Journey
サイボウズにおいてプロダクト開発を担当する開発本部では、2016年頃からスクラムを開発現場に導入してきました。チームにスクラムマスターがいない状況も続いていましたが、2022年にはエンジニアやデザイナーなどと同様の「職能」としてスクラムマスターをバックアップする組織改編に踏み切っています。 ▶ 組織のチームワークを最大化するためにスクラムマスター職能を作りました - Cybozu Inside Out これまでもサイボウズの開発本部ではマネージャー職をいったん撤廃するなど、組織のあり方に野心的な取り組みをしてきました。そういった組織改編の狙いや、スクラムマスター職能化から約1年でどのような効果があったのかを、開発本部副本部長の岡田勇樹さんと、シニアスクラムマスターの天野祐介さん、スクラムマスター職能化にともなって専任となったToshinariさんの3人に伺いました。 スクラムマスターがチー
カンバンボードで業務を可視化・整理しよう - 組織に合ったカンバンの設計・運用をヴァル研究所の実践に学ぶ - Agile Journey
Agile Journeyをご覧の皆さん、こんにちは。ヴァル研究所の熊野壮真 / 小泉翔太です。 私たちの勤務する株式会社ヴァル研究所は、日本で最初に発売された経路検索サービス「駅すぱあと」を中心に、公共交通に関連するさまざまなプロダクトを展開しています。最近では MaaS （Mobility as a Service)）といった、未来の移動のあり方を変えていくような取り組みにもチャレンジしています。 これらプロダクト開発の現場にはアジャイルの考え方が浸透しており、各チームでは現場ごとに合わせたさまざまな形のアジャイルの実践が見られます。その実践手法は多様ですが、各チーム、共通して力を入れているのが「カンバン」による仕事の可視化の取り組みです。こと「カンバン」に関しては開発部門のみならず、バックオフィス部門でも積極的に活用しており、その活用場面の多さ、バリエーションの豊かさは当社の特色と言
ステークホルダーの多いプロジェクトでもスクラムが効果を発揮するまでヤフーが取り組んできたこと─スクラムマスターとアジャイルコーチの役割とは - Agile Journey
比較的小さなチームで小回りのきくプロジェクトを進める場合には、アジャイル開発やスクラムの利点をすぐに感じられる場面も多いでしょう。しかし、より多くのステークホルダーが関わってくる大規模な開発プロジェクトとなるとどうなるでしょうか。 いくつかのチームで2010年代前半からアジャイル開発に取り組んできたヤフー株式会社の開発組織ですが、現在では新規にスクラムを導入したいプロジェクトを支援する組織があり、たくさんのステークホルダーが関わる世界的なスポーツイベントの特設メディアサイトの構築においても効果を発揮しています。 スクラムマスターとして2021年にスポーツナビの総合メディアサイト開発を推進した田原慎也さんと、その田原さんたちをアジャイルコーチとして支援した荒瀬中人さんに、複数チームをまとめたスクラムでの工夫や課題を聞きました。 後出しの追加要望や市場変化への対応が容易なスクラム 経験者が多く
プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
モブプログラミングで「一緒に働く」を戦略的に仕事に取り入れよう - Agile Journey
みなさん、こんにちは。「制御不能なアジャイルモンスター」こと及部敬雄（@TAKAKING22）です。私は現在、 Silver Bullet Club というソフトウェア開発チームに所属していますが、チームでは2017年5月にモブプログラミングを採り入れ、現在も継続しています。こうした経験のなかで得られたモブプログラミングに関する知見を、書籍、記事、コミュニティ活動などを通して発信してきました。また、アジャイルコーチとしてチームや組織へのモブプログラミングの導入支援もしています。 本稿では、モブプログラミングを実際の現場で活用する際に直面しがちな悩みポイントを抑えつつ、個人やチーム、そして組織がモブプログラミングとどう向き合っていけばよいのかについて、ご紹介します。 モブプログラミングとは モブプログラミングの流れ なぜモブプログラミングが必要なのか 分担作業とモブプログラミングの比較 2つ
すべてがXPになる ─ エクストリームプログラミングで見える開発風景（セミナーレポート） - Agile Journey
アジャイルソフトウェア開発を企業が導入する際に、スクラムと並んで名前が挙がる開発手法にエクストリームプログラミング（XP）があります。ガイドブックや研修が存在するスクラムに対して、ペアプログラミング（ペアプロ）やテスト駆動開発といったプラクティスをエクストリーム（極限的）に実践しようというXPの導入には、どこから始めればよいのかと戸惑う開発組織もあるようです。 2022年6月に開催されたユーザベース主催の勉強会「エクストリームプログラミングで見える開発風景」では、XPの提唱者であるケント・ベックの著作などの翻訳者として知られる角征典さんと、XPを導入しているユーザベースのソフトウェアエンジニアである野口光太郎さんが講演したのち、XPの始め方やエンジニア以外との体制づくりなどについて、視聴者の質問をもとにパネルトークが行われました。 本記事では、組織にXPをどのように導入するか、またスクラム
アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
「1人アジャイル」から始める、アジャイル開発導入のススメ｜Agile Journeyローンチによせて - Agile Journey
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
