徒然技術日記

Object.prototype.__noSuchMethod__

インターンシップの応募にお祈りされた原因を分析した (Microsoft, はてな, Yahoo! Japan)

Internship

これは以下の記事の派生記事です．

nodaguti.hatenablog.com

選考に落ちた企業について，その原因を探ってみたいと思います．今後応募される方の参考になれば．

Microsoft

MSR (Microsoft Research) ではなく MSD (Microsoft Development) の方です．書類選考で落とされました．

提出物

  • 履歴書 (日本語): A4 1枚
  • 履歴書 (英語): A4 1枚
  • プログラミング経験とプロジェクト内容をまとめたドキュメント: A4 3枚以内

所感

マイクロソフト、アビームのインターン選考。ES通過！（マイクロソフトはテクニカルスクリーニングで落選） : 就活奮闘記

には，

学歴フィルターかと思ったが、同じ大学の同期で落とされた人もいたので、ある程度大きなプロジェクトを作っていれば通過したのではないか、という結論。

と書かれていたので，chaika の開発もしているし書類選考は通るだろうと高をくくっていました．

しかしながら書類審査で見事に落選．原因として考えられるのは，

  • 英語の履歴書が適当すぎた．
    • プロジェクトについてのアピールは専用のドキュメントがあるし書かなくていいかなーと思って省いた結果，スッカスカの履歴書になってしまった．
  • プロジェクトの中から1つ選んで詳しく説明する必要があるのだが，そこで ESChat を選んでしまった．
    • 「プロジェクトの目的」「工夫した部分」などが chaika だと書きにくいと感じたからだが，結果的にあまり大規模なプログラムでないものを選択してしまった．

あたりかなと考えています．

はてな

はてなは書類選考のみで合否が決まります．東京在住の自分にとっては，京都観光もできるし，はてなは界隈では有名ということもあってかなり志望度は高かったものの，残念ながら落選．

通知メールには「最終選考まで残った」旨が書かれていましたが，

という見方も当たらずとも遠からずな気がします．

提出物

Google のフォームを使った応募画面でした．

これまでの制作物や研究内容などをまとめたポートフォリオのほか，「言語経験」「担当したいサービス」などを記入する小設問があったように記憶しています．

所感

これは純粋に「宿泊費を負担してまで東京からわざわざ呼び寄せてもらえるだけの技術力がなかった」という一点に尽きるかなと思います．

過去のインターン生の Github とかを見てみても，とても敵わないなという方が多いですし，仮に同程度の技術力の人がいて，一方が京都住まいでもう一人が東京だったとしたら，京都の人を選ぶでしょう．特に関西圏でない学生は，京都に住んでいる学生に比べてかなり選考通過のハードルが上がるのではないでしょうか？

はてなの場合は，毎年インターン生に課している事前課題を Github で公開している(2015年度事前課題, 2014年度事前課題) ので，インターン生でなくても腕試し的に解くことができるようになっています．また，事前課題を解くにあたっては上記リポジトリを fork して解答をアップロードするようになっているので，参加者の Github アカウントも探ることができます．このあたりから，はてなインターンに要求される技術力を推察することができるかもしれません．

Yahoo! Japan

フロントエンドばかりではつまらないかなと思い，最近インフラ周り(特にインフラを仮想化するあたり)が盛り上がってきているように感じていたので，そういう方面のインターンに参加してみるのもよい経験になるのではという考えから，あえて「クラウドインフラストラクチャコース」に応募しました．

結果としては，書類選考通過→面接落ち でした．

提出物

  • 書類選考
    • 学業で力を入れたこと，または研究内容 (500字)
    • 一番自信のあるプログラムについて (300字)
    • (論文の発表経験がある場合) 論文の概要について (300字)
  • 面接
    • 履歴書
    • (要求はされていないが) ポートフォリオを印刷したものを持って行きました．

所感

面接は終始なごやかな感じでした．しかし，あとでサイバーエージェントの面接を受けた時に気付かされたのですが，Webサービスをサーバー側含めて運用したことのない人間がインフラコースに応募するのは無謀だったようです．

手取り足取り教えてもらおう，という意識ではなく，期間前後を含めて集中的に学びたい！という姿勢でいたつもりだったのですが，やはり未経験ということは大きかったです．面接でも JavaScript でこういうもの作りました！ という話がメインになってしまったため，おそらく面接官の内心としては「なんでこいつこのコースに応募してきたんだろう？」という感じだったことでしょう．結果的に甘い気持ちでいた私の落ち度と言えます．

ただ，ポートフォリオを持参したことはかなり好印象だったように思います．

http://www.alperithm.jp/?p=256www.alperithm.jp

の記事でもオススメされている通り，面接時の話の種にもなるので，かなり有効だと思います．

まとめ

  • もっと技術力を高めよう．
  • 「興味がある」だけでは選考に通らない．実績が伴っている分野のインターンに参加しよう．

P.S.

グーグル、アップル、マイクロソフトに就職する方法

グーグル、アップル、マイクロソフトに就職する方法

夏のインターン選考結果および傾向と対策をまとめてみた

Internship

今年の夏はインターンの夏にしよう．と思いたち，Web系企業をターゲットにインターンへ応募したので，結果などをまとめてみたいと思います．

応募した企業

辞退した/お祈りされた企業

参加する企業

共通の対策

インターン申し込みにあたって，行ったこと．

Github を充実させる

いままでの成果をアピールするために，大学の講義で作ったものや，chaika のアップローダにアップロードしただけのアドオンなど，まだ公開していなかった制作物を全て Github にアップロードしました．

また，それぞれに詳細な README をつけ，どのようなプロダクトなのかを明記するようにしました．事前に Github のアカウントを見ていただけた企業では，「READMEが詳しい」というのが好印象だったようなので，単に公開するだけでなく，簡単にでも README を記載しておくのは重要だと感じました．

ポートフォリオの作成

もともとは はてな のエントリー要件としてポートフォリオを作るという項目があったのがきっかけですが，いままで制作したものを時系列に並べたページを作成し，応募フォームに URL を書き込んだり，面接時に印刷して持っていったりしました．

  • 口頭でいろいろ紹介するよりも端的に，かつ分かりやすく示せる．
  • 文書ならば，事前に内容をじっくり推敲できる．
  • 面接時に話の種になる．

など多くのメリットがあるため，仮に求められていなくても作成しておくことをお勧めします．

内容としては，公開できない部分もあるのでスクリーンショットになりますが，大体以下のような感じのもので，プロダクト名，関連する画像，概要，工夫した点，公開場所，ダウンロード数などをまとめています．

f:id:Nodaguti:20150808111810p:plain

集合知の検索

とりあえず「企業名 インターン」などでググると情報が出てくるので，参考にしました．

詳細

以下の2ページに，個々の企業ごとに詳細をまとめています．

nodaguti.hatenablog.com

nodaguti.hatenablog.com

最後に

身の程知らずにも Amazon の Wish List を作成してみましたのでご参考まで．

この夏は充実した夏休みになりそうです！
サイバーエージェント様とドワンゴ様，どうぞよろしくお願いいたします．

クリエイティブ業界を目指す人のための　ポートフォリオ見本帳

クリエイティブ業界を目指す人のための　ポートフォリオ見本帳

ポートフォリオをつくろう！―新しい自己PRのための「編集デザイン」

ポートフォリオをつくろう！―新しい自己PRのための「編集デザイン」

プログラムからFirefoxのScratchpadでファイルを開き、適切にシンタックスハイライトをするには

Firefox Add-on

Firefox のアドオンにおいて、Atom や Sublime Text のように plain text な設定ファイルをメニューから開けるようにするにはどのような方法が考えられるでしょうか。

nsIFile#launch

XPCOM を使って任意のファイルを開くためにまず思いつくのは、nsIFile#launch を使う方法です。

developer.mozilla.org

しかし、これは（おそらく）OS に処理を丸投げしているだけなため、状況や環境によっては問題が生じます。例えば、JSON や XML を開きたい場合、それらがテキストエディタに関連付けられていない環境では、ウェブブラウザで開かれてしまったり、最悪該当アプリケーションがないというエラーが出てしまったりします。

nsIFile#reveal

同じく nsIFile から、reveal メソッドを使うという方法も考えられます。これは、ファイルに対して用いるとそのファイルを内包しているフォルダを開くという動作になります（Mac における Reveal in Finder のような機能）。

launch を使うよりはまだマシですが、結局 JSON や XML の取り扱いに関する知識をユーザーに求めるという点においてあまりよい方法とは言えないでしょう。

nsIProcess

nsIProcess を利用して、エディタを指定したうえでファイルを開くという方法もあります。

developer.mozilla.org

この方法では、Mac/Windows/Linuxでデフォルトのエディタを変えなければならず、設定が複雑になるという欠点があります。

しかし、設定画面を作ることでユーザーが使い慣れたエディタを指定できるようにするなどの機能を提供できるという利点もあるため、ファイルをエディタで開くという動作が多くあるようなアドオンでは検討に値するかもしれません。

Scratchpad

Firefox には Scratchpad という CodeMirror ベースのエディタが内蔵されています。

developer.mozilla.org

しかしながら、開発者がどのように Scratchpad を使ったらよいかについての解説は MDN に書かれているものの、プログラムからどのように操作できるのかという点についてはドキュメントが全く存在しません。せっかく内蔵しているのにもったいない…

というわけで、本体のコードを読み解くことで判明した利用方法は以下の通りです。

let fileToOpen = ...; // nsIFile
let { ScratchpadManager } = Cu.import('resource:///modules/devtools/scratchpad-manager.jsm', {});
let win = ScratchpadManager.openScratchpad();

win.addEventListener('load', () => {
    win.Scratchpad.addObserver({
        onReady: () => {
            win.Scratchpad.removeObserver(this);
            win.Scratchpad.importFromFile(fileToOpen, false, () => {
                win.Scratchpad.editor.setMode({ name: 'xml' });
            });
        }
    });
});

まず、resource:///modules/devtools/scratchpad-manager.jsm にて定義されている ScratchpadManager を読み込みます。

そして、openScratchpad メソッドにより Scratchpad を開きます。このメソッドは aState という Optional な引数をとり、初期化時のパラメータを渡すことができるようです。おそらく、Firefox の起動時に前回 Scratchpad で開いていたファイルを復元するために使われているのだと思われます。しかし、ファイル名、ファイルの内容(テキスト)、実行コンテキスト(Content or Browser)を渡せるのみであり、今回の用途には適しませんでした。

ウィンドウの読み込みを待った後は、エディタの初期化を待つ必要があります。これには Scratchpad.addObserver を用います。初期化が完了すると onReady が呼ばれます。

最後に、ファイルを読み込むためには Scratchpad.importFromFile(aFile, aSilent, aCallback) を用います。aFile は読み込むファイルを、aSilent は読み込み失敗時にエラーを表示するかどうかを、aCallback は読み込みが完了した時に呼ばれるコールバックを指定します。

JavaScript を読み込む分には aCallback を無指定にして読みこめば完了ですが、（Scratchpad は JavaScript 専用エディタのようにできているにも関わらず）他のタイプのファイルを読み込むことも可能であり、その場合はシンタックスハイライトを適切に設定しなくてはいけません。具体的には上の win.Scratchpad.editor.setMode({ name: 'xml' }); の部分がそれです。

エディタの設定は Scratchpad.editor（実体は devtools/sourceeditor/editor.js）からいろいろできるっぽく（あまり調べていない）、いじってみるとなにかおもしろいことができそうな雰囲気がします。ちなみに、editor.js には xml というモードは定義されていませんが、指定してみたら動作しました :)

まとめ

  • テキストファイルを開くなら nsIProcess か Scratchpad
  • Scratchpad を外部からいろいろやるとおもしろそう

Components.utils.import でグローバル汚染を引き起こさずにインポートする方法

Firefox Add-on

Firefox 本体ではおそらくだいぶ前から使われているだろうから今更感あるし、2015年にもなって Mozilla-specific な JavaScript の記事に需要があるのかはわからないけれど、先ほどとあるコードモジュールを読んでいて知見を得たので共有します。

Components.utils.import は第2引数に何も指定しない場合、コードが書かれているスコープではなく、グローバルスコープに指定したモジュールを展開します。そのため、せっかく以下のように Module Pattern を使って書いていたとしても、グローバル汚染が引き起こされます。

(function(global){
    "use strict";

    Components.utils.import("resource://my-module/Hoge.jsm");
    // do something
})((this || 0).self || global);

Hoge === undefined; // -> false

しかしながら、第2引数に名前空間を指定して、モジュールに対しては常にその名前空間を介してアクセスするというのもコードが無駄に冗長になり、つらみが高まります。

let Modules = {};
Components.utils.import("resource://my-module/Hoge.jsm", Modules);
    
Modules.Hoge.foo();
if(Modules.Hoge.bar()){
    // do something
}

そこで有効なのが、Components.utils.import がモジュールのグローバルオブジェクトを返すということを利用し、空のオブジェクトをスコープとして渡した上で、返り値をローカル変数で受ける方法です。Object destructuring を用いることでかなり簡潔に書くことができます。

let { Hoge } = Components.utils.import("resource://my-module/Hoge.jsm", {});

返り値の利用は非推奨(use of the return value is discouraged)と MDN に書かれているのが若干気になるところですが、Firefox 本体にも多く使われているテクニックなので恐らく大丈夫でしょう。

(追記 2015/5/16 18:00) id:Syoichi さまのご指摘に基づき、Object destructuring と Shorthand Properties を誤解していたことが判明したため、上記最後の部分を修正。元文章は以下の通り。 

let { Hoge: Hoge } = Components.utils.import("resource://my-module/Hoge.jsm", {});

返り値の利用は非推奨(use of the return value is discouraged)と MDN に書かれているのが若干気になるところですが、Firefox 本体にも多く使われているテクニックなので恐らく大丈夫でしょう。

さらに、Firefox 33 以降であれば Shorthand Properties が使えるので、上記はより簡潔に

let { Hoge } = Components.utils.import("resource://my-module/Hoge.jsm", {});

と書くことができます。

STAP記者会見の最後で相澤チームリーダーが言いたかったこと

Miscellaneous

今日10:30から行われていた「理化学研究所 STAP現象の検証結果に関する記者会見 生中継」をニコ生で見ていた。

一般紙の記者は、誤解を恐れずに言うと「一般人的」あるいは「文系」的な質問をするのに対し、相澤チームリーダーや丹羽副チームリーダーはあくまで科学者として科学の発想で以って回答をしていたので、話が若干噛み合っていないのが辛そうだった。

どちらにとっても互いに互いの話の筋が通っていないように思えるという疲労度の高い記者会見だったのではないかと思う。

記者会見の終了が宣言されたのち、一旦会場を去りかけた相澤チームリーダーが戻ってきて、印象的な発言をしていた。その内容とは、以下に書き起こしてみると、大体以下のようなものであった:

（今回の）検証実験、特に小保方さんの検証実験を、このようにモニターをおいたり立会人をおいたりして行うというのは科学のやり方ではないと思っている。
科学のことは科学のやり方で処理しなければいけないので、そういうふうな検証実験をしてしまったことに対して、検証実験の責任者としてものすごい責任を感じている。
今後なにかあるたびにこのように犯罪人のような扱いをしたうえで科学の行為を検証するということは、科学にあってはならないことだと思っている。
このことに関しては、検証実験責任者として、深くお詫びを申し上げると共に、責任を痛感している。

(上記ニコ生 2:13:10 付近より)

このことに関して、ニコ生のコメントでは理解できないと言ったようなコメントも複数見受けられたが、これは上の考え方が科学界特有の考え方だからであろう。そのことについて自分なりの解釈を書いてみたいと思う。（書いていてなんだか社説みたいになってしまった…）

科学において「正しい」とはなにか？

(論文の正しさの度合い)

[正しくない]|||||||||||||||||||||[中立]|||||||||||||||||||||[正しい]

科学では、論文を発表した段階では基本的に「中立」として扱われる。つまり、正しいとも正しくないとも言えない、ということである。

ただ、一般的に完全に「中立」から始まるというとそうではなく、若干「正しい」よりになることも多い。なぜならば、

  • 丹羽副チームリーダーも話していたように科学が基本的に性善説で成り立っている
  • 一定水準以上の査読付き論文誌に掲載された論文ならば、それなりに信憑性があるものと考えられる

からだ。つまり、初めから信頼度の高い方法で発表された論文は、正しさの尺度の中で、スタートが「正しい」寄りになるということである。STAP細胞の場合には、権威ある Nature 誌に掲載されたことで、だいぶ「正しい」度合いが高い状態で発表されたと言える。

そののち、世界各地の研究者が追試、すなわち再現実験を行ってみて、複数回成功すれば論文の内容が正しい可能性が非常に高くなる（「定説」になる）し、失敗報告が相次げば「正しくない」として、研究内容は信頼を失うことになるし、場合によっては研究者自身の信頼性も揺らぐかもしれない。

すなわち、再現実験がどれだけ成功したかで論文の信頼性、信憑性が判断されるし、逆にそれ以外では判断されないものなのである（捏造の場合にも再現性がないことから信頼性がなくなると考えられる）。

（このあたりの話は「99.9%は仮説」にある「グレースケールの尺度」の話がわかりやすい）

99・9%は仮説 思いこみで判断しないための考え方 (光文社新書)

99・9%は仮説 思いこみで判断しないための考え方 (光文社新書)

今回の検証実験は必要なかった

相澤リーダーはそこまで踏み込まなかったが、相澤リーダーは今回のような検証実験を行う必要はなかった、行うべきではなかったと考えているのではないか、と個人的には推測している。

STAP細胞の論文は、論文発表後に世界中の研究者が再現できなかった時点で、その信頼性は全くなくなっている。つまり、科学界においては、本検証実験を始める前の段階ですでに、論文に書かれた方法で作成でき、かつ論文に書かれたような性質を示すような「STAP細胞」は存在しない、ということは誰の目にも明らかであった。

相澤リーダーが言っていることは、そのように科学界では「STAP細胞」が存在しないことは明らかであるのに、監視下で「再現実験」なるものを行うのは、単なる見せしめ、世論を満足させるためのショーであって、科学でも何でもないということなのだろう。

たしかに、多額の税金を投入し、あたかも再生医療における革新的発見であるかのように大々的に宣伝したことに対する罪滅ぼし、禊のような役割として本検証実験は必要であったかもしれない。しかし、相澤リーダーは一科学者として、このような科学に反する実験を行ったことに対して、科学界へ一言謝罪を言わずにはいられなかったのだと思う。

科学の世界は俗世から離れている

このような考え方は、部下が問題を起こしたら上司が責任を取って辞めるといった考えとは真っ向から反するものである。つまり、一般社会と科学界では発想、考え方が全く違うのである。マスコミは一般社会の考え方で記事を書き、科学者は科学界の考え方で発言をする。

「STAP細胞はあるのかないのか？」という質問に対して歯切れが悪い科学者に苛つくのと同様、本発言もなかなか理解しにくいものかもしれない（「捨て台詞」といった解釈をしたコメントもあった）。

しかし、「発想が違う」から「その考え方は正しい」のか？というとこれもまた難しい問題であり、必ずしもそうとは言えないだろう。互いに相互理解をするためには歩み寄りが必要だが、科学界は専門用語が飛び交う場でもあるのでなかなか溝は埋まりにくいと思う。

捏造の科学者 STAP細胞事件

捏造の科学者 STAP細胞事件

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

Product Management

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）。

最後に

書いてから改めて考えてみると、自分がテストを疎かにしたりユーザー分析を疎かにしたりと開発を適当にやりすぎていることが主な原因ですね…… 申し訳ないです。

偉そうに長文を書きましたが、きっとこんなこともできてないのか！と思われている方が多いかと思います。今後さらに精進していきますのでどうかよろしくお願いします。

顧客を知るためのデータマネジメントプラットフォーム　DMP入門 (NextPublishing)

顧客を知るためのデータマネジメントプラットフォーム　DMP入門 (NextPublishing)

  • 作者:横山 隆治
  • 発売日: 2013/05/14
  • メディア: オンデマンド (ペーパーバック)

ブログ移行

Miscellaneous

旧ブログ よりこちらに移行します。

向こうでは Bloxsom でブログ環境を構築していたわけなのですが、いちいち HTML を書かなければいけないのがめんどくさすぎるので気軽な更新ができず、放置する結果となってしまいました。

Markdown で書くことができ、技術系に向いているという定評があるはてなブログに移動することで、更新頻度を上げられたらと思っております。