オープンソースライセンスの管理を楽にする -Android アプリ編

2020年01月現在の近況については下記のエントリを参照してください

techlife.cookpad.com


こんにちは、投稿推進部の吉田です。
オープンソースライセンスの管理はアプリ開発における悩み事の一つですよね。今回はこの煩雑な作業をgradleプラグインを使って自動化する話をします。 本稿におけるライセンスの管理とは、OSSライブラリの著作権者とライセンス文の管理に限定されることを予めご了承下さい。

紹介するgradleプラグイン

license-tools-pluginが提供する機能

  • yamlを使ったオープンソースライセンスの管理
  • ライセンス追記漏れのチェック
  • ライセンス一覧のhtmlの作成

license-tools-pluginの利用方法

複雑な設定は必要なく、3ステップでライセンス一覧を管理することが出来ます。

  1. プロジェクトにlicense-tools-pluginプラグインを導入する
  2. build.gradleから依存ライブラリ情報を抜き出してyamlファイルを作成
  3. yamlからライセンス一覧のhtml作成

導入後はPull Request毎にCIでyamlファイルが適切な状態かチェックすると良さそうですね。

1.プラグインの導入

build.gradleに以下の内容を記述します。

apply plugin: 'com.cookpad.android.licensetools'

buildscript {
  repositories {
    jcenter()
  }
  dependencies {
    // 2016-04-28時点の最新バージョンは0.12ですが、最新のものを利用して下さい
    classpath 'com.cookpad.android.licensetools:license-tools-plugin:0.12.0'
  }
}

license-tools-pluginはgradle ver.2.10以上を要求するので、古いバージョンを利用している場合は、gradle/wrapper/gradle-wrapper.propertiesのdistributionUrlを更新します。

distributionUrl=https\://services.gradle.org/distributions/gradle-2.10-all.zip

導入手順は以上です。

2.yamlファイルの作成

license-tools-pluginにはyamlファイルを生成するためのコマンドはありません。 代わりにcheckLicensesタスクを実行することで既存のyamlファイルとの差分を出力出来ます。 初回利用時はcheckLicensesタスクが全てのライセンス情報をyaml形式でコンソールに出力するので、 app/licenses.ymlというファイルを作成して出力内容をコピペします。

- artifact: com.squareup.okhttp:okhttp:+
  name: OkHttp
  copyrightHolder: #COPYRIGHT_HOLDER#
  license: #LICENSE#
- artifact: com.squareup.okio:okio:+
  name: Okio
  copyrightHolder: #COPYRIGHT_HOLDER#
  license: #LICENSE#

出力されたyamlでは、情報を取得できない部分がプレースホルダになるので適宜修正して下さい。上記のyamlの場合は#COPYRIGHT_HOLDER##LICENSE#の部分を調べて手作業で修正する事になります。
ここまでの作業が完了したら、もう一度checkLicensesを実行しましょう。先程は失敗したタスクが正常に終了するようになるはずです。 また社内ライブラリやGoole Play Servicesなど一覧に表示する必要のないライセンス情報はskip: trueで一覧から除外することが出来ます。

- artifact: com.google.android.gms:play-services-basement:+
  name: play-services-basement
  skip: true  

3.ライセンス一覧の作成

ライセンスの表示方法はいくつか考えられます。例えばyamlを直接読みListViewなどのネイティブUIで表示する事も可能です。 この場合、license-tools-pluginはUIパーツの提供はしていないので、他のライブラリを利用するか自分で実装することになります。
UIパーツを提供しない代わりにgenerateLicensePageというタスクが用意されていて、yamlからフォーマットされたhtmlを作成する事が可能です。 一例としてgenerateLicensePageで生成したhtmlとwebviewを利用したサンプルコードを貼りました。下のスクリーンショットのようなスタイルのhtmlが表示されていれば成功です。

@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstancestate);
  setContentView(R.layout.activity_main);
  WebView webview = findViewById(R.id.web_view);
  webView.loadUrl("file:///android_asset/licenses.html");
}

おわりに

license-tools-pluginはまだリリースされたばかりで機能はそれほど多くないですが、ライブラリのライセンス管理を劇的に楽にすることが出来ます。 Cookpadではこのようなチョットしたものでもライブラリ化して公開するようにしています。Githubのレポジトリ上でIssueやPull Requestをいつでもお待ちしているので気軽に意見をお聞かせ下さい。

どのようにして高速に iOS アプリの UI を作り上げるか:動作モックの活用と実装時の UI 作りこみ

Holiday デザイナーの多田です。

皆さんは Web アプリやモバイルアプリを開発する時、モックアップ作成にどれだけ時間を割いているでしょうか?もしくはモックアップを作成せずにすぐに実装に入るでしょうか?私はこれまで Web アプリ開発ではいきなり実装に入ることが多かったのですが、Holiday iOS アプリ の開発では Web アプリの時のように上手くいかないことに気づき、やり方を考え直しました。iOS アプリ開発の過程で、モックアップ作成や実装をどのように捉えるか、具体的にどう行うか、ということが自分なりに見えてきたので、それらについてご紹介します。

目的は、価値のあるプロダクトを速くユーザの手に届けること

Web アプリやモバイルアプリの開発過程においてモックアップなどを作る目的は、あくまでも ユーザに届く プロダクトの価値を高めてそれを速くリリースすることです。適切な前準備は、やろうとしていることが価値があるのかどうか、またその価値が伝わるのかどうか、ということに実装前の早い段階で気づくことができるというメリットがあります。重要なことは、 モックアップや実際のプロダクトなどを作ることによって確かめられる仮説検証の精度と、それを作る時間はトレードオフの関係にある ということです。そのため、モックアップなどを作る際には、本当に作るべきなのか、もしくはどこまで作りこむのかということを意識する必要があります。

Web アプリとモバイルアプリの実装コストの違い

Web アプリとモバイルアプリの開発をどちらもやっていて気づいたことは、ほとんどの場合、モバイルアプリは Web アプリよりも UI の実装や調整に時間がかかるということです。主な理由としては、モバイルアプリが下記のような特性を持つからだと考えられます。

  • コード記述量が多くなったり、UI 絡みでクラッシュしやすい
  • ビルドに時間がかかる
  • ユーザが UI に求める期待値が高いので、最初からある程度作りこむ必要がある
    • リッチなインタラクション
    • スムーズな動作

実装コストが高いということは、それだけ失敗した時のダメージが大きいということになるため、かける時間と得られるもののバランスが取れている(いわゆるコストパフォーマンスの良い)方法がないか考えたほうがよさそうです。よく用いられる方法として、

  • スケッチ&ペーパーモック
  • 静止モック(Sketch など)
  • 動作モック(Flinto for Mac, Framer, InVision など)
  • 実装

というものが挙げられます。これらによって得られる検証精度と作成にかかる時間の関係は以下のようなイメージです。

f:id:tdksk:20160420192614p:plain

上の図のように、Web アプリと比べモバイルアプリは実装に時間がかかるため、 動作モックを活用する ことと 実装時に UI の作りこみをしやすくする ことを特に意識しています。これらについて、具体的にどのようなことを行っているのか説明します。

動作モックを活用する

f:id:tdksk:20160421003428p:plain

先述のとおり、モバイルアプリは実装フェーズで一気にコストが上がるため、途中の穴を埋めることには価値があると考えられます。最近では例えば以下のように様々なプロトタイピングツールが登場しています*1

プロトタイプの精度と作成にかかる時間のバランスを考えた時、個人的に一番しっくりきて活用しているのが Flinto for Mac です。作成可能なプロトタイプの幅が多く、かつプロトタイプを作るエディタが非常に使いやすいため、多くの場合で十分な精度のプロトタイプを素早く作ることができます。

Holiday iOS アプリの開発では、作る機能ごとに必要に応じて Sketch で画面を作り、その画面のパーツを使って Flinto for Mac でプロトタイプを作成しています。実装前にリアルなインタラクションを気軽に何パターンも試すことができるため、頭の中のイメージやラフスケッチから実装に入ったり、Sketch でモックを作成したあとすぐに実装に入るよりも手戻りが少なくなり、結果としてかかる合計の時間が短くなる場合が多いです。

f:id:tdksk:20160420192642g:plain

実装時に UI の作りこみをしやすくする

モバイルアプリはビルドに時間がかかるため、実装時に UI の作りこみをしにくいと感じることが多いです。逆に言えば、実装時に UI の作りこみがしやすければ、モック時点で作りこむ必要が薄れるため、Web アプリのように早い段階で実装に入って時間を削減できる可能性があります。

f:id:tdksk:20160420192633p:plain

Holiday iOS アプリでは、Tweaks というライブラリを使うことによって UI のパラメータをビルド後のアプリ上で動的に変更しています。このライブラリを使うと、以下のように動的に変更したいパラメータの箇所を一行変えるだけで、アプリ上でパラメータ設定画面(振ると出てくる設定画面を最初に数行書いておくだけで作ることができる)から値を変更できるようになります。

NSUInteger width = FBTweakValue(@"Activity", @"Spot", @"Width", 240);

f:id:tdksk:20160420192747g:plain

このライブラリは他にも以下のような機能を備えており、実用性が高いです。

  • 数値だけでなく、文字列や BOOL 値、また色などもアプリ上で設定可能
  • 数値の下限と上限を設定することが可能
  • マクロを使っていてリリースビルドではデフォルト値を展開するだけなので、パフォーマンス上問題にならない
  • 値が変更されたら自動で更新するビュー(オブジェクト)を設定することができる
  • 値の設定画面上でリストが選択された時に実行するブロックを加えることができる
  • 設定画面の呼び出しを手動で定義することもできる

ただし、先述のコードは Objective-C でマクロを使っているため、Swift ではそのままでは同じように一行で書くことができません。Swift の場合は Facebook Tweaks with Swift Tutorial の記事に書いてある方法でヘルパーメソッドを作ると、Objective-C での場合と似たように一行で記述することができます。

まとめ

今回は、iOS アプリ開発において UI を素早く作り上げるために Web アプリとは異なるやり方、具体的には動作モックの活用と実装時の UI 作りこみをやりやすくする方法を紹介しました。紹介したようなプロトタイピングツールやライブラリ等を用いることによって、iOS アプリ開発全体のワークフローを効率化できると実感しています。実際にリリースされている iOS アプリが気になった方は、こちら よりダウンロードしてぜひ触ってみてください。

オープンソースソフトウェアポリシーをつくろう

こんにちは、みんなのウェディング 高井です。

みんなのウェディングやクックパッドといったインターネットサービス企業では、オープンソースソフトウェアは欠かすことのできない存在です。LinuxやMySQL、Ruby、Railsといった主要なものをはじめとして、テクノロジースタックのほとんどがオープンソースソフトウェアによって構成されいるといっても過言ではありません。

ですから、企業としてどのようにオープンソースソフトウェアに向きあうかということが、とても重要な問題になります。そして、そのための指針が、オープンソースソフトウェアポリシーです。

今回は、クックパッドがどのようにオープンソースソフトウェアポリシーをつくったか、その背景も含めてをご紹介いたします。

クックパッドとオープンソース

今でこそクックパッドは、多くのオープンソースソフトウェアを公開したり、その開発に貢献したりする会社となっています。しかし、私が入社した5年前には、会社として公開しているオープンソースはひとつもありませんでした。入社したばかりのときに「ちょっとしたライブラリをオープンソースとして公開したい」と当時のCTOである橋本に相談したときに、なぜそのようなことをするのか説明を求められて驚いた記憶があります。個人の活動としてオープンソースを公開している社員はいたのですが、企業の活動としてオープンソースソフトウェアに取り組む文化はありませんでした。

そこで、私はオープンソースソフトウェアポリシーの素案をつくり、会社に提案をしました。その素案はいくつかのフィードバックをもとに修正されたのち、正式に承認されたものになっています。

また、みんなのウェディングで仕事をするようになって、まず最初にやったのがオープンソースソフトウェアポリシーを策定することでした。その結果、みんなのウェディングでもオープンソースソフトウェアを公開したり、その活動をブログで紹介したりする成果につながっています。

なぜオープンソースソフトウェアが重要か

そもそも、なぜ企業としてオープンソースソフトウェアにコミットしなければならないのでしょうか。

第一に、私たちのようなインターネットサービス企業ではその技術基盤の大部分をオープンソースに依存しているという現実があります。かつて、企業の技術基盤は、大手ベンダーが開発するプロプライエタリ・ソフトウェアが中心となっていました。ごく初期のインターネット企業にとって、サン・マイクロシステムズのSolarisやオラクルのOracle Databaseは間違いのない選択肢でした。また、初期のクックパッドが、ColdFusionで開発されていたというのは有名な話です。そのような時代には、企業はベンダーのロードマップに従っていれば何の問題もありませんでした。

ところが、その状況が変化していきます。エリック・レイモンドが「伽藍とバザール」で示したようなバザール式の開発モデルが一般的となり、それが優れたモデルとして受け入れられていきました。バザールプロジェクトでは、その開発に誰もが自由に参加することができます。だからこそ、自分たちが利用しているプロダクトの継続的な進化や発展のために、そのプロジェクトにコミットしてくことが重要になってきたのです。

第二に、人材採用面でのメリットです。オープンソースプロジェクトには、技術力の高いエンジニアが多く参加しています。会社がオープンソースコミュニティの一員になることでそうした人材を獲得するチャンスが増えます。

また、それが企業内にオープンソースプロジェクトでデファクト・スタンダードになっている開発スタイルを取り入れ、健全な開発者文化をつくり上げる基礎となります。オープンでフラットな意思決定、具体性がない議論よりも動くコード、そういったものをエンジニアは好みます。

職務著作とオープンソース

企業にオープンソースソフトウェアへのコミットメントをしていくとしたら、整理しなければならないことのひとつに、著作権があります。著作権法では、仕事で作成するプログラムについて、次のように定められています。

第十五条

2  法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする。

つまり、仕事でプログラムを作成したときには、原則として著作権は会社に所属することになります。もし、あるエンジニアが会社で利用しているオープンソースソフトウェアにバグを発見して、就業時間中にその修正パッチを作成したとします。そのパッチの著作権は会社に所属することになりますので、そのエンジニアの判断で勝手に公開してしまうと、著作権上問題のある行為となってしまいます。

ですから、企業としてオープンソースソフトウェアへの貢献していくためには、著作権の扱いをどうするか整理をする必要があります。そのための仕組みがオープンソースソフトウェアポリシーです。

オープンソースソフトウェアポリシーがなくても、暗黙的にうまくやっているという会社もあるでしょう。しかし、著作権の問題を考えるとあまり良いやり方であるとは思えません。オープンソースソフトウェアポリシーは、そこで働く開発者の行動を制限するものではなく、守るためのものです。

オープンソースソフトウェアポリシーのつくり方

では、オープンソースソフトウェアポリシーをつくりたいときに、どのようにすればいいでしょうか。

クックパッドのオープンソースソフトウェアポリシーは、一般社団法人情報サービス産業協会(JISA)がまとめた「オープンソースビジネスに取り組むSI企業のための企業ポリシー策定ガイドライン」を参考につくられました。「SI企業のための」となっていますが、オープンソースソフトウェアポリシーを策定するにあたって検討すべき項目が網羅されていますので、たいへん参考になります。

そのうえで、自分たちの実現したいことをきちんと議論し、その議論を反映させたものにすることも大切です。テンプレートのようなものがあったとしても、それを持ってくるだけでは自分たちの会社の理念に沿ったものにはなりません。ポリシーなのですから、それを自分たちの言葉で説明できなくては、価値あるものとして機能しないでしょう。

まとめ

クックパッドでは、ポリシーを定めることで、従業員が自由にオープンソースソフトウェアに貢献することのできる土壌をつくっています。また、そのことが優秀な人材を獲得し、健全な開発者文化を醸成することに貢献してきました。

最後に宣伝となりますが、みんなのウェディングはソフトウェアエンジニアを募集中です。「みんなの『大切な日』をふやす」を経営理念にユーザーファーストなサービスづくりを徹底的にやっていきたいと考えている会社です。ご興味のある方は、 株式会社みんなのウェディング採用情報からご応募ください。また、みんなのウェディングのブログもあります。こちらではエンジニアリングに関する話題をあつかっていますので、あわせてご覧ください。