スター数4200超！ 人気リポジトリ『peco』 開発者（@lestrrat）が語る「使われるOSS」の作り方

──まずはpecoに関して説明していただけますか。

牧　pecoは、コマンドラインで動作する、インタラクティブなフィルタリングツールです。基本的な機能として、標準入力されたデータをインクリメンタル検索して、その結果を出力してくれます。さらに、強力なカスタマイズ機能を備えています。

具体的な動作は、pecoのREADMEに掲載されている次のgifを見てもらうと分かりやすいでしょう。この動画では、psコマンドで現在実行中のプロセスを表示させて、それをpecoで絞り込んでいます。

従来、このような操作をする場合、psコマンドの出力をgrepで絞り込むというのが一般的でした。でも、絞り込むキーワードがうろ覚えだったり、間違えたりすると、何度もやり直す必要があります。しかし、入力のたびに即座に絞り込むことができれば、キーワードを全て入力する必要がなくなり、間違えてもすぐに対応することが可能になるのです。スマホやPCの予測変換でも、こんな感じのインクリメンタル検索が利用できますよね。

pecoは、このようなインタラクティブな操作性を、コマンドラインにもたらすフィルタリングツールなのです。

──2014年に登場したpecoは、非常に人気があります。多くのエンジニアが使用感をレポートしている、いわば“ヒット作”です。どのような経緯からpecoの開発に乗り出したのでしょうか。

牧　percolという便利なツールがあると、仲間内で上がってきたんですが、自分の環境のせいか、一回でインストールすることができませんでした。Pythonで作られていたのですが、自分はあまり詳しくないし、調べるのも面倒くさいと思っていたら、mattn（@mattn_jp）という人から「じゃあ書いちゃえよ！」と煽られて、どんなツールかもよく知らずにpercolを参考に書き始めたんです。

ライブラリやフィルタみたいなコマンドラインツールは書いたことがあったのですが、この手のインタラクティブなものは初めてでした。エディタみたいにメニューが出てくるとか、コマンドでモードが変わるとか、そういうのは全然書いたことがなくって。いわば、pecoは開発の練習代わりに作り始めたんです。

牧 大輔さん：アメリカの大学を卒業後、Network Applianceに入社。2004年に帰国してからはライブドア・LINE等を経て、現在は株式会社HDEに在籍。また、Japan Perl Associationを立ち上げ、YAPC::Asia Tokyoの運営に10年間たずさわった。さらに新しい技術カンファレンスであるbuildersconを主催している。現在は、3人の子供の父親業のかたわらコードを書く。著書に「みんなのGo言語（共著）」「モダンPerl入門」などがある。

──明確な目的があって作ったわけではない、と（笑）。

牧　しかも、覚えて日の浅かったGo言語で書いたので、初めての人がハマるところに、すべてどハマりしました。やらなくていいところで非同期処理してみたり。

──練習のために既存のツールを書き直すことが、よくあるんですか。

牧　特に自分で使うライブラリ類は、気になることがあって簡単な変更では足りなさそうな場合、仕組みを理解するために書き直してみることは多いです。

──かなりの手間に思えますが……。

牧　イチから作り直すのは、仕組みを理解しないと自分の欲しいと思った変更が有用なのか、また、可能なのか分からないからです。それに理解できていないものを使うのが不安なので。

一番気になるのは、「このライブラリは、なぜこのようなAPIなのか」という点です。ユーザーに対して、どうしてこの入り口と出口しか与えていないのかなと。そしてAPIの設計の根幹を理解するためには、裏でやっていることを理解しないと分からないことが多いので、一度ばらしてみるのが早いと思います。

──pecoは、はじめから反響が大きかったんですか。

牧　当初は仲間内の盛り上がりだけでした。それでも、着手してから、2週間から1ヶ月ぐらいで、なんとか使えるものができて、少しずつフィードバックが来るようになって、開発を続けたっていう感じですね 。

少しずつpecoが広がっていくのを感じたので、GitHubでプロジェクトのアカウントを取ってOrganizationにしたんです。ただ、それ以降順調だったかというとそうでもなく、一番の課題だったのは、練習のつもりで書いていたせいで、スパゲッティコードになってしまったことです。フィードバックをもらっても、スパゲッティコードのままだと、他の人は手を入れようがないんですよね。

開発者が語る、pecoの勝因

──そうしているうちに、一段と大きな反響になっていたんですよね。一番手ごたえを感じたのは、どんな時でしたか?

牧　自分の1ホップ2ホップ先の人たちが使い始めたって聞いた時ですよね。一番近くにいる人たちは、とりあえず一度使ってみるだけ、ということも多いんです（笑）。フィードバックをくれるんだけど、飽きたらおしまいという。

でも、1ホップ2ホップ先の人たちは、一度インストールしたらずっと使い続ける人が多くて。そこまで行くと、手応えを感じて頑張れるようになりますよね。

pecoの基礎の基礎 - Qiita
{$image_5}え、まだpecoを使ってないの？？？ - Qiita{$image_6}
{$image_7}pecoでエンジニア人生を10倍楽にしよう！ — ALL-IN Tech Blog{$image_8}

pecoを検索すると、このようなリポートが多数ヒットする。

──Qiita上に存在するのpeco関連の記事にも、かなりコメントを残していますよね。

牧　pecoが盛り上げってきたと感じたタイミングで、かなり積極的にコメントしましたね。エゴサもよくしますよ（笑）。僕は、自分の運営しているカンファレンスでも、トピックス全てにハッシュタグを用意して常にサーチするようにしています。

──当初と想像していたのと違う、意外な使い方しているケースもありましたか。

牧　Androidアプリの開発で、イメージファイルをインストールするなんて使い方もありましたね。自分では、Android開発はしないので、こういうのは想像が及びません。僕もpecoを毎日使っていますが、ひどく限定的な使い方をしているので何もクリエイティブなことはしていないと思います。

{$image_9}Sample Usage · peco/peco Wiki · GitHub{$image_10}

pecoの利用例は、こちらにまとまっている

──元ネタのpercolも、同じようにインクリメンタルサーチを実現するツールなんですよね。それに対して、pecoの優位性って何だったんでしょう。

牧　強いて言えばインストールのための手間が、ファイルをコピーするだけ、という点でしょうか。

自分がpercolを試した時にインストール失敗した理由は結局調べませんでしたが、ほぼ100%自分の環境の問題だったはずです。なのに、僕はもう二度とインストールを試みようとは思いませんでした。自分が短気すぎるのかもしれませんが、同じような感想を持った人もいたのではないでしょうか。

後で知ったのですが、pecoやpercolとよく似たツールとしては、fzfというのもありました。これはvimとの連携に優れているので、すごく人気がある印象です。fzfもpecoと同様、バイナリファイルをコピーしてくれば動くタイプのツールです。

僕は、pecoがpercolやfzfより圧倒的に優れているとは思っていません。ユーザーが好きなものを使えばいいと思っています。ただ、カジュアルなユーザーにとっては、単純に最初の導入コストの高さ・低さこそ大事だろう、というのが正直な感想です。

──だからこそ、「インストールしやすい」pecoは支持された、と。

牧　さらにもう一つ理由を挙げるとすれば、同じようなツールがいくつかあって、どんぐりの背比べ状態の中でpecoが一定の支持を得られたのは、READMEが充実していたからだと思っています。リポジトリの持つ機能が直感的に分かるのが重要なんです。

こうした「見せ方」の部分はかなり意識しました。カンファレンスの運営をしていても感じますが、人は文章をほとんど読んでくれません（笑）。見出しと、写真・画像がなければ、伝えるべきことも伝わらない、ということがpecoでよく分かりました。

開発者にとっての「良いフィードバック」とは

──機能もさることながら、見せ方というマーケティング的側面を重視したからこそのヒットだったのですね。これまでかなり多くのプルリクがあったと思いますが、マージする方針はあるんですか。

牧　プルリクに対する僕のスタンスは、自分が注視している領域のものでなければ、壊れてないなら受け取る、という感じです。それを使う人がいるか、テストされているか、どのように動くのか書いてあるか確認したら、あとはハイハイと受け入れちゃうんです。

プルリクが来るのは、自分の知らない領域での使い方であることが多いので、そもそも僕が対案を考えてもあまり良いものが出てこない。

──用途が広がっていくなかで、自分の専門外の領域からのプルリクは基本受け入れる、という考え方ですね。そもそも、「いいプルリク」ってどのようなものでしょうか。

牧　フィードバックで多いのは、一言だけ「こういう機能があったらいいと思う」とか、「俺、こういう機能を実装した」とだけ書いてあるパターンです。

一方で、開発者として受け入れやすいのは、「変更の行数は少ないけど、多くのテストパターンを持っているフィードバック」です。たくさんのテストパターンがあると、これいいね、と取り込みやすいです。

テストは、検証作業として以外に、「作ったものがどういう使われ方をするのか」を明確にするためにも重要だと思います。テストがないと、何をしたいのか分かりません。例えば「暗号化の機能を追加しました」と言われても、その機能をどういう場面でどのように使うのか一切書いてないとマージできない。でも、テストを書くと、こういう時にこう使う、というのがコードレベルで表現されるんです。

──自分がフィードバックする時も、それを心がけているんですか。

牧　そうですね。全然知らない相手に対してプルリクを出す時、フィードバックする時は、日記を書くように伝えます。「今日これこれこういうことがあって、何日か頭をひねってみたけども、できなかった」のように。 ツーカーの間柄の人ならば、もっとざっくりとしたものになりますが。

──印象的だったプルリクはありますか。

牧　技術的なものよりも、READMEに貼ってある説明動画に対して、「私のように視覚に障がいがある人のアクセシビリティのために、動画画像にもメタデータ内で説明を書くべき」というIssueをもらったのが一番はっとさせられました。当然、README内に説明文はあるんですが、動画についてはまったくケアしてなくて、“気付かされた”という意味では、一番印象深いフィードバックでした。

──それは面白いですね。他に、pecoに大きな影響を与えたプルリクなどはありますか。

牧　Emacsの「C-x, C-cで終了する」みたいに、連続した複数キーの入力を取り込んでコマンドにするというプルリクをもらったんですね。でも、それだけでは、自分だったら使いたいと思わなかった。すると例のmattnさんが、今度は「これはコナミコマンドを作るしかない！」とツイッターでけしかけてきたんです（笑）。

pecoに実装されている、コナミコマンドのコード。「↑↑↓↓←→←→ba」というまさにコナミコマンドが確認できる。

──つまり「pecoにネタを仕込んでおけ」ということですね（笑）。

牧　しかし、ネタを実装するためには根本的なところから直さなきゃいけなくなってしまったんです（笑）。従来１つずつキーをもらっていたのを、ちゃんと状態遷移していくFSM（Finite State Machine：有限オートマトン）を作らなきゃいけなかったんですね。

イチから実装するのは面倒くさいとつぶやいたら、似たような機能を作った方から返信が来て、コードをまるごとパクらせてもらって実装したんです。これが、今までで一番大きな変更ですね。

オープンソースでない理由はない

──まさにオープンソースというカルチャーの恩恵ですね。そもそもなのですが、pecoをOSSとして開発したのはなぜですか。

牧　元々、アメリカの大学でコンピュータサイエンスを勉強して、本格的にプログラミングの世界に入ったんです。当時の僕のいた環境では、オープンソースを使ったり、参加したりというが当たり前になっていたので、僕はたぶん、最初からソースコードをシェアする世界に生きているんですよ。なので、むしろシェアしない方が不自然かもしれません。

僕が最初に長く勤めた会社は、いわゆるネットベンチャー系の会社で、作っている製品のOSはFreeBSDベースでしたし、UNIXの古典ツールの作者もエンジニアリングチームにいるという環境でした。そんな環境だったので正直、クローズドソースはめんどくさいと思ったことはあれ、有用だと思ったことは一度もないんです（笑）。

FreeBSD は、さまざまなプラットフォーム に対応したオペレーティングシステムで、機能、スピード、安定性に焦点が置かれています。 FreeBSDはBSDと呼ばれる、カリフォルニア大学バークレー校で開発されたUNIX®に由来しており、多くの人々が参加する開発者チームによって開発・保守がおこなわれています。

引用：The FreeBSD Project

思い返せば、そもそも、オープンソースかどうかを議論する場さえなかったんですよね。最初からオープンソースのツールを使っていましたし。大学で授業を受ける時も、すでにテキストブックをめくるより、ネットで探したほうが早い時代でした。もちろん、今ほど速度があったわけではないけれど、探せばヒントは見つかる。

オープンソースじゃないものって、せいぜいJavaくらいでした。でも、Javaにしたって仕様はオープンだったので、使い方はネットのどこかを見た方が断然早かった。

基本的に、こんな流れで技術を身に付けてきたから、オープンソースにする・しないではなく、そもそもオープンソースの状態があって、必要に応じて「これはクローズドにする」と検討するくらいです。pecoに関しては最初からクローズにする意図は一切なかったですね。クローズドだと飽きた時にメンテナンスを移譲するのも大変ですし。

──pecoをOSSとしたことで得られることもあったのでしょうか。

牧　pecoみたいなツールがあると、カンファレンスに行った時なんかに、自己紹介が楽ですよね。

もう一つ、オープンソースには、意図的に関わり始めた側面もあります。アメリカで仕事をするには就労ビザが必要で、ビザのためには会社のサポートが不可欠でした。会社から見捨てられたら終わりなわけです。でも、海外の会社はクビになるときは簡単にクビになるので、会社の外に行ったときに評価を獲得するために、オープンソースを始めたんです。

──エンジニアとしての生存戦略にも関わるということですね。若い人にも、オープンソースの活動を薦めますか

牧　学生以上だったらガンガン参加した方がいいと思いますね。技術向上もさることながら、コミュニティとの付き合い方のプロトコルを体験できるところなので。

──何かツールを作ってGitHubで公開するだけじゃなく、いろんなコミュニティに飛び込んでいって、誰かといろんなことをやるのが実はいいかもしれない、と。

牧　そうですね。何かの変更を他人に取り込んでほしい時に、自分の意図をちゃんと通すことができるかどうかは、その変更がどれだけ技術的に素晴らしいか、という点だけでなく、それを必要だ・便利だと思わせるためのプレゼンテーションと対話力にかかってくると思います。

コードの書き方とかは、オープンソースであろうとなかろうと、時間と手間をかければ身に付けられることなんですけど、対話力は、相手がいないとできないので、そういう意味ではオープンソースプロジェクトへの参加は効果的だと思います。

ときには「OSSの敵」になれ

──オープンソースに対する有用なフィードバックの話も、こちらの意図を相手に理解してもらう対話力とコミュニケーション力といえるかも知れないですね。

牧　他人のプロジェクトに参加する際に大事なのは、こちらも、相手の意図を理解することだと思います。開発者が何をやろうとしているのか、何が難しいと感じてるのか分からないとコミュニケーションが取れません。

例えば、スペルミスを直すとか、枝葉の部分を直すことはそういう理解がなくとも簡単にできますが、根本的なところに手を入れようと思ったら、開発者側が究極的に何を求めていのかを理解しないといけない。

──そのために「練習のために書き直す」という話がでてくるんですね。

今年の春に、「OSSの敵になるのもいいじゃない」という発表をしたんです。

OSSにプルリクを送らないで、フォークして、自分で研究したり書き直したりすることをやらないと、理解できないし覚えられないことがあるので、どんどんフォークしましょう、という話です。冗談で「既存のライブラリに貢献しないとは、このOSSの敵め！」と呼ばれたりします（笑）。

この発表では、go-fluent-clientというGoのライブラリ例にしています。疑問に感じる部分を掘っていったら、結局msgpackを実装せざるを得ず、そのプロトコルを全部調べて、もう一度、イチから実装するっていうことをやりました。

ここでポイントになるのは、さっきも言ったAPIの話です 。APIを変える必要がなければ、プルリクを送るべきですが、もしAPIの変更が必要な場合、影響範囲が大きいのでプルリクを送っても基本的にマージしてもらえないんですよ。マージしてもらうためには、かなりの説得力が必要で、その説得力を獲得するためには、徹底的に実装を理解しないといけない。そして実装を理解するためには、自分でイチから書いてしまえ、というわけです。イチから書いたのであれば、それはプルリクではなくフォークさせてしまえ、となる。

──書き直すレベルでコードを書きまくり、バラして再構築するところまでやってみる。ここまで馬力を持てれば、“その先”はだいぶ変わってきそうですね。

牧　あるトピックについての深い理解や、創造性のような素養が必要な部分はまた違うと思いますが、少なくともコードを書くという点においては明らかに「素振り」をしてる回数が違ってくるので、なんらかの差は出るでしょうね。

取材・構成：可知 豊

【編集履歴】文中にある「メッセージパック」の表記を「msgpack」と修正しました（2018年1月30日）