はじめに
株式会社LITALICOでエンジニアをやっている@kazuisです。
この記事は『LITALICO Engineers Advent Calendar 2022』の20日目の記事になります。
LITALICOでは多くのエンジニアが開発を日々頑張っております。
福祉の事業所を運営している会社ではありますが、エンジニアの人数も200人近く在籍しておりIT企業の一面もでてきました。
発達ナビ、仕事ナビ、LITALICOキャリアなどユーザ向けプロダクトを開発している面もありますが、福祉施設向け、学校向けのプロダクトも自社で開発しております。
専門家のための専門家のための業務システムを作っています。
深いドメイン知識が求められる難しい面もあり、以下の問題がちらほら出てきたりしてます。
- 影響範囲が分かりづらい
- ユーザーがどう使うかイメージしにくい
- 要求が増えるけど、理由がわからん
この記事では、ドメイン知識の深みにハマらずに、納得感のあるプロダクト開発を進めるヒントになれば幸いです。
対象読者
- 業務知識が大盛りのプロダクトに関わる方
- プロダクトオーナー、UXデザイナ、プロダクト開発者、QAエンジニアなど分析フェーズでお仕事される方
どんなときに納得感がなくなるのか
このフロー図は、「サービス開発プロセス」の何が変われば、どこの成果物（フェーズ）に影響があるか表現しています。例えば、オペレーションが変わった場合、ユーザストーリに影響があり、状態遷移に影響があったしますが、画面設計などに影響はありますが、要件定義や、アーキテクチャには影響がない。業務のどのプロセス構造が変われば、どのシステム構造に影響があるかを示してます。
業務システムの場合、まず、実行しなければならない「業務」が決まっています。
そして、効率化が求められる部分が多いです。
要求が変わる多くの理由は、業務プロセスが変えたいという業務体験を変えたいという事が多くなります。
あれもこれも変えたいと言われ、Whyが抜けていく事が多くなり、納得感は消滅していくのが、ありがちです。
どのドキュメントを中心に、分析していくと筋が良さそうでしょうか？
納得は全てに優先する（※ジョジョネタです）
結論を先に書きます。
プロダクトチーム全員が納得できる状態が目指す状態とします。
ドメイン知識が深さが必要なプロダクトの場合規模感によって分析プロセスを変えるのがいいです。
しかし、多くの知識を求められるプロダクトで、プロダクトメンバーで知識を平準化するのはとても難しいです。
カスタマージャーニーマップを中心にみんなで情報共有をしていくのが1番納得感が作れそうです。
それは抽象度が高くなく、具体性のある言葉で表現されるからです。
業務システム開発でよくある業務フローやデータフローはモデリング技術や暗黙値が多くなります。
長年一緒にやってるチームの場合は、逆に論点が狭まるのでこれが早い場合もあります。
気をつけた方がいいのは、プロジェクトとしては3〜4ヶ月で一定の価値が提供できるぐらいの規模でプロダクトの開発の区切りは付けた方がいいです。カスタマージャーニーマップが巨大化すると、それはそれで業務が複雑になり平準化が難しくなり納得感は失われるでしょう。
プロダクト規模、開発プロジェクトの大きさのコントロールが1番難しく、これに成功すればいいのです。
プロジェクトの分割の難しさはありますが、それを考えるためにカスタマージャーニーマップを使うのは1番納得感があるやり方でしょう。
データフロー
< 業務設計＆ユースケース
< カスタマージャーニーマップ
どれが正解というわけではいですが、みんなで見る地図としては、上記の順序で納得感が得られそう。
業務システムだからっていう常識に囚われず、みんなが納得する手段を選ぶのが重要そうです。
業務設計＆ユースケースを中心に考える
業務フローです。よくあるAsIS ToBeの分析パターンなどを使ったりします。業務フローをベースにユースケースモデルを使い業務分析を進めていく事が多いと思います。プロセス中心に効率化を求める方法と思えます。
業務担当
業務のドメインエキスパートにわかりやすい分析手法なので、自然に話はできそう。
暗黙知になりがちで、ドメイン知識がないと納得感低い。
ドメインが求めれるシステムでは理解度がバラツキがあり業務担当者同士でも認識を合わせるのは難しい。
プロダクトマネージャ
どれだけの費用対効果が発生するのかはわかりやすい。
AsIS toBeで表現したり比較がしやすい。
ユースケースなどのモデル表現は、スキルが求められるので業務からプロダクトへのつながりを納得するのは難しさがある。
UXデザイナ
ドメイン理解度が高い場合問題はないが、業務フローから、UXへ議論に進めるのはチーム内の理解度を合わせる必要があるので困難さがある。ユースケースモデルで大枠決めてしまうので、UIデザインになりがちになってしまう。
開発エンジニア
ユースケース図などモデルで実施する方法があるので開発エンジニアが、ユースケース=機能にしてしまいがち。しかし、ユースケースを抽出し、どのような機能が必要なのかを分析する方法は業務をもれなく実施する分析をするには安心感はある。
QAエンジニア
ドメイン理解が高く、ユースケース分析から論点やリスクを洗い出すスキルがあれば問題はないが、多くの場合とても品質を定義するのは難しい。なぜならば、全体的に暗黙知が多くなるやり方なので、品質を定義するのがとても難しい。システム仕様と、業務オペレーションをつなげるのが難しくシステムへの影響を理解するのは業務モデリングのスキルが求められる。
カスタマージャーニーマップを中心に考える
ペルソナを作成し、業務分類（フェーズ）ごとにユーザ行動・思考や感情を議論し、施策案を作っていきます。ペルソナを作ったり、感情や思考を表現する事によって主観的から客観的な施策にします。
業務担当
フェーズは理解しやすく分類をつくる必要があるが、業務の流れはわかりやすい。ユーザ行動や思考を表現しているフォーマットは、業務フローに表現されてない業務を遂行する上で必要な事が書いてあるので開発者にも伝えやすくなる。
プロダクトマネージャ
プロダクトの価値を判断するのにわかりやすい。実現したい業務遂行と、どういう価値をプロダクト化するのかの関連がわかりやすく判断しやすい。ユーザーストーリーマップのように優先順位をつけるのに応用してもいいと思ってます。プロダクトを巨大化させないようにするための判断は重要です。
UXデザイナ
UXデザイナのプロダクト分析手法ではあるので、利用者の行動と、振る舞い、UIをこの手法で結びつけるのは得意です！
開発エンジニア
データ要素、ユースケースなどを追加して表現するとDFDとユースケース分析の間みたいな使い方ができるので変更点とシステムを紐付ける事はイメージが付きやすいと思います。
QAエンジニア
ユーザ行動を思考や感情と紐付けられて理解できるため、利用時の品質の指標である満足性を検証するための分析や、発生しうるリスクを分析するためな情報と変更内容にが紐付けられるので変更点の影響など納得感もって知る事ができる。
データフローを中心に考える
データ中心アプローチ（DOA：Data Oriented Approach）で考えます。データフロー図を作って、データのライフサイクルを中心に分析し、データモデル図で詳細を設計していきます。エンタープライズ向けの開発でよく使われる分析手法ではありますが、業務システムはデータを正しく記録する事が責務になりますからデータの流れで分析をするのは納得感がある。
業務担当
アクターとアクションの組み合わせでどのようなデータが作られるかわかりやすいと思われるが、、業務担当者とデータフローを作っているエンジニアの認識があっている状態をつくるのは難しい。DFDは抽象度の高いモデルであるため、理解度をお互いに合わせるのは難しい。
プロダクトマネージャ
データの流れとストアが可視化され、データを正確に記録するシステムだと安心感はある。抽象化度が高いので、ユーザに何を提供するのかはイメージは付きづらくユーザ価値視点では難解さが発生する。
UXデザイナ
そもそもデータの流れを表現しているものであるので、ユーザー体験やUIという表現はしづらい。
開発エンジニア
システム構造の分析のためのモデリング技法のため、エンジニアがシステムをイメージしやすい。アクターとアクションを紐付けるのはユースケースと似ているが、データのライフサイクル視点でみる事ができるため、システム全体のデータがどう扱われるかを分析する場合は嬉しい。
QAエンジニア
業務変わった事をデータ視点で見る場合はデータ品質、有効性を確認するのはいいドキュメントになりそう。なぜ、画面がかわるとかオペレーションがなぜ変わるかどういうリスクがあるかなど、それ以上の事は表現されないのでドメイン知識の差によって納得感はわかれそう。
まとめ
toC向けのプロダクトでつかわれるUX設計のカスタマージャーニーマップを作って業務システムをつくる事をしている会社は少ないかも知れませんが、toB向けの業務システムでドメイン知識を共有するのに有効だと思います。
ドメイン駆動でドメインモデルでドメインエキスパートと知識共有していこうぜっていう話もありますが、、難しさを感じてる方にカスタマージャーニーマップからのドメインモデルをつくるといいかもよってお話でした。
何より、新しい開発メンバーがJOINしたときにプロダクトの理解を進めやすい！っていうのが1番ですね。
新しいメンバーの納得感を1番大事です。
最後まで読んでいただきまして、ありがとうございます。