Quantcast
Channel: モチベーションクラウド Advent Calendarの記事 - Qiita
Viewing all 25 articles
Browse latest View live

新人でもできる信頼関係構築のレシピ

$
0
0

もうすぐクリスマスですね。この記事はモチベーションクラウド2018年アドベントカレンダー21日目になります。昨日は@masao-shimadaさんのQAとしてアジャイル開発で実践すべきことでした。お疲れ様でした。

僕は、この12月からモチベーションクラウドの開発部門に入ったばかりの新人です。前職ではテックリードもやったんですが、まだまだアプリケーションの仕様や使ってる技術を把握はできておらず、チームの皆さんにおんぶにだっこ状態です。
そんな仕事の成果ではなかなか貢献できない中、少なくともみんなと楽しく仕事をするために「信頼関係を築こう」と3週間ほどいろいろと動いてきました。
転職や移動、配属などで、仕事内容以外で信頼を築く必要がある人の助けになれば幸いです。

前提1:組織においてルールよりも信頼が大事

「厳密なルールよりも信頼を想像することが大事」だとリンクアンドモチベーション代表の小笹さんも言ってましたがその通りだと自分も思っています。ルールは増えると結局運用仕切れないし曖昧な部分も絶対に残ってしまう。それをカバーするのが信頼という考えです。
逆に言うと信頼があればルールは少なくて済むので仕事もしやすくてハッピーです。
なんでもいいので信頼を築くことはお互い楽しく過ごすために必須のことだと思っています。

前提2:他の人がやってないことをやるほうが信頼は築きやすい

人の評価は相対評価になりやすいです。部の全員がフロア内に響き渡る大声で挨拶をしている中で、「大きな声で挨拶をしよう」と決めてやっていても、それはなかなか評価されません。
でも、みんな遅刻ギリギリで来る会社で一人だけ朝6時には出社してるとしたらどうでしょう?それは、「あいつはいつも早く来ている」という認識になり、結果信頼が構築されると思います。
他の人と違うことをするというのが信頼を築くポイントです。

やったこと1: 「挨拶をする」(ザイオンス効果)

仕事で成果が出せない以上、やれることは少ないです。なので、誰でもできる「挨拶」を超本気でやることにしました。
殺伐としたチームならいざしらず、モチベーションクラウドの開発チームはみんな普通に挨拶します。それと一線を隔すために「各人と目を合わせながら挨拶する」ようにしてます。
毎日しつこいくらいやるので、やりすぎて「グリーティングハラスメント」(通称: グリハラ)というワードまでできちゃいましたw
最近では他の新人エンジニア達も巻き込んでやってます。
なんでもないことですが、そこで生まれる会話もあるし、お互い気持ちいいのでおすすめです。
行動心理学的にも接触する機会が増えるごとに、抵抗がなくなっていくといわれてるので、接点を増やすのは信頼を築く上で大事な行為かなと思います。

やったこと2: 「寝癖を直す」(リスクヘッジ)

前職だと、寝癖はもはやトレンドマークになってたんですが、リンクアンドモチベーションはコンサルティングがメイン事業の会社であり、開発メンバー以外はビジネスカジュアルやスーツの人が多いです。
きちっとした格好をすることは求められてないですし、今もジーパン&Tシャツですが、寝癖は人によっては嫌悪感を抱かせてしまうリスクがあるため、寝癖は直すことにしました。
前職の人に会うと「成長したね」と褒められますw
格好に制限がないとしても、「見た目は9割」「第一印象は5秒できまる」などといわれるなかで、せめて嫌悪感を抱かれないようにするのは大事かなと思います。

やったこと3: 「毎日半袖でいる」(ブランディング)

これは意図したわけではないのですが、GINZA SIXのオフィスは空調が素晴らしく冬でも過ごしやすい環境です。
もともと体温が高いので、冬でもオフィスの中では半袖でいたら「寒くないですか?」と話しかけられるようになりました。
たまたま半袖がなかったので長袖で出社したら驚かれちゃったので、その日は腕まくりでいることに。。。
そんなこんなで見事「冬でも半袖でいる変なやつ」というブランドが構築され、床に座りながら障害対応していてもよい権利を得ましたw

最後に

信頼関係は約束を守ることを積み重ねることによって築き上げられます。上記は勝手に期待を作り上げることで暗黙の約束を作って、その期待に答えることで約束を守っている感じです。
とはいえ、ビジネスにおいてはやっぱり仕事の成果が一番の信頼要素です。
これからは「すべての組織をこれで変える」ためにモチベーションクラウドも開発チームも最高の作品にできるように、最大限貢献していこうと思います。
みなさま、不束者ですがよろしくおねがいします。


【フロントエンドエンジニア向け】今年お世話になった英語圏の動画学習サービスまとめ

$
0
0

はじめに

こんにちは、モチベーションクラウドの開発にフリーのエンジニアとして参画している@HayatoKamonoです。

この記事は、「モチベーションクラウド Advent Calendar 2018」22日目の記事となります。

概要

Webのフロントエンド分野と言えば、技術の移り変わりが激しいことでも有名で、この目まぐるしく移り変わる技術の変化に対応していかなければ、あっという間に置いてきぼりを喰らってしまいます。

React? Vue? Next? Nuxt? RxJS? Functional Programming? Elm? Ramda.js? GraphQL? Firebase? PWA?

そんな次から次へと新しい技術へのキャッチアップを余儀なくされるフロントエンドエンジニアにオススメなのが、日本ではまだ情報量が充実していない比較的新しい技術に関する情報も一足早く体系化し、まとまった動画コンテンツとして提供してくれている英語圏のエンジニア向け学習サービスです。

英語圏のサービスなので配信される動画コンテンツも英語ではありますが、たいていのサービスでは、英語字幕が付くので、リスニングに自信の無い方であっても、英語がそこそこ読めさえすれば、これらのサービスの価値は得られると思いますし、また、英語の学習にもなって一石二鳥です。

というわけで、この記事では、普段から私が利用している英語圏の学習サービスをご紹介致します。

Frontend Masters

Frontend Masters
Frontend Masters

このサイトでは、名だたるTech企業の第一線で活躍している現役エンジニアが定期的にワークショップを行い、それらの映像がオンラインでライブ配信されます。このサイトのサービス利用者はライブ配信されるワークショップにリアルタイムでオンライン参加することも出来ますし、後日、編集された映像の配信を待って視聴することも出来ます。

「Frontend Masters」という名前がサイトについているだけあって、フロントエンド技術に関するコンテンツが主となりますが、フロントエンドエンジニアを対象にしたバックエンドやインフラ関連のコンテンツも提供されています。

講師もカンファレスに登壇しているような人ばかりでレベルも高く、全体的にコンテンツのクオリティーも高くて、オススメのサービスです。

  • 月額: $39
  • 字幕: 英語
  • 再生速度: 0.8 ~ 2.0倍速
  • モバイルアプリ対応: 有り

egghead

スクリーンショット 2018-12-22 21.56.53.png
egghead.io

このサービスもフロントエンドエンジニアをメインターゲットとしている、フロントエンド技術に関する動画コンテンツが主コンテンツの月額サービスですが、フロントエンド以外の技術に関する動画コンテンツも配信しています。

先に紹介した「Frontend Masters」より講師のレベルにバラツキがあったり、講師に納品されたコンテンツの質をサービス運営側がレビューしていなかったり、コンテンツのフォーマットも講師によってバラバラで統一されていないので、その辺が利用していてストレスに感じるところがあります。

ただ、このサイトの特徴としては、1本1本の動画が短めで消化しやすいので、何か気になるコンテンツがあったら気軽に観るといった使い方がしやすいです。

私はこのサイトをメインの学習サービスとして利用する気にはならないですが、他のサービスに比べて更新頻度が高いため、サブの学習サービスとして利用しています。

たまに「解約しようかな」と思うことはありますが、そんな時に限って、気になるコンテンツが配信されるので、解約のタイミングを逃してしまいます。。。

  • 月額: $40
  • 字幕: 英語
  • 再生速度: 1.0倍速
  • モバイルアプリ対応: 無し

Pluralsight

スクリーンショット 2018-12-22 21.58.04.png
Pluralsight

「Pluralsight」はフロントエンドエンジニアやエンジニア全般だけをターゲットにしたサービスではなく、ITスキルに関する幅広いコンテンツを提供しているサービスで、デザイナー向けや映像クリエイター向けのコンテンツも配信されています。

プログラミングに関するコンテンツで言えば、言語はJavaScriptだけではなく、PythonやJavaなどの言語もカバーされていますし、また、アジャイル開発に関するコンテンツやプロジェクトマネージメントに関するコンテンツもカバーされています。

サービス運営側が講師から納品されるコンテンツの質をレビューしていると思われ、コンテンツの質も一定以上の期待出来ます。また、コンテンツのフォーマットにも一貫性があり、講師によって動画コンテンツの構成が大きく異なるということもありません。

金額は他のサービスと比べると低めに設定されているものの、コンテンツの量は膨大でお得感があります。また、前述の通り、質も高めです。

  • 月額: $29
  • 字幕: 英語
  • 再生速度: 0.5 ~ 2.0倍速
  • モバイルアプリ対応: 有り

Udemy

Udemy
Udemy

最後にご紹介するのは日本でも有名な「Udemy」です。

Udemyはこれまでご紹介したサービスと違って、月額サービスではなく、コンテンツを単品購入する形式のサービスですが、Udemyはキャンペーンを度々行なっており、キャンペーン期間中になると普段1万円以上の教材コンテンツも書籍くらいの金額になったりするので、そういう時に気になる教材コンテンツをちょくちょく買ってしまいます。

日本語のコンテンツは滅多に買わないので分からないですが、英語の教材コンテンツに関して言えば、ユーザーの評価が高く、購入者数も多いものであれば、コンテンツの質は高いことが多いので買って後悔することはあまりありません。

  • 単品購入: 金額はコンテンツによる
  • 字幕: 英語、自動翻訳の日本語字幕
  • 再生速度: 0.5 ~ 2.0倍速
  • モバイルアプリ対応: 有り

まとめ

比較的新しい技術となると、日本ではそれらに関する記事がポツポツと投稿されているだけで、体系だったコンテンツとして提供されていなことが多いです。そういう時に、英語圏の学習サービスで提供されている体系化されたまとまったコンテンツを利用すると、学習効率も高く、助かります。

英語の学習にもなり、一石二鳥なので、もし今回ご紹介した月額サービスの中で、利用したことがないサービスがあれば、まずはフリートライアルからお試しアレ!

番外編

今年に限らず、私がメインで利用している英語圏の動画学習サービスは以上の通りですが、他にも単発で利用したものがあるので、それらも番外編としてご紹介いたします。

Vue関連

元々、私はReactを使っていましたが、今年の7月からフリーのエンジニアとしてジョインしたモチベーションクラウドの開発プロジェクトではフロントエンドのフレームワークにVueを使っているため、上記で紹介したサービスの他にも、以下の3つのVueに特化したコースやサービスにも登録し、Vueの知見を得られるように努めました。

Advanced Vue Component Design

スクリーンショット 2018-12-23 0.17.41.png
Advanced Vue Component Design

参考になった!

Vue Mastery

スクリーンショット 2018-12-22 22.02.21.png
Vue Mastery

そこそこ得るものはあった。月額制。解約済み!

Vue School

スクリーンショット 2018-12-23 0.13.09.png
Vue School

買ったは良いが、あまり観ていない!

テスト関連

スクリーンショット 2018-12-23 0.35.41.png
Testing Javascript - Pro Testing course

「Frontend Masters」や「egghead」でもコンテンツを提供しているPaypalのKent C DoddsによるJavaScriptとReactのテストに特化したコース。

良い!

GraphQL関連

GraphQLはUdemyのコースや「Frontend Masters」で配信されているコンテンツでも学習したが、それらとは別にボリュームのある以下のコースも購入して学習しました。

スクリーンショット 2018-12-23 0.47.59.png
Fullstack Advanced React & Graph QL

CSS Grid

今年は先延ばしにしていた「CSS Grid」も以下のコースで学習しました。

スクリーンショット 2018-12-23 0.23.39.png
Grid Critters

元々、以下の「Flexbox Zombies」というFlexboxをゲーム感覚で遊びながらも、しっかりと完全に理解するというコンセプトの無料で提供されているコースを以前利用したことがあって、これが非常に良かったため、「Grid Critters」は有料でしたが課金しました!

スクリーンショット 2018-12-23 0.26.16.png
Flexbox Zombies

エンジニアリングマネージャーやVPoEの実体験を通じ痛感したことと感謝

$
0
0

こんにちわ! これは「モチベーションクラウド Advent Calendar 2018」 23日目の記事です。

はじめに

リンクアンドモチベーション社の開発に参加してまだ間もないため、過去にエンジニアリングマネージャーやVPoEをやるなかで経験した、多くの悩みや失敗、喜び、感謝を通じて学んだことを中心に書きたいと思います。

ちょうど最近他社のエンジニアリングマネージャーやCTOと以下のような点について会話することがありました。
1. エンジニアリングマネージャーの役割と誤解
2. エンジニアリングマネージャーのコミュニケーションの考え方
3. エンジニアリングマネージャーのオンボーディング
4. エンジニアチームのパフォーマンスに影響を与える要素
5. エンジニアチームの成功
6. エンジニアチームの自己評価(!=査定)
7. エンジニアリングマネージャーを面接する際の質問
など。今回は2、4を書こうと思います。(急遽投稿日が23日になったため笑)

ご支援いただいているRector社松岡さん広木さんとも今度話してみたいです! 結果をまたどこかで書きたいと思います。

注意
・スキルよりも考え方多め。
・あくまで体験して感じたことなので、学術的視点やセオリー的にはおかしなところがあるかもしれません。

エンジニアリングマネージャーのコミュニケーションの考え方

ずっと蓄積されていく資産、と捉えています。P/LとB/SでいうとB/S。一方向ではなく、双方向で初めて溜まるもの。

エンジニアリングマネージャー に限った話ではないのでは?

もちろん「エンジニアリング」マネージャーに限ったことではないと思います。エンジニアの場合、仕事の性質上、集中してまとまった時間を取れるかどうかが成果を左右する大きな変数であるため、都度打ち合わせすることよりも、Slackなどの非対面の方がやり取りが多く、手段も増え、ほか職種に比べて大変だと思います。

ですので、コミュニケーションに対して、一定の優先順位の意識がなければ、流れるばかりになってしまいます。「言いました」⇆「見ていません」という議論に発展したこともあります。

体験

お恥ずかしい話ですが、初めてマネジメントした時の自分のコミュニケーションはこんな感じでした。なんでこんなことができないのか?これをこうしろ、相手の話を遮る、など今考えると酷いもので、相手の自己効力感は下がりまくる…私のいない飲み会では悪口ばかりだったと思います笑 *10年ほど前です。
スクリーンショット 2018-12-23 23.26.39.png

そもそも変化の激しい(VUCA)の時代では事業の前提条件が刻々と移り変わります。制約が大幅に変わる可能性が高く、指示通りに頑張るだけでは必ずしも結果が出るとは限りません。もはや特定の誰かが変化をとらえてアクションを考えるのでは間に合わないほど変化する要素が増えています。だからこそ、各自が考えて行動できる自走型になる必要があるのだと思います。

言葉では自主性や自走を求めながらも、前述のようなコミュニケーションやマネジメントスタイルでは人は去るわ、みんな楽しそうでないわなど、当然の結果だったと思います。

粘り強く指導してくれた当時の社長、後輩のおかげでようやく改めることができ、以下のようなスタイルに変わって行けたと思います。結果、離職率も激減し、目標も達成する組織へと変わっていけたと思います。

スクリーンショット 2018-12-23 23.27.53.png
加えてたまたま「大量のコミュニケーションが仕事をより早く円滑に完了させている」という研究結果 (ハーバードビジネススクール Tsedal B.Neeley教授ら)というのも目に留まり、量を増やすことも合わせて、コミュニケーションを改善していきました。

コミュニケーションだけで全てがよくなるわけではないと思いますし、相手のレベルや内容によっては指示や強い命令も必要だとは思いますが、
広木さん心理的安全性ガイドライン(あるいは権威勾配に関する一考察)
にもある心理的安全性への影響は大きかったと思います。

具体的にやったこと

効果が高かったと思うことを5つ。どれも地味です。。。

アクション 補足
日報や週報へは必ずリアクション どんなに忙しくても移動時間など1日に5分、10分は取れるはずです。
1on1 重要性やノウハウはいろんなところで言われていますので割愛します。試行錯誤の中でも特に、上下だけでなく、斜めも/8割は相手に話してもらう。聞くことへのコミットメントが大事/相手のための時間と位置付けて、対象者にテーマを設定してもらうようにすること、などが気づきが多く効果的だったと思います。
態度(ex.話を聞くときはスマホやパソコンは触らない、ちゃんその人を向く(足を組んだり踏ん反り返ったりしない) 心ここにあらずの態度として伝わってしまいます。メラビアンの法則(人は非言語の要素で多くを伝えている) 
Slackなどのチャットとあらかじめの合意 極力見ます。どうしても全部は無理な場合があるので、ストックすべき情報、定例でフォローする設計を行い、これをメンバーとも合意しておくことがいいと思います。
沈黙を堪える 前述の態度にも関連しますが、当時の自分が最もできていなかったことです。沈黙が訪れると、その間に耐え切れず、自分から話を始めてしまう人がいますが、そのときはぐっとこらえてみることをお勧めします。せかすことなく相手が話し始めるのを待ってみることで、相手が自身の内側からアイデアや思いを言語化する可能性が高くなると思います。

など。

リンクアンドモチベーションの開発組織ではパートナーさん含めてコミュニケーションやフィードバックも多く、日々気づきがあります!(飲み会にもよくお誘いいただき幸いです!)

エンジニアチームのパフォーマンスに影響を与える要素

エンジニアのモチベーション、心理的安全は言うまでもありません。

そのほかには、
- 個々のスキルレベル
- アーキテクチャと組織の整合性(アーキテクチャに合わせてパフォーマンスが発揮できる組織や構成をデザイン。マイクロサービス、モノリシック)
も影響度の大きい変数だと思います。

加えて大事なのは、
意思決定の精度(事業、業務理解の促進)・・・どれだけ自分たちで正しい意思決定ができるか?
という意見が多かったです。そう思いましたし、これまで痛感してきました。

ありがちな問題

  • ほか組織やプロダクトマネージャーと社内受発注関係になりエンジニアのモチベーションダウン・・・
  • スタートアップなど少数の時は開発速度が早かったが、だんだんと遅くなってきた・・・ 開発組織のみが独立したプロセスで考えてしまい、事業組織との足並みがあわずに、結果として差し込み開発が入るなどして開発効率が低下する・・・

など体験したことがある人は多いのではないでしょうか。

スクラムやリーン、仮説・検証などのプロセスで解決することも大事だと思います。しかし、エンジニアやそのチーム自身が高い精度で意志決定できる状態になることが望ましいのではないか?と思います。

そのために必要なことは?

エンジニアがビジネス(お客様、市場、競合、自社)について深く理解することが必要だと思います。会社が置かれている状況と、その状況で成功していくための戦略を、確実に飲み込むこと。全体の目標、戦略、期待、収益、機会、脅威、どのように利益を上げているのか、もっとも大切なことは?など。

自分自身もまだまだなため、自戒9割ですが、とても大事なことだと考えています。

なぜか?

ゲームなどのtoCやエンジニアのコードが直接売上などの数字にヒットするような領域の場合はその限りではないかもしれませんが、エンジニアが技術領域だけに目を向けてしまい、(それが意図を持ってコントロールされたものでない場合、)自分が携わるビジネスに対して受け身にしかなれず、それでは多くの場合、やらされ感が積もるし、営業やコンサルなどのほか組織と受発注関係になり兼ねません。もちろん開発や運用などのスキルは広く、深いに越したことはないですが、技術を使って、ビジネスをどうドライブするか?この意識と経験値の蓄積が重要だと感じています。

そのためにはやはりビジネスの理解が欠かせません。持っている情報が同じで、価値観が揃っていればそこまで大きくずれたりもしないとも思います。ですので、継続的にコンテキストの理解を促す仕組みも必要だと思います。

具体的にやったほうがいいと思うこと

これについては銀の弾丸的なものはないと思いますし、特効薬は見つかっていません。。。営業同行することや勉強会、KPIツリーなどで同じことを見るように、など。継続的なコンテキストの共有としては、会議体の設計もとても重要だと思います。きちんと情報が流れる設計になっているか?などなど。

そのほかに、実績のある他の方から聞いて、他社や市場の理解のために、「個人の取り組み」としてこれはよかった!と教えてもらったものを1つだけ紹介いたします。

expoなどの展示会やイベントに行きまくること

とのことでした。多くの場合無料ですね。とても活きた最新の情報が学べて有意義だったとのことです。

リンクアンドモチベーションでは、このイシューに対し、オンボーディングから継続的に学ぶ仕組みがしっかりしており、学びがとても多いです。今度整理できたらどこかの機会にアウトプットしたいと思います。

最後に

このアドベントカレンダーの取り組みを通じ、パートナー様もみなさんとても積極的に書いていて驚くことばかりでとても素敵だと感じました!今後もこういったことを継続していきたいと感じました。

リンクアンドモチベーションは組織やモチベーションを大事にする強烈な文化があります。これは日々強く感じています。引き続き、より良いサービスの改善に向けて組織で一丸となっていきたいと思います。

今回は全てを書ききれていませんが、ご意見、ご感想や「うちはこうしてるよ!」みたいなコメント大歓迎です!

積極性と強い問題意識を要求する「振り返り」は、もうたくさん

$
0
0

「この人たちのために成長したい」といつも自分を駆り立ててくれる、大好きな職場のみなさんに本稿は捧げます。

IMG_2231-a8111243-04c5-47a4-b24e-f8c1be655c30.jpg

はじめに

これからの人生で、チームで「振り返り」をする可能性が1%でもある方々に本稿は贈らせていただきます。
皆さんの「振り返り」が行われる前にもう一度、読んでいただき、参考にしていただければ幸いです。

 「振り返り」への違和感

「積極性」と「強い問題意識」を持ったメンバーがいることを前提とした方法論ばかりが叫ばれることに私は強い違和感を感じています。

その目的や背景は置いといて、「過去に起きた出来事をチームメンバーと共に目を向ける過程全般」を本稿では「振り返り」と呼びます。
業務改善、PDCA、KPT、スクラムのレトロスペクティブ、といった過程の一部に含まれており、「振り返り」は広く知られた活動と言えます。

しかし、これらの内容は、

  • 「問題があれば主張し、必ず、議題にあげる」という個人主義的な文化圏にメンバー全員がいる前提である
  • 「1人の優秀な人間が推進し改革する」というコンサルテイスト(BP改善)

といった内容が見受けられ、そのまま実行すれば、成功が保証されるような代物ではないように思われます。

なぜなら、次のような状況にチームが立ち向かう必要があるからです。

  • 本音を話すことができないメンバーがもちろんいるので、すべての問題が机に並ばないことがある
  • 無関心なメンバーがいる場合、チームの活動として継続しにくい
  • 課題の捉え方やその温度感が揃わず、チーム全体がなかなかうまくまとまらない

こうして考えてみると、現実の「振り返り」の場には、様々なメンバーがいて、「やる気があり問題をどんどん挙げてくれる」メンバーだけではないことがわかります。

20181225_チームの血肉となる振り返りの方法.001.png

実際に、振り返りを始めたばかりの頃など、「消極的なメンバーが7割で、積極的だけど課題感がずれているメンバー2割」というような状況はよくあるのではないでしょうか。

自分の意見を外に出すのが苦手なメンバーを軽視した方法や全員が最初からやる気がある前提のプロセスをいきなり導入しても、必ずボロが出ていずれ崩壊します。

一般的な「振り返り」の方法論は、メンバーが積極的に参加してくれて問題意識を強く持っている夢のような状態でのみ成立するものばかりで、私自身、現実とのギャップに苦しみました。

20181225_チームの血肉となる振り返りの方法.001.png

では、どのようにしてこの状況を乗り越えればよいのでしょうか?

「振り返り」の共感度が高いチーム

「振り返り」の質をあげるプロセスをつくる前に、「振り返り」の共感度が高いチームをつくる

この1年間、10数個のチームを隣でみてきて出した私なりの答えです。
そして、チームの成否を分けた要素であったとも思っています。

「振り返り」の共感度が高いチームとは、「メンバーが課題に対して自分の仮説を常に持ち(積極性)、問題意識の方向や温度感が揃っている(問題意識あり)」ようなチームです。

20181225_チームの血肉となる振り返りの方法.002.png

このためには、できるだけ多くのメンバーを「積極的」×「問題意識あり」の領域に引き込むことが大切です。

本稿では、このような状況をつくるための方法を、
1.「積極的」の領域に引き込む
2.「問題意識あり」の領域に引き込む
という2つの切り口から紹介します。

自分は「振り返り」の資格をもった専門家でもなければ、「振り返り」を1万時間以上やりこんだプロでもありません。

この1年間私たちが行なってきた事例をもとにした、1つの分析結果として参考にしていただけますと幸いです。

1.「積極的」の領域に引き込む

「振り返り」に対して消極的なメンバーを減らし、積極的なメンバーを増やすために実践したことをまずは紹介します。
20181225_チームの血肉となる振り返りの方法.003.png

この上で、消極的なメンバーの心理を分析します。

A. 心理的安全性がない
問題意識は持っているがそれを正直に伝えられない、本音を妨げている要因がある状態。

B. 無関心
問題意識を特に感じておらず、振り返りの価値やおもしろさも知らない状態

それぞれ2つの領域に分かれ、その対応方針も異なります。

A.「心理的安全性がない」を変える

 「心理的安全性がない」=「消極的」×「問題意識あり」

20181225_チームの血肉となる振り返りの方法.004.png

心理的安全性について深く知るために、心理的安全性ガイドライン(あるいは権威勾配に関する一考察) をぜひご一読ください。

「心理的安全性がない」メンバーを変えるためには、正直な気持ちを伝えることを阻害する要因を見つけ取り除いでいきましょう。

しかし、消極的なメンバーが阻害要因を自発的に教えてくれるケースは稀です。
そのため、阻害要因を顕在化するための工夫を私たちはチームで施しました。

「机の上に問題があげられたならば、99%は解決できる」という言葉を聞いたことがありますでしょうか?
私たちも、阻害要因が顕在化してしまえば、そのあとの対策は「対話を重ねて認識や期待を合わせていく」という手段を愚直に実行していき内容としてはシンプルなものが多かったです。

そのため、本稿では阻害要因を発見するために実践した方法に絞って紹介します。
状況の緊急性に応じて次の2つを使い分けました。

【劇薬】本音を言う会
ベテランやマネージャーに席を外してもらうことで、一時的に、心理的安全性が高い状態をつくり、まとめて阻害要因を洗い出す方法。精神的にかなりの労力となるので、ここぞという時に使う。
【持薬】人間関係の行間を読む
「振り返り」で出た発言や行動からメンバーの本音を察する方法。洞察の深さと継続的な観察の原動力となる他人への関心が求められる。

【劇薬】:本音を言う会

ベテランやマネージャーに席を外してもらい、一時的に、心理的安全性が高い状態をつくったあとで、メンバーに本音を打ち明けてもらう方法です。

手順
1. メンバーが本音を打ち明けにくいベテランやマネージャーといった方々に、部屋から一度退出してもらう
2. 各メンバーが匿名で本音を付箋に書き出す(もちろん、合意を取った上で)
3. 本音が書き出されたら、再度、ベテランやマネージャーといった方々に入室してもらい、挙げられた付箋を1つ1つ読み込んでもらう
4. その都度、メンバーとベテランやマネージャー陣、両者の本音を聞いていき、期待や認識を合わせていく

image.png

私自身、1年間でこの会に2回参加しました。不満や要望がわかるので解決の糸口はもちろん見つかります。
しかし、それ以上に、仕事への想いや過去の経験、将来の夢に話が発展することが多く、仕事の関係を超えて、1人の人間として「何を思っているか?」を知れるような機会に2回ともなりました。
また、誰からのサポートも受けることができずメンバーからの過度な要求をこらえていた「マネージャーの孤独」をメンバーが知る機会にもなり、よりチームが一体になれた瞬間でもありました。

【持薬】:人間関係の行間を読む

消極的なメンバーの発言や行動を観察することで、本音を打ち明けるのを阻害する要因を発見する方法です。
方法自体はとてもシンプルです。
しかし、阻害要因を見極める「深い洞察力」と、普段からメンバーを観察をし続ける「継続力(人への関心)」がなければ、なかなか実現しません。

image.png

私たちの現場でも次のようなエピソードがありました。

あるメンバーのパフォーマンスが明らかに悪いものの、その原因が誰にもわからないという状況がありました。
いろんなメンバーが質問を通して深掘りをしたものの、原因が謎のままに終わり停滞感が漂いはじめていました。
しかし、山下というメンバーが、「会社の先輩でもある、チームのリーダーが怖くて、アラートを正しく伝えられなかった」様子をみていて、「無茶なタスク量をこなしていたのでは?」という仮説を持ち出しました。
山下が、「こういう立場だと、よくある」と伝えると、あるメンバーは
「いくら、無理だと言っても、常に工夫することはできないのか?という押し問答を受けて辛かった」
「実は、ずっと、ぎくしゃくした関係だった」
という本音を明らかにしてくれました。(そのあと、定期的に1on1を開き、正直な気持ちを聞く場が設けられました)

このときは山下の経験則や観察力を頼りに、阻害要因を探しました。
しかし、いまなら、先日投稿された心理的安全性ガイドライン(あるいは権威勾配に関する一考察)という記事の権威勾配を構成する変数にまとまっている観点を頼りにより早く・正確に発見ができるでしょう。

権威勾配を構成する変数

「チームメンバーの人間関係」と「上図の各要素」を一問一答形式で照らし合わせていく「阻害要因ドリル」をつくるなど、今後は様々な方法を試していきたいです。

B. 「無関心」を変える

 「無関心」=「消極的」×「問題意識なし」
20181225_チームの血肉となる振り返りの方法.005.png

「振り返りの意義がわからないし、問題意識も特にない」という、いわば、「無関心」なメンバーを「積極的」に変える方法には、2つの切り口があります。

【論理で動いてもらう】
「振り返りは価値がある」と理解してもらい、メンバーがひとりでに行動が変えていく方法
【感情で動いてもらう】
「振り返りはおもしろそう」と感じてもらい、周りに巻き込まれながら行動が変わっていく方法

【論理で動いてもらう】

「振り返りは価値がある」と理解してもらうためには、「振り返り」によって起きる変化を観測して、その効果を理解してもらう必要があります。
「定量」・「定性」の観点で、実践した2つの方法を紹介します。

 定量:フォーカスサーベイで、改善を数値化

前回までの「振り返り」で決めたアクションプラン(Try)の効果を、モチベーションクラウドを使って数値化しました。
目に見える形で、振り返りの価値を伝えて理解してもらおうとした試みです。

image.png

定量観測の対象は、1週間前に決めたアクションプランだけでなく、これまで決めたすべてのアクションプランです。
これによって、1度決めた過去のアクションプランたちがちゃんと継続されているか?といったことが、現場の満足度を通じて把握できます。

image.png

振り返りの効果を伝えるために、あらゆるデータを可視化しました。
「1週間で対応するタスクの重さ」をStorypointにて、また、「1週間に使った労力」を作業時間にて測り、さらに、計画時点での予定とスプリント終了時点での実績をそれぞれに出すようにしていました。
しかし、フォーカスサーベイの結果ほど、チームの変化を実感できる指標はなく、「振り返り」の価値を伝える上では1番の方法だと気づきました。

実際に運用していく上で、「期待度が下がり、満足度が上がった」という状態に直面しました。
このときは既存の改善活動には満足していてお腹いっぱい、次のアクションに移ってもよいGOサインが出たチームで出た状態とみんなで結論づけたのですが、おもしろい洞察として記憶に残っています。

 定性:「習慣化」した行動を見える化する

KPTのKeepでチーム内で数週間続いていた行動を意識的に取り上げて、「習慣化」というタグをつけました。
振り返りで決めたアクションがチームに根付いていることを見える化して、振り返りの価値を理解してもらおうとした試みです。

image.png
「振り返り」のあとに、チームに定着した価値観や行動は無意識に溶け込みます。
1度、これらが当たり前として定着してしまうと、改めて、言語化するのはしつこいと思われるかもしれません。
しかし、振り返りがチームに良い変化をもたらしたことをメンバーに理解してもらうために、泥臭いですがみんなで伝えあることを意識しました。

私たちの現場ではできなかったですが、1週間前のKeepと今週のKeepを見比べていく方法も、「廃れたKeep」や「無意識層に潜り込んだKeep」がわかって面白いかもしれません。

【感情で動いてもらう】

もちろん、論理で人を動かすことができれば良いです。

しかし、チームが劇的に変わった成功体験がない限り、論理で説得はできても納得を生み出すのは難しかったりします。
また、頭よりも心で判断するようなメンバーもいる(特にものづくりをする職場では)ことでしょう。

そのような状況で、メンバーの積極性を促すためには、ムーブメントを興すということを実践しました。
「言語領域」・「非言語領域」の2つの切り口で紹介します。

言語領域:失敗の標語化

チームで起きた成功体験や失敗を共通言語にして、わいわい楽しく使う試みです。端からみて「なんだか楽しそう」という雰囲気をつくるだけでなく、チームが気をつけるべき事柄が一気に広まる効果もありました。以下がその一例です。

image.png

言語領域:名言の実況

チームで「振り返り」をしたあとに、その内容を第3者に共有してフィードバックをいただく機会が定例で設けられていたのですが、そこで出たキーワードをslackに投稿する試みです。目的は失敗の標語化に近いです。

image.png

定例に参加していないメンバーからすると、作業中に突然、名言風の投稿が流れてくるわけです。ここで「何があった?」と興味を持ち、詳細を聞きにくるメンバーやこのフィードバックの時間にぜひ参加したいと志願するメンバーも出てきました。

image.png

非言語領域:聞き手が盛り上げる

盛り上げの責任を、話し手でなく聞き手が持つことです。
「振り返り」だけでなく、チーム活動自体が「なんだか楽しい」と思ってもらえるようにするために行う工夫なのですが、ガヤと呼ばれる行為に近いかもしれません。
チーム全体の熱量が高く、あの渦に巻き込まれてみたいとメンバーに思ってもらうことを目指します。

そのためには、膝に手を当てて静かに話を聞く文化ではなく、聞き手が話し始めても問題ない空気をつくっていきましょう。。

image.png

私たちの現場でも次のようなエピソードがありました。

「アイスブレークマン」と後に呼ばれる男がいて、チーム活動を毎回、盛り上げてくれていました。
しかし、冷静に彼の話を思い出してみると、特段おもしろいわけでもなくどちらかというと小話に近いものが多かった気がします。
そんな彼が場を盛り上げることに成功していた理由は、彼の「場をなんとか盛り上げようとする」勇姿にメンバーの心が動かされて、「よっ!」「おおお!」「出た!」というような応援に近い合いの手が生まれていたからでした。
彼のアイスブレークは、ライブ会場のパフォーマーとそれを応援するファンたちのような関係をメンバー間に生み出したのです。
ここから話し手だけでなく、聞き手こそが盛り上げ役としての役割を果たす大切さを学びました。

2.「問題意識あり」の領域に引き込む

「問題意識なし」というメンバーを減らし、「問題意識あり」というメンバーを増やすための方法を紹介します。

20181225_チームの血肉となる振り返りの方法.005.png

このためには、チーム内で意識すべき問題を揃えて、その温度感を徐々に高めていく必要があります。
その上で私たちは次のようなことを実行しました。

・向き合う対象は「過去」でなく「未来」
・進捗の副詞に気をつける
・発言と言動を切り分ける

しかし、こちらはまとめる時間がなかったため、割愛させてください。
内容としては、私の尊敬する偉大なチームリーダー、キタさんやなさんの記事に書かれていることでもありますので、そちらを参考にしていただければ幸いです。

スクラムマスターを経験して味わった成功体験と失敗体験

スクラム未経験者がチームメンバーと共に暗黒の時代を抜けて、エンゲージメント・レーティングをAAまであげた1年を振り返る

 おわりに

本記事は、モチベーションクラウドアドベントカレンダーGoodpatch UI Design Advent Calendarの24日目の記事です。
チームで新しい取り組みを行うとき、そこには必ず、「人」がいます。
「人」の感情を無視して手法やプロセスを組み込むのではなく、その多様性を尊重・感謝する。
私自身、これを忘れずにいたいと思います。

プログラミング経験ゼロから、自社プロダクトの開発に参画することになったのでやったこと

$
0
0

はじめに

この記事は、「モチベーションクラウド Advent Calendar 2018」25日目の記事となります。

モチベーションクラウド開発に新卒2年目からジョインすることになった@shioura_yuuyaです。
モチベーションクラウドアドベントカレンダーの最終日を担当させて頂きます。

モチベーションクラウドの開発現場はハイレベルなベテランエンジニアの方々ばかりなので、配属に先立ち私はまず七ヶ月に渡るプログラミング研修を受けました。
基礎から実践で使える技術までじっくりと学んだ上で、現在は現場でエンジニアとして働いています。

この記事では、私がプログラミングを習得するためにどのような学習をしたのか、細かい内容より学習姿勢的な部分にスポットをあてて、効果的に感じたものを3つご紹介したいと思います。

  1. ドリルをやらなきゃ九九は覚えない
  2. それ本当?の精神
  3. ドキュメント化は未来への投資

プログラミング学習を始めたばかりの新人の方、あるいはそんな新人をレクチャーする立場の方に参考になるものとなれば幸いです。

ドリルをやらなきゃ九九は覚えない

研修では一部分に絞った技術要素を重点的に学ぶことで、継続的・自主的に学習して成長していける状態になることがGOALでした。
とはいえ、学ぶべき技術要素は鬼たくさんありました。
(Ruby、Rails、コマンド操作、Git、SQLなどなど)

最初はとにかく参考書を読みました。が、読むだけでは問題がありました。

読んだだけでは実践できない

具体的には、、、

  • プログラミング言語の参考書は読んだが、いざプログラミング問題を解こうとすると書けない
  • 参考書のどこに何が書いてあるかも思い出せず索引できない
  • コマンド操作の本は読んだがどんな時に使うものなのか分からない

といった事態が発生しました。私は、実は何も習得できていないのに、本を読むことで「勉強したつもり」の状態になっていたのです。
その状況を打破するために行ったことが、手を動かすことでした。

手を動かしながら参考書を読む

参考書を黙読するだけではダメで、とにかく手を動かしました。

  • irbを使って参考書に出てくるRubyのプログラムを実際に動かしてみる
  • Gitは実際にGitHubのリポジトリとか作ってpushしてみる
  • SQLもターミナル上で全て実行する

上記のようなことをめんどくさがらず徹底的に実践していくことで、学習内容の習得度合いは格段に上昇しました。
たとえば小学生の頃に九九を覚えるためにガリガリとドリルを解いたことと同じで、プログラミングにおいて「手を動かす」ことは非常に重要なファクターであると感じました。

それ本当?の精神

詰まったことや分からないことがあった時、ちょっとGoogleで検索すれば公式サイトやQiitaや個人のブログやらさまざまな情報を手に入れることができます。
情報収集をするときには、必ずその情報が「本当に正しいか」の検証を行いました。
これには二つの理由があります。

  1. 間違った知識を習得してしまう可能性がある
  2. 情報が正しいか検証する力はエンジニアにとって必須の能力となる

間違った知識を習得してしまう

これは、そのままの意味です。
ネット上で得ることができる情報は有象無象。個人サイトはもちろん、企業のブログであってもちょっと間違ったことが書いてあることは十分ありえます。
当然ですが、一次情報をたどることを大切にしました。

上記のようなことを行うことで「本当に正しいか」確認していました。
逆に、個人のブログなどでも公式の参照が記載されているものは、信用ができそうだな、という指標にもしていました。

情報が正しいか検証する力

最初は正しい情報を収集するために始めたことですが、正しいか検証するという作業はそれ自体エンジニアとしての資質になりうることを感じます。

(例)git resetのオプションによる挙動の違い

研修の中でgit resetの各オプション(--hard HEAD~--mixied HEAD~--soft HEAD~
)の違いを説明し、それを証明することを求められた時がありました。
この時私は次の3つのことを行いました。

  • Pro Gitを読んで、大枠の挙動を理解する
  • git help resetでマニュアルを開きPro Gitの説明が正しいか確認する
  • 意図した通り動いているか手を動かして(実際にgit resetを行って)確認する

このような「仮説」と「検証」は、現場に出た今でも日常的に行う仕事であり、プログラミング学習初期段階で癖をつけておくことは非常に有意義なものであると感じています。

少なくともテキストを丸暗記するより、ずっと実効性があると思います。

ドキュメント化は未来への投資

研修中に学んだことは、なるべくドキュメント化してGitHubのWikiに溜めるようにしていました。
正直最初はいちいちドキュメントを書くことにめんどくささを覚えていました。まとめている時間はインプットも止まるので、効率悪い気もして。
しかし結論、このドキュメント化する作業が知識の定着という意味で非常に効果的であると感じました。

知識の体系化

学んだことをドキュメント化することは、知識を体系化する作業です。学んだことを関連付けたり、構造的に整理したりしながら、まとめていくことが求められるからです(特にGitHubのWikiはMarkdownで書くため、普通の文書よりドキュメントの構造を意識できる気がする)。
体系化することで、知識の習熟度が上がる実感があります。
記憶には「エピソード記憶」と「意味記憶」がありますが、テキストなどで学ぶような意味記憶は体系化して関連づけることによって思い出しやすくなるという研究もあるそうです。
image.png
http://www.ipc.hokusei.ac.jp/~z00105/_kamoku/kiso/2002/itou.htm)
知識の定着が進むことで、結果的に学習効率も向上したように感じます。

ナレッジの蓄積

また、Wikiに溜めていったことはやがてナレッジとして未来の自分や、所属する組織全体にとっても貴重な資産となります。

まとめ

私が初学者として実際にやってみて効果的に感じた学習手法を3つ紹介しました。

  1. ドリルをやらなきゃ九九は覚えない
  2. それ本当?の精神
  3. ドキュメント化は未来への投資

いずれも現場で活躍するエンジニアであれば空気を吸うようにやっていることかもしれません。
しかし、プログラミング初学者にとっては必ずしもそうではありません。

  • 「技術書読んだだけで勉強した気になってしまう」という気のせい
  • 「ブログに書いてあったら検討せず信じちゃう」という思考の甘さ
  • 「ドキュメント書くより勉強進めたい」という短期視点

などなど課題も多く、相応の「訓練」を経て習得できた(今もしている)ものであったと思います。
プログラミング初学の時点で習慣化するくらい体に染み込ませたことで、スムーズに現場の業務に入ることができたと感じています!

おわりに

モチベーションクラウド Advent Calendar 2018は本記事を持ってゴールとなります。

モチベーションクラウドは「One for all, All for one」を実現する企業(組織)を増やしていくという思いが込められたプロダクトです。そのようなプロダクトを作っている開発チームの一員としては、自分たち自身が世界中でもっとも「One for all, All for one」な開発組織でありたいと思っています。
だからこそ、開発メンバーで一丸となって取り組み、無事最後まで走りきれた今回の企画は(私がゴールテープを切るのは恐縮ですが)、「One for all, All for one」の1つの形のように思えて、とても嬉しい気持ちです!

それではみなさん、メリークリスマス!

Viewing all 25 articles
Browse latest View live