エンジニアリングマネージャーをやめかけ、フリーランス武者修行して復活した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点になる必要はなく、最低限今より良い方向へ、最終的にこうなりたいまで考えられるようにしています。
相手に分かりやすい言語で伝える
例えばこのプロジェクトを提案したとき「サポート切れてるフレームワーク使ってるとかダメでしょ」と言っても伝わらない状況だったので、提案資料では技術的な観点にはほぼ触れませんでした。
サポート切れの状態のままでいることで起こりえるおそろしいできごと（例：エンジニアのモチベーションが下がることによる離職率増や伴って採用、育成にかかるコスト増）など、相手が共感できる話題を探して承認をもらいました。
まとめ：最終ゴールは「相手に動いてもらうこと」であることを忘れない
組織に属していると、人や組織との関係が深くなるにつれ感情的になり、主張をおしつけあってしまうことがあると思います（私はこれが大いにあります）。
ただ、コンサルティングに同行して強く感じたのは、私が本当にやりたかったことは「相手に動いてもらうこと」だったということです。
動いてもらうというのは「承認してもらう」「一緒にやってもらう」「誰かに何かをやってもらう」などです。
このゴールを失わないための姿勢を、コンサルティングから得ることができました。
1年半取り組んだWebプロジェクトマネジメントを振り返って、やって良かったこと、やっておけば良かったことをすべて書く
おはようございます。いしげ（@oturu333）です。
このブログは モチベーションクラウド Advent Calendar 2018 - Qiita 1日目の記事として書いています。
今回は過去私が1年半に及ぶWebプロジェクトのPMをした経験を語ろうと思っています。
この記事でお話することについて
プロジェクトの概要は既存のWebシステムの全面リニューアルです（MCSではありません）。
ざっとやっていたこと
- サービスをすべて作り直す（リプレイス）
- PHPのメジャーバージョン2つくらい一気にあげた
- CakePHP -> Vue.js + Laravel の構成に変えた
- AWS構成をがっつり変えた
- 一部マイクロサービス化した
- 機能の見直し、UI全刷新
- ドキュメントが全然なかったのでいろいろ作りつつ進める
当時の私の立場は、開発チームのマネージャーであり、今回お話するプロジェクトの企画者であり、PMであり、サーバサイドのエンジニアでした。
開発手法、プロジェクトマネジメント手法などの記事はたくさんあるのでここでは言及せず、当時の私自身も知りたかった、PMのより具体な部分「実際何をやるものなの？」を書いていきます。
また、PMと同時にマネージャーでもあったので、プロジェクト中にマネージャーとして意識していたことなどもまとめてみます。
そして最後に反省している点に言及します。
やってよかったこと
ピープルマネジメント
みんなで決めること、一部の人で決めることを分けた
このプロジェクトの企画骨子は私が作りましたが「こんなことやりたいんだけどどう思う？みんな何がしたい？」という意見を集めました。
PHPのバージョンの上げ方からお察しいただけるところもあると思いますが、プロジェクトの目的の一部として、だいぶ積もってしまった技術的 / 非技術的負債の抜本的な解消、そしてエンジニアのモチベーションのアップがありました。
長いプロジェクトになることは見えていましたし、人は誰かにやらされるのは嫌いなので「みんなで考えたこのプロジェクトを成功させよう！」というストーリーからモチベーションを作りたかったのです。
また、メンバーと仕事をする上で「この四象限の2つ以上を同時に達成する」ということを意識していたというのもあります。
その点で「メンバーと一緒に計画を立てる」はとっても素敵な案件で、人間関係、部下育成、仕事の改善が一気にできてしまいます。おすすめです。
タスクを依頼するときもただお願いするのではなく、一部のスケジュール管理と一緒にお願いしたり、設計からお願いしたり、コミュニケーションを取りながら進めたりすることで複数を達成できます。
目的をみんなで決めたことの副産物として、プロジェクトの方向性がずれそうだなとなったときにこの目的に立ち返ることができたことが良かったです。
「このAPIはこういう設計で良いですか？」
「その設計だと目的のこれに反してるからこうしたほうが良いと思うけど、なんでそうしようと思ったの？」
「実は…」
のような会話ができ、判断に迷うポイントが減りました。
逆にみんなで決めなかったことは技術採択やサービス設計など、要するに決めでしかないところです。みんなから意見はもらうところもありましたが、最終決定は少人数で行いました。
どこまでがみんなで決めるべきで、どこまでがそうでないべきなのかはっきり言語化できていません。今後のお題にしようと思います。
プロジェクトの事前準備
1. 参考になるプロジェクトの事例を集めて共有した
リニューアル、リプレイスなどの手法や、過去リニューアルプロジェクトを経験した方々の知見をあさりました。
特に以下の「backlog UI リニューアルの舞台裏」はリリース後にまで触れられていてとても参考になりました。
2. 事前にやらないことを決めた
やらないことを定義したのは以下の理由です。
- ただでさえリスキーなリプレイスという手段を選んでいるので、最大限リスクを回避するため
- 長期間プロジェクトのため内外からの要望に変化が起こる可能性が高い。もともとの要望を変えないため
具体的にやらないと定義したことは以下です。
- 既存スキーマの変更は基本行わない（リスクヘッジ）
- 変更してでもやるべきと判断できる改修は、現サービスに先行して反映させることをルールとした
- 新機能の開発（リスクヘッジ、要望変化への対応）
- 既存機能の拡張、縮小、削除はあり。ただし新規機能はなし
3. プロジェクト後（リリース後）の対応方針について定めた
事例調査や、自分たちの経験から「おそらくリニューアル後に十分な計測期間を取らないまま、元に戻したほうが良いという話になる可能性はあるよね」という議論になりました。（プロジェクトの性質上「戻す」のは無理なので、必死に直すことになりますが）
定めたことは以下のようなものです。
- リニューアル後はお問い合わせが増えるだろうし、批判的な意見も出るであろうということを「ほぼ確実に起こること」としてチーム全員に共有した
- 慣れたUIが変わるので仕方ない
- 一定期間の計測をしてから方針を判断するということの合意をとった
- 上記の内容を会社全体に周知
- 社内ユーザーからの声にも対応するため
4. プロジェクトゴールのその先について事前に語った
負債返却を含めたプロジェクトだったため、1→10というよりはマイナス→0でした。
「とりあえずスタート地点に立とう」と。
プロジェクトが始まる前から、プロジェクトのその後にやるべきことを平行して整理していこうという話をし
- 全員の方向性がずれないよう、事業のミッション・ビジョンの制定
- 負債をなるべく生まないためのルール、フローの整備
- ドキュメント作成と既存ドキュメントの整理
などを行いました。
メンバーもしんどい時期もあったと思いますが「これ終わったらこんな機能作るべきだと思う！」「デザインスプリントやってみたい！」など活発に話ができたのはとても楽しかったです。
進捗管理
1. 進捗は誰が見ても分かるようにした
ガントチャート（は作ってないですが）などを作成するも予実がずれていって、結局今の進捗はどうなってるの？という状態になることってありがちかなと思います。
予実を数値化し、今どういう状態なのか分かりやすくするようにしていました。
2. スモールステップの進捗目標を立て、週次で振り返った
プロジェクトの全体スケジュールが年超えだったので、月次の進捗目標を立てました。
しかしそれでも何かを改善するにはチェックポイントが足りないので、振り返りは週次で行っていました。
振り返りと言っても、数字をSlackでコメント付きで送るというものです。
オンスケだったら感謝と喜びのコメントを。遅れ気味だったら「なぜ遅れているか」の共有、実行中・考えている改善施策の共有などと、フォローのお願いなどを行いました。
3. コアメンバーで進捗について語り合うチャンネルを作り、改善策を出し合った
この板ではスケジュールコミットに関わるメンバーだけで以下のようなやりとりをしていました。
- 進捗が芳しくないときに、どうやってスピードを上げられるか（ボトルネックの特定）の議論
- 私が気づいていなくても「このままだとやばいと思います」というアラート発信
チャンネル内で話した、ボトルネック特定と解決策の例
- レビューに時間がかかりすぎる
- 画面デザインの仕様書が見づらい
- 複雑な画面から優先してZeplinへの移行を行った
4. 基本的にはロジカルに、たまに無茶なお願いをした
基本的には根性論で解決せず1つずつ課題に対処しましたが、これはあとはもう頑張るしかない！となった時もありました。
そのときは「友情・勝利・勇気」がキーワードになっていました。楽しかった。ランニングハイ。
アサイン調整、タスク管理
以下のようなことを工夫していました。
- 共通機能、複雑な機能はなるべく前倒し
- メンバーのアサイン時期を調整する
- 参考になる1つ目の処理は、技術力の高い人にお願いする
やっておけば良かったこと
事前にちゃんとお勉強することが必要だった
プロジェクトマネジメント手法を何も知らずにPMをしていました。無知ゆえに経験と勘ですべてをこなしました。
プロジェクトが終わってからCCPMなどについて勉強しましたが、もっとこうできたなと思うことがいくつかありました。
- なるべく早く終わらせたいという要求もあり、無茶な進め方をしたところがある
- 正しい進め方が分かっていなかったので議論ができなかった
- タイムラグのあるタスクを調整しきれなかったり
- CCPM を取り入れたり、要素分解してスケジュールを考えたりすれば、もう少し不安要素の少ないマネジメントができたかもしれない
- 検討漏れ（結合テスト後の修正の時間が特に大きかった）タスクが発生し、プロジェクトバッファをだいぶ食い尽くした
もともとあった開発プロセスの課題が顕在化した
進捗に遅れが出たときに発見されたボトルネックは、プロジェクト中だから発生したわけではなく、もともと存在していたものもありました。
プロジェクトの前に見つけることができていれば良かったなと思います。
- 気づいていたけど着手できていなかった問題も顕在化した
- 気づいていなかったものに関しては、マネージャーとして興味のチャンネルが狭かったなと感じる
1人で抱えすぎた時期があった
進捗を可視化しても感じ方はそれぞれで、私は「もうちょっと今はすすめないとなー」と思っても、メンバーはそうじゃなかったり。結果1人でタスクを抱え過ぎたりしました。
私のほうからコミュニケーションができなかったなと思います。
途中からメンバーとそういう話をするようにしてから、だいぶ楽になりました。
突然ですが、マネジメントのおもしろさについて少し語る
エンジニアとエンジニアリングをどのようにマネージメントしたらいいかが面白くて、知的で、リスペクトされる仕事にならないと怖いので誰もやりたくない仕事になってしまう。そうすると、いつまでもエンジニアリングの経営が日本に宿らない。だから #EMFM とかで少しでも面白い仕事だよと伝えたい
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) November 25, 2018
マネジメントは楽しいです（という引用…ｗ）ピープルマネジメントも、プロジェクトマネジメントも。
知的な仕事なのに人間味があって泥臭いところもある。
マネジメントをやるようになってから自己開示に勤しんだり、組織や人について知ろうと思うようになったり、自分の中の変化がたくさんあって驚いています。
自分が何をしたいのかを見つけられれば、エンジニアリングマネージャーは楽しいです。と思ってます。
この記事のまとめ
- 不確実性をへらすための事前準備
- プロジェクト運用に対する知識 ☓
- プロジェクトの方針の決定 ◯
- プロジェクト後の方針の決定 ◯
- スケジュール設定 ☓
- 事前から解消できる問題の回避 ☓
- プロジェクト中
- その他
- このプロジェクトのPMができてよかった ◎
- 辛かったけど楽しかった ◎
事前準備をしっかりやりましょう。お勉強しましょう。きちんと会話してPDCA回しましょう。目的があれば厳しい状況でも楽しめるので、全力で楽しみましょう！が今の私のまとめです。
このプロジェクトを始めるときに「しんどいこともあると思いますが、二度とこんなことやりたくないと思うようなプロジェクトにだけはしないようにしよう。せっかくの挑戦の機会を楽しもう！まぁ、二度と起こしちゃいけないけど」というようなことを言ったことを覚えています。
終わったあとに「まぁあと数年はやらなくても良いかなー」なんて話せたのも良い思い出です。
良い経験をさせてもらいました。感謝をこめてログを残しますm(_ _)m
ハッシュタグ #弊社のろけ話 のツイートから見えた、みんなが自社を好きな理由ベスト5
おはようございます。こんにちは。こんばんは。いしげ（oturu333）です。
ツイッターのハッシュタグ #弊社のろけ話 を眺めていたところ、これをまとめたらみんなが大好きになる会社の特徴が分かるのでは？と思ったので、なるべく具体的に集計、ランキングしてみました。
ランキングは2018/10/27現在のツイート121件を対象に、1ツイートで複数要素があるものは分解して出しています。
主観でカテゴライズしているところはあるのでご容赦くださいm(_ _)m
具体的なコメントは抽象的にまるめているものもあります。
第一位 人が好き
みんな大好き編
- 優しい、良い人が多い
- 自分だけじゃなく家族のことも思いやってくれる
- 褒めてくれる、認めてくれる
- 自発的に働ける人が多い
- 個性豊か
- 口だけではなく行動する人が多い
- 約束を守る
- 働きにくい人が少ない
上司大好き編
- 上司がフランク
- 優しくも厳しい上司が好き
- 上司が部下を鼓舞してくれる
- 社長がおもしろくて冗談が通じる
第二位（同率） オープンコミュニケーション
- 企画や事業にも意見が言える
- GithubやSlackの活用により、考えや議論をオープンにしようという文化がある
- 職種間、役職間の隔たりがない
- 意見が言いやすい。意見を尊重し合える
- 言いたいことを言っても引きずらない。建設的な議論ができる
- 意見や助けを求めると、みんなが議論に参加してくれる
第二位（同率） 適切な権限委譲 / チャレンジができる
- 提案したことをやらせてもらえる
- やりかたや手段（技術採択など）を自分で決められる
- 求める以上、経験以上の裁量を与えてもらえる
- 学んだことを実務でやらせてもらえる
第四位 福利厚生に満足
- 旅行プラン、娯楽施設が割引きで利用可能
- 社員旅行
- 職場飲食（ランチ、おやつ、飲み物など）が安い、無料
第五位（同率） 尊敬できる人が多い
- 尊敬できる先輩が多く学びがある、楽しい
- 社員全員Github使える
- 全員が自立している
- 本質的、長期視点の議論ができる人が多い
第五位（同率） 変化を恐れないマインド
- 未来志向ができる
- 内省ができる
- 悪しきルールは変えていく文化。変わることに抵抗がない
- 変化に協力的な人が多い。変えようと声をあげると協力者が多く名乗り出る
- 変化が多くて飽きない
第五位（同率） 仲が良い
- 仕事終わりに和やかにお酒を飲めたり、ゲームをしたりできる
- 上司をいじれる
- メンバーが会社になじめるよう、上司が手助けしてくれる
- おふざけできる
第五位（同率） 勉強を支援してくれる
- 通常業務内で成長のための時間を取れる
- 勉強会参加や本の購入などの予算が十分ある
- ランチLTがある
- みんなで切磋琢磨する空気がある
- 社内合宿がある
- 大量の本を置くための本棚を購入してくれた
番外編（順不同）
- オフィスの環境が良い
- オフィスの立地が良い
- 仕事のツール、環境（マシンスペックなど）に満足している
- 給与が適正 / 評価に納得ができる
- 休みが取りやすい
- プロダクトや事業内容が魅力的
- 役職者との物理的、心理的距離が近い
- ワークライフバランス
- フレックス制度
- 会議が少ない
- 部署や役職の希望が通りやすい
- 副業可能
- 服装、髪型が自由
- 仕事に関係ない備品を購入してくれる
いかがでしたでしょうか？
#弊社のろけ話 を眺めていると、自社を大好きな人が多くてほっこりします。
良い会社のエッセンスがぎっしり。ぜひツイッターも覗いてみてください。
調べてみたら思ったより少なかった！女性エンジニアの人数を算出してみた
はじめまして、いしげ（@oturu333）と申します。Web系のエンジニアです。
私のキャリアは未経験でエンジニアになったことから始まり、28歳でチームリーダー、29歳でマネージャーを経験し、今はフリーランスとしてIT企業のコンサルティングに同行したり、開発案件の受託をしたりしています。
エンジニアになってから「女性のエンジニアって珍しいよね」「自社に何人くらい女性エンジニアいるの？」という質問はよく聞かれましたし、
個人的には、同年代（20代・30代）女性エンジニアでマネージャー経験者はどのくらいいるのかなと気になっておりました。
肌感としては女性エンジニアも、マネージャー経験者ともに少ないことは感じていたので、定量的に理解しようと思います。
（今回は主にソフトウェアエンジニアに限定して調査しています）
1. 他職種と比較したソフトウェアエンジニアの女性比率の比較
IT人材を巡る現状について （データ編） / 経済産業省 情報処理振興課によると、IT技術者の女性比率は以下の通り。
ソフトウェアエンジニアの女性比率は14.4%です。
他職業と比較してもIT技術者の女性比率は少ないことが分かります。
2. ソフトウェアエンジニアの女性の数
ソフトウェアエンジニア人口は20代後半〜30代が最も多い層となっています。
女性エンジニアは上記の通り全体の14.4%で、46,610人です。
ソフトウェアエンジニアに限らず、IT技術者は他の職業と比較して平均年齢が若い傾向があります。
3. 日本企業の女性マネージャー比率
2017年国際労働比較 / 独立行政法人 労働政策研究・研修機構によると、日本企業全体においては、女性マネージャー比率は、12.5%です。
4. 日本企業における年齢別管理職割合
国勢調査によると、職業に係わらず30代女性マネージャーは0.2%です。
20代のデータはありませんが、40代になっても0.3%なので、20代も0.2%未満程度でしょう。
5. 以上の数字から、20代・30代女性エンジニアマネージャーの数を考える
この章はあくまで推測の数字になるため、悲観的、中間的、楽観的な数値を算出してみました。
それぞれにおいて、マネージャーのうちの10%が20代・30代だろうと仮置きしています。
5.1 悲観的観測
エンジニアは他職種と比較してそもそもの女性比率が低いです。
そのため、全職種の女性比率 : 女性マネージャー比率 = 43.2% : 12.5%
という計算式を、ソフトウェアエンジニア女性比に置き換えると、女性エンジニアマネージャー比率は4.98%。
この比率で計算すると、女性ソフトウェアエンジニアマネージャーは232人となります。
5.2 中間的、楽観的観測
3の数字を利用し、他職種と同じくソフトウェアエンジニアの女性の12.5%がマネージャーだとすると、20代・30代のソフトウェアエンジニアマネージャーは583人となります。
また、4の調査の数字を利用し、全体の0.2%が女性マネージャーだとした場合でも、932人となります。
まとめると、
悲観：232人、中間：583人、楽観：932人となりました。
エンジニアは他職種と比較して女性比率が低い上に、スペシャリストコースに進む方も多いため、悲観〜中間の数値が現実味があるのかなと思います。
6. まとめ
ソフトウェアエンジニアのすべての女性の総数は46,610人。
そのうち20代・30代は34,740人、さらにマネージャー経験者は多くて500人くらい。
ボリュームゾーンの20代・30代の中でもマネージャー経験者は1.4%。
100人の20代・30代女性ソフトウェアエンジニアに会って、1、2人会えるかどうか。
7. 感想 / および自分語り
現状なぜ女性エンジニア、マネージャーが少ないかについては言及しませんが、女性エンジニアが少ないことは、今後さらに女性が活躍しにくい環境を作るんだろうな、と想像します。
というのも、自身がマネージャーになるときも、本当はぎりぎりまでお断りしようと思っていました。
周りに女性エンジニア、及びマネージャーがいない（エンジニアでない女性マネージャーも少ない）状況で、自分に務まることなのか、結婚・出産などの未来を考える上でやるべきなのかという悩みがあり、また、相談する相手もいなかったからです。
そもそも、エンジニアの仕事は忙しいので、将来的にエンジニアを続けるべきかどうかも当時は迷っていました。
私の場合最終的にとりあえずマネージャーになってみた結果、なって良かったと思ってるんですが（笑）そういう悩みを相談できるコミュニティーなどを今後やっていけたら良いなと思っています。
