さて、専門性と体系化の話をしようか | knowledge / baigie
「専門性が高い人になりたいですか？」 そう問われたら、多くの人が「はい！」と答えるでしょう。エンジニアやデザイナーのような専門職に限らず、ビジネスパーソンの多くも、「できることなら何らかの専門性を高めたい」と思っているはずです。 しかし、そもそも「専門性が高い」とはどういう状態を指すのでしょうか。どんな人になれば「専門家」だと評価されるようになるのでしょうか。それを突き詰めて考えることが専門性を高めるヒントになると思い、少し深堀してみました。 最後には、まだ実験中ですが、ChatGPTを活用して専門性を高める方法をご紹介します。 専門性と体系化の関係 辞書サイトのWeblioを見ると、専門性とは「特定の分野のみに深く関わっているさま。高度な知識や経験を要求されることや、その度合い」と書かれています。この定義に従うと、専門性には「特定の分野の高度な知識や経験」が必要だということになります。
ソフトウェア開発における人的リソースの理想的な配分
背景SRE という概念が生まれてから数多くの開発チームで「ソフトウェアエンジニアリングの手法で運用を改善する営み」が行われてきた。 同時に、技術的負債が経営レベルで認知されるようになり、日常の会話の中でも長期・短期のトレードオフを念頭に置いたプロジェクト推進がやりやすくなったのは言うまでもない。 しかし、スタートアップでは Dev と Ops が別れていることは稀で、「全員が全てに対応する」ような状況になってしまうことがしばしばある。これは小さい組織だけの問題ではなく、例えば大企業の中の新しいプロダクト開発チームでも同じことが言える。 SRE を念頭に置き、技術的負債の主導権を握るために必要なチーム体制とはどういうものなのだろうか？ タスクの分解小さな組織のソフトウェアエンジニアは日々数多くのタスクを与えられている。場合によっては数名のメンバーで新規機能開発から日々の不具合修正、そして S
短い時間で結論が出ないのであればまだ情報が必要というシグナル - yohhatu's note
リファインメントやプランニングなどの場で、プロダクトバックログアイテム(作るもの)について理解を深めるために話し合っている
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
EMのトレンド？もしくはその兆し (2022年)
2022年昨今のEngineering Management(EM)界隈を見ていて、1つトレンドもしくは兆しがあるなぁ、と思っていることがあります。端的に言ってしまえば、EMを専門職種として切り出して、人（や組織）のマネジメントに専念させるパターンが出てきている、ということです。 もちろん、以前からこのような形態をとられている企業もあると思います。しかし、おそらくは専門性を高めている社員がキャリアラダーの1つとして、プレイングマネージャー的にマネジメントに携わるケースが多いのではないでしょうか。 プレイングマネージャーとして人のマネジメントに関わることの問題点は、2点あると考えています。ひとつは、プレイングしている内容（開発者であれば技術的なこと、デザイナーであればデザイン的なこと）と、人（と組織）に向き合う内容とのいずれにも注力できずに、どちらも中途半端な状態になるということです。結果と
「可視化」「見える化」を区別していますか？
こんにちは、エンジニア/スクラムマスターの中村です。 前回は「トラックナンバー」についてお話しました。 今回は「見える化」のお話です。 「見える化」と言うけれど･･･ 皆さん「みんなのタスクを見える化しよう」という声を聞いたことがありませんか？ その声の後、しばらくしてタスクをホワイトボードや付箋に書き出して見えるようにはなります。しかし、チームの状態やプロジェクトの状況はあまり変わらないこともあります。 何度かこのような話を見たり、聞いたりしていますが、「見える化」の一歩手前で止まっているような印象を受けることが多くあります。その一歩手前をこのエントリでは(「見える化とは区別する意味で)「可視化」と呼びます。 「可視化」と「見える化」の違い 「可視化」と「見える化」。共に情報や事象を関係者に「見えるようにする」点では同じですが、私は「可視化」は「見えている”だけ”」の状態と考えています。
2022/04/12 地味PM meetup 登壇 "地味PMと「評価」について" & イベントの感想｜永嶋 広樹 / NAGASHIMA Hiroki
私自身、登壇ネタどうしようかなぁと、直前まで悩んでいたのですが、企画言い出しっぺのところもあるし、トップバッターだし、みなさんと被らないように、あえて、地味なタスクそのものではなく、ちょっとメタ的な、地味PMの悩み、みたいなところをテーマにしてみました。事前にいただいていた質問でも「評価」については、困っている人は多そうでした。 こちらの資料を補足していきたいと思います。 イベントは、どうしても一方的に喋る感じではなく、わいわいしたかったので5分トーク＆5分QAというフォーマットにこだわりましたが、極限まで削ぎ落とした5分トークで言いたいことが全然言えなかったような気もするので、スクリプトは書き直しです。（みなさんもこの5分制約は苦労されたかと思いますが、場慣れ感、さすがでしたね） 地味な仕事は尊い大前提「どうしたら評価されるか、できるか」みたいな話をするのですが、まず、そもそも、需要のあ
開発中のコミュニケーションには色んなところで想像が入り込む - Mitsuyuki.Shiiba
例えば「会議が多い」という意見に、どう対応しよう？ 普通に考えたら「無駄な会議を減らそう！」かな だけど、できれば僕は「だからどうしたいと思ってるんですか？」というのをその意見をくれた人に確認したい 十中八九「会議を減らしたい」ってことなんだろうとは思いつつ、でも「会議が多いから、」のあとには色んなことが想像できる （順当→）会議を減らしたい それぞれの会議に自分が参加しないといけない理由を知りたい 会議が多くて他のことをやる時間がないから、自分の担当タスクを減らしたい 会議が多いのはいいんだけど、間に休憩が欲しい 「そっかぁ、それは大変だよね。ありがとう」って話を聞いて欲しいだけ もしかしたら「だから、充実してるんです」って可能性もなくはない さらに「会議を減らしたい」だったとして、その内容も 「無駄な会議が多いから減らしたい」かもしれないし 「開催頻度を減らしてもいい会議があるのではな
【2022/2/8(火)】SaaSの開発ロードマップ、マイルストーンどう決める？【開発PM勉強会vol.8 オンライン】
ともえーぬ@育休🌴Webエンジニア @tomoeine 終始勉強させていただくばかりの登壇者なのでした😅 運営の皆さま、参加者の皆さまありがとうございました。 次回は「レガシーシステムの改善」がテーマとのこと、楽しみしかない！ #開発PM勉強会 2022-02-08 20:48:22 maidol🎰システム開発屋さん @maidol_28 本日も #開発PM勉強会 ご参加ありがとうございました！たくさんの質問をいただき（ここに載せきれてないものも複数）全て回答できなかったのが心残りです😭 明日以降で皆さんからの質問を整理するので、登壇者からの回答があった際には順次 @devPM_io でもリツイートしていきます👏🔁 pic.twitter.com/sL9qm5C9KR 2022-02-08 21:03:36
【資料公開】エンジニアリングマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。 内容に関するご意見やフィードバックは、Twitter: @ryuzee までお知らせください。 スライドを見て興味を持たれた方は、ぜひ書籍『エンジニアリングマネージャーのしごと』を読んでいただければと思います。 それでは。 エンジニアリングマネージャー
SaaSの開発ロードマップ、マイルストーンどう決める？【開発PM勉強会vol.8 オンライン】に参加した #開発PM勉強会 - B-Teck!
peer-quest.connpass.com に参加してきたのでメモ。 投稿時点で公開されていた資料は記載しましたが、順次追記予定です。 個別最適のSaaSと上手く向き合うプロダクトロードマップ エンタープライズSaaSの初期成長戦略 急成長なフェーズでの成長戦略 アルプのロードマップ変遷 感想 個別最適のSaaSと上手く向き合うプロダクトロードマップ speakerdeck.com プロダクトロードマップとは 「やることリスト」ではなく「ありたい姿」への最短ルート 2軸で伝える「ありたい姿」 将来プロダクトが実現していたいユーザーの姿を描いた「よげんの書」 提供したい価値を抽象化したプロダクトビジョン ロードマップの策定 具体化するフェーズと抽象化するフェーズを行き来する 事業計画を因数分解し、優先順位を付ける やらないことを明確に バリュープロポジション内でも優先順位を決める ロード
就職氷河期と密接に絡んでいる日本のPM不足 国家事業としてやるべき育成とその方法
「マンモスプロジェクト」を提供するパラダイスウェア株式会社のYouTubeチャンネル「プロマネ道場ラジオ」。新規事業やプロジェクトについてのあるあるや、明日から使えるノウハウについて語ります。今回のテーマは「PMの育て方」。PM育成の重要性と、その方法について話しました。 PM育成は国家事業としてやるべきこと 橋本将功氏（以下、橋本）：みなさんこんにちは。パダライスウェアCEOの橋本です。 中島大輔氏（以下、中島氏）：中島です。 古長谷莉花氏（以下、古長谷）：古長谷です。 橋本：「だれプロラジオ（「誰も教えてくれないプロマネのコツラジオ」）」の第40回は？ 古長谷：プロマネの育て方、です。 橋本：前回、前々回とプロマネの採用やプロマネのなり方みたいな話をしてきたんですが、やはりプロマネは必要なので、僕個人的には国家事業としてやるべきだと思っているんですよ。 中島：ああ、そうですね。 日本の
「それってただの機能じゃない？会社になりえるの？」 (機能とプロダクトと会社の違い)｜原健一郎 | Kenichiro Hara
「それってただの機能じゃない？会社になりえるの？」 これはベンチャーキャピタルで働いていて、スタートアップに投資する際によく社内で議論される論点の一つで、特にアメリカではよく聞くセリフです。最近この「機能(Feature)と会社(Company)の違い」について色々考えさせられるニュースがあったので、この質問の意味を説明してみようと思います。 猫も杓子もストーリーTwitterで"Fleet"というInstagramのストーリー機能の類似機能が登場しました。ストーリー機能はTwitterだけでなく、キャリアSNSのLinkedInでも今年ローンチされ、至るところで登場しています。 ↓TwitterとLinkedInアプリの上部に登場した"ストーリー"機能 そのせいでネット上では、エクセルのストーリー機能、計算機のストーリー機能などパロディも登場する始末です。 「機能」はコピーされるストーリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジェンダのテンプレートの例 - yohhatu's note
「なにかないですか？」という問いかけをしない。 - yohhatu's project
ファシリテーションに関するポエム - yohhatu's project
KPTに慣れたチームがよりよい振り返りを行うために、K/P/Tのそれぞれにフォーカスをあてた考察
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
チームで盛り上げる ファシリテーション
Product Backlog Principles — Age-of-Product.com