Schema-Driven Development とアジャイルなチーム
最近は新規サービス開発で GraphQL を使っている。同じチームでAndroidエンジニアの geckour 氏が記事を書いてくれていたので、触発されてちょっと書く。
上の記事の中で、この新規開発以前にあったAPI開発の問題点となぜSchema-drivenな開発にしたいのかについて触れられているので、ぜひそちらを見ていただきたいとして、僕が感じたschema-driven developmentの意外?な副次的効果について書いてみたい。簡単に書くと、各開発者が職能を超えてタスクを進める、アジャイル的な動きが広がったという効果があった。
前提として、僕らのチームは開発者が15人前後くらいいて、だいたい半分弱くらいが Web devs (backend + web frontend), 残りの半分強が Native devs (iOS / Android) となっている。一応webとnativeでゆるくわかれているが、同じ目標を共有した1つのチームなので、スクラムのセレモニー的なミーティングも基本一緒にやるし、そこの垣根を超えた動きは歓迎という感じである。
で、最近の課題として、プロダクトの仕様や方法が詰まっていった結果、チーム結成時に思っていたよりもタスクがWeb側に寄っていた、というのがある。平たく言うと、ボトルネックがWeb devs側の開発になっていて、何も手を打たないとNative devsの手が空いてヒマになってしまう。
この状況に対して、もちろんメンバーの採用や入れ替えという手段もあるが、せっかく組成して同じ時間を過ごしてきたチームのメンバーをがちゃがちゃ入れ替えるのはあまりやりたくない。なので、職能に縛られない動きでカバーされていくのがアジャイル的で理想である。
とはいえ、各々の専門性を考えるといきなり Native devs のメンバーに Backend (Ruby など) の開発をしてくれというのは難しい話である。もちろん、Native devsの中に以下の要件を満たす人がいれば転籍はありうる -
(1) 本人が Backend 開発に興味があって
(2) キャッチアップ速度も速くて
(3) 組織的にみてもその人がNative チームから抜けてもオッケー。
...まあ、なかなかそう3つ条件が揃わないのではないか。(1) (2) が揃ってるやり手人材が (3) も満たすのはかなり余裕がある組織でないと難しい (とはいえ今所属してる組織はかなり寛容というか、本人の意向を尊重して調整してくれるので、上に近いことも行われていたりするが)
ということで、現実的には、Backend 開発そのものではないが、いままで Web (Backend) devs がやることが多かった一部の仕事を、Native devs に肩代わりしてもらう、というのが一つのやり方になる。そして、実はここに Schema-driven development が効いてきた、というのが今のチームで起きていることだ。
API schema というのは、開発の中心部分に位置している。frontend と backend の疎通のインターフェイスであることはもちろん、ビジネスドメインを色濃く反映したものであるので、仕様書に近い意味合いもある。なので API Schema を決めるためには、まず仕様を理解し、どう実現するか、正しくドメインモデルとして落とし込む必要がある。その上で、ある程度DB設計のことも考えつつ、フロントエンドからの使いやすさも考えて、Schema の形で表現していく作業になる。
で、僕はこれまで API Schema を作るのは backend 開発者の専売特許...とまでは言わなくても、backend 開発者がやった方がよいことが多いと思っていた。なぜなら Schema は使いやすさ以前に実装として実現可能でないといけないので、DB設計をする人が最終的に責任を持つ必要があると思うからだ。
なのだけど、ここ数週間で僕はこの考えを捨てつつある。上記のように Native devs が手が空いてしまうという問題に際して、本来は数ヶ月先に実装する予定だった機能に Native devs に先に着手してもらうことになった。それで実際に Native devs に仕様詰めから GraphQL Schema を書くところまでやって頂いたのだけど、それが初の試みであったにも関わらず、Backend 視点で見ても全然実現可能だし、違和感がなかった。
もちろんレビューをしたし、それによって手直しは発生したけど、それはいままで「BackendがSchemaを書く => Native devs がレビューして手直し」というフローだったのが主従逆転しただけで、必要なステップである。自分が主として仕様からSchemaに落とし込むよりは、すでに成果物があるところからレビューをする立場の方がずっと楽だったし、職種を超えてアジャイル的にタスクを進められている感覚を得ることができた。
もっというと、先に Schema が決まっていることで Backend の開発はいつでも着手可能な状態になっている。上で Native devs に Backend 開発してもらうのは専門性の観点で難しいと書いたのだけど、ここまでバチッとschemaが確定してるとそれすらもイケそうな感じがある。「Native devsがSchemaを書く => Backend devsがレビューして手直し => Native devs がBackend実装する」という流れだ。この場合、フローの中間成果物としてSchemaがあり、そこでBackend devsによるレビューが入っているというのが、安定感を出している理由だと思う。これが「Native devsがBackend API全て実装する => Backend devsがレビューする」だとどうだろうか? 多分Native devsはどこからどう着手していいのかも迷うだろうし、慣れない開発の中で色々同時にやることで、仕様理解がおろそかになったりしてしまうだろう。大事なのはまず仕様理解、それのドメインモデルへの反映であって、その成果物が先にできているというのがフローを安定させているのだ。
まあもちろん銀の弾丸ではない、場合によってはBackend実装が複雑なものであればやはりBackend devsがSchema設計したほうが良いものはあるだろう。それはチームの状況や作る機能の性質に応じて考えていけばよさそう。
ということで Schema-driven development, タスクのアサインを流動的にしてチームをアジャイルにするような効果もあったという話でした。いまのチームの Native devs は GraphQL を導入するだけでも一苦労だったところだったはずなのに、それだけじゃなくどんどん垣根を超えた動きをし続けていてスゴイなあと思っていて日々感謝です。
あとここまで書いて思ったけど、場合によってはプロダクトマネージャーがSchema書く世界線もありそうね。実装者が足りなくて仕様かける人が多い/強いチームだったらそうなる。
(毎度ですがトップ画像はみんなのフォトギャラリーからお借りしています。 GraphQLやアジャイルなチームから、網目状に繋がってる様子をイメージ)
noteの通貨流通量を増やしていきたい!!