はじめに

このドキュメントは、スクラムチームのタスクアサインにおける取り組みを事例としてまとめたものです。チーム内のスキルレベルの差が大きく、最適なタスクアサインできずベロシティーが低かったという課題あり、バックログにスキルマップを取り込むことで課題解決を図りました。その結果、最適なアサインにより効率的な開発を実現するなど、いくつかの効果が得られましたのでその取り組みを紹介します。本ドキュメントは、タスクのアサイン方法に悩みを抱える方への参考情報となることを目的としています。

背景

我々のチームは基本的にひとつの拠点に集まって開発していましたが、業務事情や家庭事情により異なる拠点で作業をすることも多々ありました。このため、リアルかんばんなど場所に依存するアナログな手法は取り入れず、情報はすべて電子化するようにしています。

ご紹介するプロジェクトは、我々が運用するWebサービスをマルチテナント化するものです。ハードウェアからOSまでをインフラチームが担当し、OSより上のミドルウェア・アプリケーションレイヤを構築するのが我々アプリチームの責務です。そのため、サーバーサイドアプリケーションのコアな方式に関わる改修からミドルウェアのコアな設定変更まで幅広いタスクをこなす必要があります。

今後のビジネス拡大でテナント増加を目指しており、構築するシステムには高い保守性と拡張性が求められます。また、本システムは国内でも事例の少ない新しい技術を扱っていることから、最適な実現方式に対する解を最初から持っているメンバーはいませんでした。そこで、多くの要件は方式の検討からスタートし、フィジビリティ調査を実施したあと問題なければ実装するという３つのステップで開発します。

チームの課題

かんばんツールとしてGitlab のIssue Boardsを使用しています。バックログをissueとして優先順に並べておき、メンバーが作業を開始するタイミングで優先度の高いタスクから取り組みます。ただし、メンバー間でタスクの得意・不得意があるので、取り組むタスクは単純に最も優先順の高いものではなくデイリーミーティング等で都度チームと相談し実施可能なタスクを選ぶようにしていました。

バックログのタスクに求められる技術は多種多様で有識者に依存しやすく、メンバーは得意分野が異なりスキル差も比較的大きいため、効率的・効果的なタスクアサインが困難でした。
メンバーがバックログに積まれたタスクから機械的に最も優先度の高いタスクを奪って進めると、不得意なタスクがアサインされることによる意図しないベロシティーの低下や品質の低下が発生しました。また、メンバーの得意分野に合わせてアサインすると一部のメンバーにタスクが集中し不公平感に繋がるだけでなく、トラックナンバー１となって人依存が解消されずチームは成長しません。

解決のためのアプローチ

タスクアサインにおける課題に対して、タスクに必要なスキルとメンバーごとのスキルマップをバックログに可視化しました。具体的な流れを以下に説明します。

まず、バックログの優先順やスキルマッチ状況を俯瞰しやすくするため、バックログをExcelで作成し優先順に並べます。

バックログの各タスクを実施するにあたり必要なスキルを定義します。

タスクのアサインの参考情報としてメンバーごとのスキルマップを作成します。スキルマップはチームやプロジェクトによって適切なスキルを定義すると良いです。スキルマップの運用については スキルマップ運用ガイド が参考になります。

続いてメンバーにタスクをアサインします。Excelマクロを使ってスキルアンマッチなアサインを赤字表記されるようにし視覚的にわかりやすくしました。 すべてのタスクがメンバーのスキルにマッチするアサインを行うことが目的ではありません。スキルアンマッチを可視化することでベロシティーの低下を予測したり、有識者からサポートを受けやすくしたりすることが狙いです。

メンバーはバックログから自身にアサインされたタスクの中から最も優先順位の高いタスクを見つけ出し、Gitlab のIssue Boardsへ登録しタスクに着手します。メンバーはタスクの進捗に合わせてIssue Boardsでステータスを遷移させます。

ステータスをバックログにも同期させ背景色により進捗状況がExcel上で俯瞰できるようにしています。完了はグレー、遅延は黄色、時期未到来のタスクは緑色の背景で表示されます。

また、Gitlabではissue Boardsのissueの並び順はステータス内でしか維持されない仕様のため、ステータス遷移させるタイミングで元の優先順を失ってしまいます。これを補うため、Excel上のバックログで全体の優先順を保持しています。

得られた効果

スキルアンマッチなタスクを可視化することで次の効果が得られました。

スキルアンマッチなタスクアサインのコントロール

優先順と見積値を元にメンバーをアサインした結果、スキルアンマッチなタスクアサインがされると赤字表記され本当にそのアサインで良いのかを再考する機会となりました。タスク実行順の変更を許容できる場合はアサインを変更しアンマッチなアサインを減らしていきました。また、全体を俯瞰して見れるので、誰にアンマッチなアサインが多いかもひと目で分かるため、赤字表記のタスクが集中しているメンバーを見つけアサインを変更しました。これにより、全体としてアンマッチなアサインの割合を減少させることができ、さらに一部のメンバーに無理なアサインが偏ることなくタスクの平準化にも繋がりました。

タスク遅延リスクの早期把握による後続タスクのアサイン変更や実行順変更

スキルアンマッチなタスクを担当していることがチームメンバー全員から見えるため、有識者からサポートが得られるだけでなく、タスク遅延リスクが比較的高いと予測できます。タスク遅延による影響を考慮し後続タスクのアサインを変更したり、変更したタスクに依存するタスクの実行順を変更したりと、対策をより早い段階で実施でき対策の幅が広がりました。

育成視点のタスクアサイン

DevOps化が進み、要件を実現するには我々サーバーサイドアプリ開発を担当してきたチームにもインフラスキルが必要となるなど、1つのチームに求められるスキルが多様化してきています。チームのスキルの幅を広げるには育成が必要です。そのためには、目先のプロジェクトの成功だけでなく長期的な育成観点でのアサインが必要で、それがまさに赤字表記されるアンマッチタスクのアサインでした。赤字表記はタスク遅延リスクのアラートだけではなく、「絶賛成長中」を示すサインでもありました。スキルアンマッチなタスクをこなしていることを可視化することで、自身の知識の幅を広げているというポジティブな気持ちで取り組めるようになりました。

隠れたスキルを活かしたアサイン

メンバーの日々の成長をリアルタイムでスキルマップに反映することは困難です。今まで経験のなかったことができるようになればスキルレベルはアップしスキルマップを日々更新することになりますが、それほど頻度は高くありません。そこで、タスクアサインを検討する際に過去タスクを振り返ると、どれだけアンマッチなタスクをこなしたかがひと目で分かります。これにより、隠れたスキルが浮かび上がりアンマッチでも積極的にアサインできるようになりました。

アサインの脱、人依存

タスクのアサインやアサインの見直しはチームのベロシティーを左右する重要なアクティビティであり、これまではタスクの詳細を知る人とメンバーのスキルを知る人、或いは両方を知る人が実施する必要がりました。該当するメンバーは限られタスクをアサインするアクティビティは人に依存していましたが、今回導入したバックログで両方が可視化され誰でもアサインやその見直しが実施できるようになりました。

さいごに

本プロジェクトの最中、COVID-19 による緊急事態宣言の発令によりチームメンバー全員がリモートワークで開発しなければならないという、これまで経験のなかった開発スタイルを強いられました。元々、場所に依存しない開発ができる準備をしていたため致命的な問題はなく開発を進めることができたものの、チーム内のコミュニケーションの難しさには苦労しました。そういった状況下においても計画通りプロジェクトを完遂できたのは、この手法によりタスクアサインが柔軟かつ最適に実施できたことが要因のひとつと考えています。

タスクのアサインについてはまだ課題も残っています。現状スキルレベルは「○」「✕」で定義していますが、ランクで詳細化し過去の経験やトレーニング状況を元に反映すればタスクのマッチング度合いの精度が増します。また、スキルマッチ度合いにより見積工数を調整するなどできれば、チームがよりレベルアップできるのではないでしょうか。

本取り組みは、日経クロステックの特集「リモートアジャイルの「壁」」の記事「テレワークでコミュニケーション不全、アジャイルチームに立ちはだかる3つの壁」で紹介されましたので、よろしければ御覧ください。

尚、本事例で紹介したバックログツールは以下からご利用いただけます。

本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。