読み込み中...
投稿日
ゼロから始めるスクラムによる受託開発
もくじ
はじめに
このドキュメントは、受託開発をスクラムで実践した事例をまとめたものである。
自社サービス開発でのスクラム事例は数多く存在する一方で、受託開発をスクラムで実践した事例は少ないのが現状である。 そんな中、私たちはアジャイル型開発の初心者であったが、スクラムによる受託開発に挑戦する機会を得た。 実際に挑戦すると、想定していた以上に難易度が高く、プロジェクト運営が困難な状況も多くあった。しかし、さまざまな問題に直面し改善していく中で、受託開発にスクラムを取り入れるメリットや注意点など多くのノウハウを獲得できた。
私たちの獲得したノウハウが、これから受託開発をスクラムで挑戦しようとしている人、すでに挑戦はしているが進め方に悩んでいる人の参考になることを目的として、本事例を公開する。
なお、本ドキュメントでは基本的なスクラムの概要については説明しない。 スクラムの概要については以下のサイトを参照していただきたい。
TL;DR
- アジャイル型開発の経験がほぼない中、スクラムを採用するに至った背景。
- 受託開発をスクラムで実践して苦労したことや工夫したこと。
- 受託開発をスクラムで実践して感じたメリット、注意点。
背景
BtoB、BtoC両方の事業を展開するA社（以降、顧客）では、事業の要求/要件の不確実性が増大してきたため、アジャイルの得意領域である「Time To Marketの速度」を意識したビジネス展開を検討していた。 一方、顧客からシステム開発を受託している私たちはこれまでウォーターフォール型での開発実績を積んできたが、開発競争力を向上させるため、アジャイル型開発も積極的に取り組みたいと考えていた。
アジャイル型開発のノウハウを有していないことにリスクはあった。しかし、要求の変更に柔軟に対処できる期待値が高く、アジャイルの中でも採用実績が多く存在し実質的にデファクトスタンダードになっている「スクラム」による開発を採用することになった。
プロジェクトの概要
本事例におけるプロジェクトの前提やコンテキストを共有するため、本章ではプロジェクトの特徴や開発対象であるプロダクトの概要、および体制について記載する。
プロジェクトの特徴
- 業務プロセス改善を目的としたスクラッチ開発のプロジェクト
- 対象業務は、窓口担当者が利用者からの申し込みを受け付けし、事務担当者が受付結果を手作業で処理する一連の業務。
- モバイルアプリケーションで、利用者からの申し込み・受け付けを可能にすることで、窓口担当者を撤廃。
- バックオフィスシステムの導入によって事務担当者の負担を軽減。
- プロジェクト開始時点においては、顧客要望はエピックとして最低限存在しており、システム化の規模や仕様に関しては「今後決定していく」という状態
- リリースまでの目標期間は5か月と短期間
プロダクトの概要
私たちが開発する対象となったプロダクトは、以下の3つのアプリケーションで構成される。
- モバイルアプリケーション（Android、iOS）
- サーバサイドアプリケーション（API）
- サーバサイドアプリケーション（バックオフィス）
体制（スクラムチームと関係者）
- POが他業務と兼務のため、上図の通りSMと開発チームはPOとは別々のロケーションで作業を行い、必要に応じて打合せをセッティングする。
- プロダクトの決定権はPOの上長が握っており、影響力は絶大。
- 対象業務に関する関係部署が多く、POサポートという立場でPOに対してアドバイスを行う役割の方が数名関わっている。こちらの影響力も大きい。
- POはシステム開発の専門家ではないため、システム開発のアドバイザーとしてシステム部が数名関わっている。こちらの影響力も大きい。
- 開発チームは顧客より3名、私たちより4名の混成である。
- 技術的な検討事項が多いため、上記の関係者間のコミュニケーションパスは開発チームを中心に構成されている。
事前に講じた対策
スクラムへの挑戦は初であったが、予見できた課題に対してはあらかじめ対策を打った。ここでは、それらの課題と講じた対策について紹介する。
1. チームメンバーのスキル差
- 不安要素
下図のスキルマップの通り、開発チームの得意分野がバラバラで、スキルレベルの差が大きかった。結果、この箇所の開発はこの人しかできないという属人化の発生(ひいては、フロー効率の低下)や、フォローに回るベテランメンバーが高負荷になることが予想された。参考：スクラム開始前のスキルマップ
＜凡例＞ ◎：得意、◯：できる、△：経験あり、－：未経験
- 対策
スプリントプランニング第ニ部においてユーザーストーリーへの対応をタスクへ分解する際、ベテランメンバー主導の下で、目的と対応方針、その前提となる採用技術、システムインタフェース等の前提知識を開発チーム全員で共有した。 開発難易度の高い機能が多い場合は、これらの共有とタスク分解に2週間のスプリントのうちの半分を費やしてしまうこともあった。それでもすべてのバックログアイテムに対し、全員がその内容を理解できるまで繰り返した。 - 効果
チームメンバー個々人が、前提となる技術や対応の進め方を深く理解した状態で開発が進められるようになった。結果として「ここはあの人しかできない」という属人化も解消され、ベテランメンバー不在の状況においても、開発メンバーの誰もが優先度の高いタスクを対応できるようになった。そのような誰もがタスクを対応できるという状況により、各自がさまざまな箇所の開発経験を積むことができ、しだいに開発を主導できるようになった。その意味での育成効果も非常に高かったと言える。
2. コミュニケーションの工夫（対顧客）
- 不安要素
スクラムチームが顧客と私たちでロケーションが分かれており、Face To Faceでのコミュニケーションを日常的に取ることが難しい。このため、コミュニケーションロスや認識の齟齬が想定された。これは、価値観の共有がとくに重要なスクラムにおいては、致命的な問題になりかねない。 - 対策
電話会議システムを導入し、デイリースクラムやプロダクトバックログリファインメント等で積極的に活用した。 - 効果
Face To Faceには及ばないが、一度に大人数での対話も可能であること、お互いの表情も確認できることから、メールや電話と比較してコミュニケーションが取りやすかった。とくに、刻々と変わる状況をデイリースクラムでの共有や、リファインメントにおける課題の検討等で大きな力を発揮した。
3. コミュニケーションの工夫（開発チーム内）
- 不安要素
開発チームは互いにほぼ初対面で、所属、年齢、職位もさまざまであった。このような状況から、立場を気にして自分から積極的に発言・提案ができなかったり、指示待ちになったりといったコミュニケーション不全な状況になることが懸念された。 - 対策
コミュニケーションを円滑にするため、初顔合わせの際、チームメンバー全員合意の上で以下のルールをFintan – ワーキングアグリーメントとして掲げ、フラットなチームを形成できるようにした。- 苗字ではなく下の名前で呼ぶ
- 作業時に悩んでいいのは30分まで（30分経ったら自作のヘルプカードを挙げる）
- メンバー持ち回りで昼食に何を食べるのか決定し、全員で昼食をとる
- 独り言OK
- 効果
これらのルールを明文化し全員が合意することで、全員が気兼ねなく質問し意見を出しあえる雰囲気がプロジェクトの早期に醸成できた。独り言OKというルールについても、作業の悩み等が周りのメンバーに伝わり、周りのメンバーが助け舟を出す形でコミュニケーションが活性化した。 この効果はプロジェクトが上手くいっていない時期のチームのモチベーション維持にも繋がり、プロジェクトのゴールまで非常に良い関係性を保つことができた。
実施時に顕在化した問題
事前に講じた対策が上手く機能した一方で、スクラムを採用してはじめてわかった問題点と、その問題に対する振り返り・改善策について紹介する。 なお、振り返り手法はKPTAを採用した。KPTAは以下の頭文字を取ったものである。
- Keep:よかったこと
- Problem:改善が必要なこと
- Try:新たに取り組むこと
- Action:具体的な行動
1. スクラムの理解
- 問題
関係者全員がスクラム初心者であり、顧客と私たち双方でスクラムに関する理解が不十分であった。結果として、顧客側では「スクラムならば要件変更が生じても当初予定通り進められる」といった誤解が生まれていた。また私たち側でも「進捗が芳しくない際のリカバリーを本来どうすべきか」という知識・ノウハウが不足しており、顧客に対して不信感を募らせてしまった。 - 振り返り
開始前に考えていた以上にスクラム開発の実践は難しいことを実感した。そして、顧客・私たち双方における、スクラムの理解を深める重要性を再認識した。 - 振り返りアクション
Fintan – スクラム概論を用いて、私たちからPOの上長を含む顧客に対してスクラムの考え方を説明した。 双方の置かれた状況に当て嵌めながら納得いくまで何度も議論を繰り返し、お互いのスクラムの理解を醸成していった。 - 結果
これまではお互いが自己の利益を最優先に意見をぶつけていたが、スクラムチームとしての協力の重要性を理解し、プロジェクトにとっての最善策は何かお互いに考えられるようになっていった。当初抱かれていた不信感も徐々に解消され、信頼関係が生まれていった。スクラムチーム内においても振り返りの質も格段に向上し、チームやプロダクトに関する具体的な改善が進むようになった。
2. スクラムにおける役割分担が曖昧
- 問題
POではなく開発チームがプロダクトバックログの管理をしていた結果、開発チームに情報が集まることになり、POに情報が集約されなくなってしまった。結果として仕様決定のスピードがあがらず、仕様の決まらない状態が発生した。 さらにそうして決まった仕様であっても、スプリントレビュー時にステークホルダーが覆してしまい、いつまでもプロダクトバックログアイテムがDoneの状態にならなかった。 - 振り返り
原因はコミュニケーションパスが整理されていなかったこと、 そして、POサポートやステークホルダーの影響力が強く、POより強い決定権を持ってしまったことだと考えた。 - 振り返りアクション
上記の振り返りを受けて、スクラムチームの体制を見直した。
POサポートを撤廃し、PO1名にすべての権限を委譲した。加えてプロダクトバックログ管理に関するコミュニケーションパスを見直し、要望は必ずPOを経由するフローに変更した。 また、ステークホルダーは「陪席」する形でセレモニーに参加していただくものとし、要求事項があったとしてもPOにて管理するよう変更した。 - 結果
上記の見直しの結果、POの決定権が強化され、POを中心に開発を進められるようになった。
3. 進捗の把握が困難
- 問題
とくに開発初期はプロダクトの全体像が見えないこともあり、プロダクトとしての全体進捗がわからない状態であった。 そのような状況にもかかわらず、開発チームは直近のスプリントの作業に手いっぱいとなり、リリース計画、スプリント計画を立てることもできなかった。結果として、プロダクトがいつリリースできるのか、目処が立たない状態であった。 - 振り返り
最初にリリース計画を立てていなかったことはもちろん問題であった。 また、実際に開発が始まってからはスプリント内の作業に追われる状態となり、全体的な計画を考えられていなかった。さらに、チームとしてのベロシティも計測できておらず、オーバーコミットメントした結果として余裕がなくなるという悪循環になってしまっていた。 - 振り返りアクション
各バックログアイテムについて、どの程度の難易度なのかストーリーポイントを見積もった。 ベロシティが測れていない当初は、稼働日数や要員毎にどれくらい稼働できるのかの見通しを立てた上でスプリントのスコープを決め、バーンダウンチャートとして可視化し、デイリースクラムで報告する方式を採った。 見通しの計算にはFintan – スプリントの見通し確認ガイドを活用した。 - 結果
稼働可能時間の明確化により、開発チームにとって妥当なスプリント計画を立てられるようになった。また、バーンダウンチャートの整備によって自分たちのベロシティも把握できるようになり、リリース計画を策定することができた。
4. 品質評価の指針がない
- 問題
顧客、私たち共にアジャイル開発での品質評価ルールが確立できていなかった。このため、評価方針を後になって顧客と私たち間で取り決める必要があった。 品質評価の主幹は顧客のシステム部が担っていたが、スクラム開発のセレモニーの中で議論する機会を設けなかったため、評価が必要なタイミングになっても担当者がどう評価すべきか判断できなかった（背景や経緯が伝わっておらず判断材料が無かった）。 - 振り返り
Doneの定義に品質に関する定義がなく、プロダクトバックログリファインメントやスプリントプランニングの場で議題に上がらなかった。 - 振り返りアクション
テスト観点・範囲などの品質要件をDoneの定義に落とし込み、スプリントの完了条件にした。 また、バックログの受入条件は必ず記入し、POの承認を得る運用を徹底した。 具体的には、以下の通り開発を進めた。- 常時実施: ソースコードのチェックイン時にCIによる自動テストを実施
- スプリント毎に実施: 成果物に対する結合テストを実施
- リリース時期の数スプリント前に実施：テストスプリントを置き、システム全体をカバーするシステムテストを実施
- 結果
上記のDoneの定義を以って品質評価ルールを策定し、品質評価を実施できるようになった。
5. 開発前の準備不足
- 問題
スプリントを開始するにあたり、必要な準備がまったく足りていなかった。 この結果、スプリント1は開発環境構築で終わってしまい、顧客の「動作するプロダクト」に対する期待を裏切る結果となった。 スプリント1だけでなく、開発に関するルールも序盤で整備できておらず、開発の中盤でのテコ入れが必要になった。 - 振り返り
開発を始めるにあたって何をしなければならないかを洗い出せていない状態で、スプリントを開始してしまった。 - 振り返りアクション
今回の問題を受けて、本来はプロジェクトの開発準備としてのスプリント0が必要であることを顧客と合意した。 また、次回の開発で同じ轍を踏まないようにするため、スクラムを開始するにあたって必要な事柄を洗い出すこととした。 - 結果
組織内でナレッジを集約し、次期開発チームの立ち上げ時に役立つFintan – スプリント開始条件チェックリストを作り上げた。
プロジェクトの成果
上述のようなさまざまな問題に直面し、当初の予定から1か月遅れてのリリースとなってしまった点は反省点である。 しかし、従来のウォーターフォール型開発と比べて状況の変化に応じた柔軟な判断と対応が可能であること、それにより顧客の要望も取り込むことができたため、関係者一同確かな手ごたえを感じている。今回の実績と今後の成長を期待され、次期プロジェクトについてもスクラムで取り組めることになった。
まとめ
はじめてのスクラムでの受託開発を通して感じたメリット、そしてとくに注意すべきと考えた点を記載する。
スクラム開発をやってみて感じたメリット
- もっともメリットとして感じたのは、設計、実装、テスト、レビューを細かいフィードバックループで回せることであった。これにより、以下のような効果があった。
- 動作するプロダクトが早い段階で確認でき、POとの認識齟齬を早期に消し込める。
- リリースが近づいても仕様変更を取り込める余地がある。
- スプリント毎にふりかえりを行うため、プロジェクトの悪習や不満に対して改善サイクルをまわしやすい。
- スプリント毎にレビューで顧客のコメントが得られるため、中だるみせず開発メンバーの意識を高く保てる。
- プロダクトバックログの優先順位を常に見直すことで、本当に必要な機能が何かを認識しやすく、ムダな機能を作ることがない。
- 成長観点でも以下のメリットがあった。
- 進め方を工夫すれば早期に自律したチームが育つ。
- 短期間でさまざまな経験を積むのでフルスタックエンジニアの育成にはもってこい。
スクラム開発をやってみて気付いた注意点
- 顧客・私たち間でのスクラムの共通理解
- 「スコープ」もしくは「納期」は調整できることが前提であることを互いに理解すること。
- ベロシティが安定しない開発初期は予実の乖離が大きくなりがちであるため、開発方針や状況について丁寧な説明を尽くすこと。
- 役割
- スクラムチーム（PO、SM、開発メンバー）以外のステークホルダーが強い権限を持ち得る場合、意思決定者はPOであることを明確にしておくこと。
- POが専任でない場合はプロダクトバックログの管理に手が回らずボトルネックとなる可能性があるため、可能であれば専任のPOを立てること。
- コミュニケーション
- POと開発チームのコミュニケーションが不足すると開発のリードタイム増加や手戻りの増加が起こり得る。当プロジェクトのようにPOと開発チームでロケーションが離れてしまう場合は、コミュニケーション手段を検討すること。
- チームが成熟するまでの間はコミュニケーションを通して道を切り開く場合が多いので、コミュニケーションの円滑化に対する策を打つこと。
- 苦手な人や受け身の姿勢が強い人に対するケアが必要。
- 長期間ウォーターフォール型開発を行ってきた人ほど慣れるまでに時間を要する傾向にあった。
- 品質
- 開発途中においても変更を受け入れながら開発するため、CIによる自動テストでリグレッションを防ぐとともに、ソースコードの定期的なリファクタリングを実施しやすい環境を整えること。
おわりに
本ドキュメントでは、アジャイル型開発の未経験者が受託開発をスクラムで実践した事例を紹介した。
今回の事例のように、経験や実績がない状態でスクラムに挑戦する場合、事前に具体的な問題を想定しづらく、開発を進める中で直面する問題の対処へ多くの時間を要した。 また、とくに開発初期の進捗が悪い状況では、顧客への適切な状況報告や信頼関係の構築に大きな労力が必要であった。
一方で、開発が軌道に乗った後の中盤以降ではスクラムチーム一丸となって良いプロダクトを作るという作業に集中でき、POからのプロダクトへの要望を柔軟に取り込みながら開発を進めることができた。 開発メンバーにとっても、常に改善サイクルをまわすなど自律的に行動を起こしていくマインドが醸成され、開発前後で大きな成長と達成感を実感できた。
当事例では最後まで粘り強く改善活動を実施したことによりプロジェクトの成功を収めることができたが、スクラムを適用するか否かは、プロジェクト計画時に特性や体制を考慮して決定することが大切である。
受託開発をスクラムで実践した事例は少ないため、これから受託開発をスクラムで挑戦しようとしている人、すでに挑戦していて進め方に悩んでいる人にとって当事例が少しでも参考になり、開発成功の助けになることを願う。