Google re:Work - ガイド: 「効果的なチームとは何か」を知る
Google に限らず、多くの組織では、仕事のかなりの部分をチームによる共同作業で進めています。チームは真の成果を生み出す最小の単位で、画期的なアイデアが生み出され評価される場です。従業員はほとんどの仕事をチームの一員として行います。しかし、チームの対人関係に問題が生じたり、メンバーのスキルが適切でなかったり、あるいはチームとしての目標が明確でなかったりすると、生産性の低下やメンバー間の摩擦が生まれるといった問題が生じかねません。 Google のピープル アナリティクス チームは、「Project Oxygen」というリサーチ プロジェクトによって、「優れた上司の条件」を突き止めることに成功しました。このプロジェクトの成功を受けて、Google の研究者はその後、Google 社内で効果的なチームの特徴を明らかにするため、同じ手法を用いて新たなリサーチを実施しました。アリストテレスの言葉
自分のプロジェクトが炎上しない理由について整理する - HIRAエンジニアブログ
私は自慢では無いですがプロジェクトを炎上させたことがありません。 （炎上案件に途中から突っ込まれたことはありますが） 炎上案件の経験や上司からのアドバイス、書籍からの学びによるものが大きいです。 ただ、しっかり言語化して自分のものにしたいと思い、整理しようと考えました。 これを他のPLやメンバーに共有することで炎上プロジェクトが減っていくことを期待したい。 プロジェクトマネジメントする上で、意識していること、大事にしていること 小さな火を消し続ける → 課題管理の徹底、朝会でメンバーと課題を共有し、期日と優先順位を決めて通常タスクより優先して取り組む。 やらないことを決める → 顧客が求めてないこと、成果物に直結しない作業を極力やらない。（とくに過剰な品質管理、プロジェクト管理資料の作成など） 受注前の見積もりの段階で、案件リスクを見極めて、リスクを下げるか受注しない対応をとる → 見積も
マネジメントは教養や所作ではなく、"業務"である｜長村禎庸@EVeM
はじめに「マネージャーは尊敬される人柄じゃないと無理ですよね」 「マネージャーは対人感受性がないと」 「そもそも、人として向き不向きがあるよね」 経営者の方と議論していると、マネージャーを誰にしようかと悩む時、あるいは自社のマネージャーについてコメントをする時、こういうご意見はよく伺います。 これらの問いに対して私の答えは「No」です。 マネジメントはフローもやり方もはっきりと言語化できる"業務"であり、そこにはマニュアルが存在します。訓練すれば誰でも一定程度のレベルで実行可能なものだと考えます。 今回は私が代表を務める会社、EVeMが提唱するマネジメント”業務”の実行方法「THE MANAGEMENT PATTERN」と、それを実行可能にする訓練方法について書きたいと思います。 マネジメントは"業務"であるドラッカーの言葉に「仕事を生産的なものにし、人間を活かすことが、マネジメントの役割
見積せえへんねやったらどうやって予算取りするねんという話｜牛尾 剛
私は世界規模のクラウドプラットフォームの開発者で、現在はシアトル付近に住んでいる。 先日書いた自分のポストに対する反応で面白い意見があってそれを読んでそらそう思うやろなぁと思った。ただ、私も別に嘘を言っているわけではないですし、これでビジネスも回っている。面白そうなので、その辺も調べてシェアすることにしてみました。 ウォーターフォールからアジャイルって開発側の話はいいのだが、それだと管理とか経営とか非エンジニアの理解を得られないので、納得できるところをちゃんと言語化してほしいんだよな。アジャイルの人の「見積もりがない」って言葉を使われるのが一番苦手、ストーリーポイントの設計は「計画と見積もり… — えふしん (@fshin2000) August 1, 2024 自分のチームの開発プロセス的なものこちらの方に自分のチームが現在やっている開発プロセスは書いてある。アジャイルとか、DevOps
ドキュメンテーションを文化にする〜コミュニケーションの「ハブ」作りに取り組んだ4年間～ - MonotaRO Tech Blog
はじめに こんにちは。プラットフォームエンジニアリング部門の池田（@progrhyme）です。 この記事では、モノタロウのテック系の部門で筆者が取り組んできた「ドキュメンテーションプロジェクト」について、下の目次の流れに沿って紹介していきます。 【目次】 はじめに 「ドキュメンテーションプロジェクト」とは プロジェクト発足の背景 ねらい（まとめ） 何をやったか ドキュメンテーションの促進 Confluence → Googleドキュメントへの移行 その結果どうだったか 上手く行ったこと 上手く行かなかったこと まとめ 「ドキュメンテーションプロジェクト」とは 初めに、プロジェクトの概要について簡単に説明します。 このプロジェクトのミッション（＝目標）は主に以下の2つです。 ドキュメンテーションを通してプロジェクト内外のコミュニケーションを効率化し、業務プロセスの効率を上げる 社内のドキュメ
大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫 | MEDLEY Developer Portal
2024-07-02大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫はじめにこんにちは。CLINICS カルテの QA 担当をしております QA エンジニアの かみむら です。 医療プラットフォーム本部 CLINICS 開発チームでは、2年以上に渡り自社レセコン1の開発を行っています。プロダクトは公開済みであるものの鋭意追加機能の開発を続けており、今後も継続して開発する予定になっています。 QA エンジニアの大切な役割の1つとして、プロセス改善があります。ふりかえりはプロセス改善のアイデアを関係者全員で話し合うための肝となるアクティビティですので、規模の大小問わず取り入れたいものです。 この記事ではレセコン開発におけるプロジェクト体制構築時の黎明期から現在の成熟期に至るまでに行った、四半期毎のふりかえり手法や効果について、かいつまんでご紹介します。 プロジェクトの状況
こんなプロジェクトは「炎上」する。PM界きってのトラブルシューターに学ぶ、“火種の種類と火消しテク” - ミーツキャリアbyマイナビ転職
度重なる期日の延期、お客さまの「激怒」、クリティカルな問題の発覚……。 多くのプロジェクトマネージャー（以下、PM）が最も恐れるのは、そんな「炎上」でしょう。巻き返しを図るものの、逆に現場に負担をかけたり、混乱を招いたり。その結果、品質が大きく下がってしまう、あるいはサービスイン（新しいサービスを開始すること）に間に合わないなんてことになれば、PMとしての信用は大きく損なわれてしまいます。 そうしたトラブルをうまく収め、プロジェクトを無事に着地させるには、どのような心構えや技術が必要なのでしょうか？ 今回お声がけしたのは、日本IBMやパナソニックなどで、PMとして数えきれないほどの炎上プロジェクトを解決してきた木部智之さん。日本IBMではPMのグローバル最高位である「シニア・コンプレックス・プロジェクト・マネジャー」に認定された生粋の「火消し屋」です。 そんな炎上対応のプロフェッショナルで
プロジェクトマネジメントのおすすめ本を４つの分類でご紹介｜コーヒー好きのPM
このnoteでは、プロジェクトマネジメント（以下、プロマネと略記）のおすすめ本をマトリックス図に整理してご紹介します。 ◆変更履歴◆ 2024.05.07 初版公開 2024.06.12 以下書籍を追加 ・プロジェクトマネジメント 最強の教科書 ・驚異のプロジェクト実行術 準備編 ・驚異のプロジェクト実行術 実践編 ◆今後追加予定◆ ※追加のお知らせはX（@coffee_nomimasu）にて行います ・プロジェクトマネジメントの基本が全部わかる本 ・プロジェクトマネジメントの本物の実力がつく本 ・プロジェクト・シン・エヴァンゲリオン ・アート・オブ・プロジェクトマネジメント ・ITエンジニアのためのプロジェクトマネジメント入門 プロマネ本を探すときの悩み筆者の本棚にあるプロマネ本プロマネ本を探すとき、多くの方は「プロジェクトマネジメント おすすめ 本」などとキーワード検索して、 プロジェ
キレッキレなPMは他と何が違うのか？ シリコンバレーのPMが重視する「Step Change」という視点
キレッキレなPMは他と何が違うのか？ シリコンバレーのPMが重視する「Step Change」という視点 シリコンバレーのプロダクトマネージャー達に見る、 覚悟を決めたPMは何が違うのか？ #1/4 酸いも甘いも経験してきたシリコンバレーのプロダクトマネージャー 曽根原春樹氏：みなさんお集まりいただきまして誠にありがとうございます。初めましての方も、またお会いできましたねの方も、ご無沙汰しています。曽根原です。今年も「PMカンファレンス」に戻ってきました。 今回はテーマが「覚悟」ということで、どんな話をしようかなと思っていたのですが、みなさんにとって刺激的な話になるといいなと思って、それでこのタイトルに決めたわけですね。「シリコンバレーのプロダクトマネージャー達に見る、覚悟を決めたPMは何が違うのか？」ですね。 本題に入る前に、僕のことをぜんぜん知らないという方もいらっしゃるかもしれないの
失敗から学ぶシステム開発委託 - CARTA TECH BLOG
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み
顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み 新PdM組織での顧客解像度の上げ方 植木氏の自己紹介 植木遼太氏：私からは「新PdM組織で実践した顧客解像度の上げ方」というテーマで発表します。簡単に自己紹介をしてから本題に移らせてください。 私は植木遼太と申します。先ほどの紹介にあったように、今現在は「楽楽精算」のPdMをしています。約2年前に入社しています。キャリアとしては2010年に新卒からインフラエンジニアとしてスタートして、その後、プロジェクトマネージャー、プロダクトマネージャーと役割を変遷させていったかたちのキャリアを歩んできました。 顧客解像度向上のための取り組みBefore／After では本題に移ります。先ほどのテーマにあったように、「顧客解像度の向上って」という話があります。発表の流れとしては、「そもそもこの
予実管理｜福島良典 | LayerX
予実管理はなぜ大事か予算(事業計画)とは現在の事業理解を反映したものである。予算は、売上の発生メカニズムやコストの発生メカニズムをモデル化する。モデルの中には変数(パラメータ)があり、基本的にはこの変数を達成していれば、予算が自動的に達成されるという前提で作られる。つまり予算は、その時点での事業の理解そのものを表している。 予算と実績が合わないということは、事業の理解が浅いということである。何かしら前提としていることが間違っている、見落としていることがある、わかっていないことがあるということである。事業の理解が浅いと、どれくらいのリソースを投下するとどれくらいのリターンが得られるかをコントロールできていないことになるため、投資の不確実性が高い状態とみなされる。 投資の不確実性が高い状態だと、資金調達コストが上がる。仮にまったく同じ構造の事業をもつ2社があるとする。コントローラビリティが高い
本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
プロジェクトはキックオフが9割 | Marginalia
9割シリーズ この記事は、けっこう前にClassiの社内ブログ記事として書いたものだ。一般論として通用する内容だし、社内に閉じておくのはもったいないと思ったので転載する。 プロジェクトの成功は、キックオフの成功にかかっています。なぜなら、キックオフとはプロジェクトの出発点であり、そのキックオフの準備こそがプロジェクトを始める準備であるからです。 準備に失敗することは、失敗する準備をしているようなものです。 https://www.atlassian.com/ja/work-management/project-management/project-kickoffプロジェクトのキックオフの目的プロジェクトキックオフとは何ですか? それは、プロジェクト チームの...最初のミーティングです。このミーティングは、共通の目標とプロジェクトの目的を確認するための機会です。 キックオフミーティングなし
(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl
マネージャー＆リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
ストックマークの社内研修の公開版※資料です。 （※実際に研修で利用したものとは異なります）
「要件定義」のまえに、「要求定義」｜しょーてぃー/ Experience Designer
多くのアクセスがあったので無料化しました 要求定義テンプレも記事内でDLできます。 はじめにはじめましてUX プランナーのShoty(@shoty_k2)です。 今回は「要求定義」をつかった、UX デザインについてご紹介します。 実践用テンプレートも記事内にて配布しておりますので、参考にしてください。 「要求定義」とは要求定義とは、「事業や施策によって実現したいこと」です。ユーザーにどのような状態になって欲しいのか・何をしてほしいのか、ビジネスで何が必要なのかなどを取り決めることです。 要求定義という言葉は、もともとはシステム開発の現場では頻繁に使われている単語で、非技術者の企画者がシステムに求める仕様を定義することです。 「要件定義」と「要求定義」の違い多くの方が「要件定義」という言葉を聞いたことがあるかと思いますが、「要件定義」と「要求定義」の違いについてご存知でしょうか？ ★要件定義
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現代的システム開発概論 2024
仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた
10分でわかるfreeeのPdM
