エンジニアのみなさんにとって、技術やマシン、環境と同じくらい気になるのが、開発手法ではないでしょうか。Libryには開発チームが複数あり、その中のBeakerチームでルーブリック評価支援機能開発を行う中で新しく取り入れたWIP制限、チーム制、ペアプロ・モブプロの紹介していきます。

ミッション・インポッシブル！？4月リリースに間に合わせよ！

弊社が開発・提供をしている、中高生向けデジタル教材プラットフォーム「Libry」は、（今、この瞬間にも）進化をし続けています。改善したり、追加したい機能が多く、常に複数の開発項目が進んでいる状態。そんなときに新たな開発項目に加わったのが、ルーブリック評価支援機能（※）の開発です。

※ルーブリック評価とは？

「1＋1＝2」のように正解がある（定量的な評価ができる）問題ではなく、「食糧問題を解決するには？」など、答えが複数ある課題で必要な定性的評価の観点を可視化したもの。2022年4月から高校でもこの評価方法が導入される。

しかも、2022年4月の高校の学習指導要領（学校の教育課程を編成する際の基準）改訂までにリリースをしなくてはならないという、かなりタイトなリミットつきです。

前述したとおり、複数の開発項目を進めている状態では、とても4月には間に合いません。そこで、プロダクトオーナーの長谷川が考えたのが、WIP制限をしてルーブリック評価支援機能の開発だけにすべてのリソースを投入すること。ほかの開発をすべて止めてしまうという不安はあったものの、「マルチタスクは開発が進んでいるように見えるだけで、実際はシングルタスクのほうが進みが早い」と考え、試してみることにしたそうです。

結果は…大成功！WIP制限を導入したことで、

• チーム内で知識の共有やタスクの相談をするなど属人化の排除。
• チームワークによるミスの軽減。
• プロダクトオーナーの多岐にわたるタスクをスクラムマスターやメンバーと共有できる。

という成果にも繋がりました。

小さく＆早く回す体制で、スピードアップとクオリティアップの両方を実現！

ルーブリック評価支援機能における開発で新しく取り入れたのは、WIP制限だけではありません。これまで8人のチームで1つの機能を開発していましたが、単位が大きすぎるのでは？と考えたスクラムマスターの佐藤は、ルーブリック評価支援機能をさらに細かくわけて、3人1チームで開発をする「ミニチーム制」を構築。それぞれのミニチームには、プロジェクトマネジメントの役割をする人も配置します。

そこで、これまでプロダクトオーナーとスクラムマスターでやっていた仕様設計を、ミニチーム内で検討することに。

その結果、

• プロダクトオーナーはユーザー視点をUI/UXに落とし込む、スクラムマスターはチーム全体の環境設計を行うという、本来の役割に注力できるようになる。
• エンジニアが当事者意識を持つようになり、積極的に提案する雰囲気ができる。

といった、想定以上のすばらしい効果が生まれました。

さらに、プロダクトオーナーの長谷川とスクラムマスターの佐藤のチャレンジに触発されたエンジニアからも、すばらしいアイデアが出てきます。ここではエンジニアの小松の話をまとめてみました。

ひとつは、開発の進め方を見直すこと。全体の画面設計をしっかり行ってから開発する方法だと、時間がかかってしまう上に、仕様変更などをすると手戻りが多く発生してしまいます。そこで、画面単位で設計→実装→テストを繰り返す手法に変更。

• エンジニアの待機時間が減る
• 効率的に実装が進む
• 課題の早期発見
• 短い期間で動くものが見られる＝モチベーションが上がる

など、開発の側面だけでなく、エンジニアにとっても大きなメリットにつながったようです。

もうひとつは、ペアプロ・モブプロの導入です。2人以上で1つの機能の開発を進めることで、知識の共有や相互チェックができ、ミスの防止につながりました。また、コミュニケーションが自然と生まれるので、寂しくなくなったという声も多かったそうです。（1人で開発を進めるのは、実際にやってみるとかなり孤独を感じてしまうんです…）

正解はひとつじゃない

ルーブリック評価支援機能を4月までにリリースするという、いわば、ピンチをチャンスに変えたことで生まれた開発フロー。全体的にかなり上手くいったように思えるのですが、実際のところ、どうだったのでしょうか？最後にそれぞれの立場からコメントをいただきました。

プロダクトオーナー・長谷川

今までプロダクトオーナーといいながら、メインの仕事がプロジェクトマネージャーになっていました。ただ今回WIP制限とミニチーム制を導入することで、本来のプロダクトや機能を考えることに時間を割くことができるようになりました。今回の開発を通じて、ミニチームからプロダクトオーナーやスクラムマスターへの共有方法や社内での調整業務の進め方等の課題が見えてきたので、今後は改善しながら更に開発体制が良くなればと考えています。

スクラムマスター・佐藤

当初の開発体制は、各ストーリー開発タスクに対して一人だけで挑む、いわば「個人商店」化している問題点がありました。この点においては、ドメイン知識含め、すでに理解している背景があれば機能しますが、新たにジョインした新メンバーの観点から見ると、一人で理解しながら開発するのは、大きなコストであると感じました。

「個人商店」化する傾向を脱却するために複数人で取り掛かる本来のチーム体制に変更し、その中でもミニチーム運用、ペアプロ・モブプロなどを取り入れた結果、開発体制の改善に繋がったと感じます。上記の改善の結果、「チームの雰囲気作り」や「無駄な会議時間の削減」を意識の醸成が促進出来たことで、相乗効果があったとも感じております。

スクラムイベントの時間を短縮し、より明確な議論を中心にしたり、なにより、メンバーが”遠慮”なく、”時には言い合い”、”楽しむ”。結局は「楽しい」を生み出すことに意義があるのかもしれません。

エンジニア・小松

開発が上手く進んだ要因はチームの動きが良かったところにあったと思います。ルーブリック評価支援機能のような大きな機能の開発は、チームとしても初めてであり挑戦でした。「開発の進め方を見直す」といった言葉があったと思うのですが、文字通り開発がはじまった初期は進め方を含め課題だらけで、このまま開発をしっかり完了させられるのか？と正直不安もありました。

ただ、そういった課題を放っておくことなくしっかり議論し、改善を進めていく文化がチーム内にはあったため、開発が進むにつれて強いチームになっていくのを感じました。ペアプロ・モブプロも初めからあったわけではありません。「この機能は2人で画面共有しながら進めた方が上手く進められるのでは？」といった仮説から、「まずはやってみよう」とトライ、その結果、上手く開発が進んだため、開発の進め方の一手段として取り入れることになりました。この「やってみよう」のハードルがとにかく低かったのが良かったと思います。

このように、課題に対してプロダクトオーナー、スクラムマスター、エンジニアが知恵を出し合って対策を立て、気軽にトライできるチームだったからこそ上手くいったのではないかと思っています。ルーブリック評価支援機能の開発で得た、経験やナレッジは今後の開発でも活かしていきたいと考えております。

Libryでの新しい取り組みが、少しでもみなさんのお役に立てれば嬉しいです。また現在お待たせしている機能についてもご利用頂けるように鋭意進めてまいります。

また、もっとくわしく話を聞いてみたい！　一緒に開発をしてみたい！　と思った方は、ぜひお気軽に「話を聞きに行く」ボタンからご連絡ください。