受託系システム開発会社がリモートでアジャイル開発したふりかえり
概要
Blogについて
プロジェクトについて
- クライアント社内で利用する業務システムの開発（数年継続して受けている案件）
- クライアントとはロケーションが離れているため、コミュニケーションはGitHubとSlackを利用
- 基本的にはクライアント側で必要な機能や要件をissueベースで作成し、こちらの開発メンバと各々やり取りして進めていく流れ
- 会社的には受託開発がメインとなっているが、以下の理由からSESに近い契約形態としている（常駐はせず、自社で作業）
- 開発が長く続く前提
- 連続した受託開発で発生する契約調整の簡素化（開発のスピード感を落としたくない、要件の優先度変更に柔軟に対応したい）
- メンバを固定した開発効率化（同じメンバで継続的に開発をすることによる生産性の向上）
2018年からの変化
- 2018年の前半はまだ開発メンバも少なく、昔から知っているメンバ3名で進めていた
- 2018年の後半に掛けて、自社の別なロケーションにいるメンバやパートナーさんなどに参画してもらい開発メンバが6名まで増員
- SESに近い契約なので毎月の作業実績工数時間に上限下限があるものの、2018年は可能であれば別な受託系案件を掛け持ちしつつ対応していたが、コンテキストスイッチによる生産性低下を考慮し、このチームで受ける案件は1本に集中するように調整
- 古くから知っている3名のときは何となくできていた開発も、初めて一緒に開発するメンバも増えたことによって、改めてシステム開発と向き合う必要があり、アジャイル、スクラム、エンジニアリングマネジメントとは？というところに立ち返り改善を検討
チーム構成
- クライアントも6名程度のチームで動いているが、そのチームリーダーがPO（プロジェクトオーナー）の役割と実作業（要件定義や設計）を兼務している状態
- 開発チームは6名のチームで対応していて、自分がSM（スクラムマスター）の役割と実作業（設計やコーディング）を兼務している状態
- 開発チーム内だけでもロケーションは分かれていて、自宅からの対応も可能なためリモート作業前提
2018年時点でのプロジェクト背景
- リモートでの作業が基本
- 作業時間もバラバラ（コアタイム的なものは特にない、但し慣習的に一般的な業務時間で仕事をしている）
- タスクに対して、振り返りみたいなものができていない
- 各メンバが独立して作業してる
- プロダクトオーナーは、別会社（チーム）になるが、アジャイルやスクラムには理解がある（但し、こちらで自由に何でもできるわけではなく説明責任は必要）
2019年のアプローチ
スクラム導入
- スクラムの存在は知っているものの、ちゃんと向き合ったことはなく自分を含めて開発チームでどういうものか理解する必要があった。
- 何冊か自分で本を読んでみて、スクラムの全体像が掴みやすく読みやすいと感じたSCRUM BOOT CAMPをチームで読み回し、知識のベースをチームで合わせるようにした。
- いきなりクライアントのチームを巻き込んでスクラム導入するのは難しく、開発チーム内でスクラムの良いと思うイベントや仕組みを導入しつつ、徐々に改善されるように進めた。
チーム定例
- これまでクライアントチームと開発チームの定例はあったが、開発チームのみでの定例は実施していなかった。
- 開発チーム専用のSlackチャンネルは設けていて、当初は何かあればそこでやり取りしましょうとしていた。
- 各メンバからヒアリングすると、Slackで言いにくい雰囲気はなく必要があれば発言しているとは言うものの、実際にface-to-faceで仕事しているときの質問や発言の量と比べると、何か見えない壁があるように感じ、ハングアウト（ディスプレイ越し）にはなるが、週1で開発メンバ内でMTGする場を設けた。
- 実際にやってみたところ、ラフな質問や発言が出やすくなった。Slackで確認するにも、分からないことを分からないなりにテキストでまとめるのにはそれなりに時間が掛かっていて、「もしすぐ分かるなら」みたいな質問ができるようになった。その場で完全な解決まで繋がらなくても、解決のきっかけやヒントに繋がり一人で悩む時間が減った。
- 開発チームには、何かあったからといって人を罵ったりする人はいないが、各々がエンジニアというプライドをもって作業する中で、基本リモートで年何回かしか会わないチームでは心理的安全性がうまく築けていなかったのかなという反省があった。
- 結果やってみて良い試みではあったが、この後にチーム設計というイベントを実施するようになり、そこで色々話す機会が増えたのでチームMTG単体でのイベントは廃止となった。
ふりかえり
- 2018年より前から続いているプロジェクトだが、「ふりかえり」を実施したことはなかった。
- 何か新しいイベントを始めようとすると、誰しもどういう体で参加すればいいか戸惑うこともあり、初回ふりかえりに対して開発メンバは漠然とした不安を感じているように見えた。
- これまでの開発サイクルで考慮しているイベントではないため、どうしても優先度が低くなってしまい、何回かのリスケの後に実現した。
- ふりかえりには「KPT、YWT、Fun/Done/Learn」などの手法を試そうかと考えていたが、いきなりやるにはメンバの気持ち的にハードルが高くなると感じたため、予め明確な質問をリストアップしてそれぞれの思いを話してもらうような流れで実施した。（パネルディスカッションに近い形式だと思う）
- 実際にやってみると、各メンバ間で普段思っている感謝の言葉が出てきたり、クライアントに対してこういうアプローチをすることで仕様調整がうまくいったとか、製造で詰まっているときの解決案だったりと、これまであえて口にすることがなかったものが表面化し絆が深まったように感じた
- 何となくうまくいっているようなプロジェクトでも、以下の理由から定期的に実施した方がいいと思った。
- 改めて言語化して相手に伝えることで、自分の思いを再認識することができる
- 定期的な実施とすることで、各メンバがそれぞれ相手のことを気にかけるようになる（良いところを見つけるような視点を持てる）
チーム設計
- これまではissueが作成されたら開発メンバのアサインを決めて、各々クライアントと話を詰めてスケジュールに落として対応を進めるという流れだった
- このやり方で露呈した問題は、大きく2つあった
- issueが各担当者で閉じてしまい、対応が人依存になりやすい
- 有識者のソースレビュータイミングから戻り作業が生じることがあり、スケジュール管理が厳しい
- 上記の問題解決としてチーム設計を実施する運用を開始した
- issue単位でまずは設計担当をアサインし、修正方針などをまとめた段階でチーム全体で設計レビューをする
- チーム全体で実施することで、どのissueも全員の目に触れることになり、アサインの柔軟な変更が可能となった
- チーム設計のタイミングで方針も合わせているので、レビューからの想定外の戻り作業が抑えれるようになった
- チーム設計が通ったものは、スクラムのストーリーポーカーのように相対見積もりを実施（リモートで実施するため、試しに以下のWebサイトを利用させていただいてます。）
- 相対見積もりは、数値ではなく「XS、S、M、L、XL」から選択するようにした。これまで各々スケジュール作成していたときは、作業に対して何時間掛かるかを見積もっていた。相対見積もりを数値で表現するとどうしても頭の中では作業時間を連想させてしまうため、手が早い人と遅い人の認識をうまく合わせるため抽象度を上げたものを利用した。また、XLになった場合には、対応の分割が可能なものは分割してissueを小分けにするようにしている。
- 相対見積もり後、製造担当者を改めてアサインし、スケジュールは各々にお願いして引くようにしている
かんばん（GitHub）
- GitHubでは各issueにマイルストーンを設定し、どのissueがいつリリースされるものか管理している。
- これまでは、issueの属性（どういうタスクか？）と一部の工程（現在、レビュー中なのかどうかなど）も全てラベルで視覚的に管理していた。
- マイルストーンに入るissueの量が増えてきたことから、マイルストーンの一覧だけではざっくりとした進捗がわかりにくくなり、GitHubのプロジェクトにマイルストーンと同様のものを設定し、かんばんで管理できるようにした。
- 利用することに対してデメリットはなく、単純にもっと早くから利用していればよかったと感じている
1on1
- 開発チームメンバと1on1させてもらうようにした。
- 最初は自社メンバのみに限定して実施していたが、いまは契約形態に関わらずプロジェクトメンバ全員を対象に話す機会をもらうようにしている。人によってばらつきはあるが、1時間/月を目安に実施している。
- 実際にやってみて思うのは、意外に話すことがなさそうかと思っていても、毎月定期的に時間を設けているとお互いの心も開けてきて、回数を重ねるごとに深い話ができると感じている。プロジェクトや会社に対する思いなどは変動するもので、モチベーションや成長意欲（キャリア設計）に対する補正のためには必須のイベントと考えている。普段から顔を合わせて話しているからこそ、改めて時間を作って話せることがある気がする。
- 基本的にはマイクロマネジメントは避けたいと思っているので、はじめる当初は実施すべきか迷うこともあったが、マイクロマネジメントしないために必要なものだと今は考えている。マイクロマネジメントしないためには、意思や価値観を共有する必要があり、そのためにはお互いがどういう思考で行動するのか、何を大切に思っているかなど双方で共有する必要がある。また、それは一度共有すれば永久的に続くものではなく、価値観などは時間とともに変わるので、そのためにも定期的な実施が必要になると考えている。
TDDBC
- 今年参加したイベントで一番面白く、為になったと感じている。
- いまのプロジェクトではUnit Testの文化がなく、これまでも何回か導入しようとチャレンジはしたもののうまくいかなかった。うまくいかないポイントは大きく3つ。
- これまでよりも開発スピードが落ちてしまうのではないかという不安。
- 開発メンバ内でやったほうがいいとは思いつつも、実際に書いていないのでそこのメリットが漠然としている。（結果、やったほうがいいと心から思えていなかった）
- クライアントとしても、Unit Testを導入するコストメリットがはっきりしないので、そこに急にお金を掛けて良いという判断ができない。
- 実際にTDDBCに参加するまではUnit Testを書くことで、単純にその分のコストが増えると考えていた。そのため、クライアントに説明するときにもUnit Testを書くことで発生するコストの増加と、書くことで保守性や障害発生率が下がるコストの減少から導入メリットを説明しなければと思っていた。それが会場でペアプロしつつ実際に手を動かしてみると、これは手を動かしながら設計を進めているということに腹落ちして、これまでの固定概念が崩れた。複雑な機能を作るときに必要な設計手法であり、それをやることで直接コストが高くなることはなく、思考を整理しつつ安全なコードがかけるという感動を覚えた。実際に自分で体験すると、今後のクライアントへの説明の仕方も変わり説得力も増すのではないかと考えている。
- 但し、とてもいいものと分かったからといって、いきなり大きく開発方針を変えるのは難しく、いまは自分ひとりでコツコツできることから始めている。テストコードが増えていくことで、他の開発メンバでも恩恵を感じる機会が増えると考えており、実際に体験すると自ずと書き始めてくれるのではないかと考えている。
2020年の課題
- CI/CDの強化
- 現在CIの方はある程度仕組み化されているが、CDの方はまだ改善の余地がある。リリースサイクルを今よりも早めることを可能にするため、システム無停止で出来る仕組みを用意していきたいと考えている。
- チーム設計前の設計準備のスケジュール管理
- チーム設計をすることで、ある程度想定したスケジュール通りに開発が進めれるようになったものの、チーム設計準備の期間については、うまくスケジュールして進めれていない。要件自体が明確な場合はスケジュール可能だが、クライアントと調整しつつ進めるものや、複雑な機能で製造を進める上で考慮する点が多いものなどは、概算で工数出していてもブレることが多く、このフェーズに関しては進め方を迷っている。
