FY21のふりかえり
振り返りを書きたいなと思ったものの、実は昨年7月にすでにふりかえりをしていたので、今期のふりかえりってことにしたく思います。
スタートと新たな発見
自分の中では変化が大きく、ついふりかえりをしたくなっちゃう期でした。
前期の終盤に、1年間ほどの長い観察・対話の時間をかけてLeSSを導入し、今期は主に今までとは畑違いの、開発チームがなく、ウォーターフォールで業務を行う組織で色々やっていました。
開発チームが進化を続ける中、自分は得意分野ではないかつ未経験の職域の課題解決に着手していて、かつ、改善の進みが自分の感覚としてはスローペース*1で、正直序盤は「つまらないな」「この仕事は自分のためになるのかな」「早く終わらせたいな」と思っていました。
という話は先日のRSGT2022での登壇のどうでも良い裏話として。
そんな気持ちが徐々に変わってきて、今では「自分の中でここまでと決めたラインが自分の中にあって、それを超えても意外とできることがある」とか思ってしまったり、興味関心の幅が広がったりしました。
開発チームの進化
開発チームは、課題はたくさんあるけれど、劇的に進化をしています。素敵。
今期、自分視点で開発チームが一番変わったことは、クロスファンクショナルチームになったことによるセクショナリズムからの開放かなと思っています。もともと、とても対立が多かったとかではないですが、ブラックボックスだったところ（あえてではなく、言う機会がなかったのも含め）を広げあうようになり、自ずとセクションの境界線を越えようとする人が増えているように感じます。
先日、ひとりのメンバーから急に相談があると言われて話してきたら「あなたには何ができて、何を相談したら良い？」と聞かれて、こういうのはチームで話せば良くね？こういうのはSMやPOと相談したら良くね？と話していたら「ああ、じゃあいっしーさんとは相談することないですし、いっしーさんがいなくてもチームが良い感じに回ってたんですね。もう相談することはないと思います。」って言われて。笑
スクラムチームの人から初めて「いっしーがいなくてもうまく回りますね。」って言われて、自分の仕事を適切に滅することができているなと嬉しくなった（ちょっと寂しいけどｗ
— いっしー🐱 (@oturu333) 2022年1月11日
「えっ。たまに思い出したら来てよ。寂しいじゃん。」と言ったら「自分は相談相手をちゃんと見極められるんでたぶん相談しないです。」と言われてしまったのですが、こういう話自体も、急に呼び出されることも以前では考えられなかったので、おもしろい変化だなーと思っています。
今期のチャレンジ
仕事のタスクとは別に、今期はアウトプットを少し頑張りました。ブログは書いていないが。
スクラムフェス大阪2021、CEDEC2021、RSGT2022にて登壇させていただきました。
あと ひろみつ (@hiromitsuuuuu) | Twitter と一緒に、furoshiki.fm という Podcast をはじめました。特にテーマを決めきらず、興味のあること、話したいことを話す場ですが、お互いのジャンル的にアジャイルや組織の話が多いです。
ひろみつファンのみなさま、ぜひ聞いていただければ幸いです。
Podcastはただただ楽しい。なぜ始めたのかとかは、もう忘れてしまった(´・ω・｀)
また、登壇は永遠に慣れないと思いますが、アウトプットをすることでインプット意欲にもなるので、今後もほそぼそと続けていく所存です。
また、この登壇は自分のため、会社のためというのはありつつ、裏目標は自社から登壇をしてくれる人を増やすことだったのですが、それは達成できそうで嬉しい！
来期の目標
興味関心の幅が広がった一方、逆に興味関心を失った分野もあり、自分がわくわくする場所は今後どこにあるんだろう？をあらためて探していきたいと思っています。
わたしは自由や！囚われずに生きていくぞ！いええええええい！
その他細やかな目標 🌼
- お引越しをして部屋をきれいにする(´・ω・｀)ｷﾋﾞｼｲ
- もう少し自炊する(´・ω・｀)ｷﾋﾞｼｲ
- 在宅環境をアップデートする
- デスクの拡張とマイクの導入
- 2匹目のおねこ様をお迎えいたす
- おねこ様の遊び場を拡張する
ねこ
今期はスクラムフェス大阪2021に参加もした、成長意欲の高いねこちゃんです。
大きくなりました。まいにちかわいい。ベンガルなのにスコ座りをします。
ねこちゃんの今年の進化は、ちゅーるを食べられるようになったことです！以前はちゅーるを食べると血便していたのでやめていたのですが、なぜか食べれるようになりました。ねこ、ほんとうに分からない。
*1:現場が忙しいため
現職エントリーというか、日記
アカツキに入社して1年半経ちました
アカツキでのEMのミッションはいくつかあるのですが、特に力を入れていたのは組織課題の解決とアジャイル開発の推進かなと思います。
アウトカムはもとよりアウトプットを出すまでにも時間がかかり、ちゃんとまとめるのも大変だったので現職エントリーも書かずにいましたが、最近、スクラムフェス大阪2021にて登壇をしてきて1つの区切りができました。
自分の発表はこちらです。スクラムマスダーさんと一緒に登壇させていただきました。
転職してから
組織課題という抽象度も難易度も高いところを、おそらくこれまでで一番、良い意味で放任してもらって（適切に言うと、信頼して任せてもらって）動いています。
過去未経験の大きい組織でしたが、魅力的な人が多い現場で、ワイワイガヤガヤ楽しんでいます。
LeSSを導入してからは特に、SMを筆頭にみんなが勝手に良い方向に動いてくれているので、登壇資料で語ったような内容で自分がやることは、既にほぼなくなってしまいました👏
ということで、直近のお仕事としては、さて次の課題に向き合いましょうというところです。
チャレンジ精神で、入社を決めた
思い返せば、アカツキに入社を決めたのは、ゆのんさんの存在と、自分の苦手や未経験へのチャレンジ精神でした。
以前はB2B・小さい会社や組織というところから、B2C（かつ、ゲーム）・大規模組織という大きな変化へのチャレンジです。
実は、入社前は大企業、大規模組織というところに苦手意識がありました。
何かを進めるのに事前のネゴシエーションが必要だとか、解決するのに時間がかかるとか、そういうのが苦手だったんです。
今は、この組織にとってどういう状態になっているのが良いのかを、少し冷静に考えられるようになってきたかなと思います。
また、過去は本当の意味で人を信じていなかったのかなと思います。だから今すぐ、自分が何とかせねばという気持ちが強かった。
最近
一緒に仕事をする方に、以下の3問のアンケートを取ってみました。
1. 私の良いところを3つ教えてください
・人当たりが良く、話しやすい ・ロジカルに物事を考えることができ、話に納得感がある ・視野が広く、話していて観点を学ぶことができる
やりきる意思がある、客観的に見る、我慢強い
たくさんあるんだけど、あえて３つでいうなら、①ドライブ力 ②論理的思考力 ③課題発見力 かなと思った。
・問題解決のための前向きな提案をする ・社内のLTとか社外発表とか情報発信力が高い ・よく笑う
パワフル、FBくれる、物事の本質に向き合う
多角的にみれる、推進力がある、勉強家
・因果関係を重視するといった論理的なところ ・歴の長いメンバーにも臆せず話に行ける胆力があるところ ・新しいことに対して柔軟に取り組めるところ
2. 最近で私があなたの役に立てたことを教えてください
わりと大きな話題でアレもコレもとなってしまっているときに、「論点の切り分け」をしてくれるのが助かってます。
組織の課題を共有してくれたこと / 猫のおすすめ商品を教えてくれたこと
課題整理を一緒に進めてくれたり、自分がやろうとしていることで視点が足りいていないところに関してヒントをくれる（どんな課題があるのか？、仮説立ててみよう！とか）
体制を変えてみようという動き
最近って感じではないですが、1on1やSlackでコミュニケーションとってる事自体、僕の中では、めちゃくちゃ助かってます！
3. 私が好きそうだな、楽しそうだなと思うことを教えて下さい
・仕事が楽しそう ・知見の蓄積が楽しそう ・お酒 + おいしいものが好きそう ・人と関わっていることが好きそう
何か説明をすることとその準備
ねこ
猫トーク
みんなでワイワイディスカッションすること
酒と猫
酒と猫、最高ですね( ´ ▽ ` )ﾉ
そして褒めすぎなんですけどね（褒めさせておいて…ｗ）。みんなありがとう〜
そして突然ですが、アカツキに入って組織課題の解決とは別に、人の成長をサポートするって何ができるんだろうとずっと手探りをしていました。
これまでそんなに個人との向き合いを重視しておらず、チームと向き合っていれば、チームが良くなっていくし、勝手に成長していくし、1on1って特別いらないのでは？くらいに考えていた人です。
大きな組織というのがあるのか、リモートの影響もあるのか、自分の視点が変わったのか、最近は1on1での個人との向き合い方はすごく大事なんだなと思っています。
困っている人にどこまで手助けをすべきなのか、というか、何をすべきなのか、毎回悩みつつお話をしています。
課題に思っている人には、どうやって解決できそうか一緒に考えてみたりしているんですが「あぁ〜。絶対一言多かった〜」と思うことも多いし、難しいですね。
そして、課題に思うことはないよ！と言われると、ハテサテドウシヨウ、何もしなくて良いのかな大丈夫かな、と思うのが現在の立ち位置です。
どうしたら人はより成長できるんだろうな。そのために自分にできることはあるのかな。
最近は、自分がどんな人間か、たとえばどんなことが得意、好き、楽しい、苦手などを知ることが、成長や変化のきっかけになるのかなと思っていた。
— いっしー🐱 (@oturu333) 2021年6月26日
けど、そもそも成長や変化をしたいと思えないならできないよな。
成長や変化をしたいと思うということは、
話は戻って、最近1on1をしていて「自分が好きなこととか、思考が分かって、行動を変えようと思った。石毛さんにはそれを伝えようと思った」と言う人がいました（私との会話とは関係ないところで気づいたという話）。
自分のことややりたいこと、好きなことを理解すると、それを成し遂げるためにどうしたら良いかを考えられるから、変化のきっかけになるんだろうなと思った。
つまり、自分が誰かに何かをできるかも、ということ自体がもしかしたらおこがましくて
でも、誠実に向き合おうとしていると、もしかしたらこういう瞬間に出くわすかもしれない。分からない。
アカツキではわくわくすることを自分で探そうという文化があって、「わくわく」というと「宗教〜」って思う人もいるかもしれないですが、わくわくすることを自分で認識する、自分のことを認識するって結構難しいんですよね。自分を理解することは、他人を理解することより難しいそうですし。
ということでさらに話は戻ってアンケートをしてみたり、私自身も、自分をもっと理解してみようということをしています。
オチがない話になってしまった。
直近の話
入社後、ずっと潜っていましたが、一区切りついたタイミングで登壇をちょこちょこする予定です。
あと、アウトプットを増やしていこうと思っていて、ゆるゆるPodcastを始める予定です。タイトルと決めセリフから決めるスタイルです。さて、決めセリフはかっこよく決まるのか！ ？
とりあえずタイトルとキメ台詞を考えている
— いっしー🐱 (@oturu333) 2021年6月30日
界隈のお友達も増えたら嬉しいなーと思っているので、ぜひお声をかけていただけるとうれしいですmm
大規模組織でLeSSの再導入をしています
スクラムが好きです。ここ数年、スクラムをよく知らないけどスクラムイベントをやっているという現場でスクラムを再導入するということに向き合ってきました（よくよく考えると不思議な縁だなと思ったのですが、よくあることなのでしょうか）。
今まさにそろそろ始めるぞ！というタイミングなので、始めるまでにやったこと、考えたことをまとめていきます。
現在の現場ではスマートフォンゲーム開発をしており、組織規模は大きめです。エンジニアはスクラムチームが複数作れる人数、ディレクターが複数人いて、デザイナーは少なめ、QAチームがたくさんというチーム構成です。PMやEMも複数人います。スクラムを知ってる？と聞くと「なんとなく知ってる」「聞いたことはある」が若干名。
プロローグ
状況把握
弊社のEMは組織課題の解決やアジャイルな開発プロセスの導入が含まれています。
まずは現在どのような状態を把握するためにヒアリングから。
把握した現在の体制、プロセス
- ロードマップを引いた数ヶ月ごとのリリース
- バージョンチーム（リリース単位で実装、テストに関わるメンバーを定める）が組成され、PJTの進捗状況により増減員しつつ、リリース後に解体される。複数のバージョンチームに携わるメンバーがいる
- 開発完了後検証を開始する
- 進捗はガントチャートで管理し、朝会でガントチャートを確認
- スクラムイベントを行っているが、バージョンチーム、セクションチームでスクラムイベントが混在（下図。朝会、夕会が抜けている）。
現場からの課題感
- MTG（スクラムイベント）が形骸化
- 複数のバージョンチームにまたがるメンバーがいるため、朝会や夕会だけでで1時間弱かかり、プランニングも時差で行う必要がある
- 振り返り〜プランニングの間に1日ある
- スケジュール管理や進捗確認が大変
- プロジェクトの後半になって進捗の遅れが判明する
- 進捗の遅れの原因が分からず、解決策の妥当性も分からない
- 振り返りがあまり意味を出せない
- チームの一体感が少ない。より主体性を促したい
さて、どうしましょ
各メンバーと1on1をして課題を聞き、各種イベントに何度か出た時点で、ちゃんとLeSSをやっていこうという方向性はEM内ですぐに合意できた（入社から10日くらい）。しかし、入社後すぐ大規模な組織を相手に「課題があるから体制とプロセスを変えるぞ〜〜」とはならないし、理解・共感をしてもらえるための時間と信頼を得るための対話を大事にしようと考えました。
理解・共感を得ようとしたのは「学習する組織」の
人は変化に抵抗するのではない。変化させられることに抵抗するのだ
という言葉があるように、自分たちでそうなりたいと少しでも感じてもらうためと、理解せずに導入しても形骸化してしまうからです。
導入ステップ1. 理解、共感
LeSS導入に至る背景をLTで伝えた
チーム全体に対して週次でLTを実施。LTは2部制で、LTを完走すると AsIs ToBe が埋まるようなコンテンツにしました。
- 第一部 認識を揃える（チームとしてありたい姿、効率的な仕事の仕方）
- 第二部 具体的にやること（LeSS）
第一部ではHRT、心理的安全、自己組織化など全15回*1ほど行いました。
LTでお世話になった書籍
1セクションでスクラムをやってみた
エンジニアのみのチームでスクラムイベントの改善を試みてみました。当初予定していなかったのですが、チームの中で「振り返りを改善したい」という声があったからです。そこでプランニング、スプリントレトロスペクティブを少しずつ変えていきました。セクションチームでスクラムをやってみようとすると、以下のような問題にぶつかります。
- 要求が不明瞭だが確認するPOがいない
- セクションを越えた課題の解決コストが高い
- セクションを越えて業務の流れを整理したり、完了の定義を定めづらい
- 上記のような状態のときにリーダーがハブになり別の場所で解決する必要がある（イベントが止まる）
「クロスファンクショナルなチームになったほうが良い」という声が聞けました。
導入ステップ2. 輪読会や勉強
有志で輪読会や勉強を行いました。読書リスト。SMは必須。
www.amazon.co.jpwww.amazon.co.jp
www.amazon.co.jp
www.amazon.co.jp
導入ステップ3. 組織への適応を考える
自チームへの適応で難しかったのは、組織規模の大きさ、Epicの大きさです。またPBIもリリース可能な単位とするととても大きくなってしまいます。
体制
通常のLeSSの体制は以下のような体制ですが、自チームでは企画を考える（PBIを作る）メンバーが複数名いること、彼らと一緒に企画を考えるデザイナーが複数名いることがありました。
また、LeSS Hugeの形は適していない（Areaが固定できない）という事情があり、POのプロダクトバックログを作成する作業を委譲する形でEPO（Epic Product Owner）というポジションを作ることにしました。全体構造が以下の図です*2。
ロールと責任範囲
RACI図でまとめました。フラットな構成の中でボールが落ちることやコミュニケーションロスを防ぐために役立ってくれるはず。
計画づくりと進捗把握
PBIを相対見積もりし、以下の記事を参考にプロジェクトバッファを算出、CCPMのバッファ消費率を用いてプロジェクトの状況を把握します。その他、タスク管理ツールのバーンダウン（スプリント、バージョン）も参照します。「10秒あれば誰でもPJTの状況が分かり、POが判断可能な状態」を目指します。
なぜ LeSS の再導入を推進したのか
能力の高い人が集まったチームや組織であっても、 体制や仕事のやり方よっては1+1が2にも満たない状態になってしまいます。メンバーには主体性を持って、プロダクトゴールのために行動できる自立した人でいてほしいし、ユーザーに価値を提供し続けられるチームでありたいです。私は、メンバーが自分の魅力や能力を発揮しやすい基礎を作ることもEMとして大事な責務だと考えているのです。ここから先を彩っていくのはメンバーが主体的にやっていってくれるでしょう。私は彼ら彼女らをサポートしていきたいと思います。
あとがき
メンバーが感じている課題からLeSSの再導入は適当（チームの固定化、クロスファンクショナルなチーム設計、テストのシフトレフト、イテレーティブでインクリメンタルなアプローチ）だと考えたのですが、体制を考えるのが当初考えていたよりも苦戦しました。
過去B2B Webサービスでスクラムをやってきました。〇〇業界だから、こんなプロダクトだからスクラムができる / できない / 適している / 適していないということはありません。どういうチームでありたいか、どのようにユーザーに価値を届けていきたいか、その先にスクラムやLeSSがあるかないかという話なだけです。
続きを読む
エンジニアリングマネージャーをやめかけ、フリーランス武者修行して復活した1年ちょっとの振り返り
会社員を辞め、フリーランスエンジニアリングマネージャーとして武者修行した1年ちょっとの出来事、自分で感じた変化を忘備録として残そうかなと思います。
エンジニアもエンジニアリングマネージャーもやめようとしていた
2018年2月、私はエンジニアリングマネージャーをしていた会社をやめようと決めた。仕掛中の大きめのPJTが終わったらやめる意思を、思い立ったが吉日ということですぐ、リリース後のバタバタが落ち着いたらやめたいと上司に伝えた。そして7月にリリースを終え、8月で退職した。やめた理由はPJTがしいんどいとかではなかった。あのときは精神崩壊を何度か経験したけれど、自分やチームでやるべきだ！やりたい！と言ったことだったので、とても楽しかった*1。松岡さんから差し入れで頂いたケーキはとても感動して、こんな粋なことができる大人になりたいと思っている。
実は、2018年2月の時点ではエンジニアもエンジニアリングマネージャーもやめようと思っていた。私は当時ストレングスファインダーで最上志向が一番強かった。だからか、上記のPJTのような課題提起はやりたいしできるし好きだけれども、エンジニアとして本来一番大事であろう学習欲が全然なかった。マネージャーとして頭にインプットしていたのは「組織の三要素」だけで、あとは周りの人たちを教師および反面教師にしてがむしゃらにやっていただけだった。それでもそれなりと頑張っていたとは思うけれど、今考えれば無茶苦茶だなぁと思う。それなのに、一緒に頑張ってくれたメンバーに「あなたがマネージャーで良かった」なんて言われたりしてすごく嬉しかった。感謝しかない。
当時、私にエンジニアリングマネージャーとして秀でた強みはないし、慣れ親しんだ組織とプロダクトだからギリギリなんとかなっていると思っていた。つまり、私が出来ていることは再現性がないと考えていた。そして、学習意欲が低いならずっとエンジニアとして生きていくのはしんどくなっていくだろうと思っていた。あとはエンジニアやエンジニアリングマネージャーという仕事を今後もやっていけるか自信もなかった*2。くわえて、メンバーの1人と色々あって、心底凹んだりもした。エンジニアリングマネージャーになったことをきっかけに組織作りには関心があったので、エンジニアとしてのバックボーンを生かせて組織作りに携われる仕事、人事にジョブチェンジしようとしていた。
その後人事として内定をいただいたのだが、ちょうど同じ頃に業務委託として一緒に働かないか？とお声かけいただいた*3。アウトサイダーという立場でエンジニアリングマネージャーをするという内容だった。人事にジョブチェンジをしようと考えていたが若干迷いも持っていた私に「やるべきこと（上のPJTのこと）をやるべきだと言える人も、やりきれる人も少ない。CTO目指してみたら？一緒に仕事してみない？」ということを言っていただけた*4。マネージャーとしての自分を嬉しい言葉で評価してもらったのは、これが初めてだった。また、私が前職で課題だと思っていたけど解決できなかったことをお話し、コーチングしていただいた。するすると自分ができていなかったことを認識できた。コーチングを知らなかったので、ものすごくびっくりした。そして、この人のスキルを奪いたい、一緒に仕事したい、エンジニアリングマネージャーとして他の組織でも通用できるのかラストチャンスで試してみたいと思った。そして、2018年9月にフリーランスデビューを果たした。内定を頂いていた会社さまには申し訳ありませんでした。。
本を読むようになった。きっかけは「人の10倍勉強しなさい」
私は学習欲がなかったため、本も継続的に読んでなかった。だからまずは本をたくさん読んだほうが良いと教えていただいた。最初の1ヶ月くらいは1日1冊読んで、要点をまとめるブログを書いていた*5。
以前は、本を読むのが心底嫌だった*6。理由は、ただひたすらに面倒くさいから。まず選ぶのが面倒くさい。書いてあることを暗記しなきゃ、お金の分だけバリューを出さないととか、考えるのが面倒くさい。あとお金がかかる。
そんな人間が多少なりとでも本を読めるようになったのは、以下のようなアドバイスをいただいたからだ。
- 本に書いてあることを全部覚えようとか身構える必要はない。1つでも学べることがあればそれで良いし、さらっと読んでつまらなければやめれば良い
- 課題に直面したときに知識を仕入れるのと、事前に知識があって選択肢を持てる状態だとどっちが良い？
- 今まで勉強してこなかったんだから、これから人の10倍勉強するつもりでいなさい
- フリーランスは経費で本が買える
本を読むようになって、自身が今まで再現性がないと思っていたことを沢山の人が言語化していて、そして逆を言えば、私は言語化ができないから再現性がないと思っていたことに気づいた。再現性を得られるなら、どこでもエンジニアリングマネージャーできる！と思った。また、同じ事象に対して異なる視点から捉えることの癖がついた。
余談ですが、福利厚生で上限なく本が買える会社さんは素敵ですよね。それだけで読書（学び）のハードルがだいぶ下がります。
アウトプットをはじめた
上記で触れた言語化能力を上げるため、アウトプットを始めた。
- 鍵をつけてたTwitterを開放
- ここでのブログ記事
- 読書記録のブログ
- 「エンジニアの成長を応援する本」への寄稿*7
言うほどできていないが、まずは書くことへの抵抗がなくなったのと、自分の抽象化、言語化能力の低さを実感できたのは良いことだと思っている。
アウトサイダーのエンジニアリングマネージャー？できるの？
「フリーランスでエンジニアリングマネージャーをやってます」と言うと、エンジニアリングマネージャーをやっている人は大体「？」という顔をします。変ですよね。私もそう思います。
フリーランス時代に書いたブログは以下のようなものです。
どんな立場であろうとエンジニアリングマネージャーとして求められることは変わらないと思っていましたが、大きくことなるのは同じ会社の人間ではないし、ましてや上司や評価者でもないということだと思います。
それにより、以下のようなことが発生します。
- 社内情報にアクセスしづらい
- エンジニア部門ではない人からは知られていない、コミュニケーション手段がない（名前分からない、メールやチャットなどでの連絡手段がない）
- エンジニアリングマネージャーというロールではなく、社員という立場にのみ与えられる権限、情報がある
- 立場による鶴の一声戦法が一切使えない
まとめると情報が足りない、影響力がない、むしろ知られてすらいない、ズルが出来ない。3つ目に関してはロールで権限と責任と情報は統一したい（社外秘を除く）とネゴってみたものの、既存のやり方を変えるのはなかなか難しかったという印象です。
情報がないから、必死に取りに行く必要がある。人を知らない、知られていないから積極的にコミュニケーションを取る必要がある。影響力がないから、持てるように努力する、成果を出す必要がある。個人としても、チームでやることも強い共感を集める必要がある。要するに社員のときはする必要がなかった（あるいはもっと楽にできた）努力をする必要があった。
私はこの状況を制約のあるゲームみたいなものと言っていた。自分で縛りをつけてゲームをしたほうが燃える属性の人って一定いますよね。あえてこの武器でボスを倒すとか、連れて行くキャラのレベルに上限制限をつけるとか。私はそうではなくさっさと先に進みたい属性なのでゲーム世界ではやったことがないですが、リアルにおける制約ゲームは良い経験でした。自分がエンジニアリングマネージャーをする上で必要なものは何かをあらためて知ることができ、基礎練からやり直した感覚があるからです。制約のあるゲームは、プレイヤースキルを上げる！（マネージャーだけど）そして、そのような状況でやりとげたことは、大きな自信になった。
一方で「上司だったら言えなかった」と言われたことがあり、それは少し悲しかった。今後会社員に戻るので、そういう人もいるのかな。
つらくない？と言われたことがありますが、結構大変です。でも、刺激的な体験をさせていただけました。
個人へのアプローチを封じた
いきなり1on1など対個人マネジメントがフィーチャーされていましたが、私はフリーランス時代にはそれを封印していた。理由としては端的で、私が一緒に働いたメンバーには別の上司がいたからである。会社や上司としてメンバーにどうなってほしいという願いがあるだろうし、メンバーとしてもその相手が複数いたら困るだろうなという思考だった。だから、何か相談したいことがあったら言ってねというスタンスだった。
そのためあくまでチームを通して個人と接することに徹底した。結果として、以下のようなはたらきかけを通じてメンバーへも変化を求めてく形になった。チームへの働きかけだけでも人が変わっていくという実感と、チームビルディングの自信がついた。1on1ができるようになったら、鬼に金棒ではないのか（ちがう）。こちらも制約ゲームである。
リリース月1、タスク管理もままならない状況から半年間でやってみたチーム施策をまとめてみた pic.twitter.com/2OuKHJKr6O
— いしげ (@oturu333) 2019年7月31日
それでも、「会社や上司がこのように言うけれど、チームではこのような話になっている」ということはたまにあったので、そのときは上司と相談したりした。
自分の変化
自分としても行動の変化や制約ゲームによる成長実感があったので、ストレングスファインダーをやり直してみた*8。赤字がニューカマーです。
相変わらず学習欲がないのが残念でしたが、難しい状況下でチームとして課題をクリアしてきた実感と新たなストレングスが一致していると感じました。情報がないから必死に集めて解決していく戦略性。人に影響をあたえるポジティブ。生産性の高いチームを作るための個別化。一切学んでいなかった頃と比べるとエンジニアリングマネージャーっぽい素質がついてきたのかな…？と思います。
あとがき
アウトサイダーでエンジニアリングマネージャーをすることをおすすめしたいわけではなく、ただの振り返りです。かなり修行にはなりますが、いずれ「とはいえ社員じゃないと難しい」ことにぶつかるんじゃないかなと思います。
マネージャー、管理職の外注する流れって本当にあるんでしょうか？さらっと調べた感じだとPMはありそうでしたが、知っている方がいたら教えてくれると嬉しいです。同じような人がいるのかは興味があります。
ただ何よりも「本を読む意味なんてない」「アウトプットする意味なんてない」と思っていて、自分のスキルが他社で通じるのか悩んでいる、会社に不満があるけど転職できるのかなと思っている方（ずばり、過去の私です）。悩みや恐怖は、選択肢がないからです。そして知識がないと選択肢は持てません。ということがこの一年で一番学んだことかなと思います*9。
また、私にこのような機会をくれて、たくさんご指導いただいた方に感謝です。来年はまた会社員がんばるぞ！
*1:超絶余談ですが、リリースが終わったら何かマネージャーっぽい良いことを言おうかなとか、みんなでガッツポーズとか青春っぽいことしたいとか考えてたんですが、放心状態で喜びすら表現できなかった
*2:過去記事でも触れていますが、女性エンジニア、エンジニアリングマネージャーは少ないのでとても未来が恐怖だった
*3:色々端折っています
*4:でも、未だにCTOになれるとは思えない
*5:こちら。業務が忙しくなってからこのペースとまとめの分量はつらくなったので、別の形で今はまとめている
*6:正直に申し上げると、今も特別に好きではない…。以前よりは気楽に読めるようになってきた。
*7:寄稿したっきりで皆さんとコミュニケーションを取れなかったのはもったいなかった…
*8:1.5年間隔で行いましたが、本当はもっと時間をあけてやるべきだそうです
他人は変えられないけど、自分で変わっていくチームは作れる
「他人は変えられない」とはよく言われることで、反対する人も少ないのではないか。ただし、なぜか他人のモチベーションや帰属意識などのソフトな部分を変えられると思っている人が一定数いることに気づき、何で変えられると思うんだろうと不思議に思うことがある。
過去「会社を好きになって！」と言われたことがあり、それが大嫌いだった。なぜなら、街中で「今からあの男性を好きになって！」くらい違和感を覚えたからだ。好きになるかどうかも好きの度合いも私次第であり、体験や時間経過に伴って作られていくものだろう。会社を好きになってほしい、可能であれば自分と同じくらい最大級に好きでいてほしいという気持ちは分からなくはないが、逆効果だと思っていた。今だから本音を言うと、同じくらいではなかったものの、結構好きだったんだと思う。会社の理念やスタイルに共感し、入社をしたわけだから。ただ、だからこそすごく嫌だった。
今回の主題とは異なるが、理念の浸透に関しては市谷 聡啓さんの「組織をファーストではなく、セカンドで合わせる。」という考え方が好きです。
「会社を好きになって」を恋愛で置き換えると「私をもっと好きになって！私と同じくらい愛して！」という言葉で恋人を変えられるかどうかが近いかなと思う。無理ですよね。男性たち裸足で逃げ出しそう。急に重い女感が出てしまったし。ほんとよくない。
好きだの嫌いだのとテンションが上がってしまったが、今日はその話をしたいのではない。私はエンジニアリングマネージャーをやっている。その中で、人やチームを変えたいと思うことがたくさんあったが、私の力で誰か、またはその集合体を変えられるとは思っていない。あくまで誰かが、自分自身で変わる必要がある。
他人を変えることはできない、特にソフト面は。と信じている私が、変えることはできないが、本人が気づいて変わっていくようにとタッチし続けることはできるという話をしていきたい。
エンジニアリングマネージャーのミッション
エンジニアリングマネージャーの仕事は組織の力の最大化だと思っている。端的に言えば、価値をより早く、高品質に、安定的に生み出し続けること。そしてその状態であるためにはチームが自走して成長し続けること（ラーニングゾーンにいること）が必要だと考えている。ラーニングゾーンについては、広木大地さんの記事がとても参考になります。
そのようなチームになるために他人を変えていきたい場合、どのようにアプローチしていくのか。
1. まず「チームになる」
組織の三要素で言う「共通の目的」を作ることは必要です。それは、目的がなければまずチームとして一緒に走れないからです。目的の存在はチームに大きく影響しますが、過去記事にまとめているので見ていただけると嬉しいです。
また、上記の記事では触れていませんが結果を定期的にメンバーで振り返ることも大切です。せっかく目的に合意してチームとして存在していてもその結果を見返すことがないと、忘れるかあるいは特定の誰かだけが頑張り続ける状態になり、自走するチームにはなれません。
2. 心理的安全の保たれたチームになる
心理的安全がない状態では以下のような問題が起こり、チームの力が激減します。1+1=2にもならない状態になるということです。
- 相談がしづらい（またはできない）ために完了が遅れる。大きな手戻りが発生しやすくなる
- 誰かが課題に気づいても言いづらいため、解決することが難しい
- 弱みや失敗を出しづらいので、同じような問題が何度も発生する
心理的安全のあるチームになるためにはまず、お互いがお互いをよく知り、ざっくばらんに話せる関係になることが大事です。
おすすめは、雑談をする機会を作ること*1、楽しいゲームをすること*2です。ゲームはチームにとって良いものだと二度美味しいですが、単純に和気あいあいとゲームをするのは楽しいのでそれだけでも良いと思います。顧客が本当に必要だったものゲームは単純にすごく楽しくて、やってみてほしいです（笑）
エンジニア3人でカオスを創出してYTK出してみた pic.twitter.com/fkJlluWBCs
— いしげ (@oturu333) 2019年9月13日
また、このようなことを考えた際に以下の書籍がとてもおもしろく、参考になりました。
「職場の問題地図 ～「で，どこから変える？」残業だらけ・休めない働き方」
雑談をベースとして心理的安全のあるチームを作ることによる一番のメリットは、課題が埋もれづらいことです。組織の力の最大化において、課題はなるべく早く見つかったほうがありがたく、視点は多いほうが良いです。そのような声を上げやすい状況を作ることで、自分も楽できる上、メンバーの思考も分かったりするので一石二鳥です。
3. 課題の発見、解決
スループットが下がることにつながるボトルネックの解決を行う必要があります。具体例で言うと、以下のようなことをしていました。
- 属人化している作業やナレッジを無くす
- 技術力の底上げ（教育）
- 見積もり制度を高めるため、不確実性と戦う
まとめ
うまいことやるためにひたすらに解決や改善を繰り返す。そのために必要な心理的安全のあるチーム作りや、目的作り、PDS回し。エンジニアリングマネージャーになってからはずっとそのように生きてきている気がします。こういうことをしているとどういうチームになるかは、過去記事を見ていただければと思います。
最後にこれまでにつらつら書いたことを図示したので、貼っておきます。
リリース月1、タスク管理もままならない状況から半年間でやってみたチーム施策をまとめてみた pic.twitter.com/2OuKHJKr6O
— いしげ (@oturu333) 2019年7月31日
P.S. 転職活動中です
こんなエンジニアリングマネージャーに興味を持っていただけたら、ツイッターからご連絡いただければと思います（こっそり）
*1:朝会で持ち回りで5分ほど話す時間を作りました。序盤は自己開示系のテーマ（趣味や、価値観など）で固定すると、みんな自分の話がしやすいです。徐々にみんなが知りたいことや、過去・未来のキャリアについてなどは楽しかったです。
*2:マシュマロ・チャレンジ、アンガーマネジメントゲーム、顧客が本当に必要だったものゲームなどをやりました
不安ゾーンにいた開発チームがラーニングゾーンに入るまで
はじめに
こんにちは。@oturu333 です。私はフリーランスエンジニアとしてモチベーションクラウドの開発チームに参画しています。
もともとEMをやっていたので、参画当初よりEM業務（組織やプロセスの改善など）に携わらせていただき、現在は複数ある開発チームの1つのPO業務も経験させていただいています。
今回はそのチームが2ヶ月で「不安ゾーン」を抜け「ラーニングゾーン」に入っていったお話をしたいと思います。
最初「自分たちは何でも屋なんで」と言っていたhotfixチームが、スクラムを取り入れ「もっとベロシティを上げられないか」「仕事を楽しめている」と言えるチームになるまでを語ります。
「不安ゾーン」「ラーニングゾーン」については、以下のブログが参考になります。
「hotfixチーム」と言われたチーム
モチベーションクラウドには複数の開発チームがあり、それぞれのチームに名前を付ける文化があります。現在私が所属しているチームにも「ドラゴンハント」というチーム名がありました。
そのチームは当初「バグを直す」「お客様からのお問い合わせに対応する」ことをミッションとして与えられたチームでした。
バグをドラゴンと呼ぶあれで「ドラゴンハント」というチーム名になっています。
しかし「ドラゴンハント」というチーム名がありながら「hotfixチーム」と呼ばれることがありました。
まさに当初のドラゴンハントチームは「hotfixチーム」でした。
学びはなく、ただ期日通りバグを直すことにコミットし、チームは不安ゾーンのど真ん中でした。
そんな中、そのチームにPO補佐としてジョインすることとなりました。
タスク管理ツールの導入と状況の可視化
私がジョインしたときには、バグをスプレッドシートで管理していました。
過去はプロジェクト管理ツールを使っていましたが、諸々の事情で一時的にスプレッドシートで管理しているということでした。
スプレッドシートは秘伝のタレ状態。
- スプレッドシートを把握しているのがPOのみ
- POは進捗状況の把握だけで精一杯
- 内容がわからない
- エンジニアはスプレッドシートを更新したくないのでGitHub Issueとの二重管理
- 二重管理によるヌケモレ、ステータスの差分が散見
- 進捗共有のためのMTGに1h / 日を費やす
そこでまずは新たなプロジェクト管理ツールの導入を提案し、せっせと移行作業に勤しみつつ、運用プロセスを設定しました。
チームリーダー就任
2018年末くらいから、ドラゴンハントチームのチームリーダーとなりました。
プロジェクト管理ツールの移行完了から半月ほどで進捗把握秘伝のタレ問題は解消し、進捗共有MTGは 15〜30m / 日 というところまで抑えられるようになりました。
テクニカルサポートチームとの連携もスムーズになり、管理にかかる工数も徐々に減っていきました。
エンジニアもスプレッドシートを離れられた喜びに満ち溢れました。
それまでチームメンバーは流動的でしたが、1月よりチームメンバーも固定化され、以前のような大混乱期は越えられました。
この時期にはそれまで明確なログを残すこともしていなかったのを是正していました。
「ちゃんとログを残そう。ログを残せば良いことがある」。そのくらいの進捗でした。
チームビルディングワーク
1月22日（Slack漁った）、やっとチームのキックオフMTGをすることができました。
キックオフでやったことはマシュマロ・チャレンジと、「自分のキーワードを50出してみよう」というアクティビティです。
キーワードのアクティビティは以下を参考にしました。
マシュマロ・チャレンジにおいては終了後に組織の三要素の話に触れ、チームには共通の目的が必要だよね！このチームの目的ってみんななんだと思う？という問いかけをしました。
共通の目的のアップデート
チームメンバーそれぞれに「このチームの目的は何だと思う？」と問いかけたところ、以下のような回答が多かったです。
- バグを直す
- 何でも屋
そこに今自分たちが苦労している原因の根本であるプロセス、組織の改善を組み込むことを提案しました。
バグをなくすには、ただ直すだけではなくバグが起きにくい環境をつくらなくてはいけない。
属人化を解消しないといつまでもチャレンジができない。
共通の目的は「開発チームの『当たり前水準』を上げ、安定した運用をするための土台を作る」としました。
共通の目的をコミットメント化
などを盛り込み、それらを3ヶ月で達成するようマイルストーンを置きました。
厳しいかなぁと思いましたがチーム全員の合意を取ることができました。
hotfixから恒久対応へ
共通の目的を高く置いたことで「とりあえず」という思考がなくなり、
「こういう依頼が来ているんですが、このように対応したほうが良いと思う」
「この作業は手戻りが多いから、フォーマットを作ってスムーズに連携したい」
そのような会話が出てくるようになりました。
「スクラムブートキャンプ」輪読会の実施
これまでもモチベーションクラウドではスクラムを取り入れてきましたが、ドラゴンハントチームではまだやっていませんでした。（hotfixだったので）
あえて輪読会を行ったのは以下のよううな理由です。
- あらためてドラゴンハントチームでスクラムを取り入れるにあたって、共通の認識を持ってスタートしたい
- 自分たちはどのようにやっていくかを考えたい
- 会議体、ロールなどが形骸化しないように「目的」を捉えよう
ロール、会議体ごとにセクションを分け、それぞれ発表資料を作成し、LTしました。
そこでこれまでリーダーと自称していた私の業務が、スクラムを取り入れるとなるとPO兼SM兼開発チームという状態になってしまうことが議題となり、SMを他のメンバーがやると挙手してくれました。
そして私はPO兼開発チームとなりました。
SMとなった彼はスムーズに業務を進行するためのbotの作成などをすぐにやってくれました。
デイリーでのProblem収集
輪読会の中でSMから「Problemは一週間またなくてもいつでも言えば良いじゃない」という提案がありました。そうだなと。「フライングKPT」と呼んでいます（Kないですが）
思い立ったときにSlackからつぶやいてスプレッドシートに連携。スプリントレトロスペクティブで振り返るという手法を取り入れています。
忘れないうちにあがるのでたくさんあがってとても良いと思っています。
ここで収集したProblemからTry（解決）を探していくことにしています。
FDL
この記事を書こうと思ったのは、スプリントレトロスペクティブで「ファン・ダン・ラーン」をやってみたことがきっかけです。
フライングKPTとは別にこれをやってみようと思ったのは、チーム状況が良いのはなんとなく分かっているので、こういう明るい振り返り手法を取り入れてみようと思ったからです（あと、個人的な趣味と興味です）。
ファン・ダン・ラーンをやり、その中からKeepしたいことを抽出してネクストアクションを作ろうとしました。
では、KPTやれば良いじゃん！となるかもしれませんが、大きな違いはファン・ダン・ラーンをやると、チーム状況が可視化できることです。
- ファン & ダン & ラーン（ど真ん中）が多い = ラーニングゾーン
- ファンに絡む物が多い = 仕事を楽しめている、心理的安全性が高い、チームの雰囲気が良い
- ダンだけのものが少ない = ただただ作業が完了するだけではない（以前のhotfixチームではない）
また、 ファン・ダン・ラーンを経てKeepを抽出しようと提案したときに以下のような発言がありました。
- 以前と違って考えて仕事ができているから、学びがある
-
もっとベロシティを上げられないか、もっと工夫できないか
Keepを出そうと思ったら、ポジティブなTryが生まれました。そしてすぐに着手。
ファン・ダン・ラーンをやったらうまく行くというわけではありませんが、今のチーム状況にはマッチしたのかなと考えています。
この1ヶ月強で起きた大きな変化を振り返る
「何でも屋のhotfixチーム」から「当たり前水準を上げるチーム」へ。
自分がやったことは共通の目的をアップデートしてファシリテーションをしただけですが、メンバーが大きく変化してくれました。
ファン・ダン・ラーンをやってみて、それを強く実感し、全部をまとめてみたくなりました。
今はプロセス改善が短期ゴールですが、今後CREチームにスケールしていけたら良いなと思っています。
コンサルティング同行で学んだ、エンジニアリングマネージャーとして新しい組織にジョインして取るべき姿勢
おはようございます。いしげ（@oturu333）です。
このブログは Engineering Manager Advent Calendar 2018 - Qiita 10日目の記事として書いています。
一般職からエンジニアリングマネージャーになり1年くらい経ったときに「ここでしかマネージャーができないんじゃないか」という思いになったことがあります。
知っている会社、プロダクト、メンバーだからできているだけじゃないかと。
そう思ったのは自分のやっていることを抽象化できなかったからだと、今になって思います。
その後コンサルティングに同行させていただく機会があり、外部の組織、人へのアプローチの仕方を間近で見て、コンサルティングの手法は新しい現場でマネージャーになるときにも使えるなと感じました。
今回はその学びをアウトプットしていきます。
エンジニアリングマネージャーの仕事だと思っていること
一言で表すならば、環境整備、仕組み作りだと思っています。
- 組織の三要素を満たす環境創り
- 共通の目的をもっていること（組織目的）
- お互いに協力する意思をもっていること（貢献意欲）
- 円滑なコミュニケーションが取れること（情報共有）
- スループットをあげるための仕組み作り
- 成長実感やビジネス貢献を感じられる仕組み作り
- 継続的な改善活動を行うための仕組み作り
- etc
これをはじめましての現場でやるにはどうしたら良いのか。
新しい組織に入って一番やってはいけないと感じていること
過去すべてやったことがあることですが、以下のようなことを気をつけています。
- べき論だけで議論すること
- 相手の知らない言語、舞台で話すこと（エンジニアではない人に対して）
- 受け身になってしまうこと
- 決めつけてしまうこと
逆に言うとこれらをしないということになるので「積極的にファクトを洗い出し、課題を見つけ、相手に分かりやすい言語で伝える」というプロセスを意識しています。
積極的にファクトを洗い出す
人を知る
一緒に働くメンバーがどんな人で、どんな技術があって、どんな仕事をしていて、どんな悩み、課題を持っているか。まずはそのあたりが知りたいです。
ただ「教えてください」と言っても話してくれる人は少ないと思うので、まずは自分から話すようにしています。
自分のキャリア、書いたブログ、こんな事を考えている、こんなことが得意 / 苦手だ、お酒が好きだ、こんな失敗をした、などなど。なんでも良いので、この人に話しても大丈夫だという信頼を得る努力をする必要があります。
主にやっていることは以下のようなことです。
- Slack の雑談板で一人語りしてみる
- ランチに誘ってみる
- なにか悩んでいることを話してくれたら、一緒に解決策を考える
- やると言ったことは必ずやって報告する
歴史を知る
新しく入った人にとっては不思議に感じるプロセスや文化も、だいたい歴史があります。
頭から否定するのではなく、その経緯や理由を詳しくヒアリングするようにしています。
ヒアリングをする際には以下のようなことを意識しています。
- 認識齟齬にならないよう、あいまいな言葉は意味やアウトプットを確認する
- 矛盾を感じるところは深く話を聞いてみる
- 歴史、現状と合わせて課題感を話し合い、認識を合わせる
- 議事録は終わった直後にパブリックな場所で共有する
あいまいな言葉は「大変」「複雑」「忙しい」というような個人によりけりなものだけではなく、一般的な言葉にも潜んでいます。
例えば「システムテストをしています」と言ったとして「システムテストだからこんなことをやるんだろうな」ではなくアウトプットまで見ないと認識がずれたりします。
総じて無邪気に、興味をもって話を聞く
誰かに何かを聞くときに「それってなぜですか？知りたいです！教えてください！」の姿勢が大事です。
例えば「どう考えてもおかしいなぁ」と思っても、斜に構えずに聞く姿勢のほうがお互いに話しやすいですし、提案も通りやすいからです。
「謙虚なコンサルティング」を読んでからこれを意識するようになりました。
謙虚なコンサルティング――クライアントにとって「本当の支援」とは何か
- 作者: エドガー・H・シャイン,金井壽宏,野津智子
- 出版社/メーカー: 英治出版
- 発売日: 2017/05/17
- メディア: 単行本
- この商品を含むブログ (2件) を見る
課題を見つける
環境整備、仕組み作りでいかに解決できるかを考えます。
すぐに100点になる必要はなく、最低限今より良い方向へ、最終的にこうなりたいまで考えられるようにしています。
相手に分かりやすい言語で伝える
例えばこのプロジェクトを提案したとき「サポート切れてるフレームワーク使ってるとかダメでしょ」と言っても伝わらない状況だったので、提案資料では技術的な観点にはほぼ触れませんでした。
サポート切れの状態のままでいることで起こりえるおそろしいできごと（例：エンジニアのモチベーションが下がることによる離職率増や伴って採用、育成にかかるコスト増）など、相手が共感できる話題を探して承認をもらいました。
まとめ：最終ゴールは「相手に動いてもらうこと」であることを忘れない
組織に属していると、人や組織との関係が深くなるにつれ感情的になり、主張をおしつけあってしまうことがあると思います（私はこれが大いにあります）。
ただ、コンサルティングに同行して強く感じたのは、私が本当にやりたかったことは「相手に動いてもらうこと」だったということです。
動いてもらうというのは「承認してもらう」「一緒にやってもらう」「誰かに何かをやってもらう」などです。
このゴールを失わないための姿勢を、コンサルティングから得ることができました。