耐えるコミュニケーションからの卒業
はじめに
マネージャーとして多くの人と仕事をし、メンバーが伸び悩んでしまうパターンに「耐えるコミュニケーションに陥る」例が少なからずあるなと感じていました。自社イベントで話す機会があったのですが、同内容をブログでもまとめておきます。あらかじめ断っておくとこれは特定の誰かを非難するものでは無く、多くの人がある特定の事象に関しては陥ってしまうことがあるように感じています。
耐えるコミュニケーションとは?
下記のように思い込んだ行動をとってしまうパターンを指しています。
- 相手の指摘にひたすら耐える。言われたことだけ対処する。
- 一定時間耐えたら次の段階に進めると思い込んでいる。
エンジニアだけに限らず、一般的な全ての業種で起き得るのではないでしょうか? 例えば個人的な経験では下記の事象で遭遇したことがあります。
- レビュー
- コード、アーキテクチャ
- 対外発表
- 学会、勉強会、カンファレンス、論文
- 会議資料
- 事業計画・ビジネスモデルなど
全体的に「答えがない」ものに対して起きがちではないでしょうか?個人的には前職の昇進試験論文がこのパターンにハマってしまいました。毎年試験時期が近づくと終わりのない書き直し練習を嫌がってやっていたのを思い出します。
なぜ耐えるパターンに陥ってしまうのか
直接的な原因は「期待するレベルと本人のレベルに一定以上の差があるから」だと思います。 間接的には「壁を乗り越え方がわからない」「答え・正解がないものに取り組んでいる」「受け手がこういうものだと観念してしまう」ことが引き金になっていると思います。 「自分はXXXに目を付けられているから邪魔されている」「どんな資料を作ってもイチャモンを付けられる」「提出日ギリギリまで直しが続く」とか、覚えがありますよね?
耐えている本人はいろいろと頑張ってはいるものの、耐えることが主目的になり近視眼的な対応・行動が増えます。 また指導をするメンバーも時間が取られ色々と疲れてしまいます。どちらも非効率です。
耐えるパターンから抜け出すにはどうしたらよいか
まずは耐えている本人に状況を理解させることから始めています。 「耐える」考え方をやめさせるために「一定以上のレベルに達したら終わる」ものであることをまず強調します。
つぎに一緒に伴走してあげます。自分でやり方を見つけて欲しいマネージャーの気持ちもわかりますが、「耐え」パターンに陥った人が自力で抜け出すのは困難です。プログラミグならペアプロ・モブプロをする、資料ならアウトライン・構成を一緒に考えるなどを行い、詰まっているポイントを理解し、助け舟を出してあげます。
最後に壁を登り切るまで見届けます。 途中で切り上げさせて別の機会に改めて取り組ませることもできますが、それだと成長はできておらず、問題の先送りにしかなっていません。 この手の問題は一度レベルを上げると下がることがないので、何度もチャレンジさせるより、一度登り切らせた方が効率が良いです。
おわりに
かなりあちこちで観測する事象だと思うのですが、良い名前がついていないために議論されることが少ないように感じています。 もっと良い名前を見つけた方はぜひ教えてください。
Re: 最高のScrumキメた後にスケールさせようとして混乱した話
www.slideshare.net
Regional Scrum Gathering Tokyo 2020の講演で「あの時こうしておけばよかった」という考えを教えて欲しいと講演で話されていたので自分の考えをまとめました。
事例・講演の概要
1チームスクラムでモバイルアプリの開発を行い、顧客の信頼を得てプロダクト開発は成功した。そこで顧客から運用・データ分析含め3チームをすべてスクラム開発へ移行したいという要望が出た。 スクラムマスターでアジャイルコーチの藤村さんは機能開発と運用のチームを合わせた15人1チームスクラムを行い、慣れたところでチーム分割を行いScrum of Scrumを行おうとした。 結果はチームは機能せず、元に近い形に戻すことになった。
私ならこうする
チームを混ぜた上で最初からチームを分割する。
チームの人数が多すぎると協力を引き出すことが難しいです。経験的には5〜7人が良さそうで、9人を超えるとチーム内からコミュニケーションの不満が出ます。 ミーティングが長い、誰が何をやっているのか分からない、開発効率が悪いというコメントがふりかえりで出てきたら分割の時期だと思っています。
チーム分割はメンバー同士の話し合いに委ねるやり方もありますが、私はメンバーが備えるスキルセット、性格などを考慮して慎重に決めています。
機能開発と運用が分かれているのは悪手
チームを分割するときは機能開発と運用のメンバーを均等に2チームに分け、運用チームそのものをなくします。 運用チームは負債を返し続けるだけのチームなので雰囲気は自然と悪くなりがちです。 また機能開発チームも自分たちの作った負債にきちんと向き合わせないといいアーキテクチャ・メンテナンスしやすいコード・運用しやすいシステムは得られないでしょう。
複数プロダクトオーナーがいる場合はチームを組んでもらう。
PO同士が話し合って優先順位を決めるのは難しいと思っています。 とはいえ代表者1人を決めることも難しいのであれば、チームを組んでもらいチームとして要望を出すことを依頼します。
いきなりLeSSを入れる。
上記を遵守しているとLeSSに限りなく近い形になります。なので人数が増えてチームを分ける必要があるだけならLeSSが1番労力が低いです。 LeSSをやるとチーム・ステークホルダーに言わなくても、スクラムイベントを2チーム同じ場所で一緒にやるだけでも効果が見込めます。
パフォーマンスが落ちることをチームメンバー、ステークホルダー全員に繰り返し伝える。
当たり前ですが人が増え、やり方が変わると学びや試行錯誤が必要なのでパフォーマンスが落ちます。 スケールを希望するステークホルダーにはこのことを十分に理解してもらう必要があります。 自分の場合2〜4スプリントかかることを織り込んでおり、これでも改善の見込みがなければやり方がまずいと考えなんらかの手をうちに行きます。
少しずつ増やす
メンバーの1/3が新しく入るのがギリギリ、1/2になるとうまくいくかどうかは賭けだと思っています。 増やす時は数だけでなく、業務の性質(toC/toB、リリース間隔、スキルセット)、メンバーの性格(前向きに新しいことに取り組む、分からないことを聞くことを恐れない)をかなりよく考えて決めるとよいです。
チーム数を増やすときは下記にそれぞれ壁があるのでメンバー・ステークホルダーと事前に話しておくと良いです。
- 1→2 : スケールの最小限。チームが対等にコミュニケーションを取り、タスクをこなせるか。
- 2→3〜8 : 1人のプロダクトオーナーの目が届く限界。チームが自律的に必要なコミュニケーションを取り、タスクをこなせるか。
- 8→N : 責任者が全員の顔を覚えられなくなるであろう限界。プロダクトオーナーも複数人で責務を分担する必要がある。
組織を見ることは悪いことではない。
反省に含まれていましたが、私は悪いことではないと思っています。 単一チームのことをいつまでも気にかけることはできず、2人目を見出し、育てて任せないといけないはずです。
いいスモールチームであっても自律的に連携しない
複数のスクラムチームを育てることと、それらが連携して1つの成果を出せるかは別問題であり、その解決のためにスケーリングアジャイルのフレームワークが存在していると認識しています。なのでチーム同士のコミュニケーションを律するなんらかの仕組みは必要だと思います。
おわりに
しくじりの反省としてでていた上記スライドですが、よく読むとスケールすることのメリットはちゃんと出ています。
- プロジェクト全体の俯瞰
- 作業の分担、余裕
- 属人化の解消、ペアプロ・モブプロ
今回はしくじり事例とのことでしたが、ぜひまたスケーリングにチャレンジして学びを共有して欲しいです。 今年もアジャイルのスケーリング一緒に悩んでいきましょう！
Regional Scrum Gathering Tokyo 2020に参加しました #RSGT2020
はじめに
去年に引き続いて2回目の参加です。今年はスポンサーとして参加してきました。 スポンサーから見た話は会社のブログに書いたのでここでは個人的なメモを残します。
聞いてきた話など
基調講演が最高！
Coplienさんの十牛図になぞらえたScrumの理解・説明はいろいろと考えるところがありました。「アジャイルの理解・実践の段階が進んでいればいい」という単純な話ではなく(「It is NOT good, it is NOT bad.」と何度も言っていました)、自分たちの現在地を知り、内なる声に耳を傾けて目的地を決め、日々改善を積み重ねていくしかないんだという指摘が、これからもまだまだやれることがあるのだと身に染みました。
Sahotaさんのアジャイルな組織におけるマネージャーの位置付けも、ここ1年の自分の実践(スクラム開発チームの外でサポート、プロセス改善・人材開発に注力)に近く、非常に納得感のあるものでした。自己管理チームを作ると自然と上が下を支える形に変わっていくのを日々感じています。
その他心に残った話
椎葉さんのスクラムチームにおけるTech Leadの役割も自分の考えに近く、非常に明快に言語化されていてためになりました。 「任せる時はコミットメントを信頼する。コミットメントは献身のことであり、結果ではない」、「相手が受け取った感情を否定しない。その原因に対処する」といった言葉は椎葉さんの思いやり・優しさ・凄みが滲み出ていて、今年も話が聞けてよかったと心から思いました。
TargetのDX変革のための教育場作りもロジックが整理されていて聞きやすかったです。「世の中に新しく生まれる仕事のうち、大卒で埋められるのは19%」という数字をつきつけられると、「足りない分は既存のメンバーを教育する必要がある」のは自明ですよね。「XXXできる人がいない、採用できない」と嘆くだけでなく、場を用意し成長に期待するのはいつだって必要な事だと再認識しました。
立ち話・ブースでの情報交換ができた
2回目の参加だからか、知り合いが増えてきたからか、セッション外での交流がたくさんでき、これだけでも参加に値するものでした。 聞かないと分からなかったような事例、非公開での情報交換のお願い、ワークショップの開催打診、お会いしたいと思っていた方々との繋がり。これができたのは運営の皆様に場をきちんと整えていただけたからだと感じています。
今年の感想
昨年転職し自分のチームは変わりましたが、去年の感想と変わらずアジャイルな開発/スクラム開発の実践が進められていたと再認識しました。 今年も一層の精進を目指し、日々の実践・コミュニティへの貢献をやっていきます。
まずはScrum Fest Sapporoにプロポーザルを出してみました。興味を持っていただけたらぜひ投票(リンク先に遷移→ログイン→プロポーザル表示にあるハートマークをクリック！)をお願いします。
#RSGT2020 を楽しむために
はじめに
いよいよ1/8(水)からRegional Scrum Gathering Tokyo 2020が始まります。 私も去年が初参加でしたが、今年も参加できることを楽しみにしています。
今年から会場が変わり、参加者数も増え、初めて参加される方も多いのだろうと予想しています。 自分も今年より楽しむために、去年知っていたらよかったなーと思ったことを思い出したので下記に紹介させていただきます。
アドバイス
タイムテーブルは印刷して持っていく
詳細スケジュールがConfengineで管理されていますが、スマホではタイムテーブルがうまく表示されず苦労しました。 昨年は会場にもタイムテーブルが印刷されていなかったので紙に印刷して持参すると何をみようか考えるときに役立つと思います。
大きめのカバンを持っていく
ストラップ付きの参加証に加え、記念品(昨年はビールグラスでした)、水・お茶、本、ブースでもらえるノベルティなどいろいろな配布物がありました。 ジャストサイズのカバンで行くと持ち帰りに苦労することになるので余裕を持っていくと良いと思います。
参加者に積極的に話しかける
初日の最後にネットワーキングパーティーがあります。 「初日に仲良くなってイベント盛り上がろうね」な位置付けだと思うのですが、初めて参加する人にとっては初日は仲良くなるきっかけが少なく、「旧知の人や同じ職場からきた人たちが集まってが飲み食いする場」になりがち(見えがち?)です。 一方通行で話を聞いて終わりのカンファレンスではなく、双方向に意見を交わしてよりよいやり方を模索するカンファレンスなので、普段の勉強会では他人と話さず帰宅してしまうあなたも、ぜひ積極的に話しかけてみてください。
また講演は発表時間ギリギリでQ&Aの時間が取れないものが多かった印象です。 なので疑問に思ったことは発表を終えて会場をうろうろしている講演者を捕まえて直接話しかけると良いです。 よくよく聞いてみると発表者の多くもフィードバックを期待しているそうです。
セッションに参加しなくてもよい
タイムテーブルをみてどれを選ぼうか考えてしまいがちですが、ピンとくるものがなければ講演を聞かず廊下にいる誰かと話を しても良いカンファレンスです。
講演者の言っていることが正解とは限らない。素直な気持ちで疑問をぶつけてみよう。
プロダクト開発は一つとして同じ事例がなく、唯一の正しいやり方があるものではないので講演者が言っていることが必ずしも正しいということはありません。 去年は基調講演でChris Lucian氏が「no estimates(見積もりしない)」を提唱していましたが、それに疑問を持った参加者が3日目の議論の場で「見積もりの良い点を議論しよう」と言っていました。それを受けてChris Lucian氏も「no estimateを参加者と話したい」と議題を挙げていました。誰かの発表を受けて議論があちこちで始まるそんなライブ感のあるカンファレンスです。
今年は大崎ではなく御茶ノ水です！
うっかり大崎に行かないようにしましょう。
ジョブボードを活用しよう(追記)
アジャイルな職場を探している人・アジャイルな人材を探している人向けにジョブボードがあります。 実際に転職に繋がる事例もあるので是非活用しましょう。
See also
去年の参加振り返り記事
他の方が書いたRSGTの楽しみ方
Engineering ManagerはManagerでしょ
この記事はEngineering Manager Advent Calendar 2019 20日目の記事です。
はじめに
他のEngineering Managerの方とお話しすると「技術」「プロセス」「組織」「育成」といった様々な悩みを聞きます。 ですが名前に"Manager"と入っている以上、組織の中間管理職の1つのはずです。 マネージャーとしての振る舞いが議論の俎上に上がることが少ない気がしたので、普段自分が気をつけていることを3つほど紹介します。
〇〇申請忘れられがち
勤怠承認・経費申請・利用申請などなど、ヒト・モノ・カネを預かるマネージャーには何かと承認作業が求められがちです。 溜めがち・サボりがち・忘れがちなのはエンジニアに限らない傾向なのかもしれませんが、ただ諦めていませんか? メンバーに何度も催促することは基本ですが、他にも工夫する余地はありませんか?
例えば「○○さんがリモート退勤1分後に勤怠時刻修正を送ってきてくれました 最高！」といったことを、皆が見えるSlackチャンネルに投稿したところ、リモーワーク時の勤怠申請をまめに送るメンバーが増えました。
また先月末の勤怠承認締め日前にはこんなメッセージをSlackに投稿したりしました。手を変え、品を変え、協力を促す努力はするべきだと思います。
ルールを文章化し、守って欲しいことを伝える
メンバーにはチームを組んで開発に取り組んでもらっていますが、中にはリモートで稼働する人もいます。 リモートワークでの業務効率を高めるため、「全員リモートワークを経験し、課題を議論しよう」という取り組みを、メンバーが自主的に始めてくれたことがありました。
マネージャーの自分抜きで改善を始めてくれたことは大変嬉しかったものの。会社としてはリモートワークは上長の許可の元行うルールになっており、リモートワークを積極的に推進している訳でもなかったのでルールと目的を改めて明示しておく必要があるなと感じ、下記のメッセージをSlackに投稿しました。
ルールや考えは口頭でつたえるだけでなく、都度皆が見える場で共有することが大事だし、自由な取り組みをしてもらうにもここだけは守って欲しいという境界を明確にしておくことは重要だと考えています。
見本となる動きをする
できていない人に注意・助言されても聞かないと思っています。 なので自分がやって欲しいなと思っていることは率先して取り組んでいます。
- 時間を守る
- 遅刻しそうなら早めに連絡する。
- 会議は時間になったら始めて、遅れる人を待たない。
- 日頃からインプットする
- 本を買う、本を読む
- 役に立つ情報を共有する。
- 日頃からアウトプットする
- ブログを書く。
- 登壇しにいく。
おわりに
「エンジニア相手だから」という先入観を捨て、マネージャーとしての当たり前の振る舞いを積み上げた先に「いいEngineering Managerのあり方」があるのではないでしょうか。
Scaled Agile with Jim Coplien に行ってきました
はじめに
TACO(Tokyo Agile COmmunity)主催の勉強会に行ってきました。
すでにまとめてくださった方もいますが、自分の言葉でまとめ直しておくことが大事かと思い、当日のメモを整理してみました。
- 知り合いを6人辿れば、世界80億人と繋がれるのに、組織内のコミュニケーションに6人以上必要なのは、おかしくない？ #TACO - 名前考えるの苦手
- 組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論 - kawaguti’s diary
Coplien氏の講演内容
"Scaled Agile"の勉強会なので、最初に参加者の取り組み状況を挙手で聞いていました。
- 1チームスクラム：会場の1/3〜1/2ぐらい→20〜30人ぐらいかな?
- LeSS：私を入れて2名だったはず。CopeはLeSS嫌いだったがLeSS考案者に"convinced"されたと言っていました。
- SAFe：何人か手を挙げていたのかも。Cope曰く"SAFeはアジャイルでない"
- Scrum@Scale：10人位か、ここ最近醸し出している「オフィシャル感」から広まっている印象。
次にCopeは「なぜスケール」を考えなければならないかについて疑問を投げかけました。 「作りたいものがたくさんあるから」というのは良く聞く理由の一つですが、人々は大きなプロダクトになるほどその使い方を知りません。 作った機能の大半が使われていないというのはソフトウェアエンジニアであれば一度は聞いたことがある話だと思います。 また開発員が増えるとプロダクトはその分良くなるのでしょうか? Coplien氏はSkypeを例に挙げていましたが、増えたエンジニアの数に見合う価値が上がったかと言うと疑問に思う方が多いでしょう。 ソフトウェア開発は1人のエンジニアがレバレッジを効かせてアウトプットを出すことができる業種です。 それなのに何故カイゼンを続けたり、スケールを考える必要があるのでしょうか?
スケールさせるとコミュニケーションコストが生じることは明らかです。 「組織の構成員が増えたからコミュニケーションコストを抑えて生産性を上げなければならない」と言う理屈もあるかもしれません。 しかしある調査結果では組織のアウトプットは構成員の人数に比例していたそうです。 したがって「組織の構成員が増えたからコミュニケーションコストを抑えて生産性を上げなければならない」と言う課題は実は存在しないことになります。
ジェフ・サザーランドはScrum@Scaleをフラクタルに設計しましたが、チームの代表者を介してコミュニケーションを行うやり方は軍隊のやり方に似ています。 5名チームのScrum@Scaleを4階層で組むと625人が参加することになり、チーム同士が会話するのに必要なコミュニケーションパスは平均7.6人となるそうです。 世界中の人と6人介すれば繋がることができる六次の隔たりという理論もあるのに、組織内で7.6人を介するコミュニケーション設計はどこかおかしいのではないでしょうか。
ではこのような環境で人はどう問題を解決するかと言うと、ハブを作り特定の誰か・専門家を介して短く繋がります。 Spotifyモデルだとギルド、LeSSだとコミュニティがこれに当たると思います。
ハブがあることでコミュニケーションが最適化できます。 限られた人がたくさんの人と繋がり、ハブとなっている構成をスケールフリーネットワークと呼びます。 Coplien氏はスケーフリーネットワークの例として学術論文を挙げていました。確かに多くの論文が限られた数の論文を引用しており、その形はスケーフルリーネットワークと言えます。 ハブがあることでコミュニケーションがやりやすくなり、フィードバックをすぐにもらえることからアジャイルに物事を進められるようになります。 マネージャーやアーキテクトといった役割は組織の自然なハブになります。 しかしアジャイルな開発を目指し、上記の役割を人から取り上げてしまうとハブが消え、フィードバックを得る機会が失われてしまいます。
やり方をカイゼンしていくには自らの常識に従うことが重要です。 「Scrum@Scaleでこう決められているから」、「集まるのは大変だからハブをツール化(例えばConfluence)しよう」としてはいけません。
Coplien氏は講演の最後をこの言葉で締め括りました。
Small is beautiful
おわりに
終わってからも色々と考えさせられる講演でした。 「スケールは基本的に良くないこと」という前提に対し、プロダクトが大きいからチームを大きくしなければならないと質問した人方がいましたが、Coplien氏はこれに「リリースしたらユーザーをよく観察しろ」と回答していました。短絡的に人員を増やして対応するのではなく、ユーザーを良く観察し、何が価値を提供するのかを良く見極め、そしてそこに注力する。小さく開発を続けることにいつか限界が来ると思うのですが、それでも自らの常識に照らし合わせて考え、シンプルなやり方を追求していく必要がある。私にはそんなメッセージに受け取れました。
レガシー感謝の日2019で「おくりびと」を話してきました
はじめに
「レガシー感謝の日」という勉強会のタイトルに惹かれて参加 & 発表してきました。 弊社のレガシー、「Retty本体」を紹介できて大変満足しております。
Twitterでいただいたコメント抜粋
#レガシー感謝の日で参照できます。あるある話なのか自社も同じようなことがあるという声が多いのだと感じました。
「Retty本体」って呼び方。なんか弊社にも似たようなものが、う、頭が… #レガシー感謝の日
— のりぃ (@m_norii) November 22, 2019
リファクタ誰が手を上げてやるか問題…( ˘ω˘) #レガシー感謝の日
— [¥199,889]にしこりさぶろ〜 (@subroh_0508) November 22, 2019
issuesやPRが残るのはやっぱりあるあるなんかな。この前私も提案してissues棚卸し会したけど... #レガシー感謝の日
— 名無しのRubyちゃん (@rubbby_chan) November 22, 2019
誰も知らない画面は生成されがち( ˘ω˘) #レガシー感謝の日
— [¥199,889]にしこりさぶろ〜 (@subroh_0508) November 22, 2019
御社は弊社か、という内容だなｗ #レガシー感謝の日
— のりぃ (@m_norii) November 22, 2019
その他
ハンズラボさんのユニケージ開発手法がいろいろな意味で面白かったです。
ありがとうございました。
— あさひな (@chickAM7) November 22, 2019
ちょっと社の闇を吐きすぎたので公開はできないのですが活動模様やユニケージについては発信してるのでよければのぞいてくださいhttps://t.co/S8seMWFp65https://t.co/sQDZD0Et65https://t.co/Gj9B3dB9lI#レガシー感謝の日
びっくりポイント
