目標設定の基本
NTT Com Open TechLunch #7「エンジニアリングマネージャー と 目標設定」の登壇資料です。20分くらいの短いセッションなので網羅的ではありません 2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2
最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。 前提 どこでも必要とされたスキル データマネジメントに関する概要レベルの知識と実行力 セキュリティや法令に関する知識 事業ドメインに関する興味関心 他職種とのコミュニケーション能力 コスト管理 / コスト削減のスキル ソフトウェアエンジニアとしてのスキル DataOpsやアラートのハンドリング能力 分析用のSQLを書く力 古いテーブルやデータパイプラインを置き換えていくスキルや胆力 あるとやりやすいスキル 関連部署の動きを何となく把握しておく力
『みんなで小さく区切ってやる』とは『みんなで小さく区切ってやる』は複雑な問題を解決するためにみんな（チーム）で一緒になって改善していくためのやり方です。 『みんなで小さく区切ってやる』で大事な考え方は『経験から学ぶ』と『ちょっとずつ進める』です。小さく区切ることで、ちょっとやってみて、それから学び、またちょっとやってみる。それを繰り返しながら進みます。 『みんなで小さく区切ってやる』を上手にするには『見える化』『チェック』『改善』の3つが重要です。これにより『経験から学ぶ』効果を高めます。 機会を作る『見える化』『チェック』『改善』を取り入れるために5つの機会を設けましょう。これらの機会は毎回同じ時間に行うことでリズムが生まれいい感じになります。 『区切り』があることで立ち止まれます。立ち止まることで落ち着いて『チェック』し『改善』することができます。この『区切り』は1週間もしくは2週間に
こんなプロジェクトは「炎上」する。PM界きってのトラブルシューターに学ぶ、“火種の種類と火消しテク” - ミーツキャリアbyマイナビ転職
度重なる期日の延期、お客さまの「激怒」、クリティカルな問題の発覚……。 多くのプロジェクトマネージャー（以下、PM）が最も恐れるのは、そんな「炎上」でしょう。巻き返しを図るものの、逆に現場に負担をかけたり、混乱を招いたり。その結果、品質が大きく下がってしまう、あるいはサービスイン（新しいサービスを開始すること）に間に合わないなんてことになれば、PMとしての信用は大きく損なわれてしまいます。 そうしたトラブルをうまく収め、プロジェクトを無事に着地させるには、どのような心構えや技術が必要なのでしょうか？ 今回お声がけしたのは、日本IBMやパナソニックなどで、PMとして数えきれないほどの炎上プロジェクトを解決してきた木部智之さん。日本IBMではPMのグローバル最高位である「シニア・コンプレックス・プロジェクト・マネジャー」に認定された生粋の「火消し屋」です。 そんな炎上対応のプロフェッショナルで
はじめに こんにちは、株式会社カケハシでエンジニアリングマネージャーをやっている小田中（ @dora_e_m ）です。 今回は、タイトルの通り「日報を書くといいよ！」、とくに「組織のニューカマーにはオススメだよ！」という話を書きます。 日報って何? まず、日報とは何でしょうか。一般には、日々の業務内容や進捗などを報告する文書を指します。 この定義に従えば、受益者は報告される立場の上長であり、日報を作成する当の本人にはあまりメリットがありません。 私自身、ただ進捗を共有するだけの日報にはあまり意味を感じません。たとえばJiraなりTrelloなりで進捗管理している現場であれば、そのうえで進捗報告のための日報を作成することは作業の重複、情報の二重管理の発生を意味します。 ですが、日報を以下の目的で作成するようにすると、それは作成者本人にとって役立つものにできます。 毎日のふりかえり 思考プロセ
モチベもやる気もないのに転職もしない。「リゼンティーイズム」してませんか？ #TrendBuzz | ライフハッカー・ジャパン
「リゼンティーイズム」とは？2023年1月にイギリスで使われはじめ、欧米諸国に広まってきているリゼンティーイズムという言葉。 「Resent」とは疎む、または不服に思うこと。それを「Presenteeism（プレゼンティーイズム）」という別の言葉とかけ合わせた混成語。 現在の仕事や職場が嫌いだが、より良い就労機会を見つけることができない、あるいは経済的な必要性にしばられているために離職できず、働き続けざるを得ない状況を意味します。 注目される背景前出のプレゼンティーイズムは「疫病出勤」とも訳され、心身に不調をきたしながらも出社しているために、業務効率が落ちている状況を指します。 リゼンティーイズムとプレゼンティーイズムは、どちらも会社にとっては可視化しづらい損失であると言えるでしょう。 だからこそ、企業が従業員の健康を「自分ごと」として捉え、戦略的に健康づくりを目指していくうえでは、避けて
紙の本が売り切れていたので手をつけていませんでしたが、ようやく全部揃ったので読みました。 まず前提として「桜井さん凄いなあ」というのはあるんですが、気になったのが、このエッセイは国内のゲーム開発手法の課題を再生産しているのではないか？ということです。 桜井さんのエッセイには繰り返し登場する課題がいくつかあります。 ・新しいディレクターが育たない、現れない ・桜井さんが忙しい ・シリーズもののゲームが増えるなど、ゲームの新奇性が減っている このうち「新しいディレクターが育たない」ことと「忙しい」ことは同一の問題で「権限の委譲が進まない」という、多くの組織に見られる問題と言えます。 しかし、エッセイで紹介されている開発手法を見ると「そりゃ、育たないのでは？」と思わざるを得ません。キャラクターの操作感を決めるパラメータは重要なので自分が担当する、企画は初期の企画書にすべて落とし込むなど、ものすご
おことわり 最初に断っておきますが、私はスクラム開発反対の立場をとっているわけではないです。また、スクラムマスターでもないのでスクラム開発について誤った見解を持っている可能性も大いにあります。 また、これから記載するスクラム開発のペインはあくまでも筆者の独断と偏見に基づいて記載されております。そのため、ペインの原因がスクラム開発ではなく、単にその所属組織の構成員の性質や文化的な要因であることも考えられます。おそらく、スクラム開発でなくても起こり得る問題も多く挙げていると思います。そういった側面も踏まえてご意見あれば忌憚なく反論異論いただければ幸いです。 なぜこの記事を書いたか チーム内で密なコミュニケーションをとりながら、個人ではなくあくまでもチームとしての成果を重視するスクラム開発の開発フローは、割と個人の活躍と成長機会を奪ってしまい、結果として組織としても開発成果が縮小均衡になってしま
不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会
「夜中に聞こえてくる音で眠れず、イライラする」など、騒音問題に頭を悩ませている人は少なくありません。 逆に、隣部屋が音に敏感な人で、自分が立てる音に細心の注意を払いながらビクビク生活している人もいるでしょう。 最近では、趣味や仕事のために、頻繁にビデオ会議をしたり、ライブ配信を行ったりする人も増えてきました。 しかし、防音シートを部屋中に張り付けたり、部屋の中に防音室を導入したりするのは簡単ではありません。 この度、アメリカのマサチューセッツ工科大学（MIT）に所属するヨエル・フィンク氏ら研究チームは、髪の毛ほどの薄さの布地で音を最大75％軽減できる防音カーテンを開発しました。 彼らはその特殊なカーテンを用いて、「逆位相による音の打ち消し」や「布地の振動を抑えて音を反射する」ことが可能だと述べています。 研究の詳細は、2024年4月1日付の科学誌『Advanced Materials』に掲
おはようございます!こんにちは!場合によってはこんばんわ! SREチームマネージャーの藤原です。 今年の3月からSREチームの中で、勉強会を定期的に実施するようになりました。 本エントリでは勉強会を開催するにあたって考えたことと、実際の進め方についての事例解説です。 勉強会を通じて実現したいことの説明から、テーマ設定、効果最大化のための開催形態と頻度、現時点(2024/4・5時点)の結果について解説しています。 勉強会を通じて実現したいこと チーム内勉強会を通じて実現したいこととして、以下を設定していました。 チーム・個人としてのレベルアップ 積極的な議論への参加 相互理解 チームとしての目線合わせ 勉強会を開催するからには何かしらのスキルや考え方を身に付けたいはずです。 また、学習効果を最大化するためにも、積極的な議論への参加を実現したいと考えました。 さらには、勉強会の中での議論を通じ
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
みなさんこんにちは。 都内のIT企業でフロントエンドエンジニアをしてますSakuです。 ここ1、2ヶ月くらいオフィスに出社して仕事をすることが多かったのですが、そこで、「あれっ…意外と仕事が捗るな…」と感じることがあったので、そこで感じたことを整理するため言語化してつらつら書きたいと思います。 その発端としては、最近新しいプロジェクトが始まり、その開発のチームリーダーという役割もあったため、まあ折角だしオフラインでチームビルディングやどういうプロダクトにするかなどをエンジニア・ビジネスサイドのメンバーと話し合うのも良いかなと思い、軽い気持ちで他のメンバーにも声をかけて出社の機会を作ってもらったのが始まりです。 それから週に何日かは出社して仕事をしていたのですが、ある時ふと思ったのが、冒頭で感じた意外と仕事が捗る感でした。 本題に入る前に、話は4年前に遡ります。 コロナ禍で生活が変わった 昨
私たちはスクラムを採用していて、プロダクトオーナーの私と、3人の開発者、そしてスクラムマスターというチームでやっている。 初期段階の頃は、頭の中のユーザーストーリーを開発者に伝えるのをめちゃくや丁寧にやっていた。 リファインメントでたくさん会話して、バイブスを伝えることに多くの時間を費やしていた。 たくさんの会話をしそれを簡潔にテキストに落とし込みバックログを完成させていた。 プランニングの時も開発者の帽子を被り、必要があったら口を挟みつつラジオ参戦していた。 数ヶ月も一緒にやっていると「今ある機能をもっと良くするならこうだよな」というのが開発者の中に思い描けるようになっていたし実際合っているので、リファインメントでたくさんの会話しなくても「あとはお任せ」の様にやれるようになっていた。 バックログを積み、リファインメントで意思疎通できてるな、ヨシ、をシュッと確認して、その後のテキストへの落
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
はじめに こんにちは！NewsPicksのVP Of Mobile Engineeringの石井です。 約1年前にPharmaXさん主催の「事例で学ぶ！エンジニア組織文化を作る採用・評価の仕組み」というイベントでPharmaX 取締役・エンジニアリング責任者の上野さん、カオナビCTOの松下さんと私の3人で事例発表やパネルディスカッションをしました。（そのときの記事は、PharmaXさんのこちらの記事にあります） このときに私が話したエンゲージメントに関することは、「採用とオンボーディングを頑張った結果、エンゲージメントもよくなりました」的な話もしました。 ただ、それ以外にも多くのことをしています。今回はそこを深掘りしたいと思います。 以前の状態との比較 当時、発表した時のモバイルチームのエンゲージメントは次の通りでした。（NewsPicksでは半期に一度、サーベイをしています） で、202
2019年にアップルを去ったジョニー・アイブ氏（左）とティム・クック最高経営責任者（ＣＥＯ）（右） Photographer: David Paul Morris/Bloomberg アップルを代表する製品のデザインをかつて手がけたジョニー・アイブ氏。同氏が率いた伝説的なデザインチームは、アップル脱出をほぼ完了した。 非公開の情報であることを理由に匿名で話した複数の関係者によれば、今では数少ないアイブ氏の元同僚、ダンカン・カー氏が近く退社する意向をアップルに通知した。1999年入社のカー氏は、数世代にわたるスマートフォン「iPhone」やタブレット端末「iPad」、パソコン「Mac」の開発に欠かせない人材だった。 アップルの広報担当者はコメントを控えた。 カー氏の退社によって、かつてアイブ氏が率いた20数人のチームはほぼ完全に消失する。2019年にアイブ氏がアップルを去った後、トップデザイ
はじめてのプロジェクトマネジメントでやりたい放題した結果
株式会社プラハは2022年、株式会社アガルートによるM&Aで子会社となりました。 この変化の一環として、アガルート社長自らがプロダクトオーナーのひとりとして参加する新規プロダクト開発が始まりました。プロダクトの開発はプラハの私たちが担当し、私も「開発チームのリーダー」としてそのチームに加わることになりました。 私はこれまで開発メンバーとしての経験しかありませんでしたが、エクストリームプログラミングとかレガシーコードからの脱却とかめっちゃ好きで、本で学んだプラクティスをリーダーとして実践できる機会が与えられて最高にハッピーでした。しかも、プロダクトオーナーの一人として参加するアガルート社長はこれまで伝統的な開発手法しか経験したことがないとのことで、新たな開発の進め方を経験してもらう絶好の機会でもありました。 やったこと 「欲しい機能一覧」を受け取ったが、いったん白紙に戻した プロジェクトが始
以前、シフトレフトのために静的テスト、動的テストの2つのアプローチからどんなアクションを取れるかを記事にしました。 上記記事で書いたように、以前までのwith QAチームではテスト設計以降の作業を重視せざるをえず、上流工程でのテスト活動を明文化できていませんでした。しかし、メンバーの増強とユニット制への体制移行により、より上流工程から積極的にQAが関わっていけるようになりました。 その中でQAとして何ができるとよいのかを考えた結果、より積極的にテスト活動が行えるようテストプロセスを詳細化することにしました。具体的にはwith QAチームでは新たにレビューとテスト分析をテストプロセスとして明示することになりました。1 今回は、このレビューとテスト分析を中心に、実際に何が変わったのかを書いていきます。 前提の確認 本題に入る前に、レビューとテスト分析とは何かという確認から行います。 「レビュー
こんにちは、 freee でエンジニアリングマネージャーをやっている sentokun と申します。 4 月になり、新人や中途入社など新メンバーの参入など、チームの変化を感じている方も多いのではないでしょうか？ この記事では、そんな新メンバーの受け入れ時に、チームで大切にしたいと思う心構えについて記載していきます。 人と環境には相性がある！焦らずその人にあったペースで 新メンバーは、チームに参画する際とにかくできるだけ早く環境に慣れて成果を出したい！と考えると思います。特に経歴がある中途入社だと、本人は経験がある分早く成果に繋げられるはず！と考えるし、受け入れ側の視点でも、経験豊富なんだから早くキャッチアップしてくれるはず！と期待するかもしれません。 もちろんスタートダッシュが決めれれば大きいですし、そのために全力を尽くすことは大事だと思います。一方で、うまくいかない場合の大事な心構えもあ
はじめに 本書『Observability Engineering』は、複雑化の一途をたどる現代のソフトウェアシステムに立ち向かうための、強力な武器となる一冊であり本稿はその読書感想文です。Observability Engineering を今から知りたい方はもちろん、Observability Engineering の基礎を改めて学びたい方もぜひお読みください。この記事もかなりの長さになるので普通に書籍を読んだほうがいいかもです learning.oreilly.com 「Observability:可観測性」という言葉は、近年ソフトウェアエンジニアリングの世界で大きな注目を集めています。しかし、その概念の本質を理解し、実践に移すことは容易ではありません。 本書は、そのオブザーバビリティについて、その基本的な考え方から、具体的な実装方法、そして組織への適用まで、幅広くかつ深く解説して
AIで生成した画像を使った漫画の著作権がアメリカで物議を醸したり、漫画の設定やあらすじを提案してくれるAIサービスが登場したりと、AIは絵やイラストの生成だけでなく漫画作品の制作にも活用されるようになってきています。中国のByteDanceと南開大学の研究チームが、ストーリーのある漫画を出力できるAIモデル「StoryDiffusion」を発表しました。 StoryDiffusion: Consistent Self-Attention for Long-Range Image and Video Generation https://storydiffusion.github.io/ StoryDiffusionは、統一感のある漫画キャラクターを出力することが可能です。例えば、以下は上からコマドリ、リス、ハリネズミのキャラクターを、左から順に「ベッドで起きる」「朝食を食べる」「道路にいる
はじめに こんにちは、土屋と申します。バニッシュスタンダードで社内システム保守とスクラムマスターを担当しています。最近の趣味は早朝にゼルダの伝説ティアーズオブキングダムをプレイすることです。なかなかハイラルが平和になりません。トーレルーフ!! ところでみなさんスクラム開発しっくりきてますか?完璧ですか?心酔してますか? 僕は開発メンバーとして何度かスクラム開発を経験してきましたがどうもしっくりきませんでした。ウォーターフォールやデスマーチしていたあの頃に戻る気はないけど、とはいえ良さが理解できない。こんな印象が拭えないままスクラムマスターになってしまいました。 でも。こんな僕でもスクラム開発とちょっとだけ仲良くなれた気がしてきました。スクラム開発と仲良くできない、しっくりこない、そんな方に向けて1つの情報になれば幸いです。 スクラムマスターになった経緯 昨年末、スクラムマスターだった dk
チームの生産性と向き合う
こんにちは @glassmonekeyです。 Ubie 株式会社に転職してあっという間に二ヶ月が立ちました。 現在私は toC 向けのアプリケーションに配信する施策を入稿・管理するシステム「案件管理システム」の開発チームに所属しています。 そのチーム内で現在、私はテックリードというロールで、日々の開発を一人のエンジニアとして進めつつもチームの生産性改善、技術的な意思決定のファシリテーションなどに取り組んでいます。 今回のエントリでは、何かと話題となるエンジニアリングの生産性ですが、テックリードとしてどのように向き合ったのか、どのように改善し今後どうしていくのか？を紹介します。 生産性の定義 前提として生産性を正しく計測することは難しく、それこそ生産性を下げる行為だと私は考えています。 @hiroki_daichiさんの開発生産性について議論する前に知っておきたいことに詳細は譲るとして、一般
サイバーセキュリティチームでマネージャーをしている岡地と申します。本記事では、いま話題（！？）の脅威モデリングを参考に実施した、社内のセキュリティリスク分析について紹介させて頂きます。 サイバーセキュリティチームについて 私は2022年12月にウェルスナビにジョインし、2023年はコーポレートIT部門でセキュリティ担当として従事してきました。2024年1月からサイバーセキュリティチームとして独立し、チーム戦略の策定から始めているのですが、その中で改めて感じたのが、自社のリスク認識の解像度が不十分だということです。別の表現でいうと、自社のセキュリティのカタチがいまいちわからない状態でした。 この段階でも、過去からの経緯で認識できている課題や昨今のトレンドを踏まえた計画の策定も可能ではあるのですが、より精度の高い戦略を立てるためには、自社環境に対する解像度を上げる必要があると感じました。 自社
「楽」する前のTerraformバージョンアップ方針と運用整理（とポエム） - 東京ガス内製開発チーム Tech Blog
はじめに、はじめまして。リビング戦略部SREチームのあおしょん（本名：青木）と申します。 2024年4月1日から弊チームにジョインしたピチピチの新人*1です。 入社から約一ヶ月過ぎまして、現在も盛りだくさんの情報量と圧倒的当事者意識を持っている弊社の優秀なエンジニアたちに日々圧倒されながらも一刻も早く事業に貢献出来るように歩を進めています。 大きな貢献が出来ている、とは未だ胸を張って言えないのですが入社したてで業務知識が無くてもまずは小さい貢献からコツコツと始めてみよう、ということで弊チームにおけるTerraformバージョンアップの方針と運用について整理したのでご紹介いたします。 ご紹介の前に申し上げておきたいこととして、今回はバージョンアップの運用をこんなテッキーなことをしてクールに自動化してやったぜ～ワイルドだろ～という内容ではございません。あくまで現状はこうなっているからこういうこ
プロダクトの機能・データについて理解を深める「輪テーブル会」の紹介 - Techtouch Developers Blog
はじめまして、テックタッチで DataEnabling チームのエンジニアマネージャーをしているtaker です。 DataEnabling チームでは、社内の様々な組織のデータ活用をより推進し、プロダクト開発やカスタマサクセスを強化するためデータ基盤の改善や社内からの様々な依頼について日々取り組んでいます。 この記事ではそんな私達のチームが、チーム内でデータに関する知識を共有するプラクティスについて共有させていただくため、一筆したためました。 はじめに 取組内容について 進める上で気をつけている点 実施した結果良かったこと 終わりに はじめに データ活用を進める上では、プロダクトのデータ構造や機能とデータの対応関係について精通している必要があります。 例えば、カスタマーサクセス（CS）から「 xx の機能を有効にしている顧客数を知りたい」という問い合わせがあった際「 xx の機能」が「ど
こんにちは、プロダクトマネージャーの yujiro です。 最近 Nintendo Switch を購入し、妻と一緒にスーパーマリオをプレイしてます。数少ない共通の話題が増えて嬉しいです。 はじめに 前提：テックタッチはハイタッチCSに支えられている 「 Showcase 」とは 事前準備 開催当日 得られる効果 さいごに はじめに テックタッチではおよそ3ヶ月に1度の間隔で新機能をリリースしており、その際にリリース内容共有会を開催してリリース内容の社内周知を行っています。このリリース内容共有会を社内では「 Showcase 」と呼んでいます。 この「 Showcase 」は、リリース内容の説明に留まらないプロダクトチームとビジネスチームをつなげるユニークなイベントになっています。本記事では、「 Showcase 」を通じてどのように両者の距離を縮め、一体感のあるカルチャーを生み出している
はじめに どうも、元QAのエンジニア @Syahu_Writer です。 今回は、元QAが開発チームにjoinしてから行った品質向上のための施策について紹介していきます。 大なり小なりいろいろとやってますが、代表して以下3つを話します。 ・開発プロセスの改善 ・シナリオテストケーステンプレートの改善 ・不具合の再発防止 開発プロセスの改善 以下は当初の開発フローを図に書き起こしたものです。 この図から読み取れる問題点はざっくりと、 ・すべて直列のフローだが、並列処理にしていいものも混じっている ・テスト完了レビューといった、不要で実際に行われていないものがある ・レビューのタイミングが悪く、大きく手戻りが発生する箇所がある という状態でした。 それを以下の通り修正しました。 ・並列にして問題ないものは並列にする ・不要なプロセスは削除する ・手戻りが最小限となるようにレビューを設置する ま
こんにちは、プロダクトエンジニアのa2cとプロダクトマネージャーのdaisukeです。 本稿では、2024年1月に組成され、スクラムを採用した私たちのチームが最初の3ヶ月間に直面した課題とその改善策、それによってもたらされた変化を共有します。スクラムに参加するエンジニアとPMの多様な視点を取り入れ、実際の経験に基づく具体的な事例をオープンに紹介します。 なお、この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。ぜひ他の記事もご覧ください。 チームの紹介 PM1名・プロダクトエンジニア3名の計4名がコアとなり、価値提供に責任を持ちます。そのコアチームに兼任のプロダクトエンジニア(チーフ)1名・兼任のプロダクトデザイナー1名が加わりチームを構成しています。専任のスクラムマスターはいません。 担当しているプロダクトとプロジェクトは、SmartHR Plu
Webフロントエンド版DX Criteria (v202402)/プロダクトのユーザー体験と変化に適応するチームのためのガイドライン
Webフロントエンド版DX Criteria (v202402)/プロダクトのユーザー体験と変化に適応するチームのためのガイドライン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
複数の企業でデータエンジニアとして求められたスキル - yasuhisa's blog
『みんなで小さく区切ってやる』ガイド｜kawanotron
日報を自分のために書いてみよう - KAKEHASHI Tech Blog
「桜井政博のゲームについて思うこと」を読んで思うこと｜Jey.P.
スクラム開発がエンジニアから成長機会を奪うかもしれない話 - 開発日報
これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと クリエイティブな仕事に求められる“アジャイル思考”
髪の毛ほど薄いのに音を75％カット！MIT開発の「革新的防音カーテン」 - ナゾロジー
チーム内勉強会の進め方事例 - MNTSQ Techブログ
プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita
最近出社して対面で会話することが多くなった結果、生産性に繋がりそうな会話があった話3選
「知識の呪い」、チームメンバーと以心伝心しているという思い込み - #あすみかんの上にあすみかん
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
エンジニア従業員エンゲージメント向上への道 - Uzabase for Engineers
アップルでまた１人デザイナーが退社－伝説のチームほぼ消滅
テストプロセスを詳細化した話 - レビュー・テスト分析 - Qiita
新メンバーを受け入れる際に大事だなと思う心構え - freee Developers Hub
もう一度読むObservability Engineering - じゃあ、おうちで学べる
ストーリー性のあるマンガを自動生成するAIモデル「StoryDiffusion」
スクラム開発が全然しっくりこないまま スクラムマスターになってしまった僕が取り組んだこと
脅威モデリングを参考に、社内全体のセキュリティリスク可視化を試みた話
組織の一体感を生み出すためのリリース内容共有会とは？ - Techtouch Developers Blog
元QAが開発チームにjoinして品質向上を試みたこと3選 - Qiita
ぼくらのスクラム奮闘記 - SmartHR Tech Blog