「Open Source Strategies for the Enterprise」～開発環境はベンダロックインからオープンソースへ進化する

Jenkins ユーザ・カンファレンス 2015に参加できなかったけれど、昨今の開発環境の流れについてメモ。

【元ネタ】
Open Source Strategies for the Enterprise?-?O'Reilly Media

≫ Jenkins ユーザ・カンファレンス 2015 東京 ? セッション/LT 日本Jenkinsユーザ会

Jenkins ユーザ・カンファレンス 2015 東京に行ってきた #jenkinsja #juc2015 - yukungのブログ

三浦カズヒト(エモいこと言う人(自動))さんはTwitterを使っています: "早い！！早いよyukungさん！ｗ Jenkins ユーザ・カンファレンス 2015 東京に行ってきた #jenkinsja #juc2015 - yukungのブログ http://t.co/pBPzNB2GQA"

【1】Linuxが出る前の2000年以前は、開発環境はベンダロックインされているのが普通だった。
マイクロソフトのVisualBasic、VisualStudioが典型例だっただろう。
他にも、IBMやらCoboleベンダー、C言語ベンダーが提供した開発ツール上で、プログラミングし、デバッグし、リリースするのが普通だった。

ベンダロックインされた開発環境では、開発環境の不明点があったり、バグがあれば、ベンダーが必ずサポートしてくれる安心感はある。
しかし、IT業界のように、案件ごとに現場を行き来するエンジニアにとって、開発ツールがバラバラであるのはすごく苦痛だ。
ベンダロックインされた開発ツールのノウハウは、他の現場では使えず、また一から開発ツールを覚えなければならないから。

また、ベンダロックインされた開発ツールは、大手ベンダーでない限り、VerUpの頻度が遅い。
PCというハードやDBなどのミドルウェアのVerUpの速度に、開発ツールがついていくのは結構大変だ。
せっかく安定している開発環境をVerUpして動かなくなるのはよくあったし、異なるバージョンの開発環境が混在するのも面倒だ。

さらに、ベンダロックインされた開発環境は、その時代の最先端の開発ノウハウが提供されていたかもしれない。
しかし、これだけ技術進歩の速い時代では、むしろ弱点の方が大きくなっている。
例えば、SAPでも、SAP特有の開発環境を用意しているが、今となってはCobolチックで、アジャイル開発に慣れた開発者から見れば触りたくもない代物だろう。

以前のIT企業は、「技術の標準化」という活動で、開発ツールを自社内で統一し、そのノウハウを共有させようとしてきた。
しかし、周囲の技術の進化のスピードに乗り遅れやすく、すぐに陳腐化しやすい弱点があった。

【2】現代は、GitHubによるプルリクエスト主導のアジャイル開発が主体となっているから、いかに開発環境を追随させていくか、という流れで技術進化している。
たしか、誰かが「エンタープライズ開発でも、オープンソースでやっているような開発スタイルを取り入れるべきだ」と言っていたが、まさにその通りだと思う。

今はベンダー主導の開発ツールよりも、オープンソースで育まれた開発ツールの方がどんどん進化しており、よりアジャイルな開発スタイルを実現させている。

その筆頭がGitHubであり、他にも、Jenkinsがあり、クラウドなインフラを提供するツール群があったりする。
もちろん、その流れに、Redmineなどのチケット駆動開発も含まれているだろう。

【3】今後の技術者は、ベンダーが提供した製品やツールに慣れるよりも、オープンソースの開発スタイルに慣れた方が数多くのメリットがあるだろう。

まず、オープンソースの開発スタイルの方が最新技術のトレンドに触れやすい。
次に、オープンソースの開発スタイルに慣れておけば、他の会社や他の現場に行っても、同じような技術を使える。一から覚え直す必要がなくなるし、開発ツールに慣れる学習時間というロスが減る。

さらに、オープンソースの開発ツールのコミュニティにも参加したりコミットできれば、世界中の開発者が今まで体験してきた開発ノウハウを共有できるし、逆に、新しい開発ノウハウを提供して、他の開発者に好影響を与えることもできるだろう。

「Open Source Strategies for the Enterprise」という本がオライリーで英語本が出ているらしく、その本では、上記のような流れの内容が書かれているらしい。
翻訳が出たら読んでみたいと思う。
(Amazonで見ると、Kindleで無料なので、読める人は読んでもいいかもしれない)