2024/06/22にScrum Fest Osaka 2024 品川&葛飾トラックで発表させていただいた資料です。 Scrum Fest Osaka https://www.scrumosaka.org/ プロポーザル https://confengine.com/conferences/…
スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
2024/06/22にScrum Fest Osaka 2024 品川&葛飾トラックで発表させていただいた資料です。 Scrum Fest Osaka https://www.scrumosaka.org/ プロポーザル https://confengine.com/conferences/…
可能性が未知数だからAI導入は無理、なんてない。ー従業員の71.8%が「生成AI」を業務に活用。LIFULLが描く未来の住まい探しとはー｜LIFULL STORIES
LIFULL全体の最高技術責任者（CTO）である長沢翼は、2022年11月に公開されたOpenAI社の対話型生成AI「ChatGPT」に「人とシステムのインターフェースが変わるかもしれない」と、時代の大きな変化を予感したという。そして長沢は2023年5月に生成AIに特化した専門チーム「ジェネレーティブAIプロダクト開発室」（現在は「ジェネレーティブAIプロダクト開発U」に名称を変更）を設立。以降、社内の業務効率化やLIFULLの事業に生成AIの活用を推進してきた。 LIFULLにとって既に良き仕事のパートナーとも言えるこの生成AIという技術は、どのように取り入れられ、また事業や業務にどのような変革をもたらしたのか。現在「ジェネレーティブAIプロダクト開発U」を統括するイノベーション開発室の室長も務める長沢に、LIFULLにおける生成AIのあり方を聞いた。 対話型生成AI「ChatGPT」は
実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
マネージャーが直面する困難のパターンとは？：マネジメントの熟達を「3つの階層」から考える | CULTIBASE
「部下を数字目標で縛りすぎてしまう」 「『君はどうしたい？』と部下に問いかけるものの、心の距離があるように感じる」 「管理職から昇格し、経営陣に抜擢されたがなぜかうまくいかない」 マネージャーの経験者であれば、このような悩みを抱えたことがある方も多いのではないでしょうか。 アメリカの経営学者・ロバート・L・カッツが1955年に発表した論文『スキルアプローチによる優秀な管理者への道（原題： Skills of an effective administrator ）』によると、マネージャーには３つの階層があり、その階層ごとに求められる能力が異なると言われています。 ロバート・L・カッツ「スキルアプローチ 優秀な管理者への道」『ハーバード・ビジネス・レビュー・ライブラリー』*に基づき、日本科学技術連盟による「図１. マネジメントの階層による要求スキルの変化」**を参考に作成 いわゆる古典に分類
リモートワークで新人が楽しく効率的に成長できたプラクティス - Qiita
はじめに 私のチームは、リモートワーク中心の開発チームです。 そのチームに新人が配属された時に、私のチームで行っている新人育成のプラクティスのうち、比較的ユニーク(だと思っている)プラクティスを抜粋して紹介します。 少しでも参考になれば幸いです。 リモートワークの知見を説明 新人に対して、チームで行っているリモートワークを快適に行うための知見を紹介しています。 特に、「今から通話いいですか」をすっ飛ばしてビデオ通話を開始する文化であることを共有します。 詳細は以下を参照ください。 インセプションデッキの説明 インセプションデッキとは、プロダクトづくりに関わるメンバーが各々の意見を持ち寄って共通認識をつくり出すための大事な質問に対してメンバー皆で議論して決めた回答です。 詳細は以下を参照ください。 インセプションデッキ | Agile Studio 私のチームでは、以下のテンプレートを利用し
開発チームのマネージャーとして意識しているチームのCapability - LayerX エンジニアブログ
こんにちは。バクラク申請・経費精算チームでエンジニアリングマネージャーをしているsh_komineです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、今日は最近自分が「開発チームのマネージャーとして意識しているチームのCapability 」について話をしようと思います。LayerXのテックブログでは数少ないマネジメント系の話です。 私自身、エンジニアリングマネージャー歴自体は1年ほどなので、まだまだ足りない面もあると思いますが、誰かの参考になればと思います。 開発チームとCapabilityの定義 開発チームの単位もいろいろとありますが、基本的にはチームとして意思決定し、開発活動を続ける最小単位のチームを想定しています。開発エンジニアにプロダクトマネージャー、チームによってはデザイナーやQAなども含みます。自分の場合は職能横断型のプロダクト・顧客に向き合うチームを
プロダクト開発チームの分断に立ち向かう - yigarashiのブログ
先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を
チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog
SmartHRの基本機能と呼ばれるプロダクトでエンジニアリングマネージャーをしている @sugamasao (id:seiunsky) です。 この文章はSmartHR Advent Calendar 2022の2日目のエントリーとして書いています。 はじめに、いくつか前提となる状態をお伝えすると、私の所属している「基本機能」プロダクトはScrumを拡張したLeSSというフレームワークを使っており、現在は6チームで1つのプロダクトを開発しています。 さらに、私は今はエンジニアリングマネージャーという立場にいますが、少し前まではこの6チームのうちの1チームに所属するメンバーでした。そのため、これ以降に記載している取り組みは私がチームに所属していた時にはじめたものという認識をしていただけますと幸いです。 テックな話題 #とは リモートワーク主体で仕事をしていると意識的に雑談によるコミュニケーシ
【お前のチケット】チーム開発でのチケット改善術【解読不能】 - seri::diary
Issue管理システムを使っている開発現場では同僚の書いたチケットに悩まされる以下の様な光景が良く見られます。 事例１「何の目的で作られたのか分からないチケット」 ソースレビューを振られたのでチケットを見てみたら、何を変更したいかは分かるけどこの変更がどういう意味があるのか分からないケース 担当者の対応 作業したメンバーの席まで歩いて行って 「ねーねーこれさー、何のために作ったの？」 「あーそれはですね、まず○○という話がありまして、それで…」 （背景から説明されて１５分経過） 事例２「ソースを全部読まないと何を変更したか分からないチケット」 ソースレビューを振られたのでチケットを見てみたら１０コミットぐらい入れてあるけどチケットの説明が簡素過ぎて何の仕様をどう変更したか（もしくは新規に作ったか）がソースの差分を全部読み込まないと分からないケース 担当者の対応 作業したメンバーの席まで歩い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
