マイペースなRailsおじさん

Ruby、Ruby on Rails、オブジェクト指向設計を主なテーマとして扱います。だんだん大きくなっていくRuby on Rails製プロダクトのメンテナンス性を損なわない方法を考えたり考えなかったりしている人のブログです。

設計について勉強し始めました

私は毎月イテレーションしながら開発しているプロジェクトに参加しています。 メンバーはSIerでSEとして経験を積んできた人が大半を占めています。 明確に設計を行う期間は設けておらず、設計書も作りません。 しかし、コードレビューを受けると、設計が悪い、外部設計を行っていない、基本設計ができていないといった指摘をもらいます。 私はWFでの開発経験が無いので、正直何を言っているかわかりません。 要は、専門用語の壁に阻まれコミュニケーションが取れていない状態です。

という問題を抱えていたので、設計について勉強し始めました。

まだ読んでいる途中ですが、外部設計と内部設計について気になったところをメモします。

外部設計と内部設計

  • 外部設計≒基本設計、機能設計、概要設計
    • 入力と出力を決める
    • ユーザーの振る舞い、外部システムとのメッセージング方法を決める
    • 顧客との合意を反映する
  • 内部設計≒詳細設計、プログラム設計
    • 入力から出力の実現方法を決定する

外部設計では、ユースケース分析、概念モデリングを行う。

  • ユースケース分析
    • システムが提供する機能とユーザーの振る舞いを明確にする
  • 概念モデリング
    • システムが扱うデータの構造を決定する

所感

私が今やっている仕事は実装だと思っていたのですが、実際は要件定義、設計、実装、移行まででした。 決めなければいけないことがバッサリすっぽ抜けいていたのです。 レビューのときにいろいろと指摘が入っていたのはまさに要件定義と外部設計を行っていなかったからでした。 アジャイルな現場においては、要件定義と設計についてもチーム内で議論を進めながらコードを書いていくことになります。私がうまく行っていなかったのは、「合意の上で決めないといけないこと」が何なのかわかっていなかったからでした。

アジャイルな現場にいながらウォーターフォールの設計手法を学ぶことは意味の無い事のように思えていましたが、私に撮ってはとても重要なことでした。 理由は、SIerのチームメンバーとコミュニケーションが円滑に進むようにになることです。これまで、〇〇設計はできているの?と聞かれても、なんのことかわからず、聞いても経験しないとわかんないよ的な答えが返ってくることが多かったのです。要は、決めるべきことは決まっているのか、何を決めるべきか把握しているのかということをチーム内で全く共有できていなかったのです。 設計について学ぶことで、チーム内で話し合うべきことがわかるようになったので、今後はもっとスムーズに仕事を勧めていけるように思います。

追記

途中で読み飛ばしたところもあるものの、全体を読み終えました。
設計について、広く浅く解説された本でした。
なぜ設計が必要なのかについてわかりやすく語られており、まさに「はじめての設計をやり抜く」ための本でした。
この本は設計について学ぶためのガイドとして非常に優秀な本であると思います。