コラムColumn

　システム開発では、すべてを事前に見通せるとは限りません。それでも、投資する側には予算を確保し、期限を設定し、組織として意思決定する必要があります。
　「不確実だから分かりません」では投資の判断はできません。一方で、まだ分からないことまで無理に確定すると、後から変更や追加費用をめぐる問題につながります。
　必要なのは、すべてを先に決めることでも、すべてを曖昧にすることでもありません。現時点で何を決め、何に探索の余地を残すのかを選ぶことです。

■不確実性に応じて、約束の仕方を変える
　開発の対象には、要件や実現方法が明確で見通しを立てやすい部分と、利用者の反応や技術的な検証など、実際に試してみなければ分からない部分が混在します。
　不確実性の程度に応じて、見積りや約束の粒度を変えます。見通しの立つものは具体的に予測し、合意する。一方、不確実性の高いものには幅や選択の余地を残します。今決められることは決め、まだ分からないことは、試して情報を得てから判断します。どこまで見通せるかを見極めながら、予測や約束の仕方を変えるのです。

■何を制約として守り、何に変更の余地を持たせるか
　開発には、予算、期間、スコープ、品質基準、必ず満たすべき条件など、さまざまな制約があります。
　しかし、不確実性が高いにもかかわらず、予算、期間、スコープのすべてを最初から固定すると、想定外のことが起きたときに対応できる余地が小さくなります。そこで、何を制約として守り、何に変更の余地を持たせるのかを意識的に選びます。
　たとえば、予算と期間に一定の投資の枠を置き、その中でスコープを調整できるようにします。すべての機能を最初から完成させると約束するのではなく、開発中に得られた情報に応じて、スコープを変更できる余地を残します。

【図：投資の枠に応じて、実現する範囲を選ぶ】

　ここでいう投資の枠は、限られた予算や期間の中で、何を守り、何を変えられるのかを考えるために置きます。予算と期間から開発量を算出したり、両者を固定したりするものではありません。

■スコープに選択の余地を残す
　スコープに選択の余地を残しておけば、将来の不確実性に対応できます。
　開発を進めると、当初は重要だと考えていた機能が、それほど必要ではないと分かることがあります。反対に、利用者からの反応や技術的な発見によって、新たに必要なものが見つかることもあります。
　最初に決めたスコープを守ること自体が目的になると、必要性や優先度が下がったものにも予算と時間を使い続けることになります。開発中に得られた情報をもとに、スコープを見直せるようにしておきます。そのためには、必ず実現すべき条件と、状況に応じて変更できる部分をあらかじめ区別します。

■契約にも、変更を前提とした考え方がある
　こうした考え方は、アジャイル開発の契約にも表れています。
　IPAは「情報システム・モデル取引・契約書（アジャイル開発版）」で、準委任契約を前提としたモデル契約を示しています。開発の中で機能の追加・変更や優先順位の変更に柔軟に対応する、というアジャイル開発の特徴を踏まえたものです。あらかじめ特定した成果物の完成に対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う、という考え方です。
　行政分野でも、行政情報システム研究所の「行政におけるアジャイル開発の実践に向けた調査研究〈プロジェクト実践編〉」では、東京都が準委任契約に基づいて実施したアジャイル開発をもとに、他の行政機関等でも活用できるプロセスを整理しています。そこでは、プロダクトではなく、専門人材の「仕事」を調達するという考え方や、準委任契約を結ぶことなどが示されています。
　ただし、単に契約形態を準委任に変えればよいわけではありません。何を合意し、何に探索や変更の余地を残すのかを明確にし、開発中に得られた情報から判断を見直せるよう、契約や発注のあり方を設計します。

■何を約束し、何を探索するか
　予算や期間、品質基準、必ず満たすべき条件など、現時点で合意できるものは合意します。まだ判断できないことには、探索と変更の余地を残します。
　全部を約束しないことと、何も約束しないことは違います。何を約束し、何を探索するのか、その境界を関係者で共有します。
　では、探索することにした部分について、最初に置いた見積りをそのまま使い続ければよいのでしょうか。探索を進めれば、分からなかったことが少しずつ分かり、実績も蓄積されていきます。次回は、そうして得られた情報を使って、見積りを繰り返し更新する方法を取り上げます。

※このコラムは全6回を予定しています。