そのソフトウェアのビジネス価値は？
まずは、ビジネス価値が曖昧なソフトウェアがなぜ作られてしまうのかについて、「クラウドを活用したコスト削減」を例に解説したいと考えます。
IT業界では近年、「クラウド」が重要視されています。
クラウドとは、ITリソースを必要なときに必要な分だけ利用できるよう複数の組織で共有し、そのリソース管理を一箇所に集中させることで管理コストの大きな削減効果をもたらすものの総称です。
これは確かに合理的な考え方であり、クラウドを効果的に活用している組織も少なくないはずです。ただし、管理コストやリソースの保有量が減ることは、果たしてビジネスの価値になりえるのでしょうか。
例えば、社内サーバをクラウド環境に移行した組織があるとします。また、この組織では、クラウド環境の有効活用を目指して運用の一元管理を実現するソフトウェアを導入し、結果として運用担当者の作業工数を従来の10分の1に圧縮することに成功したとしましょう。この一点だけをとらえれば、クラウド活用の効果は大きいように思えますが、もし仮に、導入したサービスの利用環境がこれまで使用してきたアプリケーションと大きく異なるために、クラウドの利用者全体の作業効率が従来の3分の2に落ちてしまったとしたらどうでしょうか。そうなれば、おそらく作業効率の悪さを理由にクラウド環境を使わない人が出てくるはずです。
また、利用者の一部がクラウド環境とローカル環境で2重の管理を始めてしまい、利用者の管理作業が煩雑化してしまうおそれも強まります。
この場合の対処方法として、二重管理を行っている利用者の煩雑さを解消する機能をソフトウェアに追加するといった手だてが考えられますが、そのような利用者側の要望をソフトウェアに反映し続けた結果、ソフトウェアの構造が複雑化し、改修時の費用が膨大になるケースは珍しくありません。また、改修が頻繁に発生することで、それに対処する運用担当者の工数が従来の数倍に跳ね上がる可能性もあります。もしそうなれば、先に示したクラウド活用のコスト削減効果はすべて帳消しになるのです。
目的と手段の階層構造を意識する
上の例では、話を分かりやすくするために少し極端なケースを示しましたが、実際に似たような状況が生じることは少なくありません。
この例からも分かるとおり、ソフトウェアを活用するうえでは、運用コストの削減に寄与しているかどうかだけではなく、組織としての利益率向上につながっているかどうかを見定めることが非常に重要です。
また、コスト削減を目的にクラウドを導入するにしても、削減分を別の戦略投資に振り分けることが求められるはずです。というのも、クラウドの活用は本来、組織のビジネスを強化する、あるいは支援するための「手段」だからです。
ところが現在は、そうした本来目的をどう達成するかではなく、「クラウド環境を構築するためにどうすればよいか」という、本来目的の一段下の層に位置する「手段」について、その現象面での是非を判断し、対処方法を検討／遂行しているにすぎません。実は、これこそが最大の問題と言えるのです。
ソフトウェアの開発には、目的と手段の階層構造が存在します。開発に関わる関係者は、この階層構造を常に意識しながら作業を進めなければなりません。さもないと、開発の本来の目的を見失うことになりかねないのです。
サイロに入ってしまっていないか？
近年のソフトウェア開発では、ソフトウェアの複雑化や大規模化によって、各作業に専門性が求められたり、1つのプロジェクトを複数のチームで進めたりするケースが増えています。
前述したクラウド活用の例で言えば、クラウド環境を支えるハードウェアなどのインフラ導入を担当するチームと、クラウド環境に合わせた業務を企画するエンドユーザーのチーム、さらには、業務に合わせたソフトウェアを開発／導入するシステム会社が、それぞれの役割を担う場合があります。また、システム会社の中でも、発注元の要求を獲得してまとめ上げる人たちと、設計・実装を行う人たち、そしてテストを行う人たちが別チームとして構成されるケースがあります。
このように複数のチームから成るプロジェクトの場合、各チームがそれぞれの役割に集中することはとても重要です。ただし、各者が自分たちの役割に集中しすぎると、チーム間に垣根が生まれ、プロジェクトの障害となります。より端的に言えば、「各チームの仕事が最終的に統合された際にどうなるべきか」という視点でのレビューやテストがおろそかになるというわけです。これを、「サイロ(Silo)現象」と呼びます。
サイロとは、もともとは「貯蔵庫」という意味で、一般的に貯蔵庫には窓が無く周囲が見えないことから、「周りと連携せず孤立して仕事をしている状況」を表す言葉としてよく用いられます。このサイロ現象が起きると、開発中のソフトウェアが本来目的を達成しうるか否かを判断し、達成できないと判断された場合にチーム間の調整をすみやかに行うことが困難になるのです。
チーム間の垣根を越えて開発を進める
サイロ現象を回避する手だてとしては、すべてのチームを統括するプロジェクトマネジャーを配置するという方法が一般的です。確かに、プロジェクト全体を総括してチーム間の調整を取り仕切る人がいることは非常に重要です。ただし、それだけで問題が解決されるわけではありません。すべてのチームが、チーム間の垣根を超越した見地に立って連携を取ることが同時に求められます。
当然のことながら、プロジェクトとしての成果は、要件定義やシステム設計が完了したときできはなく、開発したシステムがその本来目的を満たすことが確認できて初めてもたらされるものです。
ですから、本来目的を達成しているかどうかの確認をおざなりにせず、それをチーム同士が垣根を越えて連携するための情報収集の手段としてとらえることが大切です。またそうしたほうが、仕事を「仕上げる」スピードが速くなるのです。
以上、今回はソフトウェア開発で意識すべき2つのポイント――すなわち、「目的と手段の階層構造」と「チーム間の垣根を越えた開発」について論じました。次回は、テストやレビューの重要性について解説する予定です。
※ これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新
シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（2）」として連載したものを転載したものです。