チーム開発への挑戦
SVF開発部の働き方改革 #1
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2020、第19弾（2020年12月25日）の投稿です。
ごあいさつ
いよいよ今年のアドベントカレンダーも最終日、クリスマス当日となりました！
みなさまのお宅にはCOVID-19にも負けず、サンタクロースがプレゼントを届けてくれたでしょうか？
私は家にクリスマスツリーなどを飾っていないため、例年は街のイルミネーションなどを見てクリスマス気分を味わっていたのですが、今年はリモートワークで通勤がなくなった上に外出の機会も減っているため、クリスマスツリーを見る機会がほとんどありませんでした。
満員電車に乗らずに済むのは幸せですが、季節やイベントを感じる機会が減ってしまったことはとても残念に思います。
チーム開発に挑戦！
さて、今回は、私の所属部署で今期から始めた取り組みを紹介します。
私が所属するSVF開発部では、その名の通りSVF関連製品の開発・保守を行っています。
関連製品はかなり数が多いということもあり、今までは各製品で担当者がほぼ決まっており、開発も担当者が個人で実施するスタイルでした。
各個人の専門性が高くなる（〇〇さんに聞けばわかる／早い）というメリットもありますが、属人性が高いため特定のメンバーに負荷が集中してしまったり、担当者不在時の対応が難しい等のデメリットがありました。
また、基本的には製品単位で開発と保守を同じメンバーで行っているため、保守の作業が立て込んでくると開発のスケジュールに支障がでる場合もありました。
そこでまず今年度は、属人性を減らし負荷分散をすべく部内の働き方改革を推進しようということになり、その一環としてチーム開発を行う方針になりました。
その方針に従い、今年度のメインとなるSVF Ver.10.1をチームで開発しているのですが、どのように進めていったかを簡単に紹介します。
開発の進め方
今回はとにかくTry ＆ Errorで進めようと最初から話しており、やりながら変えていった部分も多く書き出すときりがないので、今回の開発で特徴的なところ、特にお話ししたいところをピックアップして紹介します。
- 開発期間を4つに分割し（分割した期間を部と呼んでいました）、各部毎に1人1つの機能開発に参加する。
- どの機能開発に参加するかは希望を取り、集まったメンバーでチームとして開発を行う。
- チーム内で仕様検討し、製造、テスト設計まで（場合によってはテスト実施も）すべてチームで実施する。
- 各部毎にステークホルダーを招いて仕様レビュー会を開催する。
部単位での開発
まず最初にチーム編成に関わる部分について、文章だとイメージがわかないと思ったので、イメージ図を貼ってみました。
以下の図のように、開発期間を4つの期間（部）に分け、各部毎に1人1つの機能開発に参加する形で進めました。
図内の1–1、1–2・・・それぞれが開発対象の機能で、マスの大きさがおおよその開発規模を表しています。（横軸が時間なので、縦軸が開発に必要な人数のイメージになります。）
- 製品全体での開発期間（横軸）を4つの部に分割し、開発対象の機能を優先度の高いものから順に割り当てました。
- 1つの部の中では1人1機能開発のみを担当することを基本としています。（マルチタスク回避のため）
例えば第1部では1-1～1-4の4つの機能開発を行います。
メンバー全員がいずれかの機能開発を選択し、集まったメンバーが1チームとして該当機能の開発を行うという形です。
今回は、各自の希望を優先することにしたため、部が変わるごとにチーム編成を変えながら開発を行いましたが、メインとなる機能開発だけはボリュームが非常に大きかったため、1～4部を通して大きくはメンバーを変えずに開発を行いました。（図の1-4のイメージ）
結果として、短期間でチーム編成を変えた時（1-4以外）と長期間同じチームで開発するとき（1-4）の比較になりました。
チームで考え、チームで決める
今回の開発では、全ての工程をチーム単位で行うことを基本としました。
進め方自体もチーム毎に相談しながら進めたためチームによりやり方は様々でしたが、全チームに共通していたのは、誰かに言われた通りに作るのではなく、どういう仕様にするかも含めてチーム内で検討してチーム内で決めたというところです。
主体性をもって機能仕様を決定するという工程に最初は戸惑うメンバーもいたようですが、最大4回繰り返したことで徐々に慣れてきたように思います。
今回は各自の希望を元にチーム編成を決めたため、開発対象製品や機能に精通しているメンバーがいない／少ないチームもありました。
その場合でも、チーム外の有識者に相談するなどしながらチーム内で調査・検討をしながら開発を進めることで、製品知識も徐々に深まりチームの一体感も増したのではないかと思っています。
チーム内での開発の進め方は各チームで決めていましたが、ひとつだけ、毎週のふりかえりの実施をお願いしていました。
長期間溜めずにこまめにふりかえりを実施して、ライトに改善していこうという呼びかけだったのですが、自分のいたチームも含めて開発が佳境に入ってくるとサボりがちになってしまいました。
仕様レビュー会の開催
こちらは前回のSVF Ver.10.0開発の際のふりかえりを元に企画したものなのですが、各部毎に仕様レビュー会を開催しました。
以前の開発時も製品説明会は開催していましたが、作りこみが終わった後など遅めのタイミングだったため、そこでもし大きめの問題が発覚すると手戻りになってしまうという懸念がありました。
また、開発目線では気づけない点もあるため、もっと上流工程でフィードバックをもらい手戻りを防ぎたいという意見が出ていました。
そこで今回は、各部毎に仕様がある程度固まったタイミングで、ステークホルダーを招いて仕様レビュー会を開催することにしました。
複数の部署から沢山の方にご参加いただき、様々なフィードバックをいただくことができ、大変有意義な会となりました。
ご参加いただいた方からも、機能イメージが早めにつかめてよかったとの感想もいただいており、今後も継続開催していきたいと思います。
リモートワークとチーム開発
これは偶然の産物なのですが、開発初期にCOVID-19が猛威を振るい出し、ウイングアークは完全リモートワークになりました。
リモートワークへの切り替えと開発初期のミーティングが多い時期が重なっていたため、慣れない中毎日数多くのオンラインミーティングを開催していました。
当時はかなり疲弊しましたが（オンラインミーティングってなぜかとても疲れますよね）、今思えばミーティングを数多く重ねたことも、リモートワークへの切り替えに一役買った気がしています。
よかったこと
- 有識者のフォローの元、開発しながら製品知識・仕様の共有が少しずつではあるが進められている。
- 前回開発時のふりかえりの結果を今回の開発に活かせた。（仕様レビュー会を開催し効果があった。）
- リモートワークへの切り替えと開発初期のミーティングが多い時期が重なったことが、完全リモートワークへの切り替えに役立った。
やってみてわかったこと
- チーム編成を短期間で変えるのは、チームにとってはよくなさそう。
→いろんなメンバーと関われるというメリットもあるが、慣れた頃にチームが解散しまた新たにチームビルディング・・・となるため開発効率はよくなさそう。 - ふりかえりの活用方法についてはまだまだ検討の余地あり。
→12/4のブログで紹介のあった「実践的ふりかえり講座」には部内のメンバーも多数参加し、たくさんの学びがありましたので今後に活かしたいです。 - 本来の目的の属人性排除や負荷分散についても、最初の一歩は踏み出せたものの、まだまだこれから。
おわりに
今回チーム開発を試してみて、まだまだこれから・・・な部分もたくさんありますが、それも含めて今回やってみてよかったと思っています。
開発はピークを越えつつあるもののまだ終わっていませんので、引き続き工夫や改善できるところをしつつ開発を続けます。
今回のAdvent Calenderの中に、実は我々のチームについて触れてくれている記事がありますので、最後に紹介させてください。（冒頭の「機能担当制からチーム制にチャレンジしているチーム」が私たちのチームです。）
お恥ずかしながら「スウォーミング」という言葉自体もこの記事で初めて知ったのですが、読んでみると結果的に実施できている部分もありましたし、今後意識して取り入れていきたいところもありました。
今回良かったところはまた次回も継続し、少しずつ改善しながら、こちらの記事などを参考にしながら時には新しいチャレンジ、次回以降もチーム開発を続けていきたいと思います。
最後まで読んでいただきありがとうございました。
良いクリスマスを！
