プロダクトマネージャーが担っている役割とその必要性を言語化する - Speee DEVELOPER BLOG
こんにちは、イエウール事業部でプロダクトマネージャーをしている酒井（@ryo-touch）です。 プロダクトマネージャー（PdM）という役職は、会社によって役割の実態が多様で「この会社のPdMはどんな役割を担っているのだろう？」と疑問に感じる方は多いのではないでしょうか。 Speeeでは「事業を連続的に立ち上げおり様々なフェーズを抱える事業の集合体である」「同じ役職でも役割はそれぞれの事業状況によって異なる」という背景から、意図して役職に対する明確なJob Descriptionを定義していません。 そのため今回は、わたしがイエウールで担っているPdMの役割を言語化し、大事にしていることを n=1 事例としてご紹介しようと思います。 目次はこちら 事業とプロダクトが成長していくための理想状態はなにか 事業責任者とエンジニアだけではスケールする難易度が高い PdMが事業責任者とエンジニアの間
HUNTER×HUNTER×OKR - Konifar's ZATSU
最近zatsuを書いてなかったので、「理想のOKRとは何か」をハンターハンターを例にして書く。必要な前提知識は8巻にある。 高いObjectiveの設定とは何か クロロ「全部だ」「地下競売のお宝 丸ごとかっさらう」 8巻 P152~153 これが高いObjectiveの設定である。 戦略発表前にはメンバーは「どこ狙うと思う？あたしは古書全般だと思う。団長本好きだし」「違うね。きとゲームね」などと色々な予想をしていたが、それをはるかに超えた目標を掲げている。そう 「全部盗む」である。 OKR シリコンバレー式で大胆な目標を達成する方法では、『Objectiveは達成確率が60〜70%程度になるくらいの高い目標を設定せよ』とあるが、このクロロのセリフはまさにそれだと言っていい。 合意のプロセスとは何か OKRの運用において一番大事なのは、所属するメンバーとそのObjectiveについて話して納
フラット、心理的安全性、失敗に寛容といった企業文化に対しての誤解｜片山良平＠paiza代表
この記事は「paiza Advent Calendar 2022」の最終日25日目の記事です。 最終日はpaiza株式会社で社長をやっている片山がお送りいたします。 ちなみに、paizaはITエンジニア向け国内最大の転職・就職・学習プラットフォームです。（paiza.jp) 記事概要先日、Twitterで流れてきて読んだ Harvard Business Review（以下HBR）の「イノベーティブな企業文化の残酷な現実」という記事（英文）が面白かったので、そのポイントと所感をまとめてみました。 内容としては、イノベーティブな企業文化には下記の事がセット必要であるという話です。 失敗には寛容だが、無能には寛容ではない 実験への意欲と高い規律性 心理的に安全だが、残酷なほど率直である コラボレーションと個人の意思決定、説明責任 フラットで強いリーダーシップ、オーナーシップ 「失敗に寛容」、「
許可を求めるな謝罪せよ
インターネットなんつーものはね、許可なんか求めていないクレージーな人たちによって作られてきたんだよ。それによって社会はすごくよくなったんだ。もし彼らが許可を求めていたら何も起こらなかった。そんな社会を我々は求めているのか。そーゆーことだと思う。許可を求めるな。謝罪せよ。 http://twitter.com/#!/hyoshiok/status/33183999060873216 この「許可を求めるな。謝罪せよ」というフレーズは@kawagutiに教えてもらったのだが、彼は@hiranabeから３Mの社是として聞いていて、その心はというと、ともかく試してみてうまくいかなかったら、その時また考えるというような趣旨の行動規範ということらしい。*1 関係各位の許可を求めていたら絶対物事は進まないし、何も始まらない。何かをやってうまくいくこともあれば失敗することもあって、その試行錯誤によって人は学
考え方が合わないのか情報が揃っていないのか - Konifar's ZATSU
「考え方が合わないなー」と感じた時は、相手と自分の持っている情報が揃っているかを疑ったほうがいいよね、という話を雑に書く。 たとえば「上司の理解がない」「部下の危機感が足りない」「同僚が慎重すぎる」みたいなやつ。なんでそんな考え方をするのかわからなくて憤りを感じるようなことがある。本当に考え方が合わないこともあるが、実は持っている情報量の違いによって思考結果が異なるだけで、思考回路自体に違いはなかったということも多い。 例を出してみる。プロダクトの1年後を考えてこれを絶対にやったほうがいいというボトムアップの提案が受け入れられなかったとする。 この時、実は相手は裏側で短期の売上目標を達成するために必死なのかもしれないし、ステークホルダーとのハードな交渉をしているのかもしれない。あるいは、プライベートで大変なことがあって考える余裕がないのかもしれない。逆の立場で見ると、実は提案する側はメンバ
Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識） 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
「この会社は詰んでます。潰れました」で気づいた“恥ずかしさ” DeNA南場智子氏がエンジニアから学んだこと
「DeNA TechCon 2021 Winter」は、DeNAを軸に「エンジニアとして企業で働くこと」について、学生に向けて先輩たちが紹介するイベントです。そこでまずはファウンダーの南場智子氏が、「経営者からみたエンジニアキャリア」について話しました。 本当にやりがいのある、充実した彩り豊かなキャリアとは 南場智子氏：みなさん、こんにちは。ファウンダーの南場です。オンライン開催となりちょっと寂しいですけど、「経営者からみたエンジニアキャリア」ということでお話をしたいと思います。 どの業界でも、そしてどの企業でも、もうDXをしないと後れを取るどころじゃなくて退場しなければいけないと、そういう厳しい状況になってきています。ですから、どの会社もエンジニア採用には必死です。そういう時にみなさん、エンジニアということで、おめでとうございます。 先週かな、学研の「高校生のなりたい職業ランキング」の1
Is High Quality Software Worth the Cost?
A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don't have time to work on architecture and code quality. Betteridge's Law of headlines is an adage that says
207で1年間磨き続けた1on1のフォーマットを公開します｜207株式会社
いつでもどこでもモノがトドク、世界的な物流ネットワークを創りたい、207株式会社のイナバです。 207の1on1、めっちゃ良いんです！！ 先日の忘年会で業務委託の方に「207に所属していて良いところは何か？」とお聞きして「1on1、めっちゃ科学されていて良いですよね」という話題に上がるくらいには良いです！ 私自身、業務委託で色んな会社を見ているのですが、たしかに207の1on1は凝っていると思います。 という事で、本記事では「どんな質問を」「どんな意図で」しているのかを代表にインタビューしてきたのでまとめていきます。 1on1をやる目的 そもそも1on1を実施してよかった点ですが、たくさんのメリットの中でも特に、 - 認識のズレをなくす - 信頼関係を構築する - アラートの早期検出 みたいな効果を享受できています。それぞれ、どういう意味かをご説明していきます。 認識のズレをなくす 業務上
2022年のプロダクトマネジメント方針を公開します - SmartHR Tech Blog
こんにちは、プロダクトマネージャー（以下、PM）のadachiです。 SmartHRでは、年始に各部署のリーダーがその年の方針を発表することになっています。今回は私がPMグループの方針として書いた文章を、丸ごとそのまま公開したいと思います。 本文に入る前に、少しだけ補足をさせてください。 現在PMグループには13名のPMが所属しており、それぞれ担当するプロダクトの性質もフェーズも異なります。そのようなチームに向けたメッセージということで、やや抽象的かつ焦点が絞りきれていない内容になっております。（言い訳その1） また、改めて読み返すとかなり基本的なことしか書いていないのですが、基本に立ち戻ってがんばろうぜ！という趣旨であることをご理解いただければと思います。（言い訳その2） そして、あふれる思いを詰め込んだ結果、かなりの長文になってしまいました。シンプルさを美徳とするPMとしては汗顔の至り
継続してプロダクトの品質を保つためにはプロダクトに向き合うだけでは足りないという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ソフトウェアの内部品質への投資を怠ったが故に、その内部品質がビジネスの足枷になってしまった、という失敗はよく聞かれる例だと思う。 そういう場合、「なのでソフトウェアの内部品質を直しましょう！」と言う発想になりがちだし、当然そのための投資を始めることは必要なのだけれど、それ以上に注目しなければならない問題がある、と最近は思うようになった。 「内部品質が落ちたので内部品質を直しましょう」というのは、単なる対症療法である上に「いつんなったら直って内部品質への投資やめられるの」という誤った問いを誘発してしまう。よくある話として、一定の内部品質を達成するために「リプレースプロジェクトです！」と言って書き換えを進めて、それが終わったらまた内部品質は鑑みられなくなるような話があるし、内部品質だけではなく「EOL対応」とかでもそういうケースはまま聞く。 じつは直面すべき課題は「内部品質の低さ」や「依存ライ
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（後編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（後編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
スタートアップ技術顧問は技術を見ない - メンテモエンジニアリング
こちらの記事は三部作です その1：とあるスタートアップが最初のフルタイムエンジニア採用を決意するまで 番外編：スタートアップ技術顧問は技術を見ない <= 現在の記事 その2：とあるスタートアップが最初のフルタイムエンジニア採用のために準備したこと その3：とあるスタートアップが Twitter Spaces からフルタイムエンジニアを採用した話 番外編：メンテモに転職した話 タイトルは嘘です。(必要なときに)見ます。最近は通知を送る方法*1について考えられる設計のパターンをいくつか例示した上で、今ならどれを選択しどんな感じで実装していったらいいかについて議論したりしました。 初めまして、@tagomorisです。今年の6月からメンテモで技術顧問をしています。技術的な専門としてはデータ処理基盤からWebサービス一般・ITインフラまでですが、メンテモの技術顧問では技術領域を特定せず、ありとあら
マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏
コンウェイの法則とかで、マイクロサービス=組織 という話になることが多いなと感じる。 正解の場合もあるし、不正解の場合もあると思っていて、個人的には小さいチームでもマイクロサービスをやるメリットは技術的にも組織的にもあると思う。 そのメリットを無視してすぐ組織の話に持っていきたくないので、基本分離したくないマンとしての主張を書いておく 技術観点でのメリット いまさら語るまでもないけど、 ドメイン境界の分離 デプロイ独立性 リソースの最適配分 障害の局所化(サーキットブレーカー等) このうち、ドメイン境界の分離だけはモジュラモノリスで対応可能だが、あとの3つにはマイクロサービスが必須。(もっとあるかも) この3つが必要なのにモノリス or モジュラモノリス で進める判断をするということはシステムの表現力を落とすことに直結する。 もちろん、複雑度は増すし難易度も増す。熟練のサーバーサイドエンジ
DXコンサルが絶対に言わない後ろめたい真実｜naoto
【お知らせ】200名以上の有名企業のCxO / 責任者クラスのトッププレイヤーを、月額定額でアサインできる「SHARE BOSS （シェアボス）」というサービスを運営しています。DXや事業開発に関するお困りごとや、お悩みがございましたら、まずはお気軽にお問い合わせください。 https://shareboss.net/about/ 2019年くらいから、デジタルトランスフォーメーション (DX) の相談を受けるようになって、今はアドバイザーみたいなのを含めて10社くらいお手伝いしています。 また、講演なんかも依頼されてたりして、そこではストルターマン教授がどうだ、とか、トレンドはー、みたいなことをしたり顔で言っていたりするわけなんですが・・・。内心では、定義とか事例の話から入るのはあんまり本質的じゃないのかな、と感じています。 足元の現場を見ると、DXDXディーエックスディーエックスいって
DACI - 動かす人、決める人、貢献する人、そして、知らされるだけの人｜佐々木 大輔
こんにちは。LINEやSmartNewsで執行役員を務め、現在はTales & TokensやSekappyで会社経営をしている佐々木と申します。プロダクト開発や事業開発を専門としています。今回は「DACI」というフレームワークを使いこなすための考え方を紹介します。 DACIというフレームワークは、SmartNewsでの同僚・Jeannie Yangから教わったのですが、それを頻繁に使ううちに手に馴染んだ道具となりました。もうDACIを知らなかった頃には戻れない、とすら感じています。 この意思決定のフレームワークのポイントは、少し奇妙に聞こえるかもしれませんが、「知らされるだけの人」を決めることにあります。なぜか。それを説明します。 DriverとApproverの役割まず「DACI」という言葉ですが、Driver / Approver / Contributors / Informed
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
労働者派遣・請負を適正に 行うためのガイド - 厚生労働省(pdf)
AWSにおけるアプリチームとインフラチームのコワーク設計 / Co-working Design about App and Infra on AWS
