こんにちは、ビジネス開発部でマリッシュのPMをやっているcosmoです。
noteの登場は久しぶりなので簡単に自己紹介をさせていただくと、10年くらいエンジニアとして何でも屋をしたあと、2024年2月にNewbeesに入社しました。
入社当初はディレクター業務を担当しつつ、最近はNewbees初のPMとして主に進行案件の管理や開発体制の調整をおこなっています。
PM業務については、インタビュー記事もありますのでよければそちらもご覧ください。

今回は、業務の1つである「開発体制の調整」について、どんなことをやっているのか、今後どうしていきたいのかを紹介できればと思います。

はじまり

自分が入社して9か月くらい経った頃だったでしょうか。
Newbeesでは、そこそこ大規模なイベントがありました。マリッシュと別のプロジェクトとのメンバー入れ替えがあり、主にエンジニアメンバーがガラッと変更になったのです。
メンバーが変わればやり方も変わります。というより、変わったほうが良いと個人的には思っています。善は急げ。当時はまだPMと呼ばれていなかった私は、新体制発足に伴い、開発のやり方も考え直そうと動き始めました。
新しいメンバーにも相談しながら、「どうせ変えるならガラッとアジャイルに寄ってもいいよね」という流れになったのは、昨今の開発チームであればおかしな話ではないでしょう。
今から話すのは、そんな流れの中で「スクラム」に挑戦して失敗し、それでも諦めずに「自分たちのやり方」を模索したチームのお話です。

当時の状況

とかなんとか格好良さげな導入をしてみましたが、現実はここまでプロジェクトXみたいな感じではありません。
メンバー入れ替えがあった頃、大型案件が立て続けに入っていたり、AIを用いた新機能開発を進めようとしていたり、マリッシュとしても挑戦が必要な時期でした。
挑戦すると壁が見つかります。マリッシュでは、大きく3つの問題に直面していました。

これらを解決する手段として、アジャイル開発が適しているように見えたというのが、開発体制を変更するのに踏み切った一番の理由です。

スクラムをやってみた

アジャイル開発手法の解説については、先人の解説が調べれば山ほど出てくると思うので割愛させていただきますが、マリッシュではその中の「スクラム」を軸にやっていこう、という結論になりました。……が、結果から言うと、この試みは失敗します。
マリッシュチームは、エンジニアはもちろん、デザイナー、QA、そしてディレクターと、明確に役割を持ったそれぞれのメンバーが、自分たちの領域で力を発揮し、連携しながら課題に取り組んでいます。
そもそもこの体制自体が、スクラムによるアジャイル開発とは相性が悪かったというのもありました。

などなど、実際にやってみるといろいろな問題が浮き彫りになります。
案件を進めるペースも上がらず、メンバーの意思疎通も取りづらくなり、どうにも良くない感触のまま課題に取り組むという状態に陥ってしまいました。

基本に立ち返ってみる

「これはよくないな」と誰もが感じていたと思います。
PMとしても、スクラムのまま何かを変えれば良くなるという道筋は見えていませんでした。
そこで一度立ち止まり、経営層やリーダーと話し合いの場を設けて、「そもそもなにがしたかったんだっけ？」というゴールの再確認をおこないました。
本当にやりたかったのは、「エンドユーザーにできるだけ早く触ってもらって、実際の反応を見て改良する」サイクルを回していくことです。
内容だけ見れば、アジャイルの原則そのものです。ただ、スクラムという形は、今のマリッシュの体制にはあっていないのはやってみて分かりました。
リーダーと話していく中で、「やりたいのはアジャイル開発とかスクラムじゃないよね」と改めて確認をし、マリッシュチームが活き活き動ける体制を作っていこうと志を新たにします。

たった1つではないけど私たちにとって冴えたやり方

スクラムでの開発中、反省点は多かったものの、好意的な意見も挙がってはいました。
一番は、デイリースクラムなどを通じて他部署のメンバーとの交流が増え、些細なことも聞きやすくなったというものです。
また、案件を細かく分割して少しずつ対応する……といった流れも、方向性としては概ね好評だったと感じます。
しかしながら、全体で見るとマリッシュは受託開発であり、BPからの発注書に基づいて要件定義をおこなうところからスタートします。そこである程度設計をおこなったうえで、デザインをして、実装・検証に進む、というウォーターフォールのやり方があってはいました。
ただ、ガチガチのウォーターフォールは進行速度を遅らせる上、柔軟性にも欠けてしまいます。
そこで、「やり方のベースはウォーターフォールにしつつ」「好意的なスクラムイベントは取り入れる」という方向性で調整していくことにしました。

と言う2点を重視しました。
ウォーターフォールを軸にはしていますが、設計と同時にデザインを進めたり、デザイン中にバックエンドの処理を実装しながらテストケースも作り始めたり……と、ある程度並行で進めています。
完全にどちらかに振り切らない「ハイブリッド方式」にすることが、今のマリッシュでもっとも効率的に開発できる体制だと思います。

現在の開発フロー

上記を実際の開発フローに落とし込んだのが、以下になります。

また、GitHub Issuesで作成しているEpicについて、より管理しやすいように運用ルールを定めました。

やってみてどうだったか

定量的な成果として、1度の定期リリースで対応できる数が増えました。
具体的に言うと、メンバー入れ替えしてすぐの頃は1月平均5件程度だったものが、現在は平均10件程度になっています。
もちろん、メンバーの理解度が上がっていたり、部署ごとに作業の効率化を図った結果が大きいのですが、開発のやり方を変えたことがその一助になっていると嬉しいなと思います。
また、メンバーにアンケートを実施して、現在の満足度など、生の声も聞いてみました。
まずはシンプルに「今の体制に満足しているのか」の5段階評価です。

「とても満足」：3名、「満足」：8名と、回答者16人のうちの7割弱が満足してくれており、新体制は概ねポジティブに受け入れられていることが分かりました。PMとしても一安心です。
具体的にどのようなところでポジティブに感じているかも聞いてみました。

• Epicごとに最小チームで動くため、意思疎通が取りやすくなった
• キックオフで認識合わせができ、手戻りが減った
• ガントチャートでスケジュールが確認しやすくなった

ウォーターフォールでありながら、スクラムで得た知見を活かしてコミュニケーションを取りやすい環境になっているのかなと思います。

反面、課題についても色々な意見が出てきました。

• ミーティングが多く、実作業時間を圧迫している
• ステータスの更新忘れなど、担当子Issueの管理が煩雑
• チームごとにやり方が違って分かりづらい
• 極端な並行作業に懸念

ミーティングについては、確かに以前より増加しており、個人的にも見直しできる内容だな……と感じていました。
進捗報告会などは、デイリースクラムに引っ張られ毎日開催になっていた部分もあり、チームによりますが、現在は週1〜2回の開催に落ち着いています。ミーティングとしてはその程度の頻度でも、Newbeesの社風として「Slackでのコミュニケーションが活発」「部署の垣根なくハドルミーティングですぐ会話ができる」環境があるため、意思疎通ができなくて困るという事態にならないことが大きかったなと思います。

今後取り組むこと

アンケートで出た意見を元に、直近では下記の取り組みを実施予定です。

今の形が最適だとは思っていないので、定期的にアンケートを実施しながら、随時やり方を見つめ直していきます。

まとめ

体制変更をおこなったことで、開発効率は間違いなく上がっており、メンバーの満足度も向上していました。
個人的には、なかでも「コミュニケーションが取りやすくなった」と言ってもらえたことが大きいなと感じています。
マリッシュチームは現在30人程度の規模ですが、今後さらに拡大していく見込みです。
それに伴い、また壁にぶつかったり、今のやり方が通用しなくなることもあるでしょう。
もしそうなったとしても、かわらずメンバー間のコミュニケーションが取れることが、解決に一番必要なことだと考えています。
そのために、今後もメンバーが気兼ねなく相談できる、そんな環境を継続していけるようにこれからも頑張っていきます！

最後まで読んでいただいてありがとうございました〜。
メンバーとコミュニケーションを取りながら、一歩一歩進んでいくマリッシュ開発の現場にもし興味を持っていただけたら、是非ご応募いただけると嬉しいです！