[PM向け]死んだMtgを立て直せ~議事録から考える"Mtgの型"について~
背景 ゴリゴリ系エンジニア、pageoです。 TwitterでMtgのあるべき姿についてツイートしたところ、ぼちぼちRT/いいねをもらえたので記事を書くことにしました。(お友達欲しいのでフォローしてください🙏) 最近大手クライアントとのPJに関わることが増えてきたのですが、事前アジェンダ共有なしに急にMtgが開催されるなどの無法地帯な場面に何度か遭遇したので、今回の記事では"Mtgの型"のあるべきについて自分の見解をまとめてみました。 はじめに Mtgの型 以下の章で紹介する"Mtgの型"はMtgというより議事録の書き方に寄っていますが、以下の章に書かれたことを実践することにより劇的にMtgの生産性は上がると思うので、この記事を機に是非自分/組織全体の"Mtgの型"について議論や検討をしてみてください。 いきなり結論 "Mtgの型"で説明する"教え"は以下の4つだけです 第一教: ~アジ
![[PM向け]死んだMtgを立て直せ~議事録から考える"Mtgの型"について~](https://cdn-ak-scissors.b.st-hatena.com/image/square/d4b118190a5bf163e1db49bbe20f392453552e68/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--e1f08BaI--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BPM%2525E5%252590%252591%2525E3%252581%252591%25255D%2525E6%2525AD%2525BB%2525E3%252582%252593%2525E3%252581%2525A0Mtg%2525E3%252582%252592%2525E7%2525AB%25258B%2525E3%252581%2525A6%2525E7%25259B%2525B4%2525E3%252581%25259B~%2525E8%2525AD%2525B0%2525E4%2525BA%25258B%2525E9%25258C%2525B2%2525E3%252581%25258B%2525E3%252582%252589%2525E8%252580%252583%2525E3%252581%252588%2525E3%252582%25258B%252522Mtg%2525E3%252581%2525AE%2525E5%25259E%25258B%252522%2525E3%252581%2525AB%2525E3%252581%2525A4%2525E3%252581%252584%2525E3%252581%2525A6~%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3ARyuga%252520Irie%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzNkYTE4NjRiOTguanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
"戦力外通告"をされるスタッフがどうして生まれるか - Qiita
１．色々な職場を渡り歩いて 15年ぐらいソフトウェア開発の業界にいます。 グローバル企業、大企業、中小企業までいろいろなサイズの現場で手伝いをしたことがあります。 ゆく先々で、"戦力外通告"をされる人をみてきました。 派遣やフリーランスなら契約解除です。 正社員で解雇される人はあまりみたことはないですが、自分から退職エージェントを雇って辞めた人は見たことあります。 僕が見た人は、企業サイドから辞めてほしい人なのになぜ、エージェント雇うんだろうと思うような感じでしたが。 ちなみに、記事のタイトルに「生まれる」と書いたのは、次の理由からです。 雇用関係は、雇い主と労働者の双方向であり、状況もまた一方的にできるものではなく、双方の問題で生じると思うので、「生まれる」という表現にしました。 ２．"戦力外通告"をされる人の特徴 いろいろなパターンがあると思いますが、私が実際に見てきた人の特徴を書いて
スクラムは積極的にカスタマイズして使うべき - Melting Pot of Thoughts
有名な開発フレームワーク”スクラム”が、現代のアジャイル開発にもたらした貢献は多くの人が認めるところだと思います。 私自身も、スクラムの思想である「経験主義」「リーン思考」に強く影響を受けた人間の一人です。 私はスクラムの考え方自体はかなり好きですが、唯一賛成できない点があります。 それは『スクラムの一部を変えたものはスクラムと呼ばない』というルールです。 スクラムガイドには以下のように記載されています。 最後に スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。 ~スクラムガイド2020より抜粋~ おそらくスクラムガイドの著者は「正確な”スクラム”の
スクラムガイド | スクラムガイド日本語版
我々は1990年代初頭にスクラムを開発した。世界中の人たちがスクラムを理解できるように、スクラムガイドの最初のバージョンを2010年に執筆した。それ以来、機能的に小さな更新を加えながらスクラムガイドを進化させてきた。我々は共にスクラムガイドを支援している。 スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の目的があり、スクラムで実現される全体的な価値や結果に欠かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に立たなくなることさえある。 成長を続ける複雑な世界において、スクラムの利用は増加しており、我々はそれを見守っている。スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要
心理的安全性がもたらす効果と、安全性を阻害するBadパターン - ユニファ開発者ブログ
こんにちは。スクラムマスターの渡部です。 最近出版された「心理的安全性のつくりかた*1」という本が、発売から2ヶ月経たずに4版決まった*2り、Tech系カンファレンスでも心理的安全性についてのセッションがあって*3かなり盛り上がったりと、心理的安全性機運の高まりを感じている昨今です。 当然（？）ながら僕も「心理的安全性のつくりかた」を読んで、短期的にも長期的にも今後のふるまいを見直す良いきっかけになりました。 ただ、いかんせん「心理的安全性ってわかりにくい言葉だなぁ」という感想は今でも変わっていないので、備忘的な意味で次の2つのことをブログに残したいと思います。 このブログで扱うこと そもそも、心理的安全性ってなに？どんな効果があるの？ 心理的安全性を阻害するBadパターン このブログで扱わないこと 心理的安全性を構成する4つの因子の詳細 いかにして心理的安全性を高めていくか？ これらは書
正しくないものをつくらない。7つの失敗パターン
正しくないものをつくらない。7つの失敗パターン1. Toshihiro Ichitani All Rights Reserved. 正しくないものをつくらない Ichitani Toshihiro 市⾕聡啓 - サービスづくり7つの失敗パターン - 2. Toshihiro Ichitani All Rights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市⾕聡啓 ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ 0 → 1 3. Copyright (c) 2017 Guild Works Inc. 本⽇のテーマ のべ200本以上(推
プロジェクトの残業を50%削減したタスク管理手法を惜しみなく公開する - Qiita
おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括（開発は外部委託） サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク（チケット）運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育（五十六メソッドを採用した） 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ
数字や営業が苦手なプログラマだから辿り着いた「エクストリーム経営」 | Social Change!
「心はプログラマ、仕事は経営者」プログラマである自分が働きたいと思える会社を作りたいと思って経営をしてきた。結果として、セルフマネジメントでフラットで自己組織化された組織、最近だとホラクラシーと呼ばれるような経営をしている。 いい会社だと言ってもらえることもあって誇らしく思うのだが、果たして本当に良い会社かどうかはわからない。価値観に合致するプログラマにとっては良いかもしれないけれど、合わない人や他の職種の人にとっては全然ダメな会社かもしれない。 よく取材などでも聞かれるが、今の経営スタイルは、たいそう立派な理念や理想があって実現した訳ではなく、プログラマである自分自身が苦手なことをせずに済むように、逆に出来ることと得意なことは徹底的に活かそうとしてきたに過ぎない。 思い返せば、徹底的に極端にしてきたことが功を奏したことから、この経営スタイルは、もし名付けるなら「エクストリーム経営」と呼べ
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
リモートワークの４つの失敗パターンと対処法 | Social Change!
「働き方改革」という言葉が注目される中で、リモートワークにも取り組もうとする企業も増えてきているように感じる。 しかし、これまでオフィスで働くことが普通だった会社の人たちが、いきなりリモートワークに取り組もうとしてもうまくいかないことも多いだろう。うまくいかなくて、リモートワークはやっぱり駄目だ、と思ってしまう人たちもいるかもしれない。 それは非常に残念なことだ。私のところにも、そろそろ失敗したケースの知見が溜まってきつつある。今回の記事では、失敗してしまうパターンと傾向について、そして、そうならないためにマネジメント側で出来ることについて考えてみた。 リモートワークだと集中できて良い？ リモートワークを試してみた人の感想で、よく言われるのが「リモートワークだと集中できてよかった。たまにリモートワークするべきだ」というものだ。 オフィスにいれば、参加の求められる会議が多かったり、電話や内線
ガントチャートはなぜプロジェクトで使えないのか - 誰も教えてくれないプロマネのコツ
今やあらゆる場面で必要とされるプロジェクトのノウハウを、300件以上成功させてきたプロフェッショナルがこっそりお伝えします。 「プロジェクトを計画しよう！」という話になった時、ガントチャートはよく利用されます。しかし、実際に現場でそれがツールとして「使える」かというと、使えなかったりします。 それはなぜなのか、そしてその対策はどうすればいいかをお伝えします。 目次 そもそもガントチャートとは何か？ ガントチャートあるある ガントチャートが現場で使えない理由①：実工数を無視した〆切になりやすい ガントチャートが現場で使えない理由②：タスクの相互依存関係が見えない ガントチャートが現場で使えない理由③：納期に頼ると「学生症候群」と戦うことになる 対策としてのクリティカルパスマネジメント ただ1点だけ問題が… そもそもガントチャートとは何か？ 「プロジェクト計画と言えばガントチャート」と連想され
振り返り6ツール比較!! 〜YWTとKPTとPDCAの違い(あとLAMDAとか経験学習モデルとか)〜 - ざっくんのブログ
こんにちは。ざっくんです。 最近は記事の更新頻度がめっきり少なくなっていました。その辺の、習慣化なのか自制・意志の強さなのかとかの振り返りはまた今度記事にするとして。 今回は前々からまとめようと思っていた「振り返りツール」的な奴らの話をしたいと思います。いろんな種類があって、どれがいいの？とかってなることが多いと思うので自分の中の整理も兼ねて。 この記事の要約 ◆それぞれのツールをいい感じにまとめるとこんな感じ 概要 思考(実行)の流れとの対応 ◆「こんな時はこれを使え！」ってやつははっきり言ってない。目的に合わせてカスタマイズして使うといいと思う。ただまぁ一応、オススメの使い方はこんな感じ。 毎日の個人の振り返り：YWT+経験学習モデル+α イベントの運営振り返り：YWTかKPT イベントでの参加者の学びを深める振り返り：経験学習モデル+グラフィックハーベスティング チームの改善：KPT
結果的にスクラムになってる！なのがいいと思う！ #RSGT2017
Regional Scrum Gathering Tokyo 2017
チーム開発を始める時に決めること - GeekFactory
頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略
技術的負債とどうやって戦うか - Qiita
プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう
なぜ、失敗するプロジェクトは生まれるのか。グロースハックをしようとする時に意外と見過ごされがちな組織の文化。
『MARKETIMES』は、広告収益による運営を行っております。複数の企業と提携し、情報を提供しており、当サイトを通じてリンクのクリックや商品・サービスに関する申し込みが行われた際、提携する企業から報酬を得ることがあります。しかし、サイト内のランキングやサービスの評価について、協力関係や報酬の有無が影響することは一切ありません。 さらに、当サイトの収益は、訪問者の皆様に更に有益な情報を提供するため、情報の質の向上やランキングの正確性の強化に使用されています。 はじめまして、株式会社クリエイターズネクスト 代表取締役の窪田です。 お金ではなく知恵でサイトを成長させたい。その時に考えないといけないのは、「良い文化形成をすることだ」と言うと、驚く方も多いのではないでしょうか。実はグロースハックをする際には幾つか乗り越えないといけない文化としての壁があります。いくら有能なグロースハック担当者がいて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google re:Work
Google：マネージャはやはり重要な存在である
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）
