こんにちは。
普段はdelyのAndroidアプリの設計、実装とかその他もろもろを担当している梅森です。
最近弊社では、長期的な技術的な意思決定や技術的課題の可視化・解決の支援など、技術的な側面においてdelyの開発チームが成長していけるような取り組みを考えて実施しています。本稿ではそのうちの取り組みの一つをご紹介します。
エンジニアは普段の機能実装と並行して長期的なプロダクト改善を行うための施策を行っていたりしますが、アーキテクチャの移行やリファクタリング、自動テストといった施策は短期的には成果が見えにくいということもあり、業務的に近いエンジニアや成果が分かりやすいことをやっているエンジニアがどんなことをやっているかは分かるが、あまり仕事で関わらないエンジニアは何をやっているかよく分からないという状態になったり、会社としてはどのような技術的な意思決定を推奨しているかということが分からない（あるいはそもそも知見が存在しない）という状態になりがちです。
開発チームの規模が大きくなっていけば、例えばiOSやAndroid、サーバーサイド、SREといった技術領域ごとにチームを組織化してそこで知見を共有したり溜めたり、技術的な意思決定をしたりといったことを計画的に行っていくことになると思いますが、弊社くらいの規模ですとそこまでの取り組みを本格的に始めていくというのはまだまだ難しいものがあります。
そこで、手始めに各技術領域ごとで現在取り組んでいることや技術的な課題感、ロードマップ、最近興味のある技術領域などを定期的に開発チームにヒアリングして、Qiita:teamにまとめて共有するという取り組みを始めてみました。（delyは全社的にドキュメントをQiita:teamにまとめる文化に最近はなってます）
こんな感じです
参考にしたのは、The State of Go 最新版へのリンク という1年に1回発表されるGo言語のそのタイミングでの状況をまとめたスライド（発表は実際に拝見したことは無いですが、いつか拝見してみたい）です。このような形で定期的に開発チームの技術的取り組みを概観した資料があったらいいんじゃないかということで、「State of dely dev」（なんでTheが抜けてるんだろう）というタイトルでQiita:teamに記事を投稿しています。
今回はなるべくそれを生に近い形でこちらのブログに転載します。箇条書きでざっくり書いてあるだけですが、雰囲気だけでも感じ取ってもらい、なにかの参考になれば幸いです。なお、この情報は2018年7月時点の情報なので、古い情報も多々含まれていることをご了承ください。
iOSチームの技術的課題
自動テスト
- なかなかコード量増加のスピードに追い付けていない
- 将来的にはテストもコーディングと一緒に書いていくスタイルにしたい
自動生成周り
- サーバー側のswagger.json出力の準備が進んできた
- JSON API形式の自動生成との相性は悪いが、後は手を動かすだけという状態
- プロダクト開発とは違う課題が出てきたりして面白い、コーディング的な難しさに直面しがち
- 使っているライブラリ自体の不具合も出やすい、一回ライブラリにプルリク送ってマージされたりといったことも
- コミットメッセージを英語で書いたりして、英語への心理的ハードルが下がった
- 人が少ないからこそ自動化的な方向性に投資していく
チーム開発について
- 大きいプルリクの問題は解決しているわけではない、一日一回はWIPの状態でもコミット＆プッシュして分割レビューの目安にするとかいう手はあるかも
- 一個もプルリクきてないとSlackで通知を送ったりするのはいいかも
- Dangerで500行以上のコミットの場合はWarningを出すようにしている
プロトタイプ開発
- プロトタイプ専用のコードベースでプロトタイプ開発している
- その中で既存コードを模写しつつリファクタできそうなところを発見したりしている
- ビルドも速いのでiOSの新しい機能を試したりできる、今度そこで試した機能をリリースする（3Dタッチしたときにプレビュー出したり）
- Codableでjsonパースするとかも試してみて発見がある
- 検索画面のUIとかも新しい動きを試してみたりしている
- アニメーションテストするときとかもいい
- 将来的にはUIコンポーネントを分離して、それをプロトタイプ開発でブラッシュアップして本体に取り込むみたいなこともしたい
- ペーパープロトタイピングで認識をすり合わせて作り始められているのでスピード感をもって作れている
ライブラリの更新問題
- ライブラリが更新されたら自動的にプルリクを作るものを作ったが、なかなかうまくいっていない
Androidチームの技術的課題
自動テストについて
- Kotlinはテストコードから導入する予定
- まずはUIテストからやる予定
- テストコードは気兼ねなく捨てられるのでまずは捨ててもいいからコードを書いていく
Redirectable UIについて
- ConstraintLayout 1.0にはすっかり慣れた
- ConstraintLayout 2.0 - MotionLayoutの可能性
アクセシビリティ対応をそろそろ考えたい
- 文字サイズ大きくしても破綻しないUI
- 画像にキャプションつけるとか（画面読み上げ対応）
- 色覚対応
- 長期的に対応したい
- とりあえず文字サイズが一番大きい
JetPack対応
- 今のところすぐ導入すべきものはないが
- これは～という理由で導入してないと言えるくらいのレベルには理解しておきたい
ビルド遅い問題
- Firebase、Google Play Servicesのアップデート等でだいぶビルドが遅くなってしまった
- 都度都度ライブラリの依存関係の見直し等を行うことでビルド遅い問題に対処していきたい
- マルチモジュール化の検討もすすめる
Webフロントエンドチームの技術的課題
もろもろ進行してます
- Webpackerへの移行は完了
- jQuery依存からの脱却は完了
- SSR導入は決定、作業中
PWA
- コンパイルされたJSを分割してそのページにあったものをロードするということができるようになった
- webpackで任意のチャンクに分割してJSを別々にロードすることのできる機能を活用している
SPA
- レスポンシブ表示で同じ構造で表示するのではなく、PCとSPに最適化された構造に移行していきたい
- ローディング時に読み込み対象のプレースホルダーを導入したい、今は読み込みでガタガタ動いてしまう
- デプロイ、テスト遅い問題（デプロイ40分）
バックエンドチームの技術的課題
既存の技術的負債の返済
- まずはRails 5.0へのアップデート
- 現状のアーキテクチャでもクラシルのリード過多なアプリであればスケールしていけそう
A/Bテスト
- API側のA/Bテストも出来るようにする予定
テスト遅い問題
- テストを早くする方法は分かっているが作業はめんどくさい、ElasticSearch、キャッシュも分離しないと早くできない
- 実際にどのテストケースが遅いかを調べたりとか
- データベースのボトルネックになっているクエリを潰しているが、先回りして検出してやりたい
Swagger
- swagger.jsonの自動生成については目途は立ったのでマイルストーンを立てる
- iOSとの連携も進行中
API定義をyamlで記述するトレンド
- APIをyamlで記述するのが流行っている
- Googleでyamlで書いた構造にAPIに沿っているかテストできるサービスを出したりしている
- API構造をyamlで記述しているのがメインストリームになりそう
- その先のアクション（APIを丸ごと自動生成したり）がありそう
機械学習チームの技術的課題
レシピデータの構造化を進める
- レシピ情報の構造化を進めている
- レシピの特徴量を出していくにあたって、レシピを入力する側の手順を整理したい。レシピ情報の構造化を進められれば、料理の難易度を判断したりもできそう
- ルールベースのバリデーションでチェックするなどの方法であれば、そこまでコストがかからなく役にも立ちそう
SREチームの技術的課題、ロードマップ
データ可視化プロジェクト
- 独自のダッシュボードを作っている
- Vue.js+Express
- メインのデータレイクはエターナルポース
- SQL書かない人が使うようなダッシュボードがほしい
既存のプロダクトについて
- Metabase、Re:dashなどはSQL書く人用のプロダクト
- サービスの用語を使ってデータを分析できるようなツールがない
- グラフについてもプリセットのものでなく、より見やすいものが欲しい
- 変数についても細かい制御ができない
プロトタイプ開発
- まずプロトタイプを作って、今クオーター中にプロトタイプをもとに機能追加の土台になるものをリリースし、アジャイルみたいな開発フローに載せたい
- 一チームいてもいいくらいの規模
- 1年後を考えた時に、自分たちのサービスの用語で整理された可視化ツールがあった方がいい
- 現状はレポーティング、データ分析をバラバラ、属人的にやっている、それを統合したい
データレイクの移行（エターナルポース）
- できた、追加でやることはない
- 必要になったら過去データ（Firebase, Logpose）の移行もやる
こまごまサーバーインフラ整理プロジェクト
- こまごまとしている社内システム的なプロジェクトがあり、メンテされていない
- それらのデプロイがうまくいかなくなっている、方法を統一したい
- どういうものがあってどのような構成になっているかは把握できている
検索周りの技術的課題
検索アルゴリズム自体の改善
- バックエンドのロジックのA/Bテストをやるかもしれないので、それが入ったらロジック部分の検証をやるかも
検索ログの分析の知見を開発部以外でも活用する
- 検索のログデータを活用して、いろいろなところにデータを渡せるようになってきた
- 日ごとの検索ランキングをSlackで自動で共有したり
- 検索共有MTGで検索トレンドを共有したりしている、最近はタイアップやマーケの人にも共有している
- 検索自体の改善もそうだけど、レシピ選定もデータに基づいて行ったりできるようになってきた
- 調理部の作業フロー自体の改善にも貢献できるようになってきた
- 最近では、2か月先向けのレシピの提案を行えるようになってきた
検索内容の改善
- 検索されても存在しないクエリがたくさんあったのが、最近はいい感じに埋まってきた
ちょっと長くなってしまいましたが、delyの開発チームでは最近このような取り組みをしていますというご紹介でした。
delyでは、会社の開発文化自体の発展、促進に興味がある人を募集しています。
（あとAndroidエンジニアも募集してます。）
