大企業におけるスクラム開発の課題を乗り越える、5つの勘所
ここからスクラムのフレームワークに沿ったアジャイル開発を始めていくわけだが、進める上で気をつけなければならないこととして、沓澤氏は次の点を強調した。「スクラムなどの手法は、ただの『型』。何も考えず、ただこなすだけではアジャイルな状態にはならない。アジャイルを『する』ことと、アジャイルで『いる』ことは明確に異なる。『なぜ？』と問い続けながら、アジャイルのプラクティスを、アジャイルの価値観に結びつける意識が重要です」。
勘所1：サービスコンセプトに「直結する機能＝筋肉」／「直結しない機能＝贅肉」。スクラムイベントを通して体脂肪1桁のプロダクトを目指す！
コンセプト策定が終わり、要件定義をしていく中で、「MVP（Minimum Viable Product）のスコープをいかに設定するか」という大きな壁にぶつかった。既存のリモート会議ツールが台頭している中で、チャットや鍵付きルーム、ワンクリックコールといった機能が必要であることはわかっていたが、2か月という短い開発期間を考えると、明らかにスコープが大きすぎる。だからと言って、「この機能を削る」という意思決定を下すための根拠を集めるのも、非常に難しい。
そこで開発を進めながら、ベロシティを基準としてスプリントごとにスコープを点検することで、ステークホルダーの誰から見ても「残り期間からして、どう考えてもこのままでは無理」という現実がわかるようにした。また、スコープの外に追いやる機能を何にするか判断する際には、「我々が提供したい価値に直結しない（＝サービスのコンセプトと合致しない）機能はMVPのスコープ外」と決めた。そうすることで、「鍵付きルームはあれば便利だけど、話しかけやすさには直結しない」といった具合でMVPのスコープを絞り込んでいくことに成功した。
勘所2：基本的にはスクラムガイドに従うべきだが、現実はガイド通りに進められないことばかり。そこでガイドを投げ捨てるのではなく、ガイドを自組織に最適化していくことが大切。
課題は他にもあった。スクラムガイド2020の定義では、「主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う」とある。しかし大企業の場合、デザイナーやPR担当者、チーム内のマネージャーの順で、開発に近ければ近いほど“プロダクトへのコミットメントが高い”一方、それより上位にいる企画部門長や事業部門長といった“意思決定のパワーの大きい”人になればなるほど、時間的な問題でスプリントレビューに参加できないことから、最後にちゃぶ台返しが起きるのではないかと、不安を感じていたのだ。
そこで、幹部ともこまめに認識と期待値の調整をしておきたいと考えた沓澤氏は、スプリントごとのインクリメントを既存の会議体に持ち込み、プロダクトの小さな成長を毎週見てもらうことにした。パワーポイントで作成した資料を見せながらプレゼンテーションを行う従来の形式ではなく、インクリメントを実際に触ってもらう形式に変えたのである。これにより、幹部にとっても残り期間でどのくらい変わるかの予想がしやすく、インクリメントから大幅に離れた期待をしないメリットがあったほか、ステークホルダーが好意的に見守ってくれる環境が整ったという。「承認ルートのラスボスではなく、開発チームの仲間になってもらえた感覚が強くなり、チームもとてもうまく回るようになりました」（沓澤氏）
勘所3：大企業の武器は人材の豊富さ。早期からのコラボレーションで開発スピードと品質を向上させられる。
今回のプロジェクトで行った工夫のひとつとして、WebRTCやセキュリティ、知財などの専門チームを、早期から頼っていったことがあげられる。通常、こうした専門チームとコラボレーションする際には、チェックリストが渡され、それらを埋め切らなければサービスローンチできないと決められている。そのため、どうにかチェックシートを埋めようと、最後になって頼るケースが多いのではないか。しかし、それはもったいないことだと沓澤氏は言う。
例えば、セキュリティチームには最初から検証環境を共有して、常にアクセスを可能にしていた。同時に、セキュリティチームからは他のリモート会議ツールの脆弱性を共有してもらい、対策を教えてもらってプロダクトに反映していった。開発後期になると、ソースコードも共有して、ペネトレーションテストを実施した。早期からコラボレーションしたことで、相手にもプロダクトに対する愛着が湧き、より熱心に協力してくれるメリットがあった。
勘所4：身内からも愛されないプロダクトが市場に受け入れられるのか？ ドッグフーディングで社内ユーザーの声を存分にプロダクトに反映すべし。
いよいよローンチだ。以下の図の通り、社員・事前受付ユーザー・エンドユーザーの3段階でユーザーを増やして行った。
特にドッグフーディングでは、チームのエンジニアからスタートし、実際に「NeWork」を使ってリモートワークを試してみた。次にチームメンバー、ステークホルダーへと公開範囲を広げていったところ、予想以上のフィードバックがもらえ、モチベーションにつながると同時に、ローンチ前に多くのバグを潰すことができたという。
勘所5：MVPだけでローンチしても価値を感じてくれるユーザーはたくさんいる。安心してとことんスコープを小さくするべき。
8月11日にプロモーションサイトを公開したのは、諸々の社内事情があったためだ。プロダクトローンチは間に合わなかったが、プロモーションサイトに事前受付フォームを用意して先行利用の募集を開始した。結果、市場から想像以上に多くの反響が寄せられ、社内で歴代最高の事前登録者数を獲得した。とはいえ、プロダクトはまだ完成していない。「エンジニアとしては、このときが一番つらい時期だった」と沓澤氏は振り返る。
「実際に使ってみたら期待とは違ってSNSで叩かれるのではないか？」「本当にセキュリティ大丈夫だよな？」「あれだけ苦労して小さくしたスコープだけど、本当にそれでよかったのか…」こうした不安を払拭するために、事前登録ユーザーの中から最初は20人を招待してフィードバックをもらいながら、徐々に招待人数を増やしつつ、高速でプロダクト改善を行った。すると品質に対する指摘もいくらかあったものの、それ以上に多くのポジティブな反応が見られ、提供したい価値を届けられている実感を得ることができた。
最後に沓澤氏は「今回の発表を聞いて、『NTTコミュニケーションズでも内製でアジャイル開発ができたのだから、自分たちにもできるのではないか』と感じて挑戦してくれる人が増えたらうれしい」とエールを送った。
