連載
» 2009年01月20日 12時00分 公開

進化するCIO像(6):業務改革とシステム革新は“両輪”で進めろ! ──システム開発編 (1/2)

要件定義が不十分であっても、一定のスケジュールや予算の下でシステムを開発しなければならないケースは多い。そうした中でも真に役立つ高品質なシステムを開発するには、どのような体制が必要なのだろうか

[碓井誠(フューチャーアーキテクト),@IT]

システム開発手法に“変化対応”を組み込む

 第5回『業務改革とシステム革新は“両輪”で進めろ!──システム化計画編』では、システム構築の前段に当たるシステム化計画の方法論について説明した。今回は後段に当たるシステム開発の方法論と開発体制の組み立て、運用について話をする。

 システム開発については、CMM/CMMIなど、標準的なプロセス改善手法の導入が各社で進みつつある。方針が明確であり要件定義のコンセンサスが図られているプロジェクトは、これらの手法に沿って開発とマネジメントを進めることで、品質と効率の向上が見込める。

 しかし中には、業務改革方針や要件定義の不明確な部分を携えつつ、経営−現場−システムのコンセンサスが不十分な中でも、一定のスケジュールと予算の制約の下で、プロジェクトを推進せざるを得ないケースも少なくない。さらには開発が進み、詳細のレビューの段階に入っても変更や追加の要求が後を絶たず、全体最適の同床異夢のほころびや、部分最適でさえ部門間の異床異夢の中にあり、最善策・次善策にも至らぬ場合がある。

 これらはシステム開発の最大の障害であるが、決してなくなることのない要素である。コンカレント開発やアジャイル開発といった手法を取ったり、“作り込み”か“パッケージソフトウェアの活用”かを区分し、後者の場合にはパッケージやツールのフィットギャップ分析で要望を整理、切り分けして対応しようとする考え方も1つの方法ではある。

 しかし、“変化への対応”が、今後より重要となることを受け入れ、柔軟、迅速な開発力を強化するためには、システム開発手法に変化対応を組み込み、開発マネジメントの範囲の中に、経営および現場との意思決定プロセスを包含して整備することが必要である。

 従来のシステム開発手法は、開発フェイズに対応した詳細の方法論や品質基準などは備えているが、こうした“変動要素”は阻害要因としてとらえ、本筋の議論とは別に考える傾向があった。

 これからのシステム開発手法は、情報システム部門と開発パートナーの両者間の手法にとどめるのではなく、ユーザー企業の経営層、関連部門、情報システム部門、開発パートナーの4者がコンセンサスを形成する中で、進めてゆく手法となるべきである。

システム開発の3つの鉄則

 それでは、このような手法をどう整理し、運用していけばよいのであろうか。まず開発手法の考え方の基本、目標とすべきシステム構築の在り方を以下にまとめてみる。

  1. システム開発とは、経営や各部門が発注者となり、情報システム部門や開発パートナーが受注者となって行われるものではない。システム化計画を含め、経営と各部門がオーナーシップをもって検討や意思決定にかかわり、システム活用による業務改革の責任を明確にし、共有するものである。
  2. 情報システム部門は、IT活用による業務改革の提案を常に行うとともに、開発プロジェクトの推進と、決められた進ちょくフェイズに応じて、経営や関連部門からのレビューや意思決定を受ける。また、前提条件の変化、システム仕様の修正、追加にも対応して、費用、スケジュールなどの調整内容を常に全社で共有、決定していく──透明性と共感、共有を醸成するリーダーシップが重要である。
  3. システム開発プロジェクトは、情報システム部門のメンバーを中核に、営業部門、商品部門といった関連部門から参画する専任または兼任のメンバーや、開発パートナーのキーパーソン、優秀な技術者・研究者も含めた、総合的な体制を整備する。これにより、業務面と技術面の深い相互理解と、ユーザー部門、情報システム部門、開発パートナーの三者連携による相乗効果を引き出す。さらに、マネジメントを一本化して情報共有を行うほか、開発フェイズや開発状況に応じた迅速なリソースコントロールなども可能とする。

 必要な要件は多々あるが、「経営と各部のオーナーシップの形成」「情報システム部門の提案力とリーダーシップ」「一枚岩の開発体制と相乗効果」の3点がシステム開発の強固な基盤となる。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ

マーケット解説

- PR -