アジャイル開発の導入とチームの変化。既存プロダクトの改修作業が円滑に進む理由

こんにちは、株式会社フォーイットです。2010年4月1日に設立した当社は、2022年10月の時点で従業員数が159名まで増え、まもなく創業から13年を迎えようとしています。
当社の技術統括事業本部がアジャイル開発を導入した経緯を記事化することにしました。
本記事は技術統括事業本部の本部長であるWと、スクラムマスターとしてプロダクトのリニューアルに関わるAの対談をもとに作成しています。

※ここでは、アジャイル開発の内容や手法にはほとんど触れません。アジャイル開発を学びたい方は「アジャイルサムライ−達人開発者への道−（オーム社）」「Team Geek ―Googleのギークたちはいかにしてチームを作るのか（オライリージャパン）」「SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発（翔泳社）」などの素晴らしい書籍をぜひお読みください。私たちもこれらの書籍を大いに参考にしました。

アジャイル開発導入の経緯

導入したい事業部長 vs 導入したくないメンバー
Wさんはかねてからアジャイル開発を導入したいと考え、3〜4ヶ月にわたって事業部に「アジャイル開発を試したい」「導入してみようか」と働きかけていましたが、導入したくないメンバーもいました。
アジャイル開発を導入したきっかけは、Wさんのアジャイル推進熱から開催に至った「アジャイル雑談会」でした。Wさんは、以前当社で長らく勤務をしていた開発者のFさんと継続的に連絡を取っていました。Fさんがアジャイル開発の推進を経験した話を聞いたWさんが、Fさんにも参加してもらい、アジャイル開発とは何か、どのようなものか、などを話す座談会を開催しました。

1人に深く刺さった「具体的な体験談」。
アジャイル座談会を開催したものの、チームメンバーのリアクションは「正直かなり反応が悪かった」と言うWさん。しかしこの座談会が深く刺さった人がいます。それがAさんでした。
「確かに全体のリアクションは悪かったですね。僕もアジャイル開発については、知識はありましたし、他のメンバーも知っているはずです。開発者であれば『知識として知っています』という人がほとんどだと思います。しかし座談会で、Fさんが『具体的な体験談』を話してくれました。これが大きかったです」。
実際の体験談を聞いたことで「うちのチームでもできるのではないか？」と考えたと言う、Aさん。
この後、スクラム開発の本格導入が開始されました。

スクラム開発を導入した際にポイントになった2点

スクラム開発は試すことが常にあり続け、試しては振り返る、これを続けるものです。しかし「これだけやっていればいい、これだけやっていればうまくいく」というものでもありません。

やり方通りに実施する
当社ではスクラム開発の導入時に、スクラム開発のやり方通りに推進することを意識していました。最初から自分たち流のアレンジをするのではなく、まず、スクラム開発の先人が書籍などで解説しているやり方通りに導入し始めました。

「完璧を目指すとうまくいきませんが、最初からアレンジしてもうまくいかないと判断し、先ずは型を守りました」とAさん。

スクラム開発の経験がある人がいる場合、参加してもらう
この点は再現性が難しい部分もあるかもしれませんが、当社の場合はFさんが業務委託としてほぼ社員と同等に、同じ時間帯で働いて、入り込んで、密にコミュニケーションをしていただきました。

今回はFさんに入っていただき、一緒に動く、同じことに同じように取り組んでもらう、これが当社のスクラム開発導入と浸透にうまく作用しました。

WさんもAさんも「積極的に自分事として動いてくれる有識者が入ってくれたのは非常にありがたかった」と言います。

参考記事：かつての社員を大歓迎したチームと、快諾したかつての社員のストーリーはこちら

今後の当社のスクラム開発と体制について

今はアジャイル開発を導入できているのはエンジニアのみであり、ビジネスサイドを巻き込めていません。「今後は、プロダクトに対して関わる人が、エンジニアや営業など部門に限らずアジャイルな形になっていくと良いのではないかと考えています」とWさん。

「開発部門ではアジャイル開発が浸透しつつあることが、エンジニア達にも体感としてあります。そのため、プロダクトを主語にしたときの事業全体にアジャイル開発を導入し、推進できるような体制になるとさらに多くのことが加速するような気がしています」。

アジャイル開発がチームを変えた

当社が推進をしてきたアジャイル開発手法は、小さく作っていく手法です。2022年4月以降の動き方は「試してみよう」「とりあえず、作ってみよう」という体制になりました。

まずは作る
「何を作るか完璧に決めることはできません。実際に作ってみてからわかるため、まずは実際に作ってみるチームになりました」。とAさん。

アジャイル開発を導入した結果、問題提起や情報共有の機会が増えました。サイクルが小さくなった結果、コミュニケーションの頻度も必然的に高くなったためです。

もともと存在していた問題が解決した
これまでチームには、属人化問題が発生していました。開発者が1人で開発を実施すると、その後の運用が最もうまくできるのもその開発者でした。しかし、特定の人物に頼る属人化は、結果としてチームのコストになります。

これを解消するためにDiscordやSlackのペアプロ、モブプロを導入。導入直後からしばらくは教育コストがかかりました。「チームメンバーの増員が相次ぎ、新しいメンバーの方が多くを占める時期もあり、その時にはさらにコストがかかりました。しかし中長期的に見ると属人化も教育コストも減っていくことが見込まれていました」と話すWさん。

「2022年は、細かい作業でも一緒にやるようなことも多かったです。しかし何を一緒にするのか、何を一緒にやらないのか、回数を重ねてチームの体験を通して理解が深まりました。今は、体験を通した判断ができるようになっています」。全てやってみたから、コミュニケーションの総量が増えて、チームで取捨選択の判断ができるようになった、とチームの変化を語るAさん。

アジャイル開発を導入した人の体験談を聞き、導入した結果、Aさんはアジャイル開発導入の体験談を話す側になりました。

自律したチームになった
自律した組織になり、技術的なことを各自が収集して情報が集まり、共有される情報なども多く、アウトプットも多い組織になりました。

実装方法もアプローチ方法も、調べると複数の手法や情報が出てきます。その案の中で優劣をつけ、時間や人時などのコスト計算をして比較し、目標を立てることができるようになったと言います。

またこれまでは「セキュリティリスクが見出されたから、じゃあ実装しよう」とする進め方でした。対処しなければならないことが発現し、その対処や解決に取り組むやり方です。しかしチームは「これ、やった方がいいよね？」で止まっている物事に目が向く組織になり、それらがプロジェクトになり、進む組織になりました。

「止まっていたことやなんとなく手をつけずにいたことに気づき、気づきが共有され、取り組まれるサイクルが起こり続けています。私はアーキテクト選定にも口出しはしません。チームメンバーと一緒に考えます」と話すWさん。

2023年度はどのようなチームでありたいか

技術統括事業本部は2022年の4月にビジョンを共有し、主力プロダクトである「afb」の改修を進める体制が整い、実際に改修を進めてきました。

「afb」の改修とリニューアルのストーリーはこちら

では2023年度はどのように開発を推進をしていくのでしょうか。

ビジョンとKPIを見つける組織
2022年度はビジョンとKPIが明確になっていなかった、定めるのが難しかったという経緯もあったため、2023年度はそれを自主的に見つけることができる組織にしたいと考えています。

Wさんはこう話します。「事業継続性の高いプロダクト・収益性の高いプロダクトを継続するために必要なKPIを自分で作ることができる人や、チームでありたいです。エンジニアとして開発をすることに合わせて、ビジネスに対しての指標を考慮しながら推進できるチームを作りたいです」。

「今は困り事がなく、トラブルも起きておらず、チームとして良好に凪いでいる状態です」と、Aさん。「しかし、問題がないわけではないのだと思います。別の困り事や問題に、ぜひ直面したいです。それを経て、またチームとして発見や新しいことを試すようなフェーズを体験できると思うからです」。

技術統括事業本部は、2023年も各種開発に鋭意取り組んでまいります。ぜひこのチームで一緒に働きませんか？少しでも気になった方は、まずカジュアルにお話ししましょう！ご応募をお待ちしています。

参考記事：技術的負債と複雑性の解消に向けたプロダクト改修とリニューアルの並行戦略についてはこちら