今回は、自分の失敗談も含めて、UMLのダイアグラムの１つである配置図の必要性について書きたいと思います。UMLの中でも配置図(コンポーネント図）は、１〜３人の少人数の開発になるとついつい省略しがちな図です。
というのも、その規模の開発ですと、仕様の調整、ＦＩＸなどが主な関心事となり、基本設計はテーブル設計くらいで、機能の開発にすぐ入りたくなってしまうからです。
しかし昨年の開発プロジェクトでした経験で、配置図（もしくはコンポーネント図）の作成は、どのような規模でも開発プロセス上、必須であるという考えに至りました。
プログラミングを担当するエンジニアがシステムを開発する際に、注意がまず向くのが機能要件です。機能要件とは、システムで実現したい機能そのもの（例：会員登録など）です。
小規模開発ということで、機能要件だけに目が向きすぎてしまうと、エンジニアはついついWeb(AP)サーバ１台、DBサーバ１台という構成で考えてしまいそのままプログラミングに入ります。
開発用サーバーは、そもそもWebサーバとDBサーバが１台のマシンに入っていることが多いため、そのような頭で開発しても問題なく動きます。
しかし、実際の本番環境は用途別にマシンが用意されることがほとんどです。DBは、マスター（更新系）とスレーブ（参照系）に分かれる。バッチ処理は、バッチ用に別サーバーで動く。などです。DBが２つあれば、プログラム上で使用するデータソースも複数になるため、プログラムの実装にも影響がでます。また、別サーバーでバッチが動くとなれば、Webサーバとは別にライブラリのインストールなどが必要となります。
昨年のプロジェクトでも、複数のデータソース（マスターとスレーブ）がプログラム上で必要ということに気付いたのがプロジェクト終盤となってしまったことがあり、ただでさえ忙しい時期に仕事を増やすこととなってしまい、大いに反省しました。
本番環境でサーバが用途ごとに分かれるなど、何度も経験してきました。しかし、今でも時々やってしまうのです。
開発環境と、本番環境での配置図の違いを示したのが以下の図です。
（図の上半分が開発環境、下半分が、本番環境です）
最後に配置図のメリットを簡単に上げておきます。
・図を作成する過程で非機能要件の検討事項早期摘出に役立つ
（負荷分散、コンポーネントのインストール、ミドルウェア、OS、これらのバージョン、セキュリティなど）
・インフラエンジニアなどとの情報共有
（インフラエンジニアが作成したネットワーク図は、サーバー内にインストールされたコンポーネントへの意識が薄い）
・システム全体（非機能要件）を俯瞰することができる（アーキテクト的視点）
今回の経験を活かし、配置図は必ず作成するようにして行きたいと思います。
今年の目標：１００エントリーまであと９８。
