「ライブラリの守備範囲は狭い方がいい」こにふぁーが大切にする、ソフトウェア設計の流儀
ソフトウェアが果たすべき、機能、役割をどのように定めるか。多くのエンジニアを悩ませるこの問いに、Android開発者、こにふぁーさんは「守備範囲を狭く設定する」と答えます。こにふぁーさんがこの答えにたどり着いた道筋とは。
そのソフトウェアは何をやり、何をやらないのか──。
ソフトウェア開発において、コードを書く前に考えるべきことのひとつが、「守備範囲の設定」です。あらゆる課題に対応するソフトウェアを作るのか、あるいは明確でブレようのない「たったひとつ」を解決するソフトウェアを作るのか。守備範囲を適切に設定する、とは、エンジニアにとって重要かつ悩ましいトピックでしょう。
そして、「ライブラリの守備範囲は狭い方がいい」と語るのは、マテリアルデザイン用のアイコンを生成するAndroid Material Design Icon Generator PluginなどのOSS開発者として知られる小西裕介（こにし・ゆうすけ／ 
小西さんの歩んだキャリアや設計哲学、OSSという文化への思いに至るまで、お話を伺いました。
- 会社の存続をかけたアプリのために、Android開発者に転身
- OSS開発のきっかけは、自分のキャリアへの“焦り”
- 開発の規模は「モチベーションが続く範囲」に抑える
- ライブラリの守備範囲は狭い方がいい
- “お祭りムード”が加速したDroidKaigi公式アプリの開発
- たとえクソコードでも、まずは公開してみる
会社の存続をかけたアプリのために、Android開発者に転身
──小西さんはAndroidアプリ開発者として有名です。Androidアプリに携わるようになったのはいつ頃から？
小西 2社目に入った会社で、初めてAndroidアプリの開発に携わりました。僕はもともとWebエンジニアで、その会社ではRuby on RailsでWebサービスを開発していたんです。
当時運営していたサービスが壁にぶつかっていて、DAU（Daily Active User：1日あたりのアクティブユーザー数）を上げることが至上命題という状態でした。そして、アプリを作り直すという決断が必要だったんです。そのアプリは『Airtripp』といって、いまでこそ多くのユーザー、しかもほとんが海外の方というアプリに成長しましたが、当時はかなり切羽詰った状態でした。
小西裕介さん：BtoBのサービス開発者としてエンジニアのキャリアをスタートさせる。その後、Androidアプリ開発者として経験を重ね、現在は決済サービスを提供する株式会社Kyashに所属する。共著書に『Android アプリ設計パターン入門』がある。
──いきなりの修羅場ですね……。
小西 アプリの作り直しが決まると、Androidアプリの新規開発にリソースを集中することになりました。でも、当時の社内にはAndroid開発の経験者がいません。「じゃあ、自分がやろう」となったのがスタートです。時間的な余裕もなく、「3か月後には絶対にアプリをリリースする」ということが既に決まっていました。悠長にキャッチアップしていたら、絶対に間に合わない。焦りましたね。
──スキルを短期間で習得するのは大変だったでしょう。どうやって勉強されたんですか？
小西 QiitaやStack Overflow、Googleの公式ブログ、Android著名人のブログ・書籍などをとにかく読み漁っていました。例えば、あんざいゆき（ 
OSS開発のきっかけは、自分のキャリアへの“焦り”
──OSSのライブラリを作り出したのはどうして？
小西 至上命題だったAndroidアプリ開発はなんとか区切りをつけることができました。でも状況が落ち着いてから自分のキャリアを振り返って、めちゃくちゃ“焦り”を感じたんですよ。
──焦り、ですか。
小西 ずっと僕は1人でAndroid開発をしていたので、身の回りにAndroidについて情報共有し合えるメンバーはいませんでした。それに、対外的に目に見えるような成果を出していたわけでもなかったわけです。
カンファレンスなどで優秀なAndroid開発者を目にすると「すごいなあ……」という気持ちでいっぱいになってしまう……。自分に劣等感を覚えていたんです。
──意外でした。てっきり、スキルには自信があったのかと。
小西 いえいえ、全然です。すごいアウトプットをしている人は世の中に山ほどいるので、いまだに焦りますよ。「もっと成長しないと」と常に思っています。
当時はその不安が強くて、「自分の代表作といえるような成果を出したい」と必死でした。そこで、OSSのライブラリを作ってリポジトリを公開するようになったんです。
──最初はどんなものを作ったんですか？
小西 パブリックリポジトリに最初にアップしたのは、Youtubeの好きなシーンをエンドレスに再生できるEndlessTubeというサービスです。
でもこれは公開しようと思って作ったわけではなく、単にプライベートリポジトリが上限に達していたので、パブリックリポジトリに公開したというだけの理由です（笑）。他の人に使ってもらうことを意識して作ったのは、2014年12月に発表したAndroid Material Design Icon Generator Pluginが最初です。
12月上旬から作りはじめて12月31日に公開したので、12月中は家でひたすら開発していました。妻に「何をずっと作っているの！」とすごく怒られた記憶があります（笑）。
──確かにそれは怒られそうです（笑）。アイコンを生成するプラグインを作ったのは、どんな理由からですか？
小西 当時はマテリアルデザインが出始めた頃でした。マテリアルデザイン用のアイコンもWeb上に公開されていたのですが、開発のときにそれを毎回ダウンロードして、用途に合ったものを探して、プロジェクトに取り込むのは面倒くさい。「じゃあ、アイコンを簡単に検索してプロジェクトに取り込めるプラグインを作ってみよう」と考えました。
Android Material Design Icon Generator Pluginのサンプルアニメーション。
──Android Material Design Icon Generator Pluginは、2300以上ものスターがつく有名プラグインになりました。人気に火がついたときは驚いたのでは？
小西 最初はスターの数なんて全く見ていなくて、たくさんの人が使ってくれていることに、気づきませんでした。このリポジトリがGoogle+のAndroidコミュニティで紹介されたらしく、そこから一気に広まったんです。あるとき、職場のポーランド人の同僚が「Android Material Design Icon Generator Pluginが載っているよ。すごいな！」と教えてくれて、驚きました。いつの間にか、すごいスター数になっていましたね。
開発の規模は「モチベーションが続く範囲」に抑える
──ライブラリのアイデアはどんなときに思いつきますか？
小西 業務でアプリを開発していて、何度もくり返す作業や面倒な作業が出てきたときに「自動化・効率化するライブラリを作れないだろうか」と検討することが多いです。そしてイメージできたライブラリが自分のスキルレベルで実現可能で、モチベーションが継続しそうであれば、開発に着手します。
──モチベーションが継続するかも重要なポイントなのですね。
小西 僕はライブラリの開発に1ヶ月以上かかると、途中で飽きてしまうんですよ。「こんなに開発が面倒なら、もはや毎回手作業でやればいいじゃないか」と思ってしまいます（笑）。たとえ機能を削ってでも、モチベーションが続く規模の開発ボリュームに抑えるのことを大切にしています。
──「業務の課題を解消できそうで、かつ一定以下の工数で作れそうだ」と思って開発したライブラリにはどんなものがありますか？
小西 Unused Resources Remover for Androidがいい例です。もともとAndroid Studioには使われていないリソースを削除するクリーナー機能があったんですが、いつの間にかうまく動かなくなっていました。「いつか直るかな」と思って1年間くらい待ったんですが、直らなかったんです。
そこで、代替となるようなプラグインを作ろうと思ったんです。技術的に作成可能だというのが見えていたのと、使われていないリソースを消す機能だけに絞れば短期間で作成できそうだと考えたからです。実際、リリース時は本当にミニマムなOSSだったと思います。Androidの場合、「マルチモジュール」といって、モジュールを分けてひとつのアプリを作ることができるのですが、このマルチモジュールに対応させるのが面倒くさそうな印象があったんです（笑）。開発に飽きてしまいそうだったので、その機能に関してはリリース時に実装するのは見送りました1。
ソフトウェアの機能を拡げることで救えるユーザーもいると思いますが、難しいことをやろうとして、自分自身が開発に飽きてしまったら元も子もありません。だったら、まずは「自分にできる範囲」で形にして出してしまおうと考えたんです。
ただ、リリースしてみてREADMEの下段に自分がいま所属しているKyashのドネーション機能を埋め込んでおいたら、想像以上の寄付をいただけましたし、「おかげでコードが何千行も減った！」といったコメントももらっています。機能を絞ったとしても、そのソフトウェアを便利に使ってくれるユーザーがいればいいと思うんです。
──作業ボリュームや難易度の見積もりを正確に行うのは意外と難しいことではないでしょうか。どうすれば、着手前に見通しを立てられるようになるのでしょうか？
小西 確かに、着手する前に見積もるのは難しいです。いざ手を動かし始めて挫折してしまうこともありましたし、プライベートリポジトリには、まさにいま挫折中のものもあります（笑）。僕の場合、なにかを作ろうと思って、新たにキャッチアップすべき要素の数が閾値になっているかもしれません。理想を言えば、新たにインプットすべき要素を3つ以内に抑えると挫折することなく開発に臨めるかもしれませんね。
また、初学者向けの記事や発表資料などを普段から読んでおくと、それが引き出しになって作業ボリュームを見積もりやすくなります。例えば、Unused Resources Remover for AndroidはGradle Pluginなんですが、もともと僕はGradle Pluginの開発経験がありませんでした。でも以前、ミニマムなGradle Pluginの作り方について書かれた発表資料を読んだことがあったんです。「この資料の内容をベースにすれば、あとはロジック部分を書けばいいだけだから作れるだろう」という取っかかりになりました。
小西さんに示唆を与えた資料はこちら。
ライブラリの守備範囲は狭い方がいい
──以前、小西さんはブログで「ライブラリの守備範囲は狭い方がいい」と書かれていました。なぜでしょうか？
小西 広範囲な機能をカバーしているライブラリの場合、ロックイン問題2が発生する可能性があるからです。だから最近は、業務においてもなるべく粒の小さいライブラリを使うようにしています。もしも粒の大きいライブラリを使う際には、公開されているREADMEやコードを読んで理解し、導入しているアプリや関連する記事などを見て判断するようにしています。
──過去に携わったプロジェクトで、ロックイン問題が発生したことはありますか？
小西 Android開発を始めた頃、AndroidQueryというライブラリを導入して課題を感じたことがありました。これはjQueryにインスパイアされたライブラリで、Viewの表示まわりのヘルパー機能や通信のラッパー機能など、とにかく多種多様な機能をサポートしていました。
僕はWeb開発からキャリアをスタートしたので、「これはいい」と思って飛びついたんです。ですが最終的に、AndroidQueryはあまりメンテナンスがされなくなってしまい、他のライブラリに乗り換えました。守備範囲の広いライブラリだったので、アプリとの依存関係をはがすのが本当に大変だった記憶があります。
いま思うと、僕の選択が悪かったわけですが、たとえ判断する時点で役立ちそうなライブラリだと感じても、後々どうなるかは分かりません。だから、なるべく付け替えやすい状態にしておく方がいいんです。粒の小さいライブラリを選んだ方がいいというのは、それに起因しています。
それからAndroidアプリの構造的にも、アプリ内で使われている合計のメソッド数やアプリのバイナリサイズはなるべく小さい方がいいんです。だから近年では、広範囲な機能をカバーしているライブラリよりも、必要な機能だけを持っているミニマムなライブラリを組み合わせて使う風潮があると感じます。
“お祭りムード”が加速したDroidKaigi公式アプリの開発
──さて小西さんが関わったOSSではDroidKaigi 2016の公式アプリも知られています。そもそも、なぜ、このアプリを作ることになったのでしょうか。
小西 DroidKaigi 2016に登壇者として参加しているんです。発表テーマは多言語対応だったんですが、ニッチな内容なので普通に発表したら地味な印象になってしまいます。サンプルアプリがあればだいぶマシですが、用意しても事前にダウンロードしてくれる人はほとんどいないでしょう。
どんなアプリならダウンロードしてもらえるかを考えた末に「DroidKaigiのカンファレンスアプリを作れば、興味を持ってもらえるんじゃないか」という結論に至り、作りはじめたんです。
その後、DroidKaigi実行委員会の代表である日高正博（ 
──なるほど。 DroidKaigi 2016公式アプリは開発期間が短かったにもかかわらず、184個のPull Requestという、かなりの数のコントリビューションが生まれました。これほど多くの方々が参加してくれたのは、どうしてでしょうか？
小西 いくつか理由があると思います。まずは、DroidKaigi実行委員会の方々が効果的にアナウンスしてくれて、お祭りのような状態が生まれていること。これは2017年、2018年、そして2019年のDroidKaigiでも継続できています。2018年からはtakahirom（ 
DroidKaigi公式アプリのリポジトリが公開されると、各コントリビューターがその年で一番いいライブラリの組み合わせやソースコードの書き方の知見を持ち寄り、さらにいいアプリになるようにブラッシュアップしていきます。いわば、そのソースコードをショーケースにして、Androidアプリ開発の最新知識を学べる場が作られているわけです。
それからブログの記事にも書いたんですが、DroidKaigi 2016ではコントリビューションしやすくするための工夫がいくつか試みられていました。それらがうまく機能したのも大きいです。
──どんな工夫があったのですか？
小西 まず、hotchemi（ 
welcomecontributorという緑色のラベルを作っていたんですが、これがとても効果的でした。コントリビューションしたいけれど何をしたらいいかわからない人にとって、「緑色のラベルがついたものから着手すればいい」というのは非常にわかりやすかったと思います。
リポジトリ「droidkaigi2016」のIssueにはこのように「welcomecontributor」のラベルが多数並ぶ。
Issueの粒度もできる限り細かくしました。1つひとつのIssueをすぐに完了できるくらいの簡単なものにしておいたんです。粒の細かいタスクをザクザク片づけていくことで、勢いが生まれます。夜のうちに10個くらいIssueを作っておいたら、翌朝にはもう無くなっている、ということもありました。
それから、なるべくコメントには即レスして「常に見ている感」を出していました。深夜3時くらいまでずっと起きて、ひたすらレスを返し続けていましたね。いま思えば、「当時はなぜこんな時間まで起きていられたんだろう」という感じはありますが（笑）。
──DroidKaigiのお祭り感は、数々の細かい工夫に支えられていたんですね。
たとえクソコードでも、まずは公開してみる
──エンジニアがOSS開発に取り組むことには、どんなメリットがあるでしょうか？
小西 まず、自分のスキルアップにつながることです。特に、Pull Requestを通じて自分が知らなかった領域についての知見を得られるのは、OSS開発の持つ大きな利点だと思います。
例えば、android-material-design-icon-generator-pluginでは、もともとアイコンの色を変える機能が無く、デフォルトで用意された黒・灰色・白のアイコンだけを提供していました。でも、ある方が色をつける機能を実装してPull Requestを送ってくれたんです。
ソースコードを読んでみると、ビットマップにした画像データを1ピクセルずつループし、色変換して配置し直すという手法を用いていました。「なるほど。こういう実装をすればいいのか」と勉強になりましたね。
それから、Pull RequestやIssueを発行してもらえるというのは、それ自体がライブラリ制作者にとっては本当に嬉しいものです。貴重な時間を割いてソースコードを読み、修正案まで考えてくれているわけですから。
小西さんを刺激したPull Request。
──コントリビューターとしての一歩を踏み出すには、まず何から始めるといいでしょうか？
小西 僕が以前、DroidKaigi 2015にオーディエンスとして参加した際に、印象に残ったフレーズがあって。ピースオブケイクの岡野忍（ 
「こんなソースコードを公開したら恥ずかしい」とか「マサカリを投げられるんじゃないか」と考える方もいるでしょう。でも、僕はこれまでコードを公開して怒られたことや怖い思いをしたことはありません。
怖がらずに、公開する前提でソースコードを書いてみてください。公開して反応が来たら楽しいですし、そのソースコードを読んだ誰かが、次の新しい何かを生み出してくれるかもしれませんから。
取材・執筆：中薗昴
