【レポート】総数500タイトル以上のヒットアプリを生み出した企業在籍のエンジニアが語る！最新のアプリ開発事情！

AIアプリ開発のはじめ方

続いて4人目は洪さんの登壇です。

洪小川（こう・しょうせん）／株式会社ブレイブソフト ドリーム事業部 チーフエンジニア。中国四川省出身。2012年にブレイブソフトへ入社し、現在は来日6年目。初音ミクが好き。

洪さんは、AI開発にまつわる悩み事に関して、自身の経験を交えて紹介します。まずは、言語の選択について。

・言語

「AIの開発には『Python』がよく使われています。AI研究の78％、数学・データの領域の55％に『Python』が使われているという調査もあります。その他に『Cython』『R』『C++』などの言語もありますが、数字をみると『Python』がひとつめの選択肢になると思います」（洪さん）

続いてはフレームワークについてです。iOSアプリの開発を担当した洪さんは、Appleが提供する機械学習フレームワーク「CoreML」をサポートする3つのフレームワークを紹介します。

・TensorFlow

「『TensorFlow』は、とても流行しているのでみなさんご存じだと思います。流行っているので、ドキュメントも一番充実していますね。 特徴としてはGPUとCPUの切り替えが簡単に行える点が挙げられます。ライセンスは『Apache License 2.0』となっていて、商用利用も問題ありません」（洪さん）

・Keras

「『Keras』では『Python』は2.7〜3.6をサポートしています。CPUとGPUの切り替えもできますね。拡張性が高いのが特徴で、『TensorFlow』など他のフレームワークと組み合わせて使うこともできるんです。

また、機能がモジュール化されているので、複雑なネットワークを簡単に構築できる点もポイントです。ライセンスは『MIT』なので商用利用も問題ありません」（洪さん）

・scikit-leran

「『scikit-leran」は、CPUだけをサポートしています。ただ、アルゴリズムの提供がとても充実しているので、簡単にAI開発を始めてみたい場合にはオススメです。ライセンスは『BSD』で、商用利用も可能です」（洪さん）

これらのフレームワークのうち、洪さんがオススメに挙げたのは「Keras」です。

「現在最も注目されているフレームワークは、間違いなく『TensorFlow』でしょう。OSSのコード量は約74万行あり、Googleが開発しているので開発に携わる人も多く、200人年を超えています。流行していることで、コミュニティに質問を投げるとすぐに答えが返ってくる点も非常に魅力的です。

ただ、私の一番のオススメは『Keras』です。『Keras』は初心者向けのフレームワークであり、組み合わせを利用するだけで複雑なネットワークが作れる点がいいですね」（洪さん）

最後に洪さんは、アプリ開発のリアルタイム画像認識に使用した「Darknet」を紹介してLTを終了しました。

UnitTestコードはいつ・誰が書くべきか？

最後は猪飼さんの登壇です。

猪飼綾（いかい・あや）／株式会社ブレイブソフト リード・エンジニアリング事業部 エンジニア。2016年にブレイブソフトへ入社。

「UnitTestコードはいつ・誰が書くべきか？」というタイトルでスタートした猪飼さんのLT。この問に対して「明確な答えは存在しないと思いますが、これはエンジニアが考え続けるべき問題だと考えているんです」　と説明する猪飼さんは、テストコードに関する自身の経験を紹介します。

「テストコードを書くには『時間掛かる』『リソースが必要』『コストに見合う結果があるのか？』といった問題がありますよね。でも、エンジニアなら誰でもテストコードを書いた方がいいと思ってるはずです。

私たちの子会社でのオフショア開発の事例をお話します。そのプロジェクトでは開発期間が短く、そもそもテストコードを書くスキルが子会社にありませんでした。でも、本社でもテストコードを書くリソースは不足しています。とりあえずは作ってリリースしたのですが、品質がイマイチだという結果になってしまったんです。

そこで、リリースした後ではありますが、品質をあげるために本社でテストコードを書くことにしたんです」（猪飼さん）

しかし、猪飼さんは自身で実際にテストコードを書いてみて「とても大変だった」と感じます。猪飼さんはその理由を説明します。

「そもそもテストコードを書けないエンジニアによって書かかれたコードですから、当然のことながらテストを意識したコードになっていませんでした。

『テストを意識したコード』とは、クラス分離やメソッドの設計が一定のレベルに達しているコードです。だからモック化しやすいわけですよね。

また、他人が書いたコードを読むのは時間がかかりますし、これは私個人の問題かもしれませんが、イマイチな設計のコードを読むのにはとてもストレスがたまりました」（猪飼さん）

では、テストコードは誰が書くべきなのでしょうか？ 猪飼さんは「実装者と別の人がテストコードを書く場合」と「実装者がテストコードを書く場合」のメリットとデメリットをまとめます。

【実装者と別の人がテストコードを書く場合】

■メリット

• 第三者的な目でコードを見ることができる
• 使用の対応漏れ、仕様の誤解を防げる

■デメリット

• オフショア開発のため日本語のコメントがなく、設計意図が理解しにくい
• そのため、メソッドの役割がわからない
• コードを読解しながらテストコードを書くため、とても時間がかかる

【実装者がテストコードを書く場合】

■メリット

• 第三者が見るほどではないものの、設計を見直す機会になる
• その結果、機能の品質が向上する
• テストケースを考えやすい
• モック化しやすい

■デメリット

• 仕様の漏れ、認識違いに気が付きにくい
• 自分のコードを客観視するスキルがないとうまく機能しない

最後に猪飼さんはテストコードについて自身の考えを語り、LTを終了しました。

「もちろん正解はひとつではありません。ただ、私は実装者本人がテストコードを書いたほうがいいと考えています。それは『時間が短縮できる』『設計を見直す機会になる』『テストコードを書く際に、仕様の再確認をするので、仕様の漏れ・誤解を減らせる』などが理由です。

また、テストコードを書くタイミングについては、実装と並行して実施するといいのではないでしょうか。ある機能の実装が終わったら、その機能を確認するテストコードを書ければベストだと思います。それは、細かい粒度で設計を見直す機会になりますし、機能ごとの品質があがるからです」（猪飼さん）

懇親会！

5名によるLTの終了後は懇親会のスタートです！

懇親会にはほとんどの参加者が残り、登壇者とも交流が盛りあがっていたようです。またのご参加をお待ちしています！