More Related Content
Similar to SierでScalaを試した結果 Web系に転職した話
Similar to SierでScalaを試した結果 Web系に転職した話 (20)
SierでScalaを試した結果 Web系に転職した話
- 2. 自己紹介 ● 細西 伸彦 スクィーラ@bake_nezumi ● ４２歳 ● エンジニア ● 株式会社サイバーエージェント アドテクスタジオ所属（２０１８年７月～） ● １９９９年～２０１８年までユーザー系システム子会社に勤務してました （福岡） ● Scala歴は５年くらい 2
- 3. 今日話すこと ● 経歴 ● 前職での役割 ● SIerでScalaを部分導入した話 ● SIerでScalaの完全導入はできなかった話 ● 技術選定をどのように行っていたか ● Web業界へ転職した話 3
- 4. 経歴 4
- 6. 経歴 （３０代） ● 開発を希望し福岡に戻る ● 自社の開発手順標準化 RUPベース 設計書様式、設計手順、開発手順、テスト手順 ● 自社フレームワーク構築（受託スクラッチ開発用） Java, Struts, Seaser2 + Excel設計書からのボイラープレート生成 ● フレームワークの維持、展開 開発ガイドラインの作成、機能拡張、標準化適用、トラブルシュート １０名規模 ～ １００名規模くらいのものを数プロジェクト担当 ● ３４歳くらい～ 技術責任者の立場になり、選定権限を得る 6
- 7. 前職での役割 7
- 8. 前職での役割 ● 開発プロセスは基本ウォーターフォールで行っていた 主な理由 管理手法が確立されており計画に対する実績の進捗が把握しやすい （受託開発は基本納期がマスト） トラブらないためには 計画と実績の乖離が少ない必要がある → 型にはめる ● できること、できないことを明確にする → はまらない要素は？ ● ブレが大きいと考えられる部分は先に潰す 8
- 9. 前職での役割 9 受託プロジェクトA 標準化チーム 要件定義/後工程見積 設計/開発 テスト/導入 開発フレームワークメンテナンス 標準化メンテナンス プロトタイプ 性能試験 受託プロジェクトB 要件定義/見積 設計/開発 テスト/導入 プロトタイプ 性能試験 標準化教育 標準化教育 技術的な流動要素を 引き受けるチーム 顧客との契約の単位
- 11. Scala導入のきっかけ ２０１４年、自社製WMSパッケージ新規開発の企画が立ち上がり、 アーキテクチャ策定を任された Strutsベースのフレームワークは限界を迎えており刷新を決意 ● 長年の拡張により肥大化、複雑化し新規拡張が困難 ● StrutsがすでにEOL プロトタイプにPlay Frameworkを選定し検証 → 問題無いと判断し作り上げた 11
- 13. Scalaが使えることが選定理由になった理由 ● 現代的な記述様式を学べる ○ パターンマッチ ○ イミュータブルなプログラミングスタイル ○ など ● Java資産の利用が可能 ● 個人的なモチベーションが上がる ○ 他に自信を持って布教できる 13
- 14. Scala部分導入時のアーキテクチャ概略 Java 8 Play 2.3 Bootstrap JQuery アプリケーション RDB Doma2 14 JDBCREST Client Front Server 自作フレームワーク Java 8 Play 2.3 アプリケーション Doma2 自作フレームワーク アプリケーション Back Server JDBC
- 15. 自作したフレームワークおよびライブラリ ● UIコンポーネントのサーバーレンダリング （Twirl利用） ● Pub/Subのブリッジ（Akka利用） ● - DomaとPlayの統合 アプリケーション（業務処理） ● サーバー処理 ● 画面 Scalaの利用箇所 15 Scala Java すべてJava YAML, JavaScript 言語 全体コード量の 3%くらい
- 16. できたこと、できなかったこと できたこと ● Scalaアプリケーションの開発基盤構築 ● 自チーム内のScala布教（3名程度） できなかったこと ● アプリケーション（業務処理）をScalaで作ること 16
- 18. Scalaの適用範囲を広げる際の障壁 ● 開発者の確保ができない 受託開発の特性上、プロジェクト発足時に協力会社より要員を募って 体制を作るが、Scalaエンジニアは市場に居ない → 自社で育てないと事実上不可能 ● 保守、運用に自信が持てなかった 構成上アプリケーションを一部Scalaにすることは問題なくできた。 が、１プロダクト内に２言語あると機能追加のコストが読めない状況 になる上要員が限られる 18
- 20. もうひとつの課題 O/RMapperをどうするか、決めかねていた 現状利用しているDomaに不満はなかった ※Doma コンパイル時のコード生成 ＆ チェック ２Way SQL対応テンプレート 依存ライブラリなし を特徴としたJavaのDBアクセスライブラリ https://github.com/domaframework/doma 20
- 26. アノテーションがつらい。。 26
- 31. Domalaの現況 Daoの利用について、ほぼJavaと同様に書けるようになったため実行に踏み切ろうとし ていた矢先・・・ 利用していたScala Meta ParadiceがEOL ※ Scala Meta Paradice アノテーションマクロを実現するScalaのコンパイラプラグイン experimentalなライブラリであったため仕方がない。。。 打開策が考えられていないので現在開発は中断しています Macro Paradiceに実装を変更 or sbt pluginにしてコードジェネレート 31
- 34. 技術選定をどのように行っていたか 基本指針 ● 組織のスキルとマッチすること ○ 無理はしない ○ ガイド類、サンプル類は厚めに準備した方が開発は回った ● 楽しいこと ○ つらみが少ない ○ サクサク感 ● 影響が大きいものは他者に委ねず最終的に自分で決めること 34
- 35. 技術選定をどのように行っていたか ライブラリの選定基準 ● コミュニティが活発であること ○ ガイドがしっかりしている ○ 日本語の情報もできれば欲しい ● 捨てられること ○ 依存性がない、もしくは少ない ● なるべく自分で作らないこと → 作りたくなったらOSS化した方がいいかも 35
- 36. Web業界に転職した話 36
- 37. 転職のきっかけ スカウトメールがきっかけ 特に転職活動は行っていなかった ● 年齢に不安があった ● 人間関係、仕事内容に大きな不満はなかった ● 機会があれば、という思いはあった 広告配信という全く未知の分野であったが、大量トラフィック、分散並列処理、機械学習 といった前職でやりたくても出来なかった仕事ができることがとても魅力的に感じた 37
- 39. 転職後の現在 仕事はとても楽しい ● 開発プロセスはスクラム ○ 自社サービスなのでプロダクトにフォーカスしてスケジュールできる ● 型にはめなくていい ○ 周りはみんなエンジニア ● Scalaを思う存分書ける ○ Finagle web server ○ MacWire DI library ○ ScalaPB protocol buffer compiler ○ Scanamo DynamoDB access ○ circe JSON library ○ Doobie Functional JDBC Layer ○ cats 39
- 40. 転職して気づいたこと ● 危機感が重要だということ ○ 今効果が出せていることが未来も効果を出せるとは限らない ○ 変化しつづけられれば年齢は関係ない ● 好きな仕事を見つける ○ 他人の期待に沿おうとするとツライ ○ 自分の軸はあったほうがいい ○ やりたいことがあったら周りを巻き込む努力が必要 40