RQ2：提案方法は実際の Web API に有効か?

表7-7 習得容易性の評価結果の比較 サービス名 習得容易性

(Web APIサンプル充実性)の評価結果 実証実験での評価結果

Uber 0.96 <1> 0.9 <1>

WordPress 0.70 <3> 0.3 <3>

OpenStack 0.12 <4> 0.2 <4>

メディア処理API 0.92 <2> 0.8 <2>

7.3.1で算出した習得容易性の品質評価値と実証実験での評価値の順位が一致した．従って，尺度，測定方法，

品質評価関数は妥当であると判断できる．また，習得容易性の尺度の値を求める際にAPIドキュメントのみを 用いたので，開発初期に適用可能となる．

各サービスの品質評価値について考察する．

Uberは全リクエストにサンプルがあり，必須のパラメータやプロパティ以外は1個以上のサンプルが記載 されていることが高評価につながった．

OpenStackの品質評価値が低いのは，リクエストのパラメータが階層構造を持っているWeb APIだけにし

かサンプルが記載されていないからある．OpenStackのAPIコンシューマはOpenStackのAPIプロバイダ でもあり，現状は問題視されていないと推察している．しかし，一般のAPIコンシューマにとっては習得が困 難であると判断した．

WordPressはリクエストのサンプルはあるものの，オプショナルなパラメータに全くサンプルを提示しない．

さらにレスポンスのプロパティはサンプルのみならず定義も全く記載しないため品質評価値が下がる．

メディア処理APIは，APIドキュメントとしての記述項目の充実を図るための指導を受けていた．その指導 によりリクエスト側の記述が非常に充実し，高評価につながった．一方，レスポンス側のサンプルが不十分で あることが明確になったので，APIプロバイダに対して改善に向けた提言を行うことができた．

この結果をUddinらの実証結果[84]と比較する．UddinらはAPIドキュメントの問題を10個挙げ，それら を発生頻度，影響の大きさで分類している．その中で深刻さが高い問題として不完全さ(Incompleteness)，曖 昧さ(Ambiguity)，説明不足(Unexplained examples)，不正確さ(Incorrectness)の4つを挙げている．これら の中で，曖昧さと説明不足の問題は，ドキュメント中のサンプルによって軽減できることが実証されている．

これら二つの問題を，本稿で示した習得容易性によって定量的に評価できるようになる．なお，不完全さは他

のWeb APIとのインタラクションの説明不足の問題，不正確さはAPIドキュメントと実際の動作に差異があ

ることによる問題である．不完全さは複数のAPIのドキュメントの横断的な分析が必要であり，不正確さの評

価はWeb APIの実際の動作を確認する必要があるため，本稿で示した習得容易性では定量化できない．

7.4.2.2 安定性

安定性に関して，Web APIの実際の変更内容の詳細解析による確認，及び，Web APIプロバイダ（提供者）

が公表していた成熟度との比較，の2通りの方法で有効性を検証する．

(1) Web APIの実際の変更内容の詳細解析による確認

7.2.4.1で述べた通り“Web APIを利用する前に保守の期間や工数を予測できるか”との観点で算出した安

定性について考察する．

図7-9は安定性を算出した7サービスについて，各月における安定性をプロットし，時系列変化を示してい

る．7.3.2では，安定性を高い，低い，中程度の3種類が観察できた．時系列変化も，安定性が高くかつ変動量

が少なく推移しているもの，低くかつ変動量が少なく推移しているもの，安定性が変動しているもの，の3種 類が確認できる．そこで，それぞれから代表的な1サービスをサンプルとし，実際に発生しているWeb APIの 変更量を確認する．

(a) 安定性が高くかつ変動量が少なく推移しているもの：Glance

図7-10はGlanceの非互換差分量と互換差分量の推移である．非互換差分は2017年3月に1件発生してい

るのみである．また互換差分は2017年3月に1件，7月に4件，2018年1月に1件と数ヶ月に一度程度でし か発生していない．Web APIコンシューマは，非互換変更によるインタフェース変更への対応はほとんど必要 なく，また，互換変更による品質影響の確認もほとんど必要ない状態であるといえる．従って，安定性の高さ

がWeb APIコンシューマの保守工数の低さを十分に表しているといえる．

(b) 安定性が低くかつ変動量が少なく推移しているもの：Cinder

図7-11はCinderの非互換差分量と互換差分量の推移である．非互換差分量は互換差分量よりも少ないもの

の毎月10件前後は発生しており，APIコンシューマが常にインタフェース変更へ注意する必要があることが 読み取れる．また，互換差分量も常に20 件前後は発生している状態であるため，インタフェース変更に現れ ない内部品質にも注意が必要な状態であると推測できる．

図7-9 安定性の月ごとの推移

図7-11 Cinderの変更量の時系列変化

図7-10 Glanceの変更量の時系列変化

(c) 安定性が変動しているもの：Manila

図7-12はManilaの非互換差分量と互換差分量の推移である．非互換変更に着目すると，2017年2月から

7月までは0件，また11月から2018年1月まででは1件しか発生していない．しかし，2017年8月～10月 は合計で 16 件も非互換変更が発生している．互換変更については非互換変更と完全に重なっているわけでは ないが，非互換変更と同様に変更が発生している期間と発生していない期間がある．

このように時期によって変更量が大きく異なる場合は，その該当時期においてはWeb APIコンシューマの 対応工数が多くなることが推測できる．

図7-13は図7-9からManilaの安定性のみを抽出したものである．前述の通り対応工数が多くなることが推

測できる2017年8月～10月には安定性が大きく低下しており，安定性が対応工数の増減を表していることが 読み取れる．

上記の議論から，品質特性として定義した安定性によりWeb APIコンシューマの保守に必要な対応工数の 度合いを示すことができていると言える．この結果から安定性の品質モデルは，Web APIの変更の評価尺度と して妥当であり，開発初期でのAPIコンシューマにとって有用な情報を提供できるといえる．

また，今回の測定において(c)で見られた「変更が発生する時期」について調査したところ，OpenStackのメ ジャーリリースの時期と重なっていることがわかった．例えば，2017年8月はメジャーリリース「Pike」の初 期リリースが行われた時期となる．メジャーリリースでは大規模な機能追加が行われることが多い．そのよう な機能追加時はインタフェースの互換性を保つことが難しいため非互換変更が発生し，Web APIコンシューマ

図7-11 Cinderの変更量の時系列変化

図7-12 Manilaの変更量の時系列変化

の対応が必要となることが多いと推測できる．この事例より，安定性の時系列変化を確認することで安定性の 変動の傾向を捉えることができ，そのような兆候が見られる場合は事前に対応工数の上積みを行う等の対策を とることが可能となる．

(2) Web APIの成熟度との比較

OpenStackの公式な情報には安定性を示すものはないが，成熟度を示すMaturityが2018年8月まで公開

されていた[67]．これはサービス利用の判断に使う目的で，自動または手動でつけられたタグをベースに7段 階の値で表現されており，安定性(Stability)と持続可能性(Sustainability)を示している．この特性は本稿で提 案した品質特性の安定性と類似しているため，Maturityと安定性の値を比較することで，安定性の妥当性につ いて考察する．

図7-14にNova，Cinder，GlanceのMaturityをリリースごとにプロットした．各サービス間のMaturity を比較すると，次の順序関係になっている．

Nova＞Cinder＞Glance (5) 安定性については表7-6に示した通り次の順で高くなっている．

Glance＞Nova＞Cinder (6) 図7-13 Manilaの安定性の推移

図7-14 公式サイト提供のリリースごとのMaturity

Nova＞Cinderについては同じ傾向を示しているが，Glanceは，Maturityは低いが安定性は高いという結 果となった．これはMaturity が安定性だけでなく持続可能性も評価しているのに対して，安定性はインタフ ェース定義の変更量のみを評価しているためと推測される．

また，リリースを重ねるごとにMaturityは上昇していく．そこで，安定性にも同じ傾向があるかを各月に おける安定性を算出して確認した(図7-15)．安定性に関しても上昇傾向が見られる．ただし，Nova，Cinder，

Glanceともに2017年7月の周辺で一時的に安定性が低下している．これは2017年8月30日のPikeのリリ ースと関係があると推測できる．図 7-15 はPike のリリース後に公式サイトで確認したMaturity であるが Pikeで低下していることが確認できた．他のリリースと比較してリリースからの経過日数が少ないことに起因 すると推測されるが，安定性においても同様な傾向が確認できた．

上記の議論から，公式サイトが提供する安定性を示すMaturityと品質特性として定義した安定性は類似の 傾向を示すと言える．この結果から安定性の品質モデルは，Web APIの変更の評価尺度として妥当であり，開 発初期でのAPIコンシューマにとって有用な情報を提供できるといえる．