【イベントレポート】ソフトウェアの変更・修正が劇的に楽になる！「現場で役立つシステム設計の原則」

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

7月14日に行われたイベントは、人気書籍『現場で役立つシステム設計の原則』の著者である増田亨さんをお招きした同名のセミナー。システムにおけるプログラムの変更を「楽で安全に」実施するための原則、手法を解説していただきました。その様子をお届けします。

■今回のイベントのポイントは……

・変更しやすくなる設計は「どこに何が書かれているかわかる」こと
・実践的なオブジェクト指向プログラミングは、「データ」と「ロジック」を一体にする
・分析しながら設計し、設計しながら分析する。そのサイクルを短くして何度も繰り返す

「動けばいい」というソフトウェアではなく、後の変更がしやすいように設計を組むのがプロフェッショナルの仕事。「ソースコードが書ける」だけではない、一段上のスキルをぜひ身につけましょう。

▲【講師】増田亨さん
有限会社システム設計代表。ギルドワークス株式会社取締役。業務アプリケーションのアーキテクト。日本最大級の60万件以上の求人情報キャリア「イーキャリアJobSearch」の主任設計者。ビジネスの関心事を正しく理解し、顧客に価値あるソフトウェアを届けるために、日々「ドメイン駆動設計」を実践している。著書に『現場で役立つシステム設計の原則～変更を楽で安全にするオブジェクト指向の実践技法』（技術評論社）がある。

変更が大変なソフトウェアは、何が問題なのか？

ソフトウェアの開発において、稼働後の「変更」に大変な思いをしたことはないでしょうか？最近では、いったん作ったソフトウェアを変更せずに使い続けるという運用は考えづらく、次々と修正や拡張をしていくのは当たり前です。

変更の際に「思わぬところに影響が出てしまった」「影響範囲を判別するために工数の大半を使う」など、スムーズに修正できないという問題があります。「その問題を何とかしたくてこの本を書いた」と増田さんは言います。

「最初から変更がしやすいようにソフトウェアを開発することが、システム設計の価値でしょう。修正や拡張を楽で安全にする設計原則を、私なりの経験から解説していきます。20年ほど前の“バズワード”とも言える『オブジェクト指向プログラミング』という概念を、さらに実践的にしたものです」

増田さんが言うには、変更が必要以上に大変になるソフトウェアには次のような特徴があるそうです。

・どこに何が書いてあるか理解するまでが大変
・ちょっとした変更なのにあちこちの修正が必要
・思わぬ箇所に変更の副作用が起きる
・テストをしたはずなのに後からバグが発生する

「例えば、変更自体は単純なはずの『消費税率を変える』という修正の場合でも、1箇所を直すだけで済まないケースが多い。動いている業務アプリは複雑で、あちこちで丸め計算など似たような処理が書かれており、すべて調べなくてはならないのです。また、十分に調べてテストしたつもりでも、業務を動かすとどこかで数字が合わなくなるなど、思わぬ箇所に副作用が起きることがあります」

データとロジックを一体にするのが大きなポイント

変更を楽で安全にするためには、どこに何が書いてあるかわかりやすく、見つけやすくすることが求められます。また、変更の影響を狭い範囲に閉じ込める必要があります。先ほどの消費税率の例で言えば、税率に関するデータとロジックはひとまとめにしておくということです。

データとは、「数値」や「日付」「文字」などのことで「金額」や「有効期限」「電話番号」などに使われます。対してロジックは、「金額」なら「合計や小数点以下の端数計算」「3桁ごとのカンマ編集」「千円単位に丸めて表示」といった判断／加工／計算からなるものです。

このデータとロジックを、オブジェクト指向プログラミングでいう「クラス」を使って同じ場所に置くことが大切です。

ひとまとめにする際には、「人の関心事（＝クライアントの要件）」と「プログラミング単位（＝クラスやパッケージ）」を一致させます。例えば、「年齢」について修正があるなら、「年齢クラス」だけを確認すればいいようにします。そうすることにより、「注文受け付け時にシステムの中では何をしているか」などと探し回る必要がなくなります。関心事をクラス名にしてデータとロジックを閉じ込めておけば、変更の範囲もそのクラス内だけで完結します。

ドメインオブジェクトを理解する

業務に使われる用語に合わせて、その関心事に対応するクラスを「ドメインオブジェクト」と呼びます。その中には、次のようなものがあります。

・値オブジェクト
・コレクションオブジェクト
・区分オブジェクト

「値オブジェクト」は、まさに関心事とプログラミング単位（クラス）を一致させるためのもので、具体的には「金額」「通貨」「予定日」「電話番号」などがあるでしょう。

「コレクションオブジェクト」は、ファーストクラスコレクションとも呼ばれ、配列やコレクション型のデータとロジックを持つクラスのこと。「購入履歴」や「商品カタログ」「在庫」などが挙げられます。購入履歴のクラスなら、合計金額や最新の購入などのロジックが入ります。つまり購入履歴のことならこのクラスを変更するだけでよいのです。

「区分オブジェクト」は、ロジックを区分ごとに分ける方法。例えば、「料金」を計算する際に子どもや大人、シーズンなどの複雑なロジックがあるとき、それぞれを別のクラスに分けます。Java言語では、インタフェース宣言を使って、異なるクラスを同じ型として扱うことができます。複雑な料金計算だからといって「if文の巣」になってしまうと、修正や拡張が大変なだけでなく、テストに不安も伴います。それを避けるための仕組みです。

また、クラスをひとまとまりにする「パッケージ」も活用します。例えば、「販売可能数量」「数量」「数量単位」などのクラスをひとつの「数量パッケージ」としてまとめておけば、数量に関して他の部分をチェックしなくても済みます。

その他、データモデルとオブジェクトモデルの違い、書籍で詳しく解説している「三層＋ドメインモデル」の説明、オブジェクトとテーブルのマッピングについても紹介されました。続いて、開発プロセスについて言及していきます。

ウォーターフォールとアジャイル、それぞれの欠点

過去に主流だった、開発のV字モデル、ウォーターフォール型とも呼ばれる開発の仕方は、要件定義から受け入れテストまでのそれぞれをフェーズに分け、たった1回のサイクルで本番環境を構築するものでした。ところが、「一発勝負の仕方が問題」だと増田さんは言います。

「フェーズごとに別の担当者や別の会社が担当します。専門用語も違い、伝言ゲームのようになってしまいます。それでは上手く伝わるわけはないのです。大抵、開発プロセスの後半でスケジュールが間に合わず、火を噴くことになります。
また、昔なら、給与計算をするソフトウェアを作ったら、しばらく給与体系が変わらないので安定して使えていました。開発に数年をかけても使えたわけです。ところが、今は雇用形態や年金制度、手当もどんどん変わっていきます。現在のルールで何年も使い続けられることはあり得ません。昔のような作り方では、時代の流れについていけないのです」

ウォーターフォールと逆のアプローチで、小さく早く開発していくのがアジャイルです。実装と受け入れテストを短いサイクルで繰り返すもので、新規サービスやスタートアップなどに活用されることがありますが、「みんな苦しんでいる」と増田さん。

「事業が立ち上がるのは早いのですが、サービスがうまくいって機能を追加する際にどんどん開発スピードが落ちていきます。どこを変更すればいいのかが見えなくなってしまうのです。ここ2～3年、特に相談が増えています」

オブジェクト指向の開発プロセス

そこで現在、増田さんが進めているのは、アジャイルに近い「オブジェクト指向の開発モデル」。サイクルを何度も回すのはアジャイルに似ていますが、要件定義から実装、受け入れテストのフェーズをすべて行っていく点が異なります。

「具体的には、朝に要件定義をしたら、夕方には画面を叩いて確認するような作り方です。要件を聞きながら、議事録の代わりにクラスやパッケージを書きます」

これまで話してきたように、人の関心事（＝クライアントの要件）とプログラミング単位（＝クラスやパッケージ）を一致させるため、分析・設計・実装を一貫した活動にできるのです。スキルや経験が足りない場合には「議事録代わりにソースコードファイルに書くことを徹底するだけで相当変わる」と増田さんは実感しています。

今回のセミナーのまとめとして、以下の項目を再度確認しておきましょう。

・データとロジックを一体にする
・人の関心事とプログラミング単位を一致させる
・分析・設計・実装を一貫した活動にする

あくまでこれは、増田さんが開発の現場で試行錯誤している「現時点での中間報告」とのこと。現場では、例外的なことが多発するため、すべてが理想的通りには進みません。それでも、できるだけ徹底して進めることが大切です。