進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】｜Miz Kushida
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは（7版からはすごく薄い）。 2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験
ロードマップに機能を書くべからず｜小城久美子 / ozyozyo
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
『失敗の責任は私にあります』と言えない責任者たちの話。
昔、あるメーカーで経営企画職を担当していた時のことだ。 営業部の部長から、 「ウチの商品が絶対に安心で安全という証明書って発行できませんかね・・・」 と相談を受けたことがある。 聞けば、大口顧客との取引が受注寸前で、最後にそのような証明書を出せれば契約してもいいと言われているようだ。 しかし仕様書や保証書ならともかく、絶対に安心安全な証明書などどうしろというのか。 安心安全に使えるガスボンベだって火の中に放り込んだら爆発するし、腹痛を治してくれる胃薬でも用法・用量を守らなければ命に関わる。 どういうものを書いてよいのかわからず、先方ともう少し要件を詰めて欲しいと押し返すと、 「絶対安心安全の証明が要件なんですよ・・・」 と埒が明かない。 やむを得ず、一度部長に同行し先方の会社を訪れ、どのような証明を求めているのかをヒアリングすることにした。 応対に出てくれたのは、若い現場主任だ。 熱気と熱
管理職受難の時代！？「マネジメントの地図」を作ったので共有します｜こがねん / 組織開発するマン
こんにちは、こがねんです。ファッションテック企業の管理部門で「組織開発」をしています。 「組織開発」とは何でしょう。 これにはいろいろな定義がありますが、僕は「人の集まりが同じ目的に向かって協働するチームになるためのあれやこれやの働きかけ」と考えています。 会社組織であればミッション・ビジョン・全社戦略といった「同じ目的」に向かっていくために「集団（人の集まり）」から「組織（協働するチーム）」になっていく必要があり、そのためにやること全般が「組織開発」ということになります。 「組織開発」は一人ではできないことが多いので仲間を増やしていくことが重要です。 真っ先に仲間になってもらう必要がある人は会社の代表（社長や会長）でしょう。次に役員クラスの理解も重要になります。また人事部や外部コンサルタントが制度や施策面で仲間になってくれていることも重要です。 こうして仲間を増やしながら進めていくわけで
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
重大事故の時にどうするか？｜miyasaka
ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか？」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって（若干訂正してますが）ここに残して
ジョブズが部下を｢クソ｣と罵った深すぎるワケ
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
ブルックスの法則を可視化できるのか（あるいは、人と月は等価交換できるのか） - STEAM PLACE
書籍:組織パターンにて興味深い数式が紹介されています。 その数式とは、ベテランが新人を鍛えたときのチーム全体の生産性表すものです。 本の中では”託児所”というパターンで紹介されています。 なぜ興味深いのか 人月の神話、ブルックスの法則にある通り、開発者の人数と生産性が比例しないことは自明の理ですが、わたしはそれを論理的に説明することができませんでした。 ブルックスの法則 ブルックスの法則はフレデリック・ブルックスによって提唱された、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。 数式を使ってシュミレートまでできると、開発者の人数と生産性の関係性の説明でき、さらに最適な人数がわかってくるのではないかと考えました。 問題に思うこと さて、プロジェクトを進めていると「開発者をもっと
「誰かが休んだことを、他の誰かが責める」という状況を放置するマネージャーにはなりたくない。
管理者がまずやるべきことは 「仕事が回っていないとしたらそれは管理者である自分のせいであって、誰か休んだ人のせいではない」 ということを、明確に部下や周囲に伝えることなんじゃないかなあ、と思うんです。 何度か似たようなことを書いているんですが、先日こんな記事を読みました。 「いきいきママ」で業務が崩壊した話 もちろん男性社員であるため有給の取得は管理職の顔を窺いながら取ろうとするも「いきいきママ」で空いた穴を埋める必要があるため口頭で却下されていた 残業・夜勤・休日出勤もあり振替で休めるにしてもスケジュールを会社が勝手に決めて2日以上の連休取得も口頭で注意されるような状態だった 更に子持ち男性社員の育休取得で空いた穴を埋めるために有給取得さえ許されない時期もあった 彼らの給与はどうだったか？「いきいきママ」や平社員とほぼ変わらない、幹部候補になっていた男性社員が３人辞める前にこんな事を言っ
TeamGeek から学ぶマネジメント・アンチパターン13選 - Qiita
はじめに 今更ながらTeam Geekを読んでみたら良かったので、個人的に学びが多いと思った箇所をアンチパターンの形でまとめてみました。自分でやってしまった失敗に関係する内容がメインですが、メンバーとして嫌だなと思っていた部分もあります。 いくばくかのリーダー経験を経て(大半は失敗)、チームで結果を出す難しさと大切さを知った時期に、このような良書に出会えたことを感謝しつつ書きました。現在進行形でリーダーとしての働き方に悩まれている方や、これからリーダーになる方の一助となれば、そしてTeamGeekを手に取るきっかけとなれば幸いです。 内容について 冒頭にも書きましたが、以下すべて "アンチ" パターンです。(真似しちゃダメってやつですね) アンチパターンをやってしまうときのリーダーの頭の中を再現して書いてみました。(構成は自分の経験によって再編成しているのでTeamGeekのそれとは少し異
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
障害管理の泥沼から脱出するには - プログラマの思索
リンク先から下記の記事を見つけたので、考えたことをメモ。 【元ネタ】 こんにちは。 ソフトウェアの不具合管理をしているのですが、現在はエクセルファイルを複数社で メール添付で行っています。 この方法だと、 ・どれが最新かわからなくなる.. - 人力検索はてな 不具合管理(障害管理)はソフトウェア開発の中で最も重要で、そしてコントロールが難しいマネジメントだ。 ウォーターフォール型開発で設計、開発、単体テストと順調に進んでも、結合テストや受入テストに入ると、バグが多発してしまって品質がボロボロになってしまうケースは数多い。 ソフトウェア開発が製造業など他の産業の工程と異なる箇所は、結合テスト以降の障害管理だと思う。 各種のモジュールを初めて結合して、インターフェイスが違っていたり、仕様通り作っていても性能が出なかったりする症状が分かる。 いわゆるビッグバン結合で頻発する。 上記の質問を読むと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロー効率性とリソース効率性について #xpjug