2019-06-20、青山にて開催された「DevLOVE X 」での登壇資料です。 ソフトウェア開発は不確実性が高いと言われており、とても複雑な制約のなかで、日々プロダクト開発をしています。そんな制約の中で私達が価値を早く提供するためには、強い開発チームが必要です。 強い開発チームとは、心理的な安全性が保たれて、定期的に自分たちの仕事の仕方を振り返って、日々改善し、状況を把握すること、チームメイトのクセを知る事によって、集まったメンバーが、チームになり、スプリントを重ねる毎に強いチームに育って行きます。　これら全てスクラムの原則に通じるものもあります。 これらの考え方を、組織全体に越境することで、プロダクト開発しやすくなっていきます。その越境する際にどうしたか？というお話をしたいと思います。

DevLOVE X

開発効率が上がり、チームの絆が深まり、仕事に対する当事者意識が芽生える――。こうした効果が見込めることから採用する企業が増えているスクラム開発。そんなスクラム開発の思想をオフィス設計に取り入れ、理想のワークスペース作りに挑んだのが、恋愛・婚活マッチングサービス「Pairs」や、カップル向けのコミュニケーションアプリ「Couples」の提供で知られるエウレカだ。 スクラムに最適化した「オフィス」とはいったいどのようなものなのか、なぜ、どのようにして作られたのか、どんな効果があったのか――。同社CTO室室長（取材当時）でスクラムマスターとしてアジャイルコーチも務めるプリンシパルエンジニア、梶原成親氏に聞いた。 アジャイルとスクラムで「強く自律的なチームを目指す」 2012年10月から「Pairs」や「Couples」を提供してきたエウレカは、今や日本のみならず韓国や台湾でもサービスを提供してい

はじめにメルカリUK版の立ち上げを終え2018年3月に帰国しました@tsumujikazeです。今は東京でメルペイのProduct Managerをしています。 イギリスではいわゆるモダンなプロダクトチームでのLeanなプロダクト開発を経験しました。得るものが多かったので、なるべく多くの人に知ってもらいたいと思いこのポストを書きました。 PMF　→リーンプロダクトのプロセス　→モダンなプロダクトチーム（組織論）という流れになっています。 はじめに 本編 ・何のためにプロダクトを作るのか ・プロダクトマーケットフィット ・PMFピラミッド ・要件定義フェーズのリーン化 ・モダンなプロダクトチームでのリーン開発とは おまけ ・Problem Space vs. Solution Space ・Problem Solution Fitとは ・エンジニア組織とPM組織の特性について ・バリュープロ

優れたチームをつくる鍵は「心理的安全」だという事実を突き止めたグーグルでは、どのようにしてそれを社内に広めていくことができたのか。昨日の記事「グーグルが4年にわたる研究の末に辿り着いた『完璧なチーム』をつくる法則とは」の続きを掲載します。 グーグル社内の数百のチームを研究して、成功するチームと停滞するチームの違いを見つける「プロジェクト・アリストテレス」にとって、「心理的安全」の研究こそ、成功に不可欠な規範を指し示すものだった。 チームの明確な目標設定や、信頼し合う文化の創出なども、同じくらい重要に思えたが、グーグル社内のデータは、有用なチームを作るには心理的安全が他の何よりも大事であることを示していた。 「心理的安全を確立する環境をみんなに作ってもらわなければならなかった」とプロジェクトの主任研究員であるジュリア・ロゾフスキーは言う。だが、まだ明確な方法がわかっていなかった。 「グーグル

The Agile Guild(TAG) Advent Calendar 2018 12日目 の記事です。 今年はTAGの活動に参加して チームの大切さをより一層感じているところです。・目的を共にする仲間がいる心強さ ・目的を共にするからこそブレない方向性 ・目的のために進む推進力まだ見ぬその先の景色を見たいから 仲間を信じて目的に向かう そんなチームをつくりたい。つくろうとしているよ。というお話です。 (偶然にも仕事でチームを作るタイミングと重なったこともあって) TAGへの参加でさらに加速しつつある、そんなこれまでの活動を振り返っての感想戦です。 (チームとしてはまだまだ立ち上がったばかり。いや、立ち上がろうとしている最中) チームで強くなりたい、チームで成果を出したい個が成しえないことも、チームならできる。 もっと大きな成果を出すために。 そう願っていた2016年頃 自部署のチームは

The Agile Guild(TAG) Advent Calendar 2018 11日目 の記事です。 The Agile Guild(TAG)に参加してからの数ヶ月を振り返ります。 TAGに興味を持たれている方、 TAGだけでなくコミニティに参加したけど、次のすることが見つからずお困りの方の参考になれば幸いです。 ■ 扉を開ける2018年7月20日TAGキックオフイベントへ参加しました。コミニティーのイベントや勉強会への参加ははじめてのことです。 いままで、このようなイベントに参加したことがなかったのですが、TAGのキックオフイベントだけは参加してみようと思ったのは、一冊の本（「カイゼン・ジャーニー」）との出会いが大きかったと思います。 「それで、あなたは何をしている人なんですか？」本書に出てくる、この問い。 この問いに対する満足できる答えを見つけるために、開けた扉です。 ■ TAG

デザイン思考は、問題を探索・解決するための方法です。リーンは、私たちの信念を試し、適切な成果につなげる方法を学ぶためのフレームワークです。アジャイルは、ソフトウェアの変化していく状況に適応するための方法です。 デザイン思考は、能力と学習に関するものです。スタンフォードd.schoolのCarissa Carter主任は、デザイナーを高める能力について、素晴らしい記事を書いています。たとえば、曖昧さ、共感的学習、統合、実験などが、その能力として挙げられています。意味を生み出し、問題の枠組みを設定し、潜在的な解決策を探索する、デザイナーの能力が重要なのです。 『誰のためのデザイン？』の著者であるドナルド・ノーマンは「デザイナーは最初のアイデアに満足しない」と述べています。あなたも考えてみてください。最初のアイデアが最高のアイデアだったことはありますか？意味や新しいアイデアが生まれるのは、物事を

みなさんこんにちは。@ryuzeeです。 弊社ではアジャイル開発、スクラムのトレーニングを提供しているのですが、トレーニング中には多くの質問をいただきます。 今日はよくある質問とその答えについていくつかご紹介したいと思います。 なお、過去2回のものは以下になります。 アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (1)アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (2)好評そうだったら続編も書く予定です。 ■以前のスプリントで作成したインクリメントにバグを発見した場合には、修正はどのように扱えばよいでしょうか？スプリント内で開発しているプロダクトバックログアイテムに関するバグがそのスプリント中に見つかったのであれば、そのスプリントの開発作業の一環として修正します。そのバグの内容が完成の定義を満たしていない場合は、成果とはならず、そもそもスプリント

見積もりができない。どうする？ 見積もりって大事ですよね。見積もりは何のために行なうものでしょうか？開発が終わるかどうかの見立てを立てたい。そうですね、たいてい使えるお金と時間には制約があるので、やろうとしていることが本当に完了できるのか、誰しもが把握しておかなければならないことでしょう。それに、開発チームにとってはペースを掴むためにも見積もりは必要ですね。 では、見積もりが出来ないような場合、一体どうすれば良いでしょうか。「どうすれば」の前に、そもそも「見積もりが出来ない」とはどういう時でしょう。 例えば、何をつくるべきかいまひとつ理解できていない状況なのかもしれません。そうならば、プロダクトバックログの詳細化に取り掛かりましょう。 いや、つくるべきものは分かっている。それこそ受け入れ条件も分かっている。でも、どう作ればいいか分からないような状況かもしれません。そうならば、方式の検討や設

15. ✕ よくない着手の仕方 担当 TODO DOING DONE Task: Configure database and SpaceIDs for Trac PBI #1 PBI #2 PBI #3 猿田 Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Owner: Sanjay Time Remaining: 4 hrs Owner: Sanjay Time Remaining: 4 hrs Owner: Sanjay Time Remaining: 4 hr