kiizankiizanの開発体制はどのように生まれたのか 〜開発メンバーの一言からはじまったチームビルディングの裏側〜
前回のインタビューでは、岩井さんの目的に向かう開発についてお伺いしました。今回はkiizankiizanの開発チームについて、どのような体制で開発しているのかを、kiizankiizanでCOOの大堂がインタビューをしました。
上流工程から取り組んで、課題解決をする開発チーム
大堂：
では、はじめにkiizankiizanの開発体制からお伺いさせてください。開発チームが一番大事にしていることは何ですか？
岩井：
kiizankiizanは目的に合わせた最適な手段や行動をとることを大事にしていて、開発チームも同じようにそれを大事にしています。それを僕らの中では「目的最適」とよく言います。その指標となるのはleeapのMISSIONで、上流工程から他チームと協力して課題解決をしています。
大堂：
詳細をもう少し教えてください。もう少し具体的に上流工程から、どう課題を解決していくのか教えてください。
岩井：
開発のよくある流れは、ディレクターや依頼者自身が要件や仕様をまとめて、エンジニアに渡ってくる感じだと思います。
kiizankiizanの開発チームは、課題ごとにメインの担当を決めて、個人の裁量で要求・要件定義を進めて方針を固めています。方針が固まったら、方法論を考えてシステムの仕様を作って設計していくのですが、そこからはチームプレイに切り替わります。
大堂：
方法論や設計を考えるところからチームプレイに切り替わるんですね。上流工程をチームではなく、個人が要件定義をする理由って何かあったりしますか？
岩井：
上流工程では「作る」という観点での話はあまり重視しないと思うんですね。一番価値のあるアウトプットをどう出すかを、他チームと考えることが重要のためあえて開発主体にしていません。そうなると開発チームである必要はなく、個人の方がパフォーマンスが出ると考え、個人の裁量に任せてます。ただ上流工程を考えた後は、チームに持ち帰ってしっかり共有する。ことを徹底しています。
大堂：
個人で考えてから、チームにしっかりと考えた内容を共有することは徹底しているんですね。その後に個人から、チームプレイに切り替わるのは、なぜですか？
岩井：
実際に作る工程になったときに、設計思想がそろっていないと可読性の低下や属人化につながるので、個人でなくチームでやろうという考えです。あとはメンバー全員が仕様や設計を理解していれば、タスクを持ち回すことが可能になるので、無駄がなく開発リソースを使えるという側面もあります。
今の開発体制のきっかけは、メンバーの言葉だった
大堂：
なるほど、バランスの取れた体制ですね。以前からこのような開発体制だったんですか？
岩井：
以前は、作るところも含めて個人に委ねる完全縦割りでした。すり合わせのコストを考えてそのようにしていたんですが、逆に設計やコーディング内容について議論する機会が少なかったり、コミュニケーションが少ない状態ではありました。
開発チームで雑談していたときに、メンバーの一人が「もっとチーム皆で開発がしたい」といった言葉がきっかけで、開発体制を見直しました。
大堂：
そんな一言から、開発体制が変わっていったのですね。そしてどのような体制に変えていったんですか？
岩井：
チームプレイで開発をどうやっていくかを考える段階で、メンバーからスクラムの案が出てきたんです。
kiizankiizanが解決したい課題を明確にしたうえで、kiizankiizanらしいスクラムを作っていきました。きっかけがメンバーからだったので、私は舵取り役で、アイディア出しや、方法を調べたり共有してもらうのはメンバーにできるだけやってもらうようにしました。これがいい感じにはまったと思います！
全員で目的に向かって改善し続けたい
大堂：
その開発チームで考えたスクラムについてもっと聞きたいです（笑）今のスクラム体制では、どういう感じで開発を進めていくのですか？
岩井：
開発サイクルの区切りであるスプリントは2週間単位で設定し、毎日朝イチにデイリースクラムで状況を共有するサイクルで運用しています。最終日には関係者に成果物を見せるスプリントレビューと、チーム運用を見直すレトロスペクティブを行い、次のスプリントで取り組むことを決めるという流れですね。
大堂：
これはどのへんがkiizankiizanらしいスクラムなんですか？
岩井：
デイリースクラムやレトロスペクティブなどのイベントはスクラム通りなんですが、専任のプロダクトオーナーを置かずに、開発メンバーがそれらを兼任しているんですね。上流を理解して目的最適に向かうために、メンバーが各々作るものの方向性を決め、サービスや運用が回るようになるところまで責任を持つのがkiizankiizanっぽさかと思います（笑）
大堂：
なるほど、開発メンバーがオーナーとプレイヤーを兼任をしているんですね！
岩井：
あとは、作りたい機能や達成したいことを「ストーリー」と呼ぶのですが、ストーリーが完了するまでのタスクを洗い出し、見積もりをしてからスプリントでどれに着手するかを決めるのがベーシックなやり方です。
ただ兼任しているとスプリント計画のタイミングで見積もりできるレベルまで整理できていないことも多いので、見積もりはざっくりでやっていたり、スプリントの途中で着手するストーリーが増減することを許容しています。
こういったことも、レトロスペクティブで各々思ってることを出し合って、じゃあ次こうしようというのを相談してやってますね。その改善サイクルを大事にしてまして、本来のスクラムを僕らのやりやすいように崩していってる、って感じですね。
大堂：
なるほど、レトロスペクティブで意見を出し合ってみんなで作り上げていくのはいいですね！ここまで来たら最後までお伺いします。そして機能リリースまではどう進めていくかも教えてください。
岩井：
課題ごとにメインの担当を決めて、要求・要件を整理してストーリーを起こします。その後はチームプレイに切り替わり、まずはメンバーへのストーリーを共有します。そのあとに方法論を決め、設計に落とし込んでいきます。
その際のワイヤーや設計の草案は開発メンバーの誰かが作って、開発チームの全員に見てもらいます。そこで意見を出し合って、ブラッシュアップしたらタスクとして設定をします。
タスクは誰が取ってもいいので、手が空いたら各々の判断で実装していき、誰かにコードレビューをしてもらって完了し、定期的にリリースするという流れでやっています。
大堂：
実際にスクラムを取り入れてからどう変わりましたか？何か開発チームのパフォーマンスの変化を感じますか？
岩井：
今は外部設計・内部設計段階で開発メンバーに公開し、意見を出し会える場を設けているのですが、そこで大体、頭が一致するのでコードレビュー段階でのちゃぶ台返しは、かなり減りましたね（笑）
以前の完全縦割りの個人プレーからスクラムを取り入れたチームプレイになって、相談しやすい環境になってきて、kiizankiizanのバリューにある「始めるまえに相談する」は体現できて、作る前にみんなで話し合う機会が増えて、設計・開発のパフォーマンスは上がったなという実感があります。
大堂：
では最後に開発チームで、今後チャレンジしたいことはありますか？
岩井：
今後もkiizankiizanらしい目的最適な開発体制で、チームプレイが円滑に進むようにしていきたいです。他の方法を混ぜ合わせて新しい方法を生み出してもOKです。開発メンバーといろんな方法を検証して、全員で目的に向かって改善し続けるチームでありたいです。
大堂：
今後も良い開発体制を期待しています！お時間をいただいて、ありがとうございました。
岩井：
ありがとうございました！
━━━━━━━━━━━━━━━━━━━━━━━━━
kiizankiizanでは,一緒に働くメンバーを募集しています！
詳しいKiizanKiizanの情報は、下記採用ページにまとめております。
ご興味のある方は、ご確認ください。
kiizankiinzan採用ページ
コメント
コメントを投稿