IDCフロンティアのUI・UXチームです。
前回はフロントエンド領域の開発に関する業務フローを中心にご紹介しました。今回は利用技術だけでなく、効率的に開発を進めるための工夫や普段気を付けている点などをご紹介します。
前回のブログ内容と合わせて読んでいただくと、実際の業務イメージが想像しやすいかもしれません。
利用技術
IDCフロンティアで主に利用している技術要素を紹介します。中途採用情報ページにも記載がありますので、合わせてご覧ください。
JavaScriptライブラリ
コンポーネント指向のライブラリを採用しています。Vue.js（2.x）とReact.jsを中心に採用していますが、古いサービスではjQueryやRiot.jsが採用されているものもあります。
jQuery・Riot.js・Vue.jsはReact.jsへの置き換えを計画しており、現在対応を進めています。サービスが長期的に運用される都合、大きくAPIが変わってしまう技術を採用し続けることにリスクを感じたこと・選定当初はTypeScriptとの親和性をReact.jsの方に感じたこと等が理由です。
また、素のJavaScriptではなくTypeScriptを用いて開発しています。型を使うことで関数やAPIリクエストに使うパラメータの取り扱いミスを減らせますし、型を使ってインターフェースを表現しておけばアプリケーション理解にも役立ちます。
ライブラリの取り扱い
フロントエンド領域では外部ライブラリを多用して開発を進めることもあると思います。しかし、IDCフロンティアのフロントエンド開発では、ライブラリは必要最低限の物を用いるようにしています。
理由はフロントエンド開発メンバーが少人数であるため、ライブラリのバージョンアップ対応に追われてしまうと開発業務が進められなくなってしまうからです。かと言ってバージョンアップを怠るとNode.jsのバージョンアップ対応が難しくなってしまいます。量が少なければ対応範囲も狭くなるため、開発の補助用ライブラリも含め、必要最低限になるように選定して対応しています。
また、ライブラリを導入することでCI領域のテストを記載する際、特殊なセットアップが必要になる可能性があります。すると、「セットアップが難しいからテストを書きたくない」という気持ちが強まってしまいます。 CIで守れる範囲が減ると手動テストやE2Eテストの範囲が増えます。テストの負担が増えるとデグレードを見落とす可能性が増えます。これは可能な限り避けたいので、依存対象は最小限に留め、単体テスト・コンポーネントテストの記載に支障が出ないようにしています。
静的解析ツール
LinterはESLintを使用しています。ルールはTypeScript関連とJavaScriptライブラリに関するものを導入しています。フォーマッターはPrettierを利用しています。未経験メンバーがチームに参加することが多いので、余計な指摘を減らすためgit commit直前に静的解析をかけています。この辺りはメンバーの熟練度に合わせて調整したいと考えています。
CI
GitHub Actionsを使用しています。現状はコミット前に静的検査を実施済みのため、アプリケーションビルドに成功するか・テストが全て成功するかを確認しています。
Pull RequestはCIがオールグリーンにならないとMergeできないように設定しています。余計な指摘を減らしてレビュアー・レビュイー相互の負荷を下げるように工夫しています。
CD
一部サービスはKubernetes (K8s)クラスター上で運用しています。各クラスターの管理にはRancherを用いています。その中でRancher FleetのGitOps機能を用いた自動デプロイ環境を構築し、運用しています。デプロイ後はAutifyによる自動回帰テストを実行し、確認作業の手間を減らしています。
この取り組みにより素早く安全なデプロイ作業を実現できています。今はごく一部のサービスしか実現できていませんが、今後は対応サービスを増やしていきたいと考えています。
生産性を上げるための工夫
デザインシステムを用いたUI仕様の決定
フロントエンドエンジニアが中心となってUI仕様を検討する際、全サービスを通して統一性が無くなってしまうことが多々ありました。そこでデザインシステムを整備し、一定のルールに基づいてUI仕様を検討できるようにしました。こちらに関しては過去のブログ記事に記載があるため、合わせてご覧ください。実際に使ってみると、UI仕様の検討にかける時間は三分の一程度に抑えることができています。UI仕様を考える際もデザインシステムを元に考えられるため、迷う時間が減ってとても快適になりました。
テスト駆動開発を用いた手戻り・抜け漏れの防止
関数に対する単体テスト、UIコンポーネントに対するUIコンポーネントテストを用いて仕様の表現やデグレード防止対策を行っています。このときテスト駆動開発（TDD）を用いて開発を進めています。先にテストケースを考えることで、必要な操作やインターフェースの洗い出しを行うことができるため、考慮漏れによる実装のやり直しを防げています。
特にUIコンポーネントの開発は先に一通り書いてしまうと「できあがるまでどのように動くか想像できない」状態に陥りやすくなります。テストを失敗させた後通すよう実装する方法は手戻りが少なく、着実に進捗を出せると感じています。
また、『テスト駆動開発 テスト駆動開発を原点から学ぶ』（Kent Beck 著／和田 卓人 訳 オーム社 2017）で紹介されているように、最初にTODOリストを作るようにしています。TODOをGitHub Issueコメントに記載しておけば日付をまたいでもすぐ開発に取り掛かれますし、先に処理方式の設計レビューを依頼することもできます。
このような工夫を重ねてPull Requestでの指摘や実装の抜け漏れを防止しています。
Autifyを用いたE2Eテストの実施
回帰テストのように、基本的な決まった操作を手動で確認していると時間がかかってしまいます。新機能追加の際などはAutifyを用いてE2Eテストを整備し、ボタンひとつでテストが実行できるようにしています。
Autifyの導入前は開発者の手作業でテストを実施していました。インフラリソースの作成を伴うため、テストには30分から1・2時間程度の時間を要していました。また、作業者ごとにテストの内容や深さにばらつきがあり、品質が担保しづらい状態でした。
Autifyを導入することで、新規機能追加・改修部分以外は登録済みのテストを実行するだけで結果が分かるようになりました。このため、テストの実行時間を他の作業に充てつつ、作業者ごとの品質のばらつきを抑えることができるようになりました。加えて、テストシナリオがUIの操作方法の説明を兼ねているため、新しく入ってきたメンバーもシナリオを確認すれば機能の概要をつかめるようになりました。
機能追加部分は手作業で確認しつつ、Autifyにシナリオを追加して効率よくテストができるように工夫しています。
普段開発やコードレビューで意識していること
会社によっていろいろ考え方はあると思います。IDCフロンティアのサービスは長期的に運用されることが多いので、その点を強く考慮して開発やコードレビューを行っています。
長期メンテを考慮した設計・実装にする
一度リリースするとサービスクローズまで運用するものがほとんどです。常にコード品質はそのとき一番良い状態を心がけています。後で修正すれば良いや、と妥協することは避けています。これはエンハンス開発内容は日付が経つと増えるので、「後でまとめて改善する」という時間は取れないからです。
コードを過度に共通化しすぎると仕様変更時に柔軟な対応ができず困ってしまうことが多いです。過度にDRY原則を適用するのではなく、同じコンテキストの実装が2回以上出てきたタイミングでリファクタリングを行うようにしています。無駄な物を作ってしまうとメンテナンスが難しくなるため、「後で使うかもしれない」と言って汎用的に実装しないように心がけています。
初心者でも読める実装を心がける
未経験のメンバーが入ってくることが多いため、可能な限り初心者でも読める実装を心がけています。ここでの「初心者でも読める実装」とは公式ドキュメントや本で使われる書き方に揃えること・過剰に短縮した書き方をしないことを指しています。
これは学習を始めるときに参考にするものと、実際のプロダクトコードの内容が異なると読み替えが必要となるためです。するとオンボーディングに時間がかかってしまい、中々成果を上げることができません。基本の書き方に揃えておくことで、参考にできるものを増やすようにしています。
また、似たような処理が出てきた場合は既存の実装の処理方針に合わせて記載することを心がけています。コードごとに実装がばらけていると、後から加入したメンバーはコードを書くとき何を参考にすればよいか迷ってしまいます。すると実装速度が落ちてしまいます。既存の処理方針が良くないと感じるときは、関連する箇所を全て切り替えるようにしています。重要なのは好き勝手バラバラに書かないようにすることだと考えています。
どんな方が向いているか
次に挙げる内容が実施できると、とても活躍しやすいかと思います。ただし、今足りていない箇所があっても改善の努力ができるなら全く問題ありません。
全体的な傾向としては指示待ちではなく、自力で業務を推進できる方が活躍されている印象を受けます。これはフロントエンド領域以外も同様です。また、自己改善を繰り返しながら粘り強く取り組めるタイプの方が向いていると感じます。
お客さまの分かりやすさを追及するためにどんなUIがいいか考えられる方
UIの仕様はエンジニアが中心になって決定するため、「言われたことをそのままやる」タイプの方は担当できる範囲が狭くなってしまいます。普段からサービスを使い、「こんな風に改善したらいいのに」と考えるのが好きな方が良いでしょう。自分の提案内容を実装して表現するのはとても面白くクリエイティブな作業だと思います。
より読みやすく保守しやすいコードを書くために自己改善できる方
定期的に仕様変更が入り、改善を繰り返す業務が多い環境です。そのため品質を高めるための努力ができる人が向いています。ひとつのサービスに数年は関わるため、自分自身の成果物に問題があったとき修正することになります。すると、自身の実力を上げて将来楽ができるようにするほうが仕事が楽に進められます。
ドキュメンテーションが嫌ではない方
ドキュメンテーションの機会は多いです。例えば、お客さまが使い方を確認するご利用ガイド、FAQも記載することもあります。 また、アプリケーション仕様や裏側のインフラの操作内容はコード上では表現できないため、文章で仕様をまとめたドキュメントを書くこともあります。
それが無かったとしても、複雑な処理は設計や実装の経緯をIssueやPull Requsetに記載いただくようにお願いしています。これは将来改修する際、過去の経緯が分からないと改修が難しくなってしまうためです。
在宅勤務制度を使う場合、テキストチャットやIssue等を駆使して状況を見える化することも重要です。よって、ドキュメントを書くのが苦痛である場合はあまり向いていない環境かと思います。
他の領域のメンバーとコミュニケーションが取れる方
IDCFクラウドのUIはインフラリソースの操作を代理で実行する役割をもっています。弊社内で開発しているバックエンドAPIを通してインフラリソースの操作を行うため、バックエンドエンジニアとAPI仕様を相談することが多いです。ここでお互いの認識に齟齬があると、開発後に正しくインフラリソースが操作できない・お客さまに見せてはいけない情報がマスキングされない等の深刻なミスが発生してしまいます。UIの仕様はフロントエンドエンジニアが中心となって決めるため、これを第三者でも理解しやすいように説明する必要があります。
また、企画の方や運用・お客さまサポートに関わる方に新しく追加される機能の仕様を説明する機会も多くあります。説明する際は技術的に難解な点を相手の方に伝わるように言い換える必要があります。お客さまからのお問い合わせに対する回答案を作ることもあります。
自分の仕事内容を第三者に説明するのが得意な方はかなり活躍しやすい環境だと感じます。もし、今苦手であっても練習を重ねて改善する気持ちがあれば問題なく業務に取り組めると思います。逆に、説明やコミュニケーションを取りたくない方は他の環境の方が良いかもしれません。
まとめ
以上がIDCFクラウドのフロントエンド開発の全貌です。弊社ではフロントエンドエンジニアも絶賛募集中です。入社後はフロントエンド開発業務を中心に取り組んでいただきますが、興味があればインフラ領域やバックエンド領域等、他領域の仕事にチャレンジできる環境があります。興味がある方は是非、採用ページからのご応募をお待ちしております。カジュアル面談も可能です。
職種内容は「ソフトウェアエンジニア」となっていますが、希望記入欄に「フロントエンド領域の開発を希望」している旨を記載いただければ問題ありません。
もちろん、他の職種の方もご応募お待ちしております。
