デザイナー・PO・エンジニア、チーム全員でユーザーストーリーを作る意義──「カイポケ」リニューアル、スクラム開発の舞台裏

介護・障害福祉事業者向けの経営支援サービス「カイポケ」。現場での業務効率化やケアの質向上につながる点が高く評価されており、2025年4月1日時点で5万5550件の事業所に導入されています。

2006年にサービスをローンチしてから、40以上のサービスを提供してきたカイポケ。2021年に大規模なリニューアルをすることになり、エンジニアだけでなく関係者全員が開発プロセスを共有し、さまざまな観点からユーザーストーリーを描くことで、プロダクトの品質と開発スピードを両立させてきました。

立場も専門知識も異なる関係者全員でのコミュニケーションは、どのように行われてきたのでしょうか。プロジェクトに参画しているグッドパッチの2人と、カイポケを運営するエス・エム・エスでプロダクトオーナーを務める高橋早矢香さん、同社のフロントエンドエンジニア原野誉大さんに、スクラム開発の舞台裏について聞きました。

＜話し手＞
株式会社エス・エム・エス プロダクトオーナー（PO）　高橋さん
株式会社エス・エム・エス フロントエンドエンジニア　原野さん
Goodpatch UIデザイナー　矢吹
Goodpatch フロントエンドエンジニア　大角

速度を求めたデザイナーとエンジニアの「分業体制」　コミュニケーション面のデメリットも

──まずは、改めて「カイポケ」リニューアルプロジェクトの概要を教えていただけますか。

エス・エム・エス 高橋さん：
以前、弊社の酒井にインタビューいただいた記事でもあるように、2021年9月からリニューアルプロジェクトを立ち上げました。

カイポケは介護・障害福祉事業所向けに40種類超のサービスを提供する大規模なサービスです。ローンチしてから15年以上が経過していましたが、定期的な法改正に伴いアップデートを繰り返した結果、UIが1000ページを超えて使いづらい部分が増えてきていました。「リプレイスか、リニューアルか」について社内でも何度も話し合いを重ねたのですが、ユーザー数も増えていたことから、拡張性の担保と生産性の向上を目指し、本格的にリニューアルに着手することになりました。

株式会社エス・エム・エス プロダクトオーナー（PO） 高橋さん

──前回の記事でも、デザイナーとエンジニアのコラボレーションを取り上げました。カイポケリニューアルプロジェクトで、両者が協働する際の課題はありましたか？

エス・エム・エス 原野さん：
そのインタビュー記事にもあるように、デザイナーとエンジニアがあえて分業体制を取っていた時期がありました。具体的には、まずデザイナーとPOで、アプリケーションをどういう形にしていくかをある程度固めた上で、エンジニアと相談するというプロセスを採用していたのです。開発スピードを高めるために有力な手段だったと思いますが、実装段階でデザイナーとエンジニアのコミュニケーションに時間がかかるというデメリットもありました。

例えば、デザイナーの方が作ったFigmaでのデザイン案に対して、担当エンジニアが気になる部分やコメントを書き込んでいたのですが、開発に抜け漏れが起きてしまう。エンジニアが開発段階で不明点に気付き、仕様が分からないまま想像して作ったものが、デザイナーからは「何か違う」と受け止められるなど、認識のズレが起きていました。

Goodpatch 大角：
デザイナーの間で「これでいこう」と合意した案が、納期やエンジニア側での開発コストの側面から、簡素なデザインに作り変えて実装されるケースもいくつか出ていました。

Goodpatch 矢吹：
当時のデザイナーチームでは検証フェーズを長く取っており、POの高橋さんとも「こういう理由でこのデザインでやっていく」と意思疎通が図れていました。しかし、開発するエンジニアはその経緯を知らないため、開発段階でもう一度「これはなぜ必要なのですか？」という質問を受けることが多くて「それはそうだよな」と。

デザイナーは、構想段階で機能的にもデザイン的にもやりたいことを全て詰め込んでいます。でもエンジニア目線で見ると、このデザインにした理由や意図が分からない。とはいえ誰とやり取りすればいいのかもよく分からず、双方で満足なコミュニケーションが取れていない状態でした。

──高橋さんは、POという立場から当時の状況をどう捉えていましたか。

エス・エム・エス 高橋さん：
当時はリリースを後ろ倒しにしてでも品質を担保するのか、それとも納期を優先した開発を行うかを判断しなければいけないタイミングでした。結果的に、リリースを優先した上で品質をどう担保するかをもう一度見直すという判断になりました。

「画面の振る舞い」を関係者間で共有することで、認識のすれ違いを防ぐ

──目標が定まらない状態でリリースは迫っている、なかなかカオスな状況だったわけですね。コミュニケーションがうまくいかずに手戻りが多かった状態を、どう改善につなげたのでしょうか。

エス・エム・エス 原野さん：
大角さんの言う通り、納期の関係でデザインを1から作り直させてしまったことが複数回あり、「せっかく良いデザインがあるのに、これでいいのか？」という気持ちは自分の中にもありました。

そこで僕から、関係者間で画面の振る舞いの認識を合わせるための会議を提案しました。このボタンを押すとこういう挙動になる、〇〇という振る舞いが起こるとAというアラートが出るなど、エンジニアだけでなくQA（品質保証）、デザイナー全員がボードに書き出し、認識を合わせるのはどうでしょうと。

株式会社エス・エム・エス フロントエンドエンジニア 原野さん

Goodpatch 矢吹：
メニューを開くと具体的にどんなボタンが表示されるか、複製が完了した後で複製後のページに遷移する……といった、本当に細かい単位で振る舞いの情報共有を行っていきましたね。

──こうした情報の共有というのは、通常はあまり行われないのでしょうか。

エス・エム・エス 原野さん：
かもしれません。カイポケの場合、帳票で取り扱う項目が30から40と多く、さまざまなケースを確認する必要があるため、もともとフロントエンドエンジニアとQAでデータとUI画面の整理を行っていました。

介護業界では、介護を受ける人の体調やどんな家に住んでいるのかなどの情報を事業所でケアに当たる人が把握する必要があります。このフォーマットが決まっているので、全体を整理して理解する必要がありました。

UIが開発コードのどの部分に対応するかを整理していくうちに、これは他の人も巻き込んでやった方が早いのではないかと。QAの方が「実例マッピング」という形で以前同じようなことを行った経験があるという話を聞いたので、自分たちのチームでもやったら面白そうだと思って提案しました。

──それまでの役割分業とは全く異なるやり方ですが、率直に皆さんはどう思われましたか。

Goodpatch 矢吹：
正直に言うと、最初に会議に参加したときはデザイナーは何をすればいいのか分かりませんでした。しかし、会議を重ねる中で、デザイナー側で気付いていなかった機能をその場で追加作成するなど、以前よりコミュニケーションが断然取りやすくなり、抜け漏れがなくなることで手戻りもなくなりそうだという期待が生まれました。

Goodpatch 大角：
従来は一つのデザイン案を担当エンジニアがレビューしていたのですが、デザイナーとエンジニア、2人だけでやるとどうしても抜け漏れが出てしまっていました。エンジニア・QA・デザイナーと8人全員で振る舞いを確認できるようになったことで多角的視点でのチェックが働き、エッジケースなどの細かな事象にも気付けるようになりました。

エンジニア、デザイナー、PO、QA──チーム全員で描いた「ユーザーストーリー」

──振る舞いを確認する会議を行うようになってからは、チームにどのような変化がありましたか？

エス・エム・エス 原野さん：
毎週1時間かけていたのですが、やってみると思っていたよりも時間がかかることが分かって週2時間に増えてしまいました（笑）。とはいえ、皆の評判が良く、うまく機能するようになっていたので、また異なる会議、というかワークの提案を行ったんです。

──積極的ですね！どういった内容のものでしょうか。

エス・エム・エス 原野さん：
現場のユーザーがどんな使い方をするのか、なぜその業務をしなければいけないのかといった「ユーザーストーリー」を全員で作り上げ、それに伴って必要な機能や画面の振る舞いを洗い出しました。

画面の振る舞いを確認している中で「そもそも、この機能は必要なんだっけ」という議論に発展することがしばしばありまして。PRDには「なぜ、この機能が必要なのか」ということが記述されていますが、文字を読んだだけでは理解が及ばないこともありました。今まではこうしたユーザー理解や要件定義はPOの役割でしたが、エンジニアやデザインの視点も組み込めば、より良いユーザーストーリーが描けると思いました。エンジニアとしてはリリースが迫る中、本当に必要な機能の開発に注力したいという狙いもありました。

Goodpatch 矢吹：
私としてはPRD（プロダクト要求仕様書）に書かれている事柄しか理解できておらず、作るべき機能は知っていても、現場でのカイポケの利用シーンの解像度が低かったという課題がありました。

例えば、ケアマネジャーが各帳票を印刷できる機能が必要とは知っているけれど、なぜ印刷する必要があるのかが分からない。業務の内容や自治体ごとの運用ルールなど、細かい部分や制約を皆で把握し、深掘りできる場が欲しいと感じていました。

Goodpatch UIデザイナー 矢吹

エス・エム・エス 高橋さん：
POである私からすると、どのシーンでどういった情報が必要となるかが細かくは分からないため、デザイナーやエンジニアの皆さんから寄せられた質問に都度対応している状態でした。

当時はPRDを共有しているだけで「なぜその機能が必要なのか」という情報提供やフィードバックができておらず、開発を進める中で見えてきたユースケースや細かな追加機能を都度PRDに追記していたのですが、その作業も実例マッピングのワークの場で行うようになりました。

──確かに気付いたときにPRDに加筆するくらいなら、話し合いの場で機能やユースケースを洗い出して、一気に更新する方が効率的ですね。ただ、エンジニアがユーザーストーリーやユースケースまで理解するのは負荷が高いようにも感じます。その点はいかがでしたか？

エス・エム・エス 原野さん：
僕自身は指示されたものを言われた通りに淡々と作業するよりも、使われる背景を理解して作る方がやっていて楽しいと思うタイプです。なぜ現場でこの作業が必要なのか、ユーザーはどんなシーンでどのようにカイポケを使っているのか、背景を知って納得した上で開発したいと考えていました。

Goodpatch 矢吹：
エス・エム・エスのエンジニアの方たちは、原野さんのように「背景を理解して、腹落ちした状態で作る方がいい」という方が多くて。全員で同じ目的に向かってプロジェクトを遂行できるのが良かったです。

エス・エム・エス 高橋さん：
技術やデザインとあらゆる方向から揉まれて作られたユーザーストーリーは濃く、学びが多かったです。役割によって気になる部分が違うことにも気付けましたし、知見も深まりました。何より、全員で話し合いながら作り込む時間は楽しかったですね。

「リソースの効率」から「フローの効率」へ　開発で重視すべきポイントが変わった

──面白いですね。さまざまな知見によって、プロダクト開発にとって望ましいユーザーストーリーができ上がると。メリットが大きいと感じる一方で、チーム全員が一堂に集まるというのは、それだけコストが上がっていると見ることもできます。その点に関して懸念はありませんでしたか？

エス・エム・エス 原野さん：
おっしゃる通り、当初から「全員で集まることで、今より時間がかかってしまうのでは？」という懸念はありました。ただ、エス・エム・エスの社風として、メンバーが集まって話し合うことに対しての価値を重視しているんです。

Goodpatch 矢吹：
ていねいにやっていこう、という空気はありましたね。実際、Figma上でのテキストコミュニケーションにはとても時間がかかっていて、後から見た人が分かりにくいというデメリットもありました。皆で集まれば、その場で全ての疑問を解消できるので効率的でした。

エス・エム・エス 高橋さん：
組織としても、稼働時間に着目する「リソースの効率」から、タスクの待ち時間が少ない「フローの効率」へと、重視されるものが変わってきました。結果的に、顧客に価値を早期に提供できるようになりましたね。

Goodpatch 大角：
元々は、原野さんが全部を理解して作業を割り振るというプロジェクトリーダーのような役割を担っていたため、原野さんに負担が集中していました。これはトップダウン的なアプローチです。現在はプロジェクトリーダーを置かず、それぞれのメンバーが自律的に動くようなボトムアップのアプローチなので、メンバーがユーザーの課題や解決策を理解して自分で判断して動けるようになったことで、効率が上がったと思います。

私自身、これまでトップダウン型で進める開発プロセスを多く経験してきましたが、ボトムアップ型でも機能するんだというのは、一つの学びになりましたね。

──チームとして、一つの成功体験になったわけですね。

エス・エム・エス 高橋さん：
画面の振る舞いやユーザーストーリーを皆で共有したことで、各スプリントでの作業量も安定し、結果的に開発効率も上がっていきました。チームとして良いサイクルが生まれていたと思います。

Goodpatch 大角：
役割ごとにプロセスが分断されていると、デザイナーはユーザーの使いやすさを考える、エンジニアは開発しやすさを優先するといったように、それぞれの正義によってすれ違いや摩擦が生じやすくなります。でも、職種を超えて会話する機会を設けたことで、その壁が溶け合ったように思います。POやデザイナーは開発しやすいデザインを考えてくれる、エンジニアは技術的な観点を踏まえて使いやすさを考えてくれるという形でチームワークが生まれました。

Goodpatch フロントエンドエンジニア 大角

Goodpatch 矢吹：
デザイナーはユーザーストーリーマッピング作成後にlofi（デザイン下案）を作成するのですが、その時点ですぐにエンジニアやQAからレビューを受けてデザイン案を固めることができるので、大幅な修正や手戻りがなくなりました。

エス・エム・エス 原野さん：
事前のワークで画面の振る舞いが整理されたことで、エンジニアが実装前に作成するプロトタイプの完成度も上がりました。POの受け入れ基準やデザイン案もスムーズに満たせるようになり、従来QA側で作成していたテストケースも実例マッピングに組み込めるようになったので、チーム全体の作業効率が上がりました。

開発スピードも向上し、先々の開発計画まで立てられるように

──開発フローの前半で時間をかけてでもていねいに情報を共有することで、結果的に開発速度が高まるというわけですか。チーム全員がプロセスに携わることは大きなチャレンジだったと思いますが、一連の施策の効果について教えてください。

エス・エム・エス 原野さん：
エンジニアとしての開発のゴールが分かるようになり、仕事の仕方が大きく変わりましたね。今まではスプリント中に毎日パーツの相談があって、開発に支障をきたしていたのですが、そうした相談に前もって対処できるようになり、目先の開発だけでなく、次のスプリント以降の開発にも目を向けられるようになりました。

エス・エム・エス 高橋さん：
そうですね。私としては先々に開発するプロダクト要求仕様書の検討にも取り組めるようになりました。開発の優先順位が明確になることで、仕事のスピード感も上がったと思います。

Goodpatch 矢吹：
仮案の段階から、みんなで検討したユーザーストーリーに基づいてデザイン案を起こすので、「開発が始まってから、デザインを一から作り直す」ということがなくなりました。私としてはこれが一番大きい変化ですね。

Goodpatch 大角：
リデザインは大変ですよね。早い段階で皆の意見を取り入れてデザインを作成することで、何か問題があったときに修正する余裕も生まれたと思います。

エス・エム・エス 高橋さん：
そうですね。実装に入る前に要件定義ができることで工程がスムーズになりました。固まる前のデザインを見ながら会話することで「そもそも、これって可能ですか？」といったゆるい相談もしやすくなりました。

Goodpatch 大角：
確かに話し合える関係性を作るのは大事だと思いました。今のチームはクロスファンクショナルで一つのチームにいろんな役割を持つメンバーがいるので、とても話しやすいです。

──お話を聞いていると、グッドパッチとエス・エム・エス、会社は違えど1つのチームとして動けている印象を受けます。

Goodpatch 大角：
クライアントワークでは別企業だと線引きする企業もあるかと思うのですが、エス・エム・エスの仕事ではとてもフラットな関係性を築くことができました。エス・エム・エスのカルチャーとして、「一緒にやろう」という雰囲気があったので進めやすかったです。仕事の依頼内容や情報共有なども社員の方と同じように扱っていただけたのは、そういったカルチャーが後押ししてくれたように思います。

エス・エム・エス 原野さん：
確かに。コミュニケーションの観点で言えば、僕は実例マッピングを介して「この機能はどれくらい開発が大変か、時間がかかりそうか」という点をデザイナーの方に視覚的に伝えられるようになったのが助かりました。あとは単純に、皆でワイワイ話しながらプロダクトを作り上げることが楽しかったです。

Goodpatch 矢吹：
エンジニアの方たちがどのような粒度で開発タスクを分けるか、ということが分かったことで、「段階を踏んで実現する」という考え方ができるようになったのは、私としても成長できた点だなと感じています。このタスクは1スプリントで終わる、大変なタスクはまずはこの部分だけやろう、と開発の優先度合いを整理できるようになりましたね。

いきなり「私が考えた最強のデザイン」を提示しても、実現できなければ生かせませんし、だからこそ、早い段階で理想像を共有して、そこにどう登っていくかをエンジニアと一緒に考えることが大事なんだと感じています。

Goodpatch 大角：
そういえば、矢吹さん自身がプログラムコードを書こうとしたことがありましたよね？相手の仕事を理解しようとする姿勢がとてもいいなと思っていました。

Goodpatch 矢吹：
アイコンやボタンなど、細かい修正をわざわざ依頼することが申し訳なくて、見つけた人がパッと直せたらいいなと思って。実際やってみたら、修正箇所を見つけること自体も大変なんだと分かりましたよ（笑）。

──ありがとうございました！最後にカイポケの今後の展望について教えてください。

エス・エム・エス 高橋さん：
カイポケが、ライフラインのように介護・障害福祉業界で当たり前に使われるサービスでありたいです。ユーザーである事業所の皆さんが本来の業務に専念できるようになり、ケアを受ける人も、ご自宅に帰ったユーザーさんの暮らしにも、良い波及があるサービスになっていけたらと考えています。

関連記事

エス・エム・エスのプロダクトデザイン組織について知りたい方は、ぜひこちらの記事もご覧ください。

https://cocoda.design/atsushisakai/p/p4226830268e7
時代に合う「デザイン品質」へ。カイポケのデザイン組織立ち上げの裏側