【書評】フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術
初めに
私は毎週2人の若手と1on1面談を行っており、若手の不安を取り除いたり、成長を助けられるように意識してしていますが、若手の仕事内容や考え方に対して的確なフィードバックができていないという悩みがありました。そこで、そもそもフィードバックとは何か? どんなことを意識すればよいのかを知りたいと思い、この本を読んでみました。
フィードバックとは
相手のパフォーマンス等に対して情報や結果をきちんと通知する「ティーチング」と今後の行動計画を立てる支援を行う「コーチング」の2つの働きかけを通して、部下の成長を促進することがフィードバックです。相手に問いかけて相手に自分で解決方法を気づかせる「コーチング」ばかりに気を取られていると、そもそも知識不足や経験不足の相手には、どんなに解決方法を引き出そうとしても答えは返ってきません。その時に適切な情報を伝える「ティーチング」も重要になってきます。
近年、1on1面談などの部下育成技術で、「コーチング」の重要さをよく耳にし、「ティーチング」が軽視されるような間違った認識がありましたが、これら2つを組み合わせることが重要であることを教えてくれます。
「経験軸」と「ピープル軸」で考える
- 「経験軸」⇒現場での業務経験によって成長する
- 「ピープル軸」⇒職場の人たちから、さまざまな関わりを得られた時に成長する
コーチングによる育成を行うときは、上記の軸をしっかりと押さえる必要があります。
「経験軸」で考える際に重要なのは、「現在の能力でできる業務」のレベルよりも、少し高めの業務を任せていくことが重要です。これは私も最近意識しており、後輩にタスクを振るときに、後輩が経験のない業務をなるべく振るようにしています。もちろん、いつでもサポートできるようにしておく必要があります。
「ピープル軸」で考える際は、「人と人の関わりの量」や「人間関係の質」を向上することで、様々な気づきや学びを得て、成長するきっかけを作ることが重要です。私も普段の雑談や1o1面談なので、ポジティブで楽しい話をしたり、メンタルのケアをしたりすることで、お互いの人となりを理解できるような意識をしています。
フィードバックのプロセス
さあ、実際にフィードバックしてみましょう。フィードバックのプロセスは以下になります。
【事前】・・・・情報収集
【フィードバック】
- 信頼感の確保
- 事実通知：鏡のように情報を通知する
- 問題行動の腹落とし：対話を通して現状と目標のギャップを意識化させる
- 振り返り支援：振り返りによる真因探求、未来の行動計画づくり
- 期待値通知：自己効力感を高めて、コミットさせる
【事後】・・・・フォローアップ
ここで重要なのが、事前と事後を含めてのフィードバックということです。
できるだけ具体的に事実を指摘するために事前の情報収集で「SBI情報」を用意することが大切です。
- SBI情報
S=シチュエーション
⇒どのような状況で、どんな状況のときに・・・
B＝ビヘイビア
⇒部下のどんな振る舞い・行動が・・・
I＝インパクト
⇒どんな影響をもたらしたのか。何がだめだったのか
私はこのSBI情報の収集が足りずに、論理的で具体的に事実を通知できていので、お互いに納得感のある解決策を見つけられなかったり、課題が解決しないまま時だけが過ぎていってしまったりすることがあったことに気づかされました。
終わりに
フィードバックは、相手の成長を願い、相手の意志をリスペクトした上で行う必要があります。また、相手の性格や将来どうなりたいかをしっかり見極めて行う必要があります。この本はそれを大前提として、耳の痛いことをしっかりと論理的に伝えることで、相手の成長を助けられることを教えてくれます。部下のタイプ別の具体的なフィードバックのテクニックも書いてあるので、実際に現在育成で悩んでいる人が読むとなにかしらのヒントを得られると思います。
私もこれを機に、状況を見極めて、効果的なフィードバックができるように、とにかく実践して場数を踏んでいこうと思います。
【GCP】Google Cloud Platform データベースサービスの基礎知識
始めに
GCPのデータベースサービスはいくつか存在し、データの操作方法、料金などそれぞれの特徴があります。すべての機能があり料金も安いようなサービスは存在しないので、各ストレージサービスの特徴をきちんと理解し、実現したいアプリケーションの特性に応じて選択する必要があります。また、資格試験でもこれらの特徴の違いを問う問題がでてきます。今回は構造化データのデータベースサービスについて調査しました。
また、調べるににあたって、下記本と公式ドキュメント(https://cloud.google.com/docs?hl=ja#section-13)参考にさせていただきました。
Google Cloud Platform 実践Webアプリ開発 ストーリーで学ぶGoogle App Engine
- 作者:株式会社トップゲート
- 発売日: 2019/11/29
- メディア: Kindle版
比較表
| Cloud SQL | Cloud Spanner | Cloud Firestore | Cloud Bigtable | |
|---|---|---|---|---|
| ストレージタイプ | リレーショナル | リレーショナル |
No SQL ドキュメント指向 |
No SQL カラム指向 |
| SQLの使用 | ○ | ○ | - | - |
| スケーラビリティ | - | ○ | ◎ | ○ |
| フルマネージド | △ | ○ | ◎ | ○ |
Cloud SQL
特徴
広く用いられているMySQL、PostgreSQL、SQL Serverに対応しており、これらのデータベースを利用したことのあるユーザーなら簡単にデータの操作ができます。
フルマネージドではあるものの、計画メンテナンスによるデータベースの停止が要求されることがあります。
料金
実行するインスタンスのマシンタイプ、ストレージ、ネットワークトラフィックに比例して課金されます。
用途
よく使われるリレーショナルデータベースとの互換性が高いため、オンプレミス環境からの移行時に、オートスケールが不要であれば適しています。
Cloud Spanner
特徴
Googleが新規に開発した分散データベース。SQLによる操作と強整合性、また、高いスケーラビリティを持ったフルマネージドデータベースサービスです。
ただし、標準のリレーショナルデータベースとは異なる部分もいくつかあるため、注意が必要です。
料金
データを処理するノード数と容量、ネットワークトラフィックに比例して課金されます。
用途
ミッションクリティカルなシステム
Cloud Firestore
特徴
高速でサーバーレスのフルマネージド型クラウド ネイティブ NoSQL ドキュメントデータベースです。強整合性と高いスケーラビリティを持っています。
料金
データの容量・データの操作回数、ネットワーク利用容量によって課金されます。
用途
ユーザープロフィール、ゲームの状態情報の保存
Cloud Bigtable
特徴
低レイテンシで高スループットなワークロードに最適な、スケーラブルなフルマネージドNoSQLワイドカラム型データベースです。
料金
データを処理するノード数と容量、ネットワークトラフィックに比例して課金されます。
用途
金融・証券向けのサービス、IoT
【書評】宇宙兄弟 「完璧なリーダー」は、もういらない。
初めに
最近、リーダー論やチームビルディングに興味があり、いろいろ本を読んでいる中でこの本に出合い、好きな漫画の一つである「宇宙兄弟」を通して、新たなリーダー像を教えてくれた大切な１冊になりました。
現在の私は、来年くらいには小さなチームのリーダーをすることを目指して、普段の業務からリーダーシップを発揮するように努力しています。同じように将来リーダーを目指している方や、普段、言われたことだけをなんとなくやってしまっているような方にもおススメできます。
大丈夫、あなたはリーダーになれます。
優秀でなければリーダーになれないと思っていませんか？かくいう私も少し前までのリーダー像は、「ミスをしない」、「素早く正しい判断ができる」、「メンバーをゴールまで力強く引っ張る」人物を想像しており、とてもハードルが高く困難な道のりだと思っていました。もちろんそれも一つのリーダー像ですが、この本は、宇宙飛行士のようなエリートの中では決して優秀には見えないムッタが、大きなリーダーシップを発揮していることを教えてくれます。
漫画を振り返ってみると、確かにムッタのいるチームは結果的に目的を達成しており、メンバー全員が心を開き、成長していましたよね。
それらの要因を漫画の描写を具体例に、分かりやすく説明してくれます。
愚者風リーダーシップって?
漫画の中のムッタは先頭に立ってみんなを引っ張りながらチームをまとめていくタイプではありません。自分を完璧だと思っていないので、メンバーの意見を聞き、理解し、みんなで協力して進めていきます。
このように、メンバーを仕切ったり、命令したりせず、「リード」することが愚者風リーダーシップといえます。これなら私も完璧になろうと無理に努力しなくてもリーダーシップを発揮できそうです。あなたもそう思いませんか？
終わりに
この本を読んで、自分らしいリーダーシップとはなにかを考えるきっかけとなり、自然とついていきたくなるような魅力的なリーダーであり人間になりたいと思わせてくれました。
もう一度、ムッタを新しい時代のリーダー像としてイメージしながら「宇宙兄弟」を読んでみようと思います。
最後に印象的な言葉を引用させていただきます。
さあ、人生のハンドルを自分で握りましょう!
BigQueryでJSON型の文字列の取得
はじめまして!
クラウドエンジニアのkitoketaです。
BigQueryでJSONデータを抽出する関数について、基本的な書き方と、便利な使い方をまとめました。生データのJSONをBigQueryで展開してから分析することも多いので、覚えておいておくと便利です!
■公式ドキュメント
https://cloud.google.com/bigquery/docs/reference/standard-sql/json_functions?hl=ja
JSON_EXTRACT
JSONデータをパースしてSTRING値を返します。
すべての要素取得
SELECT JSON_EXTRACT('{"name" : "Bob", "age" : 15}', '$') AS json_string
+-----------------------+
| json_string |
+-----------------------+
| {"name":"Bob","age":15} |
+-----------------------+
要素を指定して取得
SELECT
JSON_EXTRACT('{"name" : "Bob", "age" : 15}', '$.name') AS name,
JSON_EXTRACT('{"name" : "Bob", "age" : 15}', '$.age') AS age
+------+-----+
| name | age |
+------+-----+
| "Bob" | 15 |
+------+-----+
リストの要素取得
WITH tmp AS (
SELECT
'{"name" : "Bob", "age" : 15, "family" : [{"name" : "Tom", "age" : 40}, {"name" : "Emma", "age" : 39}]}' AS json
)
SELECT
JSON_EXTRACT(json, '$.family') AS family,
JSON_EXTRACT(json, '$.family[0]') AS first_family,
JSON_EXTRACT(json, '$.family[0].name') AS first_family_name
FROM tmp
+----------------------------------------------------+-------------------------+-------------------+
| family | first_family | first_family_name |
+----------------------------------------------------+-------------------------+-------------------+
| [{"name":"Tom","age":40},{"name":"Emma","age":39}] | {"name":"Tom","age":40} | "Tom" |
+----------------------------------------------------+-------------------------+-------------------+
JSON_EXTRACT_SCALAR
文字列のダブルクォーテーションを外した値を取得する
SELECT
JSON_EXTRACT('{"name" : "Bob", "age" : 15}', '$.name') AS name,
JSON_EXTRACT('{"name" : "Bob", "age" : 15}', '$.age') AS age
+------+-----+
| name | age |
+------+-----+
| Bob | 15 |
+------+-----+
Google App Engine 基礎知識
はじめまして!
クラウドエンジニアのkitoketaです。
現在のGCPを使った業務では主にDataFlowとBigQueryを使ったビッグデータ処理システムに携わっていますが、以前の現場ではプラットフォームにAWSのElastic Beanstalkを使ったWebアプリケーションの開発を行っていました。
今回、GCPのサービスを使ってWebアプリケーションを開発する際のプラットフォームはどんなサービスを使うのか調べた際に、一番最初に出てきた、
Google App Engine(GAE)に関しての基本情報をまとめてみました。
GAEの概要
一言で言うと...
「Webアプリケーションを容易に構築・稼働させることができるサービス」
です。
インスタンスの管理や、スケーリングを自動的に行ってくれるので、開発者はアプリケーション開発に集中できます。
対応言語(2020/5 時点)
Standard Environment(SE)とFlexible Environment(FE)
詳しい比較は公式ドキュメント(https://cloud.google.com/appengine/docs/the-appengine-environments?hl=ja)を参照してほしいのですが、
その名の通り、FEの方がSEに比べて自由度の高いWebアプリケーション開発が可能です。
しかし、近年ではSEも各種の制限が大きく緩和され、自由度が高くなってきています。
どちらの環境にするかの選択方法としては、基本的にはSEでできないかを考えて、それでも難しいような下記のような条件がある場合はFEを選択すればよいでしょう。
以降は、SEを前提として記載していきます。
GAEの特徴
複数バージョンの管理
１つのWebアプリケーションに対して複数のバージョンを配置することができます。
これにより、Blue-Greenデプロイメントが実現できます。
トラフィック分割
サービスの各バージョンに対してユーザーからのトラフィックを分割させることができます。
これにより、カナリアリリースが実現できます。
自動スケーリング
負荷が増大したさいに自動的にインスタンスを増やしたり、負荷が低下した場合は自動的にインスタンスを減らしてくらます。
これにより、ピーク時を想定して対策を行う必要がなく、適切なインスタンス数にしてくれるので無駄な料金が発生しません。
GAEの料金体系
詳しい料金は公式ドキュメント(https://cloud.google.com/appengine/pricing?hl=ja)を参照してください。
デフォルトでは、アクセスが無い場合は最低インスタンスが0台なので、全くアクセスがなければ料金が発生する心配もありません。
また、1日あたり28時間分の無料枠があるので、インスタンス1台であれば料金は発生しません。(FEは無料枠無し)
まとめ
調べた結果、とりあえずGCPを使ったWebアプリケーションを開発する際のプラットフォームは、基本的にGAEのSEを選んでおけば間違いないということが分かりました。
ただ、他のサービスとして、コンテナ化されたWebアプリケーションを稼働させることができる「Cloud Run」や、HTTP(S)でのリクエスト以外にもトリガーにできる「Cloud Functions」など、いろいろな候補があることも分かったので、調べてみて別記事でまとめてみたいと思います。
次回は実際にデプロイしてWebアプリケーションを動かしてみるところまでをやってみたいと思います!
Google BigQuery 基礎知識
始めに
業務で2年弱Google BigQuery(以下BigQuery)を使用したビッグデータの収集、分析業務に携わっており、この機会にBigQueryとは何か、どのような使い方ができるか、注意することは何か、なのどの基礎知識をまとめてみました。
BigQueryとは?
特徴
公式ドキュメント: https://cloud.google.com/bigquery/what-is-bigquery?hl=ja
Google Cloud Platform（GCP） で提供されるフルマネージドのサーバーレスなクラウド データウェアハウスです。
データウェアハウスとは?
意思決定のため、目的別に編成され統合されたデータを保管したデータベースのことです。時系列で保存するため、分析しやすいという特徴があります。
また、通常のRDBと異なり、列指向なので、必要な列のみを読み込むので処理が高速である。
料金
デフォルトでは、実行したクエリに対してのみ料金が発生します。
クエリの参照を必要な日付の必要な列に絞ればとても膨大なデータでも安く使えます。
※一部のみ記載。詳しくは公式ドキュメント参照してください。
| オペレーション | 料金 |
|---|---|
| アクティブ ストレージ | $0.020 per GB |
| クエリ（オンデマンド） | $5.00 per TB |
どんなことができる?
過去の膨大なデータを蓄積し、SQLやBIツールを使って分析することで、今後のビジネス方針の判断ができる。
データセット
テーブルをまとめる箱のようなイメージです。すべてのテーブルとviewはデータセットに属していないといけません。また、データセット単位でのアクセス権限の制御が可能です。
日付別テーブル
テーブル名に"_yyyymmdd"のサフィックスを付けるとテーブルを付けるとUI上でテーブルをまとめてくれます。日付ごとにデータを集計して、障害が起きた時にその日付テーブルだけを削除して再集計することができるので便利です。
パーティショニングテーブル
１つの大きいテーブルを小さいパーティションに分割することでクエリのパフォーマンスを向上させることができ、クエリで読み取られるバイト数を減らすことによってコストを削減できます。
ユーザー定義関数
JavaScript を使用して自作の関数を作成できます。
SQLだけだとできない複雑な処理や、クエリ費用を抑えたり、高速に実行できるように事前にデータを絞り込みむことができます。
料金の節約方法
- 必要な日付のみに絞る
- 「
SELECT *」はなるべく使わずに必要なカラムのみSELECTする - クエリのバイト数制限を指定する
- 分析しやすく、データを絞った分析用テーブルを作る
- 簡単にデータを見たいときはウェブUIの「プレビュー」機能を使う(無料)
- クエリ実行前にdry run結果を見て見積もる
- 分析しなくなった古いテーブルは削除する
まとめ
ビッグデータを扱うには使いやすく、値段も安く、高速なのでBigQueryが温度感の高い選択肢になると思います。
ただ実行クエリの料金は常に気を付ける必要があり、分析する際の値段が安くなるようにしっかりテーブルの設計をする必要があります。
今後の記事では、実際に使うことの多いクエリのテクニックや、他のGCPサービスと組み合わせてどのように使っているかを書きたいと思っています。
1on1面談について考えてみる 基本編
はじめに
30歳という年齢になり、それなりに自分の業務をこなせるようになると、部下の育成も仕事の1つになりますよね。私は部下の育成が楽しくて常に改善していくようにしています。
育成の一環として、これまで約１年半ほど、計3人の部下と毎週の1on1面談を行ってきました。
その際に意識していることや改善点などをまとめてみました。
一般的に定義されていることだけではなく、私が経験した中で考えたり感じたりしたことを書くので、それが少しでも参考になればと思います。
1on1面談の目的
部下の成長の手助けをする
- これが一番大事。部下の成長を本気で願っていれば、1on1面談の内容が常に改善され、より良いものに自然となるはずです。
メンタル面のケア
- 業務、人間関係、プライベートでの不安や不満をヒアリングし、協力して解決に向けて動く。
心理的安全の向上
- 部下が働きやすく、いろいろなことにチャレンジできるような環境になるように話し合う。
業務の振り返り
- 業務で上手くいったこと、失敗したこと、学んだことなどをヒアリングしフィードバックすることで、新しい学びや気づきを深めてもらう。
1o1面談による効果
- スキルアップ
- 不安の解消
- モチベーション向上
- コミュニケーション不足の解消
- 今後のキャリアについて考える時間ができる
1on1面談の内容
業務の振り返り
- 上手くいったこと、工夫したこと、失敗したこと、改善点、不安点、新しい学び、について話してもらう。
- すぐに振り返った方が効果があるので、重要なことはなるべく1on1だけでなく、普段の業務中に話す。
将来的な目標や努力していることについて話してもらう
- 気持ちの変化や、努力していることを話してもらい、ポジティブな感情を引き出しましょう。
プライベートで楽しかったことや不安なことについて話せる範囲で話してもらう
- ポジティブな話をしてもらって楽しんでもらう。不安なことは改善案を一緒に考えてみる。
部下が話したいことを何でも話してもらう
- どんな些細なことでもいいので、自由に話してもらう。それに対してきちんとヒアリングする。
気を付けること
開催頻度は週1回
- 経験上、月1回だと間隔が長すぎて、いろいろ忘れていたり深い話に時間を使えなかったです。
- 基本的には自分の通常業務より優先度が高いと考えれば、毎週のように「忙しいから今週は中止」みないにはならない。
- リリース業務や障害対応中だったり、部下から延期の申し出があれば延期します。
面談時間は基本30分だが、その場の流れで臨機応変に
- 話すことが終わって、30分より早く終わってもだらだら話さずに終わらせる。
- 話が盛り上がって30分を超えたとしても意味がありそうなら満足するまで進める。
- その時は終わるタイミングは伝えておきましょう。
主役は部下
- 聞かれてもないのに自分の話をしない。
- 「質問」を工夫して話を引き出してあげる。
部下の負担にならないように注意する
- 業務の指示、命令はしない。
- 無理に課題の解決策を出さなくてよい。
- 「コーチング」ではなく「カウンセリング」の気持ちで臨む。
それぞの部下の性格や将来的な目標に合わせて1on1面談のやり方を変える
- 自分の事を話すことが苦手な部下と得意な部下、自己学習が好きな部下とプライベートを大事にしたい部下、など、それぞれ一人ひとり違う考え方を持っているので、それに合わせてそれぞれに最適な1on1のやり方を考えて実践する。
部下の意見は否定せずにすべて一度受け入れる
- 部下が明らかに間違ったことを言っていたり、感情的になっていても、否定せずに一旦すべて受け入れましょう。そのうえでヒアリングを重ね相手の本当に伝えたいことや、改善策を引き出すことができれば、部下にとって納得感があり、進むべき道に進めるようになるでしょう。
