iOSに向き合い続けた10年。岸川克己がSpreadsheetViewで埋めたかった「iOSに不足していたもの」

KeychainAccessやSpreadsheetViewなど、iOSアプリ開発で広く使用されるOSSを送り出した岸川克己さん。iOS、Swiftの世界で先駆けと評される岸川さんに、ソフトウェア開発の裏側をお聞きしました。

iOSに向き合い続けた10年。岸川克己がSpreadsheetViewで埋めたかった「iOSに不足していたもの」

職業、iOSアプリ開発者。いまでこそ、こうした肩書は珍しくありませんが、10年以上前から、iOSに向き合い続けてきたエンジニアがいます。今回の主人公である岸川克己(きしかわ・かつみ/ 1@k_katsumiさんは、まさに“iOSの第一人者”と呼ぶにふさわしい人物です。

2008年9月、日本でiPhoneが発売されるやすぐにアプリを送り出し、以降、岸川さんはiOSアプリを開発し続けてきました。エンジニアとしての高いスキルが評価され、これまで数多くの有名企業のテクニカルアドバイザーを歴任し、現在は、株式会社FOLIOでコア開発者を務めています。

OSS開発も精力的に行っており、Swiftで書かれたKeychainのラッパーKeychainAccessや、表計算ソフトのような複雑なグリッド表示を実現できるSpreadsheetViewなど、いくつもの有名ツールを世に送り出してきました。

過去から現在にいたるまで、岸川さんはどのような手段で自らのスキルを高め続けてきたのでしょうか。

Appleが公開していないAPIを、発見して使っていた

──岸川さんは、日本人のなかではかなり早い段階からiOSアプリ開発に携わっていたと聞きました。

岸川 そうですね。私がiOSアプリを開発し始めたのは、日本でiPhoneが発売されたばかりの頃からでした。当時はApple Developer Programがすでに始まっていたので「せっかくiPhoneを手に入れたから、何かアプリを作ってみよう」と考えたんです。

これに関しては裏話があって。当時はApple Developer ProgramにPending Contract問題と呼ばれる不具合があり、名前に漢字が含まれているとAppleの契約処理がストップしてしまうケースがあったんですよ。デベロッパーの登録名が文字化けしてしまって、オペレーターに手作業で修正してもらわないと登録が完了しなかったんです。

2

岸川克己さん:大学卒業後、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位になったんです。びっくりしましたね。

4

岸川さんが受託制作したという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の補完に各メソッドが表示されるような作りにしていましたね。

──「どんな情報があれば開発者の助けになるのか」を徹底的に考えているんですね。

岸川 そうですね。人が間違えにくい設計にするというのは、システム開発全般において非常に大切なことだと思っています。

他の良質なライブラリから、優れた設計を学ぶ

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