 |
|
「最近のシステム開発事情」 イデオ・アクト株式会社 代表取締役 葉山 博昭：6月号
前号ではWBSが作成出来ない事は、システム開発の工程が明確になっていないことに問題がある事を述べたが、今月号ではシステム開発の現場が混乱に陥っている工程の現状とその問題点を探ってみたい。 前号でも述べたが、工程の決め方が発注者主導で行われており、受託者側のシステム開発上の重要な作業が工程、マイルストーンに反映していない問題を述べた。システム開発の現場では、システム開発の作業を工程・マイルストーンに反映するよう整理し計画していれば良いが、未整理なままWBSを作成し、絵に描いた餅となったWBSに従い作業がコントロールされないままシステム開発を行っていることがよくある。 1) 工程の乱れ 最近よくある工程の乱れで代表的なものは、次工程で記述すべき内容が前の工程で記述されることが挙げられる。 要件定義では基本設計の内容が、基本設計工程では詳細設計工程の内容が、詳細設計工程ではプログラミングとほぼ同じ内容を記述してしまうことが多い。 作成している技術者に、なぜかと問うと、基本設計工程時であれば詳細設計書を書いて見ないと基本設計が書けない、詳細設計時ではプログラムのコーディングを作成しないと詳細設計書が書けないという応えを得ることが多い。次工程で作成すべきことをイメージすることは必要だが、次工程の成果物その物を作成することとは違う。次工程でのキーポイントをイメージしフィージビリティを確保することは重要だが、次工程の成果物を書いて見ないと分からないというのでは、技術者としての洞察力、想像力があまりに不足しているとしか言いようがない。このような状況であるから、要件定義書と基本設計書の差が無くなり、やたらに要件定義で時間を空費してしまうことがある。また詳細設計書が出来ていないのにプログラムが出来上がってしまうようなことが発生してしまう。このように工程に則り段階的詳細化を行われていないと、途中で必要なステークホルダーのレビューが適切な時期に行えなかったり、何か誤りが見つかると工程に準拠しないで作業を行っていると、どこからどこまでを直す必要があるのかわからなくてしまったりする。その結果として低品質なものが出来てしまう。 このような工程無視の作業がなぜ行われてしまうのか、プロジェクトマネジャーはこの問題にどこまで関与しなければならないか？ 各設計書で書く深さ、粒度はプロジェクトマネジャーが決めるか、大規模なシステム開発ではプロジェクトマネジャーに委嘱された標準化(システムエンジニアリング)の専門家が決めるもので、記述する担当者が個々に勝手に決めるものではないと思うが、往々にして各記述担当者の流儀で作成してしまうことが工程の乱れに繋がっているものと思われる。このような状態を見るとソフトウェア業界はなんとレベルが低くいことかと驚愕される方が多いいかと思われますが、確かに日本ではソフトウェアという物作りが出来ない状態に成りつつあるのだと思われます。 特に発注者側から見ると、詳細設計からプログラムの完成まではどのようにつくられるか興味はないので、受託者であるシステム開発会社の自由になる面は多いが、だからといって勝手気儘に行っていいというものではない。とくにオブジェクト指向の開発になってからは詳細設計後のレビューを基本設計者と十分行い、共通オブジェクトの選定、フレームワークの作成を行わなければならないはずなのだが、最近カット&ペーストで類似オブジェクトを安易に作成してしまい、共通オブジェクト、フレームワークの高度化が不十分で生産性、品質の低下、メンテナンスのし易さを損なっていることが多い。 2)ソフトウェアエンジニアリングの重要性 ソフトウェアエンジニアリング自体がしっかりしていないと、マネジメントより以上にエンジニアリングに時間を要してしまうこととなりプロジェクトマネジメントが疎かになり、エンジニアリングとマネジメントの双方に大きなリスクを抱え込むことになってしまうのが最近のシステム開発ではよく発生している。 最近の発注者側はPCを普段から使い、様々なAPを使うようになりコンピュータのリテラシはかなり高くなってきているが、だからといってシステム開発への理解が高くなっているとは限らない。 画面の設計を例に取ると、要件定義段階で必要とされる画面イメージ、基本設計段階での画面、詳細設計段階での画面と段階を追って詳細化されれば良いものを、要件定義で詳細な画面、画面の流れを発注者が要望しそれを何回も作成し直し、顧客対応に時間を取られ、要件定義期間を遙かに過ぎてから基本設計に入ることになり開発が大幅に遅れることが良くある。このような場合に段階的に画面イメージを固めることを発注者に説得し、あまり詳細なことが要件定義で終了しなくとも開発全体のスケジュールに影響がないことを納得してもらう必要がある。最近のシステム開発ではこのような開発方法を顧客と話し合うことは少なく、発注者側の思惑に唯々諾々としたがって開発を行い、システム開発全体がうまくいかなくなってしまうことがよくある。受託者のシステム開発会社のプロジェクトマネジャーはシステム開発のプロとして開発の方法論を発注者に説明し納得させる力が必要である。 3)工程を考えるキーポイント ◇工程を考える場合何を単位に成果物を作成するか、文章の出口、入り口が重要である。 要件定義
基本設計
又、システム開発では常に次工程を睨みながら作業を行うので、次工程での重要な点が前の工程の作業途中で分かることが多い、分かったからといってそのまま前の工程の成果物にキチンと記述してしまうと、次の工程の成果物を作成しているのと同じになってしまう。次の工程へのメモとして残し前の工程の正式成果物とせずレビューの対象としない方法を取ることも出来る。最近書いたものを全て発注者に見せてしまい次工程で議論すべきことを前の工程のレビューで行ってしまうこともあるので、成果物が先行する工程ほど重くなる傾向があるのは一概に発注者側の責任とは言えないことが多い。 最近のシステム開発のドキュメントはどのフェーズのものであっても全体を俯瞰し、トップダウンに書けないことが多い。発注者側に理解を得るため、又自プロジェクトの中での早い理解を得るためにも、全体を俯瞰した資料と、その資料の関係、全体(俯瞰出来る)から詳細を書くということを、工程を意識して行う必要がある。 以上
|
||||||||||||||||||
 |