こちらの記事は12/20日のアドベントカレンダーです。

こんにちは。@esuEichi です。ツール開発チームというチームで普段は開発やディレクションをしたりしています。このチームでは各種ツールを起案から製造まで行っています。例えば今流行っているツールだと以下のようなツールです。

ここから本題です。自分は認定スクラムマスターの資格を持っており、プロジェクトの進め方としてスクラムはある種の最適解だと思っています。

しかし、自分のチームでは現在スクラムの要素を取り入れていますが厳密なスクラムのお作法に則らない形で開発を進めています。今回なぜスクラムを導入していないか、課題などなかったかなど振り返っていきます。

取り入れている要素

スプリント

1週間で行っています。

デイリースクラム

これも毎日行っています。

カンバン

タスクの管理は zenhub を用いて行っています。大きめのタスクはエピックとして管理し、分解されたタスクはissue単位で管理されています。

フィボナッチ数列での相対見積もり

後述しますが、開発チームが３人になったときに導入しました。上記のタスクに対して毎週相対見積もりを行っています。最近はある程度安定してきていますが初期は大きめに数値が振られるなどし、見積もりのズレなどありましたが改善されています。

振り返り

KPTを毎週行って改善のアクションを週に1つ行っています。

スクラムがフィットしなさそうだった要因と変更点

作るものが小さい事が多い

スクラムはある程度大きなシステムに対して以下のメリットが有ると思っています。

優先度をつけて手が空いたエンジニアが機械的に対応していくことで属人化を排除する
チーム内全員で全領域を対応するため暗黙知が自然と共有されることで生産性が高まっていく

一方で自分のチームの開発は長くても1〜2週間での機能開発をしたあと別の機能やツールを開発することが多く暗黙知を共有して生産性を改善されるまで開発されないことも多いです。また分業できない小さいサイズの作業も多いです。そのため、複数ツールを主担当を決めて開発するスタイルで行っています。

エンジニアが少ない（少なかった）

スクラムでは開発チームは３〜９人が良いとされていますが、当初開発チームは2人だったためスクラムの導入によってイベントにかかる時間等のオーバーヘッドのほうが大きいかなと思いました。

今は開発チームが３人となっています。またそのタイミングで大きめのツール製造が増えたり、作業の見える化のためにフィボナッチ見積もりを導入しています。ここについては実際に見積もりのオーバーヘッドがずいぶん大きくなったので最初はなくて問題なかったなとは思っています。

チーム内にプロダクトオーナーの権限がある

チームの役割として各種ツールを「起案から」製造まで担うようにしています。そのため、今はプロダクトオーナーとして役割を明確に誰かに任せるという形にしたくなかったという思いがあります。

課題

属人化が発生している

開発チームにメンバが増え大きなツールの製造なども動き出しました。また、既存のツールもツールごとに主担当が決まっている形で進んでいるので属人化が発生しているのは事実だと思います。そのため、最近はモブレビューを行うなどで少しずつ改善を進めたいと思っています。また、モブプロやプロダクトの担当を一時的に変えるなどして改善するかもと思っています。が、スピード感を考えるといつどのようにやるかを決めないといけないなとも思っています。