エンジニアが「PMも兼任して」と言われたときの心構え
この記事は プロダクトマネージャー Advent Calendar 2020 17日目の記事です🎄 カンタンに自己紹介 名古屋の企業でフロントエンドエンジニア兼PMをやってます、amakawaです。2年ほど前に事務員からエンジニアに転職して、総勢50名ほどのベンチャーで2年近くバックエンド〜フロントエンドを書きつつ、プロダクトマネジメント・プロジェクトマネジメント業務も担当してきました。 東京へ転居して、2月からディレクターとしてプロダクトマネジメント・プロジェクトマネジメントをメインにやっていく予定です。 どうしてこの記事を書いたか 弊社は少人数のベンチャーということもあり、1人のエンジニアが複数プロダクトの開発を兼任します。さらに専任のPMはいないので、エンジニア・デザイナーは自然とプロダクトマネジメント・プロジェクトマネジメントをやることになります。私も社内ツールを2、3つほど保守
クラウドワークスを退職します。 - クラウドワークス エンジニアブログ
お世話になったオフィス こんにちは、@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. エンジニア -> スクラムマスター -> プロダクトオーナー
Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解
【芹澤雅人】20代で技術のスペシャリストになるのを諦めた“文系出身エンジニア”がSmartHRでCTOになれたワケ - エンジニアtype | 転職type
この連載では、注目企業のCTOが考える「この先、エンジニアに求められるもの」を紹介。エンジニアが未来を生き抜くヒントをお届けします！ 企業が行う雇用契約や入社手続きを効率化するクラウド型の人事労務ソフト『SmartHR』。煩雑な業務に掛かる負担を削減したいと考える企業のニーズをつかみ、労務管理クラウドとして、国内シェアNo.１を誇っている。 その勢いとともに、このサービスを提供する株式会社 SmartHRも急成長中だ。 プロダクト開発を担うエンジニアチームを率いるのは、CTOの芹澤雅人さん。同社のメンバーがわずか３人だった頃にジョインし、エンジニアたちのマネジメントやチームビルディングを担いながら、組織の拡大フェーズを支えてきた。 だが新卒でキャリアをスタートした時、芹澤さんは「自分が文系出身のエンジニア」であることにコンプレックスを感じていたという。 それを克服できたのは、あえてスペシャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
