個人からチームへ。アジャイル開発への最初の半年間の取り組み
TECH
2022.12.27
更新日:2022.12.23
公開日:2021.03.26
PLAN-Bに入社して、2年の月日が経ちます。入社してすぐに自社プロダクトSEARCH WRITEの開発チーム立ち上げにジョインしました。現在はそのチームのリーダーとして、もともと興味のあったアジャイル開発に力を入れる日々です。前職も合わせてエンジニアとして働いてきた4年間を振り返ってみると、やっと自信を持って仕事に取り組めるようになったと感じます。社外イベントに登壇する際は「こわがりエンジニア」を自称するほど、自信のなさから立ち止まってしまいがちな私ですが、少しずつ自分が変わっていけたことで今ではSEARCH WRITEの中心に立ち、チームを引っ張っていく立場になれました。
この記事を通して、チームで働いている中で自信が持てない、こわがりな人に向けての応援メッセージを届けたいなぁという想いがあります。小さな行動が自信に変わっていくという学びを本記事にまとめていき、悩んでいる人の背中を押せればいいなと思います。
私がPLAN-Bに入社した当時は右も左もわからない中で、SEARCH WRITE立ち上げ時の開発メンバーとしてチームにジョインすることになりました。当時のSEARCH WRITEメンバーは若手の自分以外、全員ベテランエンジニアでした。技術力には自信がありましたが、経験の差や社歴の差から臆病になってしまったことを覚えています。
チームで話し合いをするときに、自分の意見を伝えるのが怖くて発言ができなくなってしまうことが多く、チームの一員として役に立てていないという焦りが日に日に大きくなりました。この状況を打破しないとチームにバリューをもたらせないと思い、まずは意見が言える自分になろうと考えました。ただ、自分を変えていくというのは一朝一夕にできることではありません。まず、自信が持てない自分でも取り組める行動を探し始めました。
なぜ自分が発言できないかを深堀りしていくと、2つの理由があることが分かりました。1つ目は「自分の意見が正しくないかもしれない」、2つ目は「間違ったことを言ってしまった時に周りにどう思われるか不安」というものです。1つ目の「正しい意見」かどうかはチームに当ててみるまでそもそもわからないことも多いです。ただ2つ目の「周りにどう思われるか不安」はチームと自分の問題です。そこで、自分が発言しやすい環境を作るために、味方づくりを始めました。
味方づくりとは、チーム全体に意見を伝えるより先に、チームの中の一人に自分の考えを事前に伝えておくことで、チーム全体の前でも発言しやすくするというプラクティスです。チームの中に少なくとも一人は自分の意見を知ってくれている人がいる、という事実が安心感をもたらしてくれます。こんな小さな習慣でも、自分にとって発言しやすい環境を作り出すことができます。チームに意見を伝えられるようになった結果、やっとチームの一員として働いている実感を持てるようになりました。
大勢の前で発言することが怖い人には、味方を作ることが発言のしやすさを格段に上げてくれるこのプラクティスをおすすめします。
チームの一員として意見を述べることができるようになり、開発もある程度軌道に乗ってきた頃、別プロダクトの立ち上げにあたりメンバーが別チームに移動することになりました。抜けるメンバーは前述の「味方づくり」でよく相談していた人たちだったため、これは私にとって大きなダメージを受ける事態でした。気軽に味方づくりができない状況に陥り、他のメンバーとも意見のぶつかり合いなどが続く中で、自分だけが勝手にチームから遠ざかって孤立してしまいました。チームを信頼するということを一切忘れ、独りよがりな働き方をする日々が2か月も続きました。
ただこのとき私は決して「もうこのチームと働きたくない」と思っていたわけではなかったのです。むしろ、どうしたらまた一緒にチームとして働けるのかを考えていたのですが、何も行動を起こすことができずモヤモヤしている状況でした。
ある日のふりかえりでのこと、ファシリテーターが私に話を振ってくれたにもかかわらず、私はモヤモヤしたままの感情を言語化できず、自分の考えや思いを何も言うことができませんでした。その時、「何も言わずに参加しているのは無意味だし、不健全だ」と気づいたのです。このままでは駄目だと思い、自分の今の気持ちを別のチームに行ってしまった人に泣きそうになりながら相談しました。結果、感情の整理をして、チームに対して今抱えている不安や不満をぶつけるお手紙を、チームのメンバーの前で発表することにしました。
味方作りのプラクティスによって仕事上の考えを伝えることはできるようになっていましたが、更に踏み込んで自分自身の感情や思いを話すのが苦手な私にとって、それはとてもしんどい時間でした。しかし、手紙を読んだことで明らかにチームと自分の関係が変わり始めました。触発されて他のメンバーも自身の思いを語ってくれる会になり、私自身反省すべきところが多くあることがわかりました。お互いの思いをオープンにしたことでメンバー間の距離が縮まり、改めて一つのチームとして働けるようになりました。
PLAN-Bで働く前は「仕事は仕事と割り切り、感情的なものはできるだけなしにしよう」と思っていた私にとって、手紙を書いたというのは自分でも驚く行動でした。仕事であっても、人と一緒に働く中で感情というものはとても大切だと学んだできごとでした。内心で誰かを責めてしまう状況を放置せず、お互いの想いを伝えあい理解しあうことで、自分自身の改善点も知ることができて視野が広がります。そして不満を溜め込まないことでメンバーが前を向けるようになり、チームの力がより発揮できるようになりました。
チームで働くということは人と人のコミュニケーションが必須になります。今では、何かうまくいかないことがあったりすると、まずは相手がどう思っているのか聞き、自分の思いを伝え、これからどうしていくかを話し合うようにしています。
チームで働いていく中で課題になるのは属人化です。私たちのチームも例外なく、この問題に悩まされました。誰かが抜けると、チームとしての活動が困難になってしまう状況でした。トラックナンバー(※1)が1の状態です。この状態で開発を進めていくのはリスキーでしたが、見て見ぬふりをしてしまいました。
例えば、ある時点から設計をする人が私しかおらず、他にアーキテクチャの全体像を把握する人がいなくなっていたことに気がつきました。「設計は高橋に聞かないと分からない」という状況では、私一人がボトルネックとなって負荷がかかり、結果として開発全体に遅れが出てしまう状況に陥りました。
このままではいけないと思いつつも、この問題を一撃で改善する案が見つかりません。何かアクションを起こそうにも、失敗が怖くてずっと悩んでいました。弊社では週1でチームとまたがってスクラムマスター達と相談ができる場が設けられていたので、この問題について話をしてみました。そこで「いわゆる一発逆転の『銀の弾丸』を求めるのではなく、まずは小さなことから。例えば、1週間で確実にできるアクションをしてふりかえってみれば?」という助言をもらいました。
早速問題を切り分け、1週間でできる小さなアクションをしてみることにしました。まずは1週目、メンバーの1人に設計プロセスを丸投げしてみました。結果は失敗でした。「設計が属人化していて現状のアーキテクチャが把握されていない」という状況が、ここで明るみに出たのです。
この結果をふりかえり、2週目は理解を深めてもらうために2人で一緒に設計を行いました。ペアプログラミングの要領で、メンバーの1人にナビゲーションしてもらいながら、私はドライバーをするという役割分担で設計を進めていきます。時には私から助言も行い、2週目の終わりにはそのメンバーが設計について理解できている状態になりました。設計プロセスの属人化解消に向けて一歩前進です。続けて他のメンバーも1人1人巻き込んでいき、チームの誰でも設計ができるようになりました。
ここでの学びは、「ついつい銀の弾丸を探してさまよってしまいがちだが、大きな課題の改善は小さなアクションによる改善の積み重ねによって達成される」ということです。小さなアクションを行って失敗したとしても、次のアクションを設計する時にそれを役立てれば良いのです。失敗することは正直怖いですが、失敗ではなく学びと受け取ることで怖さを解消できます。何か課題を抱えているものの改善する案が見つからない・案はあるけど失敗をするのが怖いという人は、やれることを細かく区切ってみてください。ほんの小さなアクションを計画・実行し、定期的にふりかえりながら次に活かすというサイクルを回すことで、どんどん問題が改善されていくと思います。
※1 トラックナンバー… プロジェクトのメンバーの内、トラックにひかれるとプロジェクトが継続困難になる人数
PLAN-Bに入社して、ふりかえってみると「チームで働く」という意識がとても高まった2年間でした。今でも以下の4つのことを意識しながらプロダクト開発チームを作っています。
技術力も大事ですが、チーム力も大事です。私はこわがりなので動き出すのに時間がかかりましたが、お互いに働きやすい環境を作っていくことでチーム、そしてプロダクトにいい影響を与えていると思っています。