品質評価ってどうしましょう？ - TECH BLOG

はじめに

弊社のSIの中心はSalesforceプラットフォーム上でのカスタマイズやApex、Visualforceによる開発です。
また、弊社製品であるSkyVisualEditorやSkyOnDemand、DCSpiderといったツールを使用した構築も行われます。

Javaや.NETといった従来のスクラッチ開発でも、各種ライブラリなどを適用することはありますが、SaaSの場合は、多くの機能が部品化されて提供されており、部品を組み合わせ、設定を行うことで、従来ならプログラムコードを書かなければならなかった機能を実現できるようになりました。

プログラムコードが必要な範囲が縮小され、ノンプログラミングで実現できるシステムの範囲が広がるにつれ、そうしたシステムについて、高い品質を維持するために、品質そのものをどのように計測し、評価すれば良いのか、品質評価基準の定義というものの変化を感じます。

今回は、そうした新しいシステム構築での品質の計測や評価について、従来と何が異なり何が同じなのか、記事にしてみたいと思います。

これまでの一般的なシステム構築プロジェクトに於いては、作成されたプログラム、構築されたシステムの品質を評価する場合、

①プログラムコードのステップ数
②テストケースの網羅性
③バグの発生件数

の3つの数値を指標とすることがよくあります。

ステップ数　VS　テストケース数　でテスト自体の品質
テストケース数　VS　バグ発生件数　で動作の品質
ステップ数　VS　バグ発生件数　で製造の品質

を測ろうという考え方です。

これはバリバリのプログラミングによるスクラッチのシステム開発ではオーソドックスな考え方で、品質の定量化のためにこうしたフォーマットで品質報告書の作成を行うシステム部門は多いと思います。

しかし、SaaSプラットフォームにこれをそのまま適用しようと思うと、いくつもの難題が立ちはだかります。
定量化のための3つの指標について順に見て行きましょう。

①ステップ数

先に挙げたプラットフォームでステップ数を計測することは出来るでしょうか。以下に見て行きましょう。

Salesforceのカスタマイズ：プログラムコードで作成されるものではないのでステップ数が存在しない
SkyVisualEditorによる画面開発：Apexコードが書き出されるため、コードのステップ数は取得できるが、Apexコード自体がSkyVisualEditorが自動生成するもので、プログラマが記述したものではない。自動生成されたApexコードの正常動作はサービス側で担保される。
SkyOnDemandによる連携スクリプト：アイコンを配置し、アイコン同士を線で結ぶことで、処理順序を決定することでスクリプト（Jarファイル）が自動生成されるため、ステップ数が存在しない

と、いきなり躓いてしまいました。

ステップ数（コード）が存在しないか、或いは存在していてもそれはプログラマが記述したものではなく、サービス側が自動生成するコードだったりするわけです。
勿論、プログラマが直接コーディングを行い、画面やトリガを実装する場合は、そのプログラムコードのステップ数をカウントすることは出来ますが、機能単位で見た時に、その機能の実現に要した開発作業の総量を測ろうと考えた場合、ステップ数という概念を適用することは難しそうです。

では、Salesforceで構築されたシステムの、標準カスタマイズも含めたボリュームの定量化はどうすれば良いでしょうか。
一例としては、メタデータと設定系オブジェクトのレコード数の増分を利用する、という方法があります。

Salesforce組織はメタデータと設定系オブジェクトへの設定レコードの登録によって、動作に必要な主な情報を格納しています。
そこにマスタやトランザクション系のオブジェクトへレコードが登録をされていくわけです。
であるならば、

システム構築前のメタデータのボリュームとシステム構築後のメタデータのボリューム
システム構築前の設定系オブジェクトのボリュームとシステム構築後の設定系オブジェクトのボリューム

の2つの差分を計測することで、「システム構築による増分」を数値化することができます。
これらに対し、任意の係数で重み付けを行った上で、Apexコードのステップ数を加えることで、システム全体のボリュームを表す数字として利用できます。

このようにステップ数という指標が適用できないケースに対し、代わりとなる定量化の方法を定めておくことで、ステップ数による構成の定量化、という従来型の評価方法に寄せて、評価を行おうとするアプローチは出来ると思います。

②テストケース数

Salesforceの標準カスタマイズで作られた画面の場合、各項目は設定された書式（数値、テキストなど）での入力を受け付け、始めから配置された「保存」ボタンによって、レコードが保存される、といった一連の動作がプラットフォームによって自動的に提供されます。
多くは入力や参照といった仕様を決め、その通りにマウス操作で設定を行うことで、その通りに動作をします。

ただ、Visualforceのようにプログラムされて動作する画面でなくても、入力規則による書式の制限などをカスタマイズによって実装することもありますし、各項目に画面上で入力可能な最大文字数と、実際に保存される文字数、レコード参照時に参照画面に表示される値といった動作が意図した通りになっているかといった観点も必要になります。

プログラムコードの動作が正しく作られているか、という観点ではありませんが、カスタマイズなどの結果、最終成果物として完成した画面が、意図した通りの動作を得られているかのチェックといった意味合いが強くなりますが、スクラッチ開発の場合と同様のテストケースを起票してテストをしています。
ただ、標準カスタマイズの場合は、コードが存在せず、プラットフォーム側で動作が保証される性格上、不合格が皆無に近いので、設定ミスや仕様の齟齬が無ければ、自ずとケースの合格率はとても高いものになります。
この辺りはケース合格率の考え方の尺度をスクラッチ開発とは別に考えた方が良さそうです。

③バグ発生件数

テストケースの消化時に想定通りの動作を得られず不合格となったものをバグと位置付け、ケース数に対するバグ数やバグの内容の重篤度合いによって、品質を計測します。
バグの内容の重大さによってランク付けを行い、テスト完了時にスコアリングをし、リリース判定に利用します。

バグの発生原因として、
、

プラットフォームの動作上の不具合
プログラムコード上のミス
実装上の考慮漏れ
仕様理解の齟齬

といったことが考えられ、例えば考慮漏れが多いなど、何が原因のバグがどの程度発生したか、といった属性も、品質評価の上で、役立ちます。
テストフェーズが進むにつれて、バグの発生率が収束しつつあるのかといった、潜在的なバグのリスクを見通す上でも、既存バグの評価は重要です。

まとめ

これまでに書いたように、構築されたシステムのボリューム、テストのボリューム、バグの件数の3つの要素を以て、品質評価を行いますが、リリース判定に当たり、何を重視し、どの程度の高さのハードルを設定するか、クライアントや案件毎に変動するものでもあります。

バグのランク付けも、影響範囲に応じて、何をSランクとするか等、予め定義・合意をしておかないと、テスト以降のリリーススケジュールが何時まで経っても確定しない、といった状況を招いてしまうようなことも考えられます。

ポイントを3つに絞ると以下のようになります。

ボリュームを定量化する方法の定義
レガシーな尺度とは別の考え方
維持すべき品質と遵守すべきスケジュールのバランス

SaaSのプラットフォーム上でシステム構築をする場合に、その品質に対する考え方も、柔軟に新しいものを取り入れていく姿勢が大事だと感じます。

また、品質とスケジュールの両立をするためには、クライアントとの間にも、品質の基準や計測といった考え方について、共通理解を醸成し、齟齬が無い状態で、レビューやディスカッションが出来る環境を作っていくことが最も重要だと思います。

最後に、従来からの品質評価の手法においては、プログラムコードの総量であるステップ数をもって、それに対する適切なケース数や、バグ数、といったその後の品質のハードルが設定される場合が多く、疑似的にステップ数へと換算を行うことで、従来型のアプローチに載せることは出来なくはないでしょう。

ただ、ここまで述べてきたように、（プラットフォーム下の層を除外すると）プラットフォーム上ではプログラムコードの存在しないシステムというものが存在し得る状況が生まれているわけですので、「ステップ数」を拠り所とした品質評価の手法そのものがクラウドの流れに対し、既にレガシーなものとなりつつあり、AppExchangeやデータ連携、Heroku、Lightningファミリーなど、システムの規模が広がり、更に複雑化していくであろう中で、ステップ数という概念に代わる、新しい数値化の方法が必要になってきているのだと思います。

技術の革新と同時に、このような品質評価の考え方もそれに追い付いて行かなければならず、ステップ数とはもっと別のモノサシを作って行かなければならないと思います。