はじめに
どうも、金融系SIerです。
業界的にウォーターフォールが当たり前な状況下でスクラムをチャレンジしています。
そんな状況下で見つけた「あ〜・・・これは伝えておけば良かったなぁ・・・」っていうスクラムのメリット・デメリットを少し整理しておきたく、記事化しました。
本記事は、「スクラムガイドを読んでもらうだけでは伝わりにくい話」を中心に記載しています。
超絶基本的な話は、スクラムガイドを伝えるべきですが、それ以外の補足記事的なポジションを狙ってます。
本記事の前提
用語のブレ
ちょっと用語のブレを直すのがしんどいので、テキトーに読み替えてください・・・すみません。
- お客様：ユーザー・ユーザー企業・事業会社
- 私：ベンダー・システム会社・SIer
体制
受託開発の形式を前提にしています。
- プロダクトオーナー：お客様
- スクラムマスター：ベンダー
- 開発チーム：ベンダー
全員が持っておくべき共通認識
全員とは、「社内の偉い人（決裁権限保持者）」「お客さんの偉い人（決裁権限保持者）」とかそこらへんも含んだ全部です。
前提
スクラムをやるのかどうかも含めて認識を合わせておく必要がある
スクラムは銀の弾丸では無い
『「スクラム」は課題を顕在化させるフレームワークである』と言い切っても良いと思っています。
なので、スクラムを導入すると決めたら、今まで押し込めてきた不都合が噴出すると思ってください。
例えば、以下のような内容を、「どちらかの責任」とかではなく、「みんなの責任」として一緒に話し合って考えていく形になります。
- 「これ本当に作るんですか？システム屋的には必要ないと思うんですけど？」
- 「この納期に間に合わせたいんだけど、どのスコープを落とせば間に合わせることができるのか？」
- 「ここの承認プロセスが無駄に見えるんですけど省けないですか？」
- 「ドキュメントはどこまで書くべきですか？」
スコープも納期も調整できないならスクラムはやめた方がいい
スコープもしくは納期が調整できないと、プチウォーターフォールにしかならないです。
どちらも調整できないのに導入して「ウォーターフォールより大変なだけだなぁ・・・」なんて感想は当たり前の結果です。
その場合でもドキュメンテーションを減らしたりなどの工夫はできるかもしれませんが、限界があります。
基本的にスクラムは「スコープ」もしくは「納期」が調整できる前提で成り立っています。
QCDの優先順位を決める「トレードオフスライダー」がよく話題になるのはこの前提があるためです。
2019/03/26追記
以下ブログは、スコープも納期も調整できない中でやっている例です。これを読んで少し心変わり中。でも、マネジメント側の難易度がとても高そうだなぁという印象は変わらないかも・・・。
一括の受託開発でアジャイル
請負契約でスクラムはできない
基本的にスコープの調整などが随時行われるため、ベンダー側は請け負うことができません。
「準委任契約」もしくは「派遣契約」などになると思います。
ベストは「内製化」です。開発者を雇いましょう。
所属組織が違うとどうしても目指すゴールもズレてきます。
スクラムは、そういうズレを想定していません。一緒に働くことを前提に組み立てられています。
ただ、そうしたズレはコミュニケーションの中で明確になり、整理できるようになるとも思いますので、
契約以上に、対面でのコミュニケーションが重要です。
「法律の遵守」と「スクラムプロセス」の折り合いを見つける必要がある
スクラムでは、物理的に同じスペースで働いたりすることが推奨されています。
ただ、そうなるとグレーになってくるのが指揮命令系統です。法的線引きは守りましょう。
これに関しては一概にどうやれば良いとか言いにくいので、各現場でより良い形を探していきましょう。
スクラムは「リソース効率」ではなく「フロー効率」を主眼にした管理手法である
「暇な時間を無くす（1人でマルチタスク）」っていうのが「リソース効率」
「タスクを早く終わらせる（チームでシングルタスク）」っていうのが「フロー効率」
どちらが良い/悪いという話ではなく、アプローチの違いです。
ただ、今までの感覚からすると「非効率」に見えることがたくさん出てくると思います。
「考え方/文化が異なるものです。そういったものを取り込んで、より良くしていきましょう。」
という前提にお互い立って会話しましょう。
「効率」についての考え方は以下リンクがすごく分かり安いです。
参考：フロー効率性とリソース効率性について
スクラムのメリットは評価しにくい
「スクラムのメリット」については後述していますが、評価が難しいです。
メリットが何か？に目を向けてもらえれば、その評価の難しさも伝わるかと思います。
お互いに「信頼」と「協力」を土台にしましょう
今まで以上の「信頼」と「協力」が求められます。
「信頼」に関しては、『開発チームの「見積もり」は基本原則として信じる』とかです。
ここがズレてしまうと、本質的ではない「見せ方」の話に寄っていってしまいます。
「あの人はうるさいから見積もりを高めに出そう・・・」とか。
「協力」に関しては、『依頼する/されるの関係性ではなく、完全に同じ仕事を一緒に行うという感覚で取り組むこと』です。
「こうやってって言ったじゃないか！」とかそういうスタンスではなく、同じ課題にお互いに寄り添っていきましょう。
どちらも、ユーザー企業側にもベンダー企業側にも求められる姿勢だと思っています。
ベンダーとしてお客様に伝えるべきこと
デメリット
お客様目線でデメリットになり得ること
不具合責任を共有することになる
前提の「請負契約でスクラムはできない」から繋がる話です。
システム（人が作ったもの）なので、不具合は出ます。
ただし、請負契約では無いので、ベンダーに瑕疵担保責任はありません。
ある種、不具合責任としてベンダーを追求することができなくなる点はユーザー企業側にとってデメリットと言えるかもしれません。
準委任契約の場合でも「善管注意義務」はあるので、それを逸脱しているかどうかはポイントになるかもしれません。
ただ、それを疑うような状況であれば、「スクラム」としては既に成り立っていないと思います。
優先順位を決める必要がある
今まで「ベンダーによろしく」していたところを、都度考えて制御する必要が出てきます。
それがPOの醍醐味とも言えると思うのですが、「手間」でもあります。
特に突発で発生したタスクなどが原因で消化が間に合わないケースも、当初は頻発すると思います。
そのため、当初思った以上に優先順位に悩む場面は多いはずです。
見積もりがブレる
スクラムでは「精緻な見積もり」に価値を置きません。
「見積もりに時間をかけるくらいなら、さっさとモノを作りましょう」という精神です。
なので、見積もりは今まで以上にブレます。
その結果、スプリントの最初の頃は、プランニングで合意したストーリーを消化できないことも多くなると思います。
もちろん、スプリントを回していく中で、徐々に見積もり精度は高まっていくとは思いますが、「100%精緻」になることはありません。
（スクラムに限った話ではありませんが・・・）
メリット
いきなりデメリットから言いましたが、メリットは何かと言うと以下のようなものたちです。
いずれも定量的に評価することは難しいです。
仕様変更にかかる契約手続きが減る
請負契約では無いため、双方契約をし直す必要がありません。
結果として、管理オーバーヘッドは減ることになります。
要件が変動しやすいプロジェクトなどでは、前述したデメリットを大きく超えるメリットがあるはずです。
リリースをコントロールしやすくなる
スコープがコントロールできているなら、リリースタイミングはユーザー企業側で調整ができるようになります。
それは年々早くなるビジネススピードに対応できるようになるとも言えます。
PayPayなど、世間で話題になるようなレベルのビッグウェーブはこの先もあると思います。
そんなビッグウェーブに乗れるようにリリースをコントロールできるメリットは言うまでもないと思います。
納得感が増す
ケースバイケースではありますが、システム開発の内情が今まで以上に見えるようになります。
また、「何に課題があって、どのように解決しているのか？」について今まで以上に会話する機会も増えます。
結果「ユーザー企業として納得行くシステム」を作ることができます。
（納得行く方向にPO自身がグリップしていくことが前提ですが・・・）
ベンダーにとってのメリデメ
デメリット
今までと違うコミュニケーション/仕事のスタイル
対面コミュニケーションは増えますし、仕事の線引とかに価値がなくなります。（契約上の線引は残ります）
完全に違う文化です。
今までの文化に完全に適応してしまった人には、かなり苦しく感じるかもしれません。
そういう意味合いで、スクラムは人を選ぶ開発手法だと思います。
ユーザー目線での説明が求められる
前述の続きのような話ですが、ユーザーと会話する機会が圧倒的に増えます。
「窓口」以外の人も、ユーザーとの打ち合わせに参加することが推奨されています。
システムだけ見ているのでは、ゴールを見誤ることもあるため、ユーザー目線で考える必要性が出てきます。
メリット
瑕疵担保責任から解放される
メリットに入れるべきか悩んだのですが、一旦こちらに。
瑕疵担保責任自体は契約の話なので、事実として無くなります。
ただ、「システム屋の矜持」はちゃんと持っておきましょう。。。
そこまで解放してしまうのは、スクラムが目指す姿ではないです。
「あるべきシステムの姿」に対していつでもアクションできる
ウォーターフォールでは、前工程で決まっていることに対して変更を加えることは容易ではないです。
一方、スクラムは少しずつ作っていくという形式もあり、どの時期でも比較的変更の取り込みが容易です。
（プロセスレベルでの話）
変更が取り込みやすいようにCIや自動テストを構築しておけば、より変更を取り込みやすいでしょう。
（ソースコードレベルでの話）
ベンダーとして社内向けに動いておくべきこと
社内の関係部署に伝えるべきこと
ウォーターフォールな他部門にもちゃんと説明しよう
システム開発時に関わる関連部署がウォターフォールを採用していれば、どんな迷惑をこれからかけることになるのかを伝えておきましょう。
スクラム側からの依頼は、ウォーターフォール側にとっての「突発」に見えやすいです。
（スクラムのスプリント期間と、ウォーターフォールが見据えるプロジェクト期間とのズレ）
大きい依頼事項は事前に整理しておくのがいいでしょう。
ただ、細かい話などは後から出てくるってのは擦り合わせておいた方が良いです。
どちらが正しいとかいう争いは無意味で、どのようにすればより良いシステムになるのか？を話し合いましょう。
スクラムを主導する人として考えておくべきこと
顧客が求める品質を保証するためにどうすべきか？に答えられること
必要とあればテスト自動化も考えておくべきです。
ATDDなどを考慮することは、もはや必須のレベルになってきているような気はします。
今すぐ導入できないようなプロジェクト状況もあったりするとは思いますが、
基本的には導入するものとして考えておくと良いと思います。
スクラムはつまるところ「文化」であることを認識しておくこと
昨日までウォーターフォールだった人が、ちょっと勉強しただけでその文化になりきれるわけじゃ無いです。
外部から仕入れる方が確実です。
また、今まで横で一緒にウォーターフォールやってたヤツが、「スクラムにしよう！」とか言っても説得力を持つのは難しいです。
「スクラムずっとやってます」みたいな顔している人を連れてくる方が何倍も早いです。
悩ましい点として、その文化に馴染めない人も出てくると思います。
「システム屋の矜持」みたいなのを途中出しましたが、「給料さえ貰えれば良い人」も少なからずいるかと思います。
「システム屋の矜持」って美徳です。そして、美徳は強制するものではないと思っています。
そこの折り合いの付け方は現場で探っていくしか無いと思います。。。
さいごに
本記事が見られることで、少しでも不幸なスクラム導入現場が減れば嬉しいです。
ちなみにですが、スクラムって考え方の寄る辺が少なくて、個人的には割と不安になることが多いです。
この記事も「ここ間違ってる！」みたいな思いを抱く人はいるかと思いますが、やさしくご指摘頂ければ嬉しいです。
参考情報
- アジャイルマニフェスト
- アジャイル宣言の背後にある原則
- スクラムガイド
-
スクラムマスターチェックリスト
- 過去翻訳担当させていただいたんですが、今見たら変わってる・・・
-
アプリケーション開発ノウハウ・ツール集：Fintan
- スクラム開発プラクティス集
- スプリント開始条件チェックリスト
- プロダクトオーナーの役割
- などなどあります
以上です。