[B! management] ledlizerdのブックマーク

ledlizerd id:ledlizerd

managementに関するledlizerdのブックマーク (16)

プロダクトマネジメントトライアングルと各社の PM の職責と JD
プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、﹁プロダクトマネジメント﹂を正確な言葉で定義することは驚くほど難しい。自らを﹁プロダクトマネージャー﹂と呼ぶ人々は、企業ごとに全く違うこと… 記事によれば、プロダクトマネージャーはこれらの領域を健全に機能させることが役割であり、機能がなければ自分で役割を演じたり、補う方法を見つける︵たとえばデザイナーがいなければ、自分でデザインを行ったりデザイナーを雇う︶﹁開発者-ビジネス﹂﹁ビジネス-顧客﹂﹁顧客-開発者﹂の融合領域における、各種の複雑さや衝突、トレードオフの統合を行うといったことが PMの職責であると理解しています。逆に言えば、これらを俯瞰して見ることができる能力が PMには求められています。そうした意味で、PM は様々なことを広く学び、組織やビジネスの変化に柔軟に対応できる必要
ledlizerd 2017/11/29
プロダクトマネージャ

PM

management

プロジェクト管理

あとで読む
リンク
自律的なチームを作るために —組織心理学・臨床心理学の応用—
Developers Summit 2022の登壇スライドです。 https://event.shoeisha.jp/devsumi/20220217/session/3647/ 俺のプロダクト開発用語辞典 https://www.youtube.com/channel/UCnUdhofhFN2RotPou4a55_w オーバーエンジニアリングとは？ https://www.youtube.com/watch?v=6XQOSj7rutI オーバーエンジニアリングとは（ブログ版） https://i2key.hateblo.jp/entry/2021/12/25/101957
ledlizerd 2016/11/10
management

チーム
リンク
マネジメントに悩める全てのエンジニアにささげる　伊藤直也の１人CTO Night
…というのに行ってきたのでメモを晒します。社内共有用に書いたんだけど、秘匿情報もないのでほぼそのまま公開します。乱文かつ文中敬称略にて失礼。～マネジメントに悩める全てのエンジニアにささげる～　伊藤直也の1人CTO Night ｜転職ならDODA︵デューダ︶開発組織マネジメントのコツ対象 : 50 – 100人ぐらいのWeb / 受託会社CTO or VP of Engineering海外ではCTO : テックリードのイメージが強いマネジメントをするのはVPofEが多いCTOがマネジメントしたくなければVPofEを雇うのもありスコープチームマネジメントヒューマンマネジメント基本姿勢﹁イシューから始めよ﹂解の質xイシュー度 -> バリューのある仕事イシュー度 : 問題設定の正しさ問題解決ではなく問題発見にフォーカスマネージャーの仕事は問題設定あとはメンバーが解いてくれるチーム構造開発組
ledlizerd 2016/09/02
あとで読む

management

チーム
リンク
開発組織マネジメントのコツ - Speaker Deck
一人 CTO Night での発表資料です
ledlizerd 2016/08/31
slide

management

development

組織
リンク
伊藤直也さんの一人CTO Nightに一人で行ってきた - comix
巷で話題？のnaoya さんの一人CTO Nightに行ってきましたので、超雑ですがメモを公開しておきます。イベント詳細‥ https://doda.jp/event/seminar/20160830.html オレオレメモなので多少ニュアンス違うところあるかもです。特に二部のパネルディスカッションの部分はかなり文脈を端折っているので雰囲気知るくらいに読んでもらえれば。もし大きく間違っていることあったらご指摘くださいm(__)m ちなみにアニメの話はあんまりなかったよ。では、早速。第一部︻プレゼンテーション︼最速で最高のアウトプットを生み出すチーム作りとは？︻プレゼンテーション内容︼ CTO・技術顧問を複数社経験した伊藤直也氏が、過去の実際の事例をもとに、最高のアウトプットを生み出すチーム作りを解説します。前提として、、、50〜300人くらいの規模の組織が対象 CTOのマネジ
ledlizerd 2016/08/31
あとで読む

エンジニア

development

management
リンク
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。そして大抵の場合、増える方向になりますよね。今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。見積もりとはまずは﹁見積もり﹂とは何なのかを正しく理解したいと思います。一般的には﹁見積もり﹂＝﹁全タスクとその工数を洗い出す﹂というものだと思います。しかしここで以下のことに気をつける必要があります。見積もりとスケジュールとコミットメントは違う見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
ledlizerd 2016/04/06
あとで読む

システム開発

見積

スケジュール

management
リンク
プロジェクトマネジメントは仕組み化が9割
今回はオペレーションに関するスライドです。特にフォーカスすること、フォーカスするためにできることについて解説しています。スタートアップへのアドバイスとして「フォーカスが大事」とよく言われます。それでも実際にフォーカスできているスタートアップは中々いないようです。なのでこのスライドでは、なぜフォーカスすべきなのか、そして実際にフォーカスするためにどうやってオペレーションを効率化すれば良いのかなど、私がこれまで支援の中で得てきた知識をまとめてます。少しでも効率化して、フォーカスできるようになればいいなと願っています。
ledlizerd 2016/02/15
management

プロジェクト管理

仕組み
リンク
残業は悪か？あるいは日本人の生産性が低い最大の理由
最近、残業をするのは社員が悪いというような記事を見たので、一言言っておこうと思う。残業常習者が会社を壊す｜トンデモ人事部が会社を壊す｜ダイヤモンド・オンラインなぜ残業が常習化するか最初に結論を言ってしまうと、経営が悪いからだ。経営と言っても事業戦略ではなく、組織運営という意味での経営だ。残業が常態化しているということは、組織運営ができていないことの証拠だと言っていいだろう。なぜ残業の常態化が経営の失敗だと言えるのか。残業が常態化しているということは、組織がこなすべき仕事に対して人員が足りないことが原因として上げられる。人材の確保に失敗しているのは、経営側の失敗だ。もし社員がダラダラと残って働いているのだとしたら、社員が何をすべきかということがトップダウンで明確に指示されていない兆候かも知れない。何をもってその日の業務が終わりだ判断とすれば良いのか。それは上司からの指示、つまり担当
ledlizerd 2016/01/13
あとで読む

management
リンク
『現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの課題と今後の展望～プロダクトオーナーシップ勉強会～』に参加した #postudy
ledlizerd 2015/09/07
management

プロジェクト管理
リンク
CEDEC2015講演チーム開発をスムーズにするために
CEDEC2015招待講演『チーム開発をスムーズにするために』 http://cedec.cesa.or.jp/2015/session/PRD/11359.htmlRead less
ledlizerd 2015/08/28
slide

まとめ

development

management
リンク
ゲーム開発プロジェクトマネジメント講座
ゲーム開発プロジェクトマネジメント講座２０１１年１０月８日株式会社スクウェア・エニックス CTO 橋本善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞めてしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
ledlizerd 2015/08/07
ゲーム開発

マネジメント

development

見積

management
リンク
1 on 1 で何を話すのか？マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。マネージャ編マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に﹁1 on 1 は君のための時間だよ﹂と説明しておこう。 1 on 1 が始まったら﹁何か話したいこと、気になることある？﹂と問いかけよう。焦ってはいけない。じっくりと待ってみよう。たとえマネージャとしてプ
ledlizerd 2015/07/31
コミュニケーション

エンジニア

management
リンク
TechCrunch
In an attempt at damage control, the CEO of the equity management startup Carta, Henry Ward, today em ailed customers, telling them that if they are concerned about “negative press” tied to the out In the Lego-like world of Roblox, about a hundred blocky avatars march through a lamplit street, wielding Palestine flags that are larger than their own animated bodies. Characters dressed like cartoo
ledlizerd 2015/06/08
プロジェクト管理

programming

management

あとで読む

開発

development
リンク
年金機構の情報流出を見てちょっと思ったこと [ほほほのほ]
いつもならFaceBookに先に書いているんだけど、今日はこっちに。あとでFBにも貼る。いつものごとく時間がないので、雑感を駄文で。年金機構が所謂職員の失敗で、年金情報を流出するという事件が発生した。詳しいまとめは、いつものごとく、高速に素晴らしいまとめをしてくれる日本年金機構の情報漏えいについてまとめてみたを参照。Kangoさん、いつも本当に素晴らしい。さて。この事件とか事件について色々喋っている人とか、大臣と呼ばれる人とかを見ていて感じた雑感を。非常に大量に情報を流出してしまった事件としては、ベネッセ事件があった。詳しくはベネッセの情報漏えいをまとめてみた。を参照。この事件において、ベネッセは様々な方面から散々ぶん殴られた。マスコミもJIPDECも利用者も、好きなようにベネッセをサンドバッグにした。まぁ、自分も殴った側にいるのだから偉そうなことは言えない。この件について、株
ledlizerd 2015/06/04
あとで読む

セキュリティ

management

security
リンク
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
ledlizerd 2015/06/03
開発

ソフトウェア開発

テスト

development

management

programming
リンク
最近の開発フローの改善と、「スプリントおじさん」という取り組み - しるろぐ
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。その中でも特に効果があった2つを紹介する。背景簡単にプロジェクトの背景を説明する。スクラムっぽい開発をしているスプリントの期間は2週間スクラムマスターはいるが専任ではないすでにリリース済みで運用中のWebサービスである基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。スプリントの最後には、レビューをして、次のスプリントの計画を立てる。スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。課題以下のような課題があった。バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
ledlizerd 2015/05/29
開発

アジャイル

agile

management

あとで読む

development
リンク
1