時系列にPOAからSOAを語ってみた

システム開発には、どこに着目をして設計するかというアプローチの仕方があります。
システム開発や情報系の大学に行ってた方はSOA、DOAは見聞きしたことがあるのではないでしょうか。
このアプローチについてどのように発展してきたのか時系列で物語っぽく語っていこうと思います。

設計アプローチの変化の流れ

設計アプローチがどのように変わっていったのか時系列で図にしてみました。
それぞれの設計アプローチは明確にこの年月にできたものではなく、システム開発のトレンドや技術、製品の発展に応じて設計アプローチが推奨されたり、実際に行われるようになってきました。
流れとしてPOA(Process Oriented Architecture)->DOA(Data Oriented Architecture)->OODA(Object Oriented Design and Analysis)->SOA(Service Oriented Architecture)を把握していくとなぜその設計アプローチが言われるようになったか分かりやすくなります。

手作業を自動化して効率化する時代POA

POA(Process Oriented Architecture)という意味でプロセス、業務に焦点を当てた設計手法です。
プロセス指向アプローチ、プロセス中心アプローチと呼ばれます。
この言葉を知らなくても、システム開発の要件定義に参画したことがある場合は業務フロー図を作る、または見たことがあるでしょう。
業務の流れを追っていくので、分かりやすいため今でも業務フロー図は使われます。
まだ手作業をシステム化、プログラムを作って自動化する場合はどの業務をシステムにやらせて、ヒトの手が入るのはどこか明らかにする必要があるので、業務フロー図、業務の整理がシステム開発をする上で重要になってきます。
業務を整理し、自動化する部分を決めていき、時には業務を変えていくといった業務を中心にシステムの設計がなされていきます。
このような業務の流れに焦点を当てたシステム設計からPOA(ProcessOrientedArchitecture)、プロセス指向アプローチと呼ばれるのです。

あまりに当たり前すぎて言葉としてはあまり聞かないかもしれません。

プログラムが作られ注目されるデータを中心とした設計DOA

業務を自動化したり、紙でやっていたことが電子化されてくると、業務も効率化されてくると同時にデータが蓄積されてきます。
システム(プログラム)は大きく分けてデータの入力、処理、出力になります。
この入力、処理、出力され次のプログラムやシステムへとつながっていくのです。
システムが作られていくと、企業では部門ごとシステムを持つようなことになります。
そうすると、部門ごとシステムのデータが存在することになります。
生産と購買、購買と経理、営業と経理などと部門間で持ってるシステムを連携させればさらに効率化されます。しかし、ここでシステムに関して言えば、データが一致していればいいのですが、一致しないことがあるとどちらのデータが正しいかと言った問題が発生します。
具体的には、営業部門のシステムで持ってる売上データと経理部門で持っている売上データが一致しないといった形です。
そこで、重複して持っているデータはまとめて一つに、業務上不必要なデータを洗い出して、データを一元化していくことでより効率的になり、データ管理も品質が高まります。
企業全体で見た時、業務間のシステムが連携されていくと企業で重要な指標が見ることが可能になります。
経営からではなかながら見えてこない営業や購買などのデータが把握でき、経営判断にも使えるようになるのです。

このように業務からデータへと目が行くようになり、システムもデータに焦点を当てた設計になっていきます。
このシステム開発のアプローチをDOA(DataOrientedArchitecture)、データ指向アプローチと呼ばれます。
1980年後半からこの言葉が出てきて、システム開発界隈ではよく聞く時期もありました。
システムも生産や営業、購買、経理といったどの企業にもある仕事は企業ごと多少違いはあれど、同じような業務が多くあります。
特に経理系の法律に縛られる部分が多い仕事は共通の業務が多いです。
こういった共通の業務はシステムとしても共通の機能を提供して、一つのシステムで営業、生産、購買、経理業務といった基幹業務を構築できる製品ERP(Enterprize Resouce Plannning)が登場し、流行り始めます。
日本語では経営(企業)資源計画と言われますがERPや基幹システムなどと聞くことが多いのではないでしょうか。
ERP製品の中でもSAPは有名で覚えておいて損はないでしょう。

データと処理をまとめて効率的に作るようになったOODA

1990年代になってくるとDOAで今までデータに焦点を当てていました。
そこからさらにデータと処理をまとめてひとつのオブジェクトと考える事でソフトウェア開発の品質、効率化を図るアプローチが生まれます。
これまで、プロセス(処理)に着目したアプローチとデータに着目したアプローチをしてきたことで、処理とデータを組み合わせることでソフトウェアを作るというものです。
これまで培ってきたノウハウや作ってきたものが増えたことで1から作る機能が少なくなってきて、すでに作った機能に扱うデータを組み合わせればさまざまなシステムやソフトウェアを作れるようになったのです。
例えば走るという機能がすでに作られているのであれば、そこに重さが1トン、材量が金属とプラスチック、形が四角、出せる速度は-20から170km/hというデータが入ると、それは車の機能、システムを作っていることになります。
これが、重さ5キロ、出せる速度が0-30km/hだと自転車となるように機能とデータの組み合わせたオブジェクトとして捉えて開発を行うアプローチが流行ります。
これがオブジェクト指向アプローチです。
当時はこのオブジェクト指向アプローチに適したプログラミング言語のJavaも出てきて、業務システムなどの構築ではJavaが主流です。SIerに入社すれば必ず新人は学ぶと言っても過言ではないでしょう。
最近は聞く数もオブジェクト指向に関する書籍も少なくなった気がしますが2010年くらいまでよく見かけた気がします。

作る時代は遅れてる？サービスの組み合わせがものを言うSOA

まずは手作業をコンピュータで処理させるPOA、データに着目するDOA、そして処理とデータを組み合わせたオブジェクトで考えるオブジェクト指向が出てきました。オブジェクト指向が流行り、さまざまなデータと処理の組み合わせでソフトウェアが出てきます。2000年を過ぎてくるとインターネットも普及しクラウドサービスも出てきました。
サービスが溢れるようになったのです。
もうもはや新しいソフトウェアやサービスを作るときに1から作ることはほとんどなくなりました。
すでに作られた機能や類似のデータやサービスがある世の中になったので開発の仕方もサービスを組み合わせて新しいサービスを作るアプローチが出てきます。
すでにあるサービスを活用する方が1から作るよりも品質も効率も高くなるので、無理に1から作る必要がなくなったのです。
こうなってくると既に出来上がったものの組み合わせで作ることができるのでコードを書かなくてもアプリを作れたり、ライブラリなどの関数1行で高度な機能が実現できるのでコードを書くとしても少なくてすむローコード開発もできるようになり、今はやっています。
このようにソフトウェアやシステム、サービスを構築するときにサービスに着目して開発していくアプローチをSOA(service oriented approach)、サービス指向アプローチといいます。
開発をするときにAWSのサービスをどう組み合わせようかと考えることがあると思います。それがもうSOAですw
高度なシステム構築、プログラミング言語の仕様、サーバー、ネットワーク部分の機能を作らずに既に提供されているサービスの組み合わせで出来るのでより新しいサービスや機能を作る部分にかける時間や作るサービスをどう売るかのビジネスの方に時間をかけられるようになったのです。
こういうことこあり、急速にITが発展することもできたのです。

最後に

システム開発の設計アプローチについて
流れを追う形で物語っぽく説明してきました。
システム開発といったITに関わる技術やトレンドは日進月歩で流行り廃りも早いです。
また、単語や言葉がバズワードのように独り歩きもするので断片的な知識しか身に付かず、なかなか書かれている説明を暗記するのに留まってしまいます。
深く理解しようにも専門書になると急に難しくなります。
特にさまざまな理論や手法間の関係、つながりはなかなか書かれているものがないので書いてみました。
理解の助けになれば幸いです。