EC/CRMの自社サービス「prismatix」開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO
この7月からDev PjMにクラスチェンジしました。何もわからない状態から、いかにしてプロジェクトの状態を把握・コントロールしようとしたか、その試行錯誤の記録です。 4ヶ月前に言ってたことダイジェスト Dev PjMになって最初の頃、こんな話を書いていました。 prismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話 | DevelopersIO マネジメントの姿勢 そこで、私は 指揮者(Conductor) として振るまおうと決意しました。 何をしたいのか Devチームを中心として系が回るようにする ことを実現したいと思っています。 もう少しわかり易い言葉でいうと、「prismatixというサービスの 開発 を通じて、顧客およびチームに 価値を届け続けている 状態を作る」のが目的になります。 どうしていくのか Devチームもハッピー、みんなもハッピー な状
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
失敗したエンジニア組織施策としくじりの反省｜nottegra@在宅勤務
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
プロジェクトの発想を活性化させる、『チームの思考能力』とは何か？ | タイム・コンサルタントの日誌から
以前も書いたが、これは、わたしがプロジェクト・マネジメントを学生や社会人に教えるときに、最初に出すクイズの一つである（「Structured Approachができる人、できない人」）。「店を探して予約する」「日取りを決める」「参加者を確定する」、等々、いろんな答えが考えうるし、どれも間違いとは言えない。しかし、わたしがあえてPM講義の最初にこの問いを出すのは、「計画を立てる」という、もう一段抽象度の高い答えが欲しいからだ。 時限的で一過性の取り組み、それも複数の人が関わって、失敗のリスクも伴うような事に取り組む際は、「まず計画を立てる」という思考習慣がほしい。言われなくても、当たり前のことである。そう思う人も多いだろう。ただ、その『当たり前』が、ちゃんと意識され言語化されていてほしいのだ。 ちなみに上記の記事を書いたのは、8年前の2012年7月だ。この年、わたしは東大大学院の柏キャンパス
プロジェクトリーダーというお仕事 - Qiita
概要 そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。 ※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。 軽く自己紹介 2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。 レジュメ https://www.resume.id/branch まずは結論から プロジェクトリーダーの使命 「担当するプロジェクトを成功へと導く」 「プロジェ
プロジェクトの成功と、アウトカム | タイム・コンサルタントの日誌から
「自分がチャレンジする予定のプロジェクトでは、ゴール到達から成功失敗の判断まで半年かかることになっていますが、このような目標設定は適当ですか？」 今回は、この質問を取り上げよう。例によって、大学でプロジェクト・マネジメントの講義をしていた時、学生から出てきた問いである。そして、とても良い質問だ。 このときの講義のテーマは、「ミッション・プロファイリング」だった。この用語は、PMBOK Guideには出てこないので、なじみのない読者も多いかとは思う。プロジェクトにおけるミッション、すなわち使命を、その目的・ゴール及び目標（＝成功基準）などの観点から、分析・定義し文章化する作業である。その結果がプロジェクト・チャーターになる。 授業では特に目標設定の大切さを学生に教え、修士論文や就活を題材に、プロジェクトとしての目標を考える、簡単な演習を入れている。さらに、自分がこれから将来関わるであろうプロ
存在しているだけで役に立つもの | タイム・コンサルタントの日誌から
これも、前回と同じ頃の話だ。 その日、わたし達は午前中の新幹線で出張に出ることになっていた。朝一番でオフィスに集まり、明日までの二日間の打合せで必要な書類一式を最終確認し、一緒にでかける手はずだった。ところが、プロジェクト・チームの一人が、なかなか出社してこない。彼は制御システムの担当で、その日の午後に、自動制御システム・メーカーと打合せする際の中心だった。気を揉みつつも、他のメンバーと書類の確認を続けていたら、ようやく40分近く遅れて、彼がやってきた。 －－どうした。遅かったな。待ってたぞ。 「すみません。ちょっと家内が入院するんで、病院まで送ってました。」 －－なんだ、奥さんが病気なのか。それは心配じゃないか。 「いえ、病気じゃないんです。だから出張は行けます。大丈夫です。」 －－病気じゃないのに、病院に行ったの？ 「今日が出産の予定日だったので・・。」 あきれて、わたしは怒鳴った。
プロジェクトは失敗するものである、という英国人の思想 | タイム・コンサルタントの日誌から
1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム「トーラス」開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ（ロンドン金融街）全体の投下コストは、総額5億ポンドに上っていた。証券取引所のＰ・ローリンズ理事長は、責任をとって辞任する。 「トーラス」は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト「ヴィスタ」をベースに開発されることになっており、本来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。 ちなみにこのプロジェクトは、ローリンズ理事
オーケストラの指揮者かジャズ・バンドのリーダーか － プロジェクト・マネジメントの４つの類型を知る | タイム・コンサルタントの日誌から
前回、「プロジェクト・マネジメントの教育について」（2014-01-27）で、“PM教育の第1ステップは、自分たちが持つべきPM能力がどんなものかを考える”ことだと書いた。あるべき姿が決まらなければ、成長の道筋も決まらないからだ。当然のことである。 ところが、自分の組織に必要な『PM能力』というものに関して、どうも誤解が多いようだ。世の中にあるPM標準、たとえばPMBOK Guide (R)や、それに準拠した資格であるPMP（Project Management Professional）の習得が、「あるべき姿」だと想定している人も多い。あるいは、英国発のPRINCE2や、日本のP2Mでもいいが、これら標準書を教科書のように思い込み、その教科書に自分の現実の方をあわせようとする。これは、プロジェクト・マネジメントの標準化活動がもたらした副作用かな、と感じる。 わたし自身もPMPの資格を持っ
クリスマス・メッセージ：折れない心をもつために : タイム・コンサルタントの日誌から
Merry Christmas! ５年前から、大学でプロジェクト・マネジメントを教えるようになった。今年の前期は東大の大学院で、また後期は法政の学部3年生に教えてきた。それ以外にも、単発的に依頼されて話した事もある。個別のエピソードについては、すでに何度か書いたと思う。しかし全体として、何をどんな風に教えるべきか、いつも悩ましい。 悩む最大の理由は、大学生・院生が実務の経験をほとんど持たない事だ。共同で事に当たることがなければ、プロジェクト・マネジメントの必要性がピンと来ない。また、授業で例題を考えるにしても、ビジネスに関わるケースを採り上げづらい。だからいきおい、「たとえば、あなたが同期30人の集まるパーティの幹事になったとしよう」といった例になってしまう。 それでも、講義を数回聴いた学生は、しだいにその意義が分かる者が出てくる。アンケート用紙にも、「もっと早くからこういう話が聞きたかっ
担当者が問題状況に陥ったら、プロマネがカバーに入るべきか？ | タイム・コンサルタントの日誌から
プロジェクト・マネジメントの講義で、学生に進捗管理について教えていた時のことだ。進捗とは、これまで消化した予算の比率で計ってはいけない。「あとどれくらい仕事が残っているか」で計るべきものである。いつもの持論を、わたしは説いた。進捗管理の最大の目的は、“仕事はいつ終わるのか、あとどれくらいのコストで終わるのか”を予測することにあるからだ。 マラソンにたとえるなら、スタート地点からゴール地点まで約42kmあるが、そのちょうど中間、折り返し点のマイルストーンがある。ここに到達した人は、それまでまっすぐ走ってこようと、多少脇道にそれて余計な距離を走った人も、あるいは道に迷ってさんざん遠回りした人も、等しく進捗率50%だ。なぜなら、残りの距離は誰にとっても同じ21kmなのだから。もしも、仕事の進捗を問われて、「これまで自分はどれだけ努力したか」を答える人がいるならば、その人は進捗の意味を誤解している
プロジェクトマネジャーのための「プロセス設計術」
知識、技術、経験がいずれも豊富なエンジニアを多数抱えていても、プロジェクトはいとも簡単に失敗してしまいます。その根本原因は「プロセス」にあります。本連載は、主にプロジェクトマネジャー（PM）を対象に、プロセスとはどんなもので、どのように設計し、どうプロジェクトの成功につなげればいいのかを中心に分かりやすく解説します。 目次 プロジェクトコンサルタント。大手ソフトウエアハウスで長年、自動車部品メーカーや大手エレクトロニクスメーカーのソフトウエア開発に携わる。品質と納期が絶対の世界に身を置き、現場のリーダーとして100人以上の開発者を統率してきた経験を基に、プロセス設計からプロジェクトマネジメントに展開する独自のコンサルティングアプローチを編み出す。「品質は設計を超えることはできない」という信念のもと、「人と組織の実行品質を高める」ことを主眼に置いたコンサルティングを実践している。コンサルティ
進捗率にはいろいろな定義が可能である | タイム・コンサルタントの日誌から
ＩＴ業界の人からときどき聞く発言の一つに、「ＩＴプロジェクトではクリティカル・パス法なんか使えない」という主張がある。わたしはスケジューリングとかタイム・マネジメントの分野で長く仕事をしてきたが、こういう主張をＩＴ分野以外できいた覚えがない。ＩＴ業界人は知的な人が多いと思うが、自分達の仕事を“特殊な仕事”だと考える傾向も強いように思われる。無論ある意味では特殊な分野かもしれないが、だとしても1日の作業のあとに2日の作業をした場合、合計3日かかるのは、どんな仕事でも共通ではないか。なぜＩＴ業界の人だけ、“ウチの分野は1+2=3の算数が成立しない”といった意味のことを言いたがるのか？ 当初はとても不思議に感じた。 しかし、話しあっていく内に、次第にＩＴ系の人たちの抱える不満、ないし問題がすこしずつ分かるようになってきた。クリティカル・パス法はいうまでもなく、プロジェクト全体を複数のアクティビテ
仕事の最小単位（２）－－アクティビティのパフォーマンスを測る | タイム・コンサルタントの日誌から
アクティビティが『お仕事の最小単位』であり、マネジメントの基本部品であることは前回の説明でご理解いただけたと思う。このアクティビティは、ときに「タスク」と呼ばれることもある。わたしも以前はタスクという呼び名の方を使うことが多かった。だが、プロジェクト・スケジューリング（特にＰＥＲＴ／ＣＰＭ）の理論では伝統的に「アクティビティ」の語が用いられてきたこと、さらにPMIのPMBOK Guide(R)が、activityよりもっと細かな日々の雑務を"daily task"と呼んでいることなどを考え合わせて、このように語法を変えることにした。 ちなみに生産スケジューリングの分野では、アクティビティという語はあまり使われず、ほぼ同じ概念が「タスク」とか「オペレーション」とか、あるいは「オーダー」と呼ばれたりする。もっとも、プロジェクト・マネジメント理論では仕事を中心に、そのインプットとアウトプットとし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://brevis.exblog.jp/28315223/
プロジェクト計画のロジックとは何か 〜 やはりExcelで工程表を書いてはいけない (2) | タイム・コンサルタントの日誌から