はじめに
よく聞くワードですが、
「アジャイル開発、採用しよう。」
「アジャイル開発をしよう。」
「ウォーターフォール or アジャイル」1
これらの延長線上で始まった「アジャイル案件」を、半年ほど経験しました。
「アジャイル案件」とわざわざ「」を付けているのは、
- 自社サービスを開発している
- 内製化している
と
- 開発会社が案件を受注して行う「アジャイル開発」
を区別する意図があります。
こうした「アジャイル案件」において、発生した失敗をもとに、思ったことをただひたすら書いてみました。
※ かなり愚痴っぽいですし、完全なポエムなので、そういうのが嫌いで、スクラムについてちゃんと知りたい方は、こちらの記事がオススメです。
期限が決まっている、または約束してしまっている
一括請負のウォーターフォールをやってきた方にとって、期限が決まっていることは当たり前かと思います。
しかし、アジャイル開発（今回の場合「スクラム」）だと、様々な弊害を生むことになります。
例えば、今回の案件では、下記のようなことがありました。
案件への参画時の打ち合わせで、かなりざっくりとしたマスタスケジュールを見せられた。
案件参画前に、プロトタイピングを数か月もやっていたらしいのだが、（正直この時点で、怪しい）
それを踏まえて期間を予測し、顧客と合意をしていた。（ちなみに、「合意」をした人物に開発・ＰＭ経験はない）
最初の見積もりが過少すぎた上に、要求に応じて様々な変更を取り入れたため、最初に宣言したような分は当然終わらなかった。
結局、会社間での問題になり、開発チームに対して
- 残業をしてでも終わらせろ
- 今までやってきた作業と、これからやる作業を全部あげろ
などのバカげた要求が飛んできたが、一切お断りした。
その一件の後、不信感が漂ったり、開発会社が及び腰になったりして、スクラムらしさに欠けることになった。
一括請負のウォーターフォールで「期限を約束できる」のは、「要件の変更」を許さないからです。
後から要件を変更されては、いくらでも依頼する量を増やせてしまえるからです。
また「リスクマネージメント」として、「見積もり」に「手心」を加えます。
これは、起こりうるリスクに対する「準備金」で、ドＭな社員が多いとかそういう事情が無い限り、
終わらないリスクが、ほぼ０になるように、どこの開発会社も、余分にお金を徴収していると思います。
どうしても終わらければ、「残業戦士による残業部隊」を組み、無理やりにでも終わらせます。
しかしこれでは、
要件が変更できないので、ビジネスの変化についていけないし
開発期間の中でいらなかった機能を作ることにもなりかねないし、
８か月分払ったのに、実は６か月で終わっていても、１円も帰ってきません
だからこそ、アジャイルでは
変更の要求に応じるし、
「今一番欲しい機能」を先に作るし、
８か月働いたら、「８か月働いた成果」がそのまま顧客のものになります
ただ何の方策もなしに、あるがまま進めている状態では、「ビジネスの予定」（例えば、プレスリリースとか）も組めませんし、実績の管理もできません。
それでは困るので、「イテレーション開発」を行います。
スクラムだと、スプリント（１か月以内）を何回も繰り返します。
１スプリント＝２週間なら、８か月で１６スプリントになります。
開発チームは、ストーリーポイントを使って、プロダクトバックログを見積もります。
- プロダクトバックログ１ ⇒ ３
- プロダクトバックログ２ ⇒ ８
- プロダクトバックログ３ ⇒ ２
これには、
「プロダクトバックログ２がプロダクトバックログ３の４倍くらいかかりそうだよね」
ぐらいの意味しかありませんし、精緻な見積もりではないですが、ある程度の予測を立てることができます。
しかし実際は、４割しか終わらなかったり、７割程度だったり、特にスクラムのやり始めは不安定でした。
そうなってくると、「期限」を気にしだす人たちがでてきて、
「終わらなかった」という言葉が持つネガティブ要素にばかり目が行ってしまったり、
１０割終わる前提で、プレスリリースを予定してしまった
等の理由で、「きちんと目標をスプリント内に達成」させようと、圧力をかける人達が出てきます。
挑戦をしなくなる
彼らの圧力に対して、「開発チーム」は下記のような手を打とうとします。
少し余分に多く、ストーリーポイントを見積もっておく
「今の速度が限界なので、目標値は増やさず、余裕があれば次のバックログに入ります」と言っておく
ですが、これでは、
「余分に多く見積もる」のは、ただのミニウォーターフォールの繰り返しですし、
「終わったら次に入る」というのは、目標値が終わるように調整しながら仕事をしているだけ
です。
これでは、「挑戦する余裕も意思」も出てないので、チームの成長＝ベロシティの向上は見込めません。
本当の理想は、
「チームが挑戦できる心理的・時間的余裕があり、その結果ベロシティが向上すること」
であるはずです。
その過程では、ベロシティが安定しなかったり、３割・４割といった実績が出てくると思いますが、
それは「進行を妨げる問題」が発生している証拠であり、それらを解決することが、スクラムのやり方です。
こうして、上がっていく目標に対して「ぎりぎり終わらない状態」になれば、それが最高の状態なのです。
３～５割 ⇒ 見積もりの精度が悪かった、または、何か進行を阻害する問題が発生している
６～９割 ⇒ ギリギリ終わらなかったが、チームは「挑戦できて」いて、改善していくことができる
１０割～ ⇒ 終わったのはいいが、見積もりが「保守的になっている」可能性がある
ここまで説明しても、「それでは予定が組めない」という人もいるかもしれませんが、
プレスリリースなどの面でいうなら、３割程度しか終わらない可能性を踏まえ、計画を進めれば良いだけです。
それを理解せず、「期限を設け、確実に終わる道を選ぼうとすること」は、開発チームの挑戦する意思を挫くことになります。
「期限・約束」を望むのであれば、アジャイル開発を諦め、ウォータフォールやハイブリッドアジャイルを選ぶしか道はなく、
その場合、多少「アジリティに欠ける」かもしれませんが、それは「トレードオフ」として受け入れるしかないでしょう。
残業をしてしまう
先に上げたような顧客の期待に応えようとして、無理な残業に手を染めてしまう人が必ず出てきます。
スプリントの予測は、実績ベースなので、１２０時間働けば、次のスプリントも、１２０時間分の作業を予測することになります。
当然、そんな状態を長くは続けていられないので、開発チームはどんどん保守的になっていきます。
中には、「８０時間になるように 2/3 を掛ければ」という方もいますが、
１２０時間働いても、８０時間の 3/2 ＝ １．５倍 の成果は出ないのに、2/3を掛けるので
どんどん減っていくベロシティに「おかしい」という話になります。
このように、顧客の期待に応えようとして残業することは、逆に顧客を裏切ることになります。
期間は約束しないが、リスクは減らせる
スクラムは始まらないと、どれくらい進むのか分からず、なかなかアジャイルに踏み出せない場合があります。
「そんなときできること」を少し考えてみました。
スケジュールの予測
例えば、
- 予算として、「４人のチームを８か月雇える」
- 大体のやりたいことは決まっていて、ゴールが少し見えている
としましょう。そうした場合は、
- バージョン
- ブレのある期間
を書いた表を作りましょう。
「バージョン」は、顧客の求めるプロダクトに必要な機能を「バージョン１」として、それに対して段階的に機能を足していったものを「バージョン２・バージョン３」としていきます。
これは、もっと細かくやっていけば、そのまま「バックログ」や、それらをまとめる「エピック」の元ネタになる可能性もあります。
「ブレのある期間」は、何も問題が起こらなければ終わりそうな日を起点に、規模に応じて１．５～２倍して、決めます。
どうせ１２か月かかるとか１６か月だとか、予測をピッタリできるわけないので、それくらいの精度でしか出せないはずです。
例えば、下記のような感じです。
| バージョン１ | バージョン２ | バージョン３ |
|---|---|---|
| ４～６か月 | ７～１２か月 | １２～２４か月 |
こうしてみると、「バージョン２・バージョン３」では、予算が全く足りないことが分かります。
「バージョン１」の期間が現実的だと、顧客は理解してくれるはずです。
こうして顧客としても「ある程度の速度感」を知ることができます。
ただし、下記のポイントを、顧客に対してしっかり説明しましょう。
- 規模が膨らむにつれ、予測が困難である為、期間のブレが大きいこと
- 期間は約束できないので、終わらなかった場合に備える必要があること
契約形態を工夫する
契約形態を少し変えるだけでも、顧客にとってのマイナス要素は減ります。
月額契約
月額契約であれば、途中の経過を見て、被害を最小限に食い止めることができます。
一括請負では、払ったお金は帰ってきません。
レベニューシェア
利益が出れば分配し、損益がでればお互いでお金を出し合い補填するやり方です。
これは、リスクもリターンも共有するやり方で、アジャイルには最適かと思います。
ただ「リスク」を取って「利益」を得るというアプローチができるだけの「企業体力」がなければ難しいです。
また、顧客がやろうとしていることが、本当に利益を生むのかを判断する必要もあります。
チームビルディングに失敗した
ウォーターフォールだろうがアジャイルだろうが、何をさしおいても大事なのは、「人」と「チーム」です。
僕のいた案件では、
- 必要な人がいない
- スクラムのルールを守っていない
- 役割を果たさない
といった問題が起きていました。
スクラムマスターが不在
非常に大事な人が欠けていました。
スクラムは「理解するのは簡単だけど、実践していくのは難しい」です。
スクラムマスターは、そんなスクラムを上手くやっていけるように支援してくれます。
正しい経験知をもとに、「ちゃんとやれれば上手くいくのだから、ちゃんとできるように支援・指導する」のがスクラムマスターです。
今回の案件では、
うまくいかないのを「スクラムのせい」にしたり、
立場的に上であることを利用して、外から圧力をかけたり、
スクラムイベントに参加して、掻きまわすだけ掻きまわして、去っていく…
といった人物がいました。
スクラムコーチがある程度、コントロールしてくれたおかげで、なんとかスクラムの体を保っていたものの、
いなくなった途端、どんどん悪い方向に向かっていきました。
そういったものと向き合う優秀なスクラムマスターがいることほど、安心できることはないです。
スクラムマスターの立場
顧客側とか開発側とかいう概念自体がばからしいのですが、スクラムマスターは顧客側から出すほうが良いと思います。
大抵、スクラムのやり方を否定しようとするのは、ウォーターフォール開発にどっぷりつかってきた開発側だからです。
また、スクラムで開発することが直接的な収益につながらない開発企業に属している限り、
いざ会社間で問題が起きた時に、顧客側の立場にたって顧客の利益を守る選択ができません。
開発側から出すのであれば、せめて内製化していた企業でスクラムを経験してきた人に頼むほうがいいでしょう。
スクラムを依頼する企業は、スクラムチーム全員を雇うのが体力的に厳しいのであれば、スクラムマスターを雇うべきだと思います。
プロダクトオーナーが近くにいない・１人じゃない
僕のいた案件のプロダクトオーナーは、
「決定権だけ持っていて、実務的なところは他の人がこなす」
状態でした。
その為、下記のような感じで、ぐだぐだしてました。
コンサル「仕様、考えてきました。」
開発チーム「ここを、こう変えるのはどうでしょう。」
コンサル「顧客に確認しましょう。」
顧客は自分の業務に忙しく、コミュニケーションが取れないことが多かった為、確定まで数日かかることもあった。
その後、ビジネスの方向性などの影響で、仕様が変化していき、その度にコンサルが、深夜まで働き資料を直してくる。
そのあと、さらに議論を重ね、顧客・開発チームのOKが出て、ようやくプロダクトバックログが成立する。
今回、「プロダクトオーナーの名札」をつけていたのは顧客側なのですが、
本来の業務が多忙がで、プロダクトバックログの管理や、それらを改善するためのイベントであるバックログリファインメントに十分な時間を割くことができませんでした。
その為、コンサルとして入った人物がプロダクトバックログの管理を行っていたのですが、「最終決定権」はありませんでした。
よって、開発チームが仕様について相談しても、「すぐにOKが出ない」ため、プロダクトバックログの管理が滞っていました。
このように、本当のプロダクトオーナーがいつでもコミュニケーションを取れるわけでもなく、
決定権を持たない、疑似的なプロダクトオーナーがもう１人いる状況では、チームは自己組織化しずらいです。
プロダクトオーナーは、顧客側ではなく開発側に籍を置くことが最適なのではないかと、考えます。
しかし、開発側に仕様の決定権を委ねるのは、
「顧客が求める仕様に対して、誤った認識を持って進めてしまうのでは？」
といった不安から、難しいかもしれません。
しかし、スクラムにおいて、プロダクトバックログや進捗はすべて見える化されていて、
顧客はいつでも確認できますし、そうなっていなければ開示を求める権利があります。
また、確認をして問題があれば、スプリントを中止することも可能です。
またスプリントの最後に行われるスプリントレビューでは、動くアプリを見ることで、リリースの判断や修正を求めることもできます。
このような見える化・透明化が徹底されていれば、安心して開発側のプロダクトオーナーに判断を任せることができるはずです。
「全部ひとりで考えて、立派な資料にしてきました」に苦しまされるチーム
「全部ひとりで考えて」きたことには、努力に敬意を表したいのですが、
仕様についても、開発チーム含めて全員で意見を出し合うのがスクラムです。
また、ビジネスが変化し、顧客の要求も変化する中で、「立派な資料」をメンテナンスし続けるのは負荷が高いです。
この場合、「ひとり」だけが苦しむわけでなく、実際はチーム全体が苦しめられることになります。
本来ならばプロダクトバックログに反映すれば終わりの作業を、
①資料の修正 ⇒ ②プロダクトバックログの修正
と余計なステップを踏むことで、プロダクトバックログがなかなか成立しないからです。
開発チームも顧客も、簡潔で明確なプロダクトバックログが、正しい優先順位で見える化されることを望んでいます。
そのためには、無駄な作業を減らし、より対話ベースで仕様を決めていき、口頭で議論しずらい画面のイメージは、デザインツールを活用するなどの工夫を徹底すべきです。
役割が明確でない・責任を持ってくれない
アーキテクト「インフラ構成、決めてきました。データモデルも考えてきました。処理はこう流れて…。」
残念なことに、実装についてはあまり記載がなく、ER図やシステム図などの概念的な部分だけが決まっていた。
参考にしつつも、実装についてはホワイトボードに簡易的なメモや図を書きながら設計していた。
アーキテクト「もっとちゃんとした図とか作らないとダメなんじゃないですか？」
そんなこんなでプランニングは２日・３日と続いた。
顧客「もうスプリントって始まったんでしたっけ？」
開発チームの「裁量」についての話になります。
スクラムでは、開発チームの仕事の進め方であったり、実装方式の決定権は、「開発チーム」が持ちます。
なぜなら、開発チームは機能を完成させる責任があり、その「トレードオフ」として裁量を与えられているためです。
つまり「開発チーム」として、「責任」をもって機能を完成させなければ、裁量は与えられません。
設計にだけ関わるようなスタンスでは、その後の実装上で不都合があったときに、責任を持つ人物がおらず、開発チームのモチベーションは著しく低下しますし、機能を完成させたとは言い難いです。
また今回の人物は、スプリントレビュー中に、内部実装や設計についての報告を求めてきたため、
貴重な顧客の時間を奪ったとともに、なぜか作ったものを説明する二度手間を被ることになりました。
一緒に設計をして開発し、機能を完成させていれば、説明などは不要なはずでした。
時間を無駄にしない為にも、
- スクラムにない役割を勝手にやりだす人物
- 場を支配しようとする人物
を生み出さないようにしましょう。
一度に全部を決めてきてしまう
そもそも、インフラの構成にせよ、業務的なデータモデルにせよ、すべてを最初から決めてうまくいくほど、単純ではありません。
スクラムは、トライ＆エラーを繰り返すことができることが売りであり、
なおかつ、変化する可能性のあるものを先に定義しようとしても、無駄な作業になるだけです。
例えば、業務的なデータモデルは、絶えずビジネスに応じて変化する可能性がありますし、
インフラの構成についても、最初はミニマムで費用を抑え、必要な場合に変更やグレードアップをしたほうがコストが低く抑えられます。
そういったことができるからこその「クラウド」です。
一度にすべてを決めようとするのは、やめましょう。
「書・図」にこだわらない、詳しく決めすぎない
図を書くことは、情報伝達や細かい仕様を洗い出すことには効果的かもしれません。
ですが、開発チームは同じ場所でプランニングを行っている為、情報伝達は不要で、その内容を写真なりで保存すれば事は済みます。
わざわざドキュメントに落とし込む必要はありません。
そして、あまり詳しいことは、プランニング時点で突き詰めないのもコツです。
時間がかかり、プランニングに２日も３日も費やすことになり、開発できる時間が減ります。
また、ある程度の柔軟性を残し、開発時にレビューやペアプロ・顧客との相談などを通して改善したほうが、効率的です。
ドキュメントはいるか、いらないか
後のメンテナンスの為にドキュメントが必要と言う人もいます。
これはただの意見ですが、私としては、
- コミュニケーションや教育に力を入れ、全員がコードを把握していれば、１人欠けても大丈夫なようにしておく方策
の方が好きです。
そうしたほうが、「本当にメンテナンスできる人」が残るし、開発者のスキルアップにもつながるからです。
大量のドキュメントと、見知らぬソースコードだけで、メンテナンスできるほど優秀な人材を探すより、現実的ではないでしょうか。
また「メンテナンスのためのドキュメントのメンテナンス」の為のコストもばかにならないです。
ドキュメントは、なにか「覚書き」の目的で残し、設計書として残す必要はないと考えています。
チームの分け方を誤る
今案件は完全なコンポーネントチームになっていました。
コンポーネントチームとは、
- インフラチーム
- サーバーチーム
- 画面チーム
のようにレイヤーで分けるチームの分割手法で、今回の場合
- フロントチーム
- サーバーチーム
となったわけですが、これがどういう事態を引き起こしていったかを説明します。
フロントチームは、優先順位に沿って、開発を進めていた。
しかし、いざ画面の開発が終わって、サーバー側のAPIがまだできていなかった。
もちろんサーバーチームが無能なのではない。
画面が簡単なわりに、サーバーの処理が複雑で、スケジュールにずれが生じていたのだ。
忙しい中、わざわざ偽のAPIを作ってもらうのだが、パフォーマンスも測れなければ、E2Eテストもできないし、リリースもできない。
仕方がないので、次の作業に手を付けているうちに、９割程度過ぎたところで、スプリントが終わった。
しかし、リリースできるのは、スコープのたった３割だった。
仕方がないので、３割のみをデプロイし、アプリを顧客に見せた。
顧客「リリースは次回にしましょうか。」
僕らは、苦笑いするしかなかった。
この比率は、決しておおげさなものではないです。
もし、１つ１つの機能を、レイヤーの垣根を越えて、一緒に作っていれば、せめて５～６割ほどはリリースできたかもしれません。
顧客が求める「コア機能」だけでも、リリースに乗ったかもしれません。
これに対する答えは、決まっています。
フィーチャーチームです。
今回のチームをフィーチャーチームにすると、１つのチームになります。
それは、「〇〇アプリ作成チーム」です。
〇〇アプリの機能を、ひとつずつ一丸となり、せっせと終わらせるチームです。
全員がフルスタックである必要はないし、ましてやSREである必要もありません。
お互いがコミュニケーションを取り、得意な分野を教えあいながら、チームで成長していけばいいのです。
そして、
「画面でバグが出た」
とか
「サーバー死んでるよもう」
みたいな責任の擦り付け合いもありません。
チームで責任を持ちます。
それがフィーチャーチームであり、「案件」に複数の会社が参加するだけで、実現が遠のきます。
そして、リリースできる対象を少しでも増やすこと。
ビジネスの速度はそれらに比例します。
より多くのものを世に出し、フィードバックを得て、さらに改良を加えていくこと。
それを実現できるのは、フィーチャーチームなのです。
僕は、ウォーターフォールでもフィーチャーチームで仕事をします。
新人にテストだけ任せたりしていては、人は育たず、会社としてもリスクを抱えることになります。
実装ができればいい設計ができますし、逆も然りと考えます。
どんなときでも、コンポーネントチームは避けるべきです。
開発のリズムが合わない
今回、サーバーチームは、「ウォーターフォール」を採用し、
フロントチームは、「スクラム」を採用しました。
このことで、どんな弊害が発生したかを説明しましょう。
最初の２スプリントは優先順位の一番高い「コア機能」の開発には着手できなかった。
「コア機能」は、ウォーターフォールでいう「設計フェーズ」だった。
効率やチームの構成があるので、一気に製造し、一気にテストをする。
テストが終わるまでリリースはできず、４スプリントほどが過ぎた。
さすがにこれでは、「アジャイルの意味がない」という話になり、
- 優先順位を合わせてもらうこと
- より短いスパン（＝１スプリント）で「製造 ⇒ テスト」をしてもらうこと
を提案した。
「短いスパン」といっても、丸１スプリントかかる。
テストは専任チームがいるらしく、それ以上は縮められないという。
この場合、１つの機能をリリースしようとすると、
仕様を決定した後に、スプリントが始まり、そのスプリントの最後に、サーバー側が完成する。
E2Eテストは次のスプリントになるので、実質２スプリントの猶予が無ければリリースができなくなっていた。
また、E2Eテストの中で修正が必要になれば、リリースはさらに先延ばしになる。
ただ契約上、顧客には、それについて口を出す権利が無かった。
顧客は、失敗したなあ、という顔で苦笑いをしていた。
サーバー側の会社を少々悪役のように書いてしまいましたが、彼らはかなり譲歩してくれています。
彼らからすれば、「ウォーターフォールなのに、なんでこんな効率悪いやり方でやらねばならんのだ」と
悪態をついていても、おかしくないし、WBSの管理も相当大変なことになっていたでしょう。
コンポーネントチームが、それぞれウォーターフォールとアジャイルで分かれて開発すると、
お互いがとことん不幸になっていくのがわかったでしょうか。
幸い（？）顧客は、「アジャイルがしたかった」ので、僕の味方寄りでしたが、
それでも会社間の歪みはどうにもならなかったのがわかります。
DDDにおける、「Bouded Context」が違ったり、お互いが「マイクロサービスの単位」であれば、
ここまで酷いことにはならなかったかもしれませんが、このようなケースでは致命的でした。
利害が一致していない
開発会社に対して払うお金は、顧客にとっては「コスト」ですが、開発会社にとっては「収益」です。
そうした利害の不一致から、こんなことが起きていました。
僕が協力していた開発会社は、あるプラットフォームを提供していた。
当然、今回の案件でも、それを使うことで収益を上げようとしていて、
顧客には、「コストが下がる」「使ってもらえる分、融通を効かせる」という説明までしていた。
その通りだったら、何の問題もなかったのだけれど、「プラットフォーム」はまだ未熟な段階で、使いづらく
また、基盤としても貧弱だったゆえに、パフォーマンスや可用性に支障を来たしていた。
そんな問題だらけにもかかわらず、どうやら管理している部署と、今回の案件に参加している部署が違うらしく、
直接、担当者に連絡を取ることすらできなかった。
開発チームからしてもストレスだったのはいうまでもないが、
顧客からしたら当然、「どうにかしろ」という話なのだが、
他のプラットフォームに乗り換えるには、システムを一から作り直す必要があった。
それでもなんとか運用を進めてはいるのだが、不安が残ることになった。
「プラットフォームの問題」でもありますが、そもそも開発会社は「自社のプラットフォームが実用に耐えられないかもしれない」ことを知りながらも、
自社の「利益」の追求のために、無難な線をやめて、無理にリスクを取る結果につなげてしまい、結果、会社間の問題になりました。
そうなってくると、「信頼」や「裁量」の話などできたものではなく、徐々にスクラムは崩壊していきます。
レベニューシェアでもない限り、この対立は避けようがありません。
これは「アジャイル案件」が抱える構造的な困難で、顧客にとってリスクです。
だったらフリーランス（個人事業主）を雇ってしまえばいい
個人事業主は、特定の企業の利益に縛られないですし、余分な人材がついてくるリスクもありません。
今では、個人事業主向けの保険もありますから、加入していれば与信の面で問題ないはずですし、
優秀であれば、そのまま正社員として雇い、ずっと働いてもらうこともできるかもしれません。
開発会社に払う人件費には、「利ざや」が含まれている為、その分損していますし、
アジャイルはウォーターフォールと違って、「人材力や、会社としての力を駆使して、必ず期限を守る」わけでもないので、
わざわざ「開発会社」に頼むメリットは無いように思います。
その為、フリーランスなどの個人事業主と直接契約を結ぶ方が、リスクが少ないのではないかと考えてます。
現地に一部の開発者しかいない
今回、会社が分かれたと書きましたが、サーバーチームは「持ち帰り案件」だったらしく、開発者の姿を見ることはありませんでした。
スクラムチームについては、
プロダクトオーナーの実務の方をやっていたコンサルは、「兼任」していたらしく、週の半分ほどは顔を見せていて
プロダクトオーナーの決定権を持っていた方の顧客は、忙しさでスクラムイベント以外、ほぼ姿を見せず、部屋も別でした。
幸い、開発チームは「兼任者」がおらず、ほとんどの時間を開発ルームに籠もっていました。
ある日、開発中に仕様的に不明な点が発生して、顧客に連絡を取った。
某チャットツールを使っていたのだが、
開発チーム「ここの仕様って、どうしましょうか？」
翌日、返事が来て
顧客「どうしましょうか。こうこうするのは大変ですか」
開発チーム「今回は、ここまでやっておいて、残りはバックログに放り込みましょう」
みたいな会話をやって、その会話を見ていたコンサルが加わり、軽く議論して開発に戻る。
その機能の開発を止めている間、別のタスクに手をつけることになり、WIPが増えた。
また、サーバーサイドの技術的な仕様についての質問をする際は、
開発者ではなく、一度マネージャを通す必要があり、スプリントプランニングをしている際も
開発チーム「ここの仕様ってどうですか？」
マネージャ「すいません。分からないんで、確認します。」
開発チーム「分かりました。」
みたいなことばかりが続き、スプリントプランニングが長引いたり、WIPが増えた。
フィーチャチームになっていて、スクラムチームが全員同じ場所で仕事をしていれば、
仕様は、すぐ口頭でプロダクトオーナーと相談できますし、技術仕様は、開発者同士で話し合うことができます。
それができないと、コミュニケーションコストがかかったり、WIPが増えます。
WIP ＝ work in progressの意味で、「取り掛かり中」のバックログの数です。
ウォーターフォールでよくつかわれる「五月雨式」はWIPが増大します。
ウォーターフォールでWIPが増大すると、WBSは意味のない「３０％」とか「７０％」という数字だらけになり、リスクが増大するのですが、
アジャイルだと、バックログは「０％ or １００％」の状態しかなく、１００％になった時点で、ストーリーポイントが「消化」されます。
消化のことを、バーンダウンといったりもして、バーンダウンチャートという図を見ると、どれくらい「ちゃんと最後まで終わっている」かがわかります。
バーンダウンチャートは、横軸に経過日数・縦軸に残ストーリーポイントをプロットするので、
WIPが増えると、日数が経っても残ストーリーポイントが残り続け、停滞します。
「実際は五月雨でやってるから、もっと終わってるんだ」
と言っても、チャートを見ても分からない＝見える化されていないので、顧客がビジネスを進める上での判断の妨げになってしまいます。
しかも、そのまま終わらないで、スプリントが終了すると、目標３０に対して消化６（２割終了）のような状態になり、
その分しかリリースできず、ユーザーのフィードバックの機会を損失します。
一緒の場所にいない ⇒ コミュニケーションがとりずらい ⇒ 保留が増え、WIPが増大する ⇒ スプリントの終了までにバーンダウンしない ⇒ 顧客の不利益になる
なので、せめて「コミュニケーションを取りやすい状況」で開発することが、大事です。
- 同じ場所で仕事する
ことが一番、コミュニケーションの効率がいいです。
- Slackで気軽に会話できる
のであれば、まだましなんですが、やはり対面でないと、相手の表情とかがわからずやりずらいです。
「１４時～１８時は、現地にいようね。残りの時間は各自自由で」
くらいが、バランスがとれていると個人的には思います。（朝のラッシュも避けられるし…）
ただし、兼任とかをしていると、他の案件や顧客の日程に合わせて、外出を強いられます。
上に書いたようなコアタイムは、みんなその時間に仕事をしているし、会議もかぶったりします。
なので、「兼任」をしていると、スクラムに悪影響を及ぼす為、「専任」で入れる人を採用しましょう。
嫌なコトを無視する
最初のころは、機能分割や、設計の粒度などがわからず、そのたびに振り返りを通して、改善を目指していました。
例えば、
一つのバックログを大きくしすぎて、途中でスプリントが終わり、その分ベロシティが減った
バックログのタスク分解ができていない、または依存関係があることで、一つのバックログに複数人で取り組めず、WIPが増加した
（WIPはチーム単位です。個人ではないです。）
等の問題に対して、
細かく機能分割するコツを考え、実践する
「１日１回ペアプロをする」などのルールを決め、一つのバックログを優先して終わらせていく。
などの対策を取りながら、だんだんと改善していきました。
こういった問題は、「やり方・手法」の問題であり、解決しやすいのです。
しかし、先に挙げたような
「期限」のせいで、起こっている速度の低下・残業
「会社が違う・やり方が違う」から、機能が完成しない
役割が不明瞭な「チーム」のせいで、スクラムの力が発揮しきれない
これらは、「組織・契約」の問題で、改善するのにコストがかかる、または会社間の問題になるせいで、今更変えられない状態になります。
- 「バックログと資料を２重で作る」という無駄な作業をやめよう
という議題を挙げると、「やり方が分からない」と言われ、
ツールの利用などを提案しても、なんだかんだ忙しさとかを理由にして、変えようとしませんでした。
これは、「改善の仕方がわからない」のではなく「改善する気が無い」場合です。
たとえ「手法」の問題でも、当事者に改善の意志が無ければ、改善されません。
こうなっていくと、「毎回挙がっているのに、解決できない問題」が出てきて、そのうち無視しだします。
こうなると、「スクラムの手法」や「開発手法」に関することばかりが毎回挙げられ、
顧客はそういったことに興味がないのか、一切意見を出さなくなりました。
「時間がないから振り返りはまた今度」
なんていうアホも出てきます。
こうして、「問題発見フレームワーク」としてのスクラムが機能しなくなり、
ベロシティも上がらないので、なんとなくモチベーションも下がっていきます。
スクラムないしアジャイルは、結構大変だし、精神的負荷が高いと感じる人もいます。
それは、問題があれば、それに立ち向かい、挑戦しなければならないからですが、だからこその楽しさもあり、
解決して、実績が出ることで、達成感につながり仕事はもっと楽しくなります。
嫌なことを無視して、「振り返り能力」が下がると、スクラムが楽しくなくなります。
「機能開発」以外の時間がない
顧客は、「〇〇機能の開発」には前向きですが、「環境構築」や「リファクタリング」などにはどこか後ろ向きです。
「期限」などで、圧力がかかっていると余計に、そういった時間を取りずらくなっていきます。
しかし、IT技術を使って開発している以上、IT技術にかかわる作業は当然入ってきます。
「非機能要件」というフレーズを忘れよう
よく「非機能要件」とか呼ばれる「ログ」とか「監視」の部分だが、そういったものもプロダクトの価値を支える立派な「機能」です。
なぜなら、ログであっても「分析」「監査」といったビジネス面での要求に応えるためのものであるはずだからです。
しかし、これらの導入の際には、
「クラウドだからすぐできるのでは」
とか
「開発会社が提供するものなのだから、当然入ってるものだと思っていた」
などと、暗に言われることもあります。（開発会社側の人間が率先して言い出す場合もあれば、顧客が苦い顔をする場合もある。）
こういった圧力に負けると、「バックログに入れない」判断をしてしまうことがあるのですが、絶対にやめましょう。
バックログで管理していない作業を入れると、ベロシティが意味のない物になりますし、
ログを出さなければ、リリースできないなら、それは「機能要件」です。
「技術」もプロダクトの一部であると考えることが大事です。
あと「スプリント０」というフレーズを使いだす人もいますが、正しく理解していないと意味がない代物で、扱いに困るので、却下しましょう。
リファクタリングをする時間がない
同じような理由で、「リファクタリング」や「ツールの導入」、「新しい技術の検討」なども非難の的になることがあります。
しかし、そういった部分を最適化しないことには、どんどん品質は下がり、
その分、開発のスピードが下がったり、アプリのスピードも落ちます。
何もしなければスピードが上がらないのではありません。
何もしなければスピードは落ちていきます。
ちゃんと時間をとってCI・CDプロセスを最適化したり、リファクタリングを行わないと、余計に後で時間がかかります。
こうした最適化は、「スプリントバックログ」に落とし込み、最低１つはスコープに組み込むものですが、
「そういうのをバックログにするのはどうも、、、」みたいなことを言われたり、そんな態度を取られたりします。
「体裁が悪いものを表（顧客）に見えないようにする体質」を持っている人は特に、そんな感じです。
そもそもプロダクトオーナーが、開発会社の人間で、IT技術に対する知識を持っていて、決定権も持っていれば、
わざわざ顧客に説明するまでもなく、作業を入れられるのですが、先述の通りそうはなっていませんでした。
開発チームで、話し合い、「決まった時間をリファクタリングに充てたり、随時改善する」しかないでしょう。
あとがき
失敗談というより、ただの愚痴や意見になってしまいましたが、自分の中で、
「アジャイルにする理由」
が納得いく形でまとまったので、よかったと思っています。
こんな長文・駄文をここまで読んでいただいただけで、感謝の正拳突き１万回です。
この記事に書いた思想をベースに、理想とするアジャイル像を実現していけるように、日々精進していきたいと思います。
アジャイル宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
-
ウォーターフォール開発 ＝ 悪という見かたはしていません ↩