nDiki : ミーティング

ミーティング

会議。2人以上で仕事する時に大概必要となるもの。

高橋誠氏は「会議の進め方」の中で目的によって会議を伝達会議・創造会議・調整会議・決定会議に分類している。

スポンサード リンク

2016年10月19日 (水)

チームのワーキングアグリーメントを作るの楽しい

スクラムマスターから「ワーキングアグリーメント(working agreements)を作ってみませんか?」と言われたのでチームでトライしてみました。これ、作るプロセス自体が楽しいですね。チームの一体感が高まるし、チームの自己組織化につながるなと感じました。

ワーキングアグリーメント

  • ワーキングアグリーメントはチームメンバで「合意した」ルールを書き出したもの。チームで合意したものであればどんな事を書いても OK。ミーティングの時刻だったり、ビルドのルールだったり。
  • ワーキングアグリーメントはチームメンバ全員で作る。上がってきたルール案に対して、例えば親指サイン(親指を上・横・下のどちらかに向ける)を使って全員に意思表明してもらい、全員が合意したものを採用する。
  • ワーキングアグリーメントは定期的に見るようにする。ふりかえりなどの際にアップデートしていく。

組織におけるルールは「誰かが作ってみんなが守るもの」というものが多いのですが、チームで合意して作るというのが自己組織化チームでは重要なんですね。

チームで作ったルールを書き出して明文化することでチームメンバ間の思い違いを無くすことができます。また暗黙的なルールは改善しにくいけれど、見える化すると改善の対象とすることができるというメリットもあるとのことです。なるほど。

アジャイルサムライでは「チームの約束」

ちなみにアジャイルサムライにワーキングアグリーメントなんてあったっけかなと思って調べてみたら、同書では「チームの約束 (working agreements)」として「チームが大事にすること (shared values)」とともに書かれていました。

スポンサード リンク
[ 10月19日全て ]

2016年11月17日 (木)

ふりかえりで Lean Coffee やってみた

ふりかえりといえば KPT がメジャーですがスクラムマスターによると「難しい手法だと感じている」とのことで、せっかくなので他の手法をいろいろトライしてみています。今日は Lean Coffee をやってみました。

http://leancoffee.org/

今回のやり方

  1. 話し合うトピックを明らかにする。
    1. 5分間で各自付箋紙に話し合いたいトピックを書く。ふりかえりだけれど内容はプロセスにかぎらずプロダクトの事でも良いとする。
    2. 順番に付箋紙を出して話し合いたいことを簡単に説明する(ここでは議論まで入らないようにする)。
      • 同じトピックを書いた人がいればまとめる。
    3. 付箋紙を眺め、話し合いたいと思ったトピックを各自2つ選び、それぞれしれっとその付箋紙にドットを書く。
    4. 付箋紙をドットの多い順に並べる。
  2. 話し合う。
    1. ドットの多いものから順に1つ取りで7分間話し合う。
    2. 時間になったらそのトピックを続けたいか親指で続ける(上)・終わる(下)・どちらでも(横)で投票する。
    3. 続けるが多いようなら2分延長する。今日は延長は1回まで。
    4. 時間がきたら途中でもそのトピックはいったん終了する(必要があれば別の機会に議論することとする)。
  3. まとめる
    1. 全体の残り時間が無くなってきたところで、今日話し合ったものをふりかえる。それぞれ今後どうするかさっと決める。

雑感

  • 良い点
    • 全員の参加意識と議論への集中度合いが高まる。
    • 決める意欲の多い人がいればその場で何か決まる可能性が高い。
  • 懸念点
    • 検討する時間が短いので、ぱっと出た意見の影響力が強くなりがち。

参加意識が高くなるというのがいいですね。

「時間内で話せるだけ繰り返す」という手法でその時間目一杯使うことになるので、他のミーティングの一部として軽くふりかえりたいというのは向かないということもわかりました。

何回か続けて他の利点・欠点も体感したいと思います。

[ 11月17日全て ]

2016年11月21日 (月)

one-on-one ミーティングをやめようかなぁ

one-on-one ミーティングというと

  • コーチング
  • 信頼関係構築
  • プロジェクト状況の確認・相談

あたりが目的かと思います。特に「コーチング」の時間にすることが大切と書かれている記事を良くみかけます。

実際のところは、話題のきっかけとしてまずプロジェクトの話をしているうちにそれで終わってしまうことも結構多かったりします。

もしプロジェクトの状況の確認や課題の相談がメインなら、週次・あるいは隔週の one-on-one ミーティングが無い方が、早め早めのコミュニケーションにつながりよりスピーディーに物事が進むのではないかと思うわけです。そういう意味では one-on-one ミーティングをやめた方が良いんじゃないかと。

本当ははきちんとコーチングの場にしていくのがベストだとは思いますけどね。

今日のさえずり: パンツ買ったので合宿行ける気がしてきた

2016年11月21日

[ 11月21日全て ]

2017年1月5日 (木)

2017年仕事始め【日記】

昨日は有給休暇をとったので今日が仕事始め。朝よりもお昼の方が風が冷たく感じられる日でした。

ミーティングはしょっぱなから9本。ミーティング駆動で仕事をしているところがあるので無駄では無いのですが、時間を費やしている分より効果的にやっていきたいところ。量もうまく調整していきたいなと。

[ 1月5日全て ]

2017年1月18日 (水)

ミーティング後の事後処理タスクは日誌にチェックリストを作る方が良いかな

ミーティングを開いたり参加したりする際の「事前準備」と「事後整理」タスクについては、今までタスク管理ツール(Remember The Milk)に入れて実行してました。でも今はデイリーノート(日誌)に必要なメモをまとめているので、メモの整理と事後整理完了チェックを一緒にやった方が楽なことに気がつきました。

事後整理タスクについては朝一でデイリーノート上にチェックリストを作り、ミーティング中・ミーティング後にメモを整理したらチェックする(あるいはリストから消す)をするようにしたら捗るようになりました(この時 next action があれば実行しちゃうかタスク管理ツールに追加するかします)。

[ 1月18日全て ]

2017年2月2日 (木)

目標を書き出しておくと実現するというのを意識したきっかけ

非常識な成功法則【新装版】

目標やなりたい姿は書き出しておくだけで実現しやすくなるからお勧めですよ」という話を one-on-one ミーティングの時にしました。

思い返してみると私の場合は神田昌典氏の「非常識な成功法則」という本で読んだのが明確に意識したきかっけだったように思います。読んだあとに目標を書いた Google ドキュメントのファイル中の記載日をみると2007年8月頃のようです。

ふりかえると書き出していたものがいろいろと実現・達成できているなと個人的には感じています。

これをきっかけに、またいろいろ書いておこうかな。

[ 2月2日全て ]

2017年2月9日 (木)

「次のミーティングで確認しておきます」とできるだけ言わないようにする

誰かに確認する必要があるとなった時につい「(その人と一緒になる)次のミーティングで確認しておきます」と言ってしまうことがあります。でもそうすると半日とか1日とか数日とか待ちが発生してしまうんですよね。

実際その場で Slack で確認してしまえば実は5分で確認・決定できたりすることも多々あったりします。遠慮しないですぐに確認します。

[ 2月9日全て ]

2017年2月10日 (金)

超小型の Bluetooth マウスが欲しい

Google スプレッドシートを使っている時は MacBook Pro でもマウスは必須。特に行を移動する時はトラックパッドではやりにくいです。

ミーティングに行く時も最近はデスクで使っている Bluetooth Mouse M557 を持参しているのですが、ちょっとかさばるので超小型の Bluetooth マウスが欲しいなと。

サンワサプライの 超小型 Bluetooth マウス 400-MA078BK が気になったので昨日家電量販店を2店ほど回ってみましたが、サンプル展示はおろか陳列もされてませんでした。確認してたらサンワダイレクト限定商品なのですね。持った感じやクリック感・クリック音など確認して良かったら買ってみたいと思っていたのに残念。

[ 2月10日全て ]

2017年3月12日 (日)

「嫌われる勇気」という対人関係哲学

嫌われる勇気 自己啓発の源流「アドラー」の教え

チームメンバとの one-on-one ミーティングの際に紹介してもらった「嫌われる勇気」を読みました(紹介感謝)。アドラー心理学に著者の持論を加えた「哲学」が哲人と青年という2人の対話の形で語られていきます。著者が重要だとしているところがあらかじめ太字になっていて、そこだけさっと読み返せるようになっているのが良いですね。

読んでいて疑問に感じる点が出てきた頃合いに「青年」が良いタイミングで代わり問うてくれて「哲人」がそれに答えてくれるという流れになっていて、それにのってすっと著者の哲学に引き込まれていく仕組みになっているのは上手いなと感じました。

論旨

「他者がどう評価するかは他者の課題であるので、気にかけず嫌われることを恐れず自分の生き方を貫こう」そして「自己受容」「他者信頼」「他者貢献」によって「自己への執着を他者への関心に切り替えて共同感覚を持つ」ことができ、「誰かの役に立っているという主観的な貢献感という幸福」を得ることができるというところが論旨でしょうか。

「課題の分離」という考え方はなるほどと感じました。そういう考え方をもつことでたしかに他者の評価を気にかける気持ちが落ち着いた気がします。

承認欲求を否定?

ただ(本書で言うところの)承認欲求を否定しきっていいのかは疑問が残りすっきりしませんでした。他人の期待を満たすために生きるのではないというのは確かにそうなのですが、お互いに依存しあっている社会の中で完全に否定しきれるものなのでしょうか?

他者を評価しない?

本書では他者を「評価」しないのが大切と述べています。褒めたり叱ったりするのは背後に操作という目的があるからであり、またそうされた方は「自分には能力がない」という信念を形成してしまうとのことです。かわりに感謝や喜びを伝えるという「勇気づけ」を勧めています。

論としては理解できるのですが、果たして実際に褒めるということを無くしきっても良いのか確信が得られませんでした。

子供の頃に本で学んだことを両親に話したら「良くしっているね」と褒められて嬉しかった記憶が残っています。その褒め言葉でちょっぴり学ぶ能力の自信が高まりましたが、それで縦の関係による能力のなさを感じることはありませんでした。また褒められたことが一時的な外発的動機付けでしかなかったとも感じていなかった気がします。

「他者への評価」、これについてはもう少し学ばないと実践すべきという判断ができないなと。

本書の内容を手放しに自分の価値観や原則に取り込むべきではないというのが読み終えた感想ですが、違った考え方を得るきっかけになりました。本書の考えの根底にあるアドラーの教えについては、デール・カーネギーも影響を受けているということですしあらためて「人を動かす」を読み返したくなりました。


[ 読書ノート ]

[ 3月12日全て ]

2017年3月14日 (火)

第19回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。

スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。

タイミングと時間と参加者

スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。

今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。

  • チームメンバが2時間のプランニングミーティングに耐えられない。きちんとスプリントプランニングするメリットを感じられていない。
  • 3チームのプロダクトオーナー(自分)が時間を確保できない。

もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。

プロダクトバックログアイテムにかけるキャパシティ

完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。

 スプリントのキャパシティ
   = PBI にかけるキャパシティ + スプリントバッファ + それ以外

予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。

今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。

作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。

プロダクトバックログアイテムの選択

基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。

タスク分解と作業時間見積もり

自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。

スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。

[ 3月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィの SNS の企画開発を行うグループでマネージャー・プロダクトオーナーをしています。CS 向上・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.089033s / load averages: 1.05, 0.76, 0.71
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker