製品の比較資料では、機能を多く並べるほど判断しやすくなるとは限りません。比較の依頼を受けたら、先に決めたいことと、そのために揃える試用条件を書き出します。
この記事に書いてあること
比較表を作る前に、誰が何を決める資料かを書きます。たとえば「来期のCIツールを選ぶ。開発チームの承認者が、必須条件を満たす候補の中から試験導入先を決める」という粒度です。
最初の一枚に置くのは、暫定結論、判断を変える条件、決めてほしいことです。機能一覧と個人の感想は、その判断に必要な箇所から出します。
iPad miniの使用レビューと比較報告の違い
以前の原稿では、iPad mini 5のWi-FiモデルからiPad mini 6のセルラーモデルに替えた人の使用レビューを題材にしました。外出時に接続しやすくなった体験は、使い方を想像する参考になります。世代だけの差を比較する資料なら、通信方式を揃えて試す必要があります。 当時の使用レビュー
よくある3つの比較ミス
片方しか検証していない機能を製品差にする、同じ利点を表現を変えて何度も数える、試用担当者の印象を実測結果として書く。この3つが重なると、承認者は表の点数が何を意味するか判断できません。
同じ作業で比べて、採否まで書く
以下はCIツールA・Bを比べた架空の記入例です。同じコミット、JDK 17、同等のランナー、キャッシュなしの条件で、同じJUnitスイートを3回動かします。開始時刻、完了時刻、結果を控え、必須の監査ログは両方で操作して確認します。
| 評価項目 | ツールA | ツールB |
|---|---|---|
| JUnit一式を実行 | 成功 | 成功 |
| 実行結果の監査ログを90日残せる | 設定と仕様で確認済み | 90日保持の可否は未確認 |
| 実行時間の中央値 | 8分 | 6分 |
この例の報告は「監査ログが必須なのでAを試験導入候補とする。Bは90日保持を確認できれば再評価する」です。Bが速いという観察を残しつつ、未確認の項目が決まれば結論を更新できます。
共通点と製品差を分ける
同じJUnitが通ることは共通点です。監査ログの保管可否は候補の絞り込みに使えます。ただし、Bの「未確認」は「できない」とは違います。仕様の根拠がなく実機でも確認できなかった、と書けば次の調査が決まります。
言葉を変えて同じことを言っている
「ビルドが速い」「テスト待ちが減る」「終業前に回しやすい」が同じ測定結果に基づくなら、見出しは実行時間にまとめます。業務への効果はその下に一文で添えます。項目数で有利になる集計を避けられます。
実測と使った人の感想を分ける
「設定が分かりやすかった」と書くなら、誰が何をしたかを添えます。たとえば「初参加の2人がサンプル設定で初回テストを完了。迷った箇所はログの保管設定」です。測った時間や操作記録と並べると、他の人でも同じ条件を試せます。
レビューコメントは「Bを速さで推す理由は読み取れました。監査ログの保存が必須なので、90日の根拠と、未確認のままなら何を採るかを一行で追記してください」と返せます。
