ラウンドトリップ型開発〔RAD方式〕やタスク・ブロック管理は、少数のエキスパートを労働集約的に集め、所謂「タスク・フォース」によって、短期間に開発を行なうという考え方である。容易に推察出来る事だが、いかなるシステム/プロジェクトであれ、必要なエキスパートを必要なだけ集め、少人数で開発できるのであれば、高生産性が得られて当たり前である。プロトタイプをベースに、完成まで導くことが出来るシステム規模は、それほど大きくはない。経験的には、数十万ステップ前後であろう。何が何でも、すべからくRADで開発するのは無茶である。
プロトタイプをベースとした開発で、高い生産性を上げることの出来るシステムには、いくつかの条件がある。
・比較的単純な構造のシステム
・技術的なクリティカル・ファクタが少ない
・運用/監視/セキュリティなどの管理的なニーズや要件が少ないこのため、大規模なシステム開発では、RAD手法とインフラ環境を前提に、プロジェクトそのものを設計し、システム開発手順を設計する必要がある。具体的には、
・手法を適用する範囲の特定
・事前のフィジビリティ・チェック
クリティカル・ファクタの切り出しと解消
・運用・管理機能の切りだし(共通化、標準化を含む)を行なう。
また、プロジェクトは、サブシステムではなく、取り扱うテーマによってチーム化すべきである。大まかな区分けとしては、
・システム開発の背景となるビジネス環境を分析し、プロジェクトをコントロールするチーム(プロジェクト担当)
・所管業務を中心に、アプリケーション機能と業務データを担当するチーム(アプリケーション担当)
・システムのインフラに関する事前準備とチェックを行ない、環境を構築するチーム(システム担当)の三グループである。それぞれは、漠然と技術者で構成してしまわずに、
・プロジェクトの推進管理のエキスパートおよびスタッフ
・業務とアプリケーションのエキスパートおよびスタッフ
・システムとインフラ技術のエキスパートおよびスタッフを中核に構成し、それぞれのスタッフや担当を横断する専門スタッフによって補強すように組織化する。さらに詳細な体制分割が必要な場合には、上記のような、各チームの位置付けを明確にしたのち、
・個々のアプリケーションに固有な機能を開発する
・共通なビジネス・ルールやサービス機能を開発する
・ユーザとのインタフェイスを開発する
・データやシステム外部とのインタフェイスを開発するなどのような、ターゲットとなるアプリケーションの機能や構造に準じたチーム分けを行なう。この場合、指標となるのは、システム全体をクライアント系、サーバ系に区別し、さらに、業務アプリ、運行管理、インフラ、データベースなどへと区分けして行く方法である。
この区分けは、業務やサブ・システム構成に依存することが少ない。一つのチームがいくつもの業務や技術を習得しなければならない状況が回避しやすい。また、大規模なシステム開発では、サブ・システム単位よりも、システム構造をもとに、開発順序を決める方が有利である。上記のような体制は、システムの開発順序やスケジュールを考慮しやすく、大規模開発を円滑に進めるのに適している。
万一、初期段階でシステム構造が明確でない場合は、開発対象となる機能の適用対象によって、
・ユーザへのサービス機能を提供する
・各アプリケーションに共通な機能を提供する
・システム環境の維持とサービス提供に必要な機能を提供する
・運用と管理のための機能を提供するのよう細分化して行くとよい。つまり、「同時に同じ事をやるチームは、複数作らない」のを原則とする。
「人間が一度に考えられる問題の大きさは、たかが知れている。問題が大き過ぎる時は、人間が理解できる大きさまで分解すべきである。」…このような考え方自体は、従来からある。しかしそれは、「サブ・システム」による、機能分割を主体とした分割統治の考え方であった。
今日の情報システムは、要素技術が広範囲にわたり、それぞれの習得に時間が掛かり、全員が全ての技術分野、業務分野をカバーする事は、もはや現実的ではない。したがって、いきなりサブ・システム分割をして、チーム分担を決めてはならない。むしろ、サブ・システム構成(＝システムの全体デザイン)に寄らないチーム構成を目指すべきである。なぜなら、技術の選択や、業務/アプリのモデリング、実現方式のフィジビリティ・チェックなどが完了しない限り、サブ・システム構造は決定できないからである。
大量の作業をサブシステム分割して、いくつかのチームが各サブシステムの全分野をこなす方法と取ると、技術者は、得意/不得意に拘わらず、全ての技術テーマや業務アプリテーマに取り組まねばならない。これは、実体として、技術と業務の全範囲に精通するスーパーマンを全てのチームに期待することと同じである。
特に、業務的/技術的な難易度が高く、不確定な要素を多く抱えたシステムの構築では、大量の人力を投入しても、習得までの期間や未熟さが、逆に足かせとなる。むしろ、分解された問題は、それを処理するのに最も適した人物に与えられるべきである。
「何でもできるスーパーマン」に委ねてしまうのではなく、それぞれが得意な技術分野/業務分野を持つ技術者によって、分野毎に特化したチームを構成し、各チームが協調して開発作業を進めるようにする。そして、システム構築プロジェクト全体として、開発効率や生産性を上げる事を狙うべきである。
於：ソフトウェア・シンポジウム’95 滋賀 SEA
コメント