株式会社クイックのWebサービス開発blog

HAPPYなサービスプランナー・エンジニア・デザイナーのブログです。

GASを使って、ChatworkにGoogle Analyticsのレポートを送信する

はじめてGASに挑戦したsatopiです、こんにちは!

自分が運用に関わっているDybe!というメディアサイトの記事を社内のみんなに見てほしくて、Chatworkのbotに月間PVランキングをつぶやかせるようにしました。

1. スプレッドシートGoogle Analyticsアドオンでレポートを作成する

スプレッドシートを作成するアカウントにGoogle Analyticsの「表示と分析」権限を付与しないとレポートは作成できません。

f:id:aimstogeek:20190416164703j:plain
Google Analyticsアドオン

Google Analyticsアドオンをインストールしたら、アドオンメニューから「Create new report」をクリック。

f:id:aimstogeek:20190416165848p:plain

レポート出力設定ウィンドウが表示されます。

f:id:aimstogeek:20190416165212p:plain

Metrics(指標)に「Pageviews」、Dimensions(分析軸)に「Page Title」「Page」を指定します。 (Pageはページのルート相対パスが取得できます)

2. 出力される内容を調整する

  1. Orderで降順にするため、-ga:pageviews を指定
  2. Filterで記事詳細のみに絞り込む

Dybe!の記事URLは、 https://ten-navi.com/dybe/記事ID/ となっているので、正規表現で絞り込みます。

f:id:aimstogeek:20190416165708p:plain
出力内容を調整したReport Configurationシート

アドオンメニューから「Run Reports」をクリックすると、別シートに結果が出力されます。

f:id:aimstogeek:20190417151503p:plain
結果が出力されたシート

3. 毎月1日にレポートを更新する

アドオンメニューから「Schedule reports」をクリックし、実施日時を設定します。

f:id:aimstogeek:20190416184041p:plain
毎月1日、9〜10時の間に実施させる設定例

4. GASにChatworkのライブラリを追加する

スプレッドシートからスクリプトエディタを開き、「ChatWorkClient」のライブラリを追加します。

f:id:aimstogeek:20190416182813p:plain
追加したら、最新バージョンの選択を忘れないようにしましょう

5. GASを書く

スクリプトはこんな感じに。

function sampleAction() {
  var currentFile = SpreadsheetApp.getActiveSpreadsheet();
  // シート名は「Run report」で生成されたほうを指定する
  var monthlyRanking = currentFile.getSheetByName("シート名");

  // チャットワークにメッセージを送る
  var RoomId = xxxxxxxxx; // ChatworkのルームID
  var client = ChatWorkClient.factory({
    token: "ChatworkのAPIトークン"
  });
  var Body = "[info][title]Dybe! 月間PVランキング[/title]";

  for (var i = 1; i <= 6; i++) {
    Body =
      Body +
      "[" + i + "] " + monthlyRanking.getRange(i + 15, 2).getValue() +
      ":PV " + monthlyRanking.getRange(i + 15, 3).getValue() + "\n" +
      " https://ten-navi.com" + monthlyRanking.getRange(i + 15, 1).getValue() +
      "[hr]";
  }

  Body += "ご意見・ご感想などがあれば、Dybe!運営メンバーまでお願いします(bow)[/info]";

  client.sendMessage({
    room_id: RoomId,
    body: Body
  });
}

スクリプトを書いたらメニューのトリガーアイコンをクリック。

イベントのソース「時間主導型」を選択し、実行日時を設定します。

f:id:aimstogeek:20190416190211p:plain
毎月1日 午前10〜11時の間に実行するようにトリガーを設定した例

※レポートの更新後にスクリプトが実施されるようにしてください。

完成

f:id:aimstogeek:20190416162721p:plain
Dybe!の月間PVランキングをつぶやく社内botのBob

まだDybe!の記事を読んだことがない方は、これを機に是非ご覧ください!٩( ᐛ )و

ten-navi.com


\\『明日のはたらくを創る』仲間を募集中です!! //
919.jp

merge commitのrevert commitをrevertしてたけど気持ち悪いからやめました。

こんにちは。mikkiです。
今回はGit運用でずっと気持ち悪いと思っていた、revertのrevertをやめる方法を見つけたので、こちらに記載したいと思います。
(もしかしたらこんなことしてたの私だけかもしれない。。。)

Gitの説明は省くので、勉強されたい方は詳しく説明の載っている外部サイトをご覧ください。
サルでもわかるGit入門 〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】



どんな時にrevertのrevertをしていたのか

developブランチから複数のfeatureを切り、developにmergeし動作確認を行っているとします。 追い越しリリースやバグが見つかった場合、対象featureブランチのmergeコミットをなかったことにしたいのでrevertします。 リリースが終わった後developに対象featureブランチのmergeコミットを復活させたいので、ここでもう一度revertをしていました。
これが今回やめようと思ったrevertのrevertです。

f:id:aimstogeek:20190411191632p:plain
revert commitのrevertをしている図

revertのrevertをしなくてもfeatureブランチをmergeしなおせばいいのでは、と考えたこともありました。 ですがdevelopブランチでは打ち消しコミットが入っているので、featureブランチを再度mergeしようとするとconflictしちゃうんです。 あるいはmerge時点より前のcommitがなかったことになってしまいます。
そのため、気持ち悪いけどrevertのrevertを行っていました。

f:id:aimstogeek:20190411190544p:plain
revert commitが有効な状態を示す図

今までrevertすることがほぼなかったので我慢していましたが、必要になると管理が大変なことに気がつきました。 それにバグが含まれていることが理由でrevertした場合、もう一度revertしてdevelopにバグを混入するのって気持ち悪いですよね?
運用を変更したい理由が二つも思い浮かんだら、変える他ないと思い、revertをrevertせずにmergeコミットの復活方法がないか検証しました。

revertのrevertをせずに修正を加える方法

結論から言うとcherry-pickを使います。

cherry-pick自体の説明は冒頭でご紹介したサイトをご覧ください。
4. cherry-pick【チュートリアル3 コミットを書き換えよう!】 | サルでもわかるGit入門【プロジェクト管理ツールBacklog】

手順

  1. developからmergeコミットをrevert
  2. 最新のdevelopをfeatureに取り込む
  3. featureの戻したい時点のコミットをcherry-pickする
  4. 修正したい場合はここで修正を加える
  5. マジリク投げる
  6. mergeする

f:id:aimstogeek:20190411191417p:plain
渾身のcherry-pick

これでrevertのrevertをすることなく、綺麗に修正を加えることができました!!!

最後に

実は今回、クイックのスクラムマスターことフルーツパーラーさんに相談して手順を確立しました。
チャットで相談したところ「えぇ⤴︎なんすか!なんすか!」と面白そうに、一緒になって事象の検証から手順の確立まで行ってくださいました!
別プロジェクトで忙しいのに、ラフに相談に乗ってくださるフルーツパーラーさんはじめみんなにいつも助けられてます。感謝感謝です。

最後までこの記事を読んでくださった画面の前のあなた!ありがとうございます。
他の手段やもっといいアイディアがあれば、ぜひコメントください。お待ちしております。


\\『明日のはたらくを創る』仲間を募集中です!! // 919.jp

新米スクラムマスターに届け!今だから伝えられる7つの事

4月いい季節ですよね。
何かを始めようと思い筋トレを掲げるのですが、
何故か身体の変化はありません。フルーツパーラーです。

スクラムを実践し学ぶ中で、新たな気付きや考える事が多々ありました。

本記事は、新米スクラムマスター(過去の自分)に対しての内容です。
スクラムマスターに向けた資料は少なく、悩まれている方の参考になれば幸いです。

弊社のスクラム開発についてはこちら

aimstogeek.hatenablog.com

お話の対象としている方

スクラムマスターをしている(新米)
スクラムを学んでいる

スクラムマスターとは?

一言で言うと
(対象者の)目的を達成する確率を最大化する

スライドの目次

気になる内容がありましたら是非内容を御覧ください。 スライドの最後にスクラムマスターに必要なスキルと学ぶ領域についても記載しています。

1. スクラムが課題を解決すると思わない
2. スクラムが出来ていると思わない
3. イベントをスキップしない
4. なぜスクラムを行っているか忘れない
5. スクラムを変えようと考えない
6. 自分自身の改善を忘れない
7. スクラムマスターがフィードバックを受ける事はない

スライドの紹介

speakerdeck.com

参考:改善を繰り返す進め方について

もしイメージがつかない方は是非こちらをご覧下さい。 www.ted.com

まとめ

実践を始めた頃は何に向かって進めばよいのか、どういうスキルが必要になるのか?出来ているのか?という悩みを持ち続けていました。

これから実践する方の入り口の一つとして見ていただけると嬉しいです。

必要なスキルはとても高く不足している部分が多いです。 しかし、すでに高いレベルでスキルを持った方々が組織内にいますので、アドバイスを頂きながらスキルを身につけて行こうと思います。

弊社では、チームを盛り上げ『明日のはたらくを創る』仲間を募集しています。



\\『明日のはたらくを創る』仲間を募集中です!! // 919.jp

カウント厨が打ち合わせ中に話した文字数から、課題意識が生まれやすい理由について考えてみた

こんにちは。サービスプランナーのZAWAです。
業務においてはサービスに関する企画と設計、そしてプロダクト開発工程の上流と言われる箇所(要件定義や設計の一部)を主に担当しています。

突然ですが「仕事」というものは時に、「誰も答えがわからなくても突き進まなければいけないもの」ですよね。

年に数回、異なる方々から言われることがあります。
『打ち合わせをもっと効果的に、無駄なくやるにはどうしたら良いか?』

今回はその課題意識が生まれやすい理由について、
数値で表しやすい部分にフォーカスし、『文字数と消化時間』の観点から考えてみようと思います。
f:id:aimstogeek:20190327231320p:plain:w150


先の方々に『なぜ打ち合わせを改善したいのか』尋ねたところ、以下の答えが返ってきました。
議事録読んだ方が効率的だから
進行のテンポが悪いから
単純に時間が長かったから など

これらの意見を参考に、1時間の『打ち合わせ』で話した文字数から、
その文字数を話すとしたら何分かかるか、また読むなら何分かかるかを割り出してみたいと思います。

なお、本記事は『打ち合わせ』の全体について論じたものではありません。
あくまで文字数と消化時間という一面を切り口としたもので、以下の要素については別の機会で熱く語らせてください。
・『打ち合わせ』に適した内容、適さない内容
・『打ち合わせ』の種類に応じた最適人数
・種類に応じた適切なやり方
・よくある失敗例と対策成功例
・対面コミュニケーションの重要性 ・参加者側に必要なこと

目次

1. 前提の確認

2. 検証

3. 仮説

4. 最後に

1. 前提の確認

1分間で無理なく話せる文字数

今回は300文字を採用します。本題ではないためこの妥当性はここでは検証しません。

1分間で無理なく読める文字数

個人差がありますが、日本人の可読可能文字数と言われている400~600文字を参考にしました。
今回は【1分間で無理なく話せる文字数】と比較しやすい600文字を採用します。

2. 検証

a.1時間の打ち合わせを文字にしてみた

とある打ち合わせにて、全力で皆の発言を書き取ったところ、4,340文字でした。
繰り返し説明している箇所もあるため、実質的な情報密度はもっと薄いです。

b.4,340文字を話すのに必要な時間

4,340÷300=約14分

c.4,340文字を黙読するのに必要な時間

4,340÷600=約7分

3. 仮説

得られた情報から「打ち合わせを改善したい」と思い至る背景として、3つの仮説を立てました。

ⅰ.議事録を読む方が効率的だと感じたから

打ち合わせによっては、議事録を読めば十分なこともあるかと思います。
その場合1時間と【2. 検証c:約7分】を脳内で比較し、改善へと進むことが推測できます。

ⅱ.進行のテンポが悪いと感じたから

【2. 検証a】事例の打ち合わせでは、1分以上沈黙が続くことはありませんでした。
それでも4,340文字です。
『テンポが良い』の最上級を、『どもらず、黙らず、重複せず誰かが話し続けた』と仮定すると、300文字×60分=18,000文字程度の価値となります。
比較して非効率と感じ、改善へと進むこともあるでしょう。

ⅲ.スケジュールがパツパツ(時間が取られすぎ)たから

『打ち合わせに適している議題』、また『議題によって適している人数や時間』はあると思います。
4,340文字使って共有するべき内容でなかったなど、それぞれで適切な選択がされていない場合、改善へと思い至ることが推測できます。

4. 最後に

少し検証してみた結果、『打ち合わせ』とは『非常に難しいモノ』と再認識しました。
最終的にその打ち合わせで何を得たいのか、「仕事」は「段取り」とはよく言ったものだなぁとつくづく感じております。

また本記事は『打ち合わせ』が無意味だと主張するものではなく、気持ちとしてはむしろその逆です。
もちろん改善すべきポイントは常にあると思いますので、具体化して検討する一例になればと思っています。
気持ちとしては、本記事を読まれたことをきっかけに、『打ち合わせ』のあるべき姿や考慮すべき点など周囲の方と議論に発展されたりしたら……嬉しいことこの上ないです。

株式会社クイックは様々な観点から「仕事とは何か」を突き詰められる職場です。



\\『明日のはたらくを創る』仲間を募集中です!! // 919.jp

【AWS Health】AWSのメンテナンス情報を取得してChatworkへ通知するスクリプトを作った

こんにちは。クイックSREチームのみっちーです。

先日、「AWSからのメンテナンスメールを見落としていて、知らぬ間にEC2が再起動」なんてことがありました。
ログ見ても原因不明。結局メンテナンスというオチで、工数返せよ!って気分になりました。(みなさんもそんな経験ありませんか?)

ということで、反省も踏まえて
AWSのメンテナンス情報を取得してChatworkへ通知するスクリプトを作った」
のでご紹介します✧(・ㅂ・)و

目次

1. 概要と背景

2. スクリプトの設計

3. スクリプトの実装

1. 概要と背景

概要

このスクリプトは、APIAWS コマンドラインインターフェイス) を利用して、「AWS Health」サービスへ情報を取得。
その結果をChatworkへ通知するシェルスクリプトを作成し、cronで1日1回動かすものです。

AWS Health」とは

AWS Health」は、ログインアカウント上で利用できる全サービスについて、以下の情報を提供するサービスです。

  • 再起動を伴うメンテナンススケジュール
  • issues

背景

これまでは、利用しているAWSサービスの全メンテナンス情報をメールで受信する運用にしていました。
しかしこの運用では、以下のような課題がありました。

  • issuesを含む全メンテナンス情報が来るので、受信メール数も(当初の想定よりも)多く、内容精査が少々面倒。
  • 基本的にはissuesが大多数。そのうちにメール自体を見なくなり、再起動を伴うような肝心なメールの見落とし頻度が増加。
  • 結果として、「知らぬ間にEC2が再起動していた」ということも何度か発生。
  • 上記に付随し、「予期せぬ再起動」なのか「メンテナンスによるもの」なのかの切り分けにも工数を割かれていた。

そこで、「再起動(ユーザ影響)を伴うメンテナンス情報だけを効率よく拾いたい」と思い調査を開始しました。

2. スクリプトの設計

ほしい情報

AWS管理コンソール上で、

と進むと確認できるメンテナンス情報の中で、
「再起動(ユーザ影響)を伴うメンテナンス情報だけ」がほしい。

具体的には、
以下画像の「Affected resources」に影響があるインスタンス数が表示されており、かつ「StatusがCompleted(またはClose)になっていない」ものが今回取得したい情報です。 f:id:aimstogeek:20190313161220p:plain

設計イメージ

以下を満たすことを前提に行いました。

  • 最新のメンテナンス情報を最低でも日に1回は取りたい。
  • 将来追加されていくAWSの新サービスについても、取得項目を追加せずとも動的に追従してほしい(ツールのメンテナンスコストを極力減らす)
  • 自分達が影響を受けるものだけを抽出するようにしたい。
  • できるだけ気づきやすいところに通知するようにしたい。※弊社だとChatworkを日々の業務で使っているので、そこに通知したい。
  • Lambda等、他のAWSサービスと連携させて~というのは、(新メンバーなど)後々のメンテナンス性が良くないので、できるだけ避けたい。

3. スクリプトの実装

事前準備

ChatworkAPIの利用申請

  • APIを利用できるように事前に申請をしてください。
  • なお利用申請方法はここでは省きます✧(・ㅂ・)و

スクリプト実行サーバの構築

  • 本記事では、「Amazon Linux AMI release 2017.03」を実行環境として記載しています。
  • AWS API コール用のコマンドである「aws」が最初から使えるためです。
  • 構築方法はここでは省きます✧(・ㅂ・)و

「~/.aws/credentials」の設置

  • AWSAPIを利用するためのキーペアを設置します。
  • 作成と設置の方法はここでは省きます✧(・ㅂ・)و

ソースコード

ご注意ください

  • ソースコードの品質に関するお問い合わせには応じられません✧(・ㅂ・)و」ので、予めご了承ください。
  • 万が一、本ソースコードを利用して損害を被るような事があっても、弊社では一切保証できません。事前によく検証してからご利用下さい。
#!/bin/bash

# define local command, & dir path.
BASEDIR=$(cd $(dirname "$0") && pwd)
LOGDIR="${BASEDIR}/logs/"

# define argument.
TARGET_ACCOUNT_AWS_PROFILE=$1

# Chatwork token.
CHATWORK_TOKEN='APIトークン情報を入れてね'
CHATWORK_ROOM_ID='通知先のルームIDを入れてね'

# exec.
## check argument.
if [ $# != "1" ];then
  echo "usage: $0 <target account for ~/.aws/credentials>"
  exit 1
fi

cd ${BASEDIR}
if [ ! -d "${LOGDIR}" ];then
  mkdir -p ${LOGDIR}
fi
ARN_NAME="${LOGDIR}/${TARGET_ACCOUNT_AWS_PROFILE}.arn"
LOG_NAME="${LOGDIR}/${TARGET_ACCOUNT_AWS_PROFILE}.log"

## initialize.
echo "" > ${LOG_NAME}

aws health --profile=${TARGET_ACCOUNT_AWS_PROFILE} describe-events --region us-east-1 \
--query 'events[?eventTypeCategory == `scheduledChange` && statusCode != `closed`].arn' | grep arn | tr -d '\,' > ${ARN_NAME} 2>&1

if [ -s "${ARN_NAME}" ];then
  for EVENT_ARN in `cat ${ARN_NAME}`
  do
    aws health --profile=${TARGET_ACCOUNT_AWS_PROFILE} describe-affected-entities --region us-east-1 --filter eventArns="${EVENT_ARN}" --query 'entities[].[entityValue,eventArn]' >> ${LOG_NAME}
  done

  SEND_MESSAGES=`echo "[info][title]警告:AWSの「再起動を伴うメンテナンス情報」が更新されました@${TARGET_ACCOUNT_AWS_PROFILE}[/title]" && cat ${LOG_NAME} && echo "[/info]"`
  ## for Chatwork report. 
  curl -X POST -H "X-ChatWorkToken:${CHATWORK_TOKEN}" -d "body=${SEND_MESSAGES}" \
  "https://api.chatwork.com/v2/rooms/${CHATWORK_ROOM_ID}/messages"  1>&2
fi

exit 0

ソースコードの説明

aws health describe-events

  • ここで指定したアカウントが利用可能なサービスの、「メンテナンス情報一覧」を取得できます。

aws healthで指定する「--region」は「us-east-1」 で固定。

  • リージョンはGlobal になるので、us-east-1(Global)で固定です。これ以外を入れるとエラーが返ってきます。

https://api.chatwork.com/v2/~

  • チャットワークにメッセージをPOSTするときに指定するAPIのURLです。
  • ${CHATWORK_ROOM_ID} は、通知したいチャットワークのルームIDです。

実行イメージ

  • ここでは実行環境として、「Amazon Linux AMI release 2017.03」を使用しています。
[ec2_user@test-ec2-instance] $ cat ~/.aws/credentials
[default]
aws_access_key_id = アクセスID
aws_secret_access_key = 秘密鍵

[ec2_user@test-ec2-instance] $ ./get_aws_health.sh default

スクリプトの引数として「~/.aws/credentials」のユーザ名(ここではdefault)を指定して実行します。
すると、こんな感じにChatwork上に通知が行きます。 f:id:aimstogeek:20190313162309p:plain

通知内容は、

  • タイトルに「影響を受けるAWSアカウント名」

  • 本文に、「影響を受けるインスタンスID」「影響を受けるサービス名」、および「メンテナンススケジュールのID」

が含まれていますので、「利用サービスにおいて、再起動を伴うメンテナンスがあるかを気づく」という目的は達成できました。
ただあまり見やすくは無いと思いますので、必要に応じて適宜整形してご利用ください~。

以上で終了です。
少しでも日々の運用のお役に立てば幸いです~ではでは!



\\『明日のはたらくを創る』仲間を募集中です!! // 919.jp

組織や風土のつながる先

はじめまして!
今回はアプリケーションエンジニアのrinx2が担当させていただきます。
前回のSK1と同じく最近入社し、PHP案件を中心に開発に携わっています。

新しいメンバーからの投稿がせっかく続くので、
今回は「透明性」と「エンジニアリング組織」という点から、
クイックの組織風土についてご紹介できればと思います。

f:id:aimstogeek:20190313212257p:plain

透明性

クイックに入社して先ず驚くことは、採用時の印象と実際の環境のギャップが小さいことです。
透明性を重視し、対話に時間を惜しまない風土があるので、
数ヶ月経った今でも、事前に知り得なかったことで困ることはほとんどありません。

同じような感想をもたれているメンバーも少なくないようで、

「面接の予定時間が過ぎても、認識が合うまでとことん会話をさせてくれたことが、
クイックに決めた理由の1つです!」

と仰っている方も居ました。
私の経験ですが、このギャップが小さいことは両者の納得に大きくつながっていると思います。

エンジニアリング組織

次に、クイックに入社して魅力的に感じたことは、エンジニアリングされる組織です。
入社後、私はメンターに組織の指向性がどういったところにあるのか、改めてうかがってみました。
すると、「エンジニアリング組織論への招待」という書籍を紹介いただきました。

ものすごく要約すると、

「組織運営における障害を定義/例示し、
それらの解決方法をマネジメント手法の変遷や心理学の観点から考えていこう!」

といった内容になっており、現代組織論をまとめた書籍になります。
とても良書なので説明しきれないことが残念ですが、
この書籍を読んだことで私が感じていたクイックの印象に合点がいきました。

  • 事業方針が明確で整理されている
  • 組織論・形成に力を入れている
  • 社員が疲れていない

文章にすると至極当然とも取れるし、ちょっぴり恥ずかしかったりすることを書いているのですが、
10年ほど前から提唱される現代組織論は、旧来日本のカイゼンにならった考えが重要視されています。

クイックでは意思決定の観点や手法を筆頭に、組織のサイジングや社員の育成方針、
制度といったものに先述の指向が随所で散りばめられているように思います。
個人の成長意欲が高く、元気に働く社員が多いことは、こういった風土があるからだと思います。

こちらも説明しきれないことが残念なのですが、
変化し続けてていくであろうこの組織を、私はシンプルに楽しみに思っています。

まとめ

私はエンジニアを7年やっていますが、上記は個人的にとても大切な観点に思います。

ITエンジニアというと、なんだかスーパーマンだらけで、 何かモノが急に出てくる印象があるかも知れませんが、
実際には日々作業し、仲間達と円滑なコミュニケーションをはかって、初めて成果物へたどり着くことができます。

人との関わりが薄い業界に見えて、人との関わりを1番見直している業界だったりします。

ものすごく体系的な内容になってしまいましたがいかがでしたか?
私もこの風土に早く混じり、活躍できるよう目の前の業務に邁進していこうと思います!



\\一緒に『明日のはたらくを創る』仲間を募集中です!! // 919.jp

メンター制度とは?

はじめまして!中途入社のSK1です('ω')ノ
社内に同姓同名がいるので、名前のあとに「1」がつきました。

実は入社ホヤホヤなのですが、ブログ担当をやっちゃいます(^o^)/
入社したばかりの目線でお伝えできればと思います。

今回ご紹介するのは、数年前から私達の課でスタートしたメンター制度についてです。

ちなみに私は、クイックに入社をするまでこの制度のことを知らなかったのですが、 「メンタル面の何だろう・・・サポートかな?」
ざっくりこんな感じのイメージでした。

所説ありますが、アメリカで始まった人材育成方法の一つで、
先輩社員をメンター新入社員をメンティーと呼びます。
メンターは、メンティーが社内で活躍しやすいよう、キャリアに関するアドバイスの他、ときには仕事以外の悩みの相談にものってくれます。

私達の課では、「新入社員」に限らず中途社員にもこの制度が適用されており、
メンターとメンティーで面談をする時間を設けています。

ちなみに私のメンターは、このブログにも登場したことのあるみっちーさんです!
とってもイケメン!

イケメンメンターのご紹介ページを載せておきます・・・
ちゃっかり(^^)v www.wantedly.com

OJT」とは何が違うの?

OJT(On the Job Training)は配属された部署で、同じチームの先輩から指導を受け、
実際に仕事をしながら経験を積んでいきます。

メンター制度は、業務の指導をするわけではないので 同じチームの先輩である必要はありません。あえて少し離れたところから見守る役目を持っています。

同じチームでは、人間関係の悩みなど相談し辛い場合もありますよね。

それでは、私の課のメンターとメンティーに協力をしてもらい
両者の視点を以下にまとめましたので、お伝えできればと思います。

メンター側の視点 

【メンターを担当しようと思ったきっかけは?】

・リーダーとして、何かメンバーに良い働きかけをしたいと思った

・自分が中途入社してこんなことあったら良かったなと感じたことを、
 新しいメンバーに提供したかった

【メンターとして心がけていることは?】

・主役はメンティである

・自分ばかり話さない

・否定しない

【メンティーと話す時間はどんな時間?】

・自分が見えていない気づきを与えてくれる時間

メンティー側の視点

【面談ではどんな話をしているの?】

・質問、疑問に答えてもらう

・一週間を振り返る

・漠然と考えていたことを整理する、してもらう

・次の方向性を考える、考えてもらう

中途入社である私が「メンティー」の立場として、この制度の良さをお伝えすると
メンターとの週に一度の面談は、自分の一週間を振り返るだけでなく、
仕事の話や他愛もない話をすることで、 緊張がほぐれる時間でもありました。

新しい環境に行くことは緊張しますし、最初は覚えることも多く環境に慣れることで精一杯です。 誰かに話を聞いてもらうことで少し楽になったり、
メンターの意見を聞くことで、考えすぎていた自分に気づくこともあります。

また今回新たな発見ですが、メンティーと話すことによって
メンターへ気付きを与えてくれる場合もあるようですね!

両者にとっても非常に意義のある制度だと感じています。

まだまだ私もスタートしたばかりですので、
早くクイックの環境に慣れるよう頑張ります!
ではまた~ヾ(@^▽^@)ノ~~~~~~~~~



\\一緒に『明日のはたらくを創る』仲間を募集中です!! // 919.jp