Making Software ―エビデンスが変えるソフトウェア開発

517

最初の試みがうまく行かなかった場合……

作業スタイルに従っているため、

1

つの

API

に対してさまざまな異なるエクスペリエンスを持ち得ます。

これらすべてを考慮しないまま

API

のユーザビリティを定めようとしても、私たちがカード整列調査

で遭遇したように、何の結果も得られない可能性が大です。

たとえカード整列調査で共通のグループ分けが分かったとしても、その結果をどのように使えるかが

はっきりしないでしょう。もし

API

のデザインを変更してクラス群がこの空想上のグループにより良

く対応するようにしたとしても、どうやってその変更が開発者の

API

を使用する能力に与える効果を

測ったらよいのでしょう？

API

が被験者の概念モデルに対応付けられたことは分かりますが、それは

良いことなのでしょうか？

私たちは本当に

API

のデザインをその

API

を使ったことがない開発者の概

念モデルに対応付けるべきなのでしょうか？

実際のところ、上

記の論点は私がカード整列調査を設計し実行した際に主張していたことなのですが、

振り返って見るとこの議論には信頼性が欠けていました。カード整列調査の結果私が確信したのは、も

し本当に

API

のユーザビリティを理解したいのなら、本当の開発者が本当のタスクを解決するために

API

を使っているところを調査する必要がある、ということでした。

有難いことに、マイクロソフト社の文化は、私が最初の

API

調査で有用な結果を何ももたらさなかっ

たにも関らず、

API

のユーザビリティを測ったり記述する方法を探究し続けるよう励ましてくれました。 ...