1人でソフトウェアを開発しているときに注意すべきこと

chaika 1.7.0 をリリースした時に論争になってしまった話とそこから得た教訓について、自戒の意味も込めてはてブロ最初のエントリとしたいと思います。

TL;DR

1人で開発しているときは特に自分が使いやすい方向へと開発しがち
- 一般には開発へのモチベーションという面でいいことだが、機能・デザインの変更や削除を行うときには弊害にもなりうる
- 自分があまり使わない機能について考えが疎かになってしまう
ユーザーに影響の大きそうな変更を行うときにはきちんとユーザー分析をしましょう
また、変更の理由についてユーザーにしっかり説明しよう

経緯

「論争」の中身について。

そもそも chaika って何？という人もいると思うので大まかに説明すると、これは Firefox に2ちゃんねる専ブラ機能を追加するアドオンで、自分は2013年1月あたりから開発に参加しています。 (ちなみに chaika 自体は2008年11月から、chaika の fork 元の bbs2chreader は2004年ごろ?から開発開始)

問題の ver 1.7.0 は 10/14 に AMO (addons.mozilla.org) へリリース審査の申請を出して、11/1 に approve されました。git log によると 1.7.0 の開発を始めたのは去年の10月なので、約1年間（だいぶ休止期間もあったけれど）開発していたことになります。

# git log --grep "ver 1.7.0pre"
commit 66fd84cab5dd07fc56cae0c9a8cdcafd49e93c13
Author: nodaguti <nodaguti@gmail.com>
Date:   Sun Oct 13 22:47:07 2013 +0900

    ver 1.7.0pre

開発期間中に Australis を搭載した Firefox 30 がリリースされ、賛否両論ありながらもサイドバーを開くボタンが削除されるなどしたこともあり、chaika からもサイドバーボタンを取り除いてスッキリしよう！と思ったわけです（詳細な理由は以下）。

933 ：nodaguti ◆ChaIKa/3o0ks ：2014/11/03(月) 22:51:23.82 ID:DuZjFdrc0
ツールバーボタンに関し、混乱を招いてしまい申し訳ございません。
chaika 1.7.0 においてサイドバーを開くためのボタンを
削除するに至った経緯についてご説明したいと思います。

もともと自分はサイドバーの開閉を全くしない（いつも開きっぱなし）という使用方法をしていることもあり、
chaika のツールバーボタンについて以下のような考えを持っていました:
（以下、削除したボタンをサイドバーボタン、しなかったボタンを機能ボタンと仮に呼びます）

・（大掛かりな変更をする動機）
　1.6.3 以前にはツールバーボタンのコードについて問題があり、根本的に書き換える必要がある。例えば:
　　- 機能ボタンは削除できないし、位置も変更できない。
　　- ツールバーボタンとコンテキストメニューの処理は互いに複雑に絡みあっており、保守性に問題がある。

・（サイドバーボタンを削除する動機）
　似たようなボタンがツールバーに2つあり混乱を招きやすい。具体的には:
　　- テンプレ（>>2）にて解説が記載されていることからも、分かりにくいという潜在的な意見があるのではないか？
　　- Australis にて「サイドバーを開くためのボタン」は削除されており、メニューの一項目となっている。
　　 （https://bugzilla.mozilla.org/show_bug.cgi?id=881436 も参照）
　　 個人的にも、ひとつのアドオンがツールバーのスペースを多く専有するのはあまり良いことだと思わないし、
　　 一つのボタン（機能ボタン）に統合したほうがよいのではないか？

以上をモチベーションとして、4/9に開発版にてサイドバーボタンを削除致しました。
https://github.com/chaika/chaika/commit/5832d059958ffe77562881df5566132ed7d04cc3

また、上記考えに加え、約半年の間、開発版をご利用下さっているユーザーの皆様から
大きな反対意見が出なかったというのもリリースまでに削除を取りやめなかった理由として挙げられます。

（bbs2chreader/chaika Part43 >>933 より引用）

しかしその結果、リリース後には主にボタンを利用してサイドバーの開閉・切り替えを頻繁に行っていたユーザーからかなりの反発を受けてしまいました。例えば:

888 ：名無しさん＠お腹いっぱい。：2014/11/03(月) 14:26:04.55 ID:WKUl5qmA0
>>870
情報ありがとうござます。
1.7.1インストールしてみました。
確かに、ツールバーボタンのクリックで、
サイドバーが表示されるようになりました。
でも、以下の問題があります。

オプションの「chaikaおよび掲示板上でのみ表示する」に
チェックを入れてると、そもそもボタンが表示されない。
で、chaikaを表示したくても、ボタンが使えない。

何回もインストールして、ようやく気づきましたよ。
まぁ、表示しっぱなしにしておけばいいのかもしれないけど、
サイドバーを活用するインターフェースなのに、
その表示のためのボタンを消したのはやはりよくわかりません。
(ボタンが押下状態にならないのも気になりました)

1.7.0で検索も使えるようになったし、開発者さんには感謝もしてるけど、
もう少し慎重になってほしい面も感じました。

（bbs2chreader/chaika Part43 >>888 より引用）

901 ：名無しさん＠お腹いっぱい。：2014/11/03(月) 17:51:09.09 ID:WKUl5qmA0
>>894
あえて書かせてもらうと、「機能を削除したこと自体」だよ。
サイドバー用のボタンは使わない人とっては非表示にしておけばよいし、
使う人にとっては「Windowsボタン/スタートボタン」並のUIだったのよ。
それを、納得できる合理的な理由も無しに削除されて、
ユーザーとしては訳がわからないわけですよ。
アイコンはともかく、細かい表示含めて、あれで洗練されてたUIだと思ってたから。

（bbs2chreader/chaika Part43 >>901 より引用）

923 ：名無しさん＠お腹いっぱい。：2014/11/03(月) 19:07:33.20 ID:BJjboqEK0
nodaguti
頼むから元に戻してくれないか？
アイコン変更は別に構わないんだが
サイドバー表示が面倒になったし、アイコン2つあったのに
1つに集約されてそこから全て操作しないといけなくなったし
本当ひどいよこれ

（bbs2chreader/chaika Part43 >>923 より引用）

つまり、1年間開発をしていたものの、

934 ：nodaguti ◆ChaIKa/3o0ks ：2014/11/03(月) 22:52:25.03 ID:DuZjFdrc0
>>933 続き

しかしながら、結果として「サイドバーを頻繁に開閉するユーザーは少ないのではないか？」という、
自分の使用方法だけに基づいた誤った仮定によって変更を強行してしまった形となりました。

「既存機能の削除」という、かなり影響の大きい変更を行う際には、
開発版にて実験を行うだけでなくスレッド上でもご意見を伺う必要があったと反省しております。
申し訳ございませんでした。

（bbs2chreader/chaika Part43 >>934 より引用）

という問題があったわけです。

教訓

反省：反発を生まないようにするためには

上記スレッドでも書いたのですが、様々な理由から削除に踏み切ったとはいえ結果的に「サイドバーボタンを使っているユーザーの存在」を軽視してしまったことに批判が生まれた原因があると思います。

思い返してみると、これまでの chaika の開発では、機能を追加したり、より便利に拡張したりということはあったものの、ある意味で「より不便に」するような変更や、機能を削除したことはありませんでした。そうした変更を行う場合には、変更/削除される機能を使っているユーザーがどのような不便を被るのかについて、詳細に検討したうえで実施の可否を考える必要があったと言えます。

また、削除の根拠についてあまりユーザーに説明していなかったというのも原因として挙げられます。仕様の変更や機能の削除などは他のソフトウェアでも珍しいことではありませんが、それらの多くはリリース前あるいはリリースノートなどでその理由を説明しています。また、「デザインの向上」など曖昧な理由の場合には、批判を受けることも少なくないように思われます。今回は、ボタンの削除という重大な変更を行うのにも関わらず説明不足でした。

すなわち、ユーザーに不利益を与えかねない変更を行う場合には、影響についてよく検討し、またユーザーへの説明責任をきちんと果たす必要があると考えられます。

開発者が一人の場合に陥りやすい罠

よくよく考えてみると、フリーソフトウェアというのは「自分が使いたい」から作っているものです。他の理由の場合もあるかもしれませんが、少なくとも自分はそうです。お金にならないにもかかわらず、使いたくないソフトウェアを作るのに何百時間という時間を費やすはずがありません。

また、開発しながら日々使っているわけなので、いわばドッグフードを常に食べている状態になります。ソフトウェアに対して使い勝手は隅々まで把握しているはずです。

こうした背景から、本来開発において、ソフトウェアを使いやすくする変更はあっても、「使いにくく」するような変更（≒批判を受けるような変更）はしないはずです（余談：だからこそ使い勝手に大きく影響するようなバグは早く修正されるわけですが）。しかし、実際には、それまでの使い方を変えてしまうような変更を行うと、少なからず批判が出てくることになります。それは何故でしょうか？

私はここに、開発者が1人もしくは極めて少数であるソフトウェアを開発する際において陥りやすい罠があるように思います。すなわち、「開発者が少ない場合は使い方に多様性がない」ということです。

様々な機能を搭載したソフトウェアを作っていたとしても、実際に自分が使うときに使う機能はそのうちの一部に過ぎないでしょう。普段使う機能ならば使い勝手はよくわかりますが、あまり使わない機能については実装をテストするときくらいしか使わないのが実情です。開発者が多くいる場合には、いろいろな使い方をする人がいることで「ドッグフードを食べるときにほとんど使われない機能」を限りなく少なくすることができますが、開発者が一人の場合にはそうもいきません。

自分が使わない機能を変更する場合には、その変更によってどのような使い勝手の向上/低下がもたらされるか、想像がしにくいのではないでしょうか。つまり、機能を変更/削除をするときに、自分が使わない機能については無意識のうちに変更に対する心理的ハードルが低くなってしまうかもしれないということです（これは「開発者は自分が使わない機能を使っているユーザーを軽視している」というわけではありません）。

罠から逃れるには

完全に自分の好きなように作ってしまうと、上記のような罠に嵌ってしまう可能性が高くなります。まあフリーソフトウェアは慈善事業ではないので、批判されても気にせず自分の使いたいものを作ればよいのかもしれませんが、私は自分だけでなく、ユーザーがみな便利に使えるソフトウェアを作りたいと考えています。

では、ある機能を削除したり、仕様を変更したいと思った時にはどうするべきなのか。これについては、使い勝手のことは実際に使っている人に聞けということで、アンケートなどで User Voice を収集するとよいのではないかと思います。つまり、開発者が少ない分をユーザーの声を詳細に聞くことで補うわけです。実際、chaika でも今回の反省を踏まえて早速アンケートを実施しました。

また、繰り返しとなってしまいますが、判断の根拠について納得の行く説明を行うことも重要です。この点、アンケートというのは判断の定量的な根拠にもなるので優秀です（もちろん「アンケートに答えてくれる層」というのがどういう層なのかも考える必要がありますが）。要望を却下する場合でも、却下した理由をきちんと説明することは必要なプロセスと言えるでしょう（chaika の Issues）。