読者です 読者をやめる 読者になる 読者になる

an odd fellow

読書と写真と情報工学

ユースケース駆動開発実践ガイド を読んだ

技術 日記 読書

年明けからバイト先の同僚とユースケース駆動開発実践ガイドの読書会をした。

ユースケース駆動開発実践ガイド

ユースケース駆動開発実践ガイド

きっかけ

僕はバイト先で Web サービスを作っているんだけれど、仕事の進め方に疑問だらけだったのでなんとかしたくて読んだ。

というのも、社長が欲しい機能「こういう感じの機能が欲しい」と伝えられて、僕がなんとなく作ってみたけど、社長が思っていたものと違ったり、社長の中での暗黙の仕様があったりして突っ返されたりなあなあの実装のまま使ってしまったりという現状があまりにも働いていて辛いのでなんとかしたかった。

なんとかしたいとは思っていたんだけど具体的にどうすれば良いのかわからん…という状況の中 NSEG でスクラム体験ワークショップをやるというので参加してきた。

スクラム体験ワークショップ・1DAYプログラム お試し版 午後の部 - 長野ソフトウェア技術者グループ | Doorkeeper

これは本当に行ってよかった。理想的な仕事の進め方だ~~!!と思った。でもスクラムに関してプロがいないとこれはうまく回らん…というのもわかったりして、じゃあどうするって時に、このイベントで講師していた方が「私は一人で仕事することが多いのでスクラムじゃなくて ICONIX で仕事してます」ということを言ってたのを思い出した。

ICONIX プロセスについて調べると小規模のチームで開発するのに向いてるし、実装以前に暗黙の仕様とか無くして全部明言化して且つその過程で設計もできるよってものらしい。

読書会

ICONIX について Google 様にお尋ねすると「ユースケース駆動開発実践ガイド」という本が詳しいと書いてあったので買ってはみたが、ひたすら厚いしひとりでやる気は起きなかったのでバイト先の同僚を誘った。

早めに仕事の進め方をなんとかしたいという思いがあったので、多少無理して週 2,3 回夜に集まって2,3 時間音読するというのをやって、1ヶ月で9章まで読んだ。早いペースだと思う。10章以降は、これ以上はもう読まなくていいねって言ってやめた。

学び

簡単にまとめてしまうと ICONIX プロセスっていうのは以下をやることだった。

  1. 要件からドメインモデルを構築すること
  2. ドメインモデルの言葉を使ってユースケースを記述すること
  3. ユースケースは基本コースと代替えコースだけを書いたシンプルなテンプレートを使うべきで、事前条件や事後条件などだらだらした項目はいらない
  4. ユースケースからロバストネス分析を行って、ロバストネス図を描くこと
  5. ロバストネス分析によってクラスの属性が発見される
  6. ロバストネス図からシーケンス図を描くこと
  7. シーケンス図を描くことでクラスのメソッド(振る舞い)が発見される

以上をやりながらドメインモデルを逐次更新していくと最終的にはユースケースから漏れのない完璧な詳細設計(つまりクラス設計)が出来上がるよ!ということだった。

特にロバストネス分析というのが ICONIX プロセスの核のようだった。一般的な開発だとユースケースからクラス設計をしてしまうが、ユースケースとクラス設計にはギャップがあるしユースケース自体が要件に対して不十分ということもありえるので、これをロバストネス分析によって橋渡しをするらしい。

確かに本を読みながら簡単な例で実践してみると新しいドメインモデルが発見されたりユースケースが洗練された(と思う)。

疑問

わからない箇所がまだ結構あるとも思った。

これはこの本への不満点でもあるんだけど、本の中で例がいくつか挙げられているんだけど、そのロバストネス図の抽象度が毎回異なるというか、すごく細かく分析したロバストネス図もあればざっくりしたロバストネス図が書かれる場合もあって、いったいどの抽象度での分析をすればいいんだ???というのがひとつ。

また本の中では spring framework での例がのっているんだけど、 Symfony だとどう書くんだろう?ううん、もうちょっと書くと、ネイティブアプリでの MVC での例が載っていたけど、これはこのまま Web MVC に適用できないよなあと思っていて、もう少しロバストネス図やシーケンス図の例が見たい!っていうのがある。

あと結局暗黙の仕様を顧客から抽出しないといけなくて、これに関してはこの本では「何度も問いかけろ」とだけあった。これに関しては確かに ICONIX プロセスの保証する範疇外だよなあとは思うので何か別の資料に当たらないとなあと思っている。

なぜ 10 章以降を読まなかったか

9 章までで ICONIX プロセスの本質はすべてカバーできたなあと思った。 10 章以降は詳細設計から実装する箇所で spring framework でどう実装するかという話が主だったように見えたので省略した。

次に読む本

目標は ICONIX プロセスのエッセンスをバイト先で使っている Symfony での開発に導入していい感じに仕事をすすめることなんだけど、Symfony は DDD を推奨しているので DDD をきちんと勉強しないと使いこなせないぞと思っている。なので次は エリックエヴァンスドメイン駆動設計を読もうと思っている。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

うーん、東京のベンチャーとかでバイトしている学生がうらやましい。すでに能力がある人が書いた綺麗な実装を参照しながら新しい機能つくれるんでしょ。設計についてコードから勉強できるのうらやましい。

一方で開発環境の構築からインフラの設計、ソフトウェアの設計、開発と運用全部丸投げされる僕…。各項目に関してまったく知識が無いわけではないけど、理想的な状況というのを文献でしかしらないので、実際やってみると「こういう場合はどうすんだ…」みたいなのめちゃくちゃあって圧倒的に経験不足を思い知る。それにあまり時間をかけずにさっさとやれという圧力もかけられるので、勉強時間を満足に取れずになあなあでいろいろなことを進めてしまって結局なあなあなものができてサービス止まりまくってる。死にたい…。大学院生として本分の研究もあったりして、こちらばかりに時間が取れなかったりもするししんどい…という弱音…

なんのノウハウも無く、知識と経験のある人もおらず…というところから始めるのしんどいお…