プロジェクトオーナーを苦しめたのは、ガチガチ要件定義 チームで最善を選べるようになるための3つのポイント

自己紹介

榎本命氏（以下、榎本）：よろしくお願いします。Classi株式会社の榎本命と言います。下の名前が命と書いて「みこと」と読むということで、よく「神社の出身ですか？」みたいに言われますが、普通の家庭になります。

今日は「ガチガチ要件定義」をやめるまでの奮闘記ということでお話しします。最初に簡単に自己紹介を挟み、あとから内容に入っていきたいと思います。私は榎本命です。教育大好き、学校大好きみたいなところでずっと生きてきて、大学院も教育系を出ています。

そのままベネッセコーポレーションに入り、「じゃあ出向してください」ということで、Classi株式会社に出向しています。ディレクション部というところに所属していて、今はプロダクトオーナーという役割を担っています。

ディズニーや漫画、料理が好きです。（スライドを指して）左は、フロリダのウォルトディズニーワールドに行った時の写真になっています。みなさん、ぜひ人生で1回ぐらいは行ってみてください。

セッションのテーマとClassi株式会社について

今日私がお話ししようと思っているのが、PO（Project Owner）としてスクラムの一歩目で出会った要件定義のプロセスについての課題と、解決のための工夫と学びについて語れればと思っています。

ウォーターフォールでふだんやっている方には、もしかしたらあんまりぴんと来ない話かもしれませんが、今後スクラムでやっていきたい、あるいは今スクラムで始めて一歩目の方には、もしかしたら参考になるかなと思っているので、よろしくお願いします。

Classiというものをご存じない方も多いかなと思うので、簡単に説明しますが、株式会社ベネッセコーポレーションとソフトバンク株式会社が作った会社になっています。2014年に設立なので、もうなんだかんだ7、8年ぐらいになります。

顧客、営業先としては学校になります。ユーザーとしては、先生や生徒、保護者になっていて、いわゆるBtoBtoCみたいなフレームでやっています。アプリケーションも「Classi」という名前でやっていて、SaaSとして提供しています。

（スライドを指して）導入実績でいうとこんな感じで、右側のほうで言うと、全国の高校の中で、Classiのシェアはだいたい2人に1人ぐらいは使ってもらえているぐらいな規模感になってきました。

電車とかに乗ると、高校生が「Classiやった？」という会話がだんだん聞こえてくるとか。そういうふうにだんだん変わってきているなと思っています。

今、大きな転換期を迎えている学校

学校という場は、今まではウォーターフォールがすごく向いていました。私たちもそれでやってきました。なぜかというと、基本的に年度で契約しているし、学校という特性上、頻繁に機能があまりに変わってしまうと困るところもあって、リリース機会は少なく、比較的大きいリリースをするようなかたちでやっているし、要件定義もかっちり決めて進めるというところはやっていました。

ただ、今ちょうどGIGAスクールという、いわゆる学校の中にタブレットやネットワークを配置していくというところだったり、あるいは入試が変わるみたいなところで、大きな転換期を迎えています。

本当に過渡期、メチャメチャ変わっている最中で、今月学校に行って、翌月に学校に行くと言っていることが変わっているようなこともあるぐらい、最近は本当に環境がすごくよく変わっているなと思っています。またそれに伴って、顧客ニーズや市場も日々変わっていくなと思っています。

ということを踏まえ、我々もアジャイル・スクラムをやっていこうというところで、社内のいくつかのチームがスタートをして、チャレンジをし始めています。

先ほども言ったとおりユーザーが学校なので、きっちり要件決めてきっちり開発することはもちろん、小さく早く出すというところを意識したり、ユーザーと一緒にものづくりをするところを、より意識をしながらみんなで進め始めています。

私もそれに乗っかるようなかたちで、プロダクトぐらいの大きさの1つの機能を思いっきり作り直す、リニューアルするということで、そのリニューアルのプロジェクトのPOとして、私も要件定義をやることに踏み出しています。

最初はいわゆるペルソナ作ったり、ユーザーストーリーマッピング作ったり、プロダクトバックログみたいなものを作りながら、要件定義を始めています。

アジャイル・スクラムを始めたことでPOに起きたこと

このあたりを始めたことで、PMのみなさんはわかるような気もすると思いますが、開発を始めてスクラムを体験できて、チームみんなで取り組み始められて、「改善をやっていこうぜ」という土壌ができてきたことはよかったです。

でも、POとしていろいろなことをやり始めたら、周りからすごくいろいろなことを言われて、「常に焦ってますよね」とか。これは実際にエンジニアやデザイナーに言われたんですが、「忙しそうですよね」とすごく言われて。

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

もう少し具体的にみなさんにもイメージしてほしいんですが、どんな会話があったかというと、私が始めた時はこんな感じでした。

「要件細かく考えました！　よっしゃこれで行きましょう、よろしくお願いします」と言ってみんなに渡すと、「ああ、なるほど。なんかだいたいわかりました。でもこの部分ってどうなるんですかね？」みたいな話が始まって、「ああ、確かに」「なるほど」と言って受け取って、「もう1回持って帰って考えてくるわ」と言って。

「よし、詰めたぞ。よろしくな」と言ってもう1回渡すと、「ああ、わかりました、そこはわかりました。じゃあこの部分はどうしますか？」みたいな話がまた返ってきて。

どんどんそのラリーが続いて、私は少しずつ、つらくなっていきました。

もちろん、「POとしてやっていくぞ」という気持ちはあったので、「ちゃんと決めなきゃな」と思っている一方で、「でもチームでやっているんだから、みんなで考えてほしいな」と思っている側面も正直ありました。

一方、開発者側に話を聞くと、「いやいや、もっとこうしたほうがいいって思った部分はあったんだけれど、POが一生懸命にがんばって考えてくれているから、何か決まっているのかなと思っていました」という話がありました。

要件を決めすぎて、答え合わせになっていた

もうちょっと深掘りすると、では私が何をしてしまっていたかという、失敗談です。端的に言うと、要件をあまりにも決めすぎていたというところになります。

（スライドを指して）左側は実際に私が作った要件というか、1つの機能を作るにあたっての、私が決めたことです。すごくガチガチに決めているんですよね。アップロードの機能を作りたいだけなのに、容量がいくつとか、ものすごく細かくすべてを指定している。正直、「もうお前がデザイン周り作れよ」みたいなぐらいに細かく作ってしまっていたというところです。

頭ではわかっていたものの、もともとのウォーターフォールでやる要件定義の癖が抜けなかったんだなと、今は振り返っています。

（スライドを指して）下にあるように、開発者が提案する余地がないと書いていますが、さっきもあったように、「POがメチャクチャ考えてきてくれている、もう考えているだろうから、なんか意見言いづらい」とか、「もっといい方法ありそうだけどなんか提案するの悪いな」という感情を、エンジニアなどが持っていました。

答え合わせになってしまうというのが近しいような話で、エンジニアたちからすると、「こうでいいですか？」という聞き方をせざるを得ない。POがあまりにも考えていたせいで、答え合わせをするような会話になってしまったというのがありました。

（スライドを指して）根本的な原因は、こんな感じです。私自身、スクラムに対しての知識とか経験、プロダクトを開発することについてもまだまだ勉強中というところもあるし、知識・経験もない中で、責任感だけでやたらがんばっていたみたいなところがあって。全部自分でやろうとしていたというところでした。

投げる時に意識した3つのポイント

「じゃあ、どうしようかな？」ということで壁に当たった時に、私が思ったことはこうでした。「もう、ぶん投げちゃおう」と。やったこととしては、ぶん投げたというところです。

とはいえ「もう全部よろしくな」みたいな感じではもちろんいけなくて、大事なのは、やはりぶん投げ方なのかなと私は思っています。みんなが受け取りやすいようなかたちで、でも受け取り方も工夫できるようなかたちで渡してあげるというのが、私が本当にすべき要件定義だったのかなと今となっては思っています。

その時の工夫の仕方として、大きく3つのポイントを書いています。1つは、役割を変えた。明示したと言ったほうが近いですかね。私がやることをもっと明確に言ったという感じです。ユーザーの望みは私が全部知っているし、これからもどんどん探索して、一番知っていく。

「課題とかやりたいことは私が一番知っているから、そこは任せろ」と言って。「その代わり、どう実現するかは全部任せるのでよろしくな」と言い続けています。今も言い続けています。

ただ、もちろん言葉だけ言っても実現できるわけではないので、あと2つ、行動としても変えていきました。意識を変えるって書いていますが、「How」のところについて考える会みたいなものはあえて出席をしなかったり、流れで始まった会話だったりしても、あえて私は何も言わないことを意識的にして。

そうすると相手側も、「ああ、何も言わないんだな」ということで、だんだん「自分たちで考えなきゃね」と変わってきているのかなと思っています。

そうは言っても、エンジニアたちにも私に何かを聞かざるを得ないシーンはもちろんあります。そういった時も、私は「じゃあ、あなたはどう思いますか？」とあえて聞き返したりとか、「一番おすすめはありますか？」「今いいと思っている仮説はありますか？」みたいに聞くことによって、お互いが選択権を持つように変えてきています。

余白が生まれて提案がしやすい環境に

（スライドを指して）結果、こんな感じです。先ほどのバッと並べたところに対して、すごくシンプルになっています。余白が生まれて、要件をもっと詰めていくという段階で、みんながもっと提案しやすいかたちになってきていると思っています。

実際、開発の過程の中でも、「こういう実現方法が実はあったね」「もっといい方法があるんじゃないですか」という提案も出てくるようになってきたと思っています。

結果、私としての一番の成果は、POの負荷です。すごくつらかったところから、少し負荷が下がったのはすごくうれしかったです。

その分、チームの不安だったり、勝手に決めて勝手に作らされるということではなくて、自分たちで考えながら作れるということで、チームの不安も減ってきました。（スライドを指して）やはり大切なのは右側ですね。対話量も増えてきて、一人ひとりの頭の中にあるアイデアだけでなく、みんなで考えられるようになって、アイデアの質やスピードも上がってきた。

なにより一番は、楽しさです。言われたことをやるだけじゃなく、自分たちで工夫しながらやれる楽しさが上がってきたのが、一番よかったかなと私も含めて思っています。

みんなで考えることで天井の押し上げができる

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

チーム全員がよりよい要件を提案できて、最善のものを選べることかなと思っています。私自身、自分のスキルだったり、知識みたいなところが要件の天井だったところから、みんなで考えていくことによって、その天井を押し上げることができたのは、すごくよかったなと思うし、今後も続けたいなと思っています。

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

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

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