arclamp.jp アークランプ

　エントリが遅くなってしまいましたが、日経SYSTEMS 5月号のコラムは「フレームワークを導入しても下がらなかったコスト」。フレームワークの選定にはユーザーの協力が不可欠、という話です。

　フレームワークというのは、なんらかのドメインにたいして、なんらかの解決策を提示しているモノです。ですから、このドメインと解決策にフィットするところに適用するのが重要です。そのため、じっくりとフィット＆ギャップを分析する必要があります。

　しかし、フレームワークの選定はプロジェクトの比較的早い段階で行われます。工数に多大な影響を与える要素ですし、どちらかというと提案そのものに含まれるモノだからです。そのためユーザーからヒヤリングした初期要件だけでフレームワークを導く必要があります。

　ところが、いざプロジェクトが進んできて、要件の整理が行われてくると「あれれっ」ということがあります。実は別の制約条件があって解決すべきドメインがずれてまう、あるいは、そもそも解決策が適用できない、といった問題です。

　僕も何回か経験をしていますし、そのたびに要件ヒヤリングの重要性や、スコープ定義など、プロジェクトマネジメント初期段階でのユーザーとの協力体制について反省をしてきました。

　今回のコラムは、そんな体験も交えながら、どうやれば初期要件段階でフレームワーク選定に必要な情報を引き出せるのか、という話です。

　僕が、いまお薦めできる手法としては、「フレームワークの解決策を設計手法に当てはめる」ということです。ユーザーは、フレームワークそのものにあまり興味がありません。ないというか、持てないというか。そのためフレームワークの機能をいくら説明しても話半分、特に良い面にしか聞いていない。

　そこで、フレームワークの持っているクセを設計手法に反映させ、設計手法を通じてユーザーに説明をすることをします。

　「何を当たり前な」と思われるかも知れませんが、これが、意外にできていない。ありがちな問題は設計手法の標準化による弊害です。設計ドキュメントの書式や内容を標準化するのは、多くの企業で行われていることです。ですが、設計という作業は、その後に続き実装工程に大きく影響を受けます（品質モデルを思い出してください）。

　ですので、プロジェクトごとに、フレームワークに合わせて設計手法（特に設計書の適用や設計書の書式）をカスタマイズすることが大事になるのです。

　ここらへんを失敗すると、フレームワークを導入したんだけど、なんだかコストが下がらない、あるいは、逆に増えたんじゃないか！？という本末転倒なことになります。

　フレームワークは技術の問題ですし、エンジニア側の領域です。ですが、品質モデルにあるように、内部品質と利用時の品質は、互いに依存し、影響されるのです。ソフトウェアの構造は表にしみ出ると言うことを、きちんととらえていきたいです。