はじめに
はじめまして。フランスのお菓子、マドレーヌです。
一日目のoohiraさんの記事とうって変わって、初心者の「やってみた」シリーズです。エンジニアの実施するソフトウェア設計の前工程または問題領域で、デザイナーがどんなことを気にしたり考えているのか、その一部をご紹介します。
前提になる対象読者
- 面白半分の方
- UXDより解決領域の近くまで踏み込みたい、システムそのものが好きなデザイナー
- 会議的な場で、ソフトのあり方について具体的な話がしたい開発に関わる人
自己紹介
開発部デザイン課の仕事内容
- ユーザビリティ全般の定義
- 機能の操作方法
- モックアップと画面プロトタイプの作成
- GUIの見た目作成
- 操作方法について利用実態の調査
私について
楽楽精算の上記担当者。入社して１年ちょっとの新米です
関心を持ったきっかけ
ICONIXプロセスを知って関心を持ったことと、UXデザインの文脈で画面プロトタイピングの経験があり、プロトタイピングしながら要求を見つけていく手法の有効さを実感していたので、魅力的に映りました。
期待していること
前工程のあるあるを減らしたい
レビューや打ち合わせで、ボタンのグラデ加減などでなくユーザーに提供する機能と使い心地についての具体的な話がしたい…
ステークホルダーが集まると、各自の職域ごとの異なる単語を使った会話が始まります。これは、しばしば文脈の共有がない悪い意味で抽象的な議論（空中戦）を誘発しがちでした。UI部品の名前や画面のふるまいも、ユーザーの設定やシステムの状態で呼び名が異なり、モックアップを作ってからはじめて「そっちじゃなくてこの画面みたいな機能にしてほしかった」的な話になることは、前工程や問題領域の検討や分析に関わる方なら鉄板のあるあるネタではないでしょうか？
エンジニアとのコミニュケーションのツールがほしい
曖昧な要求の発見がしたい。
コードが書けない以上、可能な限り実装する方には正確なことを伝えようと日々努力しています。しかし考慮漏れやシステムとして曖昧な要求をなくすことは不可能です。
また、文字だけで詳細に記述しきったとしても、そこに書かれていることの矛盾や抜けを見つけるためには読み手に負担を強いることになります。
もし、より早い時点でエンジニアがなんとなくのソフトウェア設計を想定できる情報があったら、もっと良い状況が生まれるんじゃないか、と考えました。
ICONIXプロセスにならい要求とユースケースの発見をしたい
そもそも連携段階で要求が抜け落ちていたり矛盾が露見することも起こります。ドメインモデルをもとにユースケース図と画面プロトタイプを更新し続け、インクリメンタルにドメインモデルを明らかにしてゆくICONIXプロセスは、要求の発見を頭の中でやるより効率的にできる方法なのではないかと期待しました。
メインで使った教材
ユースケース入門―ユーザマニュアルからプログラムを作る
ユースケース駆動開発実践ガイド
知らないこと、考慮しないこと、今回しないこと
- ドメイン駆動設計は未読
- 知識が不十分で権限もないので、モデリング内容を解決領域へ同期すること等は直近で目指していない
- 画面プロトタイピング
ドメインモデルを中心にすえた設計思想として「ドメイン駆動設計」があるようです。３層アーキテクチャそれぞれからドメインロジックを分けて云々は、コーディングできない現時点ではほとんどピンときません。いつか正確に理解したいです。また、ドメインモデルは最終的にクラス図として設計書のひとつになりますが、これは自分だけでは実現できないので検討していません。
準備
座学でお勉強
ユースケース駆動開発実践ガイドのロバストネス図まで読んでいます。ページが少なくてとっつきやすかったのでユースケース入門も読みましたが、前者のほうが実務を想像して読めました。
ツール
- astah* community 古いバージョンなら無償で商用利用OK
- figma プロトタイピングツールです。とても機敏で使いやすい
気をつけることの整理
先に紹介した２冊が明確に注意点を挙げているので、とりあえず覚えます。
- 属性を書かない（ドメインクラスはDBのテーブルではない）
- 多重度も書かない
- 操作も書かない
- バウンダリやGUI部品そのものを配置しない
- 技術的な言葉を極力使わず記述する
- 曖昧なところはユースケース図やロバストネス図を書いていると創発的に明らかになってゆく
要求や要求の素をあつめる
今回はすでに用意済みのものを使いました。
ビジネス側からヒアリングで得たものを整理・分析したものや、B2Cなら質的調査からUXD的な手法で組み立てたTO-BEのユーザーストーリーを使っても良いんじゃないでしょうか。
巨大いちごの出荷システム
- 出荷システムは、生産者の送信した○○と△△と□□のタグ情報を使って伝票を作成できる
- 伝票は出荷担当者がタグの内容と写真を使い検品する
- 検品には、チェックリストを使い、最後にはサイン情報を追加する
- 出荷担当者は出荷リストの更新と業者コードの追加を業務とする
- 検品OKの伝票は、すでにある市場のシステムに連携され、そこから閲覧できる
- 未検品の伝票は市場のシステムに連携しない
やってみた
初回モデル
なんかしっくり来ませんね。伝票は産地情報と写真がないと成立しなさそうなので、業者コードってどこから来たのか謎なのと、なんとなく文章の雰囲気から想像して使った伝票まわりのコンポジションが微妙です。写真はともかく産地情報は伝票がなくなったからといって当然に消えるわけではない気がします。
未検品の伝票を出荷リストが持っているのも釈然としません。それらしい単語としては出てきていない抜け落ちたドメインクラスがある気がします。
出荷リストとチェックリストもどう配置すればいいか決められませんでした。
ドメインモデルを使ってユースケース図を書く
ドメインクラスの名前を使ってユースケース図を書いてみました。
登録機能
現時点ではこれくらいしか思いつきませんでした。写真を撮る機能については都合により割愛します。
伝票管理機能
ドメインモデルで気になっていたチェックリストがここでどんなものか想像できてきました。検品OKの中に送信するためのサインを付ける操作をするには、先にチェックリストを完了する必要があります。また、ドメインモデルで浮いていた業者コードは出荷担当者の持っている業者コードマスタから選んで登録されます。
発見したドメインクラスをドメインモデルに反映
ドメインオブジェクトの洗練と汎化
検品OKが市場のシステムに連携するよう記述した部分は、検品OKは伝票のサブクラスで、ほかの伝票と異なりサインと出荷担当者がOKな状態にしたチェックリストを持つ構造に変更しました。
曖昧さや疑問の発見
-
未検品と検品OK以外の伝票が本当に無いのか気になる -
タグと産地情報の違いが業者の有無しかないが、分ける必要があるのか -
承認情報とか業者コードマスタとか勝手に作ったけどお客さんはOKなのか
考慮しても良さそうな要求
業者コードマスタができてスッキリしたのは良いのですが、業者コードマスタそのものは出荷担当者だけが編集できるのか、生産者も自分で登録できるのか、要求に疑問が出てきました。実運用をイメージすると、出荷担当者以外も生産者を追加できたほうが楽そうな気がします。
業者コードは生産者に自己申請させればタグのドメインクラスが不要になり、便利そうにみえます。
要求レビュー
ステークホルダーとのミーティングなり打ち合わせに、作ったドメインモデルを持ち込みます。少しゴチャゴチャしていたので整理してみました。迅速に検討できるのがこの手法の強みなので、図の整理はこういうタイミングだけにするべきかもしれません。
ドメインモデルで用いる関連は、「is-a」と「part-of」が基本のため、つながりを言葉で読み上げることがかなり容易です。
新たな要求や抜け落ちていたドメインクラスが発見されれば、ドメインモデルは更に確かな問題領域を記述できますし、先の 曖昧さや疑問の発見や考慮しても良さそうな要求を質問として投げかければ、皆が実業務でつかう言葉で具体的な要求を語ることができるはずです。
思うこと
実際に何度か機会があり書いていたのですが、初期の図は「こんなん当たり前だよなあ」と思うレベルでスカスカなのに、ユースケースを書きながら湧いてくる矛盾や抜け落ちたデータの入力方法を検討していると、「勝手に」具体的になっていく過程に驚きます。
1. ドメインモデルを短い言葉にしてレビューで使う。（裏で手作業で同期する）
2. ちょっとだけ小奇麗な見てくれにしたドメインモデルを出してみる
3. 自然なタイミングで未加工の図に切り替えて、しれっと図ありきの議論にする
↑こんな感じで、見る側の苦手意識をやわらげつつ、ドメインモデルを半年とかのスパンで段階的に実業務で活用できたら良いなと思っています。
明日はMasaKuさんの投稿です！