オンラインジャーナル/部会、SIG、P2Mクラブ

先号　　　次号

「最近のシステム開発事情」
その2―工程に関する問題

　前回はシステム開発における「表現能力の問題」を取り上げたが、今回はシステム開発における「工程の問題」を取り上げる。システム開発における工程は古くて新しい問題で、筆者がこの業界に入って40年近くの間に様々の工程標準が作られてきたが、システム開発がこの十数年大型汎用機からクライアントサーバー型の分散機の開発に移って行く過程で、メジャーな標準的開発工程と呼ばれるものがなくなりシステム開発の現場は混乱した状態となっている。今回はこのシステム開発の工程とプロジェクトマネジメントの関係に関して筆者が個人的に感じる問題点を披露してみたい。読者のなかには異論のある方もあるかと思われるのでオンラインジャーナルにご意見を寄せていただければ幸いである。

1．「工程」の現状
　最近では大まかには下記の工程でシステム開発を行っていることが多い。
    ① 要件定義工程
    ② 基本設計工程
    ③ 詳細設計工程
    ④ 製造工程
    ⑤ テスト工程
    ⑥ 移行工程
旧来からの内部設計、外部設計という工程の分け方は聞かなくなった、また概要設計という工程は要件定義工程に含まれるのか、提案型が減ったのか原因は定かでないが最近では聞かれない工程名となった。また詳細設計を詳細設計、プログラム設計に分けるというのも最近では見られない。製造工程は旧来プログラミング、単体テスト(UT)と分けていたが製造工程と一本にして表現されるようになっているが、プログラミング、単体テストという作業自体が無くなったことを指すのでは無い。また製造工程に詳細設計工程を含むように表現されることはあるが、これは発注者側から見た場合、詳細設計以降の工程は開発業者に委ねてしまっているので、発注者側の認識としては製造工程と一括りに呼んでいるものと思われる。テスト工程は結合テスト、総合テスト、疎通テスト等様々に呼ばれる工程があるが、発注者がテスト工程という場合は発注者が何らかの形で参加し、結果を検収することに関与する意識からテスト工程と単純化して表現している場合が多い。受注者側の立場としては、単体テスト、結合テスト、総合テスト、発注者確認テストなど必要に応じた工程を明記する必要がある。その工程の分け方によって、発注者に見せてよい品質がどの工程で実現すべきが明確となる。
2．工程は発注者が決めるのか受注者が決めるのか？
　1．の「工程の現状」ではシステム開発の「工程」を非常に浅く述べたが、この「工程」に関する浅い認識が非常に多くの問題をはらんでしまっている。旧来はシステム開発の工程をどのように分けるかは、システム開発の受注者側が主体となって決めていたが、最近では発注者が関与する場合が多く、決して受注者側の意図が反映していない場合がある。発注者側と受注者側では工程の分け方に関する認識に相当な差があるのだが、十分な摺り合わせが行われず、発注者側の認識に則ったままプロジェクトの大線表がフィージビリティ無しに決まってしまう場合が多い。システム開発の詳細な作業を理解しているのは受注者側なので、本来受注者側の工程の認識を発注者側に理解して貰い、発注者と受注者の合意に基づき大線表伝が決定するように受注者は発注者を導く必要がある。最近の受注者側のプロジェクトマネジャーは工程の分け方、マイルストーンは発注者側と十分協議する必要のあるものとの認識を持っておらず、発注者の作成したお仕着せの大線表でWBSを作成してしまうことが多く、実施不可能な大線表でシステム開発を行い、トラブルを自ら背負っている事例も多い。発注者はシステム開発のプロではなく、発注者はプロジェクト発足初期に提示した大線表が決して実施可能なものとは思っていないことも多く、システム開発のプロである受注者側から工程の分割方法、工程のマイルストーンに関する積極的な提案を期待している。
　発注者が期待しているのは、本番稼働に耐える品質を持ったシステムが、発注者側の戦略上必要とされる期日にシステム実現出来るかどうかであって、途中工程の終了期日ではない。システムによっては機能毎に本番を実施すべき時期が異なることもあり、無理な開発をおこなわなくとも良いことは多い。例えば人事給与システムの開発ではよく3月末が納期となっているケースがあるが、人事異動の原案作成に関与するシステムなら3月末の納期では、人事異動の機能の提供は遅いこともある、発注者側の提示より一ヶ月以上早く人事異動の機能は本番稼働させなければならないこともある。逆に年末調整の機能は3月末に納品してもその年の12月までは本番稼働しないこともある、また賞与の本番稼働も3月末納品の必要は無いなど、業務を理解していれば一年かけて開発すれば良いようなシステムもある。このように業務内容を理解して工程を作成すれば機能が必要とされる時期とは関係無い時期の大量の人員を投入しなくてもシステム開発を行える場合でも、単純に発注者の根拠の無い目標設定で工程を決めると開発のピークを一時期に集中し大騒ぎとなることよくある。システム開発では機能毎に必要とされる時期が違うことが多いので業務の理解とプロジェクトマネジメントは不可分である。同じシステムを開発するのでもプロジェクトマネジャーの業務理解の深さによっては大きくトラブルが発生する場合とそうでない場合がある。
　話は横道にそれるが人事給与システムの開発、ERPの導入で大きくトラブルが発生する場合となんなく開発を終了する場合とが発生する、これは大規模な組織の人事給与システムの導入ではソフトウェアの開発以上に重要なのはデータにシステム開発業者が着目しているかどうかである。人事給与システムの導入では本番を開始しようとする前年からデータの準備をしていないと、年一度しかない業務イベントが多く、本番稼働時期の直前では事務が集中し発注者側が耐えられないことがある。ソフトウェアの開発、ERPのカスタマイズとデータの整備・準備を同時に行うか行わないかで成功するかどうかは決まってしまう。受注者側がデータの整備は発注者の問題と思い込んでいるのをよく見るが、そのようなシステム開発は大きなトラブルに陥っている。
3．工程とWBS
　話を元に戻すが、システム開発ではWBSのレベル1である工程の組み方(大線表)がプロジェクトの成否を担っている。大線表は発注者の戦略的期日の認識と受注者のシステム開発のノウハウの結集であって、発注者から一方的に与えられるものではない。発注者から与えられた大線表に結合テストがないからといって結合テストをおこなわなくても良いのではなくその必要の有無、行う範囲、単位、時期の設定は受注者が行うものである。
　最近よくWBSの作成の仕方のコンサルテーションを行うが、システム開発の工程に関する知識が無い場合はWBSの第一レベルが作成出来ない。WBSは作成しようとするシステムの業務内容、適切なマイルストーンの設定、発注者の関与時期、受注者の品質確保方法、成果物・要素成果物の納品時期を総合してプロジェクト毎に作成するもので、プロジェクトマネジャーはプロジェクトごとに柔軟にWBSを作成する力量を要する。しかしPMPの資格を持っていても、プロジェクトマネジマントだけを知っていればWBSを作成出来ると思っているプロジェクトマネジャーにはWBSが作成できない。システム開発ではシステムエンジニアリング、対象のシステムの業務知識、コンピュータ技術に基本的な知識がないとWBSは作成出来ない。

次回は受注者側の詳細設計以降の工程の混乱状況とその原因について。

以上