天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

「ユースケース駆動開発をやってみた」に参加してきた

modeling-how-to-learn.connpass.com

今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

オープニング

主催者の増田さんから、会の趣旨について説明がありました。
具体的には、教科書的な説明を重視しているのではなく、現場で実際に教科書通りに実践しようとしたけれど、なかなか上手くいかなくてつまづいた事例などを大事にして話していくということでした。

発表

僕がユースケース駆動開発をする理由~林 宏勝(hiro)さん~

「より良いシステムを作りたい」というモチベーションを強く持ってシステム開発をされているというhiroさんが、より良いシステムの手段としてなぜユースケース駆動開発をするのか?というお話をしてくれました。

hiroさんは、システムを4つに分解(①入出力、②外部連携・永続化処理、③ドメインオブジェクト、④必要な順序で演算を組み合わせする)して考えてみた時に、狭義の意味で言えば、「プログラムを書く」という行為は、④の必要な順序で演算を組み合わせする部分の行為を指しており*1、この実現方法とユースケース駆動開発の相性が非常に良いことがhiroさんのユースケース駆動開発を大事にする理由になっているというお話でした。

また、hiroさんが「プログラムを書く」ことを大事にしている理由としては、hiroさんの「より良いシステムを作りたい」というモチベーションが関わっているということです。
具体的には、「より良いシステム」を作るために最低限守らないといけない条件の一つが、「プログラムが正しいこと(=ユーザがやりたいことがユースケース図で記述されていること)」だと考えているからだというお話でした。

なお、「プログラムを書く(ユースケース駆動開発を推進する)」にあたってhiroさんが大事にされているという、

も紹介されていました。

hiroさんのシステム開発に対するモチベーションの話から始まり、そのモチベーションがユースケース駆動開発でどのようにつながっているか?どのように適用しているか?という部分が最後の数分で一気に明かされていく構成は圧巻でした。

ユースケース駆動開発のワークショップやってみた!~澤井さん~

ユースケース駆動開発をワークショップ形式で学んだ澤井さんから、実際にどのようなワークショップをやって、そこからどんなことが学べたのか?というお話を聴いていきました。

ワークショップの内容紹介では、ドメインエキスパートの方と実際にどのような会話をしたか?や、これらの会話を通してユースケース図を踏まえてモデル図をどのようにアップデートしたのか?ユースケース記述をどのように記載したのか?ロバストネス分析をどのようにしたのか?がストーリー形式で具体的に語られており、ワークを追体験しているような感覚を持ちました。*2

また、ワークショップから得た学びとしては、以下が挙げられていました。個人的にはどれも同感できるもので、納得感がありました。

  • それぞれのプロセスでは完璧に作っているつもりだが、次の工程に行くたびに理解不足が分かった
  • 要求分析が足りないことを実感できた
  • ワイヤーフレームを作ることで、メンバーの共通認識が一気にできた

ユースケース駆動開発で自社プロダクトを作ってみた!~大塚さん~

保守性を高めたい, 要件定義や設計の知識が少ないメンバーのスキルを底上げしたい、という目的から, ユースケース駆動開発を実践された大塚さんが、ユースケース駆動開発を実践して良かったこと・壁にぶつかったことをリアルにお話してくれました。

実践して良かったこととしては、以下のことが挙げられていました。

  • 良くも悪くも画一的な基本設計プロセス(機能一覧→画面仕様書→DB定義書)から脱却できた
  • メンバーの要件定義スキル、基本設計スキルが向上した
  • ロバストネス図ユースケース記述と詳細設計のGapを埋める」という本の記述を、実践を通して強く実感できた

逆に、実践してみて壁にぶつかったこととしては、以下のことが挙げられていました。

  • 本に書かれているをそのまま適用させるのは難しい。
  • モデル定義をドメインモデルではなくエンティティとしていた。
  • 実装段階で設計レベルの変更があったが、ユースケース記述やロバストネス図の考慮もれが起きた。
  • 予備設計期間が長くて飽きが出た(WFでもアジャイル開発でもユースケース駆動開発はできるということなので、今度はアジャイル開発で実施したいというお話でした)

こういった経験談の話は座学だと得にくい部分なので、今回こういったイベントの場で聴くことができて、嬉しかったです。

分析・設計・テストで活きるユースケースシナリオの書き方と使い方~丹賀健一さん~

アリスターコーバーンのシナリオフォーマットの話やアジャイルソフトウェア開発、XPの考え方、RDRA...設計に関連する多数の思想をICONIXと関連させながら、どのような点がICONIXとリンクしているのか?その点を踏まえて丹賀さんがどのように設計を実践しているのか?というお話を聴いていきました。

一つ一つのメッセージが良く整理されていて、メッセージの根拠も分かりやすく、その上メッセージが多数込められた発表だったので、めちゃくちゃ学びが深い発表でした。

以下、自分が特に印象的だった点を挙げていきます。

  • コーバーンのシナリオフォーマット*3を実際に業務でどのように使用しているか?という説明(商品をカートに追加する、という具体例を基に詳細に説明してくれました)
  • シナリオ記述を書く際のポイント*4
  • ユースケース作成は、ステークホルダーの共有経験を獲得するために使用する
  • シナリオのスライスは受入テストに使用する
  • ドメインモデルの正しさをウォークスルーで担保する方法*5
  • ドキュメント0/ドキュメント書きすぎのバランスをどのように取っていくのか?

「参照可能な共有経験」といった言葉をはじめ、一つ一つの言葉がコンパクト且つ印象的な表現で綺麗にまとまっていたのが印象的で、聴いていて心地良い発表でした。

また、有名な技術書の記述を幾つも参照して、それらの記述をどのように理解してどのようにチームに適用したのか?というお話を聴くことが多数聞くことができたのも、個人的には学びが深かったです。(どのように体系的な学びを活かしていったのか、どのように理解してなぜ大切だと思っているのか、というのが聴けたのが有意義でした。)

コード中心からモデル駆動設計へ~増田さん~

最後は主催者の増田さんから、大炎上中に起きたICONIXと出逢い、出逢いから起きた変化の話を聴いていきました。

増田さんは、とんでもない障害が連続するPJの中で、何とか助けを求めるために読書をしていく過程で必要最低限のプロセスで保守性を上げていく設計技法を身に着け、その一つがICONIXだったということです。

ICONIXの素晴らしさに気が付く一方で、ユースケースを見つける難しさや代替コース/コントロールの分かりにくさ、概念モデルとクラスの関係性...難題にぶつかり、ドメインモデルやイミュータブルモデル...現場で役立つ設計技法を実践して今に至るということです。

時間がきつきつだったということもあって、簡単な発表となりましたが、最後にふさわしいエモさあふれる発表でした。

座談会+Q&A

時間が押していて、20分弱位の時間でしたが、ユースケース駆動開発を現場で実践している際の生々しい話や参加者からのQAに答えていきました。

ユースケース駆動開発のリアル

実際には予算の関係やスケジュール制約、品質保証...様々な制約があり、本の通りに実践したりすることはできないよね、という話がやはり大半を占めていました。

ただ、毎回毎回同じ開発スタイルで実験ができなかったり、手慣れた開発者をリーダーにしてその下にメンバーを置いてメンバーを手慣れた開発者のコピーのように育てる、というやり方では、設計のスキルは全くつかないし、メンバーのモチベーションが低いままになってしまうので、どこかで覚悟を持って挑戦しているというお話も出ていました。

実際、泥水をすすりながらソフトウェア開発を進めているという話が登壇者の皆さんから聞けて、

データモデルをICONIXではどのようなタイミングでやっているか?

(勿論これが正解という訳ではないですが)登壇者のみなさんは、最後の方にデータモデルされているという話でした。

全体を通した感想

ユースケース駆動開発の知識や実践経験を手に入る機会がなかなかないので、非常に有意義なイベントでした。
発表では登壇者の皆さんの個性がよく出ていて、リアルな実践話やぶつかった壁、体系的な知識をどのように実践に落とし込んでいるのか?という話が聴けてよかったです。

もっと登壇者の方の座談会を聴いてみたい思いもありましたが笑、密度の濃いイベントでした。次回もタイミング合えば是非参加しようと思います!

*1:プログラムを書くことが一番大事だという話ではないので注意

*2:ゴールまでに着々と前に進むのではなく、途中で生まれた疑問や立ち止まった部分の話までされており、これが追体験をしたような感覚を持った理由なのかな?と思いました

*3:主アクター、支援アクター、設計スコープ、目的レベル、事前条件、主成功シナリオ、拡張、成功時保証...

*4:設計スコープ定義、ユーザの目的レベルにフォーカス、各ステップの主語を明確にする、主シナリオをシンプルに保つ、ユビキタス言語の使用、UIの詳細ではなくアクターの意図を書く、事前条件を書いて冗長な副シナリオを減らす、事後条件はステップとは別の言葉で書く

*5:CRCカードの活用、オブジェクトは自分の責務以外のことはできないことを確認する、オブジェクトがコラボレーター以外と対話できないことを確認する、シナリオの最後のステップに到達したら事後条件を達成できているかを確認する、最後のステップまで到達できなかったり事後条件を達成できなかった場合は、カードを書き換えてリトライする