1on1ミーティングガイド (1on1ガイド)は未完成の部分も残したβ版として公開しており、今後コンテンツの追加やスタイルの修正などの変更が予定されています。 また追記やスタイルの修正だけでなく、現在記載されている内容が大きく見直される場合があります。
プロダクトづくりや事業づくりは、仮説検証の連続です。いかに筋の良い仮説を積み上げられるかによって、プロダクトの成功は左右されます。本ドキュメントでは、プロダクト仮説とユーザーインサイトの関係性を紐解き、ユーザーインサイトを仮説に正しく取り入れる方法について解説します。
この記事は ウィルゲート Advent Calendar 2022 - Adventar の24日目の記事です。 こんにちは!ウィルゲート開発室 開発基盤ユニット マネージャー池添です。 私は、普段はプロダクトの開発チームに寄らないプロダクト横断での改善を行うインフラチーム、SRE(Site Reliability Engineering)チーム、CRE(Customer Reliability Engineering)チームを取りまとめています。 また、今年の4月から前任の横道から組織デザインチームのリーダーを引き継ぎ、開発室全体のスキルアップや教育について従事してきました。 私は、前任である横道がいたときから一緒に組織デザインチームに所属しており、組織の技術成長やメンバーひとりひとりのキャリアアップについて考え実践してきました。 この記事では、その中でメンバーの成長に対して組織としてエ
「リゼンティーイズム」とは?2023年1月にイギリスで使われはじめ、欧米諸国に広まってきているリゼンティーイズムという言葉。 「Resent」とは疎む、または不服に思うこと。それを「Presenteeism(プレゼンティーイズム)」という別の言葉とかけ合わせた混成語。 現在の仕事や職場が嫌いだが、より良い就労機会を見つけることができない、あるいは経済的な必要性にしばられているために離職できず、働き続けざるを得ない状況を意味します。 注目される背景前出のプレゼンティーイズムは「疫病出勤」とも訳され、心身に不調をきたしながらも出社しているために、業務効率が落ちている状況を指します。 リゼンティーイズムとプレゼンティーイズムは、どちらも会社にとっては可視化しづらい損失であると言えるでしょう。 だからこそ、企業が従業員の健康を「自分ごと」として捉え、戦略的に健康づくりを目指していくうえでは、避けて
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
# 参考資料 - https://speakerdeck.com/pokotyamu/furikaeri-2024-95ceb97e-d587-4c4b-a4ec-5e52672644f6 - https://www.1101.com/umeda_iwata/ - https://speakerdeck.com/soudai/release-small
こんにちは。LayerXの本間(@maro)です。バクラク申請とバクラク経費精算のプロダクトマネージャー(以下、PdM)をしています。 最近、息子が拍手を覚えました。落ち込んだ時は息子に拍手を強要して元気を取り戻しています。 -- さて、PdMとしてプロダクトロードマップを決め、それに伴い機能の開発優先度を決めることって難しいですよね。 お客様からいただくご要望、プロダクトビジョンの実現、事業数値へのインパクト、リソース……様々な変数を元に「どのような順序でどうプロダクト成長させることが最適解なのか」を常に考えています。 その中で「お客様のご要望解決だけではプロダクト成長が鈍化するな」と感じることがあります。その背景と「お客様から頂くご要望と機能開発優先度をどうリンクさせてロードマップを描くか」を記事にしました。 記事の前提となる「バクラク申請・バクラク経費精算」というプロダクトの概略は以
「負債にも50パーセントの時間を使ってください」は機能しなかった 西村賢氏(以下、西村):最初にやったことに価値がありました。そして、次は第2段。 原トリ氏(以下、原):この説明会やった時に、6月は一回止めますと(話しました)。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村:これ、カミナシの歴史で初めてですね。 原:たぶん、初めてだと思います。 西村:そこは「大丈夫なのかな?」とかなかったんですか? 原:「この1年大きい機能、出てないよね?」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村:なるほど。なにか技術的にうまくいっていないというのがあった。 原:そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力
技育祭2024春のスライドです。 価値のあるプロダクトをつくるエンジニアになるための話と、自分がどういうキャリアでそうなっていったかを話します。
Schematic Capture KiCad's Schematic Editor supports everything from the most basic schematic to a complex hierarchical design with hundreds of sheets. Create your own custom symbols or use some of the thousands found in the official KiCad library. Verify your design with integrated SPICE simulator and electrical rules checker. Learn more PCB Layout KiCad's PCB Editor is approachable enough to make
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか? Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか? あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いのですが、そのうち、出典である『LeanとDevOpsの科学』をきちんと読んだ人はかなり少ないようです。 そして、ここで敢えて強めの主張をするのですが 『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。 Forsgrenらは徹底した研究の結果として4つのメトリクス(指標)を見出すのですが、その裏には彼女らの沢山の思いが詰まっています。その思いや彼女らの思考を理解し、彼女らの考えをきちんとトレースして始めて、Four Keysは意味を持ちます。 そして『LeanとDe
はじめに go.modにおけるGoのバージョン指定 依存先のgoディレクティブの方が古いバージョンを指す場合 依存先のgoディレクティブの方が新しいバージョンを指す場合 goのバージョンよりgoディレクティブが先行する場合 goディレクティブまとめ 1.21以降のgo.modにおけるGoのバージョン指定 require時のバージョンの指定 Minimal version selection モジュールのバージョン replaceの波及先 依存先が別のパスにreplaceしている場合 go.sum まとめ はじめに これはあくあたん工房アドベントカレンダー 2021 11日目の記事です。 ポエムを書いていたら気分が暗くなったので、消して自分の過去のメモを記事にすることにしました。そんな解釈するやつおらへんやろwwと是非笑って読んでください。 2023-09-19追記:Go 1.21からいくつ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く