ソフトウェアライフサイクルからSQuBOK^® を読み解く　第2回

株式会社日立システムアンドサービス　シニアコンサルタント
古賀　惠子
日本ユニシス株式会社　品質保証部
大川　鉄太郎
株式会社ニルソフトウェア　シニアコンサルタント
河合　一夫

第２回の内容

　連載２回目は，「ライフサイクルに関連する規格・標準」です．ソフトウェアライフサイクルの規格･標準はどのような目的で作られているのか，どう活用したらよいのか，ソフトウェアの品質を考える上でどのような意味を持つのかなどを，古河課長と熊川さんに語って貰います．

ソフトウェアライフサイクルとは

　熊川さんは，昨日から頭を抱えています．部長と課長に呼ばれて次の調査を命じられたのですが，どう手をつけてよいか分からないからです．
「Y取締役が，『うちのソフトウェアライフサイクルプロセスは，世の中の標準に整合しているのかどうかを至急報告してくれ．海外生産を一気に立ち上げることが決まったので，海外新工場のIT要員とも間違いの無いようにコミュニケーションできないと困るし，現地ITベンダーとも同じだ．』とおっしゃっている．熊川君，社内プロセスを大至急調査して報告してくれ．」
熊川さんの考え込んでしまっている様子を見て，古河課長が声をかけてきました．
「熊川君，調査を始めたかね？」
「それがそもそも『世の中の標準』が何なのかよく分からなくて困っています･･･」
古河課長は苦笑しながら話し始めました．
「ライフサイクルという言葉はいろいろな分野で使われていて，たとえばマーケティング分野では製品ライフサイクルとして，導入期，成長期，成熟期，衰退期，の4段階を経るS字カーブとして描かれる．セーフティ･クリティカル・システムと呼ばれる安全重視の製品では，製品構想から廃棄に至るまでのセーフティ･クリティカル・ライフサイクルモデルと呼ばれるライフサイクル全てにおいて安全性確保が求められて，機能安全規格がIEC（国際電気標準会議）で定められている．ソフトウェアについてもライフサイクルとして語られるモデルは実は結構多いので，まず２種類に分けてみよう．」

　「1つには，開発方法論によらず中立的に作られたソフトウェアライフサイクルモデルがある．これは，ソフトウェアを企画し，要求と要件を定義し，設計し，プログラミングし，テストし，運用･保守し，廃棄するまでの活動を網羅的に示したものだ．その代表的なものが『ISO/IEC 12207（JIS X 0160）ソフトウェアライフサイクルプロセス』で，最新版は2008年に出ている．対象をソフトウェアからシステムに範囲を広げた規格には『ISO/IEC 15288（JIS X 0170） システムライフサイクルプロセス』がある．関連規格としては12207の保守プロセス部分を詳細化した『ISO/IEC 14764（JIS X0161） ソフトウェアライフサイクルプロセス－保守』等がある．さらに国際標準を下敷きにして日本独自に作成したモデルに『共通フレーム2007』がある．」
「標準と冠がついているモデルのグループですね．もう一つのモデルはどういうものですか？」
「もう一つは反復型やウォーターフォール型等の各種開発方法論やCMMI等のアセスメントに対応したプロセスモデルのことだ．これらもライフサイクルをカバーしていることから，ライフサイクルモデルと呼ばれているけれど，それぞれの目的に即したモデルなので今回は調査対象外だね．」
「世の中の標準というと，今回の場合は前者のモデルですね．前者のソフトウェアライフサイクルプロセスの国際標準や日本の共通フレーム2007は，一体何のために作られたのでしょうか？」
「いい質問だ．その目的は，ソフトウェア開発や運用･保守において発注者や受注者など関係者に，①共通の言語，および②役割を含む共通の開発マップ，を提供するという2点に集約できる．」
「はい．」
「君も知っているようにソフトウェア開発取引の世界では，責任分担や範囲が曖昧でトラブルが生じる，発注内容の品質･機能などの理解が食い違って仕様変更と手戻りが多発する，などの問題が発注者と受注者の間に絶えない．その一方でソフトウェアビジネスはグローバル化が一気に進んでいて，中国やインドで，開発のみならず運用･保守まで行われることも現実になってきている．このままではソフトウェア取引の混乱はますます深刻になりかねない．だから共通言語や標準のライフサイクルモデルが近年注目を集めている．」
「そういうことでしたか．ではITベンダーやITユーザは皆この標準をそのまま社内用語や社内プロセスに取り込むことが期待されているのですか？」
「いやそこまでは期待されていないし，そのような実例もほとんど存在しない．そもそも社内用語や社内プロセスは長い歴史を経てきていることが多いし，メインフレームからの歴史がある組織ならなおさらだ．期待されるのは，社内用語や社内プロセスと標準の間のマッピングができていることだ．これができていると，社内用語や社内プロセスが異なる複数の組織間でも正確に意思疎通できる．もう一つの効用は，社内用語や社内プロセスが異なる組織同士が対話しようとすると力関係が表に出て，一方が他方に合わせる形になりがちだが，これも回避できる．」
「ITベンダーと協力会社の間も同じでしょうね？」
「その通り．特に海外発注であるオフショア開発はコミュニケーションのリスクが高いので要注意だ．国内外共に言えることだが，注意すべきは表面的な用語のずればかりを気にするのでは不十分であるということだ．意味する本質的な内容にずれが生じていないか，お互いに絶えず気を配ることが肝心だ．」
「形式的なことだけで無く，内実にも注意を払うということですね．」
「あうんの呼吸で・・・，というコミュニケーション方法は人間の機微を踏まえたやり方で，これができる人間関係というのはすばらしいと思う．ただこの方法は，共通の社会文化基盤，人間性まで含めた深い信頼関係，を共有していることが前提になる．今のグローバル化したビジネス環境ではとても難しいことは明らかだ．行き違いが生じたときの双方のダメージの例は，君もいくつか思い当たるだろう．」

　「そういえば去年夏にA社の担当SEのZさんは，画面インターフェース設計要件の誤解をエンドユーザテストで大量に指摘されて，夏休みが吹っ飛んでいました．」
「夏休みが吹っ飛ぶのもつらいが，仕様の行き違いが基で会社が大損害を出してしまい，合併に追い込まれたケースが最近話題になったね．ソフトウェアライフサイクルの話はここまでにしておこう．
ところで熊川君，君は職場で中堅といわれる立場に近付いているのだから，調査報告はすぐにできないと困る．ソフトウェア品質とその関連事項であれば，まずSQuBOK^®ガイドに当たるのが定石だ．
今回の調査なら，

①	SQuBOK®ガイドの『２．２　KA：ライフサイクルプロセスのマネジメント』を読んで概要と参考文献を把握する，
②	必要に応じて参考文献を読んで詳細情報を得る，
③	評価基準あるいは参照モデルを決める，
④	自社プロセスを評価する，
⑤	報告書を作成してレビューを受ける，
⑥	報告する，

　という手順になるだろう．ちなみに今回の評価のための参照モデルはISO/IEC12207：2008が適切だと思う．SQuBOK^®ガイドの該当ページに直行できないときは，目次，樹形図，索引を利用して該当ページを探すとよい．SQuBOK^®ガイドはソフトウェア品質に関する知識・知見の体系に対する最新ガイドとして作られているから，今回のような場合にとても役に立つよ．」
「はい，分かりました．」

　というわけで、熊川さんは調査にとりかかり，無事報告をすることができました．

次回は、「ライフサイクルと品質技術」についてです．