#イベント
**前半の[正しいものを探す実践者の対話セッション ：「正しいものを正しくつくる」とは何か。カンファレンス レポート①](/news/96)もご一読ください。**
**「「正しいものを正しくつくろう」と挑戦している企業の方をお招きして、[2017年8月29日に開催したカンファレンス](https://guildworks.doorkeeper.jp/events/63137)。
「Pollet（ポレット）の正しいものを正しくつくる事例」としてPollet株式会社・鈴木良様とギルドワークス代表市谷が事例を紹介しました。
困難を極める開発をなんとかゴールさせるために、市谷にどんな作戦があったのか。
※本稿は市谷が発表した「[鉄壁の中のアジャイル](https://www.slideshare.net/papanda/ss-79239778)」をもとに再構成しました。**
なお鈴木様の発表内容は「[オズビジョンの社長ブログ](http://oz-vision.blogspot.jp/2017/09/blog-post.html)」にて公開されています。
事例は[インタビュー](/casestudy/archives/26)でもご紹介しております。
## 「正しいものを正しくつくる」を支える
鈴木さんとはギルドワークスの創業からお付き合いさせていただいています。
２０１４年に新規事業の検証の実施、その翌年２０１５年ハピタスさんの検証を、それぞれプロジェクトを組んでやってきましたが、進め方、考え方、言い方などで、ことごとくケンカになりました。完全に仲違いしていたらここにはいません。
私たちは[仮説検証型アジャイル開発](https://right.guildworks.jp/)をすすめていますので、「仮説検証しない」というのは、私のセオリーから外れます。しかし、Polletのお話を聞いたときに「三度目くらい鈴木さんがやりたいことをそのままやってみよう」と思いました。
セオリーから外れつつも進めることには、理論的な理由もありました。
Polletはオンラインのアプリとオフラインの決済、いろいろな手段を行き来するサービスなので、体験してみないと検証が成り立ちません。その点、どうしてもある一定の領域でのMVP検証が必要なのですが、「ある一定の領域」が大きい。それで作ってから検証せざるを得ないということがありました。
それから、提携候補先からいい反応をいただいていたということ。これらを検証結果とみなしていいだろうと判断してすすめていきました。なので、本カンファレンスは「正しいものを正しくつくる」を支えるがテーマですが、今回の話は「正しいものを」よりも「正しくつくる」を支える、がメインとなるお話です。
## Pollet開発におけるミッション
Pollet開発におけるミッションは大きく２つありました。
・Polletの内製チームが独り立ちできること
・サービスとしてローンチがちゃんとできること
それぞれに困難がありました。
### Polletの内製チームが独り立ちできること
ギルドワークスといつも一緒に組んでいるギルドメンバーと取りかかれば、プロダクトのローンチはできます。しかし、ローンチの後にプロダクトを育てていくのは間違いなく内製チームのみなさんだから、彼らが自分たちで運用できるようにならなければいけない。それが大事なミッションだととらえました。
しかし、内製チームはサービスを０→１で立ち上げた経験がまだない、若いメンバーの方々でした。しかも彼らの経験不足を補うためにこちらでアサインしたメンバー（傭兵）は、大阪とセブ島にいた。インターネットをつないでスクラムイベントをやったのですが、案の定、ミーティングが全然盛り上がらない。つながらないし、音は悪いし、何言っているかわからない。
さらにバックログリストがしっくりしていない「これどうなればいいんだっけ？」みたいな感じになっていた。これはどうひいき目に見ても、完成する気がしない…。
### サービスとしてローンチがちゃんとできること
サービスの性質上、大きなステークホルダーとしてカード発行会社様が絡んできます。彼らがコミットしている以上、こちら側だけで「ローンチを先に伸ばしてもいいか」という判断ができるようなプロジェクトではない、という前提があります。
さらにその裏側にはカード発行側の開発会社もいます。彼らが作るものを無視して進めるわけにはいかない。全体としてモノがそろわないとローンチできない。そこで進め方や考え方をすりあわせなきゃいけないのですが、スピード感や価値観が全然違う。
私も最初のミーティングにはとりあえず行ったのですが、すりあわせる余地がないというか、時間がないというか、考え方が真逆なのでまとめようがない。これはどうひいき目に見ても修羅の道に入っていく…。
まとめると…
命題は、
・「バラバラのチーム」で「決められた範囲の機能開発」を
・「スクラム」で「決められた期間内」で収めよ。
スキルも、経験も、場所もバラバラのチームで、一定の体験ができるようなMVP（必要最小限の能力を兼ね備えたプロダクト）を作らなきゃいけない。しかも決められた期間で収めなきゃいけない。これが大事な制約ですね。
スクラムで開発するというのは、ポイントをカードに溜めてリアルに使うという新しい体験なので、最初にどういう形であるべきかを決めて一直線に作っていくのは難しい。やはり作りながら関係者間で、ああでもないこうでもないと話し合いながら、あるべき姿を追わなければいけない、となると、おのずと反復的な開発にならざるを得ない。
これをどうやって実現するか。それが「鉄壁の中のアジャイル」と名付けたものです。
## 「鉄壁の中のアジャイル」
具体的には二つの作戦をとりました。
ひとつ目が「全員でプロダクトに背骨を通す」。ふたつ目が「外堀防衛作戦」。
### 「全員でプロダクトに背骨を通す」
ひとつ目の「全員でプロダクトに背骨を通す」ですが、まず「全員で」というのが大事ですね。スキルも経験も会社も場所も違う人たちで作るので「一緒にミッションに向かう」という方向感がない状態で何かをやっても無駄です。
まず、神奈川県の某所で合宿をやりました。大阪から人を呼んで、鈴木さん達も私も参加して、お互いに「インターネットの向こうにいる誰か」ではなく、ちゃんと人間として存在をするんだ、ということを認識し合った。
そこでスターターピストルもう一回鳴らすということをしました。当初は鈴木さんがバックログを考え、メンバーがそれを読み解いてキャッチアップしていく状態だった。先行して色々検討していただくのは良いのですが、常にキャッチアップをしなければいけないというデメリットもあります。誰かが先に行って誰かが遅れているという状態を、一旦ゼロにしよう、チームとしてもう一回スタートのリズムを合わせ直すことを狙って合宿をしました。
合宿した結果、スクラムイベントやSlackでのコミュニケーションが改善されました。
「全員で」が形成された上で「プロダクトの背骨を通す」ことに臨みました。これを分解して考えると、３つの作戦で臨んででいるんですね。
・①どうなれば完成と言えるのかの認識を揃える
・②プロダクトの背骨となるものを見極めよう
・③プロジェクトとチームをバッファで守る
#### ①「どうなれば完成と言えるのかの認識を揃える」
言葉の通りです。完成のイメージが揃ってなかったら結構やばいですよね。パックログを1個1個取り出した時に、どうなれば良いかが分からない、人によって意見が違うと、どこまでやれば良いのか誰も判断できない。見積もりを言いあってもずれているし、その状態でコードを書いた日には全部ずれてしまう。これは揃えなければいけない。そのために「誰かがいつか見立てた見積もり」をキャッチアップして読み解いて…ではなく、全員で見立て直す。
実際、合宿で全体を見直し「●●さんがやった見積もり」じゃなくて「自分たちでやった見積もり」になった。「誰か」じゃなくて「自分の」仕事にする、ということを狙いとして行っていました。
大事なのが着地までのリリース計画をちゃんと全員で見立てるということです。見立てをしてバックログリストがあって終わり、じゃなくて「どのスプリントでどこまでやるのか」見立てると、何月ぐらいに、どこにたどりつけるのかが見えてきます。すると、バックログのリストが大きくなっても「いつ終わるのか全然想像がつかない」なんて状態にならない。いつ終わるのか現実感をチームで持つことができる。
#### ②「プロダクトの背骨を見極める」
そもそもプロダクトの背骨とは一体何かというと、ユーザーがサービスを利用するにあたって必ず通る機能、「これがあればひとまず動かせる」というような機能です。
この背骨が何なのか設定しておくと、まず「ものが動かせる」という喜びが得られます。背骨を通すというのは目標にしやすいですね。背骨が通せたらまとまって動かせる。動くものがあると安心感が出てきますね。絵に書いたバックログじゃない、ちゃんと動くぞ、と関係者も安心しやすいです。また、開発チーム自身も安心してつくっていけます。
完成図を想像して、それを端からいきなり作り始めるのはなかなか大変です。背骨というベースがあって、そこに機能を追加していくという、インクリメンタルな方が作りやすいということで「このプロダクトにおける背骨は何なのか」を見極め、それを最初に作っていきました。
#### ③「プロジェクトチームをバッファで守る」
厳しそうなプロジェクトほど「スプリントごとに見立てとしてちょっと甘めに見とこうかな」みたいな感じで、バッファを詰みたくなるものですが、最初のリリース計画の時にそうやっているとバッファだらけになってしまいます。そして、スプリントごとにまぶされたバッファは有効に使われることなく、パーキンソンの法則に従ってただバッファが消えるだけ。
なので、バッファをスプリントごとにとるのはやめ、見立てとしては厳しめに、前詰めにやることにしました。まず背骨を作り、残りのスプリントで背骨に対する肉付けを行うという作戦で行きました。
これによって、「本当の最悪のことが起こって、リリースできないです」という事態に対して「背骨と多少の肉を持って動かすことができる」ということができます。
スプリントに散らさなかったバッファは計画上の最後にまとめておく。つまり、計画上は何もしないスプリントが何個かあるという状態です。何かあった時にそれをちょっとずつ取り崩すというようなマネジメントをやりました。
### 「外堀防衛作戦」
もう１つの、外堀防衛作戦の話をしていきます。
具体的には、スプリント開発を外堀で守る。外堀すなわち線表です。単なるスケジュールだけでなく、いつ誰が何をするか、明確化してスプリント開発を守りました。
まず、先回りをする必要があると思いました。内製チームの経験が不足しているなら、経験を先回りしなければいけない。外部関係者のリスクがあるなら、そのリスクを先回りしていかなければいけない。
一番問題になっていたのが経験不足。経験が足りないとプロジェクトとして何が起きるだろうという予測ができない。一回やれば絶対必要だとわかることでも、やったことがなければ予想できない。外部との連携もありますから、パフォーマンスは大丈夫なのか、検証しなければいけない。全部つないだシステムテストをやっておかないと怖い。ではテストのプランニングはどうするか、この辺は当然経験豊かな皆さんは「当然じゃないか」と思うかもしれませんが、やったことがない人にすればなかなか手強い問題です。
そこで、どういうタイミングでなにをやるべきか、マイルストーンを毎月置いておくことで、そこに向けて準備をしていったわけですね。
外部関係者が手強いですから、彼らのコミットメントを明確化するために先手を打たないといけないですね。
メール添付でやり取りしてるくらいですから、このボールが誰のものか、誰が今遅れているのかが非常に曖昧になりやすい。いつ誰が何をするか、起きていることを明確化するために、まず基準を作る。その基準が外堀ですね。
もう一個の問題、プロダクトオーナーの要望の凍結化というのがありました。
プロダクトオーナーを社長がやっていると、社長の好きなタイミングで色々言ってきますからとんでもないことになりますね。もちろん鈴木さんのことです（笑）。
とはいえプロダクトオーナーの言っていることも受け止めなきゃいけない。なのでここの外堀をアイスボックスにして「ここに入れときましたから」ということが大事ですね。もちろん後で余裕ができたらそこから取り出してきて解凍する。優先順序付けをして「やっぱりいらんな」とか「これやった方がいいですね」とかみたいなことをやるんですね。
内側ではスプリント開発で攻め、その外側では結構堅めのマネジメントが求められていた。曖昧なコミット、プロジェクトタスク、PO社長の要望に全包囲されているスプリント開発があってこれを線表で守るわけです。
しかし開発ですから、当然想定していないような問題も起こる。その外堀を踏み越えてくる奴らがいます。
「ポイントの付与をいつするのか」でちょっとした揉め事がありました。多分、鈴木社長だったと思いますが「ここでどうしてもやらなければいけない」とおっしゃるわけです。
それをどうにかしなければいけない。スプリントにポンと突っ込むと開発が混乱してしまうので、計画をもう一回練るんですね。そこで取り崩すのがさっき言っていたバッファです。
何もしないスプリントで吸収して、なんとか凌いでやっていくというような開発でした。
## 正しくつくるために、場合によっては手段を選ばない
あんまりかっこいい開発じゃないですよね。むしろ泥臭い開発かもしれないですね。
「スクラムを使って良い感じにできました」という話は世の中にたくさんありますし、それはそっちで聞いていただくとして、現実ではいろんな人が、いろんな人たちと開発しなければいけないので、こういういびつな形になることもある。
場合によっては手段を選んではいけない、ということが私の言いたいことです。
まとめます。
Pollet内製チームが独り立ちできるというのもミッションですが、傭兵チームが去ったローンチ後の拡張開発運用は、内製チームだけで実施しているという状態です。
もともとこの内製チームの方々も、中村洋がオズビジョン時代に現場コーチとして関わっていたメンバーだったので、テストコードをちゃんと書いて、ちゃんとCIを回して、スクラムで何をやらなければいけないのか当然理解している。ちゃんとできる人たちなのです。
ただ外からとんでもないものが来ると、誰もが苦戦する。そこをちゃんと外堀で守ることができれば乗り越えられるし、その後は内製チームでちゃんとやれるということですね。
## 「最後まで自分たち自身を見失わないチームに正しさは宿る」
外堀・内堀と言っていますが、一番大事なのは当然チームの力です。チームの力ががあってコードが生まれて、リリースしますから、チームの力でできた成果だと思います。
鉄壁の中のアジャイルは、Polletの初期開発における開発のスタイルでした。
ケースによって、その開発における制約には何があるのかを捉え、色々調整しなければいけません。すべてを同じスタイルでやっては、当然うまくいかないことが多いだろうと思います。
何よりもああやってふりかえりをしてお菓子を食べながら、自分たちを奮い立たせをながらやっていった皆さんこそが主役でして、最後まで「自分たちにはできないんじゃないか」とか「もうだめだ」とかいって諦めずに、正しさを追い続けたチームだったからこそ、ちゃんとローンチができて、その後もうまく行っていらっしゃる。
正しさは、きっとそういう人たちに生まれるのではないかなと私は思っています。
どうもありがとうございました。
### お知らせ
2017年10月27日（金）に『「正しいものを正しくつくる」とは何か』を大阪で開催します。
是非ご参加ください。
「正しいものを正しくつくる」とは何か(大阪開催) https://guildworks.doorkeeper.jp/events/64730
