この記事は All About Group（株式会社オールアバウト） Advent Calendar 2020 24日目の記事です。

はじめに

こんにちは、Webアプリケーションエンジニアの @jnamix です。

普段の業務では、アジャイルの方法論を取り入れたチーム開発を行っています。
そんなチームのメンバーの一人として仕事をしていく中で、モヤモヤを抱くことがあります。

例えば、メンバーとペアプログラミングやモブプログラミングをしている時。

「ここの実装って本当にこれでいいんだっけ？」
「『とりあえずやってみる』という流れになったけれど、行き当たりばったりに感じる……」

私は細かなことを気にしてしまう性格で、こうしたモヤモヤに直面することが多くありました。
もちろん、こうしたモヤモヤをチームに共有することで業務やアウトプットの改善に繋がれば良いのですが、そのモヤモヤを上手に言語化できなかったりすると、かえってチーム内に混乱を招いてしまうことがあります。

そこで今年は、自分がモヤモヤしすぎないために、そしてモヤモヤしてもきちんと言語化できるように、以下の3つのことをトライしてみました。同じような課題を抱えている人の参考になれば幸いです。

その1. 日記を書いてみる

チームでの振り返りとは別に、個人的な振り返りとして、日記を書く習慣を付けました。

その日に抱いた素直な気持ちを言語化しておくことで、どんなところにモヤモヤを感じるか（同時に、どんなところにやりがいや嬉しさを感じるか）を把握することができます。それをもとに、次の日からのアクションについて方針決めすることもできるため、オススメの手法です。

その2. 仮説思考でやってみる

プロダクトの開発をしていて技術的にわからないことなど、不確実なことの壁に直面した時、どうすれば良いか分からずモヤモヤしたり、解決手順の完璧さを求めて調査の長い旅に出てしまったりして、作業の手が止まってしまうことがあると思います。
チームで動いている場合は、こうした不確実な課題に対して「とりあえずこの方法でやってみよう」という流れになり、今度は「行き当たりばったりになりそうだ」と感じてひとりモヤモヤしてしまうこともあるでしょう。

そこで取り入れたいのが経験主義に基づく仮説思考の考え方¹です。

調査や勉強を通じて理解しておかなければならない理論やルールももちろん存在しますが、仮説を立てて実際に行動し、検証してみないとわからない課題も多く存在します。検証の結果、たとえ仮説が正しくなかったとしても、「立てた仮説が正しくなかった」という事実が明らかになり、次のアクションに繋げることができます。
私は実際にこの考え方を取り入れて、作業の手を止める機会を減らすことができました。チームで動いていてどうしても引っかかるところがある場合は、メンバー同士で検証したい仮説を確認して、そのためにできること（＝自分たちがコントロールできること）を整理しておけば、チーム全体でもレベルセットができてなお良いです。

その3. 一旦、設定したゴールのことだけを考えてみる

ある要件（ゴール）の達成を目指して開発を行っていると、その途中で「そもそも、ここの画面遷移やメッセージの内容ってこれで良かったんだっけ？」などと、追加の課題を発見することがあります。これらの課題もまとめて解決すれば、さらなるサービスの改善につながるので、とても良いことに見えます。
しかし、そうした課題が発見されるたびに検討を繰り返していると、課題が散らかってしまって、当初のゴールが見え辛くなるモヤモヤに陥ります。本当は「登録フォームに項目を追加したい」だけだったのにも関わらず、それに向けては一歩も進めない状態になってしまうのです。

そんな時は、発見した課題を別途メモしたり、作業チケットとして追加しておいたりして、一旦横に置いておくのが有効です。そして、設定したゴールのことだけに集中して検討や開発を進めていきます。それでも課題がいくつも見つかりそうな時は、検討する時間をまとめて作ると良いでしょう。
この考え方は最近まで意識できていなかったことですが、チーム全体で実践する機会があり、結果として前に進むことができました。「そもそものゴールってなんだっけ？」と立ち返ってみることの効果を実感できた瞬間です。

終わりに

今回は、細かなことを気にしてしまう性格の自分がチーム開発におけるモヤモヤを軽減させようとトライしたことについて、3つ紹介しました。

日記を書いてみる
仮説思考でやってみる
一旦、設定したゴールのことだけを考えてみる

これらの3つはチームメンバー個人としてできることですが、チーム内での振り返りや1on1の機会があるのなら、それを活用して「こんなモヤモヤがあるよ」と共有することもやはり大切だと思います。メンバー同士で同じ考えを持っていることに気付いたり、新たな気付きを与えたりすることで、より良いチームにするための議論に繋げられるからです。

一人で抱えこみすぎず、良いチーム開発ライフを！
ここまで読んでくださりありがとうございました。

経験主義と仮説思考に関しては、広木大地氏の『エンジニア組織論への招待』が参考になりました。 ↩