価値の見つけ方

前回は，第1回から継続して「正しいモノを作る」方法について説明しました。今回はその先として，作ったモノをユーザに届け，「⁠フィードバックから改善する」方法について話し，価値を提供するプロセスサイクルを完成させます。そして最後に『失敗を許容し挑戦を奨励する』文化の重要性をお話したいと思います。

リリースも自動化する

「正しいモノを早く・繰り返し作る」ことができたら，それをユーザに届けて使ってもらわなければなりません。リリース作業も自動化し，すばやくユーザにサービスを届けましょう。

Bambooは，モノを作る「ビルド」だけでなく，モノを届ける「デプロイ」も自動化できます。ビルドで作った成果物をそのまま実行環境にデプロイしてみましょう。Bambooのデプロイではタスクを順番に処理するので，「⁠ビルドの成果物をダウンロードする」⁠→「⁠実行環境に成果物をアップロードする」⁠→「⁠サービスを再起動する」といったタスク実行ができます。

異なる環境にデプロイする

実際の開発プロセスで成果物をいきなり本番環境にデプロイすることは少なく，まずステージングやユーザ受け入れテスト（UAT）などの検証環境でテストを行うと思います。Bambooのデプロイでは，実行環境を複数用意し，開発／ステージング／本番などの環境ごとにタスク実行を管理できます（図1）⁠。

それぞれの実行環境はBitbucketのブランチと紐づけられ，次のような一連のプロセスのうち「ブランチへのマージ・コミット」と「実行環境でのテスト」以外を自動化できます。

1. Bitbucketでタスクごとに開発ブランチを作り，コミットする
2. Bambooで開発ブランチのコードでビルドする
3. Bambooで開発環境にデプロイする
4. 開発環境でテストする
5. Bitbucketのリリースブランチに開発ブランチをマージ・コミットする
6. Bambooでリリースブランチのコードでビルドする
7. Bambooで検証環境にデプロイする
8. 検証環境で受け入れテストを実施する
9. Bitbucketのマスタブランチにリリースブランチをマージ・コミットする
10. Bambooでマスタブランチのコードでビルドする
11. Bambooで本番環境にデプロイする

ビルドやデプロイが自動化できると，チームはコードを書くことや手動テストに注力でき，より価値のあるサービスを生み出せます。

作りなおせる環境で動かす

最近では物理サーバに直接デプロイせずに，仮想環境またはクラウドやコンテナのようなサービスを利用することも多くなっています。たとえば，次のような場合があります。

• 仮想環境にAnsibleなどの構成管理ツールを使って構築する
• Dockerなどのコンテナサービス上に構築する
• HerokuといったPaaSからアプリケーションを提供する
• AWSのCloudFormationなどでプロビジョニングして構築する

これらのサービスに共通することとして，コードで環境構築を管理できる点が挙げられます。構成管理の設計をコードで作成することで，実行環境の作りなおしやスケールアウトが容易になるなどのメリットがあります。また，コードをBitbucketでバージョン管理したり，環境構築をBambooで自動化したりもできるので，運用担当者の作業は「サーバの調達・キッティング」から「構成管理のコーディング・テスト・ビルド・デプロイ」に変わっていくと思います。

フィードバック対応の効率を高める

ユーザにサービスを使ってもらうようになると，要望や質問，障害といった問い合わせが届きます。そのほかにも，潜在的な問題が徐々に明らかになったりします。このようなフィードバックへのすばやい対応は，ユーザ満足度の維持・向上につながります。

問い合わせに効率よく対応する

ユーザからの問い合わせへの対応には次のような課題があると耳にします。

電話やメールなどで個別に対応した結果，内容や経過が正しく記録されない
• 問い合わせの内容をファイルで管理しているが，最新のものがわからなかったり，時間とともにファイルサイズが大きくなったりして確認が困難になる
• 過去に似た問い合わせがあっても情報が共有されていないため，新たに調査・対応を行ってしまう

このような課題を改善する手段の1つとしてサービスデスクツールがあります。AtlassianのJira Service Desk（以下，JSD）の場合，お客様専用のポータルサイトで問い合わせを受け付けてJiraの課題を作成するので（図2）⁠，次のような運用ができます。またJSDはITILのサービスオペレーションにも一部準拠しています。

• 要望・質問・障害といった問い合わせの内容ごとに課題タイプやワークフローを作り，対応フローを確立できる
• 問い合わせに関するユーザとのやりとりが課題のコメント欄に記録される
• 「問題管理」や「開発」といったJiraのほかのプロジェクトに課題を起票し，問い合わせの課題とリンクさせて情報を共有できる
• 対応時間を表示させてSLA（Service Level Agreement）への対応を管理できる
• Jiraのラベルやフィルタ機能を利用して類似問題のカテゴライズや検索ができる
• 情報共有ツールのConfluenceと連携してナレッジデータベースを作成し，よくある質問への回答（FAQ）を公開できる

サービスの監視と通知

稼働中のサービスからは，重大な障害を検知したり，有用な情報を取得したりできます。

• サーバのリソースが想定を超えて消費されていないか
• ユーザには認識されていないエラーやリトライ処理が発生していないか
• 不正なアクセスが発生していないか
• エラーの発生はユーザのどのような操作によって引き起こされたか

これらの情報はおもにアプリケーションやOSのログに出力されます。ログは，利用者や機能の数，稼働期間によってサイズが大きくなるため，効率的な収集と必要な情報を欲しいときに得られるしくみが重要です。また，障害を検知したらチームに通知し，自動の復旧を試みるなどの対策により，迅速に対応できるようになります。

先日開催されたAtlassian Summit 2018では，インシデント管理ツール「Jira Ops」が発表されました。インシデントの発生・検知から解決までを一元管理でき，障害対応の効率化と早期解決に役立つツールです。

ひきつづき後編では，得られたフィードバックからツールを活用してさらなる価値を見つけ，プロセスサイクルを一連のものにします。