Tech Sketch Bucket of Technical Chips by TIS Inc.

(コラム) 非機能要求検証へのこだわり 〜「OSSは本番業務で使って大丈夫?」に答える〜

Pocket

techsketch-banner-OSS+startingblock(700x65).jpg
「道具を選ぶのは日常生活でもなかなかたいへんだなぁ」というエピソードから...

剪定バサミ1.JPG
昨年の秋,自宅で庭木の剪定用のハサミを買いました。普段手入れをサボっている木の枝が伸びすぎてしまったからです。でも,脚立に乗って使っていると,枝の先端の方にちょっとだけ届きませんでした。柄の長さが伸縮するタイプにしておけばよかったかなと,ちょっとだけ悔やみました。自分自身があまり得意でない分野で道具を選ぶというのは,ITにせよ日常生活にせよ,難しいなと感じた瞬間でした。


ITシステムはそれ自体が目的というわけではなくて,何かをするための道具ですから,その用途に合わなければどんな高価なサーバやソフトウェアでも宝の持ち腐れです。また,普通の庭木の剪定にチェーンソーを買う人はいないのと同じように,ITシステムもオーバースペックが過ぎてもお金ばかりが掛かって困ります。ITシステムでは用途に応じて道具を選ぶことはとても難しいことです。この話を突き詰めると,道具の選択の前段階である要求分析の難しさにまでさかのぼってしまいますが,今回はそこには言及しません。道具の選択の話だけです。

道具が用途に適合しているかを考えるときの中心的な関心事は,おそらくは機能面でしょう。「やりたいことができるか」から「そのような機能を持っているか」を確かめることだと思います。これには,まずはカタログのような文書に記された機能や特徴から判断するでしょうし,より入念には実際に機能するかを実物で確認するかもしれません。

けれど,道具を選択する場合,機能面の確認だけではまだ不十分です。ここからが本コラムの話題なのですが,「機能を持っている」というだけでは使い物にならないケースが多々あります。機能以外に必要なことという意味で「非機能要求」という言い方をします。わかりやすい表現をすると,強度/寿命/速さ/長さの様な特徴だと言ってもいいでしょう。ITシステムの非機能要求項目としては,可用性(連続運転や耐障害性など),性能(応答時間や処理量など),拡張性,操作性などが挙げられます。


さて,私たちはOSSの活用推進を自分たちのミッションとして活動しています。やっとここでOSSが登場しました。「OSSを採用してよかった」と言ってもらえるかどうかは,まさしく上手な道具(OSS)の選択ができるかどうかだと考えています。機能の確認ももちろん大事ですが,上手な選択のキモは非機能要求の確認だと思っています。

理由(1): 本番運用する業務システムに適用したいから
本番運用する業務といっても千差万別ですが,非機能要求が重要視されるケースが多くあります。とは言っても"稼働中に絶対に一瞬でも止まってくれるな"とか"世界中からアクセスが集中しても絶対にさばけ"ということではありません。"業務停止がどのくらいの時間になるかわからない"とか,"何人くらいの利用者まで受け付けられるかわからない"という"わからない"状況は避けてくれということです。でも,これにちゃんと答えるのは意外と難しいのです。

理由(2): 製品の性能とか可用性などの品質特性は事前には分からない
ひとことで言えば「製品ドキュメントやリリースノートには必要な情報は書かれていない」ということです。なぜかというと,性能とか可用性などの非機能要求項目の多くは使い方次第だからです。ミドルウェアやOSなどの基本ソフトでは特にそうです。実はこの点は,OSSだけの課題というわけではありません。いわゆる商用ソフトウェア製品でも同じです。ただ,商用ソフトウェア製品の場合は製品ベンダがコミットしてくれる場合もあります。また,主要なOSSでは,バージョンアップに伴う改善スピードが早くて古い測定データを適用しにくいという面もあります。


このような課題を解決するために,私たちは次のようなアプローチを取っています。このあたりはちょっとPRっぽくなりますがご容赦ください。

いろいろな検証ケースを積み上げる
私たちが対象にしているOSSや,これから候補になりそうなOSSについては,想定される組み合わせ方,使い方のテストケースを設定して検証します。個々の検証ケースは,そのテスト内容も結果もほとんどは地味なものです。実施する作業はもっと地味です。
非機能品質の検証項目.png

非機能要求の検証は地味ですが,ときどきは興味深い結果が見つかることもあります。OSSを推進したいという立場からすれば,良い結果も悪い結果もあります。それらの結果については,可能な限り公開していくようにしています。
ノウハウの公開は,IT系のメディアの方とお話しをして記事にしていただくこともあります。たとえば下記の様な例があります。
 ・日経SYSTEMS - DBサーバーの可用性を高める効果的な方式は? (目次のみ)
 ・IT Pro - 新規格MOM,AMQPやSTOMP対応,プロダクトの性能はJMSと同等以上
 ・@IT - 並列分散処理の常識をHadoopファミリから学ぶ

また,このTech-Sketchでも,いろんなOSSの検証結果や仕様レポートを公開していますので,ご参考にしていただけるとありがたいです。

推奨組み合わせを作ること
しつこくネチネチと検証を積み上げても,使い方や組み合わせ方が変わってしまうと,残念ながら同じ結果にはならないことがほとんどです。インテグレータとしては,なるべくどんな組み合わせにも対応したいとは思いますが,まずは検証結果が有効に使える組み合わせをお奨めするようにしています。"なんでもやります"と言えることよりも,非機能要求に責任を持てることを優先すべきと考えています。私たちはこの推奨している組み合わせを『ISHIGAKI Template』(イシガキテンプレート)と名付けています。
http://www.tis.jp/service_solution/ossmigration/#tabitem_3


現在,推奨組み合わせに含めることができているOSSは,最小限度の汎用的なものだけです。有益かつ用途の広いOSSはまだまだたくさん存在します。多種多様なOSSをなんでも組み込むことは本来の目的ではないものの,今よりはもう少し範囲を広げた方がいいでしょう。組み合わせるものが増えると,その分だけ検証しないといけないケースが劇的に増えますが,めげずに検証活動を積み上げていきたいと思っています!
...という意思表示で,今回は締めくくらせていただきます。






と思いましたが,書き忘れていたことがありました。

最初に述べた我が家の庭木の剪定ですが,結果的には剪定バサミは買い換えずに済ませました。がんばって脚立のもう1段上まで乗って作業をしたのです。そうすると転倒するリスクが増えます。これもIT製品の非機能要求と似ています。「無理したらそこまでいけるかもしれない」というレベルがありますが,リスクを抱えることになります。我が家での話に戻すと,リスクを回避するために妻を呼んで脚立を支えていてもらいました。これで無事に一番高い枝まで剪定できました。またまたITに話を振ると,非機能要求が不満足な点,もしくはリスクがある点を補うのに,別の道具を組み合わせて回避するというのは良くある解決策です。OSSは複数の製品を組み合わせることで,高レベルな非機能要求にも応えられるようになります。テレビショッピングに登場するような,柄が何メートルも伸びて,脚立も使わずにそれだけで一人で作業できるような高枝剪定バサミは便利だとは思いますが,そんな超ハイスペックで高価な道具でなくても日々の仕事はこなせるなと思います。

エンジニア採用中!私たちと一緒に働いてみませんか?