TL;DR
学生の頃学んで、こんな棒人間が書かれた図の何が役に立つんだと思っていたユースケース図に助けられた
開発者同士の認識合わせ、どう進めるか
関係者が多い案件でそもそも何を作るのか、要件定義をするのが簡単ではない。自分も知らないシステムやマイクロサービスと繋ぐような案件だとなおさら。加えて言語の壁があると輪をかけて準備と工夫が必要になる。
そんな中で取りまとめないといけないことが時折ある。つい最近もそうだった。毎度違う状況ではあるのでその都度どうしようかなと考えている。悩ましい。
今回最終的に用意したのはユースケース図とアクティビティ図。
ユースケース図が意外に役に立ったなというのが今回の振り返り。学生の頃、こんなもん何の役に立つんだとユースケース図書いて思ったもんだけど、やっぱこの粒度で流れと登場人物がすることが一覧で見れると楽なことあるんだな。
棒人間が書いてある図とか、こんなのなくてもシステムなんて作れるんじゃないか、と本気で思ってた。でも、そんなことなかった。すごい先人の知恵だった。
ちなみに今回の案件進めるにあたって、改めてユースケース図やアクティビティ図をどう書けばいいのだろう、というのはこの本が難しすぎず、ちょうど知りたいことが載っていて参考になった。
よくよく考えてみると、実務者向けの要求定義に関する本は初めて読んだ気がする。"かんたんUML入門"は読んでたし、学生の時に勉強したからユースケース図やアクティビティ図はもちろん知っていたけど、実務でちゃんと使おうと思って使ったのは初めて or 記憶ないくらい久方振りだと思う。
ユースケース図が想定してたより役立った
そして、作成したユースケース図は、特に非エンジニアの方への説明で活躍した。どこのシステムの話をしているのか、の説明に作成したユースケース図が役立った。あと、どこのシステム(マイクロサービス)の開発に工数がかかり、人が必要なのか、というあたり。
エンジニア間で全体を俯瞰してどの役割をどのサービスが担当するかの認識合わせにも役立った。設計前の段階で、大まかな全体像と開発規模感を掴むにはちょうどよかった。
当然と言えば当然の結果だが、ユースケース図は役に立った。学生の時以来久しぶりにちゃんと真面目に書いたんだけど、まさかこんなにみんなに見られるとは。書いた甲斐があった。
まあ、ほんとに正しいユースケース図の使い方であったかはわからないけど、関係者との対話の中心になる一枚絵を用意できた、という意味でこれ以上役立つものはその時点で他になかったからよかった。
アクティビティ図にも助けられた
作成したアクテビティ図は、エンジニア間での詳細設計前の認識合わせに役立った。どこのサービスが何するんだっけ、というのを詳細な設計を各担当がする前に話すことができた。
これは個人的に感じたことだが、たまたま対象のシステムに詳しくない僕がいろいろ図を書いたものだから、さまざまな関係者から修正の指摘をもらえた。手を煩わせたとは思うが、相手をいらつかせるような間違いのある資料を作っているのではなくて、ここはちょうど認識合わせが必要そうだ、という箇所でツッコミどころのある資料を作っていた。バランスの問題もあるとは思うが、これはこれで良かったように思う。
まとめ
僕個人は、毎回参加するプロジェクトや案件で状況が違ったり、僕に期待される役割が違うから、その時々、目の前の課題を解決するのにはどんな資料用意したらいいんだろうか、と考えてしまう。今回はたまたまユースケース図とアクティビティ図が綺麗にワークした。
経験値のある関係者ばかりだったが、みんなそれぞれになんとなく担当するだろうシステムを思い描いていた。そして、そのすり合わせを早くして、スケジュールの叩き台を作らねば、というのが目下の課題であった。力量のある人ばかりだけど、みんなが同じベクトルを向くようにすることは簡単ではない。言語の壁あるとなおさら。
今回も、なにが必要かなんだろうなと思いながらユースケース図を何度もアップデートし、概ね認識が合ってきたらアクティビティ図を仕上げていった。
目下の課題については、とりあえずうまく解決できた。よかったよかった。
今後のことや感想など
LLMでうまく楽できないかなーと合間を見て考えてはいたんだけど、結局は自分で図を書いてしまった。スラックや打ち合わせの議事録などをinputにしてうまく必要なUMLでもなんでも作ってくれると嬉しいけど、まだそういうところまでは研究進んでないんだろうか。パッと思いつくくらいだから誰かやってそうだけども。
LLMの利用は何かしたいから、せっかく作ったユースケース図とアクティビティ図を使って、これから作るだろうテストケースを使ってトレーサビリティとかの観点で利用を考えるのはしてみようかな。また考えよう。終わり。
