第1回　性能品質は開発工程全体で作り込もう

　性能要件の実現は重要だと認識しながら、「結局、性能は構築し終わるまで分からない」といったスタンスでプロジェクトに臨んでいないでしょうか。最初に性能要件を定義したあとは特に何もせず、カットオーバー直前にわずかな性能テストとチューニングを行うだけというケースを、筆者はよく見かけています。

　そのようなスタンスでシステムを開発しても、性能要件をしっかりと実現できる可能性は高くありません。カットオーバー直前にその場しのぎの対策をするか、巨額の追加コストをかけてハードウエア増強に走る、といった状況に追い込まれがちです。

　ITシステムの性能品質は本来、ライフサイクル全体を通して作り込むものです（図1）。設計、実装、テストの工程を通じて、システムの性能要件達成に取り組み、検証していく必要があります。

　本連載では「システムの性能を確保するために何をすべきか」というテーマで、性能をマネジメントするための考え方やノウハウを紹介していきます。

性能マネジメントの作業プロセス

　性能品質を作り込んでいくには、開発工程の早い段階からその工程に応じた対策を打っていくことが必要です。つまり、終盤のテスト工程になって初めて性能をチェックするのではなく、「実装までに性能を見極めておき、性能テストで想定の性能に収まっていることを確認するだけ」という姿勢で臨むべきです。各フェーズで取り組むべき作業を以下にまとめました。

要件定義：
　このフェーズでは、システムの目的を達成するのに必要な前提条件と目標値を性能要件として定めます。前提条件とは、処理対象となるデータ量や取引数、ユーザー数などを指し、目標値はレスポンス時間、同時接続ユーザー数、単位時間当たりの処理可能件数などを指します。

　終盤で性能が問題となる場合、実はここで定めた性能要件があいまいなものだったり、どう考えても実現不可能なものだったりするケースが少なくありません。本連載の第2回で、性能要件を具体化するポイントについて触れたいと思います。

設計：
　このフェーズではまだ動くプログラムがありませんが、ここで性能を考慮しながら設計することや、実装後の性能を予測して、顕在化した性能リスクへ早期の対策を行うことが、後のフェーズで致命的な性能問題の発生を防ぐことにつながります。

　本連載の第3回では、性能リスクを早期に発見するための性能見積り手法について紹介したいと思います。

実装：
　早期に性能リスクを排除するには実装したプログラムに対して、できるだけ早く性能テストを行うことが望まれます。しかし実装フェーズでは、本番想定量のテストデータを用意することが困難であり、機能面の不具合修正で頻繁にプログラムが改修されるため、正確な評価が難しいことが多いものです。

　そのため、このフェーズではリソース（CPU、メモリー）を大量消費するプログラムの排除に注力する方が効果的でしょう。本連載の第4回でリソースの大量消費につながりやすいDBアクセス部分の性能対策について紹介します。

テスト：
　性能要件が確保されていることを性能テストで確認し、問題がある場合はチューニングを行うわけですが、システム開発の終盤では性能対策だけにパワーを割けないのも実状です。そこで、有限な開発リソースを効率よく活用するためにも、機能の重要度に応じて対策にメリハリをつけるといった工夫が必要となってきます。

　本連載の第5回では、性能テストにおける実施ケースの選び方や、対策方針の考え方について触れます。

プロジェクト管理での二つの工夫

　性能を適切にマネジメントしていくためには、プロジェクト管理の面でも工夫が求められます。プロジェクトのマネジャーやリーダーが、性能にリスクのある機能がどれくらい存在し、そのリスクがシステム全体に対して、どれほどの影響を与えるのかを開発工程を通じて把握するための工夫です。筆者の経験から得た工夫を二つ紹介しましょう。

（1） 機能別に性能要件を一覧にする
　対象機能の目標レスポンス時間や前提条件を一覧にして常に見える形にし、顕在化した問題やその対策方針についても情報を集約して管理します。一見地味な工夫ですが、正確に状況を把握し、その場に応じた対策を講じるためには必要な取り組みと考えています。

（2） プロジェクト体制を工夫する
　特に大規模なプロジェクトでは、開発者によって技術面のスキルにばらつきがあります。そこで、プログラム開発者から独立した性能対策の専任者部隊を設立するのも工夫の一つです。

　専任者部隊が性能のチューニング案作成を支援したり、複数の開発チームが共同で解決すべき性能問題（共通プログラムのチューニングなど）に対してチーム間の作業調整を行ったりすることで、性能問題を早期に解決に導けるケースが多くなりました。