ＩＴでらくらく建設業 Vol.155(07/04/20)

発行日： 2007/4/20

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

　　　　　ＩＴでらくらく建設業 Vol.155

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

　おはようございます。森下です。

　最近、痛ましい事件が相次いでいます。長崎の市長銃撃、米バー
ジニア工科大銃乱射、イラク爆弾テロ。亡くなった人数は違います
が、不意の暴力によるものであることには変わりありません。亡く
なった方への深い哀悼と事件を起こした側への強い憤りを感じます。

　憎しみは新たな憎しみを生みます。もちろん、どこかで許せるこ
とが出来ればとめることも可能だと思いますが、なかなか難しいで
しょう。でも、やられたこと以上のことをやらずに少し減らせれば
きっと最後はなくなるはずです。時間がかかることだとは思います
が、そんな気持ちをもって人に接することができるような日本にな
ってほしいです。

　選挙活動真っ盛りですが、なかなか心に響くものを感じないのは
なぜなんでしょう。選挙公示の内容も漠然とした似たり寄ったりの
ものばかりです。そして、任期の間にできると思えないような公約
を平気で書いている人もいます。複数回当選しても同じことしか書
いていない人もいます。こんな政治では憎しみを減らすことは難し
いのではないでしょうか。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
・建設業を取り巻くＩＴ（３週間に１回）
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃このコーナーでは、建設業を取り巻くＩＴ技術やトピックスを┃
┃ご紹介します。「現場でＩＴ」「建設業を取り巻くＩＴ」「建┃
┃設業に役立つホームページ」を週替わりでご紹介します。　　┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
K052　システム開発（ＳＬＡ作成）

　前回までで契約が完了しました。今回は、その後の開発時のポイ
ントをお話します。そのために必要なのが開発版ＳＬＡ（サービス
基準契約）です。

　「えっ～！また契約なの。終わったって言ったじゃないの」とい
われるのもごもっとも。しかし、この契約は前回のような開発前の
お約束ではなく開発中のお約束を決めるものだからです。実際には
前回の契約と連続して行う場合が多いですが、この契約を中小企業
で交わしているケースはとても少ないと思います。第 150号で紹介
したリンクにサンプルがありますので、詳しくはそれを読んでいた
だくとして、この契約のポイントをお話します。

　先ほどＳＬＡをサービス基準契約と直訳しましたが通常はサービ
ス品質保証契約という表現をします。実はこの品質保証というのが
ポイントなのです。システム開発というのはとても曲者で残念なが
ら公的に品質を保証する仕組みがありません。全くないというわけ
ではありません。ISO 9126（JIS X 0129）シリーズで定めた「ソフ
トウェア製品の品質」と、ISO14598（JIS X 0133）シリーズで定め
た「ソフトウェア製品の評価」があります。そして次世代国際基準
としてISO/IEC 25000 SQuaREシリーズがあります。しかし、これら
を利用して管理している例は特に中小ベンダーでは聞きません。

　建設業ならば、品質管理基準がありますし、ＩＳＯ９０００シリ
ーズもあります。これらは中小企業でも一般的なのですが、システ
ム開発の世界では品質管理はまだまだ浸透していません。そこで上
記のようにＳＬＡを結ぶのです。

　ＳＬＡは通常開発後の運用時に結ぶことが多いですが開発時でも
使えます。開発版ＳＬＡといっても難しく考えないでください。主
に決める項目は

・基本工程
　要はいつ頃に設計が出来、見本を見れる日がいつであるとか、テ
　スト期間とかを決めます。
・体制と役割分担
　開発側と発注側の窓口、責任者、担当を決めます。役割分担は誰
　が何を決めるのかを明確にしておきます。
・コミュニケーションルール
　打合日、打合方法、参加者、議事録、承認方法などを決めます。
・セキュリティ
　開発中に使うデータの取扱いやシステムがビジネスアイデアによ
　るものなら漏洩防止の対策を決めます。
・システム開発の品質
　システム開発の品質は、機能品質、操作品質、サービス品質、セ
　キュリティー品質の４つです。機能品質は「システムが実現する
　機能の範囲は満たされているか」、操作品質は「操作上の性能要
　件は満たされているか」、サービス品質は「いつまでに誰がどの
　ような役割でどこまで作るかの計画は満たされているか」、セキ
　ュリティー品質は「セキュリティー確保の範囲は満たされている
　か」です。

レビュー（みんなで内容をチェックする）回数やバグ対応時間、
　テスト項目消化数などの指標を決め、それをチェックできる仕組
　みを決めます。

　です。ほとんどがベンダー側が提案するものばかりです。つまり、
ベンダー側の実力が一番よく分かる資料でもあるのです。ユーザー
としては中身を理解し、自分たちのできることできないことをはっ
きりしておく必要があります。特に役割分担で仕様変更時の責任分
担が一番もめます。ここをしっかり抑えましょう。サービス品質に
関しては、システムの内容と開発手法でいろいろな表現や指標があ
るためにこれというものが出せないのが申し訳ありませんが、大事
なことは開発中はおまかせというのではなく、依頼者として途中段
階をちゃんと見ますよという意思表示をすることです。おうちを立
てるときでも途中で進捗状況を見に行くようにシステム開発も途中
の状況を見れるように指標や打合回数、工程などをきちんと決めて
おくことが最後に「こんなはずではなかった」を防げるのです。

　いずれ、システム開発も一定の基準が出てくると思います。それ
までは試行錯誤がありますが、くじけず開発版ＳＬＡを作りましょ
う。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
・略語勉強会
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃このコーナーでは、建設業・ＩＴに係わる略語をわかりやすく┃
┃説明します。　　　　　　　　　　　　　　　　　　　　　　┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
R155

　ＳＱｕａＲＥ(スクエア)
　(Software product Quality Requirements and Evaluation)

　直訳するとソフトウェア製品品質要求と評価となります。要はソ
フトウェア製品の品質向上のための測定方法及び評価方法に関する
規格をまとめたものです。前述したように最終的にはISO25000シリ
ーズとして発行される予定です。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
詳しいご相談・お問い合せは、下記アドレスよりどうぞ。
メールでのご相談は無料です。

■発行元　　　　：　ＭＩＮＴＳ(ミンツ)
■発行元ＵＲＬ　：　http://www.mint-s.jp
■執筆者　　　　：　森下　裕史(hiroshi.morishita@mint-s.jp)
　　　　　　　　　　ITコーディネータ

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－