ロバストネス図113枚!!

あるシステムについて,その構造を「バウンダリ」「コントローラ」「エンティティ」の関係で示す表記法が,ロバストネス図だ。オブジェクト指向分析,特にユースケース駆動なプロセスにおいて,分析工程の初期から中期にかけて使われるものだ。ユースケースから導き出された各ユースケースフローからクラスを発見することが,ロバストネス分析の目的であり,その過程はロバストネス図として視覚化される。

今日のWebアプリケーションで採用されるアーキテクチャは,そのほとんどが3層構造(View,BusinessLogic,DataAccess)から成り立つ。この構造であれば,ロバストネス図で使用されるステレオタイプがそのまま適用できる。つまり,「バウンダリ」「コントローラ」「エンティティ」は簡単に言ってしまえば,クラスの種類を表すものなので,ロバストネス図を記述することによって,自然と実装に近い設計図を描いていることになる。非常に便利な代物だ。

いま携わっているプロジェクトは,既存システムのリプレースが主目的だ。もちろん機能追加もかなりあるのだが,画面については既存システムのものを踏襲する。つまり,バウンダリについては,画面一覧表とHTMLの紙芝居がほぼ手元にある状態だ。あまり好きではない言葉だが,しいて言えばユーザが触る部分の外部設計が終わっているという感じだ。

顧客の一番の関心事(不安事)は,既に見えている画面ではなく,裏側の処理がどれだけのボリュームなのか?だ。自分たちが作ろうとしているものは,本当に作りきれるものなのか?おまえらは,システムが持つ機能をどれだけ把握しているのか?を知りたがっている。

前にも書いたとおり,出だしでつまずいてしまったおかげで,今は毎日終電である。モチベーションなんて上がりっこない。けれど,そんなことじゃいけないし,顧客は近年まれに見る「まともで積極的な」方々だ。ここは,自分が思っている「理想的な設計像」をちょっとは試してみてもいいのではないか?と思い始めた。

というわけで,システムの機能を洗い出し,各機能について,

  • どの画面を使っていて,

  • どんな処理が必要で,

  • どのDB表を触るのか を導き出すために,ロバストネス図を使うことを考えた。システムを「実装者にふりやすく」「テストしやすい」機能単位に分割し,その機能を満たすための「バウンダリ」「コントローラ」「エンティティ」とその関連を着々図にしていく。もちろん頭の中では,コントローラの処理をイメージして工数を思い浮かべながらの作図である。

本当は一人で行うつもりだったが,さすがに量が見えてくると一人ではつらく思えてきたので,他のメンバーにも手伝ってもらうことにした。

当面2ヶ月間で実装したい機能のみ(全体の約1/3)で,なんと113機能も洗い出せた。プリントの裏紙を使って,手書きで1機能1枚で作っていったので,結果113枚のロバストネス図が出来上がったのである。今まで何度か自分の考えをまとめるために,メモ程度で書いたことはあったが,まともなロバストネス図を100以上も書いたのは初めてだ。しかも,ほぼ1日作業。終わったあとの紙束を見て,感動すら覚えた。

複数人で書くと,ただ図ができただけではなく,いろんなことも見えてくる。正しく仕様を把握していないメンバーの図は,他のメンバーとコントローラの粒度が微妙に違ってきていた。要調整である。しかし,たった1日ちょいで100枚以上を作図できたことは,少なくとも作図に携わったメンバーは仕様の理解度はそこそこ向上していることを示しているはずだし,何よりも今までド短期で行ってきた業務分析が正しかったという証明になっているはずだ。そう信じたい。

明日は,作図の結果導き出された各機能について工数や仕様検討度合いを見積もって,顧客に提示する。そして,イテレーション開発の基準となる「時間単位でどこまで作るのか」を示す。プロジェクトの「山場」になると思う。

無事顧客の理解と合意が取れるか,不安が募る・・・。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて