ソフトウェアの力がビジネスや生活に欠かせないものになりつつある今日。すべてのソフトウェアがミッション クリティカルであるといっても過言ではない世界がやってくるかもしれません。IT エンジニアにとっては、やりがいのある世界になることを意味しますが、当然、そこに求められるものは、今までの比ではなくなってくるかもしれません。
これらをよく、QCD という 3 文字略語で表すことがあります。
QCD とは何を示すのでしょうか。いろいろな 3 文字略語として用いられますが、ここでは、Q: Quality、C: Cost、D: Delivery としましょう。日本語にすると、「高品質」、「低コスト」、「短納期」という表現をします (*1) 。

この 3 つが求められているということは、相反する要求を突き付けられていることを意味します。質の高いものを開発するには、今まで以上の手間 (コストや時間) をかける必要がでてきますが、手間もかけずに実現することが求められるわけです。さらに複雑化していくシステム、ソフトウェア、それに伴い開発チームも複雑化し、利害関係者も多岐にわたるわけですから、言ってみれば無理難題を言われているようなものです。しかし、ソフトウェアが必要とされればされるほど、この状況は避けて通り事ができません。なんとかこの課題を克服する必要がでてきます。
*1. 本来、QCD とは、「適正品質」、「適正コスト」、「適正納期」と表現すべきです。どちらにせよ、現実としてみると本当の意味での「適正」とはなっていないケースが多く、相反する要求に対応しなければならない現実に変わりはありません。
相反する要求を満たすということは、「今まで」と同じやり方で対応できるのかを真剣に検討する必要があるということを意味しています。今までと同様に行うべき成功しているポイントと、改善しなければならないポイントがあるはずです。「今まで」と同じやり方で対応しようとすると、きっと何かを犠牲にしなければならなくなります。たとえば、IT エンジニアの貴重なプライベートな時間などを。
まず、現状を認識、把握することからはじめて、継続実施すべきこと、改善すべきことを共通認識として持つことが大切になります (*2.)。
*2. 開発プロジェクトにおいては、プロジェクトの終了時に行うべく、振り返りを行わないケースが目立ちます。プロジェクトを回した際には必ず成功体験と失敗体験があるはずで、どちらも今後のプロジェクトで活かすことができる大事な資産となるはずです。
では、具体的に何を行う必要があるのかを考えてみましょう。当然そのソフトウェアの性質や組織、チームによって状況は異なります。ただし、大きな枠組みでみると、おそらく以下の二つを考えていくことが最終的には、必要となってくることでしょう。
この二つを考えることで QCD に対応できると仮定し、つぎにこの 2 つに着目し、現状のプロジェクトを振り返ってみることで、今後の改善ポイントが見えてくるはずです。
品質とコスト、納期を適切にすることを考えるならば、如何に再利用可能なアセットを構築し、適切に再利用を行っていくことが効果的ではないかということはだれも想像つくことではないでしょうか。
ここで、重要なのは再利用するアセットは、その状況により様々な粒度となることです。アセットが、クラス ライブラリであったり、デザイン パターンや、フレームワークであったり、コントロールやコンポーネントであったり、または、より大きなコアとなるパッケージであったり、ソリューション パッケージであったりするかもしれません (*3)。そして忘れてはいけない大切な再利用アセットとして、開発プロセスや、プラクティスといったものもあります。
*3. たとえば、ここ数年の動きとして、システム インテグレーションにおいて案件ごとにスクラッチからシステム開発を行うよりも、予め、様々な案件で利用できるシステムのコアをパッケージとして構築しておき、このパッケージをベースにカスタマイズや拡張機能を開発し適用するパッケージ+カスタマイズといった再利用が検討され、実践されています。
余談ですが、そういったパッケージのプラットフォームとして、マイクロソフトの SharePoint Server や Dynamics などが力を発揮します。
再利用性を高めるときには、再利用が可能であることと、実際に再利用されることが大前提となります。再利用されるかわからないアセットに必要以上に時間を割くことは、返ってコスト超過を招く危険性もあるからです。
利用されるには、どうすべきでしょうか。再利用可能なアセットのライフサイクルが明確である必要があります。そのアセットがいつ利用できるようになるのか?バグや制限はないのか?フィードバックを受け入れてくれるのかなどが不明瞭では安心して利用することができません。
再利用を可能にするためには、再利用アセットを作成するチームとそのアセットを利用する製品やシステムを構築するチームを分離することや、これらのチーム連携をも考慮する必要があります。これらのチーム間の連携を考慮するということは、当然、各チームの開発プロセスや規約などが徹底できていることも重要なポイントとなります。すなわち、開発方法の再利用ということです。

このように、再利用そして、チーム開発を考えていくと、なかなかうまくいかなかったものをよりよい循環に転換することが期待できそうです。
ただし、これらを実践するには、一朝一夕にはできないことも忘れてはいけないポイントとなります。ステップを踏みながら、ある意味コツコツを実践していくことが回り道をしているようで案外近道であったりします。
最後に、改善活動には、チームメンバーの協力が不可欠であることを明確にしておきたいと思います。自分たちが楽をする、より本質的な作業に専念できる環境を作るために、「今のやり方を変えたくない」、「余計な作業を増やしたくない」と頭ごなしに言うのではなく、できることからコツコツとやっていき、素晴らしいソフトウェアを提供し続けてほしいと願います。
今回のコラムはいかがでしたでしょうか?いつもより堅いコラムにしてみました。充実したエンジニアリング ライフを満喫するためにも、より価値のあるソフトウェアを提供し続けるためにも、ぜひ再利用やチーム開発、そのほかのことでもいいので、皆さん、そして皆さんのチームで考えるきっかけとなれば幸いです。
マイクロソフト株式会社
エバンジェリスト
長沢 智治 (http://blogs.msdn.com/tomohn)