エンジニアリングマネージャのためのファシリテーションのコツと帆船のエクササイズ
元エンジニアリングマネージャで、今は人事をやってます。
この記事は、Engineering Manager Advent Calendar 2020 - Qiita の12/6の記事になります。
今でも、エンジニアリングマネージャの人たちと話をしたりするのですが、みんな見ているチームのふりかえりがうまくいってないとか、チームで議論をしていても、議論が浅くなったりとか、いろいろ悩んでいるようなので、エンジニアリングマネージャのチーム運営に役に立つようなファシリテーションのコツを書いてみようと思います。
目次
だめなパターン
コツの話をする前に、まずは、うまく行ってないケースを考えます。
- 議論が空中戦
- 議論が浅い
- 特定の人だけが議論している
議論が空中戦
これは、まー、よく見ます。エンジニアのチームだけじゃなくて、社内の偉い人がいる会議でも普通に起きてます。 特に、リモートワークになったことで、Google meet等でWeb会議をするのですが、最初は、プレゼン資料をベースに 会議をしていたとしても、その後、議論が派生してくると、ほとんど空中戦になる気がします。
空中戦の何が問題かというと、余程議論している人たちのコンテキストやスキルが共通していない限りは、議論の前提や、考えていることが一致していません。同じキーワードで話をしていても、それが何を指しているかが、ずれます。
あと、ふりかえりのKPTで付箋を使っているので、空中戦にならないと思うかもしれませんが、軽いテーマでProblemを議論する分には良いですが、議論を深めていこうとすると結局空中戦で話していることが多くなります。
例えば、「将来的にはこうしたいよね」みたいな話が出たとき、将来というのが、1年後なのか、3年後なのかみたいなところからずれていることが多いです。
また、空中戦のまま、議論がうまくできた、結論が出たと思っても、後から冷静になって、思い出してみると、なんでこんな結論になったんだっけ?と思い出せないことになります。
ということで、ある程度難しい議論になって、みんなが口頭のみで議論を始めたら怪しいと思いましょう。
議論が浅い
これは、問題解決型の議論のときに発生しやすいです。 特に、実力のあるエンジニアにこういう傾向が多い気がします。なんとなくですが。
チームで何か解決したい問題があった場合に、問題を表面的に捕らえて、すぐできる解決策に飛びついてしまうのです。
例えば、「チームメンバーのスキルが伸びない。」という課題があったとして、「1週間のうち2時間各自が勉強する時間を取る」 という解決策を決めたりします。
もちろん、ずっと検討していて何も行動しないよりは、何かしらのアクションを取る方がいいのですが、 問題の分析が浅いので、そのアクションが本質的な問題解決になっていない場合があります。
スキルが伸びない原因が、「時間」の問題だけであれば上記の解決策でも良いのですが、それ以外に
- スキルを伸ばしたいという意欲がない
- スキルを伸ばした先のなりたい姿のイメージが湧いていない
- スキルの伸ばし方がわからない
みたいな原因があった場合は、単純に時間を作るだけでは解決しないかもしれません。
また、ふりかえりで、このようなアクションが続くと「いろいろやったけど、結局何も解決できないね。」となってしまい、 ふりかえり自体が意味がないんじゃないかという思考になってしまいます。
しかし、ファシリテーターとして、この「議論が浅い」というのを見極めるのは、ちょっと難しいかもしれません。
まず、「ファシリテーター自体が客観的に問題を見れるか」ということが重要です。 ファシリテーター自体が、チームメンバーと同じ立場で議論していると、なかなか客観的に見ることができません。 ファシリテーターは、「今、こういう議論をしているけど、他の視点や観点はないだろうか?」と問い続けないといけません。
もう1つ「議論が浅いという指摘をしたとして、そのことをチームメンバーが受け入れることができるか」という問題があります。 一般的に、ファシリテーターであるエンジニアリングマネージャよりもチームメンバーは経験が少ないでしょう。 チームメンバーが従来考えたことないような観点が抜けていたとして、それを指摘されたときに、「あぁ。なるほど。その観点は抜けていましたね。」となればいいですが、「そんなこと言ったって、やってみないとわからないじゃないか。」と思われてしまうと逆効果です。
なので、「議論が浅い」という問題が見えたときは、その指摘が、チームメンバーにとって受け入れられるレベルのギャップなのかを見極めて、もし、チームにとってちょっとギャップが大きいと感じる場合には、1回指摘するのをスルーして、チームのメンバーの結論を見守ります。その結果、うまくいかなかったときに、はじめて違う観点での指摘を受け入れられるようになるのです。
ということで、チームメンバーの「議論が浅い」と感じたときには、チームのレベルと指摘のレベルを見極めた上で対策を考える必要があります。
特定の人だけが議論している
これは、チームのメンバー構成に差があるときによく起こります。年齢差やプロジェクト経験の差、スキルの差などなど。 特定の人たちの間では、それなりに意思疎通が取れているので、議論自体は有意義に進んでいる可能性もありますが、 それ以外のメンバーの腹落ち感や感情面が置いていかれているかもしれません。
そもそものチームビルディングがうまくできていない可能性もあります。
ということで、特定の人だけが議論している場合は、要注意です。
ファシリテーションのコツ
空中戦にならないように議論の構成を事前にデザインする
何も準備なしに議論を始めると、空中戦になります。 そうなってから、空中戦にならないように議論を見える化するのは大変です。
そうならないように、事前に議論の構成(プロセス)を事前に考えておきましょう。 議論の構成というのは、単なるアジェンダではありません。 議論の前提から結論に至るまでの構成(プロセス)をメンバーの感情的な持って行き方も含めて 具体的にデザイン(想像)することが大事です。
帆船エクササイズ
議論の構成の例として「帆船エクササイズ」というものを使って考え方を紹介します。
このエクササイズは「Agile Talks vol.1」という勉強会で紹介されていて、初めて知りました。 あんまり日本では流行ってないみたいですが、使いやすいフレームだと思います。
詳細は以下に掲載されているので、興味があれば参照ください。
このエクササイズから得られるもの このエクササイズはチームがビジョンを明確にするのに役立ちます。チームの方向性に潜むリスク、チームを停滞させるもの、そして、目標を達成するために実際に必要なmのを明らかにしてくれます。
以下のSTEPは、僕なりにアレンジしたものなので、本家とは違うかもしれませんので、ご了承ください。
STEP0 ステージを設定する(5分)
説明
島、帆船、岩、錨、追風の絵を書いてください。 帆船は、自分たちのチームを表しているので、帆船の名前もつけてください。
最初は、アイスブレイクも兼ねて、みんなで絵を書いてもらいます。普段、なかなか絵を書くことはないと思うので、非日常を感じて、今後のエクササイズを受け入れる準備をします。 また、帆船に名前をつけることで、その絵を自分事に感じてもらうようにします。
例えばこんな感じの絵を書きます。
STEP1 ゴール・ビジョンを描く(10分)
説明
自分たちのチームの3年後に、どんなゴール・ビジョンを目指したいか考えてください。 今の延長ではなく、純粋にどうなっていたいかを考えてみましょう。
まずは、個人毎に考えて、付箋に書いてください。(3分)
その後、一人ずつ発表しながら、チームで共有し、島の場所に付箋を張ってください。(7分)
どうしても、何かを議論する時に、現状に引きずられがちになってしまうので、 まずは、ある程度の先の未来にどうなっていたいかを考えるステップです。
STEP2 ゴールに向かう上でのリスク・抵抗力を明らかにする(10分)
説明
帆船がゴールに向かう上でのリスク・抵抗力を考えてください。
リスク(岩):将来起こるかもしれない未知の障害になるであろうこと
抵抗力(錨):現時点のチームが前に進むスピードを遅くしている力
まずは、個人毎に考えて、付箋に書いてください。(3分)
その後、一人ずつ発表しながら、チームで共有し、岩(リスク)と錨(抵抗力)の場所に付箋を貼ってください。(7分)
時間があれば、なぜそのリスク・抵抗が発生するか話し合ってください。
STEP1で描いたゴールに対して、何が障害になるかを考えてもらうことで、次のアクションがより具体的に実効性を もたせるようにします。このSTEPがないと次のアクションが単純にゴールを実現するための思いつきになってしまうので、 このステップがとても重要です。
STEP3 リスク・抵抗力を減らして帆船を前に進める方法を考える(20分)
説明
ゴールに向かって帆船を進める方向を考えます。
今の帆船のスピードをより加速する方法
リスク(岩)を回避する方法
抵抗力(錨)を小さくする方法
まずは、個人毎に考えて、付箋に書いてください。(5分)
その後、一人ずつ発表しながら、チームで共有し、追風の場所に付箋を貼ってください。(10分)
いろいろなアイデアの中で、どれが良さそうか具体的なアクションを話し合って決めてください。(5分)
STEP1で描いたゴールとSTEP2の障害の2つを両方意識することで、 机上の空論ではない地に足のついたアクションでかつ未来に向かっていけるような思考にします。
議論が浅くならないための、「問い」を立てる
議論の構成が事前にできていれば、議論の中で、そこからずれていないか都度確認することで、議論を前向きに進めることができます。
例えば、先程の「帆船のエクササイズ」であれば、以下のような問いが有効です。
「STEP1 ゴール・ビジョン」を考える時の問い
- 現状の延長ではなく、本当に実現したいゴールが考えられていますか?
- そのゴールが実現した時をイメージした時に、ワクワクしますか?
- そのゴールは、自分たちだけでなく周りの人にも喜んで貰えますか?
- このゴールは、みなさん全員が行きたいと思えるものですか?
「STEP2 リスク・抵抗力」を考える時の問い
- まだ顕在化してないけど、帆船が進んだ時に、出くわす岩のリスクはないですか?
- 今挙げている「抵抗力の錨」がなかったとしたら、帆船は、何事もなくゴールの島につきますか?
- 他に、リスク・抵抗力はないですか?これが全部ですか?
- 今挙げている「錨の抵抗力」と違う切り口があるとしたら、何がありますか?(切り口)
- このリスクの岩は、どういう場合に顕在化しますか?
- 今、みなさんのチームが困ってることは、この抵抗力の錨として現れていますか?
- この「錨の抵抗力」は、具体的には、どんなふうに帆船のスピードを遅くしているのですか?(具体化)
「STEP3 アクション」を考える時の問い
- この風のアクションで、錨の抵抗力は、本当に吹き飛ばせますか?そう思う理由は?
- この風のアクションで、岩のリスクは本当に避けることができますか?
- 錨の抵抗力自体を無効にしてしまうようなアクションは考えられませんか?
特定の人だけ議論しないようにする
まー、これはそのままです。はい。
- 議論についていけてなさそうな人がいたら、「○○さん、この辺は、理解できていますか?」と振る。
- 何か言いたいことがありそうな人がいたら、「○○さん、どう思いますか?」と振る。
等で、全体で議論しているような演出をしましょう。 実際の議論のメインは、特定の人だけになってしまうかもしれませんが、みんなで議論したという実感を持ってもらうことが重要です。
最後に
エンジニアリングマネージャにとって、ファシリテーションのスキルは必須です。 ですが、意外と本能で乗り切っている人が多い気がします。 エンジニアのプログラミング等と同じように、ファシリテーションも基礎があって、学べば一定のスキル向上ができます。 チームでの議論がうまくいかないな、と思っているエンジニアリングマネージャの方は、ぜひ、ファシリテーションについて 学んでみてください。
参考文献
ファシリテーションというと割とふわっとした本が多いのですが、この本は、具体的にロジカルに説明してくれているので、エンジニアリングマネージャに向いてると思います。
1on1で使っているワークシート
元エンジニアリングマネージャで、今は人事をやっています。
この記事は、1on1 Advent Calendar 2019 - Adventarの20日目です。
普段ブログを書かないのに、今年はアドベントカレンダーに2つもエントリーしてしまい、なぜか今月2本目のブログです。
普段、1on1をするときに使っているワークシートを紹介します。
前提
- 普段1on1をやっている相手は、いわゆるエンジニアリングマネージャだったり、テックリードだったり、何かしらチームを見ている人が多いです。
- なので、1on1の内容もチームや組織の内容が多くなります。
- 時間は30分〜1時間くらい。
- 間隔は、週次や隔週や月次など、相手によって変えています。
使っている道具
- A3のコピー用紙
- 付箋
- ペン
1on1の教科書や研修だと、メモしないで相手を見ながら対話しましょうとなっていることも多いと思いますが、 僕は、付箋にメモをしながら、話を聞いています。1on1が終わるとそのA3の紙を写真にとって、1on1の相手に送ります。
実際に使っているワークシート
書く内容
いろんな研修や本を参考にして、現在は、以下の4つの順に話を聞いています。
- 現状の問題
- 理想の状態
- ボトルネック
- アクション
現状の問題
まずは、どんな問題を解決したいのか、どういうことに困っているのかを聞きます。 問題と言っていても、何が困っているのかわからないケースがあるので、それによってどんな不都合が発生しているかを聞きます。 また、問題が表面的に事象の場合は、ある程度、それがなぜ発生しているのかを掘り下げたりもします。
質問例
- 「現状、どんな問題がありますか?」
- 「それによって、どんな不都合が生じていますか?」
- 「どうして、その問題は発生してるんでしょうかね?」
理想の状態
次に、それが本当は、どうなっているのが理想なのかを聞きます。 どうしても、現状のしがらみに引っ張られてしまい、次のステップで行けそうな理想を言いがちです。 本当の理想が聞けないと、そこに向かう力が引き出すことができないので、いかに理想を引き出すかが大事です。 以前は、この「理想の状態」を聞いておらず、どうしても現状の延長の考えしか出てこないことが多かったので、このステップを追加しました。
質問例
- 「本当は、どうなっていたら良いと思いますか?」
- 「一旦、現状のしがらみを忘れたとしたら、どうなっているのが理想ですか?」
- 「1年後には、どうなっていたらうれしいですか?」(ある程度先の未来を示すことで発想を変えてもらう)
ボトルネック
次は、その理想の状態にならない理由を聞きます。 以前は、「問題の原因」を聞いていたのですが、表面的な原因が多かったので、「ボトルネック」という聞き方に変えました。 それによって、単純には解決しない、どこがネックになっているか?ということを考えるようになった気がします。 また、「ボトルネック」というくらいなので、それを解消したら理想の状態になるかを確認します。
質問例
- 「その理想の状態になっていない、ボトルネックはどこでしょうか?」
- 「理想の状態にならずに、現状の問題が発生し続けているということは、どこかにボトルネックがあるんですよね?」
- 「そのボトルネックを解消したら、本当に理想の状態になりますか?」
アクション
最後にアクションを確認します。 理想的には、ボトルネックを解消するためのアクションを考えてもらいます。 しかし、ボトルネックというくらいで簡単に解消できないので、ボトルネックを解消して理想の状態になるために、 何ができるかを考えます。 1on1の周期に合わせて、次回の1on1までに何をするかという宣言をしてもらいます。
質問例
- 「そのボトルネックを解消するために、何をしますか?」
- 「ちょっとでも理想の状態に近づけるために、何ができますか?」
まとめ
僕自身が1on1で普段使っているワークシートを紹介しました。もし、参考になればうれしいです。 ただ、このシートも、どんどん変化しているので、また来年は変わってるかもしれません。 1on1の内容は、これが正解というものはなく、相手によって変えても良いと思います。 大事なのは、1on1の相手の思考をサポートしてあげることだと思います。
今回のアドベントカレンダーは、納期の1時間も前に書き終わることができてよかったです。
氷山モデルで相手の立場になって考える
元エンジニアリングマネージャで、今は人事をやっています。
この記事は、Engineering Manager Advent Calendar 2019 - Qiitaの11日目です。
1年に1回、この時期しかブログを書かないので、なかなか筆が進みません。
エンジニアリングマネージャは、チームだったり、組織だったりを相手にして、いろんな問題解決をしますよね。 その時に、マネージャから上から目線で考えたりしているとだいたいうまくいきません。 そんなときに、大事なのは、「相手の立場になって考える」ってことだと思うのです。 しかし、この「相手の立場になって考える」ってのは、小学生からずっと言われ続けていると思うのですが、なかなか難しいです。 特に大人(?)になって、マネージャとかの役職や、組織などいろんな立場の違いができてくると余計に難しい気がします。
組織間でうまく行っていないケースのほとんどは、「相手の立場」を考えていないことから発生していると思っています。
とは言っても、「相手の立場を考えよう!」と言えばできるもんでもないので、僕が考えるときによく使っている「氷山モデル」を紹介します。
氷山モデルとは
氷山モデルとは、「学習する組織」という本の中に出てくる「システム思考」のフレームワークです。
ざっくり言うと、水面にちょっと出ている「できごと」だけを見て、物事を判断するのではなく、 水面下にある「行動パターン」「構造」「意識・無意識の前提」を捉えないと物事を見誤りますよという話です。
- できごと → 発生している事象
- 行動パターン → どういうパターンから事象が発生しているのか。
- 構造 → そのパターンを生んでいる構造は何か。
- 意識・無意識の前提(メンタルモデル) → その構造の意識的・無意識的な前提は何か。
正確な解説はこちらのページを御覧ください。 www.change-agent.jp
ちなみに、「学習する組織」の本は分厚くて難しいので、こちらの本がおすすめです。
- 作者:小田 理一郎
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2017/06/24
- メディア: 単行本
何か解決したい問題が発生したときに、この「氷山モデル」のフレームワークに当てはめて考えてみると割と考えやすかったりします。 いくつかの事例を見てみます。あくまでもフィクションです。
事例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
そこで、
組織として最低限満たすべき基準を、みんなで意識をあわすために「組織のベースライン」を引こう
という話をしました。
Aさんのケース
Aさんは、チームのみんなに技術的にもっと上を目指してほしいし、その方がもっと業務を効率的にできると思っています。 しかし、他のチームメンバーは、現状でも業務は回っているし、なぜそんなことをしないといけないのか伝わっていないのでしょう。 特にAさんは、技術的にもできる人なので、他のメンバーからは、Aさんが言っていることはだいぶレベルの高い理想論のように聞こえているかもしれません。 Aさんとしては、そんなにレベルの高いことを要求しているつもりもなく、チームとして「こうなって欲しい」ということを言っているだけなのですが、伝わりません。チームとしての最低限満たすべき基準(ベースライン)の認識が、みんなであっていないことから発生していると思いました。
Bさんのケース
Bさんのケースでは、いろんなレビューアが、それぞれの視点で指摘をしています。 レビューする時って、絶対的な正解があるというよりは、このケースでは、どのレベルまで引き上げるのかということが大事だと思っています。*3 しかし、このチームのレビューアたちは、指摘する際の基準である「どのレベルまで」ということが揃っていないので、「あれができていない」「これができていない」という指摘になってしまっているのかなと思いました。*4 つまり、このチームは、チームとして最低限満たすべき基準である「どのレベルまで」というところが、認識があっていないことから発生していると思いました。
Cさんのケース
Cさんのケースでは、チームでわからないことを自発的に勉強会で教え合う姿勢は、とても良いです。 しかし、チームとして、最低限満たすべき基準として、「最低限このくらいのスキルがないとこのチームではだめだよね。」というラインがないので、 初心者レベルから、「みんなでがんばろう」という感じの空気になってしまいます。それでみんががんばれば、まだいいのですが、 現状の自分のレベルと目標のレベルのギャップがないと、「がんばろう」という気にもならないかもしれません。 このケースも、やっぱり、最低限満たすべき基準である「このレベルのスキル」がないことから発生していると思いました。
どうやって組織のベースラインを引くのか
さて、組織として基準となるべきベースラインがないことからいろんな問題が発生していることがわかりました。 では、どうやってそのベースラインを作ったらいいのでしょうか。
結論から言うと「組織やチームによる」です。*5
自立意識の強いチームに対して、頭ごなしに押し付けても反発するでしょうし、逆に、まだまだジュニアなチームであれば、 自分たちからそのベースラインを作り出すことは難しいかもしれません。 だからこそ、その組織やチームをよく見ているエンジニアリングマネージャの力の見せ所なのです。 その組織やチームにあったやり方で、「組織のベースライン」を自分たちのものになるようにしていかなければいけません。
そういう自律的な基準を作れるようになることが、自己組織化の第一歩かもしれませんね。
まとめ
- 組織やチームが最低限満たすべきベースラインが決まっていないと、チームがバラバラになって弊害がおきてしまう
- そうならないために、 「組織のベースライン」を引こう。
- ただし、「組織のベースライン」が自分たちのものと思えないと、すぐ形骸化するよ。
おまけ
「組織のベースライン」という話をしていたのですが、スクラムの「Doneの定義」もある意味ではベースラインなのかなと思いました。 「Doneの定義」が、チームの成熟度に合わせて見直すように、「組織のベースライン」も組織の成熟度に合わせて、見直していかないといけませんね。
java8の開発環境をクラウド作る
開発環境
ローカルのPCに開発環境を作るといつの間にかバージョンが古くなっていたりするので、クラウド上の開発環境を利用してみます。 他にもいろいろあると思うけど、とりあえず
というのを使ってみる。
workspaceを作る
javaはテンプレートが用意されていないので、空のワークスペースを作る。
なんと右下のところに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のインストール
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はある。
というわけで、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
無事動きました。
アウトプットしたいアウトプットしたいアウトプットしたい
じゃー、さっさとしろよと言われそうなタイトルですが、アウトプットの手始めにブログを書こうかと思います。
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
- 作者: 中島聡
- 出版社/メーカー: 文響社
- 発売日: 2016/06/08
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
先日、元マイクロソフトの中嶋聡さんの「なぜ、あなたの仕事は終わらないのか」という本を読みました。
その中に
「評価恐怖症」のところでお話ししたように、100点の出来を追求しすぎると、自分の中でどんどん勝手にハードルが上がっていき、上司や顧客からの期待に応えられないのではないかという不安が増幅していきます。これではいつまで経っても仕事は終わりません。 すべての仕事は必ずやり直しになります。ですから、 70 点でも 80 点でもいいから、まずは形にしてしまうことから始めましょう。スマホアプリが延々とアップデートを繰り返している理由を考えてみてください。100点の仕事など存在しないのです。それよりも最速でいったん形にしてしまってから、余った時間でゆっくりと100点を目指して改良を続けるのが正しいのではないでしょうか。
という文章がありました。このことは、全くそうだよなと思いつつも、いざ、仕事になると、なかなか70点で形にすることは難しい。 かなり自分で意識をして、70点を目指さないと、形にできない。だからと言って、時間をかけても70点が80点になるくらいなのだけど。 もう1つ70点で形にすることのメリットは、フィードバックがもらえるということも大きいと思う。 自分が思っている100点のイメージと、実際に期待されている100点のイメージが異なる場合がある。 そういう場合は、70点の形を早く見せることによってフィードバックをもらうことが重要となる。
というわけで、ブログを書こうと思った時も、本当は、何か技術的なものを書きたいなと思ったのだけど、まずは、世の中に出すことが重要ということで、こんな内容で出してみる。
P.S. 今書いてる途中に画面遷移をしてしまって、書きかけの記事が消えてしまったかと思って超あせった。やっぱり、さっさと公開すべきだな。というわけで、ポチ。
あれ?
なんか使える。なんで?