こんにちは。ヘンリーCEOの逆瀬川です。
開発する上で、難しい部分の一つである要件定義。
最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。
本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。
では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。
- ユースケースで仕様漏れた時代
- 要求導入混沌時代
- 要求を全員で書くぞ時代
- プロダクト要求と仕様を分けて書き始めた時代
- CSと連携して速度が上がり始めた夜明け前
- 将来訪れるだろう要求開発黄金時代へ
本題に入る前に
要求の難易度を理解するために、Henryについて少しだけご紹介します。
私たちは、電子カルテ・会計システムをコアとするクラウド型基幹システム「Henry」の開発をしております。複雑な診療フローと法制度の制約、多くのアクターが使うシステムになるため開発難易度が高く、実は四半世紀以上新規プレイヤーが参入してきてない業界です。
- 開発難易度を上げる具体的な話
- 診療報酬制度は、A4で1,700ページ以上あり、かつ2年に1度大きなルール変更がある
- 3省2ガイドラインという官庁が出しているセキュリティ要件がある
- 病院には、多くの診療科・病棟の種類があり、それぞれ細かいニーズが異なる
- 入院患者さんの治療には、医者だけではなく、看護師、クラーク(医者の事務補助)、セラピスト、栄養士、薬剤師、検査技師、医療事務(会計・受付)など、多くの人が関わる
などなど
上記の様に、基幹システムでありかつ会計の機能も開発しているシステムのため、要求をしっかり捉えることが重要になります。
事業の詳細を知りたい人は下記動画を御覧ください。
レセコン×電子カルテ スタートアップ「Henry」彼らは今、何を考えているのか〜Henry CEO 逆瀬川光人 - YouTube
1. ユースケースで仕様漏れた時代
最初にクリニック向けの電子カルテの開発では、ユースケースを詳細にまとめ、デザイナーとエンジニアがそれを読んで設計や内部仕様を決めるという流れで進めていました。
クリニック向けの開発が大きな事故なくリリースできたため、病院向けの開発が始まった当初も同じように進めましたが、病院ではアクターが多く、複数のアクターが関わるユースケースの複雑性を捉えるのに漏れなく失敗しました。
例えば、処方のオーダー(院内の指示出しと指示受けのワークフロー)という機能についても、医師や看護リーダー、現場の看護師、薬剤師、医療事務、クラークといった幅広い職種が別の理由で利用します。
要件定義で行ったこと
- 業務ワークフローの書き起こし
- 最小限のユーザーインタビュー
- ユースケースの書き起こし
- テストケースの書き起こし
何を失敗したのか
- アクターが多く、すべてのユースケースを洗い出せなかった
- 当人ではない相手にユーザーインタビューをしてしまい、自分がやらない業務について、想定の回答をもらってしまった。
- ユースケースでまとめたため、プロダクトで求められる要求をMECEに整理ができなかった などなど
失敗した結果何が起こったのか
- 一部の機能を作り直した・・・
2. 要求導入混沌時代
プロダクト要求をきちんとMECEに整理しようという気持ちになり、要求を仕様化する技術・表現する技術の輪読会をして、要求と仕様を書き始めました。どういうフォーマットにするべきか、どういう粒度で書くかをすり合わせして書き出しました。電子カルテでコアとなる入退院のモデルがあるのですが、これに関しては10回くらい書き直しています。加えて、ドメインの知識を実装するエンジニアも必要だろうということで社内勉強会で各ユースケースの説明をしていきました。完成フローやフォーマットが固まるまで地獄でしたが、光が見え始めた時代です。
要件定義で行ったこと
何を失敗したのか
- Notionで書くフォーマットにして、MECEのチェックが難しかった
- レビュープロセスが定まってなく、要求をどこまで書けば完成と言えるか分からなかった
失敗した結果何が起こったのか
- 要求の完成が見えず、開発の終わりが見えない状況が続いた
- チームにストレスをかけてしまった
3. 要求を全員で書くぞ時代
フォーマットとレビュープロセスを定めて、ある程度書けるぞとなったタイミングで要求と仕様を開発メンバー全員で書いて開発速度を早めようとTryしました。元々私とPdMロールを担う2名で書いていたのですが、様々な理由で要求がスタックすることが多くスピードを上げる施策として採用しました。
これは大きな失敗でした。そもそも、書く技術もドメイン知識もバラバラな中で全員で書けるわけがなかったのですが、
失敗に気づくのも早く、この時代は短命に終わりました。
要件定義で行ったこと
- 要求導入混沌時代と同様
何を失敗したのか
- ドメイン知識がないメンバーにも要求を書くのを求めてしまった
- PdM経験などあるメンバーとないメンバーの要求化の技術力の差を考慮せずに、みんな書けることを目指してしまった
失敗した結果何が起こったのか
- 要求が2週間程度全く進まなかった
4. プロダクト要求と仕様を分けて書き始めた時代
紆余曲折を経て、現在は要求と仕様を分けて書いています。書くツールはいろいろ試した結果、要求仕様をGoogle Spreadsheetに書き貯めています。 基本的な構成はユーザーストーリーと近く、下記構成で書いています。
- 要求
- それに紐づく理由
- 紐づく仕様
また、レビュープロセスも要求と仕様でそれぞれ定めており、要求化→レビュー、要求の内容FIX、仕様化→レビューのサイクルを定めて、適切にレビューサイクルを回して完了できるように進めています。 プロダクトチーム内の改善がだいぶ進んで来たなと振り返ると感じます。
要件定義で行ったこと
要求導入混沌時代に加えて。。。
- レビュープロセスを整えた
- 要求仕様の書くフォーマットを整えた
何を失敗したのか
- Epic単位での提供価値とユーザーのペイン・ゲインが見えづらくなった
- プロダクト要求をきちんと書くことを意識しすぎた
- このプロダクト要求がビジネス的にどのようなインパクトがあるのか、なぜ必要なのかというビジネス要求がわからなくなった
- どういうものが最終的に必要なのかイメージ出来なくなった
- 要求・仕様をきちんと書かなくて良いライトな機能についても書きすぎてしまう
失敗した結果何が起こったのか
- 仕様を見直そうとした時に、何を基準に判断すればよいかわからない
- 開発速度が遅れた
5. CSと連携して速度が上がり始めた夜明け前
ここでブレイクスルーが起こります。CS(カスタマーサクセス)を担当している山本さんと永井さんがエンジニアチームのDaily Stand Up等のチームアクティビティに参加し、密に連携を取り始めました。2人は実際に病院で医事課業務を行っており、ワークフローへの理解も深いです。CSメンバーが積極的に開発に関わるようになったことで開発プロセスと要求の質が劇的に向上しました。
行ったこと
- CSのメンバーが開発チームにJOIN
- CSがビジネス要求や不明点の収集をお願いした
- 要求分析の相談をDailyで行った
- 要求化のプロセスものはCSを通じてアジャイルなサイクルを回した
ポジティブな変化
- ビジネス要求の把握がほぼリアルタイムで行えるようになった
- 顧客インタビューや観察スピードが劇的にUPして、要求化のスピードが改善した
- CSを通じて顧客との距離が近くなり、ライトなものはすぐ改善するサイクルが出来た(要求を書く強弱をつけられるようになった)
- プロセス全体としてアジャイルに徐々に品質を上げていけるようになった
6. 将来訪れるだろう要求開発黄金時代へ
3年間の学びを受けて、これから改善していきたいなと考えている内容をつらつらと書きます。継続的に開発プロセスに導入することができれば良いですが、全部改善できるというわけでもないので、一つずつ改善していきたいと思っています。
これからやりたい流れ
- ビジネス要求のデータベース化
- プロダクト要求とビジネス要求を接続し、なぜ作るかがわかりやすく
- 実例マッピングの導入
- 要求のメンテナンスのプロセス化
- 要求が常に最新であることを保つためのプロセス設計
- 要求とプロジェクト管理の整理
- 要求と開発チケットを紐付け、相互リンクできるように
- QAプロセスの改善
- すべてのプロセスでQAを行い、品質向上を目指す
など
おわりに : アジャイルなプロセスで要求開発の質を上げつつ、スピードを担保する
要求開発は、あくまで価値提供のスピードと品質を上げるための施策に過ぎません。元々、開発内で閉じた改善活動もCSと協働することで、開発スピードが上がり、要求の質も高めることが出来ました。これからも、開発内に閉じず、会社全体で良いプロダクトを提供していくために改善していく予定ですが、要求開発とそのプロセスは重要な要素の一つであり続けると思います。
ぜひ、一緒に良いプロダクトを作りたい、そのために要求の質を上げていきたいぞっていう方がいたら、ご連絡ください。
2月末と3月頭にイベントもやるので、ワイワイ話しましょう！
プロセスを設計する上で参考にした書籍・リンク
*1:要求仕様フォーマットのサンプル
