2022.01.19
教育系SaaSプロダクトのリニューアルに新人POが初挑戦! 空回りで学んだ、良い要件定義プロセス

教育系SaaSプロダクトのリニューアルに新人POが初挑戦! 空回りで学んだ、良い要件定義プロセス

高校生の2人に1人が使う教育系SaaSプロダクトを運営するClassi。その機能リニューアルに挑んだのは、初めてPOとしてスクラム開発に取り組む榎本命さん。「責任感だけじゃ上手く行かない」そんな気づきから得た良い要件定義のプロセスを解説。ポイントは「ぶん投げ」だった…!?

0 0 2 2

※2021年12月14日に開催された【開発PM勉強会】より、 Classi株式会社、榎本命さんによる「ガチガチ要件定義をやめるまでの奮闘記」セッションを書き起こし形式でお届けします。※記事内では「PO=プロダクトオーナー、PM=プロダクトマネージャー」として表記しています。

>>>[関連記事]「PM」に関する記事一覧はこちら

自己紹介|テクノロジーで学校教育を支援したい

はじめまして、Classi株式会社*の榎本命と申します。下の名前が命と書いて「みこと」と読むので、よく神社の出身ですか?って聞かれますけど普通の家庭出身です(笑)


*Classi株式会社
2014年、株式会社ベネッセホールディングスとソフトバンク株式会社の合弁会社として設立。学校ICT化を多目的にサポートする教育プラットフォーム「Classi」などを運営している。


今日は「ガチガチ要件定義をやめるまでの奮闘記」ということでお話をさせていただきます。

はじめに簡単に自己紹介をさせてください。私は「教育大好き」「学校大好き」という人間で、大学院まで教育を専門で学んでいました。

その後、株式会社ベネッセコーポレーションに入り、すぐにClassi株式会社へと出向しました。

現在はディレクション部に所属しており、チームではプロダクトオーナー(PO)という役割もやっています。ディズニーや漫画・料理が好きで、写真はフロリダのウォルトディズニーワールドに行った時のものになっています。皆さん、ぜひ人生で一回は行ってみてください。

+++

POとしてスクラム開発に初挑戦

本日私がお話するのはこちらです。

+++

もしかすると普段ウォーターフォールで進めているという方には、あまりピンとこない話かもしれません。

たとえば、

・今後スクラムでやっていきたい方
・スクラムを始めたばかりの方

に参考になるかと思います。

Classiをご存じない方も多いと思いますので、ご説明させていただきます。

2014年に株式会社ベネッセコーポレーションとソフトバンク株式会社が作った会社です。

+++

導入の意思決定:学校
ユーザー:先生、生徒、保護者

となっており、いわゆるBtoBtoCのフレームになっています。

アプリケーションもClassiという名前でやっており、SaaSとしてご提供させていただいております。

今の導入実績が以下の図になります。

+++

右側のグラフを見ていただくと分かると思うのですが、Classiは全国の高校で大体2人に1人は使ってるという規模感になってきています。電車に乗ると、「Classiやった?」という会話が聞こえてくることもあります。

そんな学校という場は、今までウォーターフォールがすごく向いていました。

学校という特性上、頻繁に機能が変わってしまうと困るからです。

▼これまで
・リリース機会 少ない
・リリース規模 大きい
・要件定義 かっちり

それが現在、

・学校へのタブレットやネットワークの整備
・入試の改変

などの大きな転換期を迎えています。

本当に目まぐるしく変わっている最中で、学校にお伺いする度に事情や環境が変わることもある程の過渡期となっています。それに伴って、顧客ニーズや市場も日々変化しています。

+++

こういった変化を踏まえ、我々もアジャイルスクラムをやっていこうとなり、社内のいくつかのチームでチャレンジをし始めています。学校なのできっちり要件を決めてきっちり開発するのはもちろんですが、

▼これから
・小さく早く出すこと
・ユーザーと一緒にものづくりをする

ということをより意識してみんなで進め始めています。

+++

ちょうどその時に、あるプロダクトをリニューアルする話がありました。

そこで私も乗っかる形でこのプロジェクトのプロダクトオーナーとして、要件定義をやろうと一歩踏み出しました。

「気合」がいつしか「辛い」に変わってしまった

最初はプロダクトゴールの設定や、ペルソナの作成、ユーザーマッピングの作成から始め、プロダクトバックログアイテムを作りながら要件定義を進めていきました。

PMの皆さんはわかるかもしれませんが、POとしていろんなことを進め始めると周りから様々なことを言われるようになりました。

中でも、チームのメンバーに「常に焦ってますよね」や「なんか忙しそうですよね」と言われたことは、自分でもショックでした。

私自身も本当にこれで良いのか不安で責められている気持ちになってしまい、だんだん元気がなくなっていきました。「よしやるぜ」って気合を入れて始めたのに、元気が無くなっているということが起きていました。

+++

具体的にはこのような会話がありました。

+++

会話のラリーが続いていくうちに、私はだんだん辛くなっていってしまいました。

もちろんPOとしてちゃんと決めなきゃなと思っている一方で、

「チームでやってるんだからみんなももっと考えてほしいなあ」

と思っている側面も、正直ありました。

「全部自分でやらなきゃ…」頑張りすぎるから意見をもらえない

一方で、開発者側に話を聞くと、

「もっとこうした方が良いって思った部分もあったんだけど、POが一生懸命考えてくれているから既になんとなく決まってるのかなと思っていた」

と返ってきました。

この失敗談を深掘りして端的に言うと、

要件をあまりに決めすぎていた

ということになります。この左側が実際私が作った要件です。

+++

1つの機能を作るにあたって私が決めていたことなんですけど、ガチガチに決めてるんですよね。アップロードの機能を作りたいというだけなのに、容量がいくつでとか物凄く細かくすべてを指定しています。

正直、開発者に「お前がもうデザインまで作れよ」と言われてもおかしくないほど細かく作ってしまっていました。頭では分かっていたものの、元々のウォーターフォールでやる要件定義の癖が抜けなかったんだなと今となっては思います。

開発者からすると、

「POがめちゃくちゃ考えてきてくれてるから意見が言いづらい」
「もっといい方法ありそうだけどなんか提案するのも悪いな」

という感情を持つのは当然だったかなと思います。

その結果、「こうでいいですか?」という答え合わせをするような会話になってしまっていました。

私自身スクラムに対しての知識や経験も無い中で、責任感だけで頑張っていました。それなのに全部自分でやろうとしていたというのが、根本的な原因だったと思います。

+++

自分じゃ背負いきれないから一旦ぶん投げてみる。

じゃあどうしようかなと壁に当たった私は、「もうぶん投げちゃおう」と思いました。

+++

とはいえ「全部よろしくな」みたいなぶん投げ方はもちろんいけなくて、大事なのはぶん投げ方です。

受け取りやすい+受け取り方も工夫できる

といったようにして「ぶん投げること」を意識しました。

これこそが私が本当にすべき要件定義だったのかな、と今となっては思っています。その時の工夫として、大きく3つのポイントを意識しました。

+++

1つは役割を変えたということです。明示した、という方が近しいかもしれません。明確に自分がやることを提示しました。

「ユーザーの希望は俺が全部知ってるし、これからもどんどん探索して1番知っていく。課題ややっていきたいことは1番俺が知ってるからそこは任せろ。その代わりどう実現するかは全部任せるからよろしくな」

ということを言い続けました。今も言い続けています。

もちろん言葉だけで実現できるわけではないので、行動としても2つ変えたポイントがあります。
意識を変えたと書いていますが、要件のHowの部分について考える会議にはあえて出席をしないようにしました。出席している会議でHowを話す会話が始まった場合には、あえて私は何も言わないことを意識的にやっていました。

すると相手側も「なにも言わないんだな」と思い、だんだん「自分たちで考えなきゃね」という風に変わってきました。

3つ目のポイントは話し方を変えたことです。

エンジニアやデザイナーが私に何かを尋ねてきた時

「あなたはどう思いますか?」
「1番おすすめはありますか?」
「今良いと思っている仮説はありますか?」

と聞き返すことで、選択権を持ってもらうように変えました。

結果、このように変化しました。

+++

先ほどの要件と比べてとてもシンプルですよね。余白が生まれて要件をもっと詰めていくという段階で、みんなが提案しやすい形になってきているなと思ってます。

実際、開発の過程の中で、

「こういう実現方法もあったね」
「もっといい方法があるんじゃないですか?」

という提案もでてくるようになってきました。

天井を押し上げるのは良い要件定義のプロセス

+++

大きな成果としては、

POの負荷が軽減したこと

です。

辛かったところから、少し負荷が下がることでことで、POがやるべき大事なタスクに時間をかけられるようになりました。また、自分たちで考えながら作れるということで、チームの不安が減ったこともよかったです。

ただ、やっぱり嬉しかったのは右側です。メンバー同士の対話量が増えたことで、

・1人1人の頭の中にあるアイデアが出るように
・みんなで考えるアイデアの質やスピードの向上

このような変化がありました。

そして何より1番は楽しさです。

「言われたことをやるだけじゃなくて、自分たちで工夫しながらやれるという楽しさ」

が上がったのが1番良かったと思っています。

今回のテーマに戻りますが、私は良い要件定義そのものについてはまだ明言できません。しかし、良い要件定義のプロセスはこうじゃないかなと思っています。

+++

▼1人で頑張っていた時
自分のスキルや知識が要件の天井になってしまった。

▼みんなで考えた時
1人の時よりも天井を押し上げることが出来た。

これがすごく良かったなと思っていますし、今後も続けたいなと思います。

先生、生徒を巻き込みつつ、より高速で質の高い開発を

+++

今後の話になりますが、先生や生徒を実際にレビュワーに巻き込みながらより高速で質の高い開発をやっていきたいと考えています。

最後に少し告知です。今後Classiは2030年を見据えて、もっともっと学びを進化させるというところにチャレンジをしています。学校を超えて授業を支援することや先生と一緒に物を作る事を考えています。また、高校だけではなくて小学校、中学校、あるいは国外にも広げていきたいなと考えております。

教育だったり学校をより良くしたいなという方がいましたら、ぜひ一緒にやれればと思ってますので何かあればお声掛けください。以上です。ありがとうございました!


編集 = CAREER HACK


PM
0 0 2 2

関連記事

特集記事

お問い合わせ
取材のご依頼やサイトに関する
お問い合わせはこちらから