目次
はじめに
はじめまして、フロントエンドエンジニアの鵜木(うのき)です。
弊社では現在、生産性の向上を目的に Motivation Cloud (以下 MC)のフロントエンドをリアーキテクトしています。今回はこのリアーキテクト活動の背景やここに至るまでの経緯をご紹介したいと思います。
新しいアーキテクチャの設計内容や採用した技術スタックに関する紹介は別記事で行います。なので本記事はこれからアプリケーションレイヤーの大規模改善を検討している人向けになります。
ことのきっかけ
リアーキテクト活動が始まったきっかけは、フロントエンド横断組織(通称 フロント会*1 )メンバーの開発モチベーション低下が発覚したことです。その時のコメントを一部ご紹介すると、
- 「実装ルールに沿っていないコードに新しいコードを追加する機会が多く、場当たり的な実装がどんどん増える」
- 「場当たり的な実装をしている自覚を持ちながらも、そうせざるを得ない状況になっている」
- 「この状況を改善するための活動をするにも、既存コードが整理されてない(場当たり的な実装が多い)ので、コストが高くなり実現可能性が下がる」
等々の声が上がりました。
上記の問題は短期間の部分的な改善では解決できないため、フロントエンド領域を横断的に管理しているフロント会が中長期的な改善を推進していくことになりました。
改善提案のためにやったこと
コストの高い改善活動は事業への影響が良くも悪くも大きいため、現場起因で活動を始める場合は、上位層への提案活動が必要になる機会が多いかと思います。
弊社の場合も例外ではなく、エンジニアリングマネージャーや事業責任者への提案活動を行いました。その際に実施したことを紹介します。
解決する課題を決める
「生産性を向上させたい」と言い動き出しましたが、生産性の向上に効きそうなアクションが多数ありました。なのでこのタイミングで「自分たちが生産性の向上のために、解決すべき課題はこれだ」というものを定めました。活動開始してから「何を解決すべきかわからない」といった事態を避けるためにも、この時点から課題を設定しておくことがおすすめです。
可能なら生産性を定量的に分析した上で課題を設定したいですが、既存コードの状況によっては分析コストが高いことも有ると思います。その場合はそのプロダクトの開発に関わりの深いエンジニアの定性的な意見から課題設定をして良いと思います。
プロトタイプを作る
解決すべき課題を決めたので次に課題の解決方法を考え始めましたが、この時点では何を作るかが殆ど決まってない状況でした。なので いつ/誰が/何を/どうやって 進めていくのかが全く想像できない(戦略が立てられない)事態となりました。
そこでプロトタイプを作り、戦略作りに必要な情報を先にそろえる方針で作業を進めました。小規模の改修であればプロトタイプなしでも戦略を立てられるかもしれません。ただある程度の規模になると、何を作るかの見立てがないと戦略作りが困難であることを実感しました。
戦略を立てる
解決すべき課題と何を作るかの大枠が決まったので、次に戦略作りました。ざっくりとですが今回は以下の流れで戦略作りを進めました。
- プロトタイプを参考にタスクを分割する
- 各タスクに対して、そのタスクを遂行できるメンバーを選定する
- 他プロジェクトが予定している今後の開発項目をキャッチアップする
- いつ/何を/どうやって 開発するのかを検討する
ここでは4つ目の工程が肝になりました。特に "どうやって" の部分については大きく下記2パターンの方法が上がりました。
- リアーキテクトチームを作り開発を進める
- 他プロジェクトの開発に便乗して開発を進める
弊社ではこの2つの方法を、開発対象や状況に応じて使い分けながらリアーキテクトを進めていきます。ただ戦略上で主軸となる進め方は2つ目の "他プロジェクトの開発に便乗する" 方法にしました。
その際に重要視した観点は「他PJTへの影響」です。他PJTへの影響が大きいと調整コストが上がり、実現可能性が下がります。実現可能性の低い戦略は効力が著しく下がるので、今回は "他プロジェクトの開発に便乗する" 方法を主軸としました。
アウトカム目標を設定する
アウトカム目標とはいわゆる成果目標です。弊社でもこのリアーキテクト活動によって得たい成果をアウトカム目標として設定しました。指標と目標値の具体的な内容は控えますが、今回のリアーキテクト活動では Quality/Cost/Delivery に沿った内容のアウトカム目標を設定しました。
成果目標と言うと、成果へのコミットメントを求められることを連想して抵抗のある人もいるかも知れません。ですが、目指す目標がないとその活動(今回で言うリアーキテクト活動)がうまく進んでいるのか、を確認する指標がなくなりPDCAのサイクルをうまく回せません。なので設定することをおすすめします。
提案する
最後に、ここまで準備した戦略とアウトカム目標、そして活動の背景をセットにして関係者に提案しました。弊社の場合は主に事業責任者とエンジニアリングマネージャー陣になります。
できるだけ他PJTへの影響が小さい戦略を選んだとはいえ、影響を0にできない以上調整が必要な場面が来ます。その際、円滑にコミュニケーションを取れるよう、関係者への提案を行いました。
さいごに
文章にするとスムーズに進んだように見えますが、本当は途中で何度も頓挫しています。(実際は一度提案に失敗してから周囲の協力を得て上記の行動を取りました笑)
今回、MCのフロントエンド領域におけるリアーキテクト活動について、活動の開始から提案までを取り上げましたが、今後は採用した技術スタック等々の記事を展開していく予定ですので、興味の有る方はブックマーク等々よろしくお願いします。