プロジェクト管理はNotionしか勝たん！MLチームのスプリント管理を改善した話 - LayerX エンジニアブログ
こんにちは、バクラク事業部のMLチームでソフトウェアエンジニアをしているTomoakiです。 今回はMLチームのスプリント管理におけるタスク・プロジェクト管理にNotionの新概念であるProjectを導入してみたら嬉しいことがたくさんあったので、それらを紹介したいと思います。 イントロダクション Notionの2.30リリースでプロジェクトという概念が登場し、プロジェクトの管理のテンプレートが公開されるなど大きなアップデートがありました。 www.notion.so 本記事でも紹介しますが、このリリースで紹介されているテンプレートが優秀すぎるので、まだみてない方は是非見てみてください。 MLチームでは5月末ごろから、ちょうどスプリント管理に課題感を感じており、早速NotionのProjectを取り入れて6月中に運用してみましたかなり良かったので、本記事では我々目線でのその効果を紹介したい
みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらに
こんにちは。バクラク申請・経費精算チームでエンジニアリングマネージャーをしているsh_komineです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、今日は最近自分が「開発チームのマネージャーとして意識しているチームのCapability 」について話をしようと思います。LayerXのテックブログでは数少ないマネジメント系の話です。 私自身、エンジニアリングマネージャー歴自体は1年ほどなので、まだまだ足りない面もあると思いますが、誰かの参考になればと思います。 開発チームとCapabilityの定義 開発チームの単位もいろいろとありますが、基本的にはチームとして意思決定し、開発活動を続ける最小単位のチームを想定しています。開発エンジニアにプロダクトマネージャー、チームによってはデザイナーやQAなども含みます。自分の場合は職能横断型のプロダクト・顧客に向き合うチームを
先月のゴールデンウィークに行われた第33回世界コンピュータ将棋選手権(WCSC33)で弊やねうら王チームが準優勝したあと(この準優勝は本当に準優勝であって、ビールにおつまみで乾杯するという意味ではない)、角換りという戦型について以下のツイートをした。 角交換と言う戦型が終わった。 1886局面の指し手を覚えるだけで先手側は公開されてる水匠（探索局面数は1億までの任意）に対して評価値+300に出来ることが証明された。 大会で上位のソフトは+300から逆転は97%ぐらいありえないので（手数で引分はある）つまりは将棋AIの世界では角交換の後手は必敗。 — やねうら王 (@yaneuraou) May 8, 2023 この前者のツイートにはインプレッションが172万もあり、Yahooニュースや朝日新聞デジタルなど多くのメディアで取り上げられた。 AIで角換わりが終わった？ 藤井聡太竜王「こちらの立
株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。1回目は、開発の生産性に大きく影響する、「チームの認知負荷（Team Cognitive Load）」について。 名村卓氏のキャリア変遷 大谷旅人氏（以下、大谷）：それでは本日のメインの名村さんのお話に入りたいと思います。LayerX 名村さん、ご登壇よろしくお願いします。 名村卓氏（以下、名村）：はい、よろしくお願いします。LayerXの名村と申します。今、LayerXでEnabling Teamという、Enablementをやっている組織にいるのですが、今日はそこでの経験と諸々含めてお話できればと思っていま
Pull Requestを小さくする戦略 - 開発チームのパフォーマンス向上のための第一歩 - Agile Journey
Agile Journeyをご覧の皆さん、こんにちは。ZOZOの御立田です。 私が所属する株式会社ZOZOは、「世界中をカッコよく、世界中に笑顔を。」を企業理念として掲げ、ファッションEC「ZOZOTOWN」、ファッションコーディネートアプリ「WEAR」などの各種サービスの企画・開発・運営や、「ZOZOSUIT」「ZOZOMAT」「ZOZOGLASS」などの計測テクノロジーの開発・活用をおこなっています。また、カスタマーサポート、物流拠点「ZOZOBASE」を運営しています。 ファッションコーディネートアプリ「WEAR」やショップスタッフの販売サポートツール「FAANS」を手がける、私が所属するブランドソリューション開発本部では、「開発生産性を3倍に」を目標に掲げ、多くの改善を進めています。 「開発生産性」をどのように定義するかには議論がありますが、まず私たちが向き合ったのは「仕事量の生産
私は長年 Pull Request のコメント数が多くて何回もレビューを往復することが多くて大変つらかったが最近ものすごく単純なコツに最近きづいたのでそのことをシェアしようと思う。 Pull Requestレビューの悩みこれはならない人はならないので、共感してもらえる人は少ないかもしれないが自分の悩みは Pull Requestのコメント数でこれが本当に多い。何がつらいって、レビューのコメントが多いという事は、マージに時間が掛かるということだ。最初にコードを書いてテストして完成させるのは２時間もかかってないのに大抵レビューで何往復もして時間を取られるのが本当につらいし、進捗がでないもの嫌だし、時間かかるし、自分が最近解決したい問題の中でも筆頭の問題だった。 何が悪いのだろう？すごく嫌なので物凄く考えたがうまくいかなかった。例えば、英語のスペルミスも良くしたし、ログやコメントの英文にレビュー
この記事は freee Designers Advent Calendar の 16 日目です！ はじめまして！ freee株式会社でUX ResearchOpsをしているkonと申します。 ResearchOpsってなに？っていう話もあるのですが(これはまたおいおい書いてみたい)、今回はじめてfreee Designers Advent Calendarに参加するにあたっては、30代半ばにして中途障がい者となった私個人のfreeeでの働き方を書いてみたいと思います！ ベッドでしごと？現在私はこの記事を、自宅のリビングのベッドの上で書いています。 普段のfreeeでの業務スタイルも同じく、フルリモートで、しかもベッドに横になったまま仕事をしています。 もっと言えば、自宅への往診を利用して点滴をうけながら仕事する日もあったりします。 自宅のリビングで点滴を受けながらおしごとそれは決して無理を
Engineering Manager という仕事をしていると、自己効力感が低下する瞬間がけっこうあると感じる。(多分 Engineering に限らない Manager 一般の話も多いと思うけど、ここではその考察はしない) 仕事において自己効力感が高まる状態というのは、たいてい、自分が何か努力して、それによって目に見える成果が出ているときに生まれるのではないかと思う。ところが、Engineering Manager の仕事というのは基本的に、自分以外のみんなが成果を出せている状態をつくることで、それにより絶妙なズレが生まれると感じる。 Engineering Manager の仕事を例にあげると、個々人のサポートをしたり、チームがうまくいくサポートをしたり、チーム間のコミュニケーションラインを整えたり、チームのはざまに落ちてるタスクを拾ったり、必要な人を採用したり、ビジネスや経営から求め
「なんちゃってスクラム」に気づくためのコツ
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、開発手法として、スクラム開発に取り組んでいます。 今回は、「なんちゃってスクラム」に気づくためのコツ、というトピックで話していきたいと思います。 自分自身数年にわたり、他社の方から「スクラム開発やってる？」と聞かれたときに、「なんちゃってスクラムですかねぇ」と言い続けてきました。長らく「なんちゃって」状態だったのですが、最近個人的にそれを脱するタイミングを味わったので、その話をさせてください。 ※ そもそもスクラム開発をよく知らないという方にもわかるように、適宜スクラム開発自体の説明もしていきます。 この記事の対象読者 現在進行形で、スクラム開発をやっているが、なんか違いそうと感じている方 (前職などで)1度スクラム開発をやった経験はあるが、いまいち
いろんなやり方の読書会をやってみたら当日音読その場でまとめ方式が最高だった話 - Gunosy Tech Blog
こんにちは、SRE チーム マネージャーの TksYamaguchi です。 こちらの記事はGunosy Advent Calendar 2023の3日目の記事です。 前回の記事は森田さんの LLM 論文の探し方でした。 概要 SRE チームは、シニアエンジニアとジュニアエンジニアで構成されているチームで、チーム内の技術的な知識の偏りの解消や、知識のタコツボ化の解消を目的として読書会をしてきました。 その過程でいろいろな読書会のパターンを行ってきましたので、その結果を共有します。 概要 読書会開始前の SRE チームの課題感 読書会 のやり方の整理と評価の観点 やり方 評価の観点 当日音読・Slack に投下する方式 実際のまとめ 方式詳細 評価 メリット デメリット 事前に読んで Miro*1 に付箋・当日議論する方式 実際のまとめ 方式詳細 評価 メリット デメリット 当日黙読・その場
イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。 仕事を終わらせるために 仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。 予想以上に仕様が複雑になった 予想以上に調査に時間がかかった 予想以上にはまってしまった これはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、 予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする 予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す 予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずける というように、終わらないと気がついた時点で調
チーム勉強会で Feature Flag とトランクベース開発の話をしました （追加訂正と書かれているスライドは、勉強会後議論した結果を反映したものです）
受託開発におけるアジャイルに限界を感じた私が、「納品のない受託開発」を始めるまで - 倉貫義人の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。株式会社ソニックガーデンの代表をしている倉貫義人と申します。 私はもともと大手システム会社でプログラマとして働いていました。そのとき出会ったアジャイル開発に魅了され、これこそ自分にとって理想の姿であると確信し、それ以来アジャイル開発を広めるための様々な活動を社内外で行ってきました。 最終的に、本当に自分の理想とするソフトウェア開発と、それを実現する組織をつくるためには、自ら会社を経営する立場になるしかないと考え、起業することになりました。そうしてできたのが株式会社ソニックガーデンです。 ソニックガーデンでは「納品のない受託開発」というサービスを提供しています。従来的な受託開発から、そもそものビジネスモデルを見直したことで、今では「アジャイル開発」を意識せずとも、自然とそれに取り組める組織として機能しています。 思い返すと、私のアジャ
修士課程を退学した15年前に、僕は全く実現可能性を考えずに”30歳までにアメリカの大学院に留学”という目標を立てました。 もう一度大学院に行きたい、行くなら世界トップのアメリカがいいだろう、そんな程度の認識でした。 ただ、これはどちらかといえば無理やりひねり出した30歳まで生きる理由であって、そこまで強い意志があったわけではありません。 しかし、おかげで何とか30歳を超え40歳目前まで生き延びることはでき、気が付けばアメリカではなくカナダで永住権を取って暮らしています。 大学院留学は引き続き他のハードルが高くて達成できる気はしませんが、15年前に目標を立てた時点では認識できていなかった 「海外に移住する」という難儀を10年ほどかけて乗り越えることはできました。 けれど、そういえば事の顛末を一つにまとめたことが無かったなと気づいたので、僕のキャリア10年＋αを振り返って記事にしてみました。
エンジニアリングマネージャーの最初の学び - このロールは何なのか - yigarashiのブログ
2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。 これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMと
Tangible, Embedded and Embodied Interaction - Lecture 9 - Next Generation User Interfaces (4018166FNR)
小中新規開発グループ (a.k.a. tara チーム) の qsona です。 tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。 tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。 スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである「学習コアチーム」において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。 なお、本
メールソフト「Thunderbird」では、ソフトウェアの品質向上のために開発チーム内で日常的に自動テストが実行されています。その理由や手法についてThunderbirdの開発チームが解説しています。 Automated Testing: How We Catch Thunderbird Bugs Before You Do https://blog.thunderbird.net/2024/04/automated-testing-how-we-catch-thunderbird-bugs-before-you-do/ ◆自動テストの目的とメリット Thunderbird開発プロジェクトではコードの変更によるバグの発生を最小限に抑えるために「自動テスト」が重視されています。開発チームによると、、Thunderbirdのコードや機能に変更が加えられるたびに、Windows、macOS、Li
みなさん、デザインツールの Figma を使っていますか？ 私はまだ「使っている」と言えるほど使えていません というわけで勉強会を開催して勉強します Figma とは 公式の紹介文は以下のとおりです デザインの追求からプロトタイプ作成、制作物のコーディングまで、Figmaはチームがコラボレーションして製品開発するためのプラットフォームです 本記事のタイトルと同じように、「デザインからデモ・実装までチームで製品開発できる」旨が書かれています まさにその通りで、ブラウザ上で UI をデザインし、そのまま動かしてみることができ、最終的にはコードの生成までできてしまうツールです Figma の人気 2022年に世界中のデザイン関係者を対象としたアンケートでも Figma は圧倒的な人気です いずれのランキングでも2位の10倍以上の得票数になっています メインで使っている UI デザインツール第1位
ふりかえりでふりかえることしかできなかったジュニアチームが、次の打ち手を出せるチームになるのにやったこと
1on1ミーティングの普及1on1ミーティングが多くの現場に浸透してずいぶん経ちます。1on1という仕組みの普及に大きく貢献したのは「ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法」でしょうか。 本書の帯に「部下のための時間」と書かれていることからわかるように、1on1はその普及段階においては「上司と部下の間で定期的に行われるミーティング」という意味合いでした。 ここ最近では1on1という言葉が指す範囲がもっと広がっていると感じます。同僚同士でのコミュニケーションだったり、定期的ではなく突発的に設けられた場だったり。 物事が普及していく過程でもともと持っていた意味合いが変化していくのはよくあることで、こういった意味の広がり自体が1on1が広く普及しているという事実を物語っています。 同僚同士の1on1上司ー部下という関係性ではなくフラットな関係性での1on1は、上下関係があ
2月に開催した、デベロッパー向けイベント「Developers Summit 2024」にて行った講演「『グランブルーファンタジー』100万行を超える大規模なシステム再構築～10周年のその先へ～」で使用したもの。全86ページに渡る資料を掲載した他、テックブログにて解説記事も公開中だ。 グランブルーファンタジーは、Cygamesが提供するスマートフォン向けRPGで、3月で10周年を迎えた。同ゲームでは、今後もサービス提供を続けていくために、100万行を超えるシステムの再構築を実施。その判断を決めた経緯や、手段、実際に遭遇した困難などについて解説している。 資料を作成したCygamesのサーバサイドエンジニアである伊藤顕二郎さんは「グラブルは数十人規模のエンジニアが開発・運用に当たっているが、リファクタリングに関しては6人のバックエンドエンジニアを中心に専任チームで進めた」と説明。「（リファク
Engineering Manager Advent Calendar 2023 15日目の記事です。 KyashでEngineering Managerとして1年半、VP of Enginneringとして2年やってきました。 体系的な話は HIGH OUTPUT MANAGEMENT や エンジニアリング組織論への招待、エンジニアリングマネージャーのしごと といった素晴らしい書籍にまとまっているので、自分はケーススタディとしてVPoEになってからの具体的な意思決定の記録を残しておきます。EMの時の話は過去にまとめています。 KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP Engineering Managerをやめた - Konifar's WIP 先に書いておくと、綺麗にうまくいった / いっているという話は
プラットフォーム エンジニアリング ガイド
プラットフォーム エンジニアリング ガイド プラットフォーム エンジニアリング チームが Microsoft やその他のベンダーの構成要素を使用して、よりパーソナライズされた、最適化された安全な開発者エクスペリエンスを作成する方法について説明します。
これは何 自分の所属しているグループではスクラムを導入しているのですが、ある時メンバー間で業務を調整するためのコミュニケーションをもっと取っていきたいよねという話になりました。 具体的には、「重いレビューと重いタスクが重なってしまって余裕がない」、「ミーティングが多くて時間が足りない」、「体調不良で思うように働けない」などなどの個別の事情をもっと共有しあってチームで調整したいよねという内容です。 元々グループで毎日朝会を実施していて、そこに「困ったこと」を書くセクションを設けてはいました。 しかし、ちょっとした困りごとは「頑張ればなんとかなるし..」「わざわざ共有するほどでもないかな」といった感じで共有されづらい状況でした。 そんな時に以前『カイゼン・ジャーニー』で読んだ「ファイブフィンガー」を思い出し、チームに導入してみたら、些細な困り事が共有されるようになりました。 ファイブフィンガー
ZOZOTOWNにおける開発生産性向上に関する取り組み / Initiatives to Improve Development Productivity at ZOZOTOWN
■ ZOZOエンジニア向け会社説明資料 https://speakerdeck.com/zozodevelopers/company-deck ■ 運用改善によるチームパフォーマンス向上のための取り組み https://techblog.zozo.com/entry/operational-improvements-tips ■ GitHub Copilotの全社導入とその効果 https://techblog.zozo.com/entry/introducing_github_copilot
おはようございます!こんにちは!場合によってはこんばんわ! SREチームマネージャーの藤原です。 今年の3月からSREチームの中で、勉強会を定期的に実施するようになりました。 本エントリでは勉強会を開催するにあたって考えたことと、実際の進め方についての事例解説です。 勉強会を通じて実現したいことの説明から、テーマ設定、効果最大化のための開催形態と頻度、現時点(2024/4・5時点)の結果について解説しています。 勉強会を通じて実現したいこと チーム内勉強会を通じて実現したいこととして、以下を設定していました。 チーム・個人としてのレベルアップ 積極的な議論への参加 相互理解 チームとしての目線合わせ 勉強会を開催するからには何かしらのスキルや考え方を身に付けたいはずです。 また、学習効果を最大化するためにも、積極的な議論への参加を実現したいと考えました。 さらには、勉強会の中での議論を通じ
自己紹介 こんにちは。名刺メーカーDevグループの伊藤惇です。 私は2022年4月にSansanに新卒として入社して、現在に至るまで名刺データの作成および印刷発注をするサービスの開発に携わっています。 名刺メーカーDevグループでは、偶然タイミングが重なったこともあり、私が入社してからこれまでの間に5人が育児休暇を取得しました。 そうした中で感じた育休に対する考え方の変化を振り返りたいと思います。 なお、本記事はSansan Advent Calendar 2023の14日目の記事です。 名刺メーカー育休スケジュール 名刺メーカーDevグループの規模感 チームの人数やプロダクトのフェーズによっても育休のインパクトが変わってくるので、私が所属する名刺メーカーDevグループの規模感について補足しておきます。 チーム人数 後述するAさん、Bさん、Cさんの育休取得時は約15人ほどのチームでした。そ
技育祭は「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。「技育祭2023【春】」に登壇したのは、株式会社CARTA HOLDINGS・CTOの鈴木健太氏。エンジニアが圧倒的に成長するためのコツを話しました。3回目は「信頼」について。 成長のコツその3 信頼 最後に3つ目のコツを話していこうと思います。最後は、チームの話です。3つ目のコツは、「信頼」です。信頼というのは、文字で書くとシンプルですね。 プログラミングとソフトウェアエンジニアリングは違うよ、という話をしたいと思います。みんなはこのイメージがつきますか？ プログラミングというのは、例えば学校の課題の中とか、あるいはみんな今手元で作っているもので短期的に動くものです。 それ自体は楽しいし、すごくすばらしいことだし、僕もすごく好きなんだけど、ソフトウェアエンジニアリングというのは
tl;dr オブザーバビリティにはあなたの直感よりもお金がかかるかもしれない。でもそれはアジリティを上げるために必要なコストである。同時にオブザーバビリティ関連ベンダーには、それらをリーズナブルに提供してもらうことを期待します。 オブザーバビリティ・エンジニアリング輪読会 8月からVPoEになりました。id:Songmuです。 社内の勉強会で輪読形式でオブザーバービリティ・エンジニアリングを読んでいます。毎週30分、参加者の中から発表者を割り当て、1~2章を読み進めるスタイルです。 ちなみに、ヘンリーではActive Book Dialogue(ADB)というフォーマットも取り入れて輪読会が運営されています。社内で同時並行で数本走っており、先日、CEOの逆瀬川が書いたソフトウェア見積もりに関する輪読会も同様の形式で実施しています。 発表者は、事前に社内のNotionにその章のアウトラインや
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 自動車レースの最高峰と言われるFormula 1（F1）は、年間20以上のレースが開催され、サーキットやテレビ、インターネットなどで観戦するファンは、世界170カ国以上で約5億人にも上る。そのサービスを支えるITインフラは、極めてミッションクリティカルであり、F1公式パートナーのLenovoが2022年からITインフラを供給している。同社が9月22～24日開催の日本グランプリ（GP、三重県・鈴鹿サーキット）で行ったF1の取り組みを説明するメディアツアーに同行し、F1のITインフラの現場を取材した。 2023年シーズンのF1は10チームが参加して、3～11月に欧州、米州、中東、アジア、オセアニアで全23戦が行われる（うち1戦は豪雨災害で中
みなさん、こんにちは！プロダクト開発部の吉川（@yoshiyu0922）です。 現在、JMDCが保有している医療ビッグデータを活用して生活者や医療に新しい価値を提供する新規プロダクト開発チームのバックエンドを担当しております。 以前に新規プロダクト開発で採用している技術や設計についてこちらの記事で紹介しましたが、Go x GraphQL x DDDでプロダクト開発をしています。今回はプロダクトの開発が一区切りしてこれからリリースするということで、開発してみて良かったことやこうすれば良かったことを振り返りをしました。振り返りの内容は主にDDDに関することです。 DDDとは DDDとは「Domain-Driven Design」の略語でドメイン駆動設計と呼ばれるソフトウェア開発手法の一つです。問題を解決しようとする領域（ドメイン）をモデリングによってソフトウェアの設計や実装に反映させることで、
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/
Findy主催のイベント「なぜ話題？Platform Engineering最前線 〜いま注目を浴びている理由とは〜」 https://findy.connpass.com/event/298961/ でお話しした資料です
こんにちは！SmartHRで基本機能の開発を担当している、エンジニアのwakasaです。2023年の1月から半年かけて、自チームのテストフロー見直しを行い、実装時間を大幅に増やすことができました。今回はその取り組みをご紹介します。 見直し前のチームの状態 私の所属するEチームは、SmartHRの基本機能の中でも、従業員情報やマスターデータの履歴データ管理周りの機能開発を主に担当しています。2023年8月現在、エンジニアが6名、プロダクトマネージャーが1名、プロダクトデザイナーが1名所属しており、QAエンジニアは所属していません。以前はQAエンジニアがチームに所属していましたが、2022年10月にチームを離れました。QAエンジニアがチームを離れたあとはエンジニアがテスト業務を兼務しています。 今回の取り組みを始めるきっかけとなったのは、2022年の年末に実装にどのくらい時間を使えているのか計
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
NTTのレッドチーム「Team V」の活動実態 「管理者権限はほぼ確実に取れる」｜BUSINESS NETWORK
＜サイバーセキュリティ戦記＞NTTグループのプロフェッショナルたちNTTのレッドチーム「Team V」の活動実態 「管理者権限はほぼ確実に取れる」 NTTグループ サイバーセキュリティ戦記 セキュリティ サイバー攻撃を疑似的に仕掛け、ターゲット組織のサイバーセキュリティに関する弱点を見つけ出すレッドチーム。NTTグループでは、2019年からグループ内向けのレッドチーム「Team V」が活動している。NTTグループの上級セキュリティ人材を紹介する連載「＜サイバーセキュリティ戦記＞NTTグループのプロフェッショナルたち」の第18回に登場するのは、Team Vの精鋭メンバーの1人であるNTTセキュリティ・ジャパンの羽田大樹だ。 対象組織の社員が標的型メールに引っ掛かり、一般社員のPCが攻撃者に掌握されてしまった――。これが、NTTグループのレッドチーム「Team V」によるサイバー攻撃演習の前提
部下の力を最大限に引き出す育成をするためには、どのような関わりをすればよいのか。褒める・叱るではない「行動承認マネジメント」のノウハウを、株式会社シンプルプランの丸茂喜泰氏が解説します。本記事では、生産性の高いチームの特徴をもとに、自社でオープンなコミュニケーションを作り上げていくためのポイントを解説しました。 前回の記事はこちら 管理職が担っている3つの役割 丸茂喜泰氏：あらためて本日のゴールです。私としましては、みなさまがご自身の日頃の行動に照らし合わせた際に、「できているか？」を点検する機会にしていただければなと思って、進めていければと思っております。 では、今日のテーマである「行動承認マネジメント～褒める叱るじゃない若手社員の育て方～」をお話ししていければと思います。この話に入る前に、一応確認でございますが、今回のテーマはマネジメントです。管理職や職場のマネージャーと呼ばれるような
プロダクト開発に利用する技術の選択は、不確実性を伴う決断であることが多いです。 私はROUTE06で働く前は個人事業主でした。仕事の多くは、新規プロダクトのプロトタイプや初期バージョンの作成でした。デザインを含めてプロダクト開発をするのは私一人だったので、おおよその要件とスケジュール、予算が合意できたら、作り方は任せてもらっていました。 当時、私が技術を選択する方法は「開発速度や品質に非線形の変化を与える可能性があると感じたらまずは使ってみる」でした。アルファ版*1でもとりあえず使ってみて、上手くいったらそのまま本番稼働させているプロダクトもあります。 足りてない機能や不具合に直面することもありますが、パッチを書いたり開発元にプルリクエストを送りながらプロダクトの開発も進めていました。この進め方は、開発者が一人であれば成果を出せますが、チームで大きな成果を出すのは難しいでしょう。 現在、私
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクトオーナーを兼務する技術、あるいはその反省 - SmartHR Tech Blog
開発チームのマネージャーとして意識しているチームのCapability - LayerX エンジニアブログ
角換りは終わったのかについて1万文字程度で | やねうら王 公式サイト
プロダクトが大きくなると、なぜ生産性は下がるのか？ 『Team Topologies』から読み解く、「認知負荷」という考え方
Pull Request のコメント数を減らすアホみたいなコツ｜牛尾 剛
わたしがベッドで仕事をするようになったわけ｜kon
Engineering Manager の自己効力感下がりがち問題｜qsona
「終わらなかったから次のスプリントにまわそう」なんてありえない
Feature Flag Deep Dive
10年かけてカナダでソフトウェアエンジニアになるまでの道のり - As a Futurist...
経験に複利を効かせろ！ふりかえり研修2024
Sprint Planning をやめた話 - スタディサプリ Product Team Blog
オープンソースのメーラー「Thunderbird」の開発チームが「バグを減らす開発手法」を解説
Figma でデザイン、そのままデモ、そのまま実装！ - Qiita
DDDやってみたら 実装以前の領域での学びが深かった話
1on1の普及と「とりあえず1on1」問題｜dora_e_m
「グラブル」のリファクタリングに関する資料、Cygamesが無料公開 6人の専任チームのノウハウを紹介
マネジメントとしての意思決定振り返り - Konifar's WIP
朝会にファイブフィンガーを導入したらみんなの調子がわかりやすくなりました - Qiita
チーム内勉強会の進め方事例 - MNTSQ Techブログ
入社して1年半の間に先輩が5人育休に入った話 - Sansan Tech Blog
「不安を共有できないチームは、絶対に信頼関係を築けない」 “ソフトウェアエンジニアリング＝チーム競技”だからこそ、大事にすべきこと
オブザーバビリティにはお金がかかる - 株式会社ヘンリー エンジニアブログ
F1日本GPに見る、世界5億人のファンにサービスを提供するITインフラの現場
DDDでプロダクト開発をしたので振り返ってみた - JMDC TECH BLOG
技術の洪水に立ち向かう: 開発者の心を軽くするプラットフォームエンジニアリングの話
チームのテストフローを見直して、実装時間を2倍に増やした話 - SmartHR Tech Blog
プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita
“仲が良すぎる会社”は1人の影響が組織全体を揺るがすことも Googleの調査結果から考える「心理的安全性」の本質
チーム開発における技術選定の進め方 - ROUTE06 Tech Blog