Stockmark ( https://stockmark.co.jp ) 社内勉強会の資料公開です。
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと!」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
プロジェクトを遂行するためには、工数の見積もりやスケジュール管理が必要になります。正確な見積もりは難しく納期に間に合わなかったり、残業や休日出勤で埋め合わせたりした経験はありませんか? 今回は、より正確に工数の見積もるための手法や、差し込み作業を考慮したスケジュール手法などについて解説されている記事をまとめました。 マネージャー、エンジニア、デザイナーなどすべての方に参考なる内容だと思います。 開発の見積もりとスケジュール管理 クックパッド株式会社の方が実践している見積もりとスケジュール管理方法について紹介されています。工数を見積もるステップや、スケジュールを立てるときの注意点、スケジュール管理の方法について学びたい方におすすめの記事です。 開発の見積もりとスケジュール管理 不安とストレスから解放される見積りとスケジュール方法 開発をしているとき、納期に間に合わなかったらどうしようと不安に
おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括(開発は外部委託) サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク(チケット)運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育(五十六メソッドを採用した) 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ
この1年ほど、プロジェクトのリードを任せてもらえるようになりました。2017年の夏くらいから「プロジェクト推進役」→「PJO」→「Tech Lead」, 「Project Lead」など、正式ではないものの「肩書」のようなものがついていますが、実際にやっていることは「プロダクトの成功に向かってプロジェクトを行動で引っ張っていくこと」で統一されています。 これは別に偉くなったとかではなくて、そういう責任を持ってPJに関わる役割だと思って臨んでいますし、実際マネージャーからもそのように言われています。 自分なりに試行錯誤をして時には成功し、時には失敗しながらなんとかかんとかやってきていているのですが、「あー、この本に救われた」とか「ちょっと前にこの本読んでおけばよかった...」という本があったので何冊か紹介したいと思います。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリフ
おはようございます。いしげ(@oturu333)です。 このブログは モチベーションクラウド Advent Calendar 2018 - Qiita 1日目の記事として書いています。 今回は過去私が1年半に及ぶWebプロジェクトのPMをした経験を語ろうと思っています。 この記事でお話することについて プロジェクトの概要は既存のWebシステムの全面リニューアルです(MCSではありません)。 ざっとやっていたこと サービスをすべて作り直す(リプレイス) PHPのメジャーバージョン2つくらい一気にあげた CakePHP -> Vue.js + Laravel の構成に変えた AWS構成をがっつり変えた 一部マイクロサービス化した 機能の見直し、UI全刷新 ドキュメントが全然なかったのでいろいろ作りつつ進める 当時の私の立場は、開発チームのマネージャーであり、今回お話するプロジェクトの企画者であ
概要 そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。 ※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。 軽く自己紹介 2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。 レジュメ https://www.resume.id/branch まずは結論から プロジェクトリーダーの使命 「担当するプロジェクトを成功へと導く」 「プロジェ
「プロジェクトマネジメント」というと、エンジニアが作業工程を管理するものだと思いがちですが、むしろ非エンジニアこそ徹底すべきものだと思います。 社内、及びチームに向けて参考になる資料を探したのですが、どうもネット上に転がっているものはエンジニア向けの難しいものばかりだったので、自分でまとめてみました。 その名も「料理で例えるプロジェクトマネジメント」 社内で使用したスライドも使って、簡単に説明していきます。 プロマネは誰がやるのか 主にマネージャークラス、責任者クラスの人が該当するように思えますが、実際のところそうでもありません。 例えば弊社の直近の事例をあげると、「魚の臭いに効くハンドソープを作ってよ」と言われた際に、任された人は何をどういう手順で行っていくかといったところですね。 これはマネジメント経験がない人でもいきなり任せられる可能性があるので、まぁぶっちゃけいうと全員知っておいて
春である。4月の花咲く頃になると、今年は何人くらい受講生がいるかな、とそわそわした気持ちを抱えながら、つくばエクスプレスに乗る日が来る。東大の柏の葉キャンパスで「プロジェクト・マネジメント特論」の開講日を迎えるからだ。まだ働いた経験のない学生たちに、PM論を教えるのは、あまり簡単でない。それでも柏の葉キャンパスは大学院なので、皆、とりあえず自分の卒論で多少は苦労した経験を抱えて、入って来る。つまり小さくて個人的ながら、プロジェクト的な取り組みをした訳だ。だから学部生よりは、少しだけ教えやすい。 PM論を教えるにあたって、どんな構成・体系で説明を進めるべきかも、悩ましい。大学で講義を持っている、というと、「じゃあPMBOKを教えるんですね」とたずねてくる人が時々おられる。こういう人は、PMBOK Guide®︎が『教科書』だと信じているのだろう。だがあれは、いくつかあるガイドブックの一つにす
ここでいうプロマネは「プロジェクトマネージャ」で、「プロダクトマネージャ」ではないです。プロダクトマネージャは暇してたらよくないかな。 プロジェクトマネージャの仕事「プロジェクトマネージャ」がなにかっていう点についてはいろんな説がありそうだけど、プロジェクトに関する以下の「6つのマネジメント領域」を調整し続ける専門職だと思っている。 ①スケジュール管理 →どんな順序でいつまでに何をやるか ②スコープ管理 →何をやるのか、何をやらないのか ③コスト管理 →いくらで、もしくは何人でどれくらいの時間をかけてやるか ④品質管理 →アウトプットをどのレベルで仕上げるか ⑤リスク管理 →リスクが顕在化する可能性と、顕在化時の損害を鑑みて何をするか ⑥ステークホルダー管理 →偉い人からは協力を、チームからはパフォーマンスを引き出す 最近では計画駆動のプロジェクトが減って、適応的に対処しなければならないい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く