nDiki : ミーティング

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

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

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

今日のさえずり: T は地道に築いていく必要がありますね

2017年02月09日

• 11:59 「次のミーティングで確認しておきます」とできるだけ言わないようにする。
• 13:23 T は地道に築いていく必要がありますね。 https://twitter.com/...

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

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

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

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

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

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

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

論旨

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

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

承認欲求を否定?

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

他者を評価しない?

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

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

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

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

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

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

---

[ 読書ノート ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今日のさえずり: ミーティング誰もこないと思ったら、誰も招集していなかったという痛恨のミス

2017年03月14日

• 12:09 ミーティング誰もこないと思ったら、誰も招集していなかったという痛恨のミス。
• 19:39 久しぶりの避難するタイプの防火防災訓練案内で心が躍った。

今日のさえずり: 計算したら週25時間ミーティングで、このままいくと4月から週30時間を超えてしまう

2017年03月27日

• 09:35 今日も荒ぶってる。 (@ 渋谷二丁目交差点 in 渋谷区, 東京都) https://www.swarmapp.com/c/21Ab30nKoRm
• 09:48 MacBook Pro 再起動待ち。
• 09:50 さらに残り約11分か。
• 09:54 完了。
• 12:50 B型インフルエンザウイルスの気配。
• 19:27 計算したら週25時間ミーティングで、このままいくと4月から週30時間を超えてしまうので早急に見直す必要を感じる。
• 19:28 (定例だけで)
• 21:48 久しぶりに ATOK for Android を入れてみたけれど、やはり変換候補に全半表示がないのが不便だな。それ以外は悪くないんだけれど。

さよならランチ【日記】

今日はマネージャーをしているグループ解散にあたりメンバでさよならランチをしました。

「青山 星のなる木」で「ランチ祝い懐石『雅コース』 (税別 4,800円)」を頂きました。さよならランチで「祝い懐石」というのもなんですが、4,800円のコース料理はとても上品でありました。ミーティングがあるので最後のデザートのプリンを食べることなく失礼したのがちょっと無念です。

今後の話やら新卒研修経験者の合宿の話やら、いろいろ盛り上がった楽しい会でした。

今日のさえずり: MacBook Pro をスーパークリーナー万能Jrくんしたらサラサラになった

2017年05月08日

• 08:26 MacBook Pro のパームレストまわりをスーパークリーナー万能Jrくんしたらすっきり綺麗でサラサラになった。
• 09:35 出社。 (@ 株式会社ミクシィ in 渋谷区, 東京都) https://www.swarmapp.com/c/aEfH19aEv8b
• 11:00 思いの外、ゴールデンウィーク明けからミーティングを入れていた。
• 15:00 既に VR なソリティアはある。 https://twitter.com/...
• 20:00 TaskPaper ちょっと飽きてきた。

複数チームへの共有事項を1つのタイムライン型ページに書いてみる

各チームの週次定例ミーティングで共有したい共有事項をどう取りまとめておくのが良いかしばらく考えておりました。それぞれの週次定例ミーティングのアジェンダページに書くのは面倒なので避けたいところ。かといって週別の「今週の共有事項ページ」だとチームによって定例の曜日が違うので新着の共有漏れがおきてしまう感じです。

そうなると日付別にタイムラインとして並べておくのが一番な気がしてきました。各定例ミーティングの際に前回からの未読の部分を共有していくのが良いのかなと。いったん Qiita:Team に共有タイムラインページを作ってそこに書くようにしてみました。やはり日別最強かな。

今日のさえずり: よく考えないである観測値を別の観測値で割り算してなんとか率って

2017年06月09日

• 08:18 よく考えないである観測値を別の観測値で割り算してなんとか率って言っちゃっているのをきちんと見極める。
• 09:29 小銭450円預け入れ。
• 13:27 仙台の人となかよしした。 (@ おばんざい料理 なかよし 並木橋店 in 渋谷区, Tōkyō) https://www.swarmapp.com/c/afW7gWAPbof
• 18:03 「ミーティングのメモを書いているの Emacs じゃない!」と突っ込まれ。 Ulysses ですよ。
• 18:50 エンジニアが PR とつけても Pull Request にしかみえない。
• 19:16 ベリーショコラ。
• 20:43 Google カレンダーの Android アプリで、作成済み予定のカレンダー変更方法がわかりません。

リフレッシュ休暇後初出勤【日記】

龍宮城から戻った気分ほど浮いた感じはしなかったリフレッシュ休暇明けの出勤でした。

朝会やミーティングなどに出つ Slack・メールは 13:00 前に既読し終えました。思ったほどは時間がかからなくて、これぐらいかという感じ。GTD 的に inbox zero にし、今日やる予定のタスクをほぼやっつけ、最近実践しているマニャーナの法則にも従って「新しい仕事は明日やる」という形で残りは整理完了。

帰り際の上司に「(1週間の間に溜まっていたの)だいたいクリアしましたよ」と答えたら「仕事量が足りないんじゃないですか?」と笑って突っ込まれたのはちょっと複雑な心境でした。ちょっと残念。手際・パフォーマンスを評価されるのではなく、むしろ逆にマイナスに評価された気持ちになりました。

早く終わったのを見て声をかける時は自身も注意しなければなりませんね。