EMに求められる「いい感じにして」を叶える4つのステップ　課題が示されない中で、課題を発見して管理・解決する

EMという働き方になってマインドチェンジが必要になった

shimobayashi氏：よろしくお願いします。それでは「『いい感じにしといて』を支える技術」ということで発表しようと思います。

自分はid:shimobayashiと申します。2023年2月頃から「EMってことでよろしく」となり、そのタイミングでこれまでいたチームから別のチームに異動することになりました。ということで、EMという職種をやったことがなかったので、やったことのない働き方、かつ知らないチーム、しかもいったん「2つのチームを見てください」なったので、2つの知らないチームを見ていくことになって、「けっこうわからないことだらけだな」となりました。

そういうわけで、けっこう状況が変わったなと思っています。これまでの仕事ではけっこう課題が示されていることが多かったと思っていて。自分は過去にディレクターとかをやっていたこともあるんですが、エンジニアに限らず、ディレクターをやっていた時でもけっこう目標とかが示されていることがあって、はてなでは「こういうことをやって」みたいなことがけっこう多かったなと思っています。

ですが、EMという働き方になってからは「いい感じにしといて」みたいな感じの要望のカラーがけっこう強くなったかなと思っていて。「まぁ……」というところで、すごく自由度が上がったので、マインドチェンジしていく必要が出てきたかなと感じていました。

EMとは？　「いい感じ」にするとは？

ということで「EMって何だっけ？」とあらためて考えてみたんですが、自分としては、「EMはプロダクト開発をいい感じにする人」かなと思っています。

じゃあ「いい感じにする」とは何だっけ？　というところに関しては、課題を発見・管理・解決していくのが「いい感じにする」ことかなと思っています。

世の中一般的に、EMってエンジニアチームのマネージャーみたいな建付けもけっこう多いような気もしているんですが、そういうのは広い課題とかを管理とかを解決していく上で人とやっていくことが必要なので、そこが中心になるというような理解で考えています。

というわけで本日は、そういったプロダクト開発の課題を発見・管理・解決する方法について、自分がやったことをお話ししたいなと思っています。この話が今回聞いているみなさんの何かの参考になればいいなと思っているので、よろしくお願いします。

「いい感じ」にするための4つのステップ

さっそくですが「いい感じ」にするってどういうふうにやるのかを、ステップとしてまずはまとめてみました。（スライドを示して）ここにあるような4つのステップをやっていくといいかなと自分は考えていています。

実際はこの間を行ったり来たりすることになるかなと思っていて、解決したと思ったらまた次の課題が見えてきたりとか、「やってみたけどよくわからない」で情報収集に戻るとか、そういうことがよくあるかなと思います。

一方通行じゃなくて行ったり来たりしながらやっていくことになると思っているし、それぞれのステップで使われるテクニックとかもいろいろあるかなと思っているので、このあと紹介したいと思っています。

ステップ1　情報収集をする

まずは1つ目のステップとして、情報収集するというところから話そうと思います。先ほどお話ししたとおり、知らないチーム、しかも「2つ見てください」ということで配属されて「ちょっと何もわからないな」となったので、まずは情報収集しようとなりました。

とはいえ、何でもかんでも情報収集するとなるとすごく効率が悪いと思うので、自分はプロダクト開発のメンタルモデルに沿って情報を集めようという判断をしました。

（スライドを示して）「プロダクト開発のメンタルモデルって何ですか？」という感じだと思います。いきなり私見で恐縮なんですが、ここに出ているようなつながりがあるかなと思っています。

これは例えば体制や計画を作るとか、双方向にリンクしている部分とかがたくさんあると思うんですが、単純化のためにいったん整理してみているという感じです。

先ほど紹介したのは自分の考えですが、何かしらしっくりくるメンタルモデルを自分の中で選び取れていることが大事かなと思っています。というのも、みなさんの現場ごとにも、仕事のやり方とかがけっこう違ったりするかなと思っているので、マッチするメンタルモデルを選べると今後情報も集めやすいし、情報も整理しやすくなってくるんじゃないかなと思っています。

ウォーターフォール的な考えをしている現場もあると思うし、アジャイル的な考え方をしている現場もあると思うし、いろいろあるかなと思うので、しっくりくるのが大事かなと思っています。

このあたりは自分なりにも考えていたことがあり、参考資料として（スライドに）リンクを貼っておいたので、見てもらえるとうれしいです。

（スライドを示して）モザイクだらけで恐縮ですが、実際に自分が情報収集した時の様子はこんな感じです。2チーム見ることになったので、それぞれのチームで情報を集めようという動きをしたんですが、（その時に）こういう「情報をまとめるよ」というページを作って。これはチームのグループウェアでやっていたので、「あわよくば見た人が情報を書き込んでくれるとうれしいな」みたいな感じでまとめていって、実際にコメントをもらったりしながら情報を集めることをまずはしました。

ステップ2　課題を見つける

という感じで、いったん自分的には情報は集められたかなということになったので、じゃあ次は課題をそこから見つけていくぞということでやっていきました。

集めた情報を整理すると課題が見えてくるかなと思っていて。こういう整理の手法として、一般的にはロジックツリーとか、現状問題構造ツリーとか、よく言われているものが世の中にはあるかなと思っているので、そういうものを参考にしながら整理していくといいのかなと思っています。

こういう整理をする時に、先ほど紹介した「自分なりにしっくりくるプロダクト開発のメンタルモデル」に沿って整理するとわかりやすいかなと思っていて。（スライドを示して）自分のメンタルモデルだとこういう感じのツリーになるかなと思っているんですが。

集めた情報を再配置して並べてみて、並べると「こことここがつながっていないな」とか、「そもそもこの要素が欠けているな」とか。弱いところというのが見えてくるかなと思っていて、そういうところが課題なんじゃないかなと思っています。

ちなみに、自分は売上をけっこうイメージの上のほうに置いているんですが、スライドにはMVVと書いていますが、ミッション・ビジョン・バリューみたいなものを達成できている・実現できているとしても、結局は売上が立っていないと続かないと思うので、かなり重要なものと認識して上に置いています。

実際に自分が整理した時の様子についてで、これもモザイクばかりで恐縮なんですが、このように整理をしてました。

（スライドを示して）左の図のチームは、自分から見ると課題はけっこういろいろありはするんですが、その課題に対する対処もちゃんと計画できていて、まぁ良さそうだなと思っていました。問題があるとすれば、そういう課題に対して対処ができているんだけど、一時的に人員が足りていない状況があったりして、マンパワー不足みたいなものが一応課題としてあるのかなと認識しました。

右のチームに関しては、企画的な戦略とか技術的な戦略の整合性が自分からはちょっとよくわからないと思うところがあって、そのあたりは整理していく必要があるんじゃないかなと思ったりしました。

ステップ3　課題をリスト化して管理する

という感じで、課題の発見はできたかなとなったので、次は課題を管理していくぞということになりました。先ほどの図ですが、ああいう図をふだんから使って業務を行っていくのはけっこう難しいかなと思うので、リスト化して管理することをしました。

そのリストを使って認識のすり合わせとかをしていけるとより良いかなと思っていて。一般的にそういうものって課題管理表とか、スクラムだと妨害リストとかと呼ばれているかなと思っていてそういう世間の知見を参考にしながら管理していけるといいのかなと思っています。

着手順についても、どうやって優劣を付けるのかということがあるかなと思うんですが、自分はアイゼンハワーマトリクスという考え方をけっこう参考にしています。

この中だと特に2番の「予定する」ということが大事かなと思っていて、「重要だけど緊急ではないもの」は、「予定することでちゃんとやっていこう」という考え方が特に大事なのかなと思っています。

緊急とか重要度という軸で整理していたんですが、「この場合の緊急って何ですか？」というと、まずは単純に締め切りが近いかどうかで考えていいかなと自分は思っています。

「重要って何ですか？」というのは、ミッション・ビジョン・バリューへの貢献が大きいかどうかで判断していいんじゃないかと考えています。

（スライドを示して）というところでリストに落とし込んだのがこういう感じで、「落とし込みました」という雰囲気を感じ取ってもらえればいいかなと思います。リストにして、自分のマネージャーとかと話をしながら認識をすり合わせたり、実際に課題を解消していったりをやっていました。

左のチームはマンパワー不足が課題で、右のチームは戦略的なところを整理する必要があるみたいなところを先ほど話しました。

自分はそういうリストを作った上で、まずはマンパワー不足解消を最優先でやろうかなという判断をして、具体的には雑用を引き受けようかなという判断をしました。

「EMと言いつつ、雑用やっているのっていいんだっけ？」みたいな気持ちはなくはなかったんですが、先ほどのように図に整理した結果、ここで雑用をやることによってチームがうまく回るだろうということが自分でわかっていたので、「大事だと思えるんだったらどちらもやったらいいのかな」と思って、「まぁやろう」と判断をしました。

その次に戦略の整理をやっていこうかなと思いました。本来であればたぶん企画的戦略のほうを先に整理するべきかなと思うんですが、すぐに整理することができなさそうで。整理できるまで技術的な戦略を放置するのもちょっと厳しいな、ないなと思ったので、並行してやっていこうという判断をしました。

ステップ4　世間や他のチームとのギャップをヒントに解決していく

まぁ、そんな感じでやっていこうというところで、どう解決していくのかというところです。ここは課題の範囲がすごく広いと思っているので、一概に「こうすればいい」みたいなことはすごく言いづらいと思っているんですが、世間や他のチームとのギャップに着目すると、ヒントが見つかることが多いなと思っています。

例えば当初立てた計画どおりに開発が進行できないような課題が仮にあったとして、そういう時に世間的には反復型の開発プロセスみたいなものがけっこう流行っているかなと思います。

別にはてながそうというわけではないんですが、例えば社内の他のチームを見てみた時に、「他のチームはすごくバッファを積みまくっているな」とかを発見できるかもしれないなと思っていて。そういうところをヒントにしてやっていけるといいのかなと思っています。

その「世間的には」というところは、自分は本から学ぶことが多いかなと思うし、社内のやり方みたいなものは、もしかしたらバッファを積みまくることで別の問題を誘発している可能性もあるかなと思うんですが、そこも含めて他のチームはどうしているんだろうということを見ていけるといいのかなと思ったりしています。

ただ、そういう「他の人はこうやっているから俺たちもこうやるぞ」みたいな、真似するだけはけっこう危ないなと思っていて。「なんかスクラムいいらしいぞ」みたいな。「やるぞ！」みたいなことはすごく危ないなと思っています。

解決法がちゃんと自分たちの抱えている課題と合っているかはちゃんと考えないと、効果がないことにすごくコストを割いて「なんか、何やっているんだろう」みたいな感じになってしまう懸念があるかなと思っているので、その解決法が本当に課題と合っているのかはちゃんと考えてやっていく必要があるかなと思っています。

4つのステップを行き来して「いい感じ」にする

というところで、最後にまとめです。最初のほうに表示したスライドと同じですが、「いい感じ」にしていくステップは、（スライドを示して）この4つがあるというふうに思っています。

この間を行ったり来たりしながら実際に進めていって、テクニックもいろいろと紹介したので、そういったところを使いながら「いい感じ」にしていけるといいのかなと考えているという発表をしました。

というわけで、自分の発表はここまでになります。ありがとうございました。