事業会社におけるプロジェクトマネジメントの基礎プロジェクトマネジメント初心者に向けた、事業会社におけるプロジェクトマネジメントの基礎を解説した資料
プロジェクトマネジメント手法 vs 絶対にどうにかする覚悟 - ミネムラ珈琲ブログ
WEBサービス開発みたいな界隈でもう5年マネージャー業をしているので、おそらく人並みにはプロジェクトマネジメントの手法に触れてきている。実際やってきたこともあれば、やってはいないが事例やテクニックとして知っていることも含む。*1 そうやって過ごしてきたが、結局プロジェクトマネジメント手法よりも絶対にどうにかする覚悟、つまり精神論の方が重要だという個人的な結論に至っている。 どんなに精緻に工数とリスクを見積もって振り返りを繰り返しても、「まあ遅れてもいいや」という空気ではプロジェクトは遅延し続ける。逆に見積もりが雑でも「どうにかする覚悟」さえあればなんとか目標とした期日に間に合う。 もちろん覚悟と精神論でやっていると残業が常態化して炎上と言って差し支えない状態になるのだが、覚悟がなくて遅延したプロジェクトも最終的に炎上としか言いようのない状態になるので、同じ炎上なら期日に間に合っている方がマ
道の真ん中をきれいにするプロジェクトマネジメント～イケてるチームになるための10原則～ - Qiita
はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが
マネジメントのきっかけは“炎上プロジェクト”。普通のエンジニアがPMにハマったわけ
女性も参加しやすいRuby勉強会「TokyoGirls.rb Meetup Vol.2」。合同会社PeerQuestの社長であり、エンジニアでもある浪川舞氏が、自身の経験を元にプロジェクトマネジメントにとって大切なことを話しました。 実はもともとJavaエンジニアだった 浪川舞 氏（以下、浪川）：よろしくお願いします。私からは、プロジェクトマネジメントについてお話しします。 本日は名立たる企業のRubyistが並んでいますね。私はRuby界隈に参加することは少ないのですが、まいどる（@maidol_28）という名前でTwitterをやっているので、よかったらフォローしてください！ 私は半年前に起業して、今はPeerQuestというシステム開発会社を3人でやっています。キャリアは、音楽大学卒業後に音楽の仕事に就いてたところから始まります。実はエンジニアになったのが5年ぐらい前の2014年と、
Mercari Microservices Platformの進捗（2019年） | メルカリエンジニアリング
Microservices Platform TeamでTech leadをしている@deeeeeeetです． 昨年のMTC2018ではMicroservices Platformチームの立ち上げから1年で僕らが取り組んできたことを紹介しました． speakerdeck.com 具体的にはStranglerパターンによるMonolithからMicroservicesへの段階的なリクエスト移行を行うためのAPI gatewayの開発や，Microservicesのインフラのセットアップを簡単にしサービス開発チームのSelf-service化を進めるためのStarter-kitの開発，GoでのMicroservicesの開発を高速で始めるためのTemplateプロジェクトの開発，Spinnakerの導入などについて紹介しました． これらはPlatformとして最低限の機能を整備したにすぎず，さ
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
実践 9 つのメモリリークどう見つける？/ How to detect 9 types of memory leaks?
ITプロジェクトの失敗はエンジニアのせいではない｜goza(ござ先輩 / YUMOTO Michitaka)
ITプロジェクトに参画するには色んな立場があると思います。ざっと上げるだけでもこんな感じで、失敗する要因はだいたい決まっています。プランニング不足です。 ・受託開発を請けた開発会社として ・プロジェクト支援依頼を請けたコンサルタント・PMOとして ・事業会社のプロジェクト運営側として私はSIer→事業会社→独立してコンサルタントというキャリアを歩んできましたので、全ての立場でITプロジェクトに参画させて頂きました。上手く行った案件もあれば、そうではなかった案件もありました。 SIあるあるだと思いますが、案件が火を吹いてしまうと優秀なエンジニアが矢継早に放り込まれる傾向があります。未熟な人では火を消せませんから。当時SIerに在籍していた私は、結果的にやらかしたPMと優秀なエンジニア、給料変わらないのに優秀な人が貧乏くじを引いてしまうの意味がわからないなぁと思った記憶があります。 その後私も
開発プロジェクトふりかえり会 失敗事例集 - ルニラボ
はじめに 3,4年くらい業務でプロジェクト反省会番長をやっていたので、情報整理も兼ねて「反省会でやらかしたNG集」を作成した。 我々は効率よく業務改善をしたいのであって、ふりかえり会をやりたい訳ではないので、発生しがちなつまらないトラブルはサッと潰しておきたいよね。 ふりかえり自体の方法については書かない。 KPT法 YWT法 NG集 議題編 発生した問題を忘れる NG 反省会までのスパンが長いほどありがちで、「何かProblemが起きたはずだがメンバーが誰一人詳細を憶えていない」事態が発生する。 「喉元過ぎれば熱さを忘れる」というやつ。 お前らさぁ…感はあるが人間そういうもの。 対策 「ふりかえり議題置き場」を作って即座に書き残してもらうようにした。 GitLab,GitBucketなどのIssueを課題管理表として活用。 そのうち、即座に書き残す文化が定着する…はず。 そもそも、短いス
Misocaに必要なことは全て受入プロジェクトで学んだ
こんにちは、 thara aka @zetta1985 です。 7月からMisocaに入社し、現在はRuby on Railsを中心に触っています。 Railsを仕事で使うのは初めてですし、採用面接のペアプログラミングではPythonを使いましたが、今のところなんとかなっています。 自分は入社後1ヶ月間 受入プロジェクト に配属され、そこでMisoca流の仕事の進め方を会得することになりました。 今回は、その受け入れプロジェクトという取り組みのご紹介と、実際に配属された上での感想を述べたいと思います。*1 受入プロジェクトとは 今回の受入プロジェクトでは、入社した人と受入担当の2人が配属され、1ヶ月間同じ課題に取り組みました。 その課題は、普段から開発チームが受入プロジェクトで取り組むのにふさわしいタスクとして日々積み重ねていたものの一つです。 具体的にどのようなタスクに取り組んだかはここ
製品ロードマップの使用をやめて、GISTプランニングを試すべき理由 | POSTD
何年にも渡り、私は相応量の製品戦略、ロードマップ、プロジェクトガントチャートを作成しました。しかし、もうこれらの資料を作ることはありません。以下に説明する優れた代替策を見つけたからです。 まず、以前のやり方はこちらです。 注釈： 戦略 ロードマップ プロジェクトプラン 実行 アジャイル このプランニング方式だと膨大な仕事が必要です。株主全員の同意を得るだけでも大変だと言うのにROIはかなり低くなります。プランはあっという間に現実と一致しなくなり、期間が長いほど、乖離も大きくなります。私の作ったすてきなロードマップやプロジェクトガントチャートが公開する時点で既に古くなっていると気づいたのは、少し経ってからでした。このプランニングもウォーターフォールのひとつなので（有名な ウォーターフォール・モデル とは異なります）、即応性はほとんど期待できません。トップで変更があると、それが波及しボトムでの
デスマーチが起きる理由 - ３つの指標
デスマーチが起きる理由 - ３つの指標 著者： 青い鴉（ぶるくろ）さん @bluecrow2 これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。 今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。 昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。 お願い もしオリジナルの図を保存されていた方いら
身近な例で学ぶMVP（Minimum Viable Product）の重要性
PaulはUXデザイナーであり、デジタルトランスフォーメーションの専門家です。非営利団体や企業のWeb、ソーシャルメディア、モバイルを使ったユーザーとの結びつきを支援しています。 MVP（実用最小限の製品： Minimum Viable Product）とは、わずかな時間でユーザー中心設計に基づくデジタルサービスを構築する素晴らしい手段です。また、MVPは大幅なコスト削減にも繋がります。 私はMVPの概念について数多く記事を書きました。しかし、MVPが正確に何であるかは説明してきませんでした。MVPという言葉を耳にしたことがあっても、その意味を知らない、もしくはなぜ重要とされるのか理解していなければこの記事は役に立つでしょう。 従来のプロセス MVPについて理解するには、まず多くの製品がどのようにして作られているのかを知る必要があります。従来のプロセスを実証するにあたり、新しい建物を建築す
プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか？：プロジェクトマジック：オルタナティブ・ブログ
プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか？ 2015年12月に「会社のITはエンジニアに任せるな」という本を出した。 「経営にとって、ITとは？」がテーマの本なので、「ITを担わせる人材をどう育てるべきか？」という章をもうけたのだが、意外だったのは、「プロジェクトリーダーとプロジェクトマネージャーの違い」という短いコラムへの反応が多かったことだ。 実は用語の混乱を避けるために書いただけなのだが、結構本質的な問いかけも混ざっている。この記事で、少し掘り下げてみたい。 ※以下、プロジェクトマネージャー⇒PM、プロジェクトリーダー⇒PLと表記する ★何が混乱の元なのか？ 大きめのプロジェクトだと、たいてい体制図が作られ、色んなカタカナの役職の人が登場する。ただ、この手の役職名は会社ごとに定義がマチマチなので、毎回関係者間で「これって結局
技術基盤チームとして働いてみて - dunno logs
この記事は Sansan Advent Calendar 2016 - Qiita の代理記事です。年は明けてしまっていますが、残った枠が出ていたので埋めておこうかなと。 ここで話すこと 私が所属する部門で初めて技術基盤チームを置いたことの背景や、活動について 技術基盤チームを置いたことで、初めてチームが分割された時に起こったこと 弊社には運営するサービス + αの開発部門が存在するため、あくまでそのうちの一つの部門の話になります。 どういう部門の技術基盤チームか 所属する開発部門はエンジニアが入れ替わりはあれど 10 名程度所属しています。（インフラエンジニアさんは別に 2 名所属しています） 運営するサービスは足掛けでいうとおそらく運営開始からは 3 から 4 年経っていると思います。 私自身はその開発部門には 3 年程前から部署異動で参加しており、サービスの運営開始から半年から 1
リーダーであるための視野・視座・視点 - Tech Inside Drecom
はじめに 十名～数十名ぐらいのプロジェクトで開発することの多いドリコムだが， プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター，プロダクトデザイン，プランナー，アート，エンジニアリーダーという風に 職種別のリード職を設けていて，エンジニアリーダーの場合はアーキテクチャや安定稼働， (技術的な) ユーザビリティ等への専門性を持って責任を負うのと，エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり，新卒 2，3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う？」と聞くと， よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか，掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕
自走するチームづくりをサポートするときのパターンぽいもの - Mitsuyuki.Shiiba
プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる！」って感じで読んでてワクワクした。良かった。 ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。 立ち止まる時間 やることが多すぎてチームが疲れている。 その状況において 少しでもタスクを早く終わらせてチームに余裕を作りたい！と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。 そこで 5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り
新規事業は「健全な独断」から生まれる？失敗から学ぶ、ドリコム流の新規事業開発とは | SELECK [セレック]
～ドリコムが自社の「失敗」から学んだ、新規事業の開発プロセスとは～ ゲーム事業や広告、メディアなど、様々な事業を展開する株式会社ドリコム。 同社は2016年4月に、社長である内藤 裕紀さんが自らプロデューサーとなり、新規事業プロジェクト「DRECOM INVENTION PROJECT（通称：DRIP）」を立ち上げた。 DRIPは、ドリコムが常に「発明を産み続ける」ためのプロジェクトで、新規事業を成功させることだけを考え、「プロデューサーを中心に」「少数精鋭」というコンセプトを掲げている。 DRIPを束ねる松江 好洋さんは、「過去に新規事業で失敗した教訓を、DRIPに活かした」と語る。今回は松江さんと、同社の新規事業「Clip」のプランナーを務める新井 崇史さんに、同チームの組織作りや、開発の裏側をお伺いした。 新規事業で「やってはいけないこと」をすべてやった過去 松江 戦略コンサルティン
![新規事業は「健全な独断」から生まれる？失敗から学ぶ、ドリコム流の新規事業開発とは | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/78fd195c3c46720f83b03995df7991f3db47b94d/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2018%2F06%2F15164535%2F36e9185e-2b57-4f1d-90db-41690ea7d98b.jpg)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Getting Things Done をベースにした仕事の進め方 / How to Work with Getting Things Done
ITプロジェクトのはじめ方 / How to work around software project
勝てる「開発プロセス」のつくり方
