（TFSUG 世話人/E-Agility 協議会 実行委員/ASTER ツールWG メンバー）
ビジネスが求める価値を提供し続けるために
情報システムをビジネスという視点で見ると、常にまずアイデアがあり、それをプロダクトやサービスという形にし、そこから出てきたデータから学ぶという流れがある。以前のビジネスでは、このサイクルを一回、回せばよかった。ビジネスモデルを固定できたからだ。
しかし、今あるビジネスはどんどん変わっていく。なぜなら、次々に新しいテクノロジーが出てくるからだ。市場の動向が変わり、競合が想定外のことをやり始める。お客様の意識も変わる。対抗するためには、ITの力が不可欠だ。長沢氏は「開発と運用がシームレスに連携し、フィードバックの流れが価値の流れを形成し、開発作業からビジネスまでのサイクルが繋がっていることが必要」と指摘する。
続いてITの世界にフォーカスすると、ビジネスが回っている中で、ITをフル活用する時代になっている。その世界観の中では、ITの価値がビジネスにマッチしていないと、ボトルネックになってしまう。その分かりやすい例として長沢氏が挙げたのがMTTR（Mean Time To Repair）。平均復旧時間だ。ITがビジネスに力を発揮できなくなったとき、いかに早く戻せるかが問われている。
長沢氏が着目する第3の視点は「価値を提供し続けるIT」のためのサイクルタイムだ。ビジネス価値に優先順位をつけ、受け入れ基準を満たした動くソフトウェアを早く提供する必要がある。ただ早ければいい、というだけではない。ビジネスのリズムに合わせなければならない。
今、よく言われているのは、定期的に提供することの有用性だ。例えば2週間に1回のリズムで、価値のある物を作ることができれば、ビジネス側がITに協力してくれるようになる。逆にリリースのサイクルがまちまちで、いつ自分がほしいものが出てくるか分からないと、協力できない。ビジネスのアイデアを、実際にデプロイするまでの期間を安定させる必要がある。
そのための一つの方法が、スクラムのタイムボックス利用による、定期的な提供リズム作りだ。開発チームは自分たちのポテンシャルを見て、例えば2週間で作れる物を選び、確実に作っていく。
もちろん、品質という問題もある。サイクルを回していくということは、ウォーターフォールでいうところの、要件定義、設計、実装、テスト、デプロイを何回も繰り返す形になる。もちろんテストは必要に応じて行った方がいい。しかし多くの場合、テスト用の開発環境上で行われ、本番に近い環境上では実行されていない。受け入れテストも同様で、特に手動のテストは、その環境でしかやらない。
長沢氏は「それではもったいない」と指摘する。テスト資産は、工程に関わらず常に活用することで安定し、開発側が安心できる開発環境になる。プラクティスもツールも、進化しており、運用環境に似た環境を仮想で用意できるようになっている。そこにデプロイし、テスト資産を常に動かし続けることが可能だ。
リズムを作り、資産をうまく活用できるようになっても、開発を難しくしている要因として長沢氏が挙げるのが資産の分散だ。要件定義書、設計書、ソースコード、バグ票などが別々の場所、ツールで管理されている。それぞれの相関関係や、時系列的な経過などをたぐっていきたいのだが、ツールが別だとトレースできない。そのため開発者には、開発能力よりも情報収集能力が求められる事態になっている。つまり、本業に集中できていない。
開発の透明性を確保し、運用ともコラボレーション可能にする環境を披露
以上のような課題を解決する手段の一例として、長沢氏は一連のデモを披露した。使用されたプラットフォームは、現在リリース準備が進められているVisual Studioの最新版2013だ。
Visual Studio 2012の時点で、チームコラボレーションなど、DevOpsにも対応した開発環境がすべて用意されている。次の2013での長沢氏のイチオシは、デベロッパーソーシャルだ。タイムラインの形で、開発現場で起きていることが全部出てくる。チャットもできるし、誰かがバグ票を作成すれば、自動的に入ってくる。その機能が、Team Foundation Server 2013に組み込まれている。また、ソースコードレベルでディスカッションを行ったり、ソースコードのエディタにテストの実施結果などが表示される。
最初のデモのテーマは透明性。Team Foundation Server 2013によるWebページ上で、すべての開発情報が見える化されている様子が披露された。要件のレベルから、実際のプロジェクトのタスクのレベル、ソースコードの変更、ビルドの結果。なぜならすべての情報が1つの中で管理できているからだ。
トレーサビリティも確保されており、要件からテストケース、絵コンテ、タスクが全部、紐付けられている。例えば要件をクリックすると、要件に関するタスクがわかる。各タスクから変更セットを辿れる。それはそのままソースコードであり、それに対してディスカッションができる。デベロッパーソーシャルだ。ソースコードは必ず、変更セットと共に、タスクやバグと関連づけられている。
続けてビルドから見てみると、どういう変更が、誰によって行われたのか、その結果、どのタスクが実行されたのか、そのタスクは、どの要件を満たすためにやったのか、全部の記録が残る。それらを元にグラフを自動生成する機能などもある。
続いて行われたデモのテーマはMTTR。運用からのフィードバックに、いかに開発が反応し、いかに正しく対処できるのかだ。その前提は、開発の透明性の確保になる。
使用されたマイクロソフトの運用監視ツール上で、問題発生のアラートが上がると、一回のクリックでステータスを変えただけで、開発側に伝えることができる。すると開発側の画面では、未解決の運用課題の件数が増える。クリックすると、運用側から上げられたアラートが全部分かる。運用上、どういう問題があるのかなど、細かい情報もすべて入っている。即時デバッグも可能だ。
それでも情報が足りなければ、「もう少し情報が欲しい」とメッセージを添えて保存すると、運用側に伝えることができる。
実はVisual Studioには、インテリトレース（IntelliTrace）という、デバッグの巻き戻しができる機能が以前からある。2012バージョンから、それを本番環境で動かすことができるようになった。この機能により、本番環境で起きた障害を、開発環境で再現できない、という問題を回避できる。
本番環境のデバッグ情報を元にして、ソースコードのどこで落ちたのか。その時の変数でどういう値が入っていたかなど、すべて分かる。修正作業を終え、ソースコードをコミットすると、継続的インテグレーションが走る。それによりビルドやコード分析、アーキテクチャ上の違反、全部チェックされ、何か問題があればコミットが拒否される。「結果、ソースコードにゴミが残らないので、他の人に迷惑をかける心配をせずにゆとりを持って作業とコミットができる」（長沢氏）。
続けて行われたデモのテーマは、テストから本番環境へのデプロイの自動化だ。作成したオートメーションのフローに従い、まずデプロイすることが決まったら、Team Foundation Serverに格納されている開発リソースに、運用のツールが直接入り、そこで必要なビルドを実行したり、バグの状況を確認したりする。その上で問題がなかったら、仮想化されたラボ環境を自動生成し、そこにデプロイし、テストする。さらに問題がなければ、本番環境にデプロイされる、という流れだ。
ここまでのデモを通じて、長沢氏が重要なポイントとするのが透明性だ。そこで、最初からのフィードバックのサイクルがうまく回っていると、運用を含めた渦、うねりを作ることができる。そうすると開発現場はものすごく強くなる。「正しいものを正しくやる環境とは、こういう物のことをいう」（長沢氏）。
もう一つのポイントは開発と運用がお互いを尊重し、理解することで新たな仕組みが生まれることだ。
最後のデモでは、Team Foundation Server 2013から利用可能になるデベロッパーソーシャルが披露された。開発上で発生するさまざまなイベントが、タイムラインに載ってくる。すべてがハイパーリンクになっており、意志決定がしやすくなっている。しかも全部、トレーサビリティが取れた状態だ。開発者がやるのは、単に関連づけてチェックインするだけ。追加負担はほとんどない。マネージャーは、「温かく見守ってフォローするだけ、という環境を作ることができる」（長沢氏）。
長沢氏は「自分たちの能力が足りない部分と時間をツールで補う」という発想をもって欲しいと語る。Visual Studioにはさまざまなエディションがあるが、能力のある人はProfessionalを使い、スキルが足りない人は最上位のUltimateを使うとツールがカバーしてくれる。高機能イコール上級者向け、という考え方は誤りというわけだ。
長沢氏は最後に「以前は考えられなかったプラクティス、ツールが今は揃っている。活用して欲しい」と呼びかけ、セッションを閉じた。
