読者です 読者をやめる 読者になる 読者になる

mfks17's blog(Life is Good !!)

趣味や思った事を書いていくと思います

PM Beginners #2に行って喋ってきました #pmbeginners

f:id:mfks17:20160611185644j:plain

project management | project management | Sean MacEntee | Flickr

2016/06/10(金)に行われた、PM Beginners #2に行ってきました!!

PM Beginnersとは

あなたのチームは成果を出せていますか?

といってはみたものの、かしこまった場所じゃあないです。

開発の現場で何かお困りでしょうか? その課題は、マネジメントで解決できる悩みではありませんか? そんな悩みをみんなで共有し、互いの経験を通して マネジメントの観点から解決しあいませんか?

プロジェクトマネジメントとはなんぞや? マネジメントってどうしたらいいの? などなど。 ライトな感じ+LTをして共有していきたいなと。

時間の割にLT本数を少なめにして、 1つでも答えを持ち帰れるような議論をしあえたらと思っております!

connpass - イベント説明より

内容

ビギナーズセッション

僭越ながら、僕が「Retrospectives」というタイトルで皆さんに振り返りの知見をお聞きしました。

f:id:mfks17:20160611114543j:plain

トークの概要としては、

  • 振り返りやってますか?
  • どんな感じでやってますか?
  • 振り返りのスコープはなんでか?
  • その他

っていう感じです。

以下、メモです。

  • ケース1

    • 規模20人
    • スプリントの周期
      • 1週間 水曜日 午前中 振りかえり(切り替え) 午後

      →日ごとだと、JIRAをいじる時間を確保

  • ケース2

    • 受託開発
    • 1年に一回大きく
    • コーヒーとか、ケーキとか(盛り上がる)
    • 半日とる
    • ネガティブな話題多い(受託あるある)
    • 負の遺産についての話題が多め?
  • ケース3

    • フェーズの終わりのタイミング
    • 1年に一回くらい
    • 開発、企画、デザイン、営業、購買
    • 1日かけてやる
    • 午前、午後で話しあう
    • 終わったら打ち上げ(大事)
    • 1年に1回なので、わすれやすい
    • もやもやする
    • KPTなんだけど、Tのチェック(効果測定)が漏れがち
  • ケース4

    • デザイナ、PG、プランナー
    • 30人 PGだけ(10名)で振り返り
    • 毎月成果物をだすので、そのタイミングでPGのみで
    • 先月の反省も毎月に振り返る
    • まじめな人がおおい
      • ルールを作る8個(素晴らしい) -できるようになったら、減らす(最大5個 制約)
    • プロジェクト毎でメンバーが違う、なれていない時がある
      • うごいてくれない(課題)
      • 前回の成功体験をうまく、活用できないか
    • 意識改革
      • ホワイトボードに貼り出す
    • 根回し
      • プランナー、デザイナーさんに対して
      • 納品日、優先順、稟議の交渉
      • PGの不明点は他のチームとの交渉も行う
      • でも、なんでもやってあげるのは良いことなのか?
  • ケース5

    • スプリントはない
    • 開発スタート、リリースのタイミングで
    • 2,3週間に1回(振り返りをする意味のあるタイミング)
    • しさくのチーム毎
    • 仕事のやり方についてをテーマに話す
    • 極力仕事しない為にどうするかを話す
  • ケース6

    • KPTを使っている
    • チームがいろいろある
    • チーム毎にやっていた
      • みんなでやりたい(でも、時間とれないチームも)
      • 週1に切り替え(だんだんなれてきた)
  • ケース7

    • 今はスクラムマスターとしてPJに参加している
    • 全社的にスクラム推奨
    • スプリントを回してやっている
    • 次回やる事はドット投票でやる事を決める
  • ケース8

    • 闇が深かった為割愛><

LT

ytnobodyさん

  • Scrum was Fired
  • 前回で得た知見のはなし
  • 締め切りがあるスクラムは壊れる
  • Tidd + ReDD
  • よくある上流工程
    • 立案
    • 要件定義
    • 設計
    • レビュー
    • 開発へ
  • 失敗
    • 立案の時点で工数が足りない
    • 立案が雑で要件定義できない
    • そこでRedd
      • 各工程度にレビュー(完成の定義)
      • 立案レビュー
        • 工数に無理がないか
        • 工数の大きすぎる変更はフェーズを着る
        • 5W1Hに漏れがないか
      • 要件定義レビュー
        • 立案された内容を網羅しているか
        • 既存機能と衝突がないか
      • 設計レビュー
        • 要件漏れがないか
        • 例外ケースの対処がなされているか(テスト項目)
  • ReDDのねらい
    • 上流工程の品質向上
    • テスト工数の削減 -リリース在庫の減少(一番大きい)
  • QA

ytnobodyさんのこの勉強会のBlog記事はこちらです。

magunolia_k_さん

  • PMはどこまで技術を学び続けるのか?
    • 個人的に、perlを学習機会があった
    • 今はScalaが好き
    • でも、自分のプロジェクトに得た技術を投入するのか?
    • Scalaの概念とか、難しいすぎるのでは?
    • でも、ごくたまに実際に手を動かした知見が、役に立つ事(じゃないと話を通せない人)がある
    • でも、マネージャー全員にそれをもとめるのか?
    • 人生の価値は人それぞれ
    • 答えは自分でも出ていません

そんな、Magnolia.Kさんの寄稿はこちらからご覧いただけます

WEB+DB PRESS Vol.90

WEB+DB PRESS Vol.90

Perl Hackers Hub 【第36回】Perlのテストモジュールの使い方・作り方 ……Test::More,Test::Builder,Test::Stream,そしてPerl 6 ……Magnolia.K,監修:Japan Perl Association

また、吉祥寺.pmというコミニュティを運営されています

「吉祥寺.pm」というイベントを立ち上げます | code-stylistics.net

すでに、この勉強会の事をBlogにしたためていらっしゃいました。

i47_rozaryさん

  • 振り返るの落とし穴とその対応
    • あるある
      • この時間必要?
      • 意見が出てこない
      • 話の収集がつかない
      • という問題にぶち当たる
    • GーKPT、G-PDCAをしよう
    • G=Goal
      • Goal=Archive(チームが達成したいゴール)
    • なので、振り返りはそういうモノをテーマにしてやろう
    • 振り返りの目標を明確にしてやる

PDCAの話

最後の雑談で出たお話

  • 「月に行くってぞ」がゴールのPDCAの例
    • ロケットを作っている人は、成果は見えにくいがゴールへちゃんと向かっている
    • PDCAは小さく回すを地で行っていて、着実に山を上っている人は評価されているけど、月には着けないよね
  • PDCAを評価する人が正しく評価しないと、細かく結果を出す人が評価されてしまうという話(高度的な意味で)
    • 参考

感想

ということで、プロジェクトマネジメント系の勉強会で、カジュアルなものは少なく貴重だと思うので、軽い気持ちで参加すれば良いと思います。 ありがとうございました。次回は8月だそうです🍻