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

多くの人が知る、人気リポジトリの開発の裏側とは? スター数4200超えを誇る『peco』の作者・牧 大輔(@lestrrat)さんに聞きました。

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

あるひとつのプログラムやツールが公開され、開発を加速させる。
そのツールから生み出されたものが公開され、多くの人に影響を与え、次なる開発を加速させる。
本稿を読む皆さんの多くは、こうした拡散するエンジニアリング、つまりオープンソースというカルチャーの一側面から恩恵を受け、また影響を与えているでしょう。

2014年7月にリリースされたツール『peco』は、まさに“影響を与えた”オープンソース・ソフトウェア(以下、OSS)でした。インタラクティブなフィルタリングツールであるpecoはシンプルな機能ながら、その使い勝手の良さによって、2017年12月の時点でGitHub上で4200以上のスターを獲得している人気のツールです。

無数のリポジトリが集積されているGitHubでpecoが抜きん出た理由とは、そして、そもそもどのような経緯でpecoは生み出されたのでしょうか。知られざる「人気リポジトリの向こう側」と、オープンソースというカルチャーとの関わり方を、開発者である牧 大輔(まき・だいすけ/@lestrratさんに聞きました。

「ただの練習」から始まった開発

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

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

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

1

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

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

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

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

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

2

牧 大輔さん:アメリカの大学を卒業後、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ホップ先の人たちは、一度インストールしたらずっと使い続ける人が多くて。そこまで行くと、手応えを感じて頑張れるようになりますよね。

3pecoの基礎の基礎 - Qiita4
{$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さんが、今度は「これはコナミコマンドを作るしかない!」とツイッターでけしかけてきたんです(笑)。

{$image_11}

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

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

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

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

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

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く