1on1で使っているワークシート

元エンジニアリングマネージャで、今は人事をやっています。

この記事は、1on1 Advent Calendar 2019 - Adventar20日目です。

普段ブログを書かないのに、今年はアドベントカレンダーに2つもエントリーしてしまい、なぜか今月2本目のブログです。

普段、1on1をするときに使っているワークシートを紹介します。

前提

  • 普段1on1をやっている相手は、いわゆるエンジニアリングマネージャだったり、テックリードだったり、何かしらチームを見ている人が多いです。
  • なので、1on1の内容もチームや組織の内容が多くなります。
  • 時間は30分〜1時間くらい。
  • 間隔は、週次や隔週や月次など、相手によって変えています。

使っている道具

  • A3のコピー用紙
  • 付箋
  • ペン

1on1の教科書や研修だと、メモしないで相手を見ながら対話しましょうとなっていることも多いと思いますが、 僕は、付箋にメモをしながら、話を聞いています。1on1が終わるとそのA3の紙を写真にとって、1on1の相手に送ります。

実際に使っているワークシート

f:id:sugimori:20191220223106j:plain
ワークシート

書く内容

いろんな研修や本を参考にして、現在は、以下の4つの順に話を聞いています。

現状の問題

まずは、どんな問題を解決したいのか、どういうことに困っているのかを聞きます。 問題と言っていても、何が困っているのかわからないケースがあるので、それによってどんな不都合が発生しているかを聞きます。 また、問題が表面的に事象の場合は、ある程度、それがなぜ発生しているのかを掘り下げたりもします。

質問例
  • 「現状、どんな問題がありますか?」
  • 「それによって、どんな不都合が生じていますか?」
  • 「どうして、その問題は発生してるんでしょうかね?」

理想の状態

次に、それが本当は、どうなっているのが理想なのかを聞きます。 どうしても、現状のしがらみに引っ張られてしまい、次のステップで行けそうな理想を言いがちです。 本当の理想が聞けないと、そこに向かう力が引き出すことができないので、いかに理想を引き出すかが大事です。 以前は、この「理想の状態」を聞いておらず、どうしても現状の延長の考えしか出てこないことが多かったので、このステップを追加しました。

質問例
  • 「本当は、どうなっていたら良いと思いますか?」
  • 「一旦、現状のしがらみを忘れたとしたら、どうなっているのが理想ですか?」
  • 「1年後には、どうなっていたらうれしいですか?」(ある程度先の未来を示すことで発想を変えてもらう)

ボトルネック

次は、その理想の状態にならない理由を聞きます。 以前は、「問題の原因」を聞いていたのですが、表面的な原因が多かったので、「ボトルネック」という聞き方に変えました。 それによって、単純には解決しない、どこがネックになっているか?ということを考えるようになった気がします。 また、「ボトルネック」というくらいなので、それを解消したら理想の状態になるかを確認します。

質問例
  • 「その理想の状態になっていない、ボトルネックはどこでしょうか?」
  • 「理想の状態にならずに、現状の問題が発生し続けているということは、どこかにボトルネックがあるんですよね?」
  • 「そのボトルネックを解消したら、本当に理想の状態になりますか?」

アクション

最後にアクションを確認します。 理想的には、ボトルネックを解消するためのアクションを考えてもらいます。 しかし、ボトルネックというくらいで簡単に解消できないので、ボトルネックを解消して理想の状態になるために、 何ができるかを考えます。 1on1の周期に合わせて、次回の1on1までに何をするかという宣言をしてもらいます。

質問例
  • 「そのボトルネックを解消するために、何をしますか?」
  • 「ちょっとでも理想の状態に近づけるために、何ができますか?」

まとめ

僕自身が1on1で普段使っているワークシートを紹介しました。もし、参考になればうれしいです。 ただ、このシートも、どんどん変化しているので、また来年は変わってるかもしれません。 1on1の内容は、これが正解というものはなく、相手によって変えても良いと思います。 大事なのは、1on1の相手の思考をサポートしてあげることだと思います。

今回のアドベントカレンダーは、納期の1時間も前に書き終わることができてよかったです。

氷山モデルで相手の立場になって考える

元エンジニアリングマネージャで、今は人事をやっています。

この記事は、Engineering Manager Advent Calendar 2019 - Qiitaの11日目です。

1年に1回、この時期しかブログを書かないので、なかなか筆が進みません。

エンジニアリングマネージャは、チームだったり、組織だったりを相手にして、いろんな問題解決をしますよね。 その時に、マネージャから上から目線で考えたりしているとだいたいうまくいきません。 そんなときに、大事なのは、「相手の立場になって考える」ってことだと思うのです。 しかし、この「相手の立場になって考える」ってのは、小学生からずっと言われ続けていると思うのですが、なかなか難しいです。 特に大人(?)になって、マネージャとかの役職や、組織などいろんな立場の違いができてくると余計に難しい気がします。

組織間でうまく行っていないケースのほとんどは、「相手の立場」を考えていないことから発生していると思っています。

とは言っても、「相手の立場を考えよう!」と言えばできるもんでもないので、僕が考えるときによく使っている「氷山モデル」を紹介します。

氷山モデルとは

氷山モデルとは、「学習する組織」という本の中に出てくる「システム思考」のフレームワークです。

ざっくり言うと、水面にちょっと出ている「できごと」だけを見て、物事を判断するのではなく、 水面下にある「行動パターン」「構造」「意識・無意識の前提」を捉えないと物事を見誤りますよという話です。

  • できごと → 発生している事象
  • 行動パターン → どういうパターンから事象が発生しているのか。
  • 構造 → そのパターンを生んでいる構造は何か。
  • 意識・無意識の前提(メンタルモデル) → その構造の意識的・無意識的な前提は何か。

正確な解説はこちらのページを御覧ください。 www.change-agent.jp

ちなみに、「学習する組織」の本は分厚くて難しいので、こちらの本がおすすめです。

何か解決したい問題が発生したときに、この「氷山モデル」のフレームワークに当てはめて考えてみると割と考えやすかったりします。 いくつかの事例を見てみます。あくまでもフィクションです。

事例1 若手がチャレンジしてくれないケース

できごと

若手が新しいことにチャレンジしてくれないことがあります。 EMとしては、もっといろんなことにチャレンジしてほしいのですが、なかなか思うようになってくれません。

行動パターン → どういうパターンから事象が発生しているのか。

では、その若手は、どういう行動パターンなのかと言うと、 目の前の業務(タスク)をやり続けています。 確かに、チームとしては、業務をやってくれた方が成果は出るのですが、 まだまだ若手なので、いろんなことにチャレンジしてほしいです。

構造 → そのパターンを生んでいる構造は何か。

どうしてどういう行動をとってしまうかというと スクラムチームで開発をしていているという構造から生まれているようです。 チームのメンバーとして、チームの成果に対してコミットするのが当たり前になっているのです。

意識・無意識の前提 → その構造の意識的・無意識的な前提は何か。

その前提としては、チーム活動なので、 * チームに迷惑かけたくない。 という思いもあるのだと思います。

こんな感じで氷山モデルに当てはめてみると「若手がチャレンジしない」という事象が、若者の立場になって考えられているような気がします。

事例2 チームのふりかえりが下手なケース

ふりかえりが下手なチームがあったとします。

できごと

発生している事象としては、 * 問題点の掘り下げが浅い * 本質的でないTryが出てくる みたいなことが発生しています。

行動パターン → どういうパターンから事象が発生しているのか。

そのチームの行動パターンをみていると

  • 定期的にふりかえりをやるということがルーチンになっている。
  • Pに対して、なんでも良いのでTを出すことでふりかえりを終わらせることが目的になっている。

みたいなことが見えてきます。

構造 → そのパターンを生んでいる構造は何か。

ではなぜそうなってるのかと言うと

  • ふりかえりをやることが組織の暗黙のルールになっている

というのが構造的な原因な気がします。

意識・無意識の前提 → その構造の意識的・無意識的な前提は何か。

そして、前提としては、

  • ふりかえりをしても、どうせ仕事でやることは変わらない。
  • 義務感なので、ふりかえりが楽しくない。

というメンタルモデルが背景にあるようです。

まとめ

ちょっと事例が強引だったのでわかりにくかったかもしれませんが、こんな感じでチームの問題点を氷山モデルを使って分析した上で、

  • できごと → 発生している事象
  • 行動パターン → どういうパターンから事象が発生しているのか。
  • 構造 → そのパターンを生んでいる構造は何か。
  • 意識・無意識の前提(メンタルモデル) → その構造の意識的・無意識的な前提は何か。

の4つのどの階層でアプローチをするかを考えていくと、エンジニアリングマネージャとして効果的にチームと向き合えると思います。 とても使いやすいフレームワークなので、おすすめです。

今日中に公開しないといけないので、この辺で。

組織のベースラインを引く

元エンジニアリングマネージャで、今は人事をやっています。

この記事は、Engineering Manager vol.2 Advent Calendar 2018 の19日目です。

もはや関係ないのに未だにエンジニアの1on1を何人かの人とやっているのですが、そこで、同じことを何人かの人に説明することが続いたので、きっと同じようなことで詰まってるんだろうなと思い、久しぶりに書いてみることにしました。*1

前提

  • 僕が1on1をやっている人は、チームのリーダーもしくはリーダー的な動きを期待されている人
  • それぞれのチームは古い人もいれば、新しい人も入ってきて、割とカオス。
  • それぞれのリーダーは、なんとかチームを良くしたいと思ってがんばっている。

1on1での話

とあるAさんの1on1から

チームのみんなが技術的に向上したいって思ってくれない

という悩み。聞いてみるとチームとしては業務はそれなりにこなせているが、Aさんとしては、技術的に分かっていればもっといろいろできるはずという思いがある。 日々の業務は、前の仕事のちょっとした改修だったり、似たような機能の追加が多いので、なんとかなってしまうようだ。 ただ、前の仕事の内容を完璧に理解しているわけではない状態で対応しているので、本来は、もっと違う設計だったり、違う対応方法ができるはずなのに、なかなかそういう発想にならないのである。仕様的には動いているし、納期も守っているので、そのAさん以外は、あんまり課題意識がないようである。

とあるBさんとの1on1から

チームで開発に関するレビューをする時にレビューアの指摘が常にネガティブな言い方になってしまうのでチームの空気が悪くなってしまう

という悩み。聞いてみると指摘事項の中にはレベルの高いことから低いことまでいろいろあるけど、レビューアの個人的な観点で目に付く事を指摘してしまっている模様。本来ならここまでできてたらまずは及第点みたいな事でも、レビューアから見るとアラが見えてしまうので指摘してしまう。また、レビューアの中にもいろんなレベルの人がいるので、指摘している内容がレビューイのレベルに合っていないような指摘になることも。

とあるCさんとの1on1から

チームで勉強会をやる時に、初心者のレベルに合わせてしまう

チームの中で、業務で必要なスキルを習得するために勉強会をしようという話になったときに、チームの中の初心者のレベルに合わせて、勉強を始めてしまうそうです。それ自体は別に悪いことではないのですが、「知らなくて当然」「みんなで覚えていこう」みたいな空気になってしまい、当然身につけておくべきスキルでさえも、「誰かが教えてくれる」という空気が出てきてしまいます。そうなってくると、なかなか勉強会も進まないし、 自分たちのスキルとしても、そのレベルでいいんだなという空気になってしまいます。

みんなで勉強しようというところまでは良かったのですが。

1on1でみんなに伝えたこと

Aさん、Bさん、Cさんのケースに共通なことは、その組織やチームでの基準がないことによる弊害が出ているんじゃないかと思いました。*2

そこで、

組織として最低限満たすべき基準を、みんなで意識をあわすために「組織のベースライン」を引こう

という話をしました。

f:id:sugimori:20181219222343j:plain
1on1で実際に書いた付箋

Aさんのケース

Aさんは、チームのみんなに技術的にもっと上を目指してほしいし、その方がもっと業務を効率的にできると思っています。 しかし、他のチームメンバーは、現状でも業務は回っているし、なぜそんなことをしないといけないのか伝わっていないのでしょう。 特にAさんは、技術的にもできる人なので、他のメンバーからは、Aさんが言っていることはだいぶレベルの高い理想論のように聞こえているかもしれません。 Aさんとしては、そんなにレベルの高いことを要求しているつもりもなく、チームとして「こうなって欲しい」ということを言っているだけなのですが、伝わりません。チームとしての最低限満たすべき基準(ベースライン)の認識が、みんなであっていないことから発生していると思いました。

Bさんのケース

Bさんのケースでは、いろんなレビューアが、それぞれの視点で指摘をしています。 レビューする時って、絶対的な正解があるというよりは、このケースでは、どのレベルまで引き上げるのかということが大事だと思っています。*3 しかし、このチームのレビューアたちは、指摘する際の基準である「どのレベルまで」ということが揃っていないので、「あれができていない」「これができていない」という指摘になってしまっているのかなと思いました。*4 つまり、このチームは、チームとして最低限満たすべき基準である「どのレベルまで」というところが、認識があっていないことから発生していると思いました。

Cさんのケース

Cさんのケースでは、チームでわからないことを自発的に勉強会で教え合う姿勢は、とても良いです。 しかし、チームとして、最低限満たすべき基準として、「最低限このくらいのスキルがないとこのチームではだめだよね。」というラインがないので、 初心者レベルから、「みんなでがんばろう」という感じの空気になってしまいます。それでみんががんばれば、まだいいのですが、 現状の自分のレベルと目標のレベルのギャップがないと、「がんばろう」という気にもならないかもしれません。 このケースも、やっぱり、最低限満たすべき基準である「このレベルのスキル」がないことから発生していると思いました。

どうやって組織のベースラインを引くのか

さて、組織として基準となるべきベースラインがないことからいろんな問題が発生していることがわかりました。 では、どうやってそのベースラインを作ったらいいのでしょうか。

結論から言うと「組織やチームによる」です。*5

自立意識の強いチームに対して、頭ごなしに押し付けても反発するでしょうし、逆に、まだまだジュニアなチームであれば、 自分たちからそのベースラインを作り出すことは難しいかもしれません。 だからこそ、その組織やチームをよく見ているエンジニアリングマネージャの力の見せ所なのです。 その組織やチームにあったやり方で、「組織のベースライン」を自分たちのものになるようにしていかなければいけません。

そういう自律的な基準を作れるようになることが、自己組織化の第一歩かもしれませんね。

まとめ

  • 組織やチームが最低限満たすべきベースラインが決まっていないと、チームがバラバラになって弊害がおきてしまう
  • そうならないために、 「組織のベースライン」を引こう。
  • ただし、「組織のベースライン」が自分たちのものと思えないと、すぐ形骸化するよ。

おまけ

「組織のベースライン」という話をしていたのですが、スクラムの「Doneの定義」もある意味ではベースラインなのかなと思いました。 「Doneの定義」が、チームの成熟度に合わせて見直すように、「組織のベースライン」も組織の成熟度に合わせて、見直していかないといけませんね。

*1:1on1やってるエンジニアにはアウトプットしろと散々言ってるのに自分は何もしてないのでその贖罪というのは内緒です。

*2:ちなみに、Aさん、Bさん、Cさんは、だいたい事実ですが、もう記憶があいまいなので、いろんなものが混ざっているかもしれないですし、創作も入っています。 弊社の人は、Aさんは、誰だ?とか、変な詮索はしないようにお願いします。

*3:いや、まあ、勝手な想像なんですけど。

*4:それ以外にも、いろいろ課題はありそうですが。

*5:あー。やっぱりって感じですよね。

java8の開発環境をクラウド作る

開発環境

ローカルのPCに開発環境を作るといつの間にかバージョンが古くなっていたりするので、クラウド上の開発環境を利用してみます。 他にもいろいろあると思うけど、とりあえず

c9.io

というのを使ってみる。

workspaceを作る

javaはテンプレートが用意されていないので、空のワークスペースを作る。

f:id:sugimori:20160924120138p:plain

なんと右下のところにbashが動いてる。すばらしい。

sugimori:~/workspace $ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"

JDKのインストール

ubuntuらしいので、javaを入れる

sugimori:~/workspace $ apt-cache search java8

java8がない。

sugimori:~/workspace $ apt-cache search java7
openjdk-7-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
openjdk-7-jre - OpenJDK Java runtime, using Hotspot JIT

java7はある。

sourcedigit.com

というわけで、PPAレポジトリというのを追加しないといけないらしい

sugimori:~/workspace $ sudo add-apt-repository ppa:openjdk-r/ppa
 
 More info: https://launchpad.net/~openjdk-r/+archive/ubuntu/ppa
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmp8zr5cno7/secring.gpg' created
gpg: keyring `/tmp/tmp8zr5cno7/pubring.gpg' created
gpg: requesting key 86F44E2A from hkp server keyserver.ubuntu.com
gpg: /tmp/tmp8zr5cno7/trustdb.gpg: trustdb created
gpg: key 86F44E2A: public key "Launchpad OpenJDK builds (all archs)" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK

んで、アップデートしてインストール

sudo apt-get update
sudo apt-get install openjdk-8-jdk

デフォルトがjava7になってるので、java8に変更

sugimori:~/workspace $ sudo update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      auto mode
  1            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      manual mode
  2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1069      manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java to provide /usr/bin/java (java) in manual mode

javacも

sugimori:~/workspace $ sudo update-alternatives --config javac
There is only one alternative in link group javac (providing /usr/bin/javac): /usr/lib/jvm/java-8-openjdk-amd64/bin/javac
Nothing to configure.

と思ったら、1つしかなかった。

最終的には、

sugimori:~/workspace $ javac -version
javac 1.8.0_91
sugimori:~/workspace $ java -version
openjdk version "1.8.0_91"
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)

というわけで、java8の環境ができました。

お試し

public class Main {
    public static void main(String[] args){
        System.out.print("Hello World");
    }
}

Runするとjavaが実行される。

Building Main.java and running Main
Hello World

Process exited with code: 0

無事動きました。

アウトプットしたいアウトプットしたいアウトプットしたい

じゃー、さっさとしろよと言われそうなタイトルですが、アウトプットの手始めにブログを書こうかと思います。

先日、元マイクロソフト中嶋聡さんの「なぜ、あなたの仕事は終わらないのか」という本を読みました。

その中に

「評価恐怖症」のところでお話ししたように、100点の出来を追求しすぎると、自分の中でどんどん勝手にハードルが上がっていき、上司や顧客からの期待に応えられないのではないかという不安が増幅していきます。これではいつまで経っても仕事は終わりません。 すべての仕事は必ずやり直しになります。ですから、 70 点でも 80 点でもいいから、まずは形にしてしまうことから始めましょう。スマホアプリが延々とアップデートを繰り返している理由を考えてみてください。100点の仕事など存在しないのです。それよりも最速でいったん形にしてしまってから、余った時間でゆっくりと100点を目指して改良を続けるのが正しいのではないでしょうか。

という文章がありました。このことは、全くそうだよなと思いつつも、いざ、仕事になると、なかなか70点で形にすることは難しい。 かなり自分で意識をして、70点を目指さないと、形にできない。だからと言って、時間をかけても70点が80点になるくらいなのだけど。 もう1つ70点で形にすることのメリットは、フィードバックがもらえるということも大きいと思う。 自分が思っている100点のイメージと、実際に期待されている100点のイメージが異なる場合がある。 そういう場合は、70点の形を早く見せることによってフィードバックをもらうことが重要となる。

というわけで、ブログを書こうと思った時も、本当は、何か技術的なものを書きたいなと思ったのだけど、まずは、世の中に出すことが重要ということで、こんな内容で出してみる。

P.S. 今書いてる途中に画面遷移をしてしまって、書きかけの記事が消えてしまったかと思って超あせった。やっぱり、さっさと公開すべきだな。というわけで、ポチ。