「はやく作る」と「しっかり作る」のバランス

再利用性と生産性の異なるベクトル

開発の現場の人と「再利用性」の話をすると、目を輝かせる人とそうでない人の2種類に大別される気がします。

前者は、基盤を作るのが好きな人で、いつかは自分でもフレームワークを、と思っています。目に見えないところにこだわる派ですね。後者はむしろアプリケーションの実装に興味のある人で、どれだけ便利なソフトウエアを開発したかとか、ユーザー要求に応えたかというところにこだわります。

ソフトウエアの開発にはどちらも重要なのですが、両者の考え方には大きな違いがあります。

ソフトウエアの再利用性を高めるには、設計したソフトウエアが、現在の要求以外のケースにも対応できる汎用性を備えていることが必要です。「その場限り」の設計では、融通が利きませんから、再利用性も落ちてしまいます。

一方、現在の要求に集中することを優先するのであれば、想定外の余計な可能性を考えるのは、むしろ無駄です。最小の労力で最大の効果を得るには、無駄は省くべきでしょう。しかし、再利用性が高ければ、全体の生産性は上がります。また、メンテナンスにも有利です。

実際の開発では、再利用性を高めることと、現在の要求に集中すること、この相反する2つのベクトルをうまく調整して、最大効果を得るようにすることが求められます。

ところで、筆者は、こうした取り組みを行っている情報システム部門の方から、面白い話を聞いたことがあります。以下に紹介します。

「システム開発は、対象とするユーザー別に3つに区分している」。

「1つ目は、顧客向け。満足度を高めるためにソフトウエア品質にも十分気を配らなければならない。社内向けの言い訳は通用しませんからね」。

「2つ目は、社内システム。社員の日々の業務にかかわるのだから、生産性、効率性を重視する。ある程度長く使われるものだから、プロセスとともに最適化されていなければならない」。

「3つ目は、その場限りのシステム。セールス・キャンペーン1つとってみても、今やシステムがないと始まらない。でも、長期間使うものじゃないから、むしろスピードが大事。すぐに結果を出せといわれたら、外見や操作性にこだわっている暇はありません」。

現場視点で考えると、この話は多分に真実が含まれているような気がします。今回着目したいのは、3つ目のケース「短時間で作るシステム」です。

小さいシステムを「素早く作る」

システムに対するユーザーの要求は日々大きくなり、扱う技術も幅広くなってきています。このため、ソフトウエア開発プロジェクトは、肥大化、複雑化する傾向にあります。

それでも、生産性を高めるツールや便利なフレームワークがあるおかげで、開発者が扱わなければならない領域は、ソフトウエアの物理的サイズほどには拡大していません。

短時間で使い捨てるシステムを作る場合、こういった環境のおかげで、むしろ短時間でそれなりに動くものが手に入ります。つまり、次のようなメリットを享受して、短期開発を行えるようになっています。

• ビジュアル開発ツールによって、わずかなコードだけで、動くプログラムを作成できる
• フレームワークやライブラリの充実によって、豊富な機能を「利用」するだけで済む
• いろいろなシステムがつながるようになっているので、それらを比較的簡単に「利用」できる

裏を返すと、このような短期開発の機敏性を備えるには、前提として以下のような条件が重要になります。

• 動くプログラムをすぐに作成できる、手になじんだツールがあること
• よく使う機能がライブラリ化、フレームワーク化されていること、あるいは、既存のフレームワークなどを利用可能にしていること
• 既存のシステムが「つながる」状態になっていること、あるいは、データの相互利用が可能になっていること

先述した情報システム部門の方は、手になじんだツールとして「Delphi」（大規模プロジェクトなどでは別のツールも導入していますが、短期開発はもっぱらDelphiだそうです）を採用しており、頻ぱんに使う機能はコンポーネント化してすぐに使えるようにしているそうです。既存システムがつながるかどうかは相手次第なのですが、基幹システムとの接続性は絶対に確保するようにしているそうです。

すぐに結果を出してくれる情報システム部門は、営業部門やマーケティング部門にとって、頼もしい存在です。でも、本当にこれだけで大丈夫なのでしょうか。