kakakakakku blog

Weekly Tech Blog: Keep on Learning!

任意のパラメータを格納できる EC2 Systems Manager「パラメータストア」を試したら便利だった

re:Invent 2016 で発表されたけど,オンプレ関連だと勝手に思い込んでいて,今まで試していなかった Amazon EC2 Systems Manager の中に「パラメータストア」というサービスがあり,試してみたらこれが非常に便利だった.簡単に言うと,任意のパラメータをパラメータストアに格納することができて,アプリケーションと環境変数を完全に切り離すことができてしまうというもの.The Twelve-Factor App を実現できるぞ!

パラメータストアとは?

  • 任意のパラメータをパラメータストアに格納することができる
  • データタイプは3種類ある
    • String
    • String List
    • Secure String (パラメータを KMS で暗号化して格納する)
  • ._ を使うと,パラメータをグルーピングできる
  • IAM Role でアクセスできるパラメータグループを制御できる

docs.aws.amazon.com

パラメータストアに格納してみた

サンプルとして,4個のパラメータをパラメータストアに格納してみた.なお,キーと値は同じにした.

  • パラメータグループとして prdstg を用意した
  • KMS の挙動を確認するため StringSecure String を用意した

f:id:kakku22:20170610180222p:plain

パラメータストアからパラメータを取得する

aws ssm get-parameters コマンドを使うと,簡単にパラメータを取得することができる.

$ aws ssm get-parameters --name 'stg.user_id'
{
    "InvalidParameters": [],
    "Parameters": [
        {
            "Type": "String",
            "Name": "stg.user_id",
            "Value": "stg.user_id"
        }
    ]
}

Secure String の場合は,デフォルトだと KMS で暗号化された値が返ってくる(今回は例として xxxxx とした).

$ aws ssm get-parameters --name 'stg.user_pass'
{
    "InvalidParameters": [],
    "Parameters": [
        {
            "Type": "SecureString",
            "Name": "stg.user_pass",
            "Value": "xxxxx"
        }
    ]
}

よって,Secure String の場合は --with-decryption オプションを付ける必要がある.ちなみに --with-decryption オプションは Secure String 以外の場合は無視されるため,String のときにも付けておけば,コマンドが統一できて良さそう.

$ aws ssm get-parameters --name 'stg.user_pass' --with-decryption
{
    "InvalidParameters": [],
    "Parameters": [
        {
            "Type": "SecureString",
            "Name": "stg.user_pass",
            "Value": "stg.user_pass"
        }
    ]
}

ちなみに aws ssm get-parameters コマンドの詳細は以下にまとまっている.

パラメータストアから取得した値を環境変数に設定する

こんな感じでスクリプトを用意すれば,簡単に The Twelve-Factor App を実現できる.便利!

$ USER_ID=$(aws ssm get-parameters --name 'stg.user_id' | jq -r '.Parameters[].Value')
$ echo ${USER_ID}
stg.user_id

$ USER_PASS=$(aws ssm get-parameters --name 'stg.user_pass' --with-decryption | jq -r '.Parameters[].Value')
$ echo ${USER_PASS}
stg.user_pass

IAM Role でアクセスできるパラメータグループを制御する

まず prd.* にアクセスできる IAM ポリシーと stg.* にアクセスできる IAM ポリシーを用意して,IAM ロールに紐付けた.

  • policy-ssm-prd
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:Describe*",
                "ssm:Get*",
                "ssm:List*"
            ],
            "Resource": [
                "arn:aws:ssm:ap-northeast-1:111111111111:parameter/prd.*"
            ]
        }
    ]
}
  • policy-ssm-stg
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:Describe*",
                "ssm:Get*",
                "ssm:List*"
            ],
            "Resource": [
                "arn:aws:ssm:ap-northeast-1:111111111111:parameter/stg.*"
            ]
        }
    ]
}

次に IAM ロールをアタッチしたインスタンスを起動して動作確認をした.以下の例は stg からパラメータストアにアクセスした状態で,prd.* グループのパラメータにはアクセスできなかった.このように設定することで,別環境の設定が誤って取得されるリスクが無くなる.

$ aws ssm get-parameters --name 'stg.user_id'
{
    "InvalidParameters": [],
    "Parameters": [
        {
            "Type": "String",
            "Name": "stg.user_id",
            "Value": "stg.user_id"
        }
    ]
}
$ aws ssm get-parameters --name 'prd.user_id'

An error occurred (AccessDeniedException) when calling the GetParameters operation: User: arn:aws:sts::111111111111:assumed-role/ec2-ssm-stg/i-22222222222222222 is not authorized to perform: ssm:GetParameters on resource: arn:aws:ssm:ap-northeast-1:111111111111:parameter/prd.user_id

簡単に図にすると,このようになる.

f:id:kakku22:20170610180308j:plain

re:Invent 2016 動画

パラメータストア以外にもいろいろ機能があるので,試してみないと!

www.youtube.com

env-injector

パラメータストアから環境変数に自動的に設定をしてくれる env-injector というツールを先輩の id:okzk が実装していた.これは便利!

$ ENV_INJECTOR_PREFIX=prd env-injector printenv | egrep 'user_id|user_pass'
user_id=prd.user_id
user_pass=prd.user_pass

$ ENV_INJECTOR_PREFIX=stg env-injector printenv | egrep 'user_id|user_pass'
user_id=stg.user_id
user_pass=stg.user_pass

env-injector の詳細は以下の記事を参照で!

okzk.hatenablog.com

まとめ

  • Amazon EC2 Systems Manager の中にはたくさんのサービスがあった
  • 「パラメータストア」は非常に便利でパラメータの格納を AWS に任せられる
  • IAM Role でアクセスできるパラメータグループを制御することもできる
  • クレデンシャル / データベース接続情報などの一般的なユースケース以外にも「パラメータストア」を活用できるアイデアがたくさんありそう

Lambda を軸にサーバレスを解説した「実践 AWS Lambda」を読んだ

AWS Summit Tokyo 2017 の先行発売でゲットした「実践 AWS Lambda」をさっそく読んだ.Lambda の解説だけではなく,サーバレスの文脈で導入事例が増えてきたアーキテクチャ(ユースケース)の紹介がされていたり,サーバレスのデプロイツールとして AWS SAM の紹介がされていたりして,非常に良書だった.Amazon を見ると,一般発売は明日 6/9 になっていたので,気になる人はすぐに買うと良いのでは!

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

Chapter 3 AWS Lambdaの使い方

3-7 バージョニングとエイリアス

Lambda 関数の ARN にバージョンを付与して識別できるのは知らなかった.また,エイリアスを付けて運用できるのも知らなかった.実際に運用している Lambda 関数を見てみたところ,確かにバージョンなしの ARN もあったし,バージョンありの ARN もあった.ちなみに Lambda 関数は Apex でデプロイをしているため,Apex の実装を確認したら自動的に current エイリアスを付与するようになっていた.おおお!

  • arn:aws:lambda:ap-northeast-1:111111111111:function:sample
  • arn:aws:lambda:ap-northeast-1:111111111111:function:sample:$LATEST
  • arn:aws:lambda:ap-northeast-1:111111111111:function:sample:50
  • arn:aws:lambda:ap-northeast-1:111111111111:function:sample:current

docs.aws.amazon.com

3-10 環境変数の利用

暗号化ヘルパーを使うと,環境変数を KMS で暗号化できるのを知った.今のところ,暗号化が必要な環境変数を使っていないため,普通に Apex の project.json でベタ打ちして運用していた.

docs.aws.amazon.com

Chapter 4 プログラミングモデル

4-5 Lambda関数作成時のポイント

特定の言語に依存せず,対応言語全て (Node.js / Python / Java / C#) の解説があるのは素晴らしかった.また Lambda の特性に合ったアーキテクチャに関しては,AWS Summit Tokyo 2017 で講演があった内容とも似ていた.

speakerdeck.com

Chapter 8 サーバレスアプリケーション開発のデプロイ

個人的に1番良かったのは AWS SAM の紹介がされていた点だった.今まで Lambda のデプロイなら Apex を使って,API Gateway が必要なときは Serverless Framework を使っていたけど,AWS から公式に提供された AWS SAM はずっと気になっていてまだ使ったことが無かった.現状サポートされているリソースは Lambda と API Gateway と DynamoDB とのことだが,CloudWatch Events もサポートされると良いなと思う.Apex もここはサポートしていなくて,自動化できなかった.

github.com

本書には記載がなかったけど,AWS SAM で Tracing を設定すれば X-Ray も合わせてデプロイとのこと.気になる!

www.slideshare.net

誤植

初版だからかもしれないけど,typo 系の誤植があって少し気になった.実際に5箇所を発見したため,マイナビに報告をしておいた.確認してもらえれば,以下のサポートサイトに反映されるのかな?と期待している.

book.mynavi.jp

まとめ

  • Lambda を軸にサーバレス全体の理解を改めて整理できた
  • 実際に Lambda + API Gateway + DynamoDB を使うチュートリアルも紹介されていて未経験者にも参考になる内容だった
  • AWS SAM の紹介があり Lambda の運用まで考慮された解説範囲の広さだった

関連記事

先週参加した AWS Summit Tokyo 2017 の参加レポートも参照してもらえればと!

kakakakakku.hatenablog.com

実際に運用している Lambda + Apex の事例も前にまとめていて参照してもらえればと!

kakakakakku.hatenablog.com

AWS Summit Tokyo 2017 に参加して2日間ずっと AWS のことを考えていた

2017/05/30(火) ~ 2017/06/02(金) の期間で,計4日間開催されていた AWS Summit Tokyo 2017 に参加してきた.僕は後半2日間に参加して,非常に満足度が高く,もっともっと AWS を使い倒さなきゃ!とモチベーションが上がった.セッションを聞くだけではなく,ブースで話を聞いてみたり,AWS 認定資格取得者専用ラウンジに行ってみたり,様々な楽しみ方ができたのも良かった.簡単にメモをまとめておこうと思う.

aws.amazon.com

2017/06/01(木)

Speed matters - Amazon Kinesis が実現するストリーミングデータのリアルタイム分析

  • 多くのデータは「持続的に」生成される
  • 新しいデータほど,意思決定において価値が高い
  • Kinesis
    • Kinesis Streams
    • Kinesis Analytics
    • Kinesis Firehose
      • 2ヶ月以内に東京リージョンで使えるようになる
  • 細かく制御をするなら Kinesis Streams,フルマネージドに運用するなら Kinesis Firehose を使う
  • シャードを複数回リードできるため,この点はキューと特性が異なる
  • split-shard コマンド

Kinesis は全然使ったことがないので,話を聞いてきた.Firehose が東京リージョンで使えるようになる(やっと!)というのは期待できる.あと,途中で "Auto-Scaled Streams" という話があったはずだけど,詳細を聞き逃してしまったので,資料公開を待ちたいところ.あと Kinesis の事例として有名なスシローの話も出ていた.AWS をフル活用したアーキテクチャになっていて,これはクラウド導入を悩んでいる大企業にも刺さるなーと思った.

(資料公開待ち)

AWS Shield と AWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション

  • AWS Edge Services
    • CloudFront
    • Shield
    • Lambda@Edge
  • CloudFront を静的コンテンツと動的コンテンツの両方の配信で使う
    • エンドユーザーの近くを TLS の終端にする
    • 1秒間の TTL も使えるため,短い時間のキャッシュでも,スパイク時の負荷を下げられる
  • Lambda はリージョン内のイベントとして使うが,Lambda@Edge はエッジロケーションのイベントとして使える
    • 訪問者バリデーション
      • Bot 判定
      • アクセスログの UserAgent 判定
      • レスポンス生成
      • HTTP Strict Transport Security (HSTS) でヘッダーを書き換えることもできる
  • AWS Shield
    • Standard Protection
    • Advande protection
      • 攻撃されたときにレポートを提供する
      • 24時間体制でサポートをする
      • 請求保護もする
  • AWS WAF
    • 特定の IP を一定時間をブロックすることができる

CloudFront 以外は使う機会がなく,特にエッジロケーションで軽量な処理が行える Lambda@Edge は,かなり未来な感じがするので気になる.

(資料公開待ち)

Cloud connect the world as a Glue

  • SRE Team とは
  • JP / US / UK 3拠点で一緒に会うことは難しい
  • Hybrid & Multi Cloud な構成になっている
    • JP : SAKURA
    • US : AWS
    • UK : GCP
  • あえてフルマネージドサービスを使わずに,仮想サーバを使うことで,環境間の差異をなくしている
  • グローバルなサービスを作るときは距離を意識する(超えられない壁)

AWS フル活用!という事例ではなかったし,他の勉強会でも似た話を聞いたことがあったため,新しい情報はあまりなかったけど,何度見てもメルカリの SRE Team は強いなという印象だった.

speakerdeck.com

Startup CTO Night with Amazon CTO ~Werner Vogels による公開技術レビュー~

chikaku,Axelspace,Repro,3社の CTO がビジネス概要とアーキテクチャを発表し,Werner のレビューを受けるというイベントだった.聞いてる側としては非常に参考になったけど,レビューされる側は相当大変だ.「アップロード機能をセキュアにするために直接 S3 じゃなくて API を経由している」という話に対して「なぜ S3 ではダメなの?」とズバっと質問が出たときはちょっと背筋が凍った.全体を通して,アーキテクチャよりも,コスト計算を強く意識するべきというメッセージを感じ取ったし,そういう目線で経営に参画してこそ CTO なんだろうなとも感じた.

2017/06/02(金)

全部教えます!サーバレスアプリのアンチパターンとチューニング

  • なぜ遅いのか?
    • プログラムの問題
    • コンピューティングリソースの不足
    • コールドスタート
    • アーキテクチャの問題
    • 同時実行数
  • コンピューティングリソースの不足
    • メモリ設定はコンピューティングリソース全体の設定
      • CPU バウンドな処理の場合は,メモリを増やす
  • コールドスタート
    • VPC を利用する場合は,ENI を作成するため,10-30秒も掛かってしまう
    • CloudWatch で取得できる Duration の値には,ENI の作成時間,コンテナ作成,ランタイム起動時間も含まれない
      • 言い換えれば,課金対象にならないということ
  • アーキテクチャの問題
    • API Gateway を Kinesis のバックエンドとして API にすることもできる
    • Lambda では RDBMS を使わずに DynamoDB などを使うと良い
  • 同時実行数
    • 平均実行時間とイベント数から,同時実行数が算出できる
    • 上限緩和も可能だが,現在の最大値は 1000 なので,ほとんどの場合は到達しないのでは

以前にも似たようなスライドを見たことがあったが,改めて理解をし直すことができて良かった.会場も満席で,注目度の高さが感じられた.同時実行数の計算ロジックは初耳だったが,ちゃんとドキュメントには書かれていた.

docs.aws.amazon.com

今週発売になる「実践 AWS Lambda」は,ブースで先行購入することができた!毎日売り切れになっていたようなので,買えて良かった.積読せずに,最優先で読もうと思う.

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

(資料公開待ち)

Amazon EC2 Innovation at Scale

  • Director of Product Management, EC2
  • C4 ➔ C5
    • C5 は Intel Skylake が乗っていて,そろそろ発表できそう
  • R4 と X1
    • R4 : GiB : cCPU = 8 : 1
    • X1 : GiB : cCPU = 16 : 1
    • 今年後半には 4TB の RAM を乗せた X1E を出す予定
  • コスト最適化
    • リザーブドインスタンス
      • スタンダード
      • コンバーティブル
    • スポットインスタンス
  • Amazon Lightsail
    • 気軽に開発環境が欲しい場合
    • AWS Summit Tokyo 2017 の初日に東京リージョンで使えることを発表した

EC2 のプロダクトマネージャーという仕事はかなり面白そうだと思った.去年の re:Invent のキーノートも見ていたし,リザーブドインスタンスとスポットインスタンスの話もある程度は理解していたため,あまり新しい情報は無かった.個人的に Amazon Lightsail を使う場面があるかどうかはわからないけど,東京リージョンで使えるようになったことは嬉しいことで,EC2 に敷居の高さを感じている人に使ってみて欲しいと思う.

(資料公開待ち)

Amazon EC2 Performance Deep Dive

  • プロセッサ関連
    • vCPU
      • ハイパースレッドの論理コア
      • ようするに,物理コアを仮想的に2個に分割する
      • よって,物理コアを2倍すると vCPU になる
    • ハイパースレッド無効化
      • lscpu で CPU レイアウトを確認する
      • 後半の論理 CPU をオフラインにする
      • もしくは chcpu コマンドを使ったり,GRUB の maxcpu カーネルパラメータを設定することもできる
    • P-state と C-state
    • NUMA バランシングサポート
  • ストレージ関連
    • EBS 最適化
    • st1 と sc1
    • インスタンスストアを適材適所に使う
  • ネットワーク関連
    • 拡張ネットワーキング
    • ENA カーネルドライバをインストールする
    • プレイスメントグループ
  • パフォーマンスクレジット
    • CPU と EBS だけではなく,r4 インスタンスにはネットワークのクレジットがある
  • ハードウェアアシスト仮想化 (HVM)
    • 余計な仮想化のオーバヘッドを無くす
    • なるべく HVM を使うことを推奨している
  • RHEL6 の カーネルは 2.6.32 で,2009年に登場したものなので,新しくする
  • チューニングをするときは,まず CPU から行うと良い

4日目で1番聞きたかったセッションに参加できた.プロセッサ関連の話は個人的に未知の領域で,実際に lscpu コマンドなどを試してみたりして勉強してみたいと思う.「詳解システムパフォーマンス」も買ったまま読めてないし,楽しみだ.ストレージとネットワークの話は,ある程度知っていた内容だったかな.困ったときにすぐインスタンスタイプを上げるのではなく,チューニングができるのかを考える癖を付けたい.

(資料公開待ち)

AWS マネージドサービスで実現する CI/CD パイプライン

  • AWS Code 4兄弟
    • CodeCommit
    • CodeBuild
    • CodeDeploy
    • CodePipeline
  • CodeStar
  • BlackDay Gate
    • デプロイしてはダメな日付の場合にデプロイを止める機能
    • DynamoDB にレコードを入れておいて,合致する場合はデプロイを止める

個人的に Rails のデプロイ環境を作るなら GitHub + CircleCI (or Jenkins) + Capistrano のような構成にすることが多いし,実際に Code 4兄弟を使ったことがなく,セッションを聞いてみた.最近発表された CodeStar もどういうレイヤーの開発者が使うんだろう?という疑問がある.簡単に環境が作れることは良いことだけども.あと途中に話が出てた CloudWatch Events と Lambda を使ったシンセティックトラフィック(外形監視とは違う?)の AWS Reference Architecture は,調べても情報が見つけられなかった.詳細が気になるので,もしドキュメントがあれば読みたい.

(資料公開待ち)

その他

AWS 認定資格を取得している人だけが入れるラウンジがあって,そこで休憩などをしていた.早めに行ったこともあって,ピンバッチ以外に傘をもらうことができて,嬉しすぎた.雨の日にドヤ顔で使おうと思う.早い時間だと飲み物もお菓子も提供されてるんだけど,あっという間になくなってしまうので,もう少し定期的な補給があると良かったように思う.

今さら後悔しているのが AWS DevOps Challenge に参加しなかったことで,ああ,これは参加しておけば良かったなと残念な気持ちになっている.絶対楽しいし,学べるし,チームワークも大切だし,挑戦したかった.次回こそは!

gameday-japan.connpass.com

まとめると,2日間非常に楽しめた!お疲れさまでした!

個人的な Keynote ベストプラクティス 2017

最近「どうやってスライドを作ってるの?」と聞かれる機会も増えてきたので,普段 Keynote を使っていて,特に意識しているポイントをベストプラクティスとしてまとめた.参考になれば!

Keynote Best Practice

コーポレート・ロゴ

Unsplash

背景画像を選ぶときは Unsplash を使っている.高解像度でクオリティも高く,様々なバリエーションの背景画像をダウンロードすることができて便利!

unsplash.com

脱 Azusa

Azusa は本当に素晴らしく,僕も今まで何度も使わせてもらった.今もまだ勉強会に参加すると少なくとも1人は Azusa を使っているような気がする.ただし,個人的にはどの資料も似てしまうという点が気になっていて,Azusa の次のステップとして,マスタースライドのカスタマイズに挑戦したという経緯があった.脱 Azusa したい人は是非!

Speaker Deck

フォントを使った例として載せた資料は Speaker Deck に up してある.スライドデザインの推移が感じられて良い!

f:id:kakku22:20170530005546p:plain

関連記事

最近プレゼンに関する記事を書いたけど,「魅せるプレゼン」と「魅せるスライド」があってこそ!合わせて読んでもらえると嬉しい.

kakakakakku.hatenablog.com

Speaker Deck を使う場合は URL に気を付けること.

kakakakakku.hatenablog.com

目標達成をもっと支援したい /「コーチングの基本」を読んだ

「コーチングの基本」を読んだ.今年は "教える" という行動をもっと深く知るという個人的なテーマがあって,2月からプログラミング学習者のパーソナルメンターという仕事もしている.また,社内でメンバーの育成を担当する機会もある.そういう背景から,まずは「コーチング」の本質を知りたいと考えていた.経験的に「こうするべきだよなー」と知っていた部分も多かったけど,それが専門的な用語で表現できることを知れたのが1番の収穫だった.用語で表現できるというのは本当に重要なことだと思う.

コーチングの基本

コーチングの基本

3原則

コーチングには「3原則」と呼ばれるマインドがある.

  • 双方向
  • 継続性
  • 個別対応

個人的にどれも意識していたことではあったが,「双方向」のところで出てきた「オートクライン」という用語を知れて良かった.オートクラインとは「アウトプットすることによって,自分自身で気付くこと」と表現することができて,例えば,どうしても困ったときに誰かに相談したら,相談しながら自分で解決できてしまった,といったような経験がある人も多いのではないかと思う.それこそが「オートクライン」である.また,オートクラインを起こすためには,適切な質問とお互いの信頼関係が必要であると書かれていて,納得感があった.コーチ / メンターの仕事は答えを教えることではなく,自律的に答えに辿り着けるようにサポートすることなので,もっともっと質問力を磨きたいとも思った.

他責と自責

掲げた目標と現在のギャップを考えるときに,そのギャップが発生している原因を他人や環境のせいにしてしまうことを「他責」と言う.

  • 上司が決めてくれないから
  • どうせ言っても聞かないだろうから
  • 私には他にもやる仕事があるから

本書では「他責」の例として,こんな発言が紹介されていた.誰しもよく言ってしまうし,そもそも「愚痴」と言うのは全て「他責」なのではないかと思う.そこで,この「他責」を「自責」に切り替えることで,全ての責任を自分に引き寄せてしまうことができ,目標達成に向けて具体的なアクションが立てられるようになる.本書にも書いてあるが,誰の問題なのかは本質的には重要ではなく,どんな状況でも「自責」に切り替えることで,前向きな行動ができるようになるということだった.僕もメンターとして「今の話を,自分を主語にして説明し直すことができますか?」と積極的に質問を問いかけようと心に決めた.

個人的にも2016年から「愚痴を言わない」というのを意識していて,言いたくなったら具体的なアクションを考えるようにしていた.僕のこの意識は,まさに「他責から自責に」だったんだなと感じた.「愚痴を言わない」という話は年末年始の記事にも書いてある.

kakakakakku.hatenablog.com

聞く(傾聴)

聞くポイントとして,大きく5点紹介されていた.

  • 「聞く」ことに集中する
  • 相手の話の先読みや,結論の先取りをせず,最後まで聞く
  • 相手のノンバーバル(非言語)な情報を受け取る
  • 「聞いている」というサインを送る
  • 沈黙を共有する

2番目に紹介されていた「話を最後まで聞く」というのが,個人的には苦手意識がある.話の先読みをすることが変に習慣化してしまっているため,ミーティングなどでも「あー,なるほど,言いたいことわかる」みたいに食い込み気味で話を進めてしまうことがある.これは本当に話の腰を折ることにもなるし,意識的に直さないといけないなと改めて感じた.

話を聞きながら常にリアクションをしたり,目線を合わせたり,そういうポイントは常に意識しているため問題ないと思うが,ここが苦手な人は非常に多いのではないかと思う.話していて「聞いてるの?」と聞きたくなる状況があれば,それは聞く姿勢が相手に伝わっていないということだと思う.

「聞く」に関しては前から似たような課題感があり,関連した本も読んだことがある.

kakakakakku.hatenablog.com

チャンクダウンとスライドアウト

質問をするときに,詳細に掘り下げていくことを「チャンクダウン」と呼び,別の答えを引き出すことを「スライドアウト」と呼ぶ.課題を洗い出すようなときは,詳細までは考えず「スライドアウト」で質問し,具体的な目標を決めていくときなどは,「チャンクダウン」で質問する.それぞれに用語があるということを知れてよかった.

アクノレッジメント

アクノレッジメントは,承認する行動のことで「活躍しているのを知っていますよ」や「業務改善の効果が本当に大きいですね」のように変化を明確に伝えることを言う.これは過去に読んだジャイキリ解説本でも紹介されていて,コーチングに限らず,組織マネジメントにおいても,本当に重要なことだと思っているので,日々意識して使うようにしている.

kakakakakku.hatenablog.com

まとめ

「コーチングの基本」はコーチングに限らず,組織マネジメントにも応用できる内容になっていて,良書だと感じた.引き続き,コーチング,メンタリング,組織マネジメントを深く学んでいく.

  • 3原則
  • オートクライン
  • 他責と自責
  • 話を最後まで聞く
  • チャンクダウンとスライドアウト

関連

3月にゲスト出演させてもらった Podcast でも関連した話をしているので是非聞いてみてもらえればと!開発合宿に技術アドバイザーを呼んだ施策は「オートクライン」を目的にしていたし,どのように新卒と「相互メンタリング」を推進したのかという話もしている.

lean-agile.fm