連載ALM（10）ビジネス成果をもたらすソフトウェアを開発するために

  • ゆもつよ｜

ビジネス価値を考慮したソフトウェア開発の実現に必要な２つのこと

　ITを活用し、ビジネス成果をもたらすためにはさまざまなアプローチが必要です。近年では、クラウドの活用やSNSの活用などのアプローチが提唱されています。また、それらを支えるインフラ技術についてもさまざまな技術が出てきています。しかし、どのようなアプローチを採用したとしても本質的に重要なことがあります。本連載では、以下の2点を利用者にとって重要なポイントとして提示してきました。

  • ビジネス価値の達成度合いの確認を利用者ができるようにすること
  • ビジネススピードに開発のスピードが合うようにすること

ビジネス価値の達成度合いの確認

本連載で提示したことの1つが、「ビジネス価値の達成度合いの確認を利用者ができるようにすること」です。まず、本連載の1回目にて、「品質の相対性」についてご紹介しました。「ビジネス価値があるソフトウェア」であるかどうかを判断するためには、人や場面の考察が必要になります。価値達成の判断は利用者自身が判断するようにしなければならず、そのためには、本来目的を達成していることを確認した結果--つまり、テストやレビューの結果--を利用者のもとに集約すべきです。

　そして、本連載の2～4回目では、テストの位置づけを見直すことについて言及しました。テストを通じて開発中のソフトウェアがビジネス要求を満しているか否かを確認できるようにすることが必要であり、そのためには、開発量と比例させてテストの量を決めるのではなく、「要求の階層化」と「テストと要求のひも付け」によってテストすべきことを適切に決定するのです。これはテストの計画/設計を行うことを指します。利用者は開発プロジェクトにおけるテストの計画／設計の内容の出来具合に留意すべきです。

　また、本連載の5回目、6回目では、「品質リスク」という考え方をご紹介しました。品質リスクの評価は、テスト計画/設計で決定したテスト量の調整を可能にしますが、同時にビジネス価値の判断が容易になるようにテストに優先順位をつけることでもあります。利用者は、品質リスクの軽減度合いをモニタリングすることで、ビジネス価値の達成度合いをモニタリングすることができます。

開発のスピードをビジネススピードに合わせる

　本連載では、ALM（アプリケーションライフサイクルマネジメント）についてもご紹介しました。開発のスピードをビジネススピードに合わせることは、ビジネス価値実現のために非常に重要になります。アジャイル、クラウド、SOAといったアプローチは、そのために提唱されているといっても過言ではないと言えますが、各アプローチの成功には、完全ライフサイクル（開発投資の計画や運用保守まで含めたライフサイクル）に対する考慮が必要です。完全ライフサイクルに対する考慮を実現するアプローチとなるのがALMです。

　本連載の8回目では、特に考慮すべきポイントとして、「技術的負債の管理」と「アプリケーション資産の管理」、そして「管理した結果を開発投資にフィードバックすること」の3点を提示し、これらを達成することがALMの実現であると述べました。

　また、本連載の9回目では、開発投資へのフィードバックスピードを開発スピードに合わせることがALMを理想論で終わらせないために重要であることについて言及し、スピードを一致させるためには、管理と自動化の融合が必要であることであると説明しました。同時に、ALM実現の阻害要因として開発チームの「惰性」があり、惰性を取り除くことがALM実現のために重要であることも述べました。

　実は、ALMの実現だけにかかわらず、ビジネス価値判断のためのテストを実現する際にも開発現場の惰性の問題はつきまといます。この問題は開発チームの問題であって、利用者には関係ない領域と思われるかもしれませんが、開発の現場にある惰性の克服を利用者も考慮することがスピードアップの実現、ビジネス価値判断のためのテストの実現に寄与します。

開発の現場にある「惰性」の克服

一般的には、惰性の克服のために重要なことは「可視化」だと言われています。可視化をしないと問題があることにも気付かないためです。ダイエットをしている人が毎日体重を計測したり、摂取カロリーを計測したりすることがよい例です。ただ、問題は、開発現場では、可視化することそのものが困難であり、「可視化しない」という惰性を克服する必要があるということです。

この解決のためには、開発されたアプリケーションの利用者の意識が重要になります。利用者は、可視化に積極的に関与する必要があります。といってもいわゆるマイクロマネジメントと呼ばれる、細かい干渉をしたり、その内容から短絡的な判断をしたりするべきだと言っているわけではありません。

利用者自らが実現したいゴール（ビジネス価値達成判断のためにテスト結果を利用者へ集約させることや、「現実」を開発投資へのフィードバックすること）を開発チームへ提示し、そのために可視化された情報を確認することが必要です。また、開発チームがソフトウェア開発の可視化を開発の業務のひとつとして位置付けることを利用者が認めることも重要です。可視化することで余計にコストがかかるという問題もありますが、可視化にかかるコスト以上に、全体としてコストダウンができれば問題ないのです。

以上、今回は、利用者として関与すべきポイントを整理しながらこれまでの連載を振り返りました。また、最後に開発の現場にある「惰性」の克服について触れました。本連載で述べてきた、利用者はどのように関与すべきポイントをうまく活用していただき、ビジネス成果をもたらすソフトウェア開発の実現に取り組んでいただければ幸いです。

※　これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新

　シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（10）」として連載したものを転載したものです。

タグ:
カテゴリ: