こんにちは。リンプレスの川上です。 プロジェクトを成功へと導くためには、プロジェクトを適切に管理していくことが重要です。 この記事ではプロジェクト管理技法として代表的な「PMBOK」をご紹介していきます。 目次[非表示] 1.プロジェクトマネジメントとは? 2.PMBOKとは 3.PMIとは 4.PMPとは 5.PMBOKのメリット 6.PMBOK活用の注意点 7.PMBOKの計画プロセス 7.1.スコープ・マネジメント 7.1.1.不十分なスコープ・マネジメント 7.1.2.スコープ・マネジメントの計画 7.1.3.要求事項の収集 7.1.4.スコープの定義 7.1.5.WBSの作成 7.2.スケジュール・マネジメント 7.2.1.無理なスケジュールは立てない 7.2.2.スケジュール・マネジメントの計画 7.2.3.アクティビティの定義 7.2.4.アクティビティの順序設定 7.2.5
共同作業とプロジェクトの成功を確実にするためには、すべてのプロジェクト関係者が自分の役割と責任、および他のプロジェクト メンバーの役割と責任を理解することが重要です。 これは、規模が大きい、分散したチーム メンバーが関与している、複数の部門のスタッフに依存しているなどの理由で、プロジェクト チームがより複雑になっている場合に特に重要です。 RACI とは、Responsible Accountable Consulted Informed の略です。 RACI マトリックスの起源ははっきりしませんが、プロジェクトの成果物と役割を関連付けるために多くの組織で採用されています。 ある Six Sigma のチュートリアルでは、RACI をこのように説明しています。 「一般的に、タスクは少なくとも 1 つの役割、場合によっては複数の役割に関連付けられています。 この役割とタスクの「関連付け」は、
プロジェクト・マネジメントとは何か?概要を解説 プロジェクトでは・・・ 実際のプロジェクトでは、様々な困難が降りかかってきます。 大幅なスケジュール遅延 足りない要員 コスト超過 低品質の成果物 暗く険悪なムードの定例会議 顧客からの叱責 チームメンバー同士の不協和音 これらは、珍しいことではありませんが、かと言って避けられないことでもありません。 世の中には、プロジェクトにおける様々な困難を乗り越えて、成功裏にプロジェクトを終えるプロジェクト・マネージャーも沢山いるのが事実です。 本ページでは、成功するプロジェクト・マネジメントを実現するために、プロジェクトマネージャーがしっておきたい基本知識やマネジメントの基本的な考え方について解説しています。 プロジェクトとは まずは、プロジェクトとは何か確認します。 2つの大事なキーワード プロジェクトという言葉自体は聞いたことがありますよね。一般
前提 主にプロジェクトを始める前に意識/確認しておきたいことが参考になったため、それらを中心にまとめている 今後意識していきたいこと 部分最適の集合体は全体最適にはならない 各部門の努力の投資対効果を最大化するためには全社最適を考える チームと組織の目標を合わせる やりたいことがあるからプロジェクトを発足させるのでなく、中長期で考えて全体で必要と判断したものをプロジェクトとする マトリックス組織(専任でなく兼務でやる場合)の場合、そのメンバーの占有率をの計画段階から決める プロジェクト開始の段階で以下やっておく フェーズ分け ステークホルダーの明確化 ステークホルダーを明確化し、期待、ニーズを明らかにする。サクセスメトリクスの一つになる ルールの明確化 オーナーの明確化 スケジュール/WBSの作成 コミュニケーションチャンネルの明確化 リスクマネジメント リスクマトリクスに沿うと実現可能性
はじめに この記事は、【徹底解説】シリーズの一環です。Daniel Russo氏と共著したスクラムチームに関する学術論文の非技術バージョンになります。Daniel氏は、オールボー大学の教授で、経験的ソフトウェア工学を専門としています。私は、組織心理学者であり、調査開発と統計が好きなスクラムの実践者です。なお、私たちの論文は、現在、学術的なピアレビューを受けています。 スクラムチームの効果性 どうすれば、スクラムチームをより効果的にすることができるでしょうか。書籍、ポッドキャスト、ブログ記事、オンラインで見つける資料のほとんどは、この質問に関係しています。「スケーリングフレームワークは、効果性に対してどのような影響を与えるだろうか」、「スプリントゴールはどうだろうか」、「どうすればチームがもっとオーナーシップを持てるようになるのか」、「スクラムマスターやアジャイルコーチが、演習やワークショッ
デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタル・トランスフォーメーション(DX)」が注目を集めるなか、従来のようなITベンダやシステム部門が中心になって要件定義をすすめるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています。 システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています。しかしながら、システム開発の遅延の過半は要件定義の失敗にあると言われるように、要件定義においては、その過程で様々な問題に直面します。 そこでIPAでは、要件定義の過程で直面する問題への対応をガイドすることが、ユーザへのよりいっそうの支援策となると考え、「ユーザのための要件定義ガイド(初版)」の内容を一新し、「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」と
複数事業に携わるPM組織のスキル成長と評価について、コングロマリットな経済圏を持つDMMのPMから聞く「複数事業を跨ぐPM!なんでもやるDMMに聞く、PM組織の成長と評価の話【開発PM勉強会vol.21】」。ここで合同会社DMM.comの金築氏が登壇。PjM能力の可視化について話します。 金築氏の自己紹介 金築英雄氏:では私から始めます。今回私からは「可視化から始まるPjM育成」といった話をします。まず自己紹介させてください。名前は金築英雄と申します。経歴としてはアプリエンジニア、チームリーダー、諸々の経験を経て、現在プロジェクトマネージャー(PjM)として仕事をしています。 2023年にPMP(Project Management Professional)を取得して、さらにプロジェクト推進とかPjM採用、PjM育成に熱を上げています。今回は可視化がテーマなので、私のステータスなんかも書
「シニアPMに聞く!3000件の新規事業立上げ経験から学ぶ、プロジェクトの始め方。」は開発プロジェクトの中でも特に「立上げ」「始まり」「キックオフ」に絞ったLTおよび相談会を行うイベントです。ここで株式会社Relicの成宮氏が登壇。新規事業開発で重要なスケジュール管理について話します。 成宮氏の自己紹介 成宮吉将氏:事前(告知)とタイトルが変わっています。書いていくうちにスケジュール管理の話で筆が走ってしまったのでスケジュール管理の話をします。それでは始めたいと思います。 よろしくお願いします。期待値とずれていたらごめんなさい。コメントとかで後で補足します。Relicの紹介は先ほど北川さん(北川祐希氏)がしてくれたので、飛ばしますね。 私の自己紹介をします。もともとNECで技術営業やシステムエンジニアをしていました。みなさんが使っている携帯電話の電話網に使う、馬鹿でかいスイッチやルーターを
「シニアPMに聞く!3000件の新規事業立上げ経験から学ぶ、プロジェクトの始め方。」は開発プロジェクトの中でも特に「立上げ」「始まり」「キックオフ」に絞ったLTおよび相談会を行うイベントです。ここで株式会社Relicの北川氏が登壇。開発チームのコミュニケーションを円滑にするための方法について話します。 北川氏の自己紹介 北川祐希氏:私のほうからは「開発チームのコミュニケーションがうまくいくプロジェクトの始め方」として、コミュニケーションのところをお話ししていきます。目次はたくさんありますが、後で見せるのでいったんいいとして。 自己紹介します。私は他業種、ゲーム業界から来ています。実はもともとエンジニア、ゲームプログラマーから始めて、ディレクターとしてディレクションをして、そこからまた別の会社に移った時に企画マンとして働いてまたディレクターをやってと、少し変わったいろいろな経歴があります。
事業会社に勤める人に向けた、プロジェクトマネジメントの基礎講座。社内向けの研修で利用した資料。Read less
こちらのエントリを読んでいたら、なるほどとてもわかるとなった。そしてこの問題については何らかの解を持っておくべきだと思ったため、ちゃんと考えることにしたのがこのエントリの趣旨である。 上述のエントリには、ソフトウェア開発者がスケジュールのコミットメントを求められた場合、精緻にスケジューリングするためのタスクやスケジュールに余裕を持たせるためのバッファを積むしかなくなり、結果としてソフトウェア開発が遅くなってしまうという話が書かれている。 ソフトウェア開発を実際に行ったことがある人であればこの話には凡そ同意できるとは思うが、それ以外の人には理解に苦しむ話となる。 それゆえに、現代においても「この機能はいつまでにリリースするの?出来なかったらどうするの?」といった質問が横行し、それに対して特に意味のないスケジュールを答えるという虚無の応答が多くのチームでいまも行われている。 ビジネスサイドの仕
こんにちは Relicでフロントエンドエンジニアをしていました高橋です。 これまでフロントエンドエンジニアとしてプロダクト開発に関わってきましたが、改めて自分のなりたい像を考え、事業を作れる人材になるためにより事業を推進するポジションにつきたいと感じ、PMを目指しました。 ということで、様々な方に相談した結果まずはPMとして経験を積む必要があるのでweb制作やLPなどのPMから挑戦させていただくことになりました。 ちなみに今回、私がPMとしての役割は以下になります。 ・QCDを保ってリリースする ・アサインを確保する ・スケジュール通りリリースする これまで経験したPMの基本の「キ」があり、型があると思い、整理する意味も込めて記事を作成しました。 今、整理すると当たり前のことですが、いざ業務をしてみるとPMの型のどの段階にして次、何をしないといけないのかがわからなくなるのでやはり基本は重要
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
Home Getting Started On-Call Being On-Call Who's On-Call? Alerting Principles Before an Incident What is an Incident? Severity Levels Different Roles Call Etiquette Complex Incidents During an Incident During an Incident External Communication Guidelines Security Incident After an Incident After an Incident Postmortem Process Postmortem Template Overview What Happened Contributing Factors Resoluti
半年ぶりのカキコ……ども……。気づいたらHRソリューション本部からMFBC-CTO室に異動していたVTRyoです。兼任で引き続きHR系のマネーフォワード クラウドシリーズも担当しています。 ソフトウェアエンジニアとしての経験値が増えてくると、次第にレビュー担当者になることが増えてくるでしょう。私が所属するSREチームでもTerraformの相互レビューが頻繁に実施されています。そこで、事件は起きたのです。 自信を持ってApproveしたPull Requestで次々に事故が起きてしまった 現在HR内のマネーフォワード クラウドシリーズは、モダンな開発基盤へとリプレイス作業を多く行っています。これまで動いていた基盤に感謝しつつ、新しいPlatformへと移行し、最終的に元あったリソースを削除します。 事件はこの リソース削除 で起きました。 チーム内レビュー OK リポジトリ管理者レビュー
プロジェクトマネージャーの頭の中を書いてみました。 (本当は美味しいもの食べたいな、とかコーギーってかわいいよな、とか考えています。) AWS事業本部 マイグレーション部松浦です。 今月の終わりでちょうど入社して1年が経ちます。早い・・・ なので、この1年を振り返ってみたいと思いブログを書きました。 AWS移行におけるプロジェクトマネージャーとは、を考える良い機会になったのでよかったらご覧ください。 (最後に宣伝あり) 入ってからやっていたこと プロジェクトに関わる各種対応、およびチーム立ち上げ時期ということもあり、主に以下のような取り組みをしていました。 プロジェクト対応 提案活動 移行案件の推進、プロジェクト管理 全体的な状況整理や顧客調整 技術的な実務はソリューションアーキテクト(以下SA)、AWSエンジニアの方が対応 チームの立ち上げ 情報整理や調整 AWSプログラム プロジェクト
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
はじめに PMを志してからの半年を振り返り、未来の自分への備忘の意も込めここにまとめました。 前提 当記事で扱うPMとは以下の定義とされているPjMのことです。 プロジェクトマネージャー(PJM)は、開発プロジェクト計画を立案して、プロジェクト全体の品質(Qualit)、スケジュール工数・予算(Cost)、納期(Deliverly)の責任者です。 要件定義、概要設計、基本設計、詳細設計、製造、単体テスト、結合テスト、システムテストといった開発工程があり、進捗管理、品質管理、リスク管理、不具合管理等を行い、ユーザ対応を行います。 設計、製造プログラミング、テストを行うのではなく、全体を取りまとめる人がプロジェクトマネージャーです。 PMを志した背景 4年エンジニアとしての日々を歩むも、半年程前からPMを志すようになりました。 きっかけはエンジニアリングを行う中でのはがゆい出来事なのですが、「
はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか?その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く