Noを伝える技術 #pmconf2021プロダクトマネージャーカンファレンス2021登壇時の資料です。 https://2021.pmconf.jp/sessions/pkikYIU5
スタートアップの熱狂と急成長を両立させる野望 - 株式会社ヘンリー エンジニアブログ
VP of Engineeringのid:Songmuです。このエントリーは株式会社ヘンリー Advent Calendar 2023、最終日の記事です。 ヘンリーは今年、本丸の病院向け電子カルテ・レセコンシステムのサービスを開始し、順調に事業が立ち上がっています。早くも業界でもユニークなポジションを獲得し、注目度も上がっています。 そんな中アクセルを踏む決断をし、来年は組織として100人採用に踏み切ることになりました。 ビジネスを勝ち切るためのアクセルを踏むフェーズにおいて、自分がVPoEとして採用や組織開発に主体的にチャレンジできる立場にいることは喜ばしいことです。その中で自分が考えていることを書き出していきます。 公器を志向すること 「面白法人でありながら上場することに意味と面白さがある」 2011年頃、当時私が所属していたカヤック社で代表の柳澤さんが度々こう言っていました。カヤック
スクラムマスターの役割とは何か？ チームと環境の変化で“変わる”取り組みと“変わらない”原則
2001年の「アジャイルソフトウェア開発宣言」から20年以上が経過し、アジャイル開発の認知や実践は大きく広がりを見せています。一方で、社会や環境の変化に適応するように、その実践の形も、姿を変えながら進化を続けています。今回は、スクラムマスターを務めるヤフー 田原慎也氏とChatwork 粕谷大輔氏に、「リモートでのスクラム」「大規模スクラム」など、アジャイル開発、特にスクラムにおける、ホットなトピックについて語っていただきました。 ともに複数チームでプロジェクトを推進する2人のスクラムマスター 田原：ヤフーの田原です。スクラムマスターを務めるようになったのは1年ほど前からで、まだ初心者です。今回は、自分のこれまでの取り組みをお話しして、エキスパートである粕谷さんに、いろいろと突っ込んで、教えていただければと思っています。 粕谷：Chatworkの粕谷です。こちらこそ、よろしくお願いします。
すごい開発チーム育成ハンドブック · すごい開発チーム育成ガイド
すごい開発チーム育成ハンドブック プロダクト開発の｢やること｣リストはTrelloで順序立てておくとうまくいく ビジネス上の要求が変化しやすいときは、タスクの優先順位を2週間変えないようにする ビデオ会議で遠方チームに「伝わらない」と思ったら、一度「顔合わせ会」を開催する 「これは使えない」と言われたら、機能の意思決定を「担当者」に委ねる エンジニアに期間が「わからない」と言われたらタスクを細分化して具体的に 仕様を考えるときはエンジニアと対話する 開発チームの開発速度がわからないときは、短い期間で速度を計測する 開発状況を把握できないときはスクラムで開発する 「Scrum for Trello」でストーリーポイントをチームで共有する やってみないと分からないタスクは調査する スクラムが定着しないときは、2日のスプリントで慣らす ストーリーポイントの見積もりは「比べる」が基本 ストーリーポ
エンジニアが「PMも兼任して」と言われたときの心構え
この記事は プロダクトマネージャー Advent Calendar 2020 17日目の記事です🎄 カンタンに自己紹介 名古屋の企業でフロントエンドエンジニア兼PMをやってます、amakawaです。2年ほど前に事務員からエンジニアに転職して、総勢50名ほどのベンチャーで2年近くバックエンド〜フロントエンドを書きつつ、プロダクトマネジメント・プロジェクトマネジメント業務も担当してきました。 東京へ転居して、2月からディレクターとしてプロダクトマネジメント・プロジェクトマネジメントをメインにやっていく予定です。 どうしてこの記事を書いたか 弊社は少人数のベンチャーということもあり、1人のエンジニアが複数プロダクトの開発を兼任します。さらに専任のPMはいないので、エンジニア・デザイナーは自然とプロダクトマネジメント・プロジェクトマネジメントをやることになります。私も社内ツールを2、3つほど保守
プロダクトマネージャーに必要なテクニカルスキルを定義してみた話。｜オカダヤスヒロ | プロダクトマネージャー
はじめにここ数年プロダクトマネージャーを名乗る人が増えているかと思います。私もその一人ですが、PMの役割や定義って、非常に曖昧だなーと感じることが多々あります。 プロダクトマネージャーの役割は、それほどはっきりしておらず、曖昧さを抱えています。それが故に、自身のキャリアやメンバーのキャリア育成に悩むことがありました（今でも悩みますが）。 プロダクトマネジメントトライアングルま、私が考えるような悩みは世の中の偉人（？）たちが既に考えており。有名なのはDan Schmidtさんのプロダクトマネジメントトライアングルです。 このプロダクトマネジメントトライアングル。非常に素晴らしいフレームワークなのですが、私や自分の所属している組織には少々難解で、普段のコミュニケーションの中で、うまく利用することができませんでした。 PM個々人のレベル感を捉えるには向いてないかも。という課題感も感じていました。
クラウドワークスを退職します。 - クラウドワークス エンジニアブログ
お世話になったオフィス こんにちは、@ysk_118 です。 実は2020/06/30をもって退職することになりました。 2015/05/18に入社していますので5年とちょっと在籍していたことになります。 時系列とKPTでこの5年を振り返ります。 whoami やってきたこと 2015年 2016年 2017年 2018年 2019年 2020年 KPT Keep Problem Try whoami この5年で非常に多くのことに携わりましたので、まず軽くやってきたことを振り返りながら何者なのか知っていただけたらと思います。 2015/05〜2016/03: 開発Div. エンジニア 2016/04〜2017/02: プロダクトDiv. 新規事業開発グループ チームリーダー 2017/02〜2018/03: プロダクトDiv. エンジニア -> スクラムマスター -> プロダクトオーナー
WeChat 開発者の 4 つのプロダクト原則 - FoundX Review - 起業家とスタートアップのためのノウハウ情報
#1 黄金の原則: ユーザーはあなたの友だち #2 技術は効率のために #3 KPIは二次的なもの #4 分散型エコシステム Allen Zhangは中国中で「WeChatの父」として知られています。公に知られているZhangの人格は、アメリカにおける伝説となっているSteve Jobsと同様の文化的重要性と重みを持っています。中国の技術シーンにおいて、彼はアーティスト、哲学者として有名です。またそれだけでなく、ユーザーエクスペリエンスを低下させるあらゆるものに反対する激しい使命感を持つことでも知られています。中国中のプロダクトマネージャーたちがWeChatで働き、Zhangのプロダクトに対する鋭い洞察力から学ぼうと集まり、彼が構築した(エンジニアリングや設計主導とは異なる)プロダクト主導の環境から学びました。 その一方で、英語版ウィキペディアでのZhangについての記載はたった3つの文章
専門職と視座
こんにちは。ミクシィでスポーツやライブエンタメ関連の技術部長を担当している石井です。社内向けに書いている記事を少しづつ外部公開していきます。 大規模なサービス開発組織で働いていると、技術職スタッフにおいても、視座の高さを求められることが増えます。「視座の高さ」という単語は、曖昧で、入社していきなり「視座！視座！」と言われても、「えらい人がなんか言うとる」「わいには、まだ早い」くらいで、腹落ちしないと思います。しかし、給与体系にも紐づいていたりするので、給与が上がってくると、「視座をもうちょっとあげてもらわないとね…」と上長から言われれて「えー」となるかもしれません。私の考える「視座の高さ」と、なぜ専門職にも必要になるのかを説明しつつ、サービス開発と組織の関係について考えてもらう機会になればと思います。 私は、エンジニアリングを、単にプログラミングを書いたりすることで技術課題解決するというこ
Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解
プロダクトに必要なスキルを10年維持するために――「スキルマップ」と「ソフトウェア式年遷宮」
プロダクトチームにおけるスキル維持の難しさ プロダクトの運用には、さまざまな知識やスキルが必要です。プロダクトに対するドメイン知識や、プロダクトを実装するために用いているプログラミング言語。アプリケーションフレームワークやミドルウェア、インフラなど数え上げればキリがありません。プロダクトを長い期間運用していくためには、これらの知識やスキルをどのようにチーム内にとどめておくか、ということを考えていく必要があります。 これらは、さまざまな要因でチームから失われていきます。改修や機能追加などで頻繁に手が入るところは良いのですが、あまり手が入らない領域は時間とともに記憶から消えていきます。ドキュメンテーションをしっかりすることである程度防げますが、それでも失われる暗黙知は存在します。また、異動や退職などによって人がチームから去ることもあります。異動や退職の際に、ほとんどの現場では引き継ぎが行われる
【芹澤雅人】20代で技術のスペシャリストになるのを諦めた“文系出身エンジニア”がSmartHRでCTOになれたワケ - エンジニアtype | 転職type
この連載では、注目企業のCTOが考える「この先、エンジニアに求められるもの」を紹介。エンジニアが未来を生き抜くヒントをお届けします！ 企業が行う雇用契約や入社手続きを効率化するクラウド型の人事労務ソフト『SmartHR』。煩雑な業務に掛かる負担を削減したいと考える企業のニーズをつかみ、労務管理クラウドとして、国内シェアNo.１を誇っている。 その勢いとともに、このサービスを提供する株式会社 SmartHRも急成長中だ。 プロダクト開発を担うエンジニアチームを率いるのは、CTOの芹澤雅人さん。同社のメンバーがわずか３人だった頃にジョインし、エンジニアたちのマネジメントやチームビルディングを担いながら、組織の拡大フェーズを支えてきた。 だが新卒でキャリアをスタートした時、芹澤さんは「自分が文系出身のエンジニア」であることにコンプレックスを感じていたという。 それを克服できたのは、あえてスペシャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アニメ制作の常識が変わる!? VRベンチャーとavexが組む 「AniCast Maker」の狙い【西田宗千佳のRandomTracking】