SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2023 セッションレポート(AD)

オフショアから内製化へ、スクラム開発を導入し生産性を最大化するには?

【10-B-7】スクラム開発を導入し開発生産性を最大化するまでの軌跡

  • このエントリーをはてなブックマークに追加

ストーリーポイント導入とQAチームの強化で作業量と品質を改善

 「内製化の中期には、採用を進めて社員も増えてきたので、バックエンドを皮切りにオフショアから社内にちょっとずつ開発を切り替えていきました。」

内製化中期の開発プロセスと組織開発組織の改善
内製化中期の開発プロセスと組織開発組織の改善

 この時期に、各チケットの工数見積にストーリーポイントを導入して効果を発揮した。それ以前は、アサインされた人が自分なりに「5時間かな、8時間かな」と見積りしてスプリントに利用していた。これを属人的にやるのではなく、タスクの大きさをチームで考えていくようにしたのだ。

 同じバックグラウンドを持ったエンジニア同士で「自分だったら3ポイント」「いや8ポイント」といった会話をすると、8ポイントの人は3ポイントの人に「なんでそんな短くできるの?」といった具合にディスカッションになり、そこで認識合わせができるのだ。結果として見積りの精度が上がり、レビュー工数や開発工数も下げることができた。

ストーリーポイントの導入とQAチームの強化を実施
ストーリーポイントの導入とQAチームの強化を実施

 「スト―リーポイントを導入するといった改善のおかげで、開発スピードが早くなり、リリースする量も増えていきました。一方で、サービスが増えていたにも関わらず品質については手が回っていなかったため、どんどんバグが増えていました。2020年の終わりごろ本当にバグが頻発して、社内の組織同士の関係性も悪化していました」

 そこでQA専門チームを結成して、2週間のスプリントの後に品質を確認する体制をとった。すると、「これはバグです」といったフィードバックが多くなり、修正工数も増加して、2週間で開発したものがQAと修正を含めて1か月後にリリースといったスパンになってしまった。

 このように、作業量と品質は改善したが、改善速度は低下していたのだ。

作業量・品質を維持したまま改善速度を増加させた方法

 「内製化の後期では、開発できる量も増えて品質も安定してきたので、これを維持したまま改善速度の増加に取り組むことになりました」

内製化後期の開発プロセスと組織
内製化後期の開発プロセスと組織

 この時期は、さらにメンバーが増えて、ほぼ完全に内部で開発できるようになっていた。オフショアはあくまで何かあった時のヘルプの位置付けだ。

 開発手法も、デイリースクラムやスプリントプランニング・レトロスペクティブのように、ちゃんとスクラムに合わせたイベントを実施するようにした。開発者が主体のイベントなので、エンジニアがちゃんと参加してエンジニア同士で会話するのだ。そのおかげで、自分のタスクだけでなく周りが何をやっているかも分かるようになった。また、エンジニア一人ひとりの事業ドメインへの理解も進んだ。

 「さらに、QAチームを増強して、さまざまなテストを実施できるようにしました。新機能テストだけじゃなく、リリース前にリグレッションテストを全部回すとか。マスターテストケースとかもある程度作っていますし、サービス稼働率も計算して、SLOとかSLAも測定できるようにしています」

 昨年からは、バックエンドを中心にユニットテストをちゃんと書くという取り組みを進めている。テストコードをちゃんと書くことで、コードを書いている時点である程度バグのリスクを削減できる。そのおかげで、QAチームからのフィードバックも減って、次のスプリントにスムーズに入れるようになった。QAチームの強化とユニットテストを書くことで品質を担保しているのだ。

QAチームの戦力化、ユニットテストをしっかり書く文化の定着
QAチームの戦力化、ユニットテストをしっかり書く文化の定着

 「現在、25名ぐらいの開発チームのなかでQAチームが5名くらいいます。5人にひとりがQAチームになっています。開発チームのなかにデザイナーもいて、開発時に円滑にコミュニケーションできるようになっています」

 現在の開発プロセスは、次図のようになっている。

スクラムをベースとした内製化後期の開発プロセス
スクラムをベースとした内製化後期の開発プロセス

 「開発組織の人数が倍々で増えると、いろいろなところが柔軟に動けなくなることがありますが、私たちは採用にも恵まれたおかげで、開発プロセスも結構いろいろと変えていって、開発できる課題数やチケット数も倍増できましたし、品質もSLOで99.9%以上を守れるようになってきています。リリース頻度も、2週間に一度のペースになっています」

 こうした成果を得られたのには、いくつかのポイントがあったと月澤氏は説明した。

 まずはストーリーポイントで、エンジニア同士で事前にディスカッションできるようになったこと。レビュー工数や開発工数の低減につながっている。またスクラムイベントでエンジニアの参加が進んで、他のメンバーのタスクへの理解だけでなく、事業やプロダクトに関する理解が進み、それが作業量やベロシティにつながっていると述べた。品質に関しても、ユニットテストの定着とQAチームの戦力化が効果を発揮している。さらに、スクラムにQAフェーズを合わせて、リリースまでのサイクルを最適化したことで、作業量と品質を担保したうえで安定したリリースが可能になったと説明した。

 「組織フェーズや、そこにいる人たちにも寄ると思いますが、開発プロセスの課題は、1つ上げたら1つ下がるというトレードオフの形になりがちです。組織の成長に合わせて、組織の生産性を客観的に見て、どこが足りないのか、どうしたら上げられるのか、そうした課題を1つずつ解消していくことが大事だと思っています。我々の話を参考にして頂いたり、反面教師にして頂くなりして、何か役立てて頂けたらと思います」と語って、セッションを締めくくった。

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
Developers Summit 2023 セッションレポート連載記事一覧

もっと読む

この記事の著者

可知 豊(カチ ユタカ)

フリーランスのテクニカルライター 興味の対象はオープンソースの日常利用、ライセンス、プログラミング学習など。 著書「知る、読む、使う! オープンソースライセンス」。https://www.catch.jp

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

丸毛 透(マルモ トオル)

インタビュー(人物)、ポートレート、商品撮影、料理写真をWeb雑誌中心に活動。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

提供:株式会社助太刀

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/17517 2023/04/24 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング