デザイナー2人が新卒研修でスクラム開発をやってみて、学んだこと

こんにちは、新卒デザイナーの小板です。今回は、新卒デザイナーが新卒研修であるパイロットプロジェクトのなかでスクラム開発をしてみて、わかったこと・学んだことを紹介します。

新卒研修でのスクラム開発

まず、また新卒研修でスクラム開発をする意図と、「なぜ2人でスクラム開発に取り組んだのか?」についてお話しします。

研修の意図

このパイロットプロジェクトは、OJTに入る前に、実際のプロジェクトの流れを体験することが目的でした。実際にどのようなプロダクトを開発するか決め、マークアップ作業までに1ヶ月で取り組むことを通して、スクラム開発を知り、プロジェクトの中ではどのようなことを考えていかなければならないかを体験しました。

2人でスクラム開発をすることについて

前提として、本来スクラム開発は5〜9人で行うのが適切とされています。しかし、今回のパイロットプロジェクトでは、新卒デザイナーである我々2人のみでスクラム開発を進めていくことになります。これは、単純に新卒デザイナーが2人しかいないことや、先輩方は実際の業務が忙しいため参加できないなどの理由があります。しかし、このパイロットプロジェクトでは実際のプロジェクト進行に取り組むという意図があるため、2人でスクラムに取り組むこととなりました。 なお、プロダクトオーナーの役割とスクラムマスターの役割は、それぞれ別の先輩が担当してくれました。

使ってみたツール

さて、今回のパイロットプロジェクトでは、実務ではあまり使用されていないけれど、もしかしたら使えるかもしれないツールをいくつか使ってみました。これらの良かった点・悪かった点を紹介します。

AdobeXD

弊社のデザイナーは、2019年8月現在主にSketchを使用してデザイン制作を行っています。今回は、デザイナーが2人参加するということで、それぞれが作ったデザインを1つにまとめる作業が予想されました。その際、どのようにすべきか?を検討した結果、後ほどデザインを本制作する際に使えるかどうかを試すために、それぞれが制作したワイヤーフレームを統合するタイミングで、共同編集機能のあるAdobeXDを使ってみることにしました。

結果は、共同編集機能は何度かコンフリクトを起こし、その都度作業が止まってしまうという問題が発生しました。コンフリクトを起こさないようにお互いに確認を取りながら作業をしなければならなかったり、そもそも1つのファイルを共同で同時に編集すること自体にメリットをあまり感じられなかったため、使用は中止しました。

デザインの本制作では、それぞれが単独のSketchファイルを編集し、プロトタイプ制作の際にProttで統合するという形になりました。

GitHub Project

今回のパイロットプロジェクトでは、ホワイトボードなどの物理カンバンが用意できなかったこともあり、GitHub Projectをカンバンとして使用していました。 GitHub Projectを選んだ理由としては、弊社ではデザインレビューなどもissue上で行なっているため、それらを紐づけることのできるGitHub Projectがカンバンとして有用かどうかを試してみる、という意図がありました。

GitHub Projectの良かった点としては、やはりissueと紐づけられるのが、わかりやすかったです。うまく活用すれば、プロジェクトのタスク単位でプルリクを作るなどして、カンバンと実際の作業を紐づけることによって、全体の把握が容易になりそうだな、などと思いました。

一方、物理ではないカンバンを用いることで、お互いがどこにいてもカンバンを確認できるようにはなりましたが、逆に「見に行かなければカンバンが見えない」という状況になってしまいました。常に見える位置に置いておける物理カンバンでは、意識をしていなくても目に入ってくることによって、意識していなかったタスクの進捗に目が向いたり、着手していなかったタスクに気付いたりなどがあるかもしれません。しかし物理ではないカンバンを用いることによって、「カンバンを気にしなくなり、現状把握が後手に回る」可能性がより高まるのではないか、と感じました。

デザイナーとスクラム開発

それでは、ここからはデザイナーとしてスクラム開発を行い、どんな問題が発生したか、そしてそれにどう対処すべきだったかについて、パイロットプロジェクトを通してわかったことを紹介していきます。

デザインレビューの工数見積もり

今回のプロジェクトで最も大きな失敗は、デザインレビューの工数見積もりを見誤った点でした。

現在、弊社のUXデザイン部では主にGitHubのIssue上でデザインレビューを行なっています。この方法では、どんなやり取りをしたかが残ること色々な情報がGitHub上に集約されることなどのメリットがあります。 しかし一方で、自分たちのデザインの意図をテキストで説明したり、どんなデザインかがわかる画像やプロトタイプを用意するという作業に時間がかかってしまいます。

また、レビューは全てIssueへのコメントという形で各デザイナーより投稿されます。これによって、レビュー内容は各人ごとにまとまってしまい、それぞれの意見をまとめ、デザインのどこをどう直していくべきか?を検討する作業が大変になります。

さらに、各デザイナーは手が空いたタイミングなどでそれぞれIssueにコメントをするため、デザインレビューを投稿した後は「待ちの時間」が発生します。時には、全員からのフィードバックを受け取るまでにかなり長い時間を要するケースもあります。

今回は、かなりタイトなスケジュールでプロジェクトを進めていたため、即時にフィードバックをもらえるように、直接デザイナーの皆さんを招集して初回レビューをしてもらいました。それによって最初の「待ち」は省略することができたのですが、その後の修正→フィードバックの繰り返しはIssue上で行うこととしました。しかし、この判断は誤りで、これによってデザインが確定するまでに長い時間がかかることになってしまいました。

結果として、デザインレビューの工数は、見積もりよりも大幅に大きくなってしまい、デザインレビューを行なった週は1つの工程も完了できないという事態になりました。

今後の対処法としては、スケジュールと合わせてデザインレビューのやり方を工夫していく(対面でのレビューにしてもらう、誰か特定の人に見てもらうなどで時間を短縮する)ことが考えられます。また、工数見積もりの際は、ただ「デザインレビュー」という作業ではなく、さらに細分化して見積もっていくことで精度が上がるとも考えられます。

スケジュールに合わせて、品質が担保できるボリュームを検討する

今回のプロジェクトでは、1ヶ月以内にマークアップまで、という期限が決められていました。その中で、プロジェクトを進めていくうちに「このままでは、作ろうとしているものは完成しない」という問題が発生しました。

問題が起きた原因としては、適切なスクラム開発ができていなかったことが考えられます。本来は、プロジェクトを進めながら、プロダクトバックログは常に整理されます。しかし、このプロジェクトの進行中は、あまり整理せず「これなら大丈夫だろう」と進めてきてしまい、途中で間に合わないことに気づく、ということが起きてしまいました。

この際の対処としては、プロジェクトの目的を再確認し、その目的を達成できる最低限の項目を整理することを行いました。これにより、残り工数は削減され、期間内に完成する、というボリュームへ落とし込むことができました。

プロジェクトが始まり、どんなものを作るか?を検討する中で、「これを入れたら、もっと良いユーザー体験が生まれるだろう」などと、機能がどんどん提案されます。しかし、重要なのはそれらのアイデアが出きった後に、このプロジェクトではどんな目的があったか?ユーザーにはどんな価値を提供するのか?を再確認し、そこに合わせて断捨離をしていくことだと思いました。

もちろん、全く機能の削減などを行わなかったわけではありません。むしろ、「この範囲なら作れるだろう」という読みの元作業を進めていました。しかしながら、最低限は詰めきれていなかったかな、と思います。

またさらに、このような問題が起こってしまったそもそもの原因として、パイロットプロジェクトを自分たちだけで進めてしまった、ということも挙げられます。 例えばランチや、何気ない雑談などでも、自分たちの現状を先輩にお話しすることによって、より早期に問題に気づけたのではないか、と考えています。

これは今回のプロジェクトのバーンダウンチャートです。途中で工数見直しが発生したタイミングで大幅に残り工数が減っています。しかし、18日以降はデザインレビューに時間がかかり、残り工数が減らなくなってしまいました。

これからの課題

では、パイロットプロジェクトを終えて、これから私が取り組んでいくべき課題についてです。

デザインレビュー

デザインレビューに時間がかかってしまう課題は、実際の案件でも起こり得る課題です。レビュー待ちの間に他の作業を進められれば問題ありませんが、デザインが確定しなければどれだけ実装を進めてもプロジェクトが進んだと言えない、という場面もあるかもしれません。先輩方は、「レビューしてほしい点を明確にする」「レビューする内容によっては特定のデザイナーだけに見てもらう」などの工夫を行なっているようです。また、UXデザイン部としても、デザインレビューをもっと効率化できないか?という問題提起がされており、MTGなどで現状把握から進めている最中です。

一方で、ツールや形式だけでなく、レビューしやすい文章を書いたり、レビュアーがわかりやすい図を用意するなど、個人としてできる取り組みがあると考えています。まずはデザインレビューに慣れるために、デザイン業務に取り組んでいくことだけでなく、先輩方のレビューを観察するということをしていきます。

プロジェクトの外の人を頼る

自分のプロジェクトで問題が起きている時、あるいは何も起きていなくても、プロジェクトに関わっていない人とお話しすることが重要だと感じました。

これにより、まず自分たちでは気づいていなかった問題や、その対処法などが得られる可能性があるからです。さらに、誰かに自分の状況を伝えることで、自分の状況を整理するきっかけにもなります。逆に、誰かのプロジェクトの話を聞くことによって、自分の業務に取り入れられる良いポイントなどを発見することができるかもしれません。

弊社はデザイナーが基本的にUXデザイン部に固まっていて、毎週シェア会として知見の共有の場も用意されています。また、正式な場でなくても、普段から仲の良い先輩方ばかりで、話しやすい環境だと思います。せっかく素敵な環境にいるので、これを利用しない手は無いんじゃないかな、と今は思います!

聴く力・伝える力をつける

最後に、このパイロットプロジェクトを通して、デザイナーにとって最も大切だと感じたスキル「聴く力・伝える力」を強化していかなければ、と感じています。これは前述のデザインレビューと、プロジェクトの外の人を頼るというお話どちらにも共通して必要なスキルです。

今後、プロジェクトを円滑に進めていくためには、聴く力・伝える力が大切になるのだと思います。お互いが考えていることを、正しく聞きとり・伝えることによって、プロジェクトに関わる全員の共通認識を作っていくことができるのではないでしょうか。 そして、これによって良いチーム開発が進められれば、結果として良いサービスを世に出すことへとつながっていくのだと思います。