ALMを実現するための3大要素
ビジネスが要求する開発スピードを達成するために、「技術的負債」や「アプリケーション廃棄に対する対処」からのフィードバックを開発投資に反映させる――これが、前回紹介したALMの本質です。
ただし、実際の開発の中でこのような管理を実現するには、開発のスピードとフィードバックのスピードとを一致させなければならず、そのための手だてを講じる必要があります。今回のテーマである「マネジメントと自動化の統合」は、ALM実現に向けて両者のスピードを一致させるために配慮であり、手だてとなります。
「マネジメントと自動化の統合」をより具体的に言えば、本連載の第7回においてALM実現のための3大要素として挙げた「トレーサビリティの維持」と「プロセス間連携の自動化」、および「レポート（あるいは、分析結果）の作成」がそれに該当します。つまり、それぞれを実現させることが、ALMを実現可能なものにすることというわけです。
トレーサビリティの維持
トレーサビリティは、品質管理の世界で当たり前のように用いられている概念です。例えば、「1つの要求に対するテストが何件実施され、何件合格しているか」といったことを把握するためにトレーサビリティが必要になります（この点に関しては、本連載の第4回にて、「テストを整理して調整するための2つの成功要因」としても記載しています）。
プロセス間連携の自動化
一方、プロセス間連携の自動化についてですが、これを「1つの要求に対するテストが何件実施され、何件合格しているか」を例にして考えてみると以下のようになります。
まず、開発者が以下の2つの作業を実施する。
- アプリケーションに対するビジネス要求と、その要求が満たされているか否かを確認するテストケースをデータベースに保存する
- ビジネス要求を満たしたアプリケーションのコーディングを終了させ、ソースコード管理リポジトリにプログラムをアップする
次に、開発者によるプログラムのアップをトリガーにして、以下の一連の作業が自動的に実行されます。
- ソースコードのビルドを自動実行し、ビルドしたバイナリをテスト環境に自動的に配置する
- データベースに保存されているテストケースを自動的に実行する
- 実行した結果（合格／不合格の判定結果）を自動的にビジネス要求やテストケースに紐づけして保存する
- 不合格の場合は自動的に不具合レポートを作成し、開発者にメールで通知する
上記のような一連の連携作業を、人手を介さず行うことがプロセス間連携の自動化となります。上の例では、「要求管理」「テストケース管理」「ソースコード管理」「ビルド」「システム環境への配置」「テスト実行」「実行結果の収集」「不具合管理」の８つのプロセスの連携部分が自動化されています。
レポート（分析結果）の作成
ここで言うレポートの作成とは、上記の「トレーサビリティの維持」と「プロセス間連携の自動化」の結果として、開発に関与するすべての人たちのために状況を可視化させることを意味します。可視化といっても、手元にある情報をとにかくすべて列挙するような方法では本当の意味で可視化できているとは言えません。人の判断に必要な情報だけを、必要なときに入手できるようにすることが大切なのです。すなわち、「1つの要求に対するテストが何件実施され、何件合格しているか」を例にして言えば、「過去の傾向から、合格する割合は少なすぎるのか多すぎるのか」を判断したり、「今の進捗で今後の日程に影響が出るか否か」の判断を下したりすることが必要となります。そのため、それらの判断が下せるように情報を加工して報告することが状況の可視化――つまりは、レポートの作成に該当することになります。
ALM実現のカギは「IT化」
ALMを実現するための3大要素は、どれも開発マネジメント作業と呼ばれるものです。これらの作業を効率化するためにはALMツールを導入する必要があるのですが、単にツールを導入すればそれで万事がうまくいくわけではありません。カギは「IT化」です。
要するに、開発そのものを業務としてとらえ、販売管理や生産管理のアプリケーションを開発するときと同じように、要求分析や設計といった手順をきちんと踏み、開発プロセス全体を効率化するITを導入するのです。もちろん、その際には、他の業務システムを導入するときと同じような阻害要因に突き当たることにもなります。
ALM実現の阻害要因である「惰性」
開発のマネジメント作業は、コーディング／設計といった本来の開発業務とは一線を画したものであり、効率化のための投資がおざなりになってきた部分です。
しかし、トレーサビリティの維持やレポーティング（状況報告）などの作業はかなりの分量となるため、それらを人手に頼ったかたちで行っていると、開発チームの本来業務が圧迫されかねません。
それを避けるために、「開発メンバーにはマネジメント作業を行わせない」といったルールを定めたとしても、トレーサビリティの維持やプロセス間連携を1人のマネジャーが一手に担うというのが現実的ではないはずです。
さりとて、トレーサビリティの維持を放棄してしまうと、状況報告がリアルタイムに行えなくなり、「進捗度が何％で、未解決の不具合のうち日程内に対応できないものが何件ある」といった当日の結果が翌日にならないと報告できないといった事態に陥ります。しかもマネジャーは、そのための情報収集と分析に1日の作業時間のほとんどを費やさなければならなくなるおそれもあるのです。
大抵の場合、このようなマネジメント上のボトルネックは、マネジャー1人の問題であって開発全体の問題ではないと見なされがちです。また、そうした開発の現場で長い間仕事をしていると、マネジメント作業を効率化することで、どのような恩恵を受けることができるのかがわからなくなってしまいます。加えて、状況の可視化が進んでいないため、どこに問題があるのかが見えなくなり、結果として、問題解決に向けた有効な手だてが何なのか、どのような手だてを講じればよいのかもわからなくなるのです。
このような見えない状況では、「やり方を変えるよりも、これまでのやり方を踏襲したほうがよい」といった惰性が働きます。そしてこの惰性こそが、ALMを阻害する最大の要因であり、これを取り除くことがALMの実現につながるのです。
以上、今回は、ALMというアプローチの詳細の説明として、「マネジメントと自動化の統合」について具体的に説明しました。次回は、上で言及した「惰性」を排除するための方法について論じたいと思います。
※ これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新
シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（9）」として連載したものを転載したものです。