◆オブジェクト指向とは、プログラムやシステムの設計・開発手法の一つであり、データとその処理方法(メソッド)をひとまとめにした「オブジェクト」を基本単位とする概念である。
◆オブジェクト指向プログラミングは、カプセル化、継承、ポリモーフィズムといった特徴を持ち、ソフトウェアの再利用性、保守性、拡張性を向上(つまり、従来型の硬直的なITシステムよりも変化に対応しやすいITシステムで、開発コストを抑制)させる。オブジェクト指向は複雑なシステムをモジュール化し、管理しやすくする(定期的な変更を要する部分を「クラス」として分類しておく)ための枠組みとして広く利用されている。
・カプセル化:抽象概念の基本機能を定義
・継承:抽象クラスで定義した機能を具象クラスで引き継ぐ
・ポリモーフィズム:抽象的なクラスに対してプログラミングする
◆オブジェクト指向に適合しやすいプログラミング言語は、Java、C++、Python、C#、Rubyなどであり、クラスやオブジェクトを基本構造としている点で一致している。
【Plus】オブジェクト指向ではソフトウェアの構造が複雑になり、開発初期段階で成功か失敗かが決まってしまう。重要なことは「開発時にユーザーと開発者が業務要件を(想定できる範囲で発生可能性の高い「変化」を含め)しっかり議論し、開発者が正確に理解しておくこと」である。そうしないと、テスト運用時にさまざまな問題が発覚し、想定外の仕様変更に右往左往し、複雑怪奇なITシステムが出来上がる。つまり「業務を正確に理解できる開発者」を選定するか、「業務を理解できない開発者にでも理解させられるユーザー」を選定するということである。
【Plus】つまり、「業務知識とIT知識とコミュニケーション能力の高い人」がプロジェクトのキーパーソンになるようにすべきである。この重要性や困難さを理解してない経営者が多く、IT専門性だけで人を選んでしまって失敗する。IT専門性だけ優秀な人はそこそこいるが、3つ兼ね備えている人はめったにいない。だから、必要な能力を備えた最少人数チームを全体のコアにするのが正解である。これは、オブジェクト指向開発のような複雑ケースのみならず、比較的シンプルなDX全般にあてはまる。DXで失敗が多い理由の1つである。
【Plus】IT責任者に丸投げすれば、結果、想定外に開発期間やコストが膨らむ。「人は不完全でも融通が利く。機械は完璧でも融通は利かない。」という原理原則があるので、ITシステムは「人がやる作業を機械にやらせるもの」である以上、「人がやる作業を過不足なく機械の言葉に翻訳できたら、物凄く速く正確になるが、翻訳に失敗したら機械は完璧に失敗する」という性質を持つ。このような複雑なプロジェクトでは、100人のふつうの人がいても無意味というか有害で、1-3人の優秀な人が中心になって進める方がよい。この点、M&Aアドバイザーと非常に似ている。複雑系のコミュニケーションを複雑にしてはいけないのである。
【Plus】本来、オブジェクト指向で開発したITシステムは、PMIとの相性もよい。ITシステム統合において互換性や拡張性が高いためである。オブジェクト指向が常に優れているわけではないが、利用中のITシステムがどのようなプログラミング言語でどのような設計で開発されたものか、もし数年内に大幅な改良を要する場合や別の会社のITシステムと統合する場合にどのような課題があるかを把握し、可能な範囲で対策を講じておく(例えば、ITシステムの要件定義書、保守・運用に関するドキュメントやマニュアル等の確認と整備)ことは、M&A売主にとって有益である。
【Plus】M&A交渉を始める前に、M&A売主が対象企業のソフトウェア開発やシステム運用においてオブジェクト指向を導入することで、柔軟なシステム拡張や事業展開の変化に対応しやすいITシステム環境を整備できる。特に重要なITシステムを開発する予定がある場合、必ず選択肢に入れておくべき論点である。もちろん、小規模システム開発の場合、より単純な志向で開発した方がよいので、全体を俯瞰して検討すべきである。
【Plus】M&A交渉が始まってから、M&A買主にわかりやすくシステム環境等の情報を開示すべきである。書類の内容が曖昧だったり、容易に誤まりが発見されるなどを通じ、PMIコストを保守的に見積もられてしまえば、(システム修繕費のかかるITシステムに依存している会社として)直接的に企業価値評価に影響してしまうからである。多額のCAPEXを要する会社の評価が高くなりづらいのと同じである。億円単位でシステム開発コストが増えてもおかしくない以上、億円単位でM&A売主が受け取るキャッシュが減ってもおかしくない。やはり準備が大事なのである。