Ivar Jacobson『Object Oriented Software Design』

五島で読んだ本。大阪ハーフマラソンへ向かう時は旅のお供。今は遥か彼方、三島にあるコピー。手元には本はないが、メモを参考に振り返りをする。

『Object Oriented Software Design』との出会いは、『Clean Architecture』の著者、ロバート・マーティン、通称アンクル・ロブが、YouTubeにアップされている動画で毎回、同書を紹介していたこと。同書以外もいくつか本は紹介をしているが、この本だけはプレゼン資料の1スライドとして紹介されていた。

同書のサブタイトルは「A Use Case Driven Approach」。Clean Architectureの「use case」層という概念は、この本に記載されていることがお手本になっている。

オブジェクト指向ソフトウェアデザインとオブジェクト指向プログラミング言語は違う。オブジェクト指向プログラミング言語を使って、ソフトウェア開発をすれば、プロダクトはオブジェクト指向ソフトウェアデザインの結果となりそうだが、必ずしもそうではない。

自分はPHP、Node.jsを使った開発をする。基本はライブラリーないしフレームワークに依存して開発を進めて来てしまった。その依存がソフトウェアをスケールしたい時、足枷になる。その足枷を外すヒントが、clean architectureであったり、オブジェクト指向に隠されている、というのが自分の出した答えだ。

JavaScriptはオブジェクト指向プログラミング言語ではある。しかし、世間一般的に紹介されているJavaScriptコードは関数型プログラミングされている。

オブジェクト指向と関数型の違いは大まかに以下のようになる。

オブジェクト指向が認識され始めたのはおよそ1980年初頭。C++のリリースは1985年である。とりわけオブジェクト指向はGUIと共に発展を遂げて来た。

ソフトウェアエンジニアリングは、システム開発と言い換えられる。ソフトウェアの目的はあくまで「プロダクト」を生み出させることである。ソフトウェアはあくまでツール・手段であり、それ自体は最終ゴールになりえない。

今だ100年の歴史も持たないソフトウェアエンジニアリング。物的形がないソフトウェア産業だが、ソフトウェアエンジニアリングの過程は、産業デザインの過程のそれを辿る。

自動車製造産業を例に挙げる。

ソフトウェアエンジニアリングは工場をつくるようなものだ。システムは、要求・要件を基に、期待される商品を製造する過程ないし手法である。

そして、その過程をつくる過程は、

となる。

Analysis

端的に日本語に訳すのであれば、分析だが、実務と紐づけるのであれば、仕様書作成と言ったところだろうか。自動車製造工場であればすぐ思いつくだけでも、以下のような仕様を明確にしなければならない。

• 最小必要面積
• 収容従業員数
• 天井高さ
• 製造部品
• 素材・部品管理方法
• 製造順・アッセンブリーライン
• インストールする設備・機器

近年であれば、ここにCO2排出量制限なども入るかもしれない。

Construction

Constructionはdesign(設計)とimplementation(実装)から構成される。

同書で「design」はAnalysisではなく、Construction過程に分類されている。Analysisの成果は「理想型」であることが多い。しかし、design/implementation成果物は「現実型」でなければならない。

Designは建築士が図面を描く作業に相当する。ソフトウェアエンジニアリングであれば平面図の代わりにUMLを描く。

Implementationでは、柱を一本一本建て、壁を作り、インテリアを仕上げる。作業が設計から建設へと変わる。ソフトウェアソフトウェアエンジニアリングであれば、コード、プログラムを書く。設備—インフラストラクチャー、つまりはサーバーやDBなど—の導入もしなければならない。

Test

Constructionが終われば、そのプロダクトが要件・仕様通りものかどうか評価しなければならない。建造物であれば、「ここが少し違うので、ダメだから作り直してください」という訳にはいかない。しかし、後から修正ができる、比較的しやすい、もしく比較的低コストで修正できる点は、ソフトウェアエンジニアリング特有である。

-

アジャイル開発とソフトウェアエンジニアリングデザインについて。

同書は1992年に出版された。出版から今日まで、ソフトウェアエンジニアリングも既にに33年の歴史と経験を重ねた。

このブログを書く前、著者のプレゼン動画をYouTubeで閲覧した。動画の中で以下のような図が紹介されていた。

動画は2003年に撮影されたものなので2025年時点での傾向は不明だ。

個人的な印象だが、国内で他エンジニアとチームを組むとき、設計主義手法を取りたがるエンジニアの方が多い。彼らはコードを書く前にいろいろとドキュメント・資料・設計書みたいなものを用意したがる。私的に、彼らが設計主義手法を採用するのには、2つの背景があると推測する。

1. コードを書いた後のミス・不具合の責任をできるだけ依頼主(時には同チーム内のディレクター・マネジャー・マーケターなどの非エンジニア)に押し付けたい。「こちらは言われた通りに作っただけです。悪いのは要件・仕様の方です」と逃げ道を作って起きたいのである。
2. 物事には正解があり、正解を答えないといけない、正解通りに行動しなければならないと教え込まれている。これは、エンジニアに非はなく、学校教育・受験主義のせいだ。与えらた正解を答えねばならないと躍起になり、一緒に正解をつくることをしようとしない。偏見だが、なまじ学歴に自信のあるエンジニアのほど、設計主義手法、ウォーターフォール開発を好む印象だ。

設計主義手法の謳い文句は「後で開発が楽になる」だ。楽な開発など、この世に存在はしないと思うが。

結局、オブジェクト指向と関数指向はどちらが良いのか?

全てのソフトウェアエンジニアリング・ディシジョンはトレード・オフ。プロジェクトでどちらを採用するかの目安は以下のようなところだろうか。

	オブジェクト指向	関数指向
初期コスト	×	◯
拡張性	◯	×
保守性	◯	×
コミュニケーション	◯	×