2024年5月29日、「VALTES QUALITY DAY」が開催された。
オムロンとバルテス社員による対談セッションは「オムロンの目指す企画・営業まで巻き込む、アジャイル開発の品質保証」がテーマ。ゲストにオムロン松本光博氏を迎え、バルテス田中慶之とディスカッションを行った。
登壇者紹介
オムロン株式会社
データソリューション事業本部 自立支援事業部
商品・技術開発グループリーダー
松本 光博氏
バルテス株式会社
品質マネジメントサービス事業部 エンタープライズ品質マネジメント部
リーダー
田中 慶之
五月雨の要求を受け止めるために高速アジャイル開発を採用
オムロンでは介護領域における自立支援ソリューション事業を展開している。本ソリューションの中心は、介護現場で働く専門職による分析やノウハウをシステム化したものである。具体的には、専門職が高齢者にヒアリングとアセスメントを実施して高齢者の生活行為を工程分析。これをもとに生活課題や阻害要因を抽出し、その人に適した介護支援、目標設定を行なう。また、文章作成支援機能によって専門職の負担軽減にも貢献する。バルテスはテストチームとして参画した。
本プロジェクトでは介護の専門職のみならず、オムロンの営業や企画の意見をその都度、採用しながら反映させてきたという。まずはこの特異な点について松本氏が解説した。
「自立支援ソリューションは新規事業開発モデル事業の一環で、介護現場に営業や企画の人間が張りついて一緒に解決法を探ったり、施策を重ねたりしながら進めてきました。こうした背景からやりたいことが変わることがたびたびあり、五月雨でやってくる要求に答え続けないとゴールにたどり着けない状態でした。そのため、一般的なアジャイル開発のスプリントによるアプローチでは開発を進められないという課題がありました」（松本氏）
そこで採用したのが高速アジャイル開発だ。要件定義、設計、設計レビュー、実装、実装レビュー、デバッグ、テストがひと塊になって進行するイメージとなる。
「今回のプロジェクトの特徴は営業、企画、開発、テストチームが並走して取り組まないとプロダクトが作れなかったことです。一般的なアジャイル開発では1週間、1カ月などの単位でスプリントが進行し、テストとデバッグは工程が分けられています。通常であればバルテスはその段階で参画するわけですが、開発メンバーを集めたタイミングでテストチームを招集しました。なぜなら、我々自身がドメイン知識を学びながら、試作を作って確認するステップを何度も繰り返してきたからです」（松本氏）
招集当初からテストチームのメンバーに介護業界の教科書的な書籍を渡して読み込んでもらうなど、本プロジェクトならではの方法も適用した。チームが一丸となり、一気通貫でドメイン知識を深めることが重要だったためだ。
「立ち返ったのは『アジャイルソフトウェア開発宣言』（2001年）です。アジャイル開発はフレームワークが注目されがちですが、アジャイルソフトウェア開発宣言にまとめられているのはスローガンそのものです。骨子は対話と協調、変化への対応、動くソフトウェアといったシンプルなもの。ですから営業、企画、開発のメンバーはテストチームの意見を真摯に受け止め、テストチームも営業、企画、開発の意見を尊重するといったように、お互いが対話と協調をもとに一緒にプロダクトを作る環境を基本としました」（松本氏）
テストチームが上流工程から伴走、次々とアイデアを出す
この言葉通り、バルテスのテストチームは開発の上流工程から伴走。「アジャイルソフトウェア開発宣言の骨子を愚直に実現し、要求仕様、UI資料、実機を高速かつ多角的に検証しました」と田中は振り返る。
先に述べたように、介護現場で直接やり取りする営業や企画からは五月雨で新規のアイデアや改善案が舞い込み、機能実装のリクエストが絶えない状況だったが、度重なる要件変更にも柔軟に対応した。
「仕様検討の段階でテストチームが仕様を一旦読み込んだり、実機で試す際にUIの部分で詳細に確認したりしてフィードバックを返してもらいました。常に情報を共有しているので『ここはどう動くのか』『このボタンはこういう動きでいいのか』といった意見がテストチームからも出てきて、それが上流の要件定義に反映されるのが開発プロセスの日常でした。商用で正しく高品質なプロダクトを作るには、バルテスのノウハウが不可欠。それを活用して高速アジャイル開発を成功させました」（松本氏）
こうした伴走型の検証を「探索的テスト・仕様整理」と名づけ、テストチームはユーザーの立場に立った使い方やシステム構築などについて積極的に案を出した。田中は「毎週金曜日に定例会議を開き、しっかりとコミュニケーションを取る場合は週に2回ミーティングを開催。必要に応じて臨時の打ち合わせも実施しました。定例会議では松本様と対話を重ねながらいろんなチャレンジをさせていただきました」と語る。
例えばFigmaで作成された図案をもとにUI／UX仕様書をテストチームで作成。それによりさらなる仕様理解の浸透に努めた。「我々が画面設計書を作りますと立候補して、それが結果的にインプットや早期のフィードバックにつながったと考えています」と田中は語る。松本氏も、これらスピード感のある手法が上手くハマったと評価する。
オープンな場を作れたことが最も大きな成功要因
田中は本活動におけるメリット、デメリットを開発チーム、テストチーム双方の視点からまとめた。開発チームのメリットとしては「仕様バグ・漏れの早期発見（品質の向上）」「UI／UXの妥当性が評価できる（品質の向上）」「仕様書作成分の工数を開発に注力できる（コスト削減）」の3つ、テストチームのメリットには、「仕様の早期把握による時間コスト削減」「仕様整理のアウトプットがテスト設計のインプットとなる（精度の高いテスト設計が可能）」の2つを挙げた。
一方のデメリットについては、開発チームが「開発人員が古い思想だと指示待ちになってしまう」「『変化への対応』によって優先度が低いタスクを諦める必要がある」「スケジュールを次々と組み替えるため、チーム間のコミュニケーションに多くの時間を取る必要がある」の3つ、テストチームが「カバー範囲が拡がったことにより、ドメイン知識の習得が必須になってしまう」の2つを挙げた。そのうえで田中は、今回の学びについてこのように触れた。
「テストチームの観点で言えば、前段階で仕様やUIを煮詰めたものに対してテスト設計を行なうので、非常に精度が高いものができあがるのが大きなメリットです。ただし、単純にテストの知識があればいいというわけではありません。介護業界に限らず、厚生労働省の仕組みなどもしっかり頭に入れて設計する必要があったため、人員のアサインも含めて、そこが一番難しいと感じました」（田中）
松本氏は「デメリットよりも遥かにメリットのほうが大きい。デメリットは課題と認識してリスクヘッジすることでカバーできるのに対し、メリットは失われるわけではないからです。表面化したデメリットに関してはおおよそリスクヘッジできたこともあり、今回のプロジェクトは成功したのだと思います」と手応えを見せた。
最後に田中は、「今回のケースをすべてのプロジェクトに当てはめることは難しいですが、開発チームとテストチームのあり方の成功例の1つとして紹介したい」と前置きして成功させる4つのポイントを披露した。
これを受け松本氏は、次のように結びの言葉を述べた。
「この4つのポイントは確かに必須ですが、結局は発注側、受注側という立場を超えて、“1つの目標に向かう一緒のチーム”との意識を持つことが最も重要だと考えます。私自身、それぞれの立場を超えて協力し合い、コミュニケーションを重視した環境を作ることが大事だと改めて感じました。
このポイントで言えば4番目はよくあるケースです。おかしいと思っていても言えないことは多々ありますから。でも疑問をすぐに相談できたり、議論できたりすれば、失敗する確率を減らすことができます。その空気を醸成できなければ、どれだけ緻密なプロセスを計画しても検知されたリスクが判断されず、放置されて瓦解することが起こり得ます。しかし今回はそうした問題をクリアしつつ、なおかつ次々と出てくる要求に対して対処することができました。やはり、オープンな場を作れたことが最も大きな成功要因だと捉えています」（松本氏）
VALTES QUALITY DAYでは品質向上に力を入れる各社をゲストに迎え、その取り組みを伺った。各セッションのレポートは特設サイトに掲載している。
（所属・役職は2024年5月時点のものです）
