ちっちゃいウォーターフォールがスプリントに2つできてしまう問題をどうするべきか？

ちっちゃいウォーターフォールがスプリントに2つできてしまう問題は、アジャイルコーチとしてお客さまを支援していると、ほとんどの現場ででてくる問題です。代表的なものは「バックエンドができないとフロントエンドが開発できない問題」。2つの依存する開発がならぶと、必然的にそうなってしまいがち。さて、どうやって解決スべきなのでしょうか？

案1：フィーチャチーム作戦

最近あんまりフィーチャって聞かないですが、コンポーネントチームとフィーチャチームの文脈でたまに出てくるチーム構成です。いわゆる多能工。ひとりのエンジニアが要件定義からリリースまで、フロントエンドからバックエンドまで一気通貫で働けるので、「ちっちゃいウォーターフォールがスプリントに2つできてしまう問題」を避けられます。

最近だとJavascriptの利用がサーバサイドまで広がってきているので、フロントもバックエンドもJSで統一できたりしますし、APIの作り方もシンプルになってきているので、比較的導入しやすくなってきたかもしれません。

しかし、ネガティブな面を考えると、いわゆるなんでもできるエンジニアが必要なチームなので、導入ハードルは高いと言えます。育成にも時間が掛かるでしょうし、ハイレベルなエンジニア採用は売り手市場な現状とても難しいでしょう。

案2：モックなど中間層を先に作る作戦

結構現実的なのがこの案です。実際に、この案からはじめるチームは多いです。

アーキテクチャ的にも職能的にもフロントとバックエンドに分かれているのはよしとして、その結合部分を先に設計・仮作成（Swaggerを利用、MockやIF仕様書を作るなど）することで中間層を設けます。あとは各者中間層にむかって仕事をするだけ。

ネガティブな面は、フロントとバックエンドの結合コストはなくならないこと。ただし、軽減はされます。

案3：プラットフォーム化する作戦

バックエンドをフロントエンドに提供するAPIサービスと定義し、専任チームを立てて専属で開発を行う形です。いわゆるコンポーネントチームになるのでしょうかね。マイクロサービスチームもこの形なのかなぁと思いました。

Chatworkさんのモバイルアプリ開発チーム、カンバンはじめました。に登場するiOSプラットフォームチーム、Androidプラットフォームチームがちょうどいい事例です。

彼らはプラットフォームチームの導入理由として

突発依頼の対応が必要
プロダクトに向かうスクラムチームではなく、技術的判断が求められる専門家チームであること
調査・検討が続く先のスパイクが必要な作業が多いこと

をあげており、プロダクト開発の中心になるスクラムチームを支えるために、同期的な「スクラムの歯車」とは別の非同期的な「かんばんという歯車」を取り入れ、開発全体の歯車がスムーズにまわるようにしています。

これが同期的なスクラム同士だと、スプリントごとの同期がボトルネックになり「突破依頼」や「スパイク」で消耗してしまう可能性が高まります。

学ぶポイントの多いすばらしい事例ですね。

一方でネガティブな面は、『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』に出てくる「無価値なAPIをひたすら作り続けるチームになってしまう」というビルドトラップにはまりやすいこと。

大きな企業だと、プラットフォーム化が全体の生産性アップになりますが、プラットフォームチームが誕生し、そこが予算を持つとなると、その予算はプロダクトの成長とともにどんどん大きくなります。そうするとその予算を消化しなければならなくなる（消化しないと翌年の予算が下がる）ので、不必要なものまで開発計画にいれてしまったり。

これ、結構ありがちなんですよね。間接部門（ユーザに直接価値を届けないチーム）の悩ましいところだと思います。間接部門は価値を届けるユーザの定義がとても重要。