nDiki : コーチ

コーチ

関連情報

2005年5月27日 (金)

すごい会議 - 短期間で会社が劇的に変わる!

rimage:ISBN:4479791183 Webで紹介されているのをみかけて、どんなものかと思って買ってみた。 今月中旬にでたばかりの本で、現在Amazon.co.jp で売上ランキング1位になっている。

本文112ページ、付録48ページ。本文前半では著者、大橋禅太郎氏がエキサイテイングなビジネスの中でハワード・ゴールドマンと出会うまでのお話。一気に引き込まれていく。 その後、ハワード・ゴールドマンからマネージメントコーチを受けた時の様子を描きながら「すごい会議」のエッセンスが語られていく。

この本の良いところは、「あなたのオフィスで実際に明日から使えるように」書かれていて実際に本文の流れを真似しながら適用してみることができるというところである。 また全ページの約1/3を占める付録(裏表紙の方から読み進めていけるようになっている)には惜しげもなく「すごい会議のやり方」がまとめられていて、まさに明日から使えるようになっている。昨日本を買った自分も、早速今日実際に開発会議で適用してみてしまったぐらいである。

実際にちょとやってみると、細かい点については「ここの進行はどうすればいい?」と感じるところも出てくる。 その辺は各自でうまく考えればいいのだろうが「もっと、詳しく話(解説)を聞きたい」という人もきっと多いはず。 大橋氏はマネージメントコーチのビジネスをしているから、もしかしたらこの本はそういうことも計算されて書かれているのかもしれない。

手に持った時の本の厚さを考えると税込み1470円はちょっと高く感じるが、読んで得られるものがあれば十分もとが取れるであろう。


[ 読書ノート ] [ お薦めの本 ]

スポンサード リンク
[ 5月27日全て ]

2005年12月10日 (土)

すごい考え方

rimage:ISBN:4-8061-2296-3

大橋禅太郎氏による「すごい会議」のやり方のもとになった、マネージメントコーチのハワード・ゴールドマンの著書の翻訳本。

すごい会議」「すごいやり方」に感銘を受け、ぜひハワード・ゴールドマンの著書を読んでみたいと思っていたので早速読んでみた。 最近やりはじめた三色方式で読み切った最初の1冊でもある。

すごい会議」「すごいやり方」の根底にある考えがわかる

なまじ自分がコンピュータ関係なので、OSを使った比喩的キーワードは逆にしっくりこないところがあったが、言いたい事は良くわかる。

自分の場合は、この本の前に「すごい会議」「すごいやり方」を先に読んでいたわけであるが、この本を読み進めていくとそれらの根底にある考え方が見え、リンクしてくる。 それがすごく楽しい。

ぎゅっとエッセンス化した「すごい会議」では分からなかった、詳細な問題解決やプロジェクトの進め方がわかるようになる(もっとも「すごい会議」は会議にフォーカスしているのだから別に悪いというわけではない)。

しかし、「すごい考え方」を読めば「すごい会議」「すごいやり方」はいらないかというと決っしてそうではなくて、逆にこれらの方が分かりやすく心に届く部分も多々ある。

この本のどれかが気にいっているならば、3冊全てを読むのがお勧め。


[ 読書ノート ] [ お薦めの本 ]

[ 12月10日全て ]

2012年5月23日 (水)

[ 5月23日全て ]

2016年3月7日 (月)

雨の銀座でデート

naney:25585598155

今日は有給休暇を取ったのでと2人で銀座にデートに行ってきました。デートは昨年の9月に横浜に行って以来です。あいにく午前中は結構な雨でしたがそのお陰か少し空いていたかもしれません。

今回の回ったのは以下です。

夫婦それぞれ寄りたかったところを一通り回れて満足です。余裕をもって歩ける日は銀座も便利だなと思うようになったのは年齢のせいもあるでしょうか。

[ 3月7日全て ]

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日全て ]

2017年1月10日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会10回目。今日は第10章 スクラムマスター。

「私は 問題を解決するためにいるわけではない。あなた方が問題を解決できるようにここにいるのだ」

チームに作業を依頼したり、仕事のやり方を指示したりすることもできない。スクラムマスターには仕事を完成させる責任はない。

スクラムマスターはコーチのように振る舞いプロセスのリーダーとして支援する役割の人です。

スクラムマスターの存在はスクラムのかなり大きな特徴といえる要素だと思っています。スクラム以外の開発プロセスで同様にコーチ的な役割の人は定義されているのでしょうか。そんな特筆すべきスクラムマスターですが、期待よりかはちょっとあっさりな説明だった感じはします。

誰がスクラムマスターになる?

スクラムマスターの経験豊かな人がいる場合は別として、多くの場合は今いる人の中の誰かになってもらうことになるのでしょう。その場合は

  • ビジネスドメインの専門家の必要はないが技術的知識を理解していること
  • コーチとして質問力がある・辛抱強いこと

が良い条件のようです。

人が少ない場合はどうでしょうか。その場合は複数のチームのスクラムマスターを兼任する形が良く、そうでなければ(有能な人であれば)開発チームメンバがスクラムマスタを兼任するのが良いとのことでした。前の章でも書かれている通りスクラムマスターとプロダクトオーナーの兼任はやめた方が良いとmもあらためて述べられていました。

スクラムマスターはとても1章で全てを語れるものではない奥が深いものなのでしょうね。もし担当することになったら沢山学ぶべきことがありそうです。

[ 1月10日全て ]

About Me

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

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

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

月別インデックス
Process Time: 0.049915s / load averages: 1.42, 0.96, 0.77
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker