patorashのブログ

方向性はまだない

UMLでドキュメントを残していきたい

ここ最近、設計書を書くためにPlantUMLを使いたいなと思いたち、ちょこちょこ書いていってたんだけれど、ユースケース図の粒度がこれでいいのか?とか、他のダイアグラムの使い方もいまいちわかってないから最近の本で勉強し直すかーと思って、Amazonでこの本を買った。

基礎からはじめる UML2.4

基礎からはじめる UML2.4

まだ読んでいる途中ではあるけれど、現状分析から設計に落とし込むところまで使えるとは知らなかったのですごく勉強になった。

今までなんとなく使っていたのは、ユースケース図とシーケンス図くらいで、アクティビティ図はフローチャートだろ?みたいな感じだった。 オブジェクト図を使って具体的なオブジェクトを登場させて、必要なクラスを考えていく工程や、アクティビティ図で役割を分けた状態でフローチャートを書いていくことで流れが直感的にわかりやすくなるところなど、めちゃくちゃいいじゃんと思う。

雰囲気で設計をやって手を動かしていくのも経験値を積めていいとは思うのだけれど、そういうふうにして出来上がったものは後から見ると、作った人しかわからないようになってしまう。Railsとかフレームワークを使っていれば、コードをある程度は読めるので、小規模であればまぁまぁわかるのだけれど、規模が大きくなってくるとわかりづらくなる。やっぱり設計書が欲しくなる。

というのも、担当外の製品のコードレビューをすることがあるのだけれど、仕様の機微がわからないから、この変更によって他の機能にこういう影響を与えてしまうんじゃないか?みたいな直感が働かなくて、上っ面のコードレビューになってしまっていることがあって、あまりよくないなと感じている。

なんとなく考えている理想的な開発の流れ

コードレビューが上っ面で終わらないためにも、このような流れにしていきたいなーと考えている。

  1. PlantUMLで設計を行う
  2. PlantUMLの設計が終わったらPull Requestする
  3. レビューを行い、仕様が正しいことを確認する
  4. コードを書く
  5. オブジェクト図を元にテストデータを作成する
  6. テストを作成する
  7. Pull Requestする
  8. レビューを行い、問題なければマージする

UML自体は学習コストも高いし一時的に開発スピードは下がると思うけれど、設計能力は上がるだろうし、なにより共通言語としてUMLが使えるようになったらいいチームになるんじゃないだろうか?という考えがある。社内勉強会とかでUMLの有用性を広めていこうかなと思っている。

そのためにも、来年は既存製品の設計書をUMLに起こしていこうかなと考えている。そうすれば、もし新たにメンバーを加えることになったときも、仕様に対する理解のスピードが早いだろうと思うし。