保守運用コストを軽減。開発手法「デザインパターン」の利用例をご紹介

 

Webサイト・システムを作って満足していませんか？

Webサイト・システムは作って終わりではなく、作ってからがスタートです。

公開後も、バグ対応や機能開発・関連システムとの連携対応など繰り返し保守運用を行うことが必要となります。
特に企業の基幹となる業務を管理する「基幹システム」では、10年、20年、さらに長期に渡って保守開発を続けることも珍しくありません。

公開後もバグが発生しにくいつくりになっているWebサイト・システムの状態を「保守性が高い」状態であると言います。
長期にわたる保守を見据え初期開発の時点から保守性を高めないと、Webサイト・システムの品質を保つことが難しくなります。
例えば「スパゲッティコード」と呼ばれる煩雑で読みにくいソースコードや、影響調査が困難なソースコード、改修の影響が広範囲に広がってしまうソースコードを書いてしまうと、保守開発の際に新たなバグが発生するリスクが高くなってしまいます。
保守性が低いことはすなわち、事前の影響調査やテストなどに多くの工数を費やすことにつながる、ということです。低コスト・高品質の保守開発を実現するためには、保守性の高いシステムを開発する必要があります。

Webサイト・システムの保守運用を容易にし保守性が高い状態とするためには様々な手段があり、その一つに設計ノウハウを再利用しやすい形にパターン化する、デザインパターンという手段があります。

この記事では保守運用の一例として、デザインパターンの説明や使用例などを紹介していきます。

この記事の執筆者
東京のWeb制作会社　株式会社サービシンク　エンジニア

このコラムでは、制作実績でご紹介できないようなWeb技術の活用例をご紹介し、「サービシンクは何を得意としているの？」 「サービシンクに依頼すると何をしてくれるの？」という疑問を解決いたします。
詳細のサービス内容は下記のリンクからご確認ください。
サービス｜ホームページ制作・Web制作会社 サービシンク（東京）

 

 

 

保守性の高いWebサイト・システムを作るには

保守運用をしていくためには、「保守性の高いコード」を書いていくことが必要です。
「保守性の高いコード」は例えば下記のような特徴を持っています。

• 可読性が高い
• 変更に強い

上記のような保守性の高いコードを書くために重要となるポイントをご紹介します。

 

可読性の高いコードを書く

下記を心がけることで、可読性の高いコーディングとすることができます。

変更に強い設計にする

変更に伴う影響範囲を限定しやすくするための設計手法を取り入れると、変更に強い設計にすることができます。
設計手法には、「データ中心アプローチ」「プロセス中心アプローチ」「オブジェクト指向アプローチ」といった種類があります。

「データ中心アプローチ」とは業務で使われるデータを明確化し、それに従ってシステム機能を設計する考え方です。
「プロセス中心アプローチ」とは業務手順やデータの流れに注目し機能要件を定めていくシステム設計の考え方でデータ中心アプローチの対義語として用いられます。
「オブジェクト指向アプローチ」に関してはデザインパターンの考え方を取り入れることで、変更に強い設計とすることができます。
ここではオブジェクト指向のデザインパターンについて紹介していきます。

 

デザインパターンとは

「デザインパターン」は、Wikipediaでは下記のように定義されています

ソフトウェア開発におけるデザインパターン（型紙または設計パターン、英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。（Wikipediaより）

つまり、よく出会う問題に対してのGOODな設計パターン集のことです。

デザインパターンと言ってもいろいろありますが、最も有名なものはGoF（Gang of Four）のデザインパターンです。「生成」「構造」「振る舞い」の3つに分類された、23のパターンがあります。

GoFのデザインパターンについて、それぞれどのようなパターンかの概要をご紹介します。

 

オブジェクトの生成に関するパターン

オブジェクトの構造に関するパターン

オブジェクトの振る舞いに関するパターン

 

デザインパターンの使用例

GoFのデザインパターンは具体的にどのように使われるのでしょうか。
23種あるGoFのデザインパターンすべての使用例をご紹介すると長くなってしまうため、その中から「TemplateMethodパターン」を取り上げ実例を交えながらご紹介します。

TemplateMethodパターンの使用例

異なる色のペンや、筆・マーカーなどを用いても同じ形式にする「テンプレート」になぞらえて、スーパークラスで処理の枠組みを決め、サブクラスで具体的な内容を定めるデザインパターンをTemplateMethodパターンと呼びます。

TemplateMethodのクラス図

• AbstractClassで抽象メソッドの宣言、TemplateMethodの実装
• ConcreteClassで抽象メソッドの実装

実際のコード

TemplateMethodパターン適用前

「コーヒーを作る」

<?php

class Coffee 
{
    public function makeCoffee() 
    {
        echo 'コーヒーを作る。\n';
    }

    public function boilWater() 
    {
        echo'お湯を沸かす。\n';
    } 

    public function brew() 
    {
        echo 'コーヒー豆を挽き、ドリップする。\n';
    }

    public function pourInCup() 
    {
        echo 'カップに注ぐ。\n';
    }

    public function addContents() 
    {
        echo '砂糖とミルクを足す。\n';
    }

    public function makeDrink() 
    {
        $this->makeCoffee();
        $this->boilWater();
        $this->brew();
        $this->pourInCup();
        $this->addContents();
    }
}

「紅茶を作る」

<?php

class Tea 
{
    public function makeTea() 
    {
        echo "紅茶を作る。\n";
    }

    public function boilWater() 
    {
        echo "お湯を沸かす。\n";
    } 

    public function brew() 
    {
        echo "ティーバッグを浸す。\n";
    }

    public function pourInCup() 
    {
        echo "カップに注ぐ。\n";
    }

    public function addContents() 
    {
        echo "レモンを足す。\n";
    }

    public function makeDrink() 
    {
        $this->makeTea();
        $this->boilWater();
        $this->brew();
        $this->pourInCup();
        $this->addContents();
    }
}

見比べてみると同じ項目「お湯を沸かす」「カップに注ぐ」があります。これら重複する項目を共通化し、テンプレートとするのがTemplateMethodパターンです。
TemplateMethodパターンで書くと下記のようになります。

TemplateMethodパターン適用後

AbstractClass（抽象クラス）

// CaffeineDrink.php

<?php

abstract class CaffeineDrink 
{
    /**
     *  各クラスの共通の処理
     * 
     * @param string $drink_name
     */
    public function drinkDetail(string $drink_name) 
    {
        echo "【" . $drink_name . "を作る】\n";
    }

    public function boilWater() 
    {
        echo "お湯を沸かす\n";
    }

    public function pourInCup() 
    {
        echo "カップに注ぐ\n";
    }

    /**
     *  各クラスによって異なる処理。抽象クラスとして定義
     *  中身はサブクラスで実装
     */
    abstract protected function brew();

    abstract protected function addContents();

    /**
     *  TemplateMethod
     */
    public function makeDrink($drink_name) 
    {
        //一連の動作を定義
        $this->drinkDetail($drink_name);
        $this->boilWater();
        $this->brew();
        $this->pourInCup();  
        $this->addContents();
    }
}

ConcreteClass（具象クラス）

// makedrink.php

<?php
require_once 'CaffeineDrink.php';

class Coffee extends CaffeineDrink 
{

    /**
     * それぞれのクラス独自の処理のみを実装する
     */

    protected function brew() 
    {
        echo "コーヒー豆を挽き、ドリップする\n";
    }

    protected function addContents() 
    {
        echo "砂糖とミルクを足す\n";
    }
}

class Tea extends CaffeineDrink 
{
    /**
     * それぞれのクラス独自の処理のみを実装する
     */
    
    protected function brew() 
    {
        echo "ティーバッグを浸す\n";
    }

    protected function addContents() 
    {
        echo "レモンを足す\n";
    }
}

実行結果

// client.php

<?php

require_once 'makedrink.php';

$coffee = new Coffee();
$coffee->makeDrink('コーヒー');

$tea = new Tea();
$tea->makeDrink('紅茶');

------------------------------
【コーヒーを作る】
お湯を沸かす
コーヒー豆を挽き、ドリップする
カップに注ぐ
砂糖とミルクを足す
【紅茶を作る】
お湯を沸かす
ティーバックを浸す
カップに注ぐ
レモンを足す

重複する項目を「抽象クラス」として共通化することにより、「具象クラス」で呼び出す処理のみを行えばよくなり、コードを簡略化することができました。

また、もしこの実装に共通化した親クラスを利用できる「ココアを作る」を足すとなった場合でも、ココアのための独自の処理を「抽象クラス」に追加し「具象クラス」で呼び出すコードを書けばよいため、あとから入った変更であってもコードを複雑にせず、簡潔に追加することが可能です。

 

デザインパターンのメリット・デメリット

実例でご紹介したように、デザインパターンの手法を取り入れることには以下のようなメリットがあります。

• 保守性を高めることができる
  • ソフトウェアの変更が簡潔にできるようになる
  • コードの内容が理解しやすくなる
• チーム・開発者同士のコミュニケーションが円滑になり、時間的コストを減らすことができる

反対に、デザインパターンの手法を取り入れることのデメリットは

• デザインパターンを理解していない開発者だと対応ができない
• 複雑ではない開発には向かない
  （上記で挙げたTemplateMethodパターンでいうと、共通処理が「お湯を沸かす」しかないコーヒーとカップラーメンに適応した時、ほとんど共通化できないのに親クラスが無駄に1つ増えてしまいます。
  デザインパターンは例えば検索項目が多いWebサイトや機能の多いシステムなど、ある程度複雑な場合などに適用するのが良いでしょう。）

 

開発段階から公開後の運用を見据えることで運用コスト・負担の軽減を

ご紹介した「デザインパターン」のような開発手法を取り入れることで、Webサイト・システムの保守運用の運用コスト軽減・負担軽減につなげることができます。これらのメリットは開発に携わるエンジニアにはもちろん有効ですが、依頼する制作会社がこのような手法を取り入れているかどうかで担当者さまの負担軽減にもつながるでしょう。

公開前から保守運用に有効な技術・観点を重視した開発をすることで、公開後もスピード感を持ってお客様に納品をすることができ、運用コストが過剰にかさむことを防ぐことができます。これらの技術や観点を持って運用時を見通した開発ができることが、サービシンクが保守運用サービスに自信を持つ理由の一つです。
大型システムの開発から6年以上にわたり開発保守をお任せ頂いているプロジェクトの実績もあり、大手不動産会社をはじめとした企業様とご一緒した経験からの知見も豊富です。

これまで費用が安くシステム開発に不慣れな制作会社に発注したために、1から要件定義をやり直したり、公開後の制作会社との調整で疲弊してしまった経験があるご担当者様も中にはいるのではないでしょうか。
Webサイト・システムの依頼をする際には、公開だけをゴールにせず、開発時から保守運用を重視した開発ができる制作会社への依頼をしてみませんか。その際にはぜひサービシンクをご検討ください。