今のSI業界もリファクタリング可能だと思います

SIという用語を聞いてイメージするもの

業界の現状を考えると理解できることではありますが、SI業界やSIerという言葉に対して、極端に悪いイメージを抱く人が多いようです。SEやPGなどの用語もそうですが、立場によって用語からイメージするものが大きく違っているみたいです。

用語 文字通りの意味 業界の常識 先端技術を追う人
プログラマー プログラムを書く人 PGと同義 新しい価値とサービスの創造者
PG プログラマーの省略語 コードを書き下す単純労働者 時代遅れの恥ずかしい言葉
SE システム化を行うエンジニア PGの上位職、御用聞き
Excelパワポの専門家
じゃまで不要なもの
SIer 大規模な業務システムの開発・
統合・保守を専門で行う会社
ITゼネコン構造の上位に位置するもの
人集め、中抜き、ブランド
軽蔑の対象、憎むべき敵
つぶされるべきもの

私はどちらかというと言葉の意味を文字通りの意味で考えてしまう傾向がある*1ようです。SIerについても、既にもしSIerがまともなエンジニアリングの会社だったとしたらどんな仕事が考えられるか?で書いたとおりですが、本来は達人プログラマーのもっと活躍する場所があってよいのではと思ってしまいます。本来の文字通りの意味のSI(システムインテグレーション)という言葉の意味を考えるのであれば、SIerシステムインテグレーター)はクラウド、ESBなどの技術を活用することで企業のITシステムの価値を最大化するプロフェッショナルからなる集団であるべきですし、達人プログラマーが正社員として正しく評価されて、相応の地位や責任を与えられるべきではないかと思えてしまいます。

オブジェクト指向の知識が要求されるドメイン駆動型設計

まず、新規の業務システムを構築するのであれば、業界固有(ドメイン)の業務知識をオブジェクト指向的に分析し、クラスに落とし込む能力が求められます。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

Domain-Driven Design: Tackling Complexity in the Heart of Software

Domain-Driven Design: Tackling Complexity in the Heart of Software

を読むと、達人プログラマーである著者がエンドユーザーと対話し、徐々に業務に関する理解を深めながら、あるべきオブジェクト指向のプログラムを創り上げていく話が随所に出てきます。複雑な業務知識を対象とするシステムの構築において、オブジェクト指向プログラミングの知識やスキルがいかに大切かということがわかります。ドメイン駆動型設計=DDDについては、以下も参考になります。
Domain Driven Design(ドメイン駆動設計) Quickly 日本語版
ドメイン駆動設計・開発の実践
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回|オブジェクトの広場
現状の業務をオブジェクト指向のプログラムに落とし込むというだけでは、技術革新などなくつまらないと考える人もいるかもしれませんが、DDDにより今まであいまいだった業務が整理されて、再利用可能なプログラムになることで、今まで明確になっていなかった非効率な業務のリファクタリングが進み、さらに、新しいサービスや価値の発見といった機会も得られるかもしれません。
そして、DDDで業務知識がドメインモデルとして抽象化されると、次の段階として業務知識のレベルの言語を使ってプログラムを記述するという次の段階に進化させることができます。つまり、一種のマクロ言語のように業務の言葉で直接プログラムを記述できるということです。最近はこのDSL(Domain Specific Language)という考え方がかなり一般的になってきているようであり、既に本も何冊か出版されています。
Domain-Specific Languages (Addison-Wesley Signature Series (Fowler))

Domain-Specific Languages (Addison-Wesley Signature Series (Fowler))

DSLs in Action

DSLs in Action

システム統合におけるプログラマーの活躍場所

一方、大企業の場合は特にそうですが、既存の大量のシステムが情報資産として存在し、複雑に絡み合っています。新しい言語や開発環境が利用できるからといって、直ちにすべてのシステムを全面更改するというわけにはいきません。こういう場合に、どういう順番でシステムを更改し、どの部分を統合するのが効果的か、あるいはどのようなパッケージやSaaSを再利用すべきかということを戦略的に考える必要がありますが、そういう視点は規模こそは違いますが、オブジェクト指向プログラミングにおけるカプセル化や抽象化、再利用の能力が必要とされるところです。そして、こういうところでも達人プログラマーが活躍する場所があると思います。実際、エンタープライズシステム統合に関しては、以下の有名なパターン本がありますが、著者のGregor氏は達人プログラマーの一人であり、実際プログラマが知るべき97のことにも文章を寄稿しています。

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series (Fowler))

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series (Fowler))

SI業界のリファクタリング

私のやはり、私は今後もSI業界で達人プログラマーを目指したいに対して、いろいろとコメントをいただいた中で、

SIerは達人プログラマを必要としていないんですよね・・・。自分は、SIerとは違う形でシステム開発に関わりたい

情熱ある文章だけど、ぼくはひがさん派だな。お金を払ってもらえるということは顧客に価値を提供できてるということ。社会を良くしている。それに比べ望まれなくても自分がやりたいからやるというのは自己満足に近い

のような意見も多いのですが、ちょっと日本の現在のSI業界の現状にとらわれすぎてはいないでしょうか?現状の業界の状態が今のまま不変であると考えるのはあまりにも悲観的過ぎるのではないかと思えます。本来は業務システムはビジネスを遂行する上で欠かすことのできない基盤となっています。それゆえ、本来SIという仕事は顧客企業から本当に必要とされる価値の高いものであり、達人プログラマーのスキルが本当に求められる領域だと私は思うのですが、それはそんなにおかしい考え方でしょうか?
もちろん、今までの業界の構造を一夜にして変えることはできませんが、プログラムをリファクタリングするように、一歩一歩改善できるところから直していくようにすれば、数年という比較的短い時間でSIの仕事のやり方を劇的に変えることは不可能ではないと私は思います。そして、そのための第一歩として、プログラムのデッドコードに相当する無駄な仕事や構造を削減すること。そして、クラスの役割が明確化されたMVCアーキテクチャーのように、何でも屋ではなく役割のはっきりした専門家の仕事をもっと明確に評価することが必要不可欠だと思います。

*1:アスペルガー症候群の典型的な特徴の一つ