NTTデータ、富士通、NEC、日立製作所、三菱電機インフォメーションシステムズ、OKIの6社は、非機能要求(情報システムの応答速度などの性能や障害時の耐性など、システムの強度や品質に関するもの)の見える化と確認方法を共同研究するために「システム基盤の発注者要求を見える化する非機能要求グレード検討会(非機能要求グレード検討会)」を発足させた。同検討会において、非機能要求について、ユーザー(発注者)と開発ベンダー(受注者)の両者で共通の認識を持てるようにする方法を検討し、広く利用されることを目指す。09年4月をメドに標準案を策定して公開することにしている。(08/04/14発表)
【コメント】情報システムを開発する際には機能要求と非機能要求を明確にし、ユーザーと開発ベンダーの間で確認しながら、開発を進めていく。ここでいう機能要求とは、業務フローや業務データとその処理方法のこと。また、非機能要求とは、業務データ処理量、応答速度、同時処理件数、さらに障害耐性などのことで、いわゆるシステム基盤のことだと思えばいい。特に非機能要求について、不十分な認識に基づいて開発した場合は、想定外の方法で運用しなければならなかったり、稼働後に問題が発覚した場合には、修正のためのコスト負担が増大する。機能要求については9社による「実践的アプローチに基づく要求仕様の発注者ビュー検討会」が、08/03/18に「発注者ビューガイドライン」を完成させ発表している。
今回の「非機能要求グレード検討会」の発足の背景には、最近、特に金融機関で多発しているシステムダウンなどの問題があるといえる。東証の例のように、想定外のアクセスの急増によってシステムが動かなくなったりすることがある。これはユーザーと開発ベンダーとの間の意思疎通が十分に行われないために発生する。このようなことを回避するには、業界全体で標準化された基準を設け、これに基づいてシステム開発を行えばいいという結論になる。
この意味からすると今回の同検討会の発足は、問題解決の第一歩が踏み出されたということはできる。しかし、問題点も内在している。その1つは“見える化”である。最近、猫も杓子も見える化を頻発するが、見える化=問題解決という図式に必ずしもならないケースもある点に注意すべきだ。システムが複雑になればなるほど見える化も複雑になり、この結果結局は見えないことに終わりかねない。要は何が重要で何が副次的要素かをまず仕分けてから、見える化に取り組むことが肝要だ。
もう1つは現場との遊離に注意しなければならない点。現場はあすの仕事をこなさねばならない宿命を常に背負っている。そのため従来からの慣習を踏襲しがちだ。そんな中、業界標準を作ったから使えと頭から命令しても普及しない。大体、今回の検討会に参加している6社は、業界標準化案が作成された暁には、自社のシステム開発業務に本当に取り入れていくのかを確認してから作業に当たってほしいものだ。既に9社により発表済みの機能要求に対応した業界標準仕様「発注者ビューガイドライン」を、作業を行った9社が本当に自社業務に取り入れていくのか注目したい。(ESN)
http://ja.wikipedia.org/wiki/%E8%A6%81%E6%B1%82%E4%BB%95%E6%A7%98
【コメント】情報システムを開発する際には機能要求と非機能要求を明確にし、ユーザーと開発ベンダーの間で確認しながら、開発を進めていく。ここでいう機能要求とは、業務フローや業務データとその処理方法のこと。また、非機能要求とは、業務データ処理量、応答速度、同時処理件数、さらに障害耐性などのことで、いわゆるシステム基盤のことだと思えばいい。特に非機能要求について、不十分な認識に基づいて開発した場合は、想定外の方法で運用しなければならなかったり、稼働後に問題が発覚した場合には、修正のためのコスト負担が増大する。機能要求については9社による「実践的アプローチに基づく要求仕様の発注者ビュー検討会」が、08/03/18に「発注者ビューガイドライン」を完成させ発表している。
今回の「非機能要求グレード検討会」の発足の背景には、最近、特に金融機関で多発しているシステムダウンなどの問題があるといえる。東証の例のように、想定外のアクセスの急増によってシステムが動かなくなったりすることがある。これはユーザーと開発ベンダーとの間の意思疎通が十分に行われないために発生する。このようなことを回避するには、業界全体で標準化された基準を設け、これに基づいてシステム開発を行えばいいという結論になる。
この意味からすると今回の同検討会の発足は、問題解決の第一歩が踏み出されたということはできる。しかし、問題点も内在している。その1つは“見える化”である。最近、猫も杓子も見える化を頻発するが、見える化=問題解決という図式に必ずしもならないケースもある点に注意すべきだ。システムが複雑になればなるほど見える化も複雑になり、この結果結局は見えないことに終わりかねない。要は何が重要で何が副次的要素かをまず仕分けてから、見える化に取り組むことが肝要だ。
もう1つは現場との遊離に注意しなければならない点。現場はあすの仕事をこなさねばならない宿命を常に背負っている。そのため従来からの慣習を踏襲しがちだ。そんな中、業界標準を作ったから使えと頭から命令しても普及しない。大体、今回の検討会に参加している6社は、業界標準化案が作成された暁には、自社のシステム開発業務に本当に取り入れていくのかを確認してから作業に当たってほしいものだ。既に9社により発表済みの機能要求に対応した業界標準仕様「発注者ビューガイドライン」を、作業を行った9社が本当に自社業務に取り入れていくのか注目したい。(ESN)
http://ja.wikipedia.org/wiki/%E8%A6%81%E6%B1%82%E4%BB%95%E6%A7%98