設計その後

画面設計、処理設計、チェック条件、メッセージ一覧等の整理で今週は終わりました。主に外部設計が中心でいくつか内部設計に入って終わりっという感じでしょうか。
基本的な作業の進め方を説明し、後は勝手にメンバーが各自の分担作業に着手し、適宜途中段階で私がレビューするという作業方針を打ち立てましたが、思いのほか、これがうまくいっています。なぜか？と考えると、以下の2点につきると思います。

• 設計の考え方やドキュメント作成の手順が比較的わかりやすかった
• 早い段階でのレビューにより正しい方向へアジャストされることで新人たちが常に前に進んでいるように感じてくれている（つまり、自分の行動が間違っていないと自信を持てるようになる）

まず設計が簡単だったというのは、設計するアプリケーションがマスタメンテ系であり、かつ、DB設計がすでに完了しているということが前提となっています。で、その上でクラスがどうだ、関連がどうだ、というのではなく、画面、画面上でのイベント（操作）、データの流れの3点についてできる限りはっきりと明確にするという指針で設計を指導していきました。当然のことながら、アウトプットとなる設計書はこうで、これを作るために考えるポイントはこれこれで、設計の基本的な進め方はこうだよ、っていうのを細かく指導しないといけません。
で、今回思いのほか効果があったのがデータの流れを「おしごとマジカ（特におしごとパズル）」を参考に作成したシートでした。と言っても、ほんとに単純で前画面→処理１→・・・処理n→次画面という一連の操作の流れをすべて紙に張り出し、その間でいきかうデータも書くということ。
まぁ本当に昔流行っていたデータ中心アプローチをただ紙の上でやっているってだけなのですが(w
で、「お！？」と思ったのはメンバー自身で設計書中の漏れを発見できたことでした。一番うれしかったのはスキル的に弱いメンバーがちゃんと紙の上で問題点をいくつも指摘できた時です。あぁ、やっぱりわかりやすいやり方でちゃんと物事を表現できると効果があるなぁと思った瞬間でした。つまりは「おしごとマジカ」すげぇー！！ってことです(w
やっぱり業務アプリってデータの流れに着目するのが重要なんじゃないか？と再認識した1週間でした。
来週からは内部設計〜製造と移っていくことにより、もう少し考えることや気にしなければならないことが増えてくるので、それをどう整理して指導していくかが課題です。が、Goyaベースのアプローチににしたがってやればクラス設計とかで迷うこともないし楽っちゃ楽ですね。
ちなみに他２チームでマスメン系の開発で一般的なオブジェクト指向設計を新人にさせるように指導者が指示しています。で、現状ではハードルが高いようでなかなか進まないようです。やっぱり概念レベルでのクラス抽出は経験をつまないとねぇ。厳しいですよ。やっぱ難しいもん。
つーか、マスメン系でオブジェクト指向設計をする意味があるのか一番不思議だったりしますが。