ITS／BTSによるプロジェクト運営7つの勘所と手軽に使える5ツール：DevOps時代の開発者のための構成管理入門（2）（1/2 ページ）

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

[縣俊貴, 染田貴志，株式会社ヌーラボ]

そもそも、構成管理とは

　第2回目からはいよいよ、構成管理の具体的な内容に踏み込んでいきますが、最初にソフトウェア開発における「構成管理」とは何か、そのメリットは何なのか、を考えてみたいと思います。

　「構成管理」という言葉は古くからあり、CMMIをはじめ、さまざまなフレームワークや標準化プロセスにおいて定義されていますが、ここでは本特集と内容のかかわりが多い、書籍「継続的デリバリー」の第2章より、その定義を引用します。

構成管理とはプロジェクトに関連するあらゆる成果物とそれらの間にある関係性が、保存され、検索され、一意に特定され、修正されるプロセスのことである。

　ここでいう成果物とは、アプリケーションそのものだけではなく、その元となるソースコード、アプリケーション設定や、OSやミドルウェアなどの環境に至るまで、動作するアプリケーションを取り巻く全てを指しており、「その構成管理のプロセスを通じて、いつの時点のアプリケーションでも簡単に再構築できるようにしなければならない」と述べられています。

構成管理は「ソフトウェア開発におけるタイムマシーン」

　言い換えれば、「構成管理とはソフトウェア開発におけるタイムマシーンを実現するためのプロセスである」といえます。

　では、その「いつの時点にでも戻れる」ことのメリットは何でしょうか？

　さまざまなメリットが考えられますが、「DevOps」というキーワードで考えたときに最も大きなメリットの1つが「アジリティを高める」ことです。

　誰しも動作しているソフトウェアや環境に対して変更を加えることには「怖さ」を感じます。連載第1回の「現代のソフトウェア／サービス開発で構成管理が重要になった5つの理由」でも述べたように、現在のソフトウェア開発は変化に柔軟に追随できるかが生死を分けるといっても過言ではなく、こうした変更に対する恐怖心を払拭することは必須です。

　構成管理によって安全な場所に簡単に戻れることが保証されるので、「変更」に伴う時間的、心理的コストが最少化され、結果としてスピードを保ったままダイナミックにソフトウェアサービスを展開可能となります。

　その他のメリットについても、連載第3回以降に各プロセスの中で紹介していきたいと思います。

AWSは最大で1時間1000回にも及ぶデプロイ

昨秋ラスベガスで開催されたAWSのイベント「re:Invent」にて、最大で1時間1000回にも及ぶデプロイを行っていると発表されました。こういった迅速で頻繁なリリースの背景に適切な構成管理プロセスが存在することは、いうまでもないでしょう（参考：Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか？）

ITS／BTSはプロジェクト運営におけるハブ

　さて、構成管理の定義からすると、成果物を特定の時点に戻すために欠かすことのできない要素として真っ先に挙がってくるのはバージョン管理システムです。本連載でも第3回目以降の内容は全てバージョン管理システムを前提としています。

　ここで、一見すると構成管理の要素としては必要なさそうな、ITS／BTSによるプロジェクト運営をバージョン管理よりも先に取り上げているのには理由があります。

　それは私たちの経験上、ITS／BTSを利用することが構成管理をスムーズに進めるうえで重要な役割を果たしており、以下の2つの観点からそれを説明します。

【1】ソースコードやコミットメッセージに現れない情報

　ソースコードや環境に変更を加える際には、必ず何か理由があります。それはタイプミスの修正から、特定のWebブラウザや複雑な条件化で発生するバグの修正、新機能の追加、またはパフォーマンスチューニングの結果による設定変更など、多岐にわたるでしょう。

　簡単な内容であればソースコード上にコメントとして残すか、またはコミットメッセージに記載することも可能ですが、ある程度の分量を伴う場合には現実的に難しいことが数多くあります。

　そういった情報をITS／BTSに課題として登録しておき、コミットメッセージ内にチケット番号を残すことで、以下のような双方向からの追跡が後から簡単に行えます。

1. ある課題の変更がどのコミットでソースコード上に反映されているか
2. ソースコード上の変更がどういった理由や背景で行われたか

　ほとんどのITS／BTSがバージョン管理システムと連携する機能を有しているので、こういったことは容易に実現可能です。

バージョン管理システムとITS／BTSの連携イメージ

　適切に変更に関する情報を残すプロセスにしていたとしても、例えばスプレッドシートのようなバージョン管理システムと親和性が高くないツールで管理されていると、ソースコードや設定ファイル上で行われた変更の理由を探るのも一苦労です。当然、変更に対してかかる時間はより大きくなってしまいます。

　ITS／BTSを利用することで、変更に対する追跡が容易にできる、スピード感のある構成管理プロセスを実現できるといえるでしょう。

【2】役割が異なるメンバー間でのコミュニケーション

　ソフトウェアプロジェクトには、さまざまな役割の人間がかかわります。DevOpsでいうところの開発者と運用者のみならず、営業やデザイナ、広報やサポート、テスターなどプロジェクトを成功に導くためにさまざまな役割のメンバーとコミュニケーションをとりながら、協調して仕事を進めることが必要です。

　これらのメンバーの間では、構成管理の成果物になる手前にあたるコミュニケーションは日々たくさん行われています。これらのコミュニケーションをITS／BTS上で行うことで、以下のようなメリットが生まれます。

1. あらゆるやりとりの情報が一元管理される
2. 役割の違うメンバー間での協力体制を作りやすい

• メリット1：あらゆるやりとりの情報が一元管理される

　まず、前者についてですが、特にエンジニアではない役割のメンバーにとって、バージョン管理システムを操作することは現実問題として難しいことがあります。それと同時にそこでやりとりされる、スプレッドシートや画像、プレゼン資料などの情報が、後々重要になることも多くあります。

　「そういった情報も全てバージョン管理システムにチェックインすべきだ」というのは「プロセス」ありきの主張で、プロジェクトに携わるさまざまな「人」に主眼を当てた考え方ではありません。そうではなく、バージョン管理システムほどの厳密さはなくとも、「課題」単位でメンバー同士がコミュニケーションを取りやすいように設計されているITS／BTSは、構成管理に対して補完的な役割を果たすことになります。

• メリット2：役割の違うメンバー間での協力体制を作りやすい

　次に、役割の違うメンバー間での協力体制を作りやすい点についてです。DevOpsの観点からすると、ここがITS／BTSの非常に大きなメリットです。

　一例ですが、筆者たちが「Cacoo」の運営の中で、パフォーマンスの問題に直面したことがありました。インフラの担当者がDBの構成変更で、それを解決しようとしてタスクを開始しましたが、さまざまな試行錯誤の結果、アプリケーションの改修をしないと、乗り切れないことが分かりました。

　それまでの試行錯誤の途上で、開発者とテーブルの使い方や発行されるクエリなどについて密にコミュニケーションを取りながら作業を進めており、またDBのチューニングによるテスト結果なども共有していましたので、「アプリケーションが悪い」「インフラが悪い」といった議論ではなく、「パフォーマンスの問題を解決する」という共通のゴールに向かって協力できました。

　これは、同じITS上で常に情報共有をしながら仕事を行っていたからなし得たことです。

　もし、役割の違うメンバーが別々にタスクを管理していた場合には、お互いの仕事に対して何らかのフィードバックを行うことは、ここまで簡単ではないでしょう。

　ITS／BTSでは各ユーザーのタスクは、その他のメンバーに対してオープンに共有されます。情報をオープンにすること、関係するメンバー全員がそれに対してアクセス可能にしておくこと、これらは役割を越えた協力体制を生み出すための1つの鍵といえるでしょう。

　このように、ITS／BTSはソフトウェアの開発プロジェクトにおける情報やコミュニケーションのハブとして機能し得るもので、以下の図で示すように構成管理とは強い補完関係にあります。こういったことから、筆者はこれから構成管理のプロセスを考えるうえでは、併せてITS／BTSの利用を検討することが重要だと考えています。

ITS／BTSの立ち位置