TECHHILLS-CROOZ CTOが考える 企業とOSSとの付き合い方-

Transcript

1. CROOZ CTOが考える 企業とOSSとの付き合い方 クルーズ株式会社 鈴木 優一
2. 自己紹介 経歴 ・2008年にモバイルコンテンツプロバイダに入社 ・2012年クルーズ株式会社に入社 入社後は技術統括部門の責任者として全社の開発平準化や採用技術選定、 アーキテクト業務に従事のほか、品質管理部門やCS部門、人材育成部門 の運営に携わる。 ・2015年に執行役員就任 最高技術責任者CTO グループのIT技術・セキュリティ分野全般を担当する。 鈴木 優一 クルーズ 株式会社 執行役員 CTO 兼 CROOZ SHOPLIST株式会社 技術統括部長
3. ・CROOZ のについて ・SHOPLISTで採用しているオープンソースソフトウェアについて ・技術選定時の視点 ・企業視点でのOSSとの付き合い方 ・OSSとの付き合い方の注意点 本日のAgenda
4. １ CROOZ について
5. CROOZ について クルーズは『SHOPLIST.com by CROOZ』を軸に、EC領域に関連する 複数のサービスを展開する「ECソリューションカンパニー」です。 モバイル コンテンツ 受託開発事業 IT業界に 特化した 人材派遣事業 2001年 検索エンジン CROOZを 活用した ネットワーク 事業 2002～ 2009年 事業売却 コンテンツ ブロバイダ 事業 ソーシャル ゲーム事業 2003年 2007年 Mobage 参入 2007年 ネイティブ ゲーム市場 参入 2014年~ モバイル コマース 事業 2008年 2016年~ 事業撤退 ファッションEC SHOPLIST 2016年~ 10業種20社を超 えるグループ経営 で1兆円を目指す 時代の流れに合わせメイン事業を 5回変更
6. CROOZ について 現在EC領域を中心にゲーム領域/ 広告/メディア領域で 事業の展開をしています
7. CROOZ SHOPLISTについて 「一番お得、ここにしかない商品の提供」をビジョンに、レディー ス・メンズ・キッズのファッションアイテムを中心にインテリアや コスメや雑貨に至るまで、幅広いジャンルのアイテムをまとめて購入 できる通販サイト「SHOPLIST.com by CROOZ」を運営しています。
8. 2 SHOPLISTで使用している オープンソース ソフトウェアについて
9. 採用しているオープンソースソフトウェアについて 9割以上がオープンソースソフトウェア 例）サーバ周り ・CentOS、Ubuntu ・MySQL、PostgreSQL ・PHP、 Laravelr、その他各種ライブラリ 例）クライアント回り ・Flutter、その他各種ライブラリ 例）開発ツール関連 ・GitLab CE 一方で商用で使も使っている ・Microsoft の各サーバ製品（Windows Server／SQL Server）
10. 主な技術スタック ・技術スタックはサーバはLAMP ・ネイティブはJava/Kotlin/XCode/Swift併用 ・現在技術スタックの置換え中（後程詳細説明） Server Side Frontend Dev/Ops Native App Infra Structure
11. 3 技術選定時 の視点
12. 技術選定時の視点 前提 ▪企業（営利法人）の目的は利益を上げること 業種は違えど、市場や顧客から満足をするサービスやモノを提供し、 利益を追求するもの なので、技術選定は上記を実現する手段の１つにしか過ぎず、 商用ソフト使うことは悪である！ みたいな考えではないです。
13. 技術選定時の視点 前提 ▪企業（営利法人）の目的は利益を上げること 業種は違えど、市場や顧客から満足をするサービスやモノを提供し、 利益を追求するもの また、 オープンソースプロジェクトに参加し、OSSにコミット することを強く奨励します！ みたいな考え方もないです。
14. 技術選定時の視点 技術選定時に最も大事にしていることは以下５つ １．その時の課題を解決するソリューションとして適切なものか？ ３．いま採用している技術スタックから置き換え可能なものか？ ４．選定しようとしている技術要素に対する情報が十分にあるか？ ５．選定しようとしている技術要素に将来性があるか？ まず、OSS云々関係なくこの視点で見ています ２．採用しようとする技術要素は経済合理性があるか？
15. 技術選定時の視点 技術選定時に最も大事にしていることは以下５つ １．その時の課題を解決するソリューションとして適切なものか？ 例えば ・ページ表示速度を速くしたい → 画像フォーマットのwebP対応 レスポンスのBrotli 圧縮 ・生産性を向上させたい → クロスプラットフォーム言語 の採用 など、課題を解決させるうえで適切かという視点
16. 技術選定時の視点 技術選定時に最も大事にしていることは以下５つ ２．採用しようとする技術要素は経済合理性があるか？ 例えば ・この技術要素はオープンソースソフトウェアとして存在するけど 実装にかかる時間が商用製品と比較して3倍かかる →工数と人月単価と、商用製品のコストを見たら 投資対効果は適切なの？ といった、投資対効果の視点。
17. 技術選定時の視点 技術選定時に最も大事にしていることは以下５つ ３．いま採用している技術スタックから置き換え可能なものか？ 例えば ・この技術要素は、いま採用している技術要素と親和性が高いので 習得コストが少ない。 ・この技術要素は、いま採用している技術要素との親和性が低いので 経済合理性を見る際に、学習コストを見込んでおく必要がある という技術の視点。
18. 技術選定時の視点 技術選定時に最も大事にしていることは以下５つ ４．選定しようとしている技術要素に対する情報が十分にあるか？ 例えば ・この技術要素は、コミュニティの公式ドキュメントはあるけど、 利用ユーザの投稿記事が多い、少ない ・この技術要素は、商用で公式ドキュメントはあるけど内容が薄くかつ ブラックボックスなのでサポートへの問い合わせベースでの対応になる かもしれない という採用する技術に対する情報の視点。
19. 技術選定時の視点 技術選定時に最も大事にしていることは以下５つ ５．選定しようとしている技術要素に将来性があるか？ 例えば ・オワコン化している技術じゃないか？ ・開発コミュニティは活動をしているか？ ・オワコン化している技術であっても経験者が市場に十分いるか？ という将来性の視点。
20. 技術選定時の視点 過去の技術選定事例 WebP １．その時の課題を解決するソリューションとして適切なものか？ →ブラウザに転送されるデータ量が多いことが課題。うち8割が画像リソースである ため、画像を圧縮するという問題の解決策は適切 ２．採用しようとする技術要素は経済合理性があるか？ →CDNは転送量に応じた従量課金なので、仮に画像リソース容量が4割削減でき、 その削減費用相当の投資額で実現できるのであれば経済合理性がある。 ３．いま採用している技術スタックから置き換え可能なものか？ →当時はサムネイル生成処理はEC2上に構築されたWebサーバ(Nginx)上にsmalllight をたてて動的変換したものをCDN上でキャッシュ化していた。 今回ngx_sall_lightを使って置き換えも可能ではあったが、スケーラビリティと コアコンピタンス視点から、置き換えるのではなく、処理一式の外だしを検討 OSSという手段ではなく、Fastly CDNのImage Optimizerをの利用を検討
21. 技術選定時の視点 過去の技術選定事例 WebP ４．選定しようとしている技術要素に対する情報が十分にあるか？ →公式ドキュメントもあり、また第三者の作成記事もあり設定実装を行うのに 十分な情報量と判断 ５．選定しようとしている技術要素に将来性があるか？ →CDNサービスで見て、Fastlyのシェアは純増。 現行のEC2＋nginx+smalllightを独自で運用し続けるよりは商用サービス利用 のほうが将来性があるのでは？と判断
22. 技術選定時の視点 過去の技術選定事例 Laravel １．その時の課題を解決するソリューションとして適切なものか？ →管理画面の生産性高く製造できないのが課題。 独自フレームワークからLaravelに切り替えることで製造スピードの向上が期待 ２．採用しようとする技術要素は経済合理性があるか？ →学習コストは多少かかるものの、同じLAMP環境上で動作し、同じMVCの思想に 基づくフレームワークのため、学習コストが少なくかつOSSなので投資コストは小 ３．いま採用している技術スタックから置き換え可能なものか？ →上記記載のとおり既存フレームワークと親和性が高く置き換え可能と判断
23. 技術選定時の視点 過去の技術選定事例 ４．選定しようとしている技術要素に対する情報が十分にあるか？ →公式ドキュメントもあり、また第三者の作成記事も十分ある。 また従業員にも経験者が多い ５．選定しようとしている技術要素に将来性があるか？ →自社フレームワークの100倍将来性がある Laravel
24. ４ 企業視点での OSSとの付き合 い方
25. 企業視点でのOSSとの付き合い方 １．原則利用がメインにどうしてもなっちゃう ・前のページでも触れたとおり、営利企業だとサービスやモノを提供して 利益を出すことをが目的。 ・その手段として各技術要素があって、その一部がOSSとなるため、 原則は利用となり、OSSプロジェクトへのコミットが目的であって はならない。
26. 企業視点でのOSSとの付き合い方 ２．OSSコミュニティへの貢献も必要 ・ただ利用しているだけでは、利用しているOSSプロジェクトは発展しな いかもしれなし、極論将来的にOSSプロジェクトのバージョンアップが 行われず、最終的に困ってしまうのが自分になるかもしれない。 ・大前提MIT License, Apache Licenseなどの各ライセンス従い、自分で 改変した場合にソース開示（対象project へのPull Requestはすべき） →技術統括本部だけでも直近1年間で4件Pull Requestを実施 ただ業務で使っている中で、これは大本直したほうが良いよねってのが原則なので 数は多くない
27. 企業視点でのOSSとの付き合い方 ３．OSSプロジェクトへのコミットだけがOSSへの貢献ではない ・例えば、Issues（バグ報告、要望、質問など）を上げる ⇒OSSコミュニティ内に情報を発信する。 ・事例記事をまとめて自社の技術ブログで公開する。 ⇒OSSコミュニティ外に情報を発信する。 ・業務上で改変したらPull Requestする ⇒仕事の中で行った改変はソースとして開示する。 ソースコードを開示する以外にもOSSプロジェクトを継続的に盛り上げて 行くことのサポートはできる！！
28. ５ OSSとの付き合 い方の注意点
29. OSSとの付き合い方の注意点 公式の「保障」「サポート」がないことへの留意は必要 ・決して「品質に問題がある」「サポートが悪い」というわけではない ・実際にレビューがされたのちリリースされており、Issusへのレスある。 ・ただしOSS提供元は個人やコミュニティで活動している人々が大半で、 なので、期日や要求する品質を「保証」するという考え方ではない。 ⇒自分で改変しすることや、代替プロダクトを選定するなどの対策を 考えておく必要がある。 ※特にライブラリ系は気軽に探して使ってしまう分注意が必要 過去にWebViewライブラリで実現したいことができず、代替ライブラリに 差替え、呼出し部分の書換えで対処した経験あり。
30. OSSとの付き合い方の注意点 Pull Requestしたからといって100% Mergeされるわけじゃない ・自部署のメンバーで直近1年間で4件Pull Request して、Mergeまで いったのは2件 ・いまだにOpen状態のものもある。 ・要するに、コミュニティの事情により改変を開示してもMergeされるまで の期間に差があり、MergeかCloseのいずれかが保証されてるわけではない
31. OSSとの付き合い方の注意点 場合によりOSSのほうがプロダクトの継続性に優れる場合がある 過去にあったこととしては ・Flashの変換エンジンを外部の企業より商用で提供を受けていたが、その会社 が変換エンジンの提供・保守をやめてしまった。 ・結局OSS のFlashの変換エンジンに乗せ換えて運用していた ・なので、稀ではあるものの商用だからと言って継続性の保証があるわけじゃ ないということを念頭に置いておくべき
32. ６ まとめ
33. まとめ ・企業視点でのOSSとの付き合い方だと、利用がメインに ・一方でOSSへの貢献は必要 ・改変した場合は各ライセンス規定に従ったソース開示はマスト ・ソースコード開示という方法以外にもOSSへの貢献として情報の 発信という手段もある ・なので、OSSプロジェクトへのPull Request がすべてだと思わず 業務の中で両立できる貢献は積極的にしていくべき
34. 今後のイベントのお知らせ
35. 本日お話できなかった裏側のディープなお話や CROOZ SHOPLISTの組織についてお話します 直近開催予定のイベント
36. 次回 2022年7月開催予定！ 次回のテックヒルズ開催のお知らせ TECHPLAYで CROOZをフォローして 情報をお待ちください！
37. Twitterでも情報発信しています！ 情報発信強化中！！！ ハードボイルなCTOのつぶやき 未経験エンジニアの教訓 s-flo
38. 最後に 現在積極採用中です！！ 詳細はこちら⇒