ソフトウェア開発の「新」3種の神器

ソフトウェア開発の「新」3種の神器に関する記事を見つけたのでメモ。
日経Systems2013年6月号に掲載されている。

【元ネタ】
記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro

記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro

記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro

【1】興味深いのは、アンケート結果では、「「Microsoft Project」（MS Project）で48.7％、2位はオープンソースソフトウエア（OSS）の「Redmine」で40.4％、3位も同じくOSSの「Wiki」で32.4％だった」こと。
他に、TracやTFSも上位に上がっている。
日本でRedmineの人気は高いのが意外だった。

Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blogの記事で、Redmineのガントチャートにおけるイナズマ線描画機能は 伊藤忠テクノソリューションズ株式会社 (CTC) の提供だったという話があるように、日本ではRedmineのニーズが高いのかもしれない。

また、MSProjectとRedmineを併用している特徴もなるほどと思う。
現場ではRedmineで運用し、客向けや上司にはMSProjectのガントチャートで進捗報告する手法を使い分けているのだろう。
この考え方は、基幹系業務システムの発想と同じように思える。
基幹系業務システムを使う人は現場の担当者であり、経営者は普通、現場にタッチしないからそもそもシステムに触れることもない。

でも、プロジェクトの進捗や課題、品質に関する情報はすべてRedmineの背後にあるDBに一元化されているのだから、顧客や上司が知りたい情報の元ネタはDBにある。
そのデータをどんな観点で抽出して見せるのか？
データが一元化されているからこそ、プログラムを組めばいくらでも好きなだけメトリクスを抽出できる。
この発想も、BPR、ERPに似ている。

Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索

定量的プロジェクト管理ツールはIT企業の基幹システムを目指す: プログラマの思索

Redmineが使いづらいと言う質問～開発業務をRedmineへマッピングできていない: プログラマの思索

【2】ソフトウェア開発の「新」3種の神器とは、「Redmine」「Jenkins」「Chef」を指すらしい。
ちなみに、@haru_iidaさんが提唱された3種の神器はITS・SCM・CIだった。

アンケート結果では、JenkinsやChefの利用度はRedmineに比べて少ない。
現場リーダーの意識はプロジェクト管理に向いていて、開発インフラまで回っていないのかもしれない。

しかし、JenkinsやChefが重要な理由は、ビルド管理やリリース管理、サーバー構築をすべて自動化できることによって、アジャイルに開発できることだと思う。
実装できれば即座にリリースして納品できるだけでなく、顧客から早くフィードバックをもらうことで、ソフトウェアを早く機能改善できる利点がある。

クラウドの本質はインフラ管理のIT化: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

また、Jenkinsには「メトリクス収集ツール」「ジョブ管理ツール」という2つの側面を持っていて、そこにたくさんの可能性を秘めていると思う。

メトリクス収集ツールJenkinsという観点では、定期的にプログラムをビルドしたりテストすることでメトリクスを自動収集して集計する機能がJenkinsには元々付いている。

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

Jenkinsで静的コード解析を常時自動化する: プログラマの思索

ジョブ管理ツールJenkinsという観点では、定期的にバッチのように処理を一括実行する機能が元々付いているので、高機能化したCronとしてバッチジョブを管理するツールへ発展できる可能性を秘めている。

Jenkinsをジョブ管理ツールとして使うアイデア: プログラマの思索

Jenkinsをバッチ監視ツールとして運用する事例: プログラマの思索

Jenkinsをジョブ管理ツールとして使う事例part2: プログラマの思索

Jenkinsのジョブフローを可視化: プログラマの思索

【3】だが、Jenkinsの普及がまだ広がっていない理由は、それだけではないと思う。
Jenkinsを使いこなすには、ビルドスクリプトを作って定期実行しなければ意味が無い。
つまり、ビルドやリリースを実現するプログラムがなければ、Jenkinsはただの箱にすぎない。
その意味ではChefも同じ。
逆に、Redmineは一度インストールすれば、画面からチケットを登録してすぐに運用できるお手軽さがある。

Jenkinsの今後の課題は、ビルドスクリプトをAntやMavenのようなJavaではなく、Rakeのようにもっと強力で表現力の高いRubyへシフトして、ユーザを拡大していくことにあるのではないか、と思っている。
Jenkinsを紹介する本や記事で、いまだにAntの使い方を説明しているのはもはや時代遅れだと思う。

Chefのように継続的デリバリーに関するツール群のほとんどがRubyで実装されている事実からしても、その傾向は明らかだと思う。

CIツールはビルドスクリプトのプログラミングに依存している: プログラマの思索

僕は開発プロセスをツールでサポートしていく発想が好きだ。
上から目線で理論を盾に現場を管理するよりも、現場で役立つツールを駆使しながら、ノウハウというプラクティスを生み出していく手法の方が好きだ。

高速道路で走る車の速度はエンジンに依存する～ツールが良くてもプロセスの成熟度はチーム次第: プログラマの思索

今後もその観点で追いかけてみる。