【コラム】本業がフルフルの中で時間を作るための工夫
今回は
The Agile Guild(TAG) Advent Calendar 2018 7日目の記事として書いてみました。
突然ですが、みなさん忙しいですか？
そりゃそうですよね。 私も週5で8時間 + 残業 で勤務をしているのでとてもわかります。
ただ、そんな中でも本業以外のコミュニティー活動、複業、趣味の時間をつくるために私がやっていることをつらつらと書いていこうかと思います。
なぜ、自分の時間を使ってまで活動をするのか
私は主に本業の他に The Agile Guildに7月に、DevLOVEというコミュニティーに3月に参加させていただいています。
そもそも、それまでの私は毎日9:30に出勤し、タスクに追われて22時まで時にはテッペンまで働くことも厭わないようなスタイルでした。 ただ、2018年2月のDevSumiでのある講演を聞いてから私の生活は一変しました。
ちなみにそれについてまとめた記事がこちら。
このブログを始めるきっかけにもなりました。
どんな衝撃を受けたかというと・・・
- 毎日悶々としている中で背中を押してくれた
- 今の自分の状況を打開するヒントがあった
という点です。ここでいくつか気づきを得ました。 それは
- 社内では初めてのことをやっていても外の世界にはすごい人がいっぱいいる！
- 自分にできることは社外にもあるのではないか？
- 同じ志を持った同志は社外にもいるかもしれない。
そこから、カクカクシカジカありまして・・・DevLOVEにJoinしました。 ※ ここにまとめてます。
www.slideshare.netここで思ったのが、
やってみよう！と思うのは誰でもできる。しかし、やらない理由 > やる理由になる人がほとんどではないか？
という疑問です。 例えば、本業以外にやりたいことがあっても、やらない理由はたくさん思いつきます。
- 疲れるし・・・
- 遊びたいし・・・
- 家族がいるし・・・
- 嫁がいるし・・・
- 子供がいるし・・・
- 会社がダメって言うし・・・
- 自分レベルがわからないし・・・
- 本業忙しいし・・・
- 時間ないし・・・
などなど。ただ、そこで諦めていたら、次のステージに進む速度は本業で得られる成長スピードでしかないかなと私は思いました。 そして、本業では得られないスキルを社外の人は持っているかもしれないと。
私にとってそれは「仮説検証」というものでした。
私とTAGと
私は本業でエンジニアとして働いています。 主な業務は、PM、PO、スクラムマスター、AWSエンジニア、セールスエンジニアといった感じで1000人規模の企業においてエンジニア10人弱のチームで37のプロダクトを作っています。 そのため、プロダクトマネージメントという観点で当然ながら顧客に対するマーケティングも行います。 しかし、私の所属する企業では、「マーケティング = 営業の仕事。PMは開発のみに携わる」という文化が根付いていました。 そのため、いくら外部の方とお話ししたり本を読んだりして得た知識で説得を試みてもどことない「顧客のことは営業の方が分かっている」という空気に押し出されて、正しいことができない状況にありました。
しかし、案の定、マーケティングはうまくいかず、手塩をかけて育てたプロダクトは何回も沈んでいきました。 私はもうそんな思いはしたくない。しかし、自分の力不足は否めない。
そこで、直談判し、TAGにおける仮説検証業務にくわえさせてもらいました。
そのため、私におけるTAGの活動は
- 複業で小遣いを稼ぐ
- 自分の実力を確かめる
でもなく、
- 自分が成長する
- TAGにも貢献したい
- それを本業や業界にも還元する
- そして、自分にしかできない形で社会に貢献したい
という側面が強いです。
複業との向き合い方
と私の複業との向き合い方を書いてきましたが、 複業をどう考えるかは人それぞれだと思います。
- 空いた時間でお金を稼ぎたい
- 自分のスキルを活かしたい
- 自分のスキルを伸ばしたい
- 人脈を作りたい
- 世の中を良くしたい
どれもありだと思います。 間違っていないと思います。
では、そのために使う時間は本当に残されていないのでしょうか？
時間を作る工夫
では、具体的に私が時間を作る些細な工夫についてです。
- 行きの電車：調べ物や読書に使う
- 業務中の移動時間：メールやSlackのどうでも言い返しは全てこの時間でしか行わない
- 業務後：積極的に打合せや勉強会を入れて体を慣れさせtる
- 帰りの電車：1日の振り返りと帰宅後のアジェンダを脳内で組み立て
- 帰宅後：入浴後に必ず1時間は確保。ここでブログを書いたり、仕事をしたり。
- 入浴中：アイディア出しの時間に使う
- 就寝直前：読書で頭を休ませ、眠気を誘う
正直全て大したことがないです。ただ、こんな大したことがない方法で時間は作れます。気持ちさえあれば！
改めて・・・
そのために使う時間は本当に残されていないのでしょうか？ やらない理由 > やる理由 になってませんか？
もし、一歩踏み出そうと思った方は、こちらから門を叩いてみてください。
【読書感想】スクラム現場ガイド ~スクラムを始めてみたけどうまくいかない時に読む本~
今日はXP祭りの登壇時にいただいたこの本。
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
ちょうど私自身がステークホルダーとしてスクラムでプロジェクトがひと段落し、来月からProduct Ornerとしてのプロジェクトを始めるうえで、読んでとても良かったと実感しました。
この本の読んで良かった点や感じた3つのことをまとめていきます。
各ポイントを網羅した各テーマ
この書籍は30章の章立てがされています。それぞれは10~15ページで構成されていて、サクサクと読めるもの内容です。 そしてこの各章も準備から実践、緊急対応、上級者向けとステップをおいて書かれており、基礎から応用まで順を追って学ぶことができます。 特に終盤は受託企業としての契約方法やプロジェクトコストの見積もりなど他のスクラム導入書ではなかなか得られないアドバイスが含まれています。
イメージしやすいストーリーと解説
というわけで、各章、満遍なく押さえてられています。一方で、章の中の構成もストレートでわかりやすい構成になっています。 まずは想像しやすいようなストーリー形式でシチュエーションを想像させ、そのストーリーの解説を挟み、最後には実践した際の実践の鍵という構成です。 この構成のおかげでストーリーを読みながら、実践をイメージし、自分の場合の難易度やどう実践しようかを考えている間に解説でストーリーでわかりにくいところをさらに紐解き、難しいと感じている部分のヒントを左もらえる構成で、実践がうずうずなるような印象です。
自分が実践し、成功するための鍵
先述の通り、各賞の最後には"成功の鍵"というページがあり、ここで実践に向けたアドバイスが書かれています。 ただ、この書籍自体が訳書ということで、アメリカ文化と日本文化のギャップは多少感じますが、実際の自分ごと感をしっかり与えてくれるだけでなく、自分への問いを自然に生まれるものでした。
今後のこの書籍との向き合い方
この書籍はある意味、百科事典のような付き合い方もできるかなと感じました。 実際に自分が壁にぶつかった時に逆引きして課題を乗り越えたり、向き合うことに使えると思いました。
そのため、会社のデスクの脇にいつでも手に取れるようにおいておきたい一冊です。
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
【AWS再入門】5分でわかるEC2
AWS Solution Architectをとってもうすぐ早2年。 更新をするにあたり、最新情報をおさらいしようと思います。なので、それに合わせて自分の"学び直したこと"と"気になったこと"をこのブログにも書いていこうかと思います。今日は最初にして最大の情報量になるだろうAmazon EC2です。
Amazon EC2とは
- Amazon Elastic Compute Cloudの略称
- AWSのクラウド上で稼動する仮想サーバー
- そのそれぞれをインスタンスと呼ぶ(仮想サーバーなので、1台と呼ぶのは気持ち悪い。物理的には1つのH/W内に複数インスタンスが動いているので)
- 任意のリージョン、アベイラビリティーゾーンで稼動
- WebブラウザからAWSマネージメントコンソール経由、API、CLI経由での操作が可能
リージョンとは？
- いわゆる国、エリアの概念
- 複数データセンターの集合体
- 2018年現在 18のリージョンと1つのローカルリージョンが存在
- ローカルリージョンとは機能や性能が制限されているリージョン(ちなみに大阪)
- ローカルリージョンを除くリージョンは2つ以上のアベイラビリティーゾーンで構成されている
- リージョン間は高速ネットワークが構築されている
アベイラビリティーゾーン(AZ)
- リージョン内に複数存在する
- 地理、電源、ネットワーク、空調などを互いに影響を受けないレベルで別れたデータセンター群の単位 (よくデータセンターそのものと表現する人もいるが厳密には複数あるらしいのでデータセンター"群")
- リージョン内での災害対策の地理冗長などを目的に複数AZにインスタンスを立ててを組み合わせて利用することが多い
EC2の物理基盤
EC2インスタンスの種類
- インスタンスファミリー + 世代 . インスタンスサイズ という記法で表現 ex) c5.large
- インスタンスファミリー：何に最適かしているか
- 世代：文字通り世代。
- インスタンスサイズ：バーチャルCPU、メモリ、RAM、ネットワークスペックの大小
- インスタンスファミリーと現行の世代は以下 - T2：汎用(開発環境など向け) - M5：汎用(小中規模のDBなど) - C5：コンピュート最適化 - D2：ストレージ最適化(Big Dataなど) - H1：ストレージ最適化(同じくBig Dataなど) - I3：ストレージ最適化(NoSQL DWHなど) - R4；メモリ最適化(ハイパフォーマンスDB) - X1e：メモリ最適化(インメモリDB) - G3：アクセラレーテッド(3Dレンダリング) - P3：アクセラレーテッド(機械学習) - F1：アクセラレーテッド(ゲノム解析)
- 通常は低負荷だが稀にスパイクするサービスのためにT2 unlimitedというオプション機能がある
物理ホストの占有
- ハードウェア占有インスタンス/ EC2 Dedigated Hostの2択
- どちらも専用の物理サーバでインスタンスを起動
- EC2 Dedicated Hostはハードウェア単位のBYOL(ライセンス持ち込み)が可能
- ただしハードウェア自体の直アクセスは両方できない
- そこで第3の選択肢「AWS EC" BareMetal」がプレビュー中
- ハードウェアへのダイレクトアクセスを提供する新しいEC2インスタンスのシリーズ
EC2の機能
- Key pair：EC2は公開鍵認証でアクセスをする。そのための公開鍵と秘密鍵の組み合わせ
- Security Group：インスタンス単位のFirewall機能
- Elastic IP：インスタンスにアタッチできる固定のパブリックIPアドレス
- Elastic Network Interfaces (ENI)：EC2をホストするVPC(Virtual Private Cloud)内の仮想ネットワークインタフェース
- 拡張ネットワーキング：各インスタンスの通信性能を最適化する機能
- Cluster Placement Groups：各インスタンスをグループ化してインスタンス間のネットワーク通信を最適化する機能
- Auto recovery：何らかの原因でインスタンスが落ちた場合に自動復旧させるオプション(起動時の実行コマンドも仕込める)
EC2のストレージ
- 「インスタンスストアボリューム」と「Elastic Block Store(EBS)」の２種類
- インスタンスストア：インスタンスに密結合されたストレージ領域(停止/起動で中身が削除される揮発性メモリ)
- EBS：着脱可能なブロックストレージ(停止/起動で中身が削除されない)
Amazon Machine Image
- インスタンスのイメージを取得して保存する機能。
- AMIを取得してインスタンスを削除しても、AMIからインスタンスをシド作成すればイメージを元にインスタンスを作成できる
- AWS本家だけでなくサードパーティーからも提供されている
インスタンスのライフサイクル
- 起動/停止/削除の３パターン
- 起動(Start)：文字通り実行。Stoped→Runningにステータスが変わる
- 停止 (Stop)：停止状態。Running→Stopedにステータスが変わる
- 削除(Terminate)：削除状態。インスタンス自体を破棄しているので、二度と同じインスタンスは立てられなくなる。
EC2の費用
- 起動時間の1秒単位で課金
- インスタンスの種類によって単価が分かる
- 購入オプションごとにも金額が変わる
購入オプション
- 以下の5種類
- オンデマンドインスタンス：初期費用無し、従量課金
- リザーブドインスタンス：1年間または３年間、常に利用可能なキャパシティ予約により、最大75%の割引
- スポットインスタンス：未使用キャパシティを時価で提供、最大90%の大幅な割引で利用可能。ベットした金額を上回る入札があれば強制終了される
- 専用ホスト(Dedicated Hosts)：インスタンス実行用物理ホストの単位で支払い。
- ハードウェア専有インスタンス( Dedicated Instance)：シングルテナントのため丸々かかる
まとめと私の思うポイント(あくまでテスト対策)
【コラム】RSGT2019で話したかったこと！
来たる2019年1月、毎年恒例となりました、Regional Scrum Gathering Tokyo2019が開催されます。
このイベントのセッションは10月に公募がなされていて、計80を超える応募の中から約30のセッションが行われます。 私も下記の2つを応募してみました！
残念ながら、両方とも採択されるに至らなかったのですが、今回はこの講演でどんな話をしたかったのか、整理してみようと思います。
序文に抱いた思い
今回はまず序文にこんなことを書きました。
"チームで仕事をする"という場面において、気心の知れた仲間や同じ価値観を持った仲間のみとチームを組成できる機会はそうそうありません。
むしろ、自分と異なるスキルや価値観を持つ人や初対面でのチーム組成も少なくありません。
そして、プロダクトを生み出すにあたり、エンジニアのみではなく、企画職、営業職など文化の異なるメンバーが集まることも当然必要になります。
一方で、「スクラム」「アジャイル」といった流儀を営業や企画職にうまく伝え、一緒に進めていくのも一苦労。
言葉の違うチームにおいて、お互いを知りながら、チームを形成するために私が行った「営業、エンジニア合同のスクラム勉強会」についてワークショップ設計時の工夫、そこでの学びをお話しします。
また、初めてでも同じように組織にチームビルディングのワークショップを行っていただけるようなポイントについても紐解いていきます。
これは私が携わっているプロジェクトでのモヤモヤから生まれたものです。 私の所属する会社はソフトウェア、ハードウェア、ネットワークエンジニアが全体の約1%です。 そのため、プロダクトに関しても複数を同時にこなし、チームも2,3人がメッシュ状に絡まなくてはならない、スクラムでいうとアンチパターンに相当する状態で、ビジネスの規模や需要を考えるとここは仕方ない状態です。
一方でチームとしては気心の知れたメンバーとのやりとりを基本としてはいますが、チームビルディングやカイゼン、ふりかえりを重んじる空気には育ちました。 開発チームとしてはそんな状態ではありますが、複数あるプロジェクトにおいては各部署や外部の顧客などステークホルダー異なり、また複数存在するパターンが多くあります。 そのため、PdMに相当する人間が調整を進めていきます。 ただし、発話する言葉の種類や観ている世界が異なることですれ違いやお見合い状態が多く発生しています。 特にそれはメンバーと外部の顧客というよりも
開発チーム - 担当営業 - 外部顧客
という構図の中で
開発チーム - 担当営業
によく起こります。中には 開発チームと外部顧客は意思疎通ができているのに、担当営業との方向が揃わないこともあります。 具体的には
外部顧客「(優先順位は高くないから)もし可能であればお願いしたい」 開発チーム「根本の設計思想に影響するので、代替案としてこれはどうか？」 外部顧客「OK！」
担当営業「いやいや、顧客が最もやりたかったのはそれじゃないから、叶えないと！」
といったことが起こります。
これはどうして起こるのか？私はいろいろ調べてみました。
あらゆるアジャイルやスクラムの書籍や勉強会に参加してもなかなか見つからない。
一つ見えてきたのはそれぞれの役割で
- 評価者が違う
- ゴールが違う
- 価値観が違う
- 嬉しいポイントが違う
と言った点が大きいということ。ただし、これは当たり前ではありつつも解決策に直接結びつくものではありません。 そんな中で出会ったのが、Jeff Patton氏のCSPO(スクラムアライアンス認定プロダクトオーナー)研修で出会った "ディスカバリーチーム"という考えでした。
ディスカバリーチームという考え方
ディスカバリーチームとは開発チームのみならず、営業、企画、アナリスト、デザイナーなども含めたチームでプロダクトを開発する前にインタビューやプロトタイプを活用した仮説検証を行うことで「本当に必要なものだけを作ることに専念する」という考え方です。
この考え方に感銘を受けた私はそこからいろいろと仮説検証を学ばせていただいています。
では、ディスカバリーチームを組めばそれでいいのか？
私はそうではないと思います。
というのも、開発チームで新しいプロジェクトにのぞむ時に
という行動は開発チームはおろかプロジェクトに関わる全員が行うべきではないでしょうか？
そう、それはアジャイルやスクラムを知っていようがいなかろうが。
"アジャイル"、"スクラム"は開発チームだけのものではない。
ただ、いきなりそんなことを言って「なんだそりゃ？」となるのも当然です。 なので、私は営業と企画を交えたスクラム勉強会を開催しました。
内容は全6回で座学半分、ワークショップ半分というで
- アジャイルって何？スクラムって何？
- POとは？SMとは？チームとは？
- 相対見積もりとは？ベロシティーとは？
- 各種セレモニーの意味と内容とは？
- 心理的安全性の高いチームとは？
- プロジェクト、プロダクトのゴールとは？
と言った話をしました。
そんな私の取り組みの中からの気づきや「まだ始められてないけど、どうしたらいいのか？」と言った方々に伝えられればと思って申し込んでみたのが今回の内容でした。
今回は残念ながら採択されませんでしたが、もしご興味がある方がいれば、DevLOVEなど他の場で是非お話しさせていただければと思います。
あらためてS3のデータ整合性モデルを整理してみる(2018年11月現在)
いつも"アジャイル"とか"スクラム"、"カイゼン"みたいな文脈で書いているのですが、 普段の業務の中での関わりが大きいAWSについても書いていこうかと思います。
とある出来事
私の勤める会社のSlackには「困りごとch」というものを設けています。 先日、そこにこんな投稿がありました。
ruby aws-sdkで困りごと s3にオブジェクト登録→ラムダ発火でapi叩く→そのs3オブジェクトにアクセス(deniedされる)→1秒sleep→同じs3オブジェクトにアクセス(成功) なぜすでにあるオブジェクトにアクセスしているのにdeniedされてしまうのか、 一秒待つとdeniedされないのか、わからなくて困っています。
「ああ、あれじゃん！」 と思う方、その通りです。
AWS S3 のデータ整合性モデルに絡んだ話です。
公式のデータ整合性モデル
AWS自体が日進月歩の世界なので、この記事もすぐに廃れてしまうわけですが、 現状を整理しておきます。
ポイント1：もうリージョンごとの差異はない
2015年時点ではこのデータ整合性モデルは
- US Standardリージョン
- それ以外
で一部の挙動が異なっていました。
しかし、2018年11月現在ではこれが解消され、全てのリージョンで統一されています。
※2015年8月にアップデートされました。
ポイント2：オペレーション内容によって異なる
データ整合性モデルはどんなオペレーションを行うかによっても異なります。 具体的には
- 新規登録(New PUTs) = 書き込み後の読み込み整合性
- 更新(Overwrite PUTs) = 結果整合性
- 削除(DELETE) = 結果整合性
という3パターンがあります。
ポイント3：「書き込み後の読み込み整合性」と「結果整合性」の違い
ここで、独自の言葉が2つ出てきました。 この二つの意味はというと
- 書き込み後の読み取り結果整合性 = 登録後すぐにオブジェクトを参照できる(書き込んだ後の読み取りがすぐにできる)
- 結果整合性 = 動作後に読み込みをしても動作前の状態が参照される場合がある(その時点での結果次第)
つまり、ここまでを整理すると
「新規登録したオブジェクトはすぐ参照できるが、それ以外は即時には反映されないこともあるよ」
ということです。
とはいえ、実際は違う！
ここまではあくまで公式で発表されている内容です。Solution Architectの試験などの範囲でもあります。 ただ、これだけを信じていると実際の現場ではハマります！！
そうこれが困りごとchに流れてきた事象です。
端的にお話しすると
「書き込み後の読み込み整合性」とはいっても、書き込みが終わらなきゃ読み込みはできない
ということです。 オブジェクトの新規作成についてはオブジェクトのサイズや種類によらず、書き込み後の読み込み整合性を宣言しています。
しかし、実際はS3に格納後、アクセスできるようになるためにはS3内部で何かしらの処理が行われているので、 稀にアクセスできないことがあります。
これは、いろんなところでも言われています。
こちらの記事より
新しいオブジェクトを Amazon S3 に書き込み、すぐに読み取りを試みます。変更が完全に反映されるまで、Amazon S3は「キーが存在しません」というレポートを表示する場合があります。 新しいオブジェクトを Amazon S3 に書き込み、すぐにバケット内のキーのリストを表示します。変更が完全に反映されるまで、オブジェクトがリストに表示されないことがあります。
そして公式にも
Amazon S3 では、すべてのリージョンで S3 バケットの新しいオブジェクトの PUTS については "書き込み後の読み込み" 整合性を提供しますが、注意点があります。注意点は、オブジェクトを作成する前に (オブジェクトが存在するかどうかを調べるために) キー名への HEAD または GET リクエストを実行する場合、Amazon S3 は、読み込み後の書き込みに対して結果整合性を提供する、という事です。
ドキュメントだけじゃなく、触ってみよう
ということで、ドキュメントで理解できること以外に実際に触ってみると「あれ？」と思うことや「おや？」と思うことがあります。 なので、一番は自分で触ってみること。そして悩んだら、サポートに問い合わせたり、聞いてみること。
そうすることで、知見が広がり、世の中のみんながハッピーになります。
というわけで、誰かの参考になればと思います。
【ワークショップ開催】第4回こそ勉Lab.「あの映像どうなってるの？～気になる映像技術～」
さてさて、今日はうちの会社らしい社内勉強会を開催しました！
今日は先輩社員によるドメイン知識バリバリの内容。 テーマに沿ってこのようなものの最新事例を関わったものや世の中の動向を元にお話いただきました。
- AR
- VR
- OOH
などなど。
90分という尺の中で
「どれが実写でどれがCG?」というクイズであったり、
Youtubeの動画を再生しながらの解説など、とてもためになる内容でした！
そして最後にはワークショップ！ 「学んだことを踏まえて、どうやって新しい技術を生むか」という視点で3チームに分かれて進めました！
また、今回は参加者も10月に合併するまでは別会社だった方や初参加の方もいて、 次に繋がるいい会になりました！
ここ2回で「私以外の方が会をやる！」という目標は達成し、話してもらう土壌が整ったので、 次はまた、私がお話しさせてもらおうかなと思ってます。
そして次の野望としては
- 平日、休日で参加者の層が違うので、それに合わせて実施
- 別拠点のリモート参加
- 裾野を広げる為のメルマガ
- グループ会社への拡散
とどんどんと仲間を巻き込んで加速していこうと思います！
【私のやり方紹介】5本の指で心理的安全性を高めた話
久しぶりのブログになってしまいました。今日からまた頑張って行こうと思います！
今日はチームの心理的安全性のお話。
毎日顔を合わせるチーム。あなたのチームの風通しはどうでしょうか？
「毎日挨拶してるよ！」
「土日もBBQやるくらい仲良しだよ！」
「毎週飲みに行ってるよ！」
といろんなバロメータがあると思います。
ただ、そこには議論をぶつけあえる、時に言いにくいことを言い出せる空気はあるでしょうか？
そんなチームにおける心理的安全性について考えてみます。
ある新人の一言
昨日、チームで恒例にしている感謝の月間MVPというワークをやっていました。詳しくは別でお話ししますが、その中である新人がこんなことを言ってくれました。
「はちさんが僕が体調が悪い時に"もう今日は帰ったら？"と言ってくれたので救われました。それに朝会で行うファイブフィンガーのおかげで言い出しにくい自分の体調や気分のことも隠さず軽い気持ちで伝えられています」
と。
私の取り組みがひとりの新人の心の重荷を取り去ってあげることができたのが、私の中でもとても嬉しいできごとでした。
彼の言うように新人や後輩は
「言っていいのかな？」
「頑張らないと怒られるかな？」
と何かと不安を感じています。
そんな彼らにとって、先輩だらけのチームは心理的安全性が低くなりがち。
一方で、チームの今後を担うのも彼らであり、彼らが100％のパフォーマンスを発揮できる環境こそ、未来に繋がるチームだと考えます。
私のいるチームはそれだけでなく、体調を崩しやすいメンバーが多かったり、気持ちを表に出しにくいメンバーがいます。
そんな彼らに
「ちゃんと言いなさい！」
「絶対休むな！」
というのは逆効果で、まるで北風と太陽の北風のような状態です。
そこで、誰でも気持ちを表しやすい方法をと考えて、カイゼン・ジャーニーにもあるファイブフィンガーを朝会に取り入れました。
口に出しにくいことを表現する
チームにいる以上、言いにくいことの他に言いたいんだけど、言い出せないこともあるでしょう。
赤ちゃんであれば、泣いて表すことができますが、大人は我慢して、我慢して、心の中で苦手意識や嫌いという感情が大きくなり、爆発します。
ただ、そんな人もどこかでアラートを出しているはずで、それがわかりにくいだけかもしれません。
であれば、わかりやすか表せる場を提供することも時に重要で、それもファイブフィンガーの使いどきかもしれません。
Yes／Noでは表せないこと
ファイブフィンガーの使いどきは体調や気持ちを表すときだけではありません。
社内の勉強会や説明会などでも活用できます。
説明会などは内容にもよりますが、どうしても一方的な説明に終始してしまい、最後には質問タイムというものが多いですが、この質問タイムも質問することに抵抗がない人のための時間となってしまい、いつも同じメンバーのみが話している構図ができてしまいます。
また、質問タイムにしてしまうと
・なんかモヤモヤしてる
・どう表現すればいいかわからない
・何がわからないかがわからない
という人の意見を抽出できなくなってしまいます。
そのため、最近では説明終了後にファイブフィンガーを行い、1の人や5の人にその理由を聞いてディスカッションを行ったりします。
そもそも、ファイブフィンガーって何？
さて、ここまで何の説明もなく来ましたが、そろそろ
「ファイブフィンガーって何？」
「きになる！」
という状態になっていないでしょうか？
ファイブフィンガーとは、文字通り、片手の5本の指で今の気持ちや状況を表す簡単なアンケートです。
実施する際は
「全然わからない場合は1、完全に理解したと思う場合は5」などルールを定義し、
「せーの！」でみんなに出してもらいます。
一斉に出すことでいわゆる忖度や顔色を伺うことがなく、アンケートをすることができます。
また、必ず、何かしらを出す必要があるので、全員の様子を可視化することができます。
明日あなたができること
ということで、ファイブフィンガーには道具はいりません。
そして使えるシーンも多く、続けることで心理的安全性を高めることができるかもしれません。
ぜひ、明日の朝会やチームで何かを教えあう際などに活用してみてください！
