キングダムを参考にプロジェクトをなんとかした話

# はじめに
こんにちわ。エンジニアのdoweです。
元々はサーバーサイドエンジニアで
現在はスクラムマスターやEM見習いみたいなことをしながら、チームビルディングやエンジニア採用などをしています。

とある開発プロジェクトを、2ヶ月ほどでなんとかした話をします。

素直に工数試算をしたときは、半年くらいかかる想定でした。
それでもなんとかした、というお話です。

まず、キングダムというワードに釣られた方には申し訳ないですが
キングダムは少ししか出てきません。(笑)
でもキングダムが好きな人には共感していただけると思いますし、キングダムを見ていない人に興味を持ってもらえたらなと思っています。

ぜひ最後までご覧ください。

# サマリー
## プロジェクト(PJT)の方針決定まで
本PJTにおける事業部長からのオーダーは以下でした。

> 2.5ヶ月で開発し、リリースする。

詳しい話ができませんが、事業計画上、大事なことでした。

一方で、PJT開始前の見積もりでは
既存システムのUIの調整やロジックやDBの修正などの既存システムの改修なども必要となり、工数は22人月と試算しました。
そしてなおかつ、事業部内のエンジニアほぼ全員を投下し、9人で3ヶ月でなんとかする計画を立ててみましたが
事業部内には他のPJTも当然存在するため計画は却下されました。
(当然といえば当然です...)

そこで最終的な決断としては、他のPJTへのリソースも加味しながら以下のような体制で決めました。

* 人数はPO1人、SM1人(**自分**)、エンジニア6人(スクラム開発)
* 既存システム改修はしない（テストも書かないつもりでいた）
* 別PJTもしっかりとパフォーマンスを出す
* その上で、本PJTは2.5ヶ月でリリースする

今思うとこの計画は、無理があったと思います。(笑)
開発チームは2チーム存在し、そのうちの1チームを自分がリーダーとして、PJTを遂行することになっていましたが
両チーム共に非常にきつい2.5ヶ月となりました。

しかし、事業計画を遂行する上で、「やるしかねぇ」と思ったので、全体のリーダーでもある自分は決断しました。
そしてこれを完遂するため、両チーム含め、開発チームが全体的にベストパフォーマンスを出せる状態を目指しました。

キングダムで例えると、朱海平原の戦いで、王賁と信の隊の覚醒に近かったです。
開発をするのは開発チームであり、僕ら自身がチームを覚醒させる必要がありました。

<img width="50%" alt="d69bfb1b-7902-4f93-ba3a-93ed65db629e.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73081/331b3b60-3bda-92c8-5877-b185eab30d70.jpeg">

## 結果
結果から言うと、予定通りリリースすることができました。
本当に担当チームメンバーの努力の成果であったが、それだけでなく別チームもかなりのしわ寄せ(事業部からの調査タスクやバグ対応など)を文句も言わずにやり切ってくれました。
開発チームが文字通り一丸となって成し遂げた功績でした。

ストーリーの総ポイントで言うとほぼ100%のスピードを終始出し切った計算でした。
ただ、仕様策定や調査などのベロシティに反映されなかったものを含めると120%は確実に出していた感覚。
2ヶ月ちょっとのプロジェクトでこれだけのパフォーマンスを出し切れたのは本当にすごい。
初速からリリースまで、絶えずロスもなく走りきれたことが素晴らしいと思っています。

# チームで意識したこと
ここからはやったことなどの振り返りです。

## ・開発チームの方針を正しく全員に伝える
テストも書かないし、複雑度も気にしない。と言うのは正直あり得ない判断だと自分でも自覚していました。
だから、プロジェクトの計画を立てた時に、エンジニア全員を集め
このPJTの重要性と、事業部おける我々の役目を伝えました。

一方で、「僕らの努力がいくらの売上になるのか？」に対しての共有も行いました。
メンバーは事業のためになることを喜んでくれる方が多いので、みんなが欲しい情報は常に伝え続け、皆が納得とやりがいをもって仕事に取り組めるように努めました。

<img width="50%" alt="20161116234415.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73081/917f71b9-df59-1bf8-9844-60667ec87fd6.jpeg">

## ・まず最初にメンバーの役割を明確に決める
仕様から何まで、決まっていないことが多すぎた中でPJTが始まりました。
そんな中で、POやSM(自分)が全ての意思決定に関与しているとスピードが出ないことは明白だったので
最初に決めたのは、 **メンバーの役割・責務の明確化** です。

* POは、仕様・優先順位決めはもちろん、関係各所との折衝は丸投げ。
* SMである自分は、開発チームの障害排除に全力を注ぐ。少しでもスピードが落ちるタイミングがあれば即座に入り、障壁の排除を行う。主に仕様策定の部分でのロスが多かったが、POへの補佐を行いながら即座に意思決定を行う。
* 開発チームは、とにかく作る。困ったらSMに相談。

ここまでは一般的なスクラムと同じだが
だが今回はそれだけじゃなく、エンジニアを2つに分けた。
その2チームのなかでサブリーダー的ポジションを若手エンジニアに任せ、自分が見切れない部分(仕様策定やコードレビュー)をできる限り任せた。

こうして、スクラムチーム全員の役割を完全に明確にすることで、無駄なコミュニケーションロスなどが起きないような体制を事前に作った。
また、会議体も事前に改め、徹底的に時間のロスを削るようにしました。

今回、開発スピードを出しきれたのはこの役割や責務の明確化が非常に大きいと感じていて
役割が明確になったからこそ、開発チームがスムーズに開発を行えたと思っています。

でも実際に開発したのは開発チームなので、本当にすごいと思っています。
時にはチームに対してリーダーである僕からプレッシャーも与えたが、それに答えてくれたメンバーをめちゃくちゃ尊敬しています。

## ・優先順位を明確にする
毎週のスプリントプランニングでは、特に「優先順位」を意識しまくった。
「 **これは今やるべきことなの？** 」と言う投げかけを口うるさくチームに投げかけた。
開発をしていると時たま今やらなくてもいいことをやったりする。
開発じゃなくて、通常の業務でもそうだが、「これは今やるべきことなの？」と言う問いかけは非常にチームの意識をいい方向に向けた。(MVPと言う概念も実は大きく役立った。)

# プロジェクトの進め方
## ・進捗とパフォーマンスの可視化
今回はバーンダウンチャートを作り、目標と現状の差分をわかりやすくした。
毎週リリースしなければいけないポイントや、足りていない速度(=ベロシティ)の把握をできるようにした。
結果、チーム全員の進捗に対する認識を揃えることができ、スピードを出すべき時は全員が力を出し、そうでない時は別のことに注力することができた。
開発チームへプレッシャーをかけることもあったが、休む時は休む、と言う判断もでき
 **チームの緩急を最適化させることができた。** 

<img width="653" alt="スクリーンショット 2021-03-02 3.14.35.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73081/c6e995f9-d0cf-3e35-1a06-2187901e77b4.png">

## ・サイレントリリースを採用
いつもなら、この規模の開発をする時は、専用のブランチを作成し、専用ステージング環境を作っていた。
そして、リリース時にドンとリリースする。

ただこの場合、リリース前のステージングテストの期間を取らなければいけないため
今回はサイレントリリースをし続け、本番テストを毎週行った。
もちろん、本番にバグが出るリスクもあるがこれは許容した。もちろんバグを起こさないように気をつけながら。

これが速度向上にもつながったとは思うが、正直精神衛生上良くは無い。。。(笑)
もうちょっと心に余裕を持ちたかったと言うのが正直な気持ちだった。

# その他の施策
## ・相互レビュー会(モブレビュー)
序盤戦は仕様策定から始めたため、リリースポイントはあまり良くなかった。
そんな中、なんとか期間半ばでオンスケペースに乗せることができた。
しかし、開発を2チームに完全に分けて開発をしていたため、それぞれのメンバーは別画面の仕様を理解していない状態が起きていた。
コードの複雑化ももちろんあるし、両者のロジックが噛み合わずデグレもあるかもしれない、、、という状態だ。

そこで、相互レビュー会を開催した。
丸二日を使ってモブレビュー、スプリントを丸々一回潰して、一旦みんなで立ち止まった。
ここでリファクタやデグレ解消もした。
前半戦で残業も多かったから、この1週間はほぼノー残業。小休止の意味も込めていた。

## ・フロントとバックエンドは徹底的に分離
今回のPJTでは、今まであまりやっていなかったSPAでの開発をした。
設計フェーズでは、API定義をblue printを使って作成し
これを起点に、フロントとバックエンドでそれぞれ爆速で開発。

もちろん最後に結合テストは必要で、そこでのバグもあったがなんとかなった。
初めてのSPAの開発だったが、このAPIの定義が本当に大事だったという気づきを得た。

それだけではなく、実は少し前にstory bookも作っていたので、こういったものもフロントエンドの開発において速度向上に役立った。

イメージ的には、函谷関の戦いで、合従軍が国別に配置をはっきり分けたのに近い。
<img width="50%" alt="20161116234415.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73081/33345934-e036-7a68-473a-d407a461b5fa.jpeg">

## ・とにかく時間を作った。
フルリモートでのコミュニケーション活性化のために毎日夕会を開催していたが、週二回に変更した。
1日30分だったので、1.5時間/週 削減した。
こう言った、細かいところで時間をとことん作るという意識も大事だった。
<img width="50%" alt="20161116234415.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73081/43a18dec-4ffc-1960-c626-07e996a48484.png">


## ・終盤戦では気持ちで勝負。結果にコミット。
平均のベロシティは40pt弱だったが、終盤戦では、90ptをリリースしたタイミングがあった。
リリース前週にテストの期間としてバッファを生み出したかったので、この決断をした。

だが、もうそろそろメンバーの気持ちが切れるころだ。

だからSMであり、リーダーである自分がを剣を抜いた。
プランニング上で、90ptにどうしても足りないところを自分が開発した。
90ptリリースするとSMが言ったからには絶対にリリースをする、という気持ちで乗り切った。

キングダムでいうところの、函谷関の戦いで、最後に政王が剣を取った時の感覚に近い。
普段他の雑務などに追われている自分も、この時ばかりは残業でもなんでもして開発タスクを消化した。
<img width="50%" alt="20161116234415.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73081/4cec1bb3-d919-cc4f-b3a1-5a0bf37cdd10.jpeg">

世の中にはいろいろなタイプのマネージャーがいると思うが
自分は「一緒に戦う」ことを大事にしているため、普段はあまりやってない開発タスクもこの時ばかり共に命を賭して戦う決意をした。

# その他、気付き、改善点
## ・単体テストの文化
単体テスト書く時間を最大限抑えるつもりでいたので、ほぼ書かないつもりでいたが
実はこの一年で、テストを書く文化が知らぬ間に根付いていた。
気がつけば、リリース後も全体のカバレッジは上がっていた。
本当にテストを書く文化ってすごいと痛感した。

## ・チームビルディングの重要性
一年前、実は開発チームは自分を含め3人だった。
そこからこの1年間で10人ほど増え、本PJTの前にやったPJTでは、チーム面での問題がいろいろ発生した。
突然行方がわからなくなったメンバーもいたし、揉めたりもした。
チームワークができていなかった部分がたくさんあったが、それを乗り越えた今回のメンバーのチームワークは本当に強かった。
苦悩を共に乗り越えた仲間との信頼関係は、自分の想像以上のパワーを発揮した。
<img width="50%" alt="20161116234415.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73081/0e1e2623-f655-d31e-cad3-8e512c6ddb6e.jpeg">

## 改善点
### ・セールスメンバーとのすり合わせはもっと気をつけるべきだった
セールスメンバーとのすり合わせを甘く見たせいで、無駄な工数を使ってしまった場面があった。
僕らとセールスでは見ている景色が違う。
だからこそしっかりとヒアリングを行い、重要な条件や情報は全て出し切らないといけなかったし
逆に開発チームからの要望は漏れなく伝え切るべきだった。

### ・実は今回のPJTは失敗となった
今回のリリースは、システムリリースとして目標を達成した。
そして、サービスリリースを控えていたところ、DB構成に問題が発覚したのだ。
目標達成のため、いろいろな負債を犠牲にしてきた中で起きた大打撃だった。

PJT開始時の設計での自分の判断ミスが大きく、非常に心が痛く、大反省をしました。
個人的には、システムリリースまでの道のりで得たものが大きかったのですが
やはり、計画が遅れてしまった = 事業計画に影響を出してしまったので、反省すべき点だったと思います。
これをポジティブに捉えつつ、同じミスをしないよう、今後は注意しなければいけないと思っています。

<img width="50%" alt="20161116234415.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73081/106b6db8-4c23-d1c4-7b03-5539e9321f3f.jpeg">

# 最後に
事業会社であれば、事業計画が非常に重要であり、僕らエンジニアもその事業計画の上で成り立っています。
一方で技術的負債のようなものは、エンジニアの僕らは危機感やリスクを感じ取れますが、経営層(営業畑)にはなかなか伝わらない、なんてこともよくあるのではないでしょうか

そういった面も加味しながら、僕らエンジニアは経営層に寄り添いながら、どうやって作っていくかを意思決定しなければいけない場面が訪れます。

今回、私の決断はかなり事業計画に寄った決断をし
エンジニアからは不満が出てしまいかねない部分もありましたが
それも含め、エンジニアやセールスも関係なく、全員がチームです。

こういった、「やりきった」実績を作り、理解してもらいながら信頼を気づき
今後、ステークホルダー全員が幸せな未来を作るために僕らは開発をしていかなければいけないのです。

今回のような決断は、個人的には二度とやりたくはないですが(笑)
より良いプロダクトを作るため、日々精進したいと思います。