2. アプリケーション性能管理を行うための情報活用体制

　

繰り返しを前提とした開発モデル
近年のアプリケーション開発では、将来に渡っての継続的なリリースを前提とし機能や性能の向上を繰り返し続けるような開発モデルが選択されるケースが多くなっています。

このモデルの下では、アプリケーションの機能・性能・品質を高めるために、開発ライフサイクルの工程全体（機能・性能要求→設計→実装→テスト→ 運用→ユーザ経験フィードバック）を通して効率化し、出来るだけ（質量共に）多く、このサイクルを循環させることが最も重要であると言われております。

対象範囲が広がる困難さ
ただ、工程全体や繰り返しのライフサイクルを意識した情報の共有や蓄積は従来のアプローチよりも広い範囲を視野に入れなければならないため、情報共有やコミュニケーション手法の向上が伴っていなければ、新しい方法論に実態が追いつけず期待した成果が得られないことになります。

とりわけ、性能管理の場面では、まず、個別の数値計測ありきで、さらに反復実施等により膨大な数値やケース情報を管理する必要があり、1回のリリースだけで再利用しきれない程の情報が蓄積され、その効果的な管理や、活用が十分行い尽くせていないのが大半の現況です。

情報管理に必要なこと
まずドキュメントです。品質を意識してきた多くの開発現場では既にこの点は出来ているかと思いますが、要件・設計・計画・レポート等をスプレッドシートや他のドキュメントツールでファイルに書き出していきます。これは各担当者間の情報の受け渡しや継承のために非常に欠かせない重要な作業です。

かつてはドキュメントの量と質がアプリケーションの品質そのものだとも言えました。

コミュニケーション
次に、軽視されがちですが担当者間の相互の意思疎通を重視すべきです。情報は解釈されて理解されるものですが、例えば、開発者とテスト担当者と運用者では、それぞれアプリに対するスタンス、考え方や組織文化が異なることが多いため、協働の際に様々なオーバヘッドが生じます。また、相互理解、忌憚の無い意見伝達、信頼関係等が構築されている環境では、誤解、疑心暗鬼、責任回避・転嫁、無用な対立等が避けられます。そのため、担当者間の、密接なコミュニケーション、出来れば私的な交流（飲み会、パーティ等も）を持つことを促進し、相互理解と親近感の醸成に努めることも重要であると言えます。

情報の統合と自動収集化
例えば、開発ライフサイクルの過程で、通常下記のような情報がドキュメント化され蓄積されて行くものと思います。

* プロジェクト運営に関するもの
* 開発工程管理に関するもの
* 不具合情報
* テスト要件
* テスト実行工程
* ケース別の性能計測値
* 要望・要件リスト

それぞれは、互いに共通の情報を含みながらも、担当部門が異なる場合には、それぞれ別の体系やフォーマットで作成される可能性があります。

まず、これらの情報源を一元化することで、工程全体の共通の情報伝達の基盤を形成します。

一元化によって必要となるもの
扱う情報量は飛躍的に増加しているため、各情報のフォーマットを定型化し、また、見出しや検索によって簡単に必要な情報を取得出来るような仕組みの用意が欠かせません。

サイクルを俯瞰する
次に、例えば、工程毎の進捗、件数、成功率、過去のサイクルと比較を行ったり、他の部門の動態をマクロ的に把握したり、蓄えている情報を活用する仕組みも必要です。

管理は測定から始まりますが、単に多量のデータを保有するだけでは無く、ライフサイクルの向上への端緒に繋がらなければ、管理とは言えません。

特に、アプリケーションの性能管理を行う際に、これらの基本的な情報共有手法を伴っていなければ、テストや計測を形だけ行っても効果的な成果には結び付けられにくいものです。