ソフトウェア開発における課題と対策(2)~標準化、可視化、情報化の重要性

RSS

2005年08月26日

  • フロンティア研究開発センター長 田中 宏太郎

しばしばソフトウェア開発は、建築と比較され、語られることが多い。しかし、建築とソフトウェア開発には大きな相違点がある(なお本コラムでも、過去に建築との類似性に触れたものが、ものがいくつかあるので、対比については最後にまとめておく)。
ソフトウェアは建築と異なり不可視性があり、また物理的な実態がない「情報」を扱うため、そもそも工法等について体系の成熟度がまだまだ低く、そのため標準化も遅れている。
したがって、ユーザとベンダーとの間で出来上がりに対する認識相違が起きやすい。この不可視性の克服が、ソフトウェア開発の根本的課題である。

建築も昔は品質や納期に問題があったかもしれないが、数千年にわたる先人の英知により解決されてきている。
一方、コンピュータは誕生して半世紀ほどであり、さらに不可視性の克服という大きな課題が存在するため、ソフトウェア開発が建築と同様の完成度を持つには、膨大な学問的研究と時間が必要であろう。

ならば、現時点で未成熟なソフトウェア開発を成功させるために、我々はどう対応したら良いのだろうか。

重要なポイントは、標準化、可視化、情報化の3つである(可視化は、さらに文書化・図式化・指標化の3つに分類できる)。すなわち、設計書の書き方や作業の手順をまとめ(標準化)、それに基づいて情報や機能をモデル化してしっかり表現し(文書化・図式化)、それらをプロジェクト関係者が共通認識を持てるようにコミュニケーションやグループウェア等で情報共有する(情報化)。また、システム規模・作業量の見積り、進捗度合や生産性を計測する(指標化)…ことに尽きる。残念ながら標準化・可視化には、統一的な規格が確立していないため、自社で決めた基準や指標を実際のプロジェクトに適用してみて、実績データを丹念に集め、それらに基づいて改善を重ねて精度を上げていくしかない。

もっとも昨今、標準化に関する動きは多い。例えば、文書化・図式化についてはUMLがデファクトスタンダードになりそうな勢いである。また標準化・指標化についても、昨年10月に発足したIPA(情報処理推進機構)の下部組織「SEC(ソフトウェアエンジニアリングセンター)」が開発プロセスや見積り手法の標準化に取り組んでおり、今年3月末で1,009のプロジェクトの実績を収集・評価を終え、白書が発行されている。

体系化が未成熟である以上、すべてを解決する唯一絶対の方法はない。ソフトウェア開発に際しては、UMLやSECが公表した諸データを大いに参考にし、標準化・可視化を行い、改善のPDCAサイクルを地道に回していくことが最善の道である。

■建築とソフトウェア開発の比較

●建築
【作る対象が目に見える】
形・大きさ・色・質感など作ろうとするモノが目に見える。
【作っている間に対象が普通は変わらない】
よほどの問題がない限り、着工してから部屋の広さを変える等の変更は行わない。
よって当初4LDKの予定であったが、完成したら8LDKになっていた…等の規模の増加はありえない。
【工法がおよそ理解できる】
発注者が素人でも、玩具や模型、過去の学校教育(「技術」)等から、作業を想像できたり、実際の作業を見て、概要がおよそ理解できる。

●ソフトウェア開発
【完成品を見る事がなかなかできない】
画面や帳票等のユーザインターフェースを通してシステムらしきものが見えてくる。しかし情報やシステムそのもの見ているわけではない(見る事ができない)ので全貌が見渡せない。また、画面や帳票等が見られるのは、一般的にはかなり最後の方の工程となる。
【作っている間に作る対象(範囲)が変わっていく】
画面や帳票のテスト結果から、イメージや操作感が違う、当初は思いつかなかったがやはりこういう機能もほしい等と要件の変更が発生する。いざ稼動してみたら、当初予算の2倍の規模・金額となっていた…等がありえる。
【標準的な工法が存在せず、理解しにくい】
開発方法論について統一的な規格が確立しておらず、ベンダーによって工程・作業・成果物の名称や範囲が異なり、発注者が理解しにくい。

このコンテンツの著作権は、株式会社大和総研に帰属します。著作権法上、転載、翻案、翻訳、要約等は、大和総研の許諾が必要です。大和総研の許諾がない転載、翻案、翻訳、要約、および法令に従わない引用等は、違法行為です。著作権侵害等の行為には、法的手続きを行うこともあります。また、掲載されている執筆者の所属・肩書きは現時点のものとなります。