2時間でチームビルディング：ノーミングセッション

-
時間が2時間ぐらいしかないけどさっとチームビルディングしたいっていうときにおすすめなのがノーミングセッションです。

ノーミングセッションとは？

このノーミングセッションの基本的なアイディアは、

  • 自分が果たすべき役割と責任
  • ほかのメンバーに期待すること
  • チーム全体のルールであるグラウンドルール

を決めることにあります。

このセッションを経てチームメンバーはどうなるのか？

  • 自分が果たすべき役割や責任の認識齟齬がなくなります。
  • メンバーがある役割については自分がすることに対して、心理的な障壁が少なくなり、その役割におけるメンバーの心理的安全性が増します。
  • また、グラウンドルールは判断できることを増やし、意思決定が早くなります。

具体的にはどうするのか？

よくやる方法としては、以下のような手順で開催します。
  1. 模造紙をチームメンバー分用意してチームメンバーに配ります。メンバーに配られた模造紙は彼のことが書かれる模造紙になります。
  2. 次にチームメンバーに自分が果たすべきだと思っている役割と責任を自分に配られた模造紙書いてもらいます。(15分)
    1. ここでメンバーは自分が期待されていると思っていることを書き出しています。
  3. 次にチームメンバーはほかのチームメンバーに期待していることを付箋に書き出していき、それをほかのメンバーの模造紙に貼ります。(5分×人数分)
    1. この段階であるメンバーが果たそうと思った役割とほかのメンバーから期待されている役割の認識齟齬が可視化されます。
  4. メンバーに対して一人ずつ、自分はどう思ってこの模造紙に記載したのか、ほかのメンバーはその人に対して、どう思って期待していることを書いたのかを話し合って、どこが期待値がずれていたのかを話し合います。(20分×人数分)
  5. 最後に、この辺は上記の話し合いの結果を何かに反映します。(10分)
    1. チームが決めておいた方が良いグラウンドルールを決めてもよいし
    2. 役割が比較的明らかになった場合は明示的に役割分担してもよいです。

おすすめなシチュエーション

  • チームの役割分担が良く分からんという課題感がある場合
  • チームの目標が明らかな場合。

時間はどのくらいかかるのか？

4人くらいのチームだと2時間くらいです。

必要なもの

  • 模造紙：人数分(ホワイトボードでも可)
  • 付箋紙：人数分
  • ペン：人数分


このノーミングセッションはケンブリッジ・テクノロジー・パートナーズによって発案されています。こちらの記事でノーミングセッションの名前の由来を確認することができます。

コメント

コメントを投稿

このブログの人気の投稿

コーチやメンターとの付き合い方

-
なんの話？ マネージャーといわれる人たちにって、一般的に正解のない問題について立ち向かうことが多いと思います。
そういう時にコーチやメンターっていうものに使って、前向きにとらえられた経験があるので、その時のコーチやメンターを使ってみた経験をお話ししたいと思います。
私がどんな時にコーチやメンターを使ったのか、実際使ってみてどうだったのか？どういうときにコーチやメンターを使ってどうなったのかをお話ししていこうかなと思います。

当時何やっていいのかわからず凹んでた 先日、こないだEOFで自分らしいリーダーシップでメンバーから目標設定とか成長って本当に必要なんですかって言われた事についてちょっとお話ししようかなと思います。

この当時メンバーから目標設定とか成長とか必要ですか？って言われた時に
僕はマネージャーとしてほんと何したらいいのかよくわかんなくなっていました。
というのも目標設定とか成長とかをうまく作ってチームの雰囲気は良くなるんじゃないかと思って色々やってたんですけど、
僕は本当に何すればチームが良くなるのかいいのかが全然わかんなかったです。
なので、めっちゃ困ってました。

困ってはいたので、それをどうにかするために本を読んだりもしました。
1on1の本を読んでその通りにしてみたりとか、
成長段階もついての本を読んでこういう段階があるのかフーンって思ったりとか、
その本に書いてあることも通りにやってきました。

例えば1on1の本にはまずは雑談から初めてその人の好きなこととかしていきましょうねって書いてあったので、
雑談から話をするのがいいのねと思って、普段の何してんの？とかから話を聞いていくようにしました。
それで好きなことを知っていくようにしていくとかをトライしてました。

でも、ずっともやもやしてました。

今振り返るとマネジメントの結果が出るのはいかんせんロングスパンなのですが、それが分からず、結果が出なかったからだと思っています。
でもその当時そのこと実感なかったので、ただただ凹んでたりしてました。

マネージャーって仕事へよく言われるエンジニアリングの仕事からするとやっぱで結果が出るのが結構長くなるのでモチベーション下がりがちだったと思います。

例えばコーディングすると結果がすぐに帰ってくるじゃないですか。
実装してテスト書いて、テスト流すとテスト落ちたりテスト成…
続きを読む

DDDと私

-
イメージ
Table of Contents最初にDDDとの出会いDDDに近づく。オブジェクト指向に興味を持つDDDと再び出会う現在、DDDとともに
最初に こんにちは moai です。
この記事は、ドメイン駆動設計 #1 Advent Calendar 2018 の7日目です。

昨日は、@kawakawa さんによるドメインオブジェクトとユースケースの関係についてでした。
今回は私とDDDの話をしようかなと思います。

ここでは、手法の話はしません。
手法の話をご期待の場合は、ご期待には沿えませんので、どうぞこちらでおかえりください。 DDDとの出会い 私がDDDに出会ったのはおおよそ二年前のことでした。
Amazonの購入履歴を見るに、わたしは2016/02/21にエリック・エヴァンスのドメイン駆動設計を買ったようです。

しかし、その時は第一部を読んで満足したような気がします。
ざっくり言うと良さがあんまりわからずに、途中で読むのをやめちゃったんですね。

だって、分厚いんだもの。

そのころ、私は新規開発をたくさんするようになったものの、
CRUDに非常に近い機能を作っており、 DBにうまく値を格納するかに熱心でした。

例えば、あるテーブルのデータをPDFに乗せるとか、
テーブルのデータを使って一覧画面をつくりソートするとかですね。

PDFにデータ載せて、こんなの作ったり、


一覧画面を作ったり。(これは弊社の今の画面なので、とても奇麗ですが昔はもっとおぼこい感じでした。)




そのため、そのころ読んでいたのはData Modeling Resouce Bookという
世の業務アプリケーションで使われているモデリングはこうなっているんだよという本を熱心に読んでいました。

そのころ思っていたこととしては、 うまくテーブル設計できていれば、
モデルの設計はあとからちゃんとついてくると信じていました。
何なら、DDDなんか知らなくても、俺は俺の最強のアプリケーション作れると信じていました。
そして、なんなら英語の本まで参照しちゃう俺すごい、くらいに思っていました。

今思うと、それは正しい局面もあれば、少し複雑になると正しくない局面もあると教えてあげたいですね。

若さ。

そんなこんなで私はDDDと出会いはするものの、
すぐに興味をなくし、
データモデリングという違う技術にご執心でした。 …
続きを読む

ロバストネス分析をやってみるとモードレスっていうのはAPIも単純になっていいなと思った

-
イメージ
そもそも 私、設計スキルを学ぼうと思っていて、本とか読んで、インプットだけはやっていたんですが、設計スキルを発揮するにふさわしい複雑な問題には出会ったことがなかったです。 もともと設計というプロセスを挟むことによって、時間はかかるようになるし、いつでもどこでも必要とは思っていないです。 いろいろ本を読んだ今でも、設計プロセスをむやみやたらに挟むのは良くない派です。 とはいえ、設計プロセスの一つである、ロバストネス分析をやってみると問題が単純化するよという例が得られたので、今回記事を書いてみることにしました。 今回考えた問題 こんなUIが与えられているとします。(Google Keepに保存ボタンがついているものです。) このUIでは、何かしらリストを追加したり、リストの内容を変更したりすることができます。

保存ボタン付きのリスト。リストの一行に保存ボタンがついているのではなく、リストを含むセクション全体に対して、保存ボタンがついている。
何やら、複雑そうな気がします。 ロバストネス分析をやってみるとどうなる？ これを一度ロバストネス分析をやってみることにします。 以下の図において、赤い丸が、ユーザが行う操作で、緑の丸がブラウザ上におけるエンティティです。 また、グレーの丸がサーバ上のエンティティになります。 複雑度がお分かりいただけたでしょうか？ 注目は赤枠で囲われている箇所です。 このUIだと、フロントでサーバ上のリストにある要素か、ない要素かを保存しておく必要があって、実装が複雑になりそうです。 また、APIとしてもRESTだけで表すことはできず、どうしてもリストに削除フラグなどを仕込んで、削除フラグが立っているリストの要素に対してだけ、削除を実施するなどの工夫が必要です。 私はこのロバストネス分析をやってみた結果、この実装はやりたくないなと思いました。 で、どうしたらもっと単純な実装になるUIになるのかなと考えた結果、世の中のリストUIを見ているとリスト全体を含む塊には保存ボタンがついていないことに気づきました。 つまり、モードレスなUIです。 で、モードレスなUIにするとどうなる？
続きを読む