ユースケース駆動開発BootCampはじめました

昨日のこととなりますが、札幌でソフトウェアの開発プロセスの１つであるICONIXをテーマとした勉強会を開催しました。ユースケース駆動開発BootCampという名称で、TDDBCの派生です。本家TDDBCと同様に、午前中は講演中心の座学、午後から演習で実際に手を動かして体験してみるというスタイルの勉強会です。最近はこの手の体験型勉強会がテスト駆動開発などを中心に広がりつつあるような気がします。

開催の経緯

実は３年ほど前に札幌Javaコミュニティを立ち上げた時、最初の頃に行っていたのが「ユースケース駆動開発実践ガイド」の読書会でした。この本は、ユースケース駆動開発に関してICONIXというプロセスを紹介しながら解説する本です。その後、自分としても関連したプロジェクトにユースケース駆動開発のエッセンスは取り入れるように取り組んでおり、一定の成果があったと感じております。そこで、このプロセスを広めたいという想いもあり、ちょうど去年の末から取り組んでいるTDDBCとうまくリンクできそうだという目論見もあって、今回のUcDDBCの企画を立てました。

ユースケース駆動開発実践ガイド (OOP Foundations)

ICONIXとは

軽量なソフトウェア開発プロセスであり、歴史としてはアジャイルよりも古い時代からあります。その後、アジャイル的なプラクティスを取り入れながら今に至るという歴史を持っていますが、特徴としてレビューやドキュメントを重視するプロセスでありながら、アジャイル的に反復的で柔軟なプロセスであると言えます。
ICONIXはユースケース駆動開発を実践するための１つの手段であり、精度の高いユースケースを書く事が基本ポリシーです。しかし、良いユースケースとは何かという点について、それが実装にリンクしていなければならないという点をあげています。このため、システム化可能かどうかを検証する目的でロバストネス分析を行います。最終的に作成されるソースコードとユースケースのトレーサビリティを高める事により、より精度の高い見積や進捗管理が出来る点がポイントです。

午前中の講演

今回のBootCampでは、午前中にICONIXについて２時間ほど説明を行い、午後から演習となりました。講演の資料はこちらに公開していますので、興味のある方はご覧ください（ただし140頁くらいあります）。

UcDDBootCampSap0.1

View more presentations from Shuji Watanabe

午後の演習

午後の演習は、参加者の様子もわからなかったため、手探りで行いました。題材としては、「会議室予約システム」という簡単なものを用意し、Trac（Kanon）を使ってユースケースを書く演習を３人１チームで行いました（最終的な参加者は９名＋自分）。
1つ目の課題は、ユースケースの一覧を抽出するという作業です。大まかな要件が与えられていたので、そこから必要と思われるユースケースを抽出していきます。３０分ほどで抽出し、その後にプロジェクタで投影しながらレビューを行いました。ユースケースの一覧を抽出することは、システム全体を把握するという意味では非常に重要な工程になります。
最初のお題は「会議室を登録する」というユースケースについて、３チームでそれぞれ書きます。やはり慣れていないところもあり、戸惑いながら書いていたようです。３０分ほどでレビューの時間としました。レビューではプロジェクタにそれぞれのチームのユースケースを映し出し、ディスカッション形式で良い点や悪い点などを指摘しました。
ここで、ロバストネス分析になるのですが、いきなり演習を行うのも難しいと判断し、ロバストネス分析のデモを行います。上で作成した「会議室を登録する」というユースケースについてロバストネス図を作りながら、修正を行いました。この部分は今日のBootCampでの一番の肝かと思われます。
最後に各チームで１つづつ別のユースケースを選択し、ロバストネス図を意識しながらユースケースの作成を行いました。こちらも３０分程度で止め、相互レビューを行います。2回目ということもあり、ある程度は慣れてきたという感じですが、用語のブレや外部システムの存在など、細かい部分で新しい指摘があり、興味深い感じでした。
最後に全体を通しての振り返りを行い演習は終了です。全体を通しての成果物は、こちらから確認できます。

感想と反省

今回は試験的な部分もあり、10:00〜17:00で実質５時間半程度の開催となりました。その中で講演が2時間半、演習が3時間程度です。まずは、可能な限り講演を圧縮し、1時間半程度に抑えたいところです。一方、プロセス全体を説明しなければ、一部だけのノウハウを話しても中々伝わりにくいので、悩ましい部分でもあります。まずは2時間以内を目安としたいかと思います。
演習ですがTDDBCと同様に「慣れてきたところでタイムアップ」的な感じは否めません。また、今回はロバストネス分析は簡単にやった程度であり、ドメインモデリングやシーケンス図の作成などはやれませんでした。単純に時間を追加すればある程度は増やせるかもしれませんが、うまくまとまるような工夫をしたい所です。
参加者からの感想としては、全体的におおむね好評で、開催して良かったと思います。特にユースケースなどのUMLは何となく解るけど実際の開発への効果的な適用方法についてみえてきたなど、実業務に生かせそうだなという感想が多かったのは嬉しい限りです。講演の中でも話しましたが、ICONIXは全工程を完全に適用する必要は（自分は）ないと思っています。質の高いユースケースを書く訓練として、ICONIXを学ぶ事は十分な効果を出すと思っています。比較的にウォーターフォールに近い要素も多いので、提案の仕方によっては実業務を上手く改善できる可能性もあると思います。

次回に向けて

ユースケース駆動開発もTDDと同様に訓練すれば身につけられるスキルだと思います。そのためには1回だけ参加するのではなく、何回か参加し、そして会社で周りに教えられる状態になることが重要かと考えます。なので、今後も継続して開催していきたいです。お呼びがかかれば札幌以外でもやりたいですね。

そして、TDDBC

実はICONIXを使いロバストネス分析を行っていくと、抽出されるコントローラはオブジェクトの主要なメッセージとなります。Javaであればインターフェイスに近い部分です。したがって、ICONIXでは各コントローラに対してユニットテストを行う事が推奨されています。
つまり、このコントローラというのはTDDを行う非常に都合の良い単位と言えるのです。もう少し細かく言えば、BDDの範囲でしょう。コントローラ「例）検索条件から商品一覧を取得する」という振る舞いに対しテストを先に作り（BDD）、内部で使う細かいモジュールをTDDを使って組み立てていくという流れが理想と思っています。
TDDは開発の中で実装にフォーカスを当てたスキルです。それはとても重要ですが、「どこを基点にTDDしたらいいのか解らない」という状態になっていることはないでしょうか？そんな人は是非ユースケース駆動開発（ICONIX）を学ぶと１つの答えは見えてくるのではないかと思います。そして、UcDDBCとTDDBCを合わせて３日間のトレーニングとか出来たら面白いですね！

おまけ

Togetterのまとめはこちらです。