実は知られていないModel（処理）とView（表示）を分離させる理由

2019/12/27

以前のコラムでMVCのなりたちとファミリー（派生した考え方）について、書かせていただきました。
初心者必見！　知られざるMVCのなりたちとファミリー
皆さんお気づきかもしれませんが、私が紹介したファミリーにはすべて「M」と「V」が入っています。
ではなぜModel（処理）とView（表示）は分けるべき役割として考えられているのか？ということについて、改めて考えてみたいと思います。

プログラムを作る上で・・・

MVCのなりたちとしてGUI開発によって誕生し、普及したと紹介しました。
その中でも書きましたが、GUI開発においてMVCはとても基本的な要素を含んでいます。
例えば、下記のようなGUIの機能を作成するために必要とされる流れなどです。

１．イベント（クリックなど）の発生
２．イベントに対応した処理
３．イベントに対する応答

当然上記を一つのオブジェクトに詰め込んでも機能は作成できますが、以前も紹介した通り、とてもメンテナンス性が低いプログラムになる可能性が高いです。
システムの規模が大きくなれば尚更です。
私の考えではMVCはGUI開発における基本的なこの流れを「最低限必要な役割に分けて、プログラムを構成しましょう」というある意味プログラム作成における「知っておいて損はない一般的なマナー（心構え）」のようなものだと思っています。

少し脱線しますが、皆さんも普段のお仕事などでお客様へ失礼の無いようマナーを意識する機会があると思います。
「この人マナーがなってないな」と思われるのは自分にとってもお客様にとってもあまり良いことでは無いですよね？
プログラム作成でも同様のことが言えると私は思っています。

作成したプログラムは、レビューや引き継ぎ、納品後の改修などで、社内・社外を問わず他人にも
見られる、のはよくあることです。
その際に「なんでこんな造りになっているの？」と思われないために、最低限学んでおくべきマナーの一つではないかと思います。

Model（処理）とView（表示）を分けることのメリット

MVCのメリットとしてよく言われているものに「分業により並行作業ができ、専門家の作業がしやすい」というものがあります。
これは例えばデザイナーとエンジニアが別になっているような案件において、お互いの作業範囲（デザイナーはView、エンジニアはModelなど）がはっきりと分かれるため、作業がしやすくなり、開発効率が上がるということです。

しかし、実は私今まで（10年以上やっていますが）ちゃんとしたデザイナーさんとお仕事をしたことがありません。
なぜかと言うと単に今まで社内で使われる業務システムなどの見栄えより機能が優先される案件をやってきたからなのですが、そういう経歴の私が上記のようなメリットを言っても説得力がないので、私の経験も踏まえ少し別の視点でメリットを説明致します。

皆さんは「結合テストでバグが出すぎて対応しきれない」と言った状況を見たことや経験されたことはありませんか？
そういった状況になると大概はシステムの中枢を担っているような複雑で難しい機能でバグが多発したり、仕様漏れが発覚したり、要望がどんどん追加されたりします。
そうすると何が起こるかと言うと、「ヘルプ」が発生し、複数人で一つの機能のバグ対応を行うということがあります。
こういう時にMVCの考え方で作ってあると次のような良いことがあります。

１．処理のバグ（Model）か表示のバグ（View）かで担当を分けられる
２．プログラム構成がわかりやすいため、他人でもすんなりとバグ解析ができる

「1」は単純に並行してバグを直せるという作業効率的なメリットもありますが、バグを目で見た時点で、ある程度区別できるのでデバッグ作業の担当者を割当てるリーダーもメリットがあります。

「2」は先に記載した「一般的なマナー」にも関連します。
例えば自分の担当範囲外をヘルプする際に、プログラム構成がわかりにくくて解析するだけで時間が過ぎていってしまうと
無駄に時間がかかってしまい、焦りでイライラしてしまいます。
その結果モチベーションが低下し、さらに作業効率が低下していくという最悪の状況になりかねません。
こういった状況を防ぐのにも有効だと思います。

上記は少し視点が狭いように感じますが、作成したプログラムには必ずバグがあり、必ず改修が発生します。
つまり「作って終わり」ということはないので、後で困らないようにする方法の一つとして、ModelとViewを分けておくというのは非常に効果的です。

自分だけでなく、みんなのためのプログラムを書こう

ここまでMVCのメリットを書いてきましたが、MVCのメリットを十分に受けられないのであれば、手間がかかるだけで導入する意味もありません。
ですが、MVCを使わないのであればそれ相応の理由が必要だと思います。
「なぜこのプログラム構成にしたのか？」「MVCにしなかった理由は？」という問いにしっかりと答えられるようにしておくことをお勧めします。
是非皆さんも「みんなが見る」、「みんなが修正する」という視点で自分の作成したプログラムを振り返ってみてください。
新しい発見、改善点が見つかるかもしれません。

この記事を書いた人について

平山和昭

オーシャン・アンド・パートナーズ株式会社　システムエンジニア

顧客をリードし、最適なシステムを構築、提供できる技術者を目指しています。
コラムでは若手技術者向けを中心に今までの経験を踏まえた実際の開発現場で役立つ情報を発信していきます。
プライベートでは家族の足（専属運転手）となり、今ではかねてからやりたかった日々の送り迎えが日課になっています。