SUUMOアプリチームがスプリントを廃止してカンバン方式に移行した話 | リクルートテクノロジーズ メンバーズブログ
このエントリは全9回を予定する18卒新人ブログリレーの第4回です！ 今回は、SUUMOのモバイルアプリ開発の現場から、企画と開発が一体となったチームでの開発プロセスについてご紹介します！ はじめに はじめまして。リクルートテクノロジーズ新人の三田涼介です。現在は不動産検索サービスSUUMOのAndroidエンジニアとして働いています。 今回はSUUMOアプリチームの開発プロセスについて紹介します。 SUUMOは巨大なサービスでありながら日々高速に改善を行っており、週1回以上の頻度でiOS、Androidの各OSでリリースを行っています。このスピード感を実現するために、開発プロセス自体も日々磨き込みが行われており、私が配属された3ヶ月前にも開発プロセスに大きな変化がありました。 この記事では、私が新人としてキャッチアップしていく中で学んだ、 なぜ開発プロセスを選ぶことが必要なのか どうやって
Magic Podによる自動テスト 〜QAチーム記録第2回〜 - ロコガイド テックブログ
技術部品質向上グループのきしけん（@takeya0x86）です。 今回の記事ではトクバイアプリの自動テストについてお話ししようと思います。 これまでのトクバイアプリのE2E自動テストについて トクバイアプリでは、アプリとバックエンドそれぞれでユニットテストやAPIテストが存在し自動化されています。しかし、アプリからバックエンド全体を通したE2E自動テストについては整備されていませんでした。前回の私の記事では、まず手動でのリグレッションテストを整備し、自動化については今後の課題にしていました。ここではテストの自動化について、ツールの選定から現在の運用について解説します。 ツール選定・Magic Podについて Magic PodとはTRIDENT社が提供するSaaS型の自動テストサービスです。今回はAppiumなどを使用する場合との比較を行い、こちらのサービスをメインに使うことに決定しました
プロダクト開発の経験が浅い中でProduct Owner になったら｜アジャイルコーチ/知花里香
デジタル変革や新規事業開発で、プロダクト開発責任者に任命されたり、プロジェクトマネージャーだけどアジャイルで、などと周りから期待されている方が、実際にプロダクト開発を始める際に向き合うことになることを書いていきたいと思います。 「調整役」からの脱皮これまで、上司の言うことや全体の雰囲気の中で決まっていくことを具体化することはあっても、自分が中心にコトが回るなんて経験はない。 そんな中で、プロダクトオーナーになると突然問われる「VISION」に戸惑うことになります。「とめどなくやってくる意思決定」にも対処せねばなりません。 「では、あなた自身はどうしたいのか？」と問われ、 「・・・（うーん。まあこう言われているし、なあ。）」 となる人を多く見てきました。これは日本の歴史ある大企業などにいれば当たり前でのことです。 変革途中で権限委譲されていないケースも多く、実際に自身で決められない実情もある
続・プロダクトオーナーをやっている - Chatwork Creator's Note
こんにちは。藤井 @yoshiyoshifujii です。 来る 2022/10/07(金) Chatwork が主催するオンラインカンファレンス『Chatwork Product Day 2022』が開催されます 🎉 lp.chatwork.com カンファレンスまで、あと10日です。ふるってご参加いただけますと幸いです。 今回、私が投稿するのは、過去に投稿いたしました以下の記事の続編となります。 creators-note.chatwork.com creators-note.chatwork.com 当記事では、プロダクトオーナーを最近、どうやってるの？ってあたりを紹介したいと思います。 戦略的ゴールと中間ゴール プロダクトバックログ(エピックレベル)の運用 エピックのライフサイクルを出来るだけ短くする プロダクトバックログ(ストーリーレベル)の運用 スプリントバックログの運用 プ
適正ユーザーストーリーは1期間に2～3実装、アジャイル開発の肝
アジャイル開発は「プロジェクト途中での変更を受け入れる」ことを前提とするが、プロジェクトのスタート段階ではその時点での「全体を見据えた初期計画」をつくる必要がある。初期計画ではプロジェクト代表者の「プロダクトオーナー（PO）」、または多忙なPOを支援して調整役やリーダー役を担う「代理プロダクトオーナー（PPO）」がリードしながらスコープ、優先順位の付け方、移行やテストといった「通常タスク」の扱い、リリース計画などを決める。 この「初期計画」は最初から綿密に固める必要はないが、ステークホルダーと事前に合意して進めることが欠かせない。どの程度まで決めておけばよいのか、具体的に解説しよう。 ポイント（1） ユーザーストーリーを「ちょうどいい大きさ」に整える 本書の「基礎編」では、要件定義においてシステムの全体像や機能の詳細を把握するには、エンドユーザーの要件を「役割（誰が）」「要望（何をしたい）
Four Keys 〜自分たちの開発レベルを定量化してイケてる DevOps チームになろう〜
はじめに この記事タイトルに興味をもって読み始めていただいている方の多くは、ソフトウェアエンジニアとしてチームで開発をしていたり、エンジニアリングマネージャーとしてチームビルディングやマネジメントをされている方なのではないかと思います。 実際、この記事を書いている加藤も、リクルートライフスタイルのデータプラットフォームグループ (以前は CETチーム と呼ばれていました) に所属するデータエンジニアとして、データ活用のための基盤開発・運用を行っている一人です。また、担当している社内データプロダクトのプロダクトマネージャーも兼任しています。 本記事では、自分の所属している DevOps チームを「イケてる DevOps チーム」にするために取り組んだ内容や気づいた点をお伝えしたいと思っています。 目次 はじめに 「イケてる」DevOps チームってなに？ Four Keys とは なぜ Fo
スプリントの期間を長くしたいと思ったら...
みなさんこんにちは。@ryuzeeです。 元記事はLichard Lawrence氏のWhy Longer Sprints Probably Won’t Helpです。 良記事でしたので抜粋・意訳にてご紹介します。 本文に入る前に若干前提事項を補足しておきます。 以下で言っている「スプリント期間を伸ばす」というのは、あるスプリントだけの期間を伸ばすのではなく、スプリントのサイズ自体を変えることです（例：2週間スプリント→4週間スプリント）タイムボックスであることに意味があるので、ご存知の通り「あと1日あれば終わる」とか言ってスプリント期間を延長することは許されませんそしてスプリントの期間は原則固定なので、今回は2週間、次回は4週間、その次は1週間、というのも無しです。ただし変化への対応はもちろん大事。今回はその点に関するお話です コーチとしてよく、「スプリント期間が短すぎるので、XからYに
スコープとスケジュールを継続して計画する方法 - Chatwork Creator's Note
こんにちはー。藤井 (@yoshiyoshifujii) です。 Akkaってスウェーデンの山の名前なんですって、ご存知でした？わたしは知りませんでした。 そういえば、Akkaのロゴって山っぽいですもんねー さて、今回の標題の件ですが、ひらたくいうと、 「プロダクトバックログを作成して、バーンアップチャートを作り、Velocityを計測して、観測しましょう」 ということになります。 アジャイルの書籍やコミュニティでの発表など、それが必要で効果のあることだと分かってはいたのですが、なかなか実践できておりませんでした。 先日、Scrum Inc.主催のLicensed Scrum Product Owner研修を受けさせていただき、その中で教わった内容を、早速、現場で実践したところ、チームの評判も良く、ステークホルダーへの説明にも効果を発揮しそうな肌感を得ておりますので、そのあたりをご紹介でき
わかった気にならずに原典を読む「スクラムガイド」モブリーディング
「スクラムガイド」モブリーディングとは文字通りチームで「スクラムガイド」を読むだけです。 個々に読むのもいいですが、ふだん働いているチームで雑談しながら読み合わせをしたかったので、モビングスタイルで読みました。全員で同じ画面を見ながら輪読し、気になったところや分かりづらいところは「ああでもない」「こうでもない」と議論をしながら読み進めていきます。 スクラムガイドはとても短くまとまっているところが素晴らしいです。どれだけじっくり読むかによりますが、そこそこ議論をしながらすべて読み合わせをするのに、2回に分けて合計2時間程度で終わりました。見積もりのご参考までに。 モビングについて学びだければ、こんな素晴らしい本が出たそうですよ！ 「スクラムガイド」で面白かったところ今回モブリーディングをして、改めて面白かったところをご紹介します。 スクラムの定義スクラムとは、以下のようなものである。 • 軽
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
「スタンダップミーティングは役に立たない」 - Qiita
というタイトルの面白そうなポエムを見つけた。「デイリースタンドアップミーティング（デイリースクラムとして知られている）は、次のようなやり方で行われると無駄になる。」というもの。 全員がTrelloやAsana、JIRAのボードを見つめ、PjMやTechLeadが各チームメンバーに作業中のチケットに関する質問を投げかけ、以下のような会話が起こります。 (PjM) ジョン、チケットXYZの進捗状況はどうですか？ (John) いい感じですよ。あれもやったし、これもやったし、ほとんど終わったよ。あとは最後の仕上げで、コードを磨いて、いくつかテストを追加するだけだ。今日中に完成させなければなりません。 (PjM) 素晴らしい、次に進みましょう。マリアさん、あなたのチケットの状況はどうなっていますか？ (Maria) ボブが私のプルリクエストをレビューしているので、コメントがない限り、私はこれで終わ
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
#4 アジャイル開発成功の秘訣 | NTTデータ
「アジャイル開発」というという開発手法が浸透して久しい。社会の在り方が大きく変化する中、ビジネスもまた変化への即応が求められている。そのため、ビジネスを支えるITシステムの現場では、変化に柔軟なアジャイル開発の導入が重要となっている。しかし、「アジャイル開発に失敗した」という話を聞くことも少なくない。アジャイル開発を成功に導き、変化に即応するには？その答えとして、ソフトウエアエンジニアリングを専門とする早稲田大学基幹理工学部の鷲崎弘宜教授とNTTデータAgileプロフェッショナル担当部長の市川の対談を通じ、アジャイル開発成功における要諦を探る。 目次0. 変化に即応できるアジャイル開発の重要性の高まり1. アジャイル開発の成功事例2. 改善し続ける「マインド」は「行動」で測る3. 自分たちの課題を考えてパターンを活用する4. 価値の連鎖「見える化」と「協創」5. アジャイル開発の成功に必要
開発中のコミュニケーションには色んなところで想像が入り込む - Mitsuyuki.Shiiba
例えば「会議が多い」という意見に、どう対応しよう？ 普通に考えたら「無駄な会議を減らそう！」かな だけど、できれば僕は「だからどうしたいと思ってるんですか？」というのをその意見をくれた人に確認したい 十中八九「会議を減らしたい」ってことなんだろうとは思いつつ、でも「会議が多いから、」のあとには色んなことが想像できる （順当→）会議を減らしたい それぞれの会議に自分が参加しないといけない理由を知りたい 会議が多くて他のことをやる時間がないから、自分の担当タスクを減らしたい 会議が多いのはいいんだけど、間に休憩が欲しい 「そっかぁ、それは大変だよね。ありがとう」って話を聞いて欲しいだけ もしかしたら「だから、充実してるんです」って可能性もなくはない さらに「会議を減らしたい」だったとして、その内容も 「無駄な会議が多いから減らしたい」かもしれないし 「開催頻度を減らしてもいい会議があるのではな
【徹底解説】正しい「KPT」が仕事の成果を生み出す！進め方のコツ、現場の事例を紹介 | SELECK [セレック]
「KPT」とは、「ふりかえり」によって、仕事やプロジェクトの改善を加速するフレームワークのひとつです。 個人的には、KPTはシンプルながらも非常に優秀な手法だと思っています。 仕事を進める中で、「やったことを振り返る」機会ってよくありますよね。年度末であったり、新たな目標設計をする際や、プロジェクトが終わったときなどなど…。 こうしたとき、ミーティングなどで盲目的に意見を出し合っても、「…で、どうする？」ということになりがちです。 そんな時にKPTを用いれば、スマートに現状分析を行うことができ、次にやるべきことが明確になります。 今回は、このKPTの日本企業における使い方の事例と、使う際に役立つITツール、進め方のコツを紹介します。参考にして、ぜひKPTを実践してみてくださいね。 【目次】 「Keep・Problem・Try」で構成される、KPTとは？ KPTを実際に活用している日本企業の
![【徹底解説】正しい「KPT」が仕事の成果を生み出す！進め方のコツ、現場の事例を紹介 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/3c2961543bd26e30c8ffa32d99c319b9b66990a6/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2018%2F02%2F12180206%2F1.png)
SWET | TEAM - DeNA Engineering
SWETグループの属する品質本部は、ゲーム・ソーシャルライブ・ヘルスケア・スポーツなど様々な事業を展開し続けるDeNAグループ全体の様々な品質にコミットしている部署です。その中で、SWET（SoftWare Engineer in Test の略）グループは、ソフトウェアテストを起点とした、「DeNA サービス全般の品質向上」と「DeNA エンジニアの開発生産性向上」の両方により、価値あるものを素早く提供できるようにすることをミッションとしています。 近年、アプリケーションには高機能さが求められるようになり、かつ開発サイクルは徐々に短くなってきています。それに伴い、ソフトウェアの品質を担保するための「テスト自動化」の重要性が高まっています。テスト自動化をすることで、バグを早期に発見して取り除き高い開発生産性を実現できます。 そのため、開発現場の中に入り込んでいき、開発者と共に早期にバグを検
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ざんねんなプロダクト開発事典
初心者スクラムチームが陥っていた間違ったスクラムの見積もり方法とそれに対するカイゼン
おいしいドッグフードの食べ方
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
