おのたく日記 YouTubeも始めました→

■ プログラムの変更要求の出し方

「2004-12-07 BUGデータベースの書き方」に続いて吉岡さんの日記は、BUGレポートの送り方について語っている。良いBugレポートの書き方と言う事で、真剣に読んでいた。そしたら、その次の日の吉岡さんの日記にも、良い事が書いてあった。

私のようにソフトウェアを開発している側としては、変更要求というか、不具合のレポートというか、そのようなたぐいのものを毎日のように受け取っている。

吉岡さんの例だと、海外にあるオープンソースコミュニティの開発者に、日本のユーザなどが、変更要求を出すときの話だけど、私の場合は、世界中のユーザから上がってくる要求を次のバージョンにコストを上げず、どうやって反映していくか、日々なやんでいる開発部隊に属している人間なので、立場は逆。

そんな立場で、吉岡さんの

どんな問題を解きたいかという宣言で、それをどう解くかと言う事ではない事に注意してほしい。

われわれは多分問題をよく知っている。しかし解き方を一番良く知っているとは限らない。

DEC時代の尊敬するエンジニアのGayn Wintersは常に「問題を正しく理解しろ」と言っていた。問題を正しく理解することは難しい。本当に難しい。われわれはともすると、問題を理解する前に回答に飛びついてしまう。何が本当に問題なのか？徹底的に考えろとよく言っていた。

[2004-12-08 要求の出し方 - 未来のいつか/hyoshiokの日記より引用]

というのを読むと、「そうそう」と、うなずける。

実際に、ソフトウェアに知見のあるプロフェショナルなユーザからの変更要求の中で多いのは「こういう風に変更しろ」というもの、それに対して「はいそうですね」といってプログラムを修正するは、開発者としては変更方法まで示されているから簡単。

このユーザは、自分の使い方で変更すると良い方法を示してきている。一人のユーザ専用のソフトウェアならば、言われたとおりに修正してしまうのが「ユーザのご意見どおりに直しました」ってことで、ユーザの納得も得やすいし簡単。

しかし、多くのユーザに使われているソフトウェアの場合には、他のユーザの事を考えると、そういうわけにはいかない。

また、ユーザの示した修正方法が、最終的にユーザが欲しい物ではない場合がある。

さらに、外見から簡単に修正できるように思える方法と、中の基本的な部分から変える方法の工数を比べた場合に、実は、外見から簡単に見える修正方法の方が手間が掛ってしまう場合なんてもある。

そんなことがあるので、ソフトウェアの変更要求では「それをどう解くか」より「どんな問題を解きたいか」という情報を上げてもらった方が、多くの役にたつように感じたのが、同意の理由。

ただ、ユーザとしては、「こうすると使いやすいのにな」と修正方法を示すのは簡単でも、「どんな問題を解きたいか」ということを、正しく示す方法というのは、むずかしいんですよね〜

ある程度ソフトウェアのプロフェショナルである、お客様であっても「『それをどう解くか』より『どんな問題を解きたいか』という情報を上げてくれるほうが、うれしいのでそうしてください。」とお願いしたり、その利点を分かってもらうのは更に難しい…

というわけで、吉岡さんの日記に書いてあるようなことを、ユーザに読んでもらえていたら嬉しいとも思った。

(私の開発しているソフトウェアのユーザの9割は、日本語が読めない人々なんだれどね)