現代のソフトウェア／サービス開発で構成管理が重要になった5つの理由：DevOps時代の開発者のための構成管理入門（1）（2/2 ページ）

「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする

[縣俊貴, 染田貴志，ヌーラボ]

【3】さまざまな用途のツールの進化

　こういった環境の変化に対応し、柔軟なソフトウェア開発を支えるためのツールも進化しています。本連載で取り上げる内容についても、以下のように変化してきています。

• バージョン管理システムは、Subversionなどの集中管理方式から、GitやMercurial、Bazaarなどの分散管理方式へ

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

• 継続的統合システムは、ContinuumからJenkinsへ

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

• ITS／BTSは、BugzillaからRedmine、Pivotal Tracker、JIRA、Backlogへ

　これらのツールを活用することは、良いソフトウェア製品を生み出す力の源となります。各ツールがどんな問題を解決しようとして、何を目指しているのかを知ることは、より良いプロセスを作り、チームに活力を与えることにつながります。

【4】ソフトウェアビジネスの移り変わり―アジャイルへのシフト

　ソフトウェアビジネスはこれまでの受託開発中心だったものが、特に中小のソフトウェア企業、スタートアップにおいて、自社のWebサービス／製品開発に移り変わってきています。

　これは、小規模な事業者でも、iPhone／Android／Facebook／AWSといった全世界に低コストで配信可能なプラットフォームが充実してきたことにより、ビジネスチャンスが広がってきたのが要因の1つでしょう。

　こういった製品開発では、納期までに所定の仕様を満たすソフトウェアを納めれば完了ではなく、むしろ提供を開始した段階でようやくスタート地点に立つようなものです。

　ユーザーに満足してもらう価値のあるサービスとして成長させるには、変化する要件に対して柔軟に追随し、それを頻繁に、そして迅速にユーザーに届ける必要があります。

　これを実現するには、まさにアジャイルな開発が打ってつけです。構成管理の考え方はアジャイルに限ったものではありませんが、その要素の多くはアジャイル開発を支えるためになくてはならないものです。

【5】リーン型の開発プロセスの重要性の高まり

　ソフトウェアサービスに限らず、今は「作れば売れる」から「作るだけでは売れない」時代になっています。何が正解かは、誰も分からない中、どうすれば成功できるのでしょうか。その方法論として注目を集めている手法の1つがリーンスタートアップです。

　リーンスタートアップでは、以下のループをいかに早く回し、自分たちのアイデアや製品が正しい方向に向かっているかを検証することが重要である、と説いてます。

1. 実用最小限の製品（Minimum Viable Product）を作り
2. それを顧客に利用してもらってフィードバックを得て
3. そこから学ぶ

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　また、Ruby on Railsの開発者であるDavid Heinemeier Hansson（DHH）がいることで知られる37signalsの経営哲学ともいえる「Getting Real」では「ソフトウェアの実用性を確かめるには、現場で使うしかない」とも説かれています。

　実際に彼らは、自分たちの製品の新機能や改善を検証するために、プロダクション環境のデータベースにアクセスするベータ機能のサーバを6つ用意し、簡単に切り替えれるようにしているそうです（参考：Running beta in production by David of 37signals）。

　リーンスタートアップにせよ、37signalsにせよ、こうした素早いリリースや、プロダクションと自分たち向けの検証用のベータ環境を切り分けた環境のリリースを実現するには、素早く、安定し、コントロールされたプロセスが必要となります。

　これは言い換えれば、構成管理はソフトウェアサービスを正しい方向に導くための必須の要素であるといえるでしょう。

DevとOpsがお互いを良く知るために―― 本連載の予定

　本連載は全部で5回の予定です。2回目以降は以下の内容をお届けします。

本連載の全体像

第2回「ITS／BTSを使ったプロジェクト運営」

　課題管理システム（ITS：Issue Tracking Sysytem）や、バグ管理システム（BTS：Bug Tracking System）を中心としたソフトウェア開発、プロジェクト管理を紹介します。

第3回「バージョン管理（SCM）」

　GitやSubversionを使って、ソースコードなどの成果物を安全に管理・保守する手法を紹介します。

第4回「継続的な統合（Continuous Integration）」

　継続的な結合により、安全にソフトウェア開発をドライブできます。デファクトである「Jenkins」を使った活用事例を中心に紹介します。

第5回「継続的な配布（Continuous Delivery）」

　配布を自動化し、ソフトウェアを安全に手軽に配布する手法を紹介します。また、そのソフトウェアの配布先であるインフラ管理をどのように行っているか、私たちの実践を中心に、その考え方についても取り上げます。

　「DevOps」の考え方の中で強調されていることの1つが、「Dev（開発者）とOps（運用者）という、表面的には利害が対立する人々がお互いを『尊敬し、信頼する』ことが全ての基礎にある」という点です。

　月並みではありますが、そういった関係を築くためには、お互いのことを知ることが第一歩です。本連載は「開発」の側面からの内容を中心に取り上げますが、Devの方だけではなく、ぜひOpsの方にも読んでいただき、お互いを良く知り、そのソフトウェアやサービスの価値をより良くする1つの手助けになれれば幸いです。

　次回は「ITS／BTSを使ったプロジェクト運営」です。お楽しみに。

「次回」へ

著者プロフィール

縣俊貴

プロジェクト管理ツール「Backlog」、ドローツール「Cacoo」など、コラボレーション型のWebサービスの企画と製品開発を行う。福岡在住。株式会社ヌーラボ所属。著作に「良いコードを書く技術（技術評論社）」

染田貴志

株式会社ヌーラボにて、プロジェクト管理ツール「Backlog」、ドローツール「Cacoo」の開発、インフラ運用などにたずさわる。ソフトウェアとロックと家族を愛する開発者。京都在住