システム開発部アプリケーションエンジニアの工藤です。
今回は、マイクロアドのWebアプリ開発における社内標準化の動きとその策定内容について、簡単に紹介したいと思います。
課題
Webアプリプロダクトに注力する機会があることで、チーム内・外のメンバーが様々なWebアプリプロダクトに触れることが度々あります。 その際、そのプロダクトの立ち上げ時期が大きく違うなどの理由で、プロダクト間の差異に困惑してしまうケースが見受けられていました。 例えば、フロントエンドの自動テストフレームワークにJasmineが採用されているプロダクトもあればJestが採用されている場合もあるなどです。
「チームの垣根を越えてWebアプリプロダクトへの参入障壁を少なくしていきたい」という理想も踏まえ、標準を策定していくことになりました。
同好会の立ち上げ
そこで標準化同好会が立ち上がり、Webアプリプロダクトにおける標準策定を推し進めています。
策定内容
まずは現状、同好会で策定できている内容の一部を紹介します。
Vueの自動テストフレームワーク
下記を理由にJestを採用。
- JavaScriptのテストフレームワークで一番利用率が高く、デファクトスタンダードと言える。（Testing Libraryはテストランナーです。）
- AirbnbがMochaからJestに切り替えている。
タイポグラフィー
下記を理由にtext-lint（Configはtextlint-rule-preset-JTF-style）を採用。
- 日本翻訳連盟の翻訳ガイドに則っている。
- 弊社の技術ブログでも採用している。
Javaのスタイルガイド
下記を理由にGoogle Java Style Guide
- 「Java formatter IDE」などで検索すると大体これが使用されている
- EclipseやIntelliJ IDEA用の設定ファイルが公開されている
インデントや行の長さについて、特に参考になりそうな情報はなかったため、弊社のWebアプリプロダクトで標準となっている基準を採用しました。
- インデント： スペース4
- 行の長さ：120文字
Kotlinのスタイルガイド
下記を理由にKotlin Coding conventionsを採用。
- Kotlin公式のコーディング規約
- 弊社で主にサーバーサイド開発に利用されているIDEは開発元が同じIntelliJ IDEAで、標準でフォーマッタを提供している
策定する際の試行錯誤
標準の策定は想像よりも遥かに難航しています。 理由としては下記が考えられます。
- 何を標準とするのかが判断し辛いものが多い
- 想定していたよりも標準化したい・した方が良い項目が多い
- 限られた時間の中で進めたい
- 調査・検討の時間が長いとモチベーションが低下しがち
採用基準
何を標準とするのかが判断し辛いものが多い
調査・検討する際に決めきれないケースを避けるために下記の基準を設けました。
調査・検討する際に気をつける「標準」とは
- 多くの会社で採用されている
- 技術的に信頼できる特定の会社で採用されている
多くの会社で採用されている
具体的には、技術ブログなどその会社発信の情報を参考にしたり、npmモジュールの場合、npm trendsでinstall・Star数を比較することで判断しています。
検討する際に気をつける4つのコスト
- 学習コスト
- 導入コスト
- 運用コスト
- 検討コスト
チームを超えてWebアプリプロダクトへの参入障壁を少なくしていきたい
これが念頭にあるため、画期的と思われるものでも学習コストが高いため断念するケースもありました。
検討・導入コストを下げるための施策
検討していく中で、コストを下げる方法についても下記のように決めることができました。
- 検討コスト： 大きな標準を決定・導入した後、小さい課題に対して規約を改修していく。
- 導入コスト： 既存への変更は即時行わず、プロジェクトで変更を加える部分のみ適用していく。
検討コスト： 大きな標準を決定・導入した後、小さい課題に対して規約を改修していく。
lintが分かりやすい例になります。
eslintで、eslint-config-airbnb-base を採用し、linebreak-style は許容したいなどの詳細な規約に対する変更については、導入後に検討するという流れです。
効率的に進めるために
限られた時間の中で進めたい 調査・検討の時間が長いとモチベーションが低下しがち
上記の検討コストを下げる工夫も効率化の1つに当たりますが、他にも工夫しています。
- 当事者意識を高めるため、少ないメンバーで少ない項目を調査・検討していく。
- 長期化によるモチベーション低下を防ぐため、重要度が高いと思われるものをメンバーの数だけに絞り、各項目の調査をメンバーに依頼する。
- 調査が進まずに長期化することを避けるため、場合によっては調査時間を設ける。
今後の展望
サーバーサイド・フロントエンドの設計思想など標準を策定していきたい内容は山積みですが、 少しずつでも様々なWebアプリプロダクトへの参入障壁を少なくして、効率的な開発ができるようにしていきたいです。
組織・チーム内における規約を設ける際などの参考になれば幸いです。
募集
現在マイクロアドでは、フロントエンドからバックエンドまで幅広く経験できる環境で、大規模なWebアプリプロダクトを共に作り上げていくエンジニアを募集しています。
少しでも興味をもたれた方は、採用ページをぜひご覧ください。
