（TFSUG 世話人/E-Agility 協議会 実行委員/ASTER ツールWG メンバー）
ビジネスが求める価値を提供し続けるために
情報システムをビジネスという視点で見ると、常にまずアイデアがあり、それをプロダクトやサービスという形にし、そこから出てきたデータから学ぶという流れがある。以前のビジネスでは、このサイクルを一回、回せばよかった。ビジネスモデルを固定できたからだ。
しかし、今あるビジネスはどんどん変わっていく。なぜなら、次々に新しいテクノロジーが出てくるからだ。市場の動向が変わり、競合が想定外のことをやり始める。お客様の意識も変わる。対抗するためには、ITの力が不可欠だ。長沢氏は「開発と運用がシームレスに連携し、フィードバックの流れが価値の流れを形成し、開発作業からビジネスまでのサイクルが繋がっていることが必要」と指摘する。
続いてITの世界にフォーカスすると、ビジネスが回っている中で、ITをフル活用する時代になっている。その世界観の中では、ITの価値がビジネスにマッチしていないと、ボトルネックになってしまう。その分かりやすい例として長沢氏が挙げたのがMTTR（Mean Time To Repair）。平均復旧時間だ。ITがビジネスに力を発揮できなくなったとき、いかに早く戻せるかが問われている。
長沢氏が着目する第3の視点は「価値を提供し続けるIT」のためのサイクルタイムだ。ビジネス価値に優先順位をつけ、受け入れ基準を満たした動くソフトウェアを早く提供する必要がある。ただ早ければいい、というだけではない。ビジネスのリズムに合わせなければならない。
今、よく言われているのは、定期的に提供することの有用性だ。例えば2週間に1回のリズムで、価値のある物を作ることができれば、ビジネス側がITに協力してくれるようになる。逆にリリースのサイクルがまちまちで、いつ自分がほしいものが出てくるか分からないと、協力できない。ビジネスのアイデアを、実際にデプロイするまでの期間を安定させる必要がある。
そのための一つの方法が、スクラムのタイムボックス利用による、定期的な提供リズム作りだ。開発チームは自分たちのポテンシャルを見て、例えば2週間で作れる物を選び、確実に作っていく。
もちろん、品質という問題もある。サイクルを回していくということは、ウォーターフォールでいうところの、要件定義、設計、実装、テスト、デプロイを何回も繰り返す形になる。もちろんテストは必要に応じて行った方がいい。しかし多くの場合、テスト用の開発環境上で行われ、本番に近い環境上では実行されていない。受け入れテストも同様で、特に手動のテストは、その環境でしかやらない。
長沢氏は「それではもったいない」と指摘する。テスト資産は、工程に関わらず常に活用することで安定し、開発側が安心できる開発環境になる。プラクティスもツールも、進化しており、運用環境に似た環境を仮想で用意できるようになっている。そこにデプロイし、テスト資産を常に動かし続けることが可能だ。
リズムを作り、資産をうまく活用できるようになっても、開発を難しくしている要因として長沢氏が挙げるのが資産の分散だ。要件定義書、設計書、ソースコード、バグ票などが別々の場所、ツールで管理されている。それぞれの相関関係や、時系列的な経過などをたぐっていきたいのだが、ツールが別だとトレースできない。そのため開発者には、開発能力よりも情報収集能力が求められる事態になっている。つまり、本業に集中できていない。
