はじめに
典型的なSIer企業における、業務システム開発へのスクラム適用のメモです。
将来の自分向けの備忘録が目的の中心ですが、誰かの何かの参考になれば幸いです。
初版: 2019.09.07
最終更新: 2019.09.07
体制・ロール
- プロダクトオーナー
- モデリングチーム（任意）
- スクラムマスター
- DEVチーム
- QAチーム（任意）
- アジャイルコーチ（任意）
モデリングチーム
プロダクトオーナーは1人です。
その役割は、新たなユーザー要求のバックログ化、直近対応バックログのタスク見積可能な粒度への詳細化、バックログの優先順位付、リリース計画策定、DEVチームの照会への回答、スプリントレビューでの受入判定、プランニングやレトロスペクティブへの参加、、、
業務システム開発では対象とする業務に対してDEVチームが深い知見を持っていないパターンも多いため、バックログはそれなりに詳細に記載する必要があります。（多くはありませんが、業務ロジックを示した計算仕様のような資料をバックログに添付することもあります）
よほど小規模な開発でない限り1人でこなすのは難しく、バックログのタスク見積可能な粒度への詳細化、いわゆる要件定義〜外部設計の一部にあたる作業を行う、モデリングチームを編成しましょう。
私が携わったPJでは、プロダクトオーナーのリリース計画に従ってモデリングチームが要求の詳細化とプロダクトバックログ起票を行い、プロダクトオーナーに情報共有を行うような役割分担にしていました。
QAチーム
私が携わったPJでは、ある段階からプロダクトオーナーが品質要求をそれなりに具体的なレベルで提示することで、DEVチームでテストも含めて対応することとしてQAチームは組成していませんでした。
業務シナリオ観点でのテストが薄くなりがちな部分については、少々変則的ですがモデリングチームがスプリントレビューと並行して検証やモンキーテストを行うことでカバーしていました。
アーキテクチャ・ツール
- Angular
- ASP.NET WebAPI
- Visual Studio Code
- Visual Studio
- Team Foundation Server
- Redmine(ほぼWikiのみ)
- OpenAPI+apisprout(後から導入を試したものの不採用。最初からやっておけば・・・)
アンチパターン
準委任契約でも善管注意義務（プロマネ義務）は存在する
準委任契約での仕事に慣れていたら、本項目は読み飛ばしてください。アジャイルやスクラム固有の話ではありません。
請負の場合は、成果物と期限を守ることが義務であり、バーストしたらとにかく要員追加して収益を悪化させても開発完了を行うというのがベンダー企業の暗黙的な共通認識だと思います。
準委任の場合は、成果物責任もなければ瑕疵担保責任もありませんので、人月分の人数を出せばいいという勘違いが起きることがあるようです。私が携わったPJでは、ユーザー企業側が内製開発のようなことをしたいと言ったことが拍車をかけて、特にベンダー企業上層部にこの傾向がありました。
しかしながら、本当にそれでいいのは派遣契約で、準委任契約は業務委託であり、善管注意義務が存在します。
システム開発のプロとしてプロジェクトマネジメントをすることは受託側の責任な訳です。
特にスクラムの各ロールがベンダー企業内で完結しない場合には、プロジェクトマネジメントの分野毎などで、契約前に役割分担を決めておく必要があるでしょう。
QCDSの優先順位や判断方法の指針などもこのタイミングで決めて置かないと後々厄介なことになります。
プロジェクトマネージャーやチームリーダーの存在
スクラムのフレームワークにプロジェクトマネージャーやチームリーダーは登場しませんので、スクラムチームの役割外で慣習的にプロジェクトマネージャーを置くだけでは役割が不明確でほとんど機能しないでしょう。
ユーザー企業とベンダー企業の役割分担にもよりますが、いわゆるマネジメントスキルを発揮する機会の多いロールは以下の順序と感じます。
- プロダクトオーナー
- スクラムマスター
- DEVチームのエンジニアリングマネージャー（置いた場合）
- QAチームのテストマネージャー
マネジメントスキルに長けた人には、上位の役割を担ってもらったり、その役割のサポート役などとして業務に当たってもらうのはいいでしょう。
多重業務委託の慣習によるチームビルディングの阻害
業務システム開発の分野で一般的な多重業務委託の場合、品質保証計画や開発プロセス、開発環境などはプライムベンダーが定義してユーザー企業と合意するパターンが大半です。
そのため、二次以降のメンバーには開発プロセスの改善などはそもそも自分たちの検討領域ではなく所与のものだという意識が潜在的に存在する場合があります。
このような意識のメンバーが多いと、チームビルディングに失敗してプライムベンダからのトップダウンの構図になってしまう危険性が極めて高いです。私の携わったPJでもありました。
スクラムマスターのチームビルディング経験が豊富でない場合は、立ち上げ時期のスポット参画であっても、フラットな立場の外部人員によるアジャイルコーチをお願いした方がよいでしょう。
事例ベースでのチームの成長記録
レトロスペクティブの成長
レベル１：レトロスペクティブやってみた
開発開始当初は大半がスプリントレビューに間に合わない、間に合ったものも多くが受け入れてもらえない、という状態だったため、KPTのうちPとTを中心にすることにしました。
課題を全員で付箋に書き出して、簡単に読み合わせながら同じものは一緒にして（非グルーピング）、それに対して対策したいものをお買い物ゲームで決めるスタイルで始めました。
この頃は表面的な課題と対策が議論の中心となり、何らかの対策を決めて改善行為はするものの場当たり的な対策しか打てず、チームとしての成長はなかなか感じられませんでした。
例えば、ブランチが増えて来て邪魔だからみんなちゃんと消そう、プランニングでもっとちゃんと影響を確認しよう、リファクタリングによる不具合が多いのでテストをもっとしっかりやろう、など。
プロセス改善の経験不足なのか、振り返ると対策立案についても結論が「もっと〜する」「ちゃんと〜する」になっていました。典型的な対策が対策になっていない状態ですね。
レベル2：大きなテーマを定めて取り組む
スプリントレビューの前日が夏休み最終日の宿題の追い込みのような雰囲気になり、多数のバックログを次スプリントに持ち越すことが常態化していたため、まずはこれを解消して開発の進捗を安定させることを大きなテーマに設定しました。
ただ計画タスクを増やすだけでは本質的な生産性は向上しないのでその目線はどうなのかという疑問もありましたが、現在の働き方は継続出来ないこと、予実が近づいて計画の変動幅を減らすことはビジネスの観点でもメリットがあること、などを確認しました。
この目的設定によって、実装・単体テスト作業に偏重した議論の範囲は広がったように思います。
このテーマでレトロスペクティブに望んだ初回で、プランニング時に見込んでいなかった想定外作業とはそもそもどんなことが起きているのか、タスク管理に色分けした状態で追加するという、対策のためにまず事実を記録する（データを取る）発想になったのもこのタイミングでした。
これによって、スプリントレビュー向けのマージ作業やマージ後の確認作業を計画に織り込むなど、タスクとして明確に認識されていなかった作業が明らかになっていき、改善がなされていきました。
レベル3: お互いを認め合う
スプリント内での他のメンバーのグッジョブを出し合う時間を設けました。
具体的な効果との結びつきは不明ですが、きっといい影響があったのだと思います。
レベル3.5：対策の前提となる問題解消後の姿を共有しようとする
明確な成果が出せなかったので .5 だけレベルアップとしています。
タスクの抜け漏れがある程度落ち着いた後に、タスクに対する設定時間の問題に切り込むとまた対策がうまく打てなくなりました。
このあたりはまた書きます。