iOSに向き合い続けた10年。岸川克己がSpreadsheetViewで埋めたかった「iOSに不足していたもの」
KeychainAccessやSpreadsheetViewなど、iOSアプリ開発で広く使用されるOSSを送り出した岸川克己さん。iOS、Swiftの世界で先駆けと評される岸川さんに、ソフトウェア開発の裏側をお聞きしました。
職業、iOSアプリ開発者。いまでこそ、こうした肩書は珍しくありませんが、10年以上前から、iOSに向き合い続けてきたエンジニアがいます。今回の主人公である岸川克己（きしかわ・かつみ／ 
2008年9月、日本でiPhoneが発売されるやすぐにアプリを送り出し、以降、岸川さんはiOSアプリを開発し続けてきました。エンジニアとしての高いスキルが評価され、これまで数多くの有名企業のテクニカルアドバイザーを歴任し、現在は、株式会社FOLIOでコア開発者を務めています。
OSS開発も精力的に行っており、Swiftで書かれたKeychainのラッパーKeychainAccessや、表計算ソフトのような複雑なグリッド表示を実現できるSpreadsheetViewなど、いくつもの有名ツールを世に送り出してきました。
過去から現在にいたるまで、岸川さんはどのような手段で自らのスキルを高め続けてきたのでしょうか。
- Appleが公開していないAPIを、発見して使っていた
- 制作したアプリが、App Storeのダウンロードランキング1位に
- Swiftの特性をフルに生かし、KeychainAccessが生まれた
- 他の良質なライブラリから、優れた設計を学ぶ
- 読んで、書いて、公開すべし
Appleが公開していないAPIを、発見して使っていた
──岸川さんは、日本人のなかではかなり早い段階からiOSアプリ開発に携わっていたと聞きました。
岸川 そうですね。私がiOSアプリを開発し始めたのは、日本でiPhoneが発売されたばかりの頃からでした。当時はApple Developer Programがすでに始まっていたので「せっかくiPhoneを手に入れたから、何かアプリを作ってみよう」と考えたんです。
これに関しては裏話があって。当時はApple Developer ProgramにPending Contract問題と呼ばれる不具合があり、名前に漢字が含まれているとAppleの契約処理がストップしてしまうケースがあったんですよ。デベロッパーの登録名が文字化けしてしまって、オペレーターに手作業で修正してもらわないと登録が完了しなかったんです。
岸川克己さん：大学卒業後、SIerに入社しプログラミングを学ぶ。その後、国内外の企業でエンジニア、また技術アドバイザーとしてコミットする。2018年4月より現職。自身のブログ『24/7 twenty-four seven』やカンファレンス登壇など、iOS、Swiftに関するアウトプット活動にも精力的に取り組んでいる。
──そんな時代があったんですね！ 今では想像もつかないです。
岸川 でも、私はなぜか運よくそれに引っかからずに審査がスッと通ったんです。どうしてなのかは今でも謎なんですけど（笑）。それがきっかけになり、他の開発者の方々から「Pending Contract問題で困っているんだけど、どうやって解決したんですか？」と連絡をもらうようになりました。「いや、理由はよく分からなくて」と回答をしているうちに、その方々と交流ができたんです。
当時はまだ今と違って、開発に関することをネット上に自由に書いてはいけないという規約がありました。そこで「実際に会ってみようか」ということになり、彼らと内輪で5～6人くらいで集まって勉強会をするようになったんです。
──勉強会では何を学んでいたんですか？
岸川 いろいろやりましたが、例えば、まだ公開されていないAPIをみんなで発見して使ってみる、みたいなことをやっていました。
──発見……というと、どうやって？ 当然、そのAPIはAppleの公式ドキュメントなどに載っていないですよね。
岸川 確かに載っていないんですが、いくつかのテクニックを駆使すると、まだ公開されていないAPIを調べることができたんです。
Objective-Cはメソッド名などが最終的に全て動的に解決されるという特性があります。だから、開発者に対してメソッド名を隠蔽できないんです。適当なプログラムを書いて実行しながら、どんなものが隠されているかを調べていました。
出てきたメソッド名をもとに「これ、こういう挙動をするんじゃないかな」と推測して、実際に使ってみて。あとはトライアル&エラーで「こういうパラメータを渡すとこんな結果になった」というのをひたすらくり返しながら、処理内容を解析していったんです。
──そんな方法があったとは。まさにギークの楽しみ方ですね。
岸川 今はもう、隠しAPIの解析みたいなことはほとんどできなくなっているんですけどね。当時はそういうことをやっているのが本当に楽しかったです。
制作したアプリが、App Storeのダウンロードランキング1位に
──最初に作って公開したiOSアプリは何でしたか？
岸川 「はてな touch1」というアプリでした。なぜこれを最初に作ったかというと、私は昔からはてなユーザーだったからです。それに、はてながAPIを公開してくれていたから、作りやすかったという理由もあります。
岸川さんのブログにはいまもはてな touchリリース時の記録が残されている。
──当時、iOSアプリ開発者向けの技術書はあったんですか？
岸川 いや、なかったです。だから代わりに、『MAC OS X COCOAプログラミング』という本を読んで、Objective-CやXcodeについての情報をインプットしていました。それで、なんとか開発できるようになったんです。Appleの統合開発環境であるXcodeって、その頃から完成度が高くて、初学者でも試行錯誤しながら学びやすかったですね。
MAC OS X COCOAプログラミング 第4版 - 東京電機大学出版局 科学技術と教育を出版からサポートする
『MAC OS X COCOAプログラミング』は現在は第4版を数えるロングセラーだ。
岸川 その後、3つくらいアプリをリリースしてから、あるデザイナーの方から「アプリを作ってくれないか」という受託開発の依頼がありました。「アイデアはあるんだけど、自分はデザイナーだからプログラミングができないので手伝ってほしい」と。
その仕事を請けて最初に作ったのは、iPhone上に時刻とカレンダーを表示させて、卓上時計のように使えるアプリ「LCD Clock」でした。確かにデザインはすごく綺麗だったんですけど、「iPhoneって基本的に持ち歩いて使うものだから、あまり多くの人には使われないんじゃないかなあ」と思っていたら、なんとApp Storeのダウンロードランキングで1位になったんです。びっくりしましたね。
岸川さんが受託制作したというLCD Clockは、時刻とカレンダーがデジタル時計のように表示されるアプリだ。シンプルで洗練されたデザインが人気を博し、多くの愛用者を生んだ。
──すごい功績じゃないですか！
岸川 LCD Clockのヒットでデザイナーの方も本腰を入れ始めたんだと思うんですけど（笑）。その形態でしばらく一緒に仕事をしました。2年くらいはやっていたと思います。それまで、本業は別の開発をしつつ趣味としてiOSアプリ開発をやっていたんですが、本業として好きなiOSアプリ開発に携われるようになって。楽しかったですね。
Swiftの特性をフルに生かし、KeychainAccessが生まれた
──岸川さんは、OSS開発にも長年携わっています。新しいツールの開発に着手する際には、どのようなアイデアをもとに実装がスタートするのですか？
岸川 例えばKeychainAccessは、Swiftを勉強するために開発したものです。もともとObjective-Cで書かれたほぼ同じ役割のアプリがありました。それのSwift版を作ろうと思ったんですね。
せっかく勉強用に作るので、できるだけSwift特有の機能を使って、Objective-C版よりも便利なものを作るというコンセプトで開発がスタートしました。結構悩みながら、何回もコードを書き直しながら実装していきました。
──KeychainAccessでは、どんな箇所がObjective-C時代と変わっているのでしょうか？
岸川 KeychainのAPIって、用意されているメソッドは非常に少なくて、呼び出しと保存と削除の機能があるくらいなんですよ。でも、挙動の全てをパラメータで制御するので、渡すパラメータの種類がめちゃくちゃ複雑なんです。だから、良いラッパーを作るためには「パラメータをどう扱うか」が重要になってきます。Swift版では、複数のパラメータをメソッドチェーンで連結させるような形で利用できるようにしました。
──Objective-Cでは、メソッドチェーンによるパラメータの受け渡しは難しいのですか？
岸川 Objective-Cは言語仕様上、メソッドチェーンを書こうとするとコードが冗長になってしまい、可読性が低くなりIDEの補完機能とも相性が悪くなってしまいます。ですが、Swiftはメソッドチェーンがシンプルに記述できるので、「これならばパラメータの設定を綺麗に書ける」と思って、記法を整備しました。
let keychain = Keychain(server: "https://github.com", protocolType: .https)
do {
try keychain
.label("github.com (kishikawakatsumi)")
.comment("github access token")
.set("01234567-89ab-cdef-0123-456789abcdef", key: "kishikawakatsumi")
} catch let error {
print("error: \(error)")
}
KeychainAccessのREADMEより抜粋。極めて可読性の高い記法で、パラメータの受け渡しが実現されている。
結果的に多くの方に使っていただけるライブラリになったので、「自分の設計は間違っていなかったんだな」と自信につながりましたね。
──他に、KeychainAccessの設計において気をつけたことはありますか？
岸川 KeychainAccessに限らず、「利用者にとって親切な設計になっているか」はツールを作る上では常に注意しています。例えば「どんな種類のパラメータを渡す必要があるか」をより分かりやすくするため、候補パラメータをenum（列挙型）として定義しておき、IDEの補完を見れば何を渡すべきかが読み取れるようにしました。
また、旧バージョンのXcodeでは、複数の引数を持ったメソッドがあり、いくつかにデフォルト値が設定されている場合、引数が最も多くなるケースだけが補完の候補に出ていました2。それが嫌だったので、引数が少ない同名メソッドをあえて定義しておき、IDEの補完に各メソッドが表示されるような作りにしていましたね。
──「どんな情報があれば開発者の助けになるのか」を徹底的に考えているんですね。
岸川 そうですね。人が間違えにくい設計にするというのは、システム開発全般において非常に大切なことだと思っています。
他の良質なライブラリから、優れた設計を学ぶ
──岸川さんの作ったOSSのなかではSpreadsheetViewの人気も非常に高いです。このライブラリはどういったアイデアから生まれたのでしょうか？
岸川 iOSのコンポーネントの中には明確に不足している機能がいくつかあって、そのひとつがSpreadsheetViewのような複雑なグリッド表示を実現できるライブラリでした。
SpreadsheetViewはこうしたグリッド表示を簡潔に実装できるライブラリだ。
岸川 CollectionViewでも似たようなことはできますが、縦横の複雑なグリッドの概念があるViewというのは、なかなか実現が難しいです。そういったViewを作るのは大変なので、実務においては「シンプルな縦だけのカラムにしましょう」とか「横はそろわないけれど縦のカラムとスワイプだけにしましょう」という方向で処理することが多いです。
しかし、それだと他のアプリのUIとの差別化が難しいですし、パフォーマンスも出ません。その課題を解決したくて、SpreadsheetViewを作りました。
──制作する上で苦労した部分はありますか？
岸川 とにかくパフォーマンスを向上させることが大変でした。ライブラリのコンセプトは明確でしたしAPIのデザインなどもCollectionViewを踏襲すればよかったので、プロトタイプを作るところまではすぐにできました。でも、データ量を増やすと全然動かなくなってしまうんです。そこからは、ひたすらにパフォーマンスチューニングのくり返しでした。
──どのようなアプローチでチューニングを行ったのでしょうか？
岸川 パフォーマンスチューニングは基本的に、マシンの状態を計測してボトルネックを見つけ、それを丁寧に潰していくという地道な作業です。iOSの場合は、ひとつの画面に乗るViewの数と画面の大きさがボトルネックになることは経験的に分かっていたので、今回もそこが問題になることは推測できました。その課題をいかに解消するかがカギだったんです。
具体的には、TableViewやCollectionViewといった既存のライブラリは「表示される部分だけを描画して他は描画しない。かつViewを再利用する」という設計にすることでパフォーマンスを稼いでいるので、この方法を踏襲していきました。
その過程は結構面白かったです。「なるほど、TableViewやCollectionViewのデザインは本当に良くできているんだな」と実感できました。
──そうすることで、他のライブラリの設計意図を学ぶことができたんですね。このケース以外にも、一般に公開されているライブラリやツールのソースコードを見て、設計について学習することは多いですか？
岸川 かなり多いですね。コードを書くだけではなく読むのも、設計のスキルを高めるには必要だと思います。
──今まで見てきたなかで、「これは本当に参考になった」と思うものはありますか？
岸川 例えば、ニック・ロックウッドという方のコードは本当に綺麗で良くできているので、一時期はこの人の書いたコードをひたすら読んでいました。
あとは有名なエンジニアでマット・トンプソンという方がいるんですが、彼は便利なライブラリを数多く作っていますし、設計のレベルも高いです。ネーミングも上手で、全ての面において参考になります。
例えば、数学の演算子記号をそのままコード内で使えるようにできるライブラリにEuler3という名前を付けるとか、StoreKitのラッパーライブラリにCargoBay4という名前を付けるとか。本当にセンスがあるなと思いますね。
読んで、書いて、公開すべし
──この記事を読んで、「自分自身もiOSアプリを作りたい。OSSに携わってみたい」と考える読者もいると思います。その方々に対してアドバイスをするなら、何と伝えますか？
岸川 まずは、自分の作りたいものを自由に作ればいいと思います。「何を作るか」に正解なんてないですから。
「自分の作ったものを多くの人に使ってもらいたい」という気持ちが強いのであれば、世の中にある良質なツールやライブラリを研究してみてください。コードを読み込んでいくことで、「こういう設計になっているのはこんな理由だったんだ」とか「こう書けば使いやすいものになるんだ」と、見えてくるものがあるはずです。
それから、自主的に何かを作っている人、そのソースコードを公開している人は想像以上に少ないものです。ですから、ソースコードを公開する、という行為自体が本当に価値のあることだと私は思っています。
公開しておけば、そのアウトプットは世の中にいる誰かの役に立つかもしれません。「ちゃんとしたものでなければ、公開するのは恥ずかしい」と考える必要は全くないです。私自身も、誰かが公開してくれていたソフトウェアやソースコード、ドキュメントのおかげで、これまで何度も助けられてきましたから。
──とにかくアウトプットを世に出していくことが大事なのですね。
岸川 そうですね。とにかく読むこと、書くこと、そして公開することを継続していくべきだと思います。
幸いにも、ソフトウェアエンジニアリングの領域はアウトプットの良し悪しが客観的に分かるので、公開した後に誰かがしてくれるフィードバックが有効に機能します。それが自分自身の成長にもつながるので、とにかく恐れずに、作ったものを世に出していくといいと思います。
取材・執筆：中薗昴
