🐈

新規プロダクトを開発するために実施したこと

2023/09/06に公開

インセプションデッキ

私は現在、「技工くん」という歯科医院・歯科技工所のDXを推進するSaaSサービスの開発リーダーを行っています。
「技工くん」は会社の新規事業としてちょうど1年前に開発を任されました。
新規プロダクトの開発は私が行いたかったことであり、それを任されたことは大変嬉しかったです。
また、それを行うためにこれまで努力を積み重ねてきたのでこのプロジェクトを成功させることに対する大きな自信がありました。
しかし、実際に行ってみるととても難しい仕事であり、全然上手くいかないと感じることが多々ありました。
そのような困難な時期を乗り越えてプロダクトを先日無事にリリースすることが出来ました。

今回は新規プロダクト開発をどのように進めてきたかについて記述します。
本記事は今後新規プロダクト開発を行う誰かの参考になれば嬉しいです。

1. プロダクト紹介

今回私が開発したのは「技工くん」というSaaSアプリケーションになります。
まず、歯科技工とは何かご存知でしょうか。
歯が欠けてしまった時に被せる補綴物や義歯等を製作したり、修理することを「歯科技工」といいます。
具体的には銀歯だったり入れ歯などをイメージしていただくと分かりやすいと思います。
その歯科技工を製作する施設を「歯科技工所」と呼びます。
一般的には歯科技工物は患者さんが歯科医院に来院された時に歯科医師から必要だと判断されれば歯科技工所に発注されます。
その後製作されたものが歯科医院に届き、患者さんの口の中にセットされます。
この一連の過程の中で歯科医院と歯科技工所間でコミュニケーションが必要になります。
「技工くん」はそのコミュニケーションの部分をサポートするプロダクトになっています。

技工くんについてさらに詳しく知りたい方は以下ご覧ください。

WHITE CROSSの新サービス「技工くん」が生まれるまで | 赤司征大

プロモーション動画

以上が「技工くん」の概要になります。
次からは実際にどのように開発を進めたかについて解説します。

2. インセプションデッキ

私達はプロジェクト開始時点で「歯科技工向けSaaSプロダクト」を開発するという所まではイメージが共有できていました。
しかし、そのような抽象的なイメージだけではプロダクト開発を進めることは出来ません。
より具体的なイメージをプロジェクトチームメンバーで共有するための手段としてインセプションデッキを行いました。

インセプションデッキとは定義された10のトピックを進めていくことでこれから開発するプロダクト全体像を具体化する手法です。
書籍「アジャイルサムライ」ではインセプションデッキについて以下のように紹介されています。

インセプションデッキは10の課題で構成されている。
いずれの課題も、プロジェクトを開始する前に聞いておかないとまずい質問ばかりだ。
インセプションデッキを活用すれば、プロジェクトというバスに然るべき人が乗っているか、
バスが然るべき方向を向いているかを、
プログラマが最初の一行目のコードを書き始めるよりもずっと前にしっかりと確認できるようになる。

インセプションデッキで用意されている10の問いは以下になります。

1. 我々はなぜここにいるのか
2. エレベーターピッチを作る
3. パッケージデザインを作る
4. やらないことリストを作る
5. 「ご近所さん」を探せ
6. 解決案を描く
7. 夜も眠れなくなるような問題は何だろうか
8. 期間を決める
9. 優先順位は？
10. 何がどれだけ必要なのか

私達も実際に上記の質問に答えていきながらインセプションデッキを作成しました。
実際に作成したものをいくつかご紹介します。

1. 我々はなぜここにいるのか？

WHITE CROSSは歯科医療の社会的価値を高める事業を展開していく。

歯科医療の担い手の１プレーヤーである歯科技工の社会的価値を高め、
歯科技工士が安定・安心して歯科技工の本質的な価値提供できる世界観を作り出す。

そのために、歯科技工の周辺業務をDXにより効率化する。
具体的には、非効率、面倒、属人的な業務をシステムに分担させ、
歯科技工物の製作作業そのものに注力し、技工士さんが稼げる仕組みを作る。

4. やらないことリストを作る

6. 具現化する

今改めて見返すとインセプションデッキを行った時点でイメージしていたプロダクトと実際に開発したプロダクトとは所々違います。
ただ、この時点で話し合ったプロダクトイメージの根幹の部分はあまり変わっていません。

重要なのはプロジェクト開始時点でこれから開発するプロダクトの全体像をざっくりと具体化し、それをプロジェクトに参加する全員で共有することです。
そのためのツールとしてインセプションデッキを活用することをぜひおすすめします。

インセプションデッキの作成はおおよそ1週間程度で終わりました。
全体像を具体的にイメージすることが重要なので詳細についてはこの時点ではあまり話し込むべきではありません。
むしろ一旦は早く完成させて、後の工程で更に良いものにブラッシュアップしていきましょう。

3. ユーザーヒアリング

アプリケーションはユーザーの課題を解決するために開発します。
では実際にユーザーがどのような課題を抱えていて、それを解決するためにどのようなアプリケーションを提供してあげれば良いかを知る必要があります。
インセプションデッキ時点での課題はまだ仮説に過ぎなかったです。
その仮説が本当にあっているのかどうかを検証するためのアクションとしてユーザーヒアリングを行いました。

具体的にはいくつかの歯科医院、歯科技工所に実際に訪問し、直接どのような課題を抱えているかを聞きました。
その際には事前に作成しておいたペーパープロトタイプも見せて意見を貰ったりもしました。

ここでペーパープロトタイプに対しては色々な意見を貰いました。
実際に貰った意見の中でとても印象に残っているものは以下の意見です。

ネガティブな意見
「確かにこれがあると便利そう。だけどこんなの作っても歯科医師は誰も使わないよ。」
「こんなの全然だめ。何も分かってないね。」

ポジティブな意見
「これは素晴らしいね。こういうシステムがあれば歯科技工業界はもっと良くなる。」
「なんで誰もこのシステムを今まで開発してこなかったんだろうね。これは今すぐにでも欲しい。」

現場で働いている方々からの意見はとても正直です。
私達を応援してくれているからこそ出てくる辛辣な意見には肩を落とすこともありました。
しかし、反対にすごく期待してくれていることが分かる意見を貰うことも出来ました。
そのような意見は私達が今回のプロジェクトに取り組む気持ちを高めてくれました。

また、プロトタイプへのフィードバックでは以下のような意見を貰いました。

「こういうものがあれば欲しい。」
「〜の業務が大変。これを簡単にする機能を開発して。」

このような意見は更にプロダクトをブラッシュアップするためのとても参考になる意見です。
このようにユーザーヒアリングを重ねることでユーザーの解像度を高めることが出来ます。
それにより、どのような機能を備えたプロダクトを開発すれば良いかをより深く考察することが可能になります。

今振り返って思うのはユーザーにヒアリングを行わずに仮説のままプロダクトを開発していたら絶対に失敗していたということです。
歯科医院、歯科技工所と大きく分類してしまうと分かりづらいですが、実際には専門分野や組織規模、運営方針等の違いによりそれぞれの組織で解決したい課題が全然違うことが分かりました。
しかし、反対にどこに行っても耳にする共通の課題があることもありました。
様々な意見をこの時点で聞いておくことで、まずはどのようなプロダクトを開発すれば良いかが判断しやすくなります。

実際にユーザーの元へ足を運び、ユーザーヒアリングを行い、ユーザーの課題を抽出し、それを解決するためのソリューションを提供する。
この一連のフローを行わない限り、ユーザーの課題を解決し、ユーザーに支持されるプロダクトを開発することは出来ないと私は思います。

4. ユーザーストーリーマッピング

ユーザーヒアリングの結果、ユーザーが大変多くの課題を抱えていることが分かりました。
それらの課題を解決するための機能を実際にプロダクトに持たせてあげる事ができればたくさんのユーザーが使ってくれるプロダクトを開発する事が出来ます。
しかし、プロジェクトには予算と期間が決まっていていました。
その様な状況では開発できる機能は限られてきます。
そうなった時にはどの機能を開発して、どのような機能は開発を後回しにするか取捨選択を行う必要があります。

ここでは開発するべき機能の洗い出しと取捨選択を行うためにユーザーストーリーマッピングを活用しました。

ユーザーストーリーマッピングについて簡単にご説明するとユーザーの行動を時系列順に横軸に並べ、その行動に対してプロダクトが提供したい機能を縦軸に優先順位順に並べることで、どのような機能を開発していくべきかを洗い出すことが出来ます。

私達が作成したユーザーストーリーマッピングは以下になります。

こちらはオンラインホワイトボードツールのMiroを使用して作りました。
Miroを使用することでリモートでチームメンバーとユーザーストーリーマッピングを作成することが出来ます。
本来であればオフラインでみんなで肩を突き合わせて行いたいですがこの頃はコロナウイルスが流行していたのでオンラインで行っています。

私達はさらに縦に並べたユーザーストーリーに対してMoSCoW分析を行いました。
MoSCoW分析は要件をMust(必ず対応)、Should（対応するべき）、Could（出来れば対応）、Won't（今は対応しない）に分類する手法です。
これを行うことで作成したユーザーストーリーに対してどこまでをまずは開発してどこからは後で開発するかを分かりやすく分類しました。

5.ワイヤーフレームの作成

次にユーザーストーリーマッピングでMustに分類されたユーザーストーリーを具体的にどのようにアプリケーションで表現するかについて検討しました。
ここでは画面のワイヤーフレームを作成しました。
作成したワイヤーフレームのうちいくつかを抜粋してご紹介します。

このようなワイヤーフレームを作成することで、より開発するアプリケーションに対するイメージをプロジェクトメンバーと共有することが出来ます。
また、もし修正するべき点があった場合に実際に開発し終えてからコードに対して修正するよりもこの時点で修正するほうが簡単に行なえます。
こちらもMiroを使用して作成しました。

その後、上記のワイヤーフレームをデザイナーに渡しました。
結果として、以下の画面デザインを作成してもらいました。

デザイナーさんの手腕によって私の下手くそな絵をアプリケーションのデザインに落とし込んでもらう事が出来ました。
私のワイヤーフレームとデザイナーに作成してもらったデザインは見比べると詳細は色々と違う所があります。
しかし、特別何かが大きく変わってもいないでしょう。
ワイヤーフレームを作成することでエンジニア・デザイナーに実際にこれから作って欲しいもののイメージを分かりやすく伝えることが出来ます。

5.技術選定

技術の採用基準

Webアプリケーションを作成するために活用できる技術は沢山あります。
しかし、プロダクト開発時には沢山ある技術の中から絞って選択する必要があります。

実際に選択する際に私は以下の点を重視しました。

開発メンバーが慣れている技術である
チームメンバーの同意を得られた技術である

それぞれについて理由を説明します。

1. 開発メンバーが慣れている技術である

これは現在いる開発メンバーの能力を最大限に発揮するために必要だと考えています。
沢山の技術があり、それぞれの技術に対してメリット・デメリットが存在しています。
そのような状況下では１番優れたプログラミング言語は何か？という討論が絶えず行われています。
しかし、例えば1番優れたプログラミング言語に対する回答があったとして、現在の開発メンバーが誰も触ったことのない技術であれば1から習得し始める所から始めなければいけません。
学習能力の高いメンバーが揃い、時間に余裕があれば上記のプログラミング言語を採用しても良いかもしれません。
しかし、私達のプロジェクトは開発メンバーには能力の差があり、時間と予算にも余裕が無いという状況でした。
その様な状況下では今いる開発メンバー全員が開発経験があり、慣れ親しんでいる技術を採用するのが好ましいと判断しました。

2. チームメンバーの同意を得られた技術である

プロジェクト開始時にはまずはユーザーにプロダクトを提供することを目指すべきです。
なので、まだそこに達していない段階で学習コストを払うことには基本的には消極的です。
しかし、1で述べたこととは少し相反しますが、メリットがコストを上回ると判断出来るのであればこれまで触ったことのない技術であっても採用するべきです。
この点についてはもし私だけが開発を行うのであれば独断で判断してしまっても良いかもしれません。
しかしチームで開発を行い、今後長期的にプロダクトを保守することを見込むのであれば、攻めた技術を選択したい場合にはチームの同意は得るべきだと思います。

私は実際に開発チームメンバーに技術を提案し、同意してもらった技術を採用しました
逆に同意してもらえなかった技術もいくつかあり、それらは不採用にしました。
もしかしたらメンバーの中には論理的な意見ばかりではなく感情的な意見も混ざっていたかもしれません。
しかし、実際にその技術を使って開発を行うメンバーが楽しく開発出来るかどうかという観点も重要だと思います。
なので技術の採用においてはメンバーの同意を得ることは大切だと私は考えます。

実際に採用した技術

上記の採用基準を踏まえて私達は以下の技術を採用しました。

基本的には慣れた技術ではあるが、チームとして少し背伸びをしたような技術選択を行いました。
現在はこの当時採用した技術でプロダクト開発を進めてみます。
もちろん慣れずに戸惑うところもありますが、チームメンバーからは反発の声が挙がることはなく、それでいてそれぞれの技術の恩恵を受けることが出来ています。
約半年以上前に行った技術選択は現在でも正解だったと主張したいです。

ぜひ技術選択を行う際には私の選択基準を参考にしてみてください。

6.プロダクトリリース直前に気をつけること

プロダクトの開発は2022年の12月頃に開始しました。
その後開発を行い、4月にPoCを開始するスケジュールでした。
しかし、実際に4月にPoCを開始することは出来ませんでした。

原因としては以下が挙げられます。

確認と修正を行う時間を十分に設けられていなかった
結合テスト不足

それぞれについて解説します。

6-1. 確認と修正を行う時間を十分に設けられていなかった

新規プロダクトを開発するという行為は白紙のキャンバスに書きたい絵を描いていく行為に似ています。
しかし、圧倒的に違うのは最終的にはそれをソフトウェアとしてユーザーに提供できる品質まで高める必要があるということです。
当たり前ですが締切が近づいたら好き放題絵を描くのを止めて、お客さんに届けられるように汚れを綺麗に取り除き、額縁に収める必要があります。

ソフトウェアの場合はバグが無いか徹底的に確認し、もし見つかれば修正する時間が必要です。
しかし、私はプロダクトの確認・修正を行う時間を設けてることが出来ていなかったです。
言い訳を言うとスケジュールの保険としてバッファの期間は設けていました。
ただ、その期間も想定よりも開発の進捗が悪かったため、開発の時間に充ててしまいました。

バグを発見して潰すのはエンジニアは得意です。
どこかで開発に区切りをつけ、バグハンディングを行う時間さえあればそれは確実に防げました。

私の反省を踏まえて、新規プロダクト開発を行う際にはリリース前（おおよそ1ヶ月程度前）には時間を開けてバグが見つからないか徹底的に探して修正する時間を設けましょう。

6-2. テスト不足

私達の開発チームは個々のエンジニアが一つ一つの機能を開発していました。
開発する際に単体を行ってもらっていたので単体テストは問題なかったです。
ただ、単体テストでは問題なかった部分もリリースするために結合すると多くのバグが発生してしまいました。

上記の自体を踏まえ、私達は結合テストの不足を解消するために結合テストのシナリオを大量に作成しました。
実際に作成したものが以下になります。

結合テストは以下の要素で構成しています。
・No
・ユーザー種別
・シナリオ
・機能
・テスト内容

これを全ての機能に対して作成することで実際にどのような利用シーンが想定され、その際にどのような挙動が発生することを期待しているかをテスト実施者に伝えることが出来ます。

また、発見されたバグをまとめて記載しておくバグ管理表も作成しました。

これを作成することにより、発見したバグについて漏らすことなく修正することが出来ました。

7.最後に

今回はプロダクトを実際にリリースするまでにどのようにプロジェクトを進めてきたかについて詳細に解説しました。
読みやすい記事を目指し、簡潔にまとめたため、この記事を読むだけだと綺麗にプロジェクトが進んでいるように感じられるかもしれません。
しかし、実際はここでは書くことが出来ない様々なドラマがありました。

私はこのプロジェクトを上手く進めることが出来たと言うことは出来ません。
最初にも述べた通り、私はこのプロジェクトを任された当初は自信に満ち溢れ、絶対に成功させてやるという確固たる意志がありました。
しかし、困難な場面に遭遇する中で私の自信は少しずつ失われていきました。
自分一人で進めるのは無理だという現実を突きつけられました。

そのような中でもプロジェクト内外のたくさんの人に助けてもらえたおかげでプロダクトは最終的には無事にリリースすることが出来ました。
最後に新規プロダクトのプロジェクトを成功させるためのアドバイスを添えるのであれば、もし困ったら協力して貰える人を探しておき、その人を頼ることです。
その時の恩は短期的には感謝の言葉を伝え、長期的にはプロダクトの成果で返しましょう。
私も今回のプロジェクトでたくさんの借りを作ってしまいました。
これからさらに「技工くん」を成長させることで徐々にその借りを返していこうと思います。

ご一読いただきありがとうございました。

8.告知

技工くんの開発を手伝ってくださる方を探しています。
ぜひご応募ください！

Twitterやってます。
ぜひフォローしてください！
https://twitter.com/kazukiogura_

9.参考書籍

・「アジャイルサムライ」(https://shop.ohmsha.co.jp/shopdetail/000000001901/)
・「ユーザーストーリーマッピング」(https://www.oreilly.co.jp/books/9784873117324/)