この記事はペパボアドベントカレンダー24日の記事です。
前回は@adarapataさんのゲームを作るときに考えていることでした
まえがき
はじめまして yuma300 と申します。仮想通貨界隈ではびっとぶりっとというハンドルネームで活動をしております。
ハンドルネームからもご想像つくかもしれませんが、元々は組み込み系の会社で下回りの開発を長くやっておりました。その組み込み系の会社では研修時にかなり長い時間をかけてUMLモデリングを叩きこまれて、今でもとても役に立っております。その経験を活かしてペパボというWeb業界にきても効率的に開発できてるんじゃないかと自分では思っておりますｗ
ということで今回は実際に開発現場でモデリングをすることで感じたメリットを僕の経験に基づいて書いていこうと思います。実際どのようにモデリングを開発プロセスに取り入れているかについては次回以降の記事で書いていこうと思います。
本文
開発チームでの情報共有がしやすい
実際に実装する前に、どのような実装になるのか開発チーム内で共有することができます。チームで開発するとなると、たいがいコードレビューをするわけですが、コードレビューの段階になって設計レベルで不備や不合理な点がみつかって、設計からやり直すとなると多大な手戻りが発生してしまいます。モデリングをして開発チームで共有することで、実装をする前に設計レベルのレビューができ、コードレビューの段階での設計からやり直すといった手戻りを抑えることができます。
更にコードレビューでコードだけ見せられるより、モデリングした図を見ることでより一層コードの理解が進み、的確かつ速くコードレビューをすることができます。
後から新しい人が開発チームに入ったときもコードを追わなくても、モデリングした図を見ることでどのような事をどこでしているのか把握することができます。
プロダクトオーナーとの仕様調整がしやすい
要求分析をする過程で、プロダクトオーナーの要求が整理されプロダクトオーナー、開発チーム間での認識をあわせることができます。大まかに定義すべき要件が漏れ無くこの段階で決めておけば、実装してから考慮されてないケースに対応するためそれまで実装したものを大幅に変更するという事態を防げます。
シーケンス図やクラス図まで用意するとかなり細かな仕様や制約をプロダクトオーナーと共有することが出来ます。
これらを早期にプロダクトオーナーと共有することで早い段階でプロダクトオーナーからフィードバックを貰うことができます。そのフィードバックには仕様変更も含まれるわけで実装をしてから仕様変更に対応するより、だいぶ効率的です。
プロダクトオーナーへの進捗報告がしやすい
クラス図を用意しておき、実際に実装を開始した後に実装が完了したメソッドやクラスをクラス図上で色分けしておけばプロダクトオーナーに進捗報告をする際、パッと見てどの程度出来上がっているかがわかってもらえます。
実装も大詰めを迎えてリリース期日近くになってきた際に、優先度についてプロダクトオーナーと話しあう際、今の実装状況とその機能を実装するためにどのクラス・メソッドを実装する必要があるのかを照らし合わせながら視覚的に議論することができます。
テスト駆動開発しやすい
モデリングするとなるとたいがいオブジェクト指向設計をすることになるわけですが、よい設計を実現するため当然各クラスは疎結合 高凝集となるようなインタフェースを用意することになります。
モデリングの段階でそれらインタフェースが定義されるので実装の段階ではそれらインタフェースが期待通り動く事を確認するテストコードを用意すればよいことになります。実装にあわせてテストコードを用意するのでなく、まずインタフェースがあってそれが正しく動くテストコードを用意するという流れになるので必然的に効率的にテスト駆動開発ができます。
作業分担しやすい
上で述べた通り、モデリングの段階でインタフェースが定義されているため、それらインタフェースを実装するために必要な作業量や開発チームメンバーの力量を鑑みながら作業を視覚的に割り振る事ができます。
それらインタフェースは粗結合・高凝集になっているため作業がバッティングする心配もほとんどありません。
作業の見積もりがより正確になる
モデリングによりインタフェースが定義されて、どの機能を実装するのにどのような作業が必要になるかより具体的にイメージできるためより正確な見積もりをモデリングの段階でプロダクトオーナーに伝えることができます。
リリース計画を立てやすい
モデリングの段階で機能の優先度と作業量の見積もりを視覚的に把握できるため、どのようにリリースしていくかの計画をプロダクトオーナー、開発チーム双方がしやすくなります。
あとがき
弊社では、基本的にプロダクトは全部内製なので主な利点としてはこれくらいなのですが、受託開発して外部の方々と連携してプロダクトを作る場合は上記に上げた事以外にも様々なメリットがでてきます。
従って弊社では受託開発する場合に比べてモデリングするメリットは少ないのですが、それでもこれらメリットを考えるとモデリングをするのは開発効率アップに多大に寄与すると僕は考えます。
現在僕が所属する部署では開発プロセスにスクラムを取り入れております。
今後の僕の課題としてはモデリングの手法をこの部署でのスクラムに更に最適化していき、社内にもそのノウハウを広げていこうと考えております。
次は@shikakunさんです?