こんにちは。BASE BANK株式会社 Dev Division にて、 Software Developer をしている東口（@hgsgtk）です。私のいる開発チームでは、アジャイル開発の考え方・取り組みを取り入れています。アジャイル開発の導入については、「小さなチームが始めたアジャイル開発」という資料を公開しています。 今回は、アジャイル開発において、重要な振り返りについて、Mad Glad Sad(喜、怒、哀) というレトロスペクティブ（振り返り）のワークを紹介したいと思います。 TL;DR Mad Glad Sad(喜、怒、哀)は、感情データを集めるためのワーク イテレーションで起きた、喜んだり、怒ったり、哀しかったりした時間やイベント、を書き出していくイベント 素直な感情ベースでイベントを振り返ることで、 "理性のフィルター"で見つからない潜在的課題をチームが見つける きっかけに

2021-12-17 Harajuku.ts Meetup #1

株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575

機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針

はじめに私は2006年新卒でリクルートに入り、2009年にDeNAへ転職をしました。 当時のDeNAは今より社員数も少なく、まさに”ベンチャー企業”という感じでした。 初めてのベンチャー企業は、1社目とは全く異なる世界でした。 入社して半年間は使い物にならず、 君は今のところコストだね とフィーバックいただいたことを覚えています。 その後8年間DeNAに勤めるわけですが、初めてベンチャー企業に入る人は自分と同じような苦労をしていることに気づきました。 そして、その人たちが”コスト”を脱却し活躍するときは、前職のマインドセットがベンチャー企業用に切り替わった瞬間です。 今やたくさんの業界・業種からベンチャー企業に移る人がいます。昔よりも随分増えました。 初めてベンチャー企業に行く人、その人の転職を支援する人、その人を受け入れるベンチャー企業の人のために、ベンチャー企業に入る際に身に着けるべき

## 今回発表したイベントについて PeerQuest Inc. （ https://peer-quest.jp/ ）様主催の、#開発PM勉強会（ https://twitter.com/search?q=%23%E9%96%8B%E7%99%BAPM%E5%8B%89%E5%BC%B7%E4%BC%9A&src=typed_query ）の第7回目のイベント、「要件定義どうしている？共有LT」で発表させていただきました。 株式会社Speee プロダクトマネージャー 塚本尚 https://peer-quest.connpass.com/event/229463/ ## 発表した内容について 結局行き着いたのは、（あるある話だとは思いますが）**whyとwhatの定義をしっかりす定義すること** でした。 その過程で多くの失敗をしたので、当時私がやってしまった要件定義時の失敗について発表し

マネーフォワードでは、THE GUILD代表の深津貴之さんをアドバイザリとして招き、日頃からサービスデザインに関する助言をいただいております。 先日は、社内のサービス開発力の底上げを目的とし、フィッシュボーン図を使った課題整理のワークショップを行っていただきました。 PM、デザイナー、ビジネスのメンバーを中心に、100名近くが参加しています。 今回はそこで学んだ内容をご紹介します。 表面的に対処してしまう問題 プロダクト開発の現場には、日々さまざまな要望が届きます。 それらに対処する際に気をつけたいのが「表面的に対処してしまう問題」です。 例えば次のようなケースです。 ユーザーが「検索機能を強化してほしい」と言ったので、パワフルな検索オプションを搭載しました。ユーザーの声にそのまま従っており、その背景にある課題は分からないままです。 機能は追加したが効果がでなかった、効果がよくわからない、

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。Yahoo! JAPAN研究所で快適に操作できるUIを作るといったインタラクション分野の研究をしている山中です。 この記事では、リンクやボタンの大きさに基づいてタップの成功率を推定するモデルについて解説します（国際会議ISS 2020で発表した研究成果です [1]）。 このモデルを活用すると、アプリやウェブページのデザインをするさいに、デザイナーが経験的にボタンやリンクの大きさを設定するのではなく、「リンクがこの大きさであれば95％の確率でタップできるから十分だ」などと操作性に基づいてユーザインタフェース（UI）を設計できるようになります。 タップの成功率を推定できると何が嬉しい？ スマートフォンやタブレットPC向けの

<> 2024.1.11 みなさんも編集可能・かつさらに使いやすくなった「コミュニティ版」をリリースしました。 是非そちらもご参照ください！ https://qiita.com/viva_tweet_x/items/f4db2c923d474f67fe0f 古今東西のふりかえり手法を集めています。 pdfをダウンロードしてお使いください。 詳細な利用方法や更新履歴は以下をご覧ください。 https://qiita.com/viva_tweet_x/items/cc3bad3bd298406b6cc7

みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え

こんにちは、kintone.comのバックエンドエンジニアをしている@ueokandeです。 いきなりですが、メールって難しいですよね。 普段HTTPに慣れていると、メール周りのプロトコルの理解は難しく、トラブルにも見舞われることも少なくないです。 またメールプロトコルの性質上、メールを送った後にもトラブルは起こりがちです。 グローバル向けkintone.comはAWSで運用しており、メールの機能はAmazon Simple Email Service（SES）を利用しています。 この記事ではkintone.comのメール基盤の全貌と、Amazon SESを利用する上での運用プラクティスを紹介します。 kintone.comとメール kintone.comでは、ユーザーの招待やkintone上の更新を知らせるためにメールを利用し、メール送信は重要な機能の1つです。 kintone.comは

プロダクト作りにおいて、開発したプロダクトがユーザーにとって価値提供が成り立つのかを検証する作業のことをプロダクトマーケットフィット（PMF）と呼びます。これもふわりふわりとした概念で、元々はBenchmark Capitalの創業者であるアンディー・ラフレフ氏が以下のように定義しました。 「PMFとは強力な価値仮説を見つけることである。価値仮説とは、なぜユーザーや顧客があなたのプロダクトを使うのかを説明しうる重要な仮説のことである」 プロダクトを作る新規事業において、まず目指すのはPMFになります。最小限のプロトタイプ（MVP）をユーザーのフィードバックを受けながら改良し、「使いたい」と思わせること、そしてそれが多くのユーザーに適用可能な「強力」であることになります。 過去を振り返り、B2BのPMFプロセスを考えてみる 僕のいくつかの経験を思い返してPMFまでの流れを言語化してみます。

September 15, 2021 @ iCARE Dev Meetup #25

こんにちは。クックパッド デザイン戦略本部長の宇野です。 いきなりですが「ユーザーファースト」って良い言葉ですよね。サービスのあり方の基本であり、モノづくりをしていてそれを無視したいという人はいないはず。 しかし僕はこのユーザーファーストという言葉をあまり使わず、使う際は慎重に取り扱うようにしています。この言葉の概念はとても難しいと考えているからです。 「ユーザー」って誰のこと？目の前にいるユーザーの話をそのまま取り入れれば必ず良いものが作れるの？ 答えは明確にNoです。 当然ですが無視するべきという話ではありません。ただ、向き合ってるユーザーがどんな人なのか、その人が本当に欲しているものは何なのかを徹底的に考え抜く必要があります。 お問い合わせをしてきている人はだれ？ ユーザーからのご意見やお問い合わせ、アプリストアのレビューはとてもありがたいですよね。そこから新たな改善案をもらったり、

日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能

みなさんこんにちは。@ryuzeeです。 スクラムに限らず開発プロセスそのものは目的を達成するための手段に過ぎないので、定義されたプロセスやプラクティスを単に守れば良いというわけではありません。 根底にある価値観や原則を理解することが重要です。 とはいえ、自分たちのプロセスが定義されたもの、一般的なものとどれだけ違うかを知ることは、改善のキッカケにもなります。 今回、スクラムチームが、自分たちの仕事のやり方を改善する際に参考にできるような、セルフアセスメントのチェックリストを作ったので共有します。 現時点では単なる試作品なので、ご利用は自己責任でお願いします（この記事に限らず当サイトの記事を参考にする場合も同様です）。 使えそうなら適宜更新していく予定です。 観点はスクラムの主要要素（3-5-3）にしています。フィードバックなどがありましたら、@ryuzeeまでお知らせください。 使い方使

mROS 2: yet another runtime environment onto embedded devices

pmconf2021登壇スライド。 Rettyがプロジェクトマネジメント一辺倒な組織から、アウトカムドリブンな開発ができるプロダクトマネジメントが根付いた組織に至るまでの成長の経過について。 具体的な取り組みの一例を挙げると、私たちは力のあるプロダクトマネージャーを育てるために、PMのスキル定義や評価制度を導入しました。 この試みによって浮き彫りになった課題、チームに不足していたロードマップ作成、UXリサーチ、データ分析などのスキルをどの様に向上していったのか具体的な取り組みもご紹介します。 Rettyが組織としてユーザーさんと飲食店さんにアウトカムを届けるために日々悪戦苦闘してきたストーリーが、皆さんのプロダクト組織の「非連続な」成長の参考になれば幸いです。

Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://soudai.hatenablog.com/entry/2017/06/03/183508 - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://speakerdeck.com/twada/worse-is-better-understanding-the-spiral-of-technologies-20

はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り