2022年のプロダクトマネジメント方針を公開します - SmartHR Tech Blog
こんにちは、プロダクトマネージャー（以下、PM）のadachiです。 SmartHRでは、年始に各部署のリーダーがその年の方針を発表することになっています。今回は私がPMグループの方針として書いた文章を、丸ごとそのまま公開したいと思います。 本文に入る前に、少しだけ補足をさせてください。 現在PMグループには13名のPMが所属しており、それぞれ担当するプロダクトの性質もフェーズも異なります。そのようなチームに向けたメッセージということで、やや抽象的かつ焦点が絞りきれていない内容になっております。（言い訳その1） また、改めて読み返すとかなり基本的なことしか書いていないのですが、基本に立ち戻ってがんばろうぜ！という趣旨であることをご理解いただければと思います。（言い訳その2） そして、あふれる思いを詰め込んだ結果、かなりの長文になってしまいました。シンプルさを美徳とするPMとしては汗顔の至り
自作DBを始めたい人におすすめの本 - salachike:blog
この記事は、慶應理工アドベントカレンダー2021の20日目の記事です。 カレンダー全日埋まってすごい 🎉🎉 adventar.org 「Database Design and Implementation」という簡素なDBをスクラッチで作っていく本に取り組んだので、その読了エントリです。 Database Design and Implementation: Second Edition (Data-Centric Systems and Applications) (English Edition) 作者:Sciore, EdwardSpringerAmazon こんな人におすすめ MySQLやPostgreSQLを使った経験はあるが、DBの理論やその実装はあまり詳しくない人に特におすすめです。特に自作〇〇*1に興味がある人は間違いなく楽しめると思います。単純に本に紹介されている理論
MonotaRO Tech Talk #9 (データマネジメント編)を開催しました - MonotaRO Tech Blog
こんにちは、データ基盤グループの吉田(id:syou6162)です。10/28(木)に開催したMonotaRO Tech Talk #9 (データマネジメント編)のレポートをお届けします。イベント前の参加希望者が514人、イベント当日も310人がご参加くださり、大変盛り上がったイベントとなりました。 MonotaROのデータ活用と基盤の過去、現在、未来(香川和哉) 社内のデータ活用を一段階あげるための取り組み(吉本直人) データ基盤グループを支えるチームビルディング(吉田康久) 最後に MonotaROのデータ活用と基盤の過去、現在、未来(香川和哉) 最初の発表ではグループ長の香川より、MonotaROのデータ活用の変遷とそれを支えるデータ基盤のこれまでの歴史、現在取り組んでいる課題、今後の取り組みについて発表しました。10年以上の歴史があり、全社員の約6割を越えるデータ基盤の歴史について
データウェアハウスのバージョン管理をどうやるか - yasuhisa's blog
というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。 背景 / 前提 データウェアハウスのテーブルを社内に広く提供したい 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る (事前にレビューはもちろんするが)SQLのミスなどで以前のバージョンに戻したいといったことがありえる 他の部門では新しいバージョンをすでに使っていて、気軽に戻せないこともある データウェアハウスのバージョンを場面に応じて複数提供できると都合がよい 一方で、大多数のデータウェアハウスのユーザーは最新バージョンの利用だけでよいはず SSOT(Single Source of Truth)になっていて欲しいわけなので... 複数バージョン見えていると「どのバージョンを使えばいい
SREチームがスクラムを導入し1年でタスクの可視化と脱属人化を実現した話
ビズリーチ事業部のSREチームは、スクラムを導入して1年が経ち、タスクの可視化と脱属人化を実現しました。 導入にあたって何をしたのか、開発チームとは異なる工夫が必要だったところはどこか、導入後何が変わったのかを振り返ってみました。 ビズリーチ事業部のSREチームについて 「ビズリーチ」を担当していて、SRE(Site Reliability Engineer)としてアプリケーションエンジニアと共にプロダクトの継続的な成長のため信頼性・可用性の向上、自動化、効率化などに取り組んでいます。 なお、チームの構成は以下のようになっています。 開発者: SREチームのメンバー(5人) PO: SREチームのマネージャー スクラムマスター: 社内横断組織に所属している専任のスクラムマスター SREチームが抱えていた課題とスクラムの導入目的 まず、SREチームがスクラムを導入した背景を説明します。 PO
3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス
現場主導で始まったHRMOSの開発組織のオンボーディングは、ほぼ毎月、地道に運用と改善を続けてきました。2018年に開始してから3年近くになりますが、エンジニアを対象に始まり他職種のメンバーを巻き込みながら、効率と効果の両面を少しずつ洗練させてきました。この記事では、私たちのオンボーディングを定義や効果を俯瞰しながら紹介し、その中で徐々に確立されてきたプラクティスをご紹介します。 変化の時代に不可欠なオンボーディング オンボーディングとは採用や異動によって組織に加わった人材の早期戦力化のための施策であり、 組織に新しく加わった人材を1日も早く戦力化し、組織全体との調和を図ることを目的とした育成プログラムのことを指します。『機内』や『乗船』という意味を持つon-boardから派生して生まれた造語であり、直訳すると『飛行機や船に乗り込んでいる』という意味です。 〜 BizHint などと定義さ
「挑戦させすぎ？」マネジメント勉強会で分かった組織課題とその解決策 - ZOZO TECH BLOG
こんにちは、ZOZOテクノロジーズSREチームリーダー兼組織開発チーム所属の指原(@sashihara_jp)です。 この記事では2019年12月から全11回開催してきた「マネジメント勉強会」を通じて分かってきたZOZOテクノロジーズの組織課題と、これから取り組もうとしているその解決方法を紹介します。 ZOZOテクノロジーズの社員構成 マネジメント勉強会とは 立ち上げまでの道のり 運営メンバーの勧誘 経営層への企画提案 勉強会の命名 1年間で実施したテーマ 第1回 各チームで実施しているチームビルディング施策の共有 第2回 書籍「1on1マネジメント」を読んだ上で内容について議論 第9回 採用面接で質問している内容について意図と効果共有 マネジメント勉強会を通じて分かってきたZOZOテクノロジーズの現状 1.組織の急拡大による弊害 2.現場のコンフリクト 3.マネジメントと人材育成 組織開
NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers
こんにちは。このブログでは初めまして。2020年の2月にNewsPicksに入社した高山です。 今回は僕がNewsPicksのCTOになってからの1年でやったお仕事について書いていきます。 CTO最初のミッション DX Criteriaについて 「デプロイ回数」を定点観測 やってきたチャレンジ 1年経ってみて CTO最初のミッション NewsPicksは2013年に誕生し、5年ほどの壮大な創業期の間にたくさんの新しい領域に挑戦しており、僕が入社したときには既に事業面でもシステム面でも「それなりの複雑さ」という感じでした。 前任CTOの杉浦さん（今はグループ内でアメリカでの新規サービスの立ち上げをしています）からバトンを受け取って最初のミッションが「DX Criteriaを上げること」だと聞いたときにそのあたりの事情を全て察しました。😅 結論から先に書くと、1年で大幅改善を達成することがで
職能横断型スクラム体制になってからのチーム改善活動 - STORES Product Blog
こんにちは、STORES ECでフロントエンドエンジニアをしている@daitasuとバックエンドエンジニアをしている@phayacellです。 STORES ECでは、今年の5月よりエンジニア内の大きな体制変更がありました。 その変更では、フロントエンド/バックエンドで分かれていたチーム体制から、デザイナーやプロダクトマネージャーも含めた職能横断型のチーム体制へと変更になったのですが、この記事では、その際に生じた、今まで各チームで行っていた開発の進め方とのギャップや手法をマージしていく上での課題について、またそれらをどのように解決していったのかについてをお話しします。 チーム改善までの背景 組織体制の変更 元々STORES ECでは、フロントエンド/バックエンド/デザイナーは独立したチームとして動いており、PJTとしてメンバーが切り出されてはいますが、活動の主体としては職能で分かれている組
エンジニア評価制度の取り組みを振り返ってみた - Retty Tech Blog
はじめに Rettyでは2018年から組織的な改善活動を数多く始めており、その一つにエンジニアフィードバック（以下、フィードバックはFBと省略します）制度があります。 本記事はRettyのエンジニアFB制度への取り組みの紹介を兼ねた、これまでの改善活動の振り返り記事となっています。 （2018, 2019年のアドベントカレンダーの小迫の記事に組織的な改善活動についての紹介がありますので興味がありましたらご参照ください） engineer.retty.me engineer.retty.me エンジニアFBは今なお半年の評価ごとに継続的に改善を繰り返していて、今は4回目の改善サイクルとなる2020年上期のエンジニアFBが終わった頃となります。 対象としたい読者 下記のような項目にピンと来る方に読んでいただけると嬉しいです。 会社のエンジニアが評価に対して不満を抱えており、他社の評価制度の取り
Athena: Our automated build health management system
At Dropbox, we run more than 35,000 builds and millions of automated tests every day. With so many tests, a few are bound to fail non-deterministically or “flake.” Some new code submissions are bound to break the build, which prevents developers from cutting a new release. At this scale, it’s critical we minimize the manual intervention necessary to temporarily disable flaky tests, revert build-br
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
Announcing a New Management Structure for Ecma TC39 – Mozilla Hacks - the Web developer blog
Author’s note: You might have noticed that the name of the author appears in this article in the third person. Hi, I’m an engineer at Mozilla working on the Firefox DevTools server. I’m also a TC39 representative. I don’t usually write about myself in the 3rd person. In 2019, Ecma’s TC39 (the standardizing body behind JavaScript/ECMAScript) will be trying something new. The committee has grown in
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
Working Out Loud 大声作業（しなさい）、チームメンバー同士でのトレーニング文化の醸成 - スタディサプリ Product Team Blog
ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス
Cookieにかわる Sec-HTTP-State ヘッダの提案 - ASnoKaze blog
20190424 追記 IETFに提案仕様が提出されました https://tools.ietf.org/html/draft-west-http-state-tokens-00 Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。 現在はIETFのHTTPbis WGのMLに投稿されただけで仕様が正式にinternet-draftとして提出されたものではありません。まだまだどうなるかは全然わからない状態です。 この提案では、現在のCookieはセキュリティと非効率性とプライバシーの問題があると言っています。 現在のcookieは、Same-Origin-Policyとは異なりオリジンを超えて
メンバー同士でお互いの価値観を可視化するムービングモチベーターズを新チーム結成時に使ってみよう - RAKUS Developers Blog | ラクス エンジニアブログ
id:radiocat です。今年度はビアバッシュ推進委員から一歩身を引いてアドバイザー役になりました。 このブログでも何度か紹介している ビアバッシュ ですが、このたび新しい運営メンバーが選抜されて、先日キックオフを行いました。同じ会社の社員とはいえ価値観は人によって違うため、ビアバッシュをどのように推進していきたいか、思い描くイメージはそれぞれ違っているものです。はじめはお互いに手探り状態で意見をすり合わせながらやりたいことをまとめていくことになりますが、そんな時に役に立つ価値観を可視化する手法が「ムービングモチベーターズ」です。 ムービングモチベーターズとは チームのメンバー同士でお互いの価値観を共有するためのワークショップです。手法の成り立ちや考案者については後述します。 10種類のカード モチベーションの源泉となるキーワードが書かれた10種類のカードがあります。このカードを自分が
マネジメントの要素を知る - 「マネジメント入門」を読んだ - $shibayu36->blog;
マネジメントの技術全体に興味があるので、その要素にはどういうものがあるかを知っておくために「マネジメント入門」を読んだ。 マネジメント入門---グローバル経営のための理論と実践 作者:スティーブン P. ロビンス,デービッド A. ディチェンゾ,メアリー・コールターダイヤモンド社Amazon この本は、マネジメントにはどういう話題があり、それぞれにはどのような研究や考えがあるかについて、ざっくり概要を教えてくれる本だった。マネジメントの機能を、計画する、組織する、リーダーシップを発揮する、コントロールするの四つに分類して話を進めている。目次は以下のとおり。 イントロダクション: マネジャーとマネジメント・マネジメント環境・マネジメント全般に関わる課題 計画する: 意思決定の基礎・計画策定の基本 組織する: 組織の構造と設計・人材を管理する・変革とイノベーションのマネジメント リーダーシップ
ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog;
半年前から会社でシニアエンジニアという役職で、エンジニアのメンターの役割を担っている。その役割を出来るだけうまく演じられるように、半年間はコーチングの学習を進めてきた。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; なぜ最近コーチングや人間の学習モデルの勉強をしているのか - $shibayu36->blog; 「コーチングのすべて」読んだ - $shibayu36->blog; また、半年間、目標・1on1・評価と一通りの業務をこなし、コーチングの実践が出来た。 そこで今回はコーチングの学習と一通りの実践を通して学んだことで、特に役に立ったと思うことについて一旦まとめてみる。特に役に立ったと思った知識は以下の二つである。 ゴールを決め、現在位置とのギャップを考え、目標を決める 解決案を与えるのではなく質問する ゴールを決め、現在位置とのギャップを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクト・エンジニアリングマネジメントへの所感
