バックエンドエンジニアにフロントの案件をお願いして並走開発の末に気づいたこと

はじめに

この記事はペライチアドベントカレンダーの22日目の記事です。

こんにちは。株式会社ペライチ 開発エンジニアのKOTAです。
日頃はフロントエンドエンジニアとして開発業務に勤しんでいます。

ペライチでは各人の技術力向上のため、自身の担当職種以外の領域へのチャレンジを積極的に行っています。ペライチ社内ではこれを多能工化(multi-skill development)と呼んでいます。

上記活動の一貫として、弊社のバックエンドエンジニアが技術力向上のため、フロントエンドの開発案件に取り組むことになり、開発サポートとして筆者が並走開発を実施しました。

本記事では、「バックエンドエンジニアにフロントの案件をお願いして並走開発の末に気づいたこと」として、まだまだ教育体制などのフローが明確に存在しないベンチャー企業において、手探りでバックエンドエンジニアがフロントエンドの案件を進めてみて気づいたことをポエム的な記録として残しています。

「新人教育という訳ではなく、通常業務を行いながら各エンジニアメンバの多能工化を進めたいんだよな」というチームの参考になれば幸いです。

なお、ペライチの技術スタックや開発体制については、弊社CTOの香月が書いたペライチ開発チームのご紹介に詳しく記載されていますので事前にご一読いだければ幸いです。本記事の内容も上記開発体制を前提として記載しています。

また、一緒に並走開発をしたバックエンドエンジニアのあずまもアドベントカレンダーにあずま的ディスプレイ選定という記事を投稿していますので、よろしければぜひ。

何はともあれ、まず最初にやったこと

フロントエンドの案件をバックエンドにアサインしてからまず真っ先に実施すべきことは「何がわかって、何がわからないのかを確認し、細かな実装上の仕様を詰める打ち合わせを実施すること」でした。

振り返りとしてバックエンドエンジニアのあずまに感想を聞いてみたところ、

• （HTML/CSS/JavaScriptは読めるといえば読めるので）力づくで既存のソースコードをコピペして動かそうとするが、動かない。
• （フロントエンド開発の勘所がないので）質問しようにも何を質問すればいいかわからない。
• （一緒に詳細要件を決めるMTGを実施するまでは）メンタル的に不安な部分があった。

という状態だったとのこと。私としても「お互いに忙しいし、私自身も受け持っている案件あるから、そもそもあまり時間も作れないし」など考えて、実装してもらったPRベースでレビューを進めれば良いかと最初考えていた節がありました。

「ドライバとナビゲーターを決めてペアプロをやろう」や「とりあえずPR出してもらってレビューベースでやればいい」というお話ではなく、真っ先に実施すべきは「何がわかって、何がわからないのかを確認し、細かな実装上の仕様を詰める打ち合わせを実施すること」でした。

改めて振り返ってみれば、至極当たり前のことといえば当たり前のことですね。

実際にやってみたことと、振り返り

実際にやってみた内容と振り返りを記載しています。
重要だったポイントはほとんど①に集約されていると感じています。

①一緒に実装仕様と開発スコープの策定

前述した通り、一番最初に実施した内容です。
実施内容をまとめると下記の通りとなります。

• １:要件を元に結合テストのテストケースを書いて貰い実装仕様をすり合わせる。テストケースを元にしてフロントエンド固有の実装で注意すべきポイントもインプットしてしまう。
• ２:テストケースを元にして、実際の修正ファイルレベルまで認識を合わせてPRの粒度も決める。
• ３:HTML/CSS/JavaScriptの前提知識がある程度ある場合は、フレームワーク固有のざっくりとしたルールの共有にとどめ、コーディングルールレベルの細かいインプットは後述するPRベースで実施する。

3つ目の項目について補足すると、今回お願いしたフロントエンドの案件は

• JavaScriptはBackbone.js + jQueryの入り混じったSPA
• HTMLはphpフレームワークのView部分とBackboneのテンプレートに必要に応じて記述
• CSSはsassで記述し、CSS設計はFLOCSSを採用

という比較的レガシーな技術領域のフロントエンド開発であり、且つCSS設計でBEM記法を利用したり云々などの、プログラミングというよりは、フロントエンド独自の知識や社内のコーディングルール周りのインプットが必要でした。そのため、最初にざっくりとしたルールの共有を実施しました。

②PR(PullRequest)単位でのコードレビュー

「①一緒に仕様と開発スコープの策定」で決めた実装スコープとPRの粒度に基づいて作業を進めてもらいました。
PRレビューを実施した際のポイントは下記です。

• 1:MUST(必須)やIMO(私見・提案)の箇所を優先してレビューする。
• 2:フロントエンド独自のルール（特にCSSのclass命名ルールやHTMLマークアップ等）についてはNits(些細な指摘)で後出しでコメントしつつ、キャッチアップしてもらう。

最初に作業スコープとテストケース、PRの粒度を決めていたおかげでPRのレビューはつづがなく進行できたと感じています。

③ペアプロ

ペアプロは、都度必要に応じて実施しました。

ただ、一般的に言われるような「ドライバとナビゲーターを決めたペアプロ」は、職能の違うエンジニア同士では上手く機能せず、PR単位でのコードレビューの方が効率的であったように感じています。

やり方が悪かったのか、お互いに忙しくしていて落ち着いてできなかったのか、スクラムゴールとして適切に設定すべきだったのか、等々振り返りを行いながら今後も試行錯誤していきたいところです。

④一緒に検証、一緒にバグ潰し

最後はもちろん、検証とバグ潰しです。
PR毎と最後の結合フェーズで適宜一緒に検証していきます。

今回実際に実装をしてみて遭遇したバグケースとして

• 利用しているプラグインによって付与されるtabindex属性によって、その他のプラグインの挙動が阻害されてしまう

といった事象がありました。

フロントエンドエンジニアであれば、挙動の不具合があったときに、CSSかJavaScriptか？はたまはた、DOMに付与されている属性値などか？などと開発ツールを使って原因を絞り込むことは日常茶飯事ですが、バックエンドエンジニアにとっては慣れないものらしく、

CSSまたは、モーダルのJSの処理がバッティングしている？という点までは思考できそうなもんですが、、tabindexの干渉に踏み込むのが自分じゃできなかったなと思いました。

と振り返ってみて感想を貰いました。

検証方法やバグの見つけ方、アクセシビリティに関する知見は一緒に検証しながら都度インプットするのが地味ながらも最適だなと感じた次第です。

さいごに

サーバサイドのエンジニアにフロントの案件をお願いして気づいたことというよりは、慣れない領域を一緒に並走開発してみた振り返りになってしまいましたが、何かしらの参考になれば幸いです。

また、弊社CTOの香月がアドベントカレンダーの記事内で書いていた

ペライチは技術的なトライができてプロダクトを通した社会貢献できる、そんなテックカンパニーを目指しています。

上記の雰囲気の一端が少しだけでも記事から伝われば幸いです。