モブプロを軸としたスクラム開発に参加して悩んでいた話

はじめに

 こんにちは、社会人2年目のざーです。

 私はこの1年間、モブプロを中心としたスクラム開発に取り組んできました。その中で、思うようにいかないことや壁にぶつかることが多く、悩む場面が何度もありました。解決策を探しても似たような立場の人がどのように対処しているのかを具体的に書いた記事があまり見つからず、どうすればいいのかわからず困った経験があります。 

 そこで、この記事では私自身が直面した課題やその原因、試行錯誤しながら実践してきた改善策をまとめました。スクラム開発のスタイルや環境はチームによって様々ですが、同じように悩んでいる方にとって、少しでも参考になれば嬉しいです。

自分のバックグラウンド

  • 情報系とはまったく関係のない分野の学部出身
     ITという分野の学びとは無縁でPC系は昔から苦手です、なんだったら今も変わらずです…。
  • 入社後の数ヶ月間はjavaやreactを用いた実装の研修を経験
     めちゃくちゃここらの研修では苦労してました。オブジェクト指向?はぁ?わからんわからんと講師の方やサポーターの方に毎日泣きついてました。
  • 研修が終わった後、2024/1月からスクラム開発に参加
     ベテランや最低でも5年目以上の先輩がいるチームの中に1人参加することとなりました。そこからWeb申し込みアプリのセキュリティ周りやDesignToCode、VR、AIなどと言った領域にこの1年間に関わってきました。
     一般的なスクラムでは、プロダクトの機能拡張や改善を継続的に行い、ある程度技術スタックが限定されることが多いかと思います。しかし私が参加してきたチームでは幅広い技術領域に関わっていたため四半期毎、場合によってはスプリント毎に扱う技術ややることが大きく変わることがありました。

何に悩んでいたか

 開発の経験も浅く、できることも限られる自分がせめてこういうことはしていこう、できるようになっていこうと考えていた理想と、現実のギャップに対して悩んでいました。

自分の中の理想

質問をどんどん積極的に行って活発に参加する
取り組んだ内容を確実に自分のものにでき、自信に繋げる
チームに少しでも貢献できる

実際に直面した現実

活発に参加できていない
成長が実感できない
貢献できていない

 このギャップが生まれた理由としてモブプロ、スクラム開発のそれぞれの特徴が関わってきていたので詳しくお話したいと思います。

ギャップを生んだ要因

①モブプロ中の質問を実行する際のハードル

 あるあるですね。リアルタイムのコミュニケーションが求められるモブプロで、人数がいる中、チームの会話の流れを断ち切って質問を行うハードルの高さはそれなりに感じていました。

 加えてタイミングや時間的プレッシャーも加わってより発言しにくい状態を自分で作り出していたのかなと思います。
この点は後でもう少し詳しく話します。

②モブプロ中の「わからない」の解消の難しさ

 経験が浅いとチームの取り組みや会話でぼんやりとした疑問は浮かぶものの、何から聞けば良いかわからなくなることが多いと思います。そういった時こそ周りには頼れる仲間がいますからモブプロのメリットが発揮されますよね。

 ただ、闇雲に聞いても知りたい部分や理解するためのポイントを押さえられていないので結局解消できなかったり、時間をとってしまったりということに繋がりがちです。
 また、知りたい部分や理解するためのポイントを洗い出してから質問しようとしても、その間に話が進み聞けずじまいに、、、なんてこともザラにあり、モブプロの効果をうまく活用できていない感じがしてました。

 質問をする際のハードルと合わさって学ぶということはおろか、チームの取り組みへのキャッチアップが難しい状態になりました。

③スクラム開発の柔軟なスタイル

 スプリント毎に取り組む内容が変化する場合があるため、一つのことについて深く学び続けることが難しく、キャッチアップにも苦労していました。
 身についた知識を次に活かす機会があってもかなり先となってしまい、記憶が薄くなっている状態が多々ありました。そのため新しい知識が「点」としても残りにくく、いつまで経っても「線」として繋げずにいるような感覚でした。

④時間的プレッシャー

 ストーリーポイントに基づいたタスク見積もりがあると、質問したりドライバーを担当したりした際に時間を多くとってしまった場合、DSの度に進捗具合を見て「自分のせいで遅れてしまっているな。。」というプレッシャーを感じやすくなります。
 個人的にできる作業であれば困るのは自分一人ですが、モブプロの中だとその人数分の時間も奪っちゃってないか考えすぎてしまい、その考えが自分の行動を制限するといった流れを生み出すこととなりました。結果活発な動きを制限し、貢献もできていないと言った悩みに繋がりました。

⑤未経験のためできることがかなり限られる

 ドライバーの役割を経験しましたが、指示通りにコードを打つだけの「ラジコン状態」になりがちでした。
 アイデア出しなどの発言の場面でも的外れだったり、とんちんかんなこと言ってしまわないか心配になるため言えても当たり障りのない意見を言うことしかできない感じがし、意見の発信量が増やせずにいるといった状態になりました。

そして上記の①、②、③が相まって成長できずにいるなと思っている中、果たして自分はこのチームや作るプロダクトの「何か」になれているのか段々と疑問に思うようになり、焦燥感が付き纏うようになりました。

改善のために実践したこと

①質問のタイミングを作り出す

 モブプロ中に質問しやすい場面を意識的に作るようにしました。タスクの切れ目や作業の合間のちょっとした沈黙などに注目してみると、意外と質問できるタイミングは多くあることに気づきました。何かしらのアクションが一区切りついた瞬間は自然と話が途切れることが多く、質問を挟みやすいと感じましたね。
 また質問のしやすさをより高めるために、モブプロのドライバーを積極的に引き受けることを意識しました。ドライバーの役割では、コードを書く際に「次にどうするか?」をナビゲーターに確認する機会が多くなり、自然と質問しやすい環境が生まれました。実装の手が止まったとしても「ここがわからないのですが、、」とすぐ尋ねることで周囲も質問を受け入れやすい状況になったかと思います。個人的に一番質問しやすい状況になるためおすすめです。

②疑問に対して優先度をつける

 「今すぐ必要な理解」と「後回しにする理解」を分けるようにしました。またぼんやりとした疑問も、ざっくりとどこでどんな感じでわからなくなったかメモして後で見返せるようにしました。
 そのため直近の取り組みで必要なことを質問し、それ以外は後回しにすることで作業に集中しやすくなりました。
 疑問に対して悩む時間を変えたことで、目の前の作業には集中でき、また見返した際にゆっくり何を質問したら良いか考えられるようになったと思います。これは後!って思いっきり割り切るのが良かったですね。

③学んだことを繋げる工夫

メモの活用

 学んだことをメモするときはやり方だけで無く、なぜそれをやったかなどを軽く残しておくと、後で見返した時に思い出しやすくなりました。
 またすぐに見返せる環境にしておくのも大事です。いつも作業中はアプリのメモ帳を開き前にやったなっていうことがあった場合すぐ検索して見返すことができるようにしてました。紙でメモっておくと探すの大変なのでアプリ使った方が楽です。 

 学んだことだけじゃなく、不安や何に疑問を持ったかなど自分の中から浮き出たことをメモするようにもしてました。後から見返した時に当時はこの知識が足りなかったからこう悩んでいたのかという当時との比較ができるようになり、見返すのが楽しくなるのでおすすめです。

他者に共有して理解を深める

 学んだことをチームメンバーに共有することで、自分の理解度を客観的に確認できました。どこまで理解できているか、どこが曖昧なのかが明確になり知識の定着にも繋がります。
また他者に伝えることで「ちゃんと理解できてる!」と実感し、自己肯定感が上がる効果もありました。

④他者やチームに正直に悩みを相談する

 自分の状態を正直に伝えることで、考えの整理ができました、当時はうまく言語化できていなかった部分もありましたが、他の方の視点やアドバイスを通じて理解を深めることができました。
 また、チームも悩みに対して柔軟に対応し、改善策を一緒に考えてくれました。その結果以下のような取り組みを試すことに繋がりました。

  • ソロプロの導入:個人のペースでじっくり考え、学習し、質問を練れる時間を確保
  • ワーキングアグリーメントの設定:キャッチアップしやすい環境を整備

こうした工夫により、少しずつチームとの関わり方や学び方を改善できました。

もっとこうすれば良かったと感じること

質問時間をタスクに含めてもらう

 各スプリントごとに、あらかじめ「この時間分は質問に充てる」とチーム内で設定してもらうイメージです。質問に使用できる時間を明確に決めておくことで「この時間分は自由に質問していいんだ」と安心感が生まれたのではないかと思います。
 また時間を気にして質問を躊躇うことが減り、タイミングを見計らうストレスも減っていたんじゃないかと考えたためやってみたら良かったと思いました。

メンバーから自分に質問をしてもらう機会を多く作ってもらう

これを実践することで得られるメリットは以下4つかなと考えてます。

  • 自他共に理解度の確認ができる
  • 要点整理の練習になる
  • 視点の違いに気づける
  • 知識の定着につながる

この記事を書いている途中で思いつきましたが本当にやっておけば良かったと思いました、、。

最後に

 この記事では、私が所属しているチームのスクラム開発のスタイルや、私自身が理想とする部分の話を交えながらお話ししました。そのため、チームごとのやり方の違いや、私個人の考えが反映されている部分もあり、読みにくい点や共感しずらい点があったかもしれません。

 それでも、この記事を読んでくださった方が、「こんな考え方もあるのか」「この工夫を取り入れてみてもいいかも」と少しでも参考にしていただけたら嬉しいです。

読んでいただきありがとうございました。