組織改革として実施したこと

はじめに

現在フロントエンドチームのメンバーとして、業務をさせていただいています。
その業務において、携わらせていただいているプロジェクトソースはスパゲッティコード・大きな泥団子の塊のようなもの（今はだんだんと改善してきています）で、割れ窓で言うと崩壊寸前のビルの１歩手前をギリギリで支えているような状況となっています。

前回書かせていただいた Nuxt バージョンアップの記事においても、そのソースが進捗に影響したことも事実としてあります。

今回は、そのようなレガシーシステムに対して実施した改革内容について、記事にまとめようかと思います。
レガシーシステム自体は、どの企業でも存在するものだと思ってもいるので、そういった方々に読んでいただけたらと思っています。

どのようにしてそのようなソースが誕生したのか

こちらに関しては、僕自身の憶測になってしまいますが、原因は下記などがあるかと思っています。

• 機能拡張だけを考え、ソースを完成させる（アーキテクチャや各レイヤーなどは無視）
• それぞれのメンバーがそれぞれの思想で実装
• 単純な技術力不足（コードモンキーのメンバーが多い）
• 「動けばOK！」な精神での実装方針

上記、書いてみて改めて感じることとしては、ほんと恐ろしいですね。。
とは言いつつ、開発スケジュールも短かった背景もあったらしいので、どうしようもない部分もあるにはありますが、、
最終的に、しっかり動くものは出来上がりますが、中身のソースに関しては、もう理解不能なアルゴリズムが書かれている箇所もたくさんあったりして、メンテナンスができないものがあったりします。
また、最悪なことに僕がプロジェクトに参画させていただいたときには、すでに本システムを誕生させたメンバーは全員いませんでした。。。

組織改革を行う前の事前準備

チームメンバーへのヒアリング

改革を行う際に、僕自身だけで考えて行動しても、それは僕だけの自己満足になってしまいます。
そのため、メンバー全員に今のフロントチーム組織に対する課題をヒアリングしました。
ヒアリング結果はマインドマップ形式でまとめ、それぞれのメンバーがどのような不満や考えなどがあるかを細かくまとめました。
（マインドマップ自体はモザイクをかけさせてもらってます:bow:）

ヒアリングした結果、それぞれのメンバーがどんな課題を感じていてどう思っているのかが可視化でき、改革する上での非常に良いヒントになったので、こちらは実施して本当に良かったと思っています。

チームリーダーへ連携

こちらは、当たり前っちゃ当たり前ですが、業務とは別で改革などの準備等を行うため、しっかり連携をする必要があります。
また、連携する際にリーダーならではの視点で質問や指摘等が入るため、こちらも必ずやったほうがいい内容だと自分は感じています。
指摘を受けた内容で、確かにその視点も重要だな〜と思ったのが下記になります。

• 今回実施する改革をするメリットを IT リテラシーがない部長などに報告する際、どのように報告するのか
• 報告する人の気持ちになって伝え方を工夫した方がいい

上記のような点も考えて改革内容の準備を進めていきました。

実施した組織改革

結論から言うと、実施した改革の内容は下記です。

• PR レビューを2次レビューまで行う
• 開発基準書の作成
• フロントエンド定例会議の内容変更

PR レビューを2次レビューまで行う

今まで、PR レビューは1人のレビューが通れば Approve となり、マージしていました。
ただ、それでは開発者もレビュアー者も不安が残る形でマージされることとなり、デグレになりうる可能性がありました。
また、「本当にこの実装でいいのか」といった不安も残ってしまうようになり、自信を持ったマージができない状態が続いていました。
そこで、レビュアーをもう1人増やすことにより、少しでも不安を減らしたり、実装内容を最低でも2人が知ることになるのでメンバーの複数が実装内容を把握するといったメリットがあります。
そのほかにも下記のようなメリットがあると思っています。

• 複数人のレビューが入るので、漏れが発生しにくい
• レビュアーは他の人のレビュー観点に気づける
• いろんな人の実装の観点を吸収できるので技術力が上がる
• いろんな人の観点でコメントが入るので、議論が起きやすく、コーディング規約が充実していきやすい

逆にデメリットとしては、下記になります。

• 複数人のリソースを割いてしまう

開発基準書の作成

こちらは、「それぞれのメンバーがそれぞれの思想で実装してしまう」を改善するために用意した資料になります。
また、開発基準書自体は別チームでも実施しており、そちらがとてもいい取り組みだと感じたのもあって導入させていただきました。
開発基準書にまとめた内容の具体的なものとしては下記となります。

• プロジェクトの使用パッケージ一覧
• プロジェクトで使用するスクリプト一覧
• ディレクトリ構成
• Vue / JavaScript / TypeScript / Sass / Css の開発ルール
• 開発時のヒントになるような辞書

（今では反省していますが、こちら1人で作成し、ものすごい時間と労力を持っていかれました。。。w）

開発基準書におけるメリットは下記になるかと思っています

• ソースコードの統一感が増す
• どう書けばいいかの辞書代わりになる
• 単純に総合的に技術力が上がる（と思っている）
• 職能横断にも影響する（バック・インフラメンバーのキャッチアップ材料になる）

逆にデメリットとしては下記になります。

• 単純に作業量が増える
• ルール等を覚えるのが大変
• 資料のメンテナンスが発生する

フロントエンド定例会議の内容変更

毎週、プロジェクトに関わるフロントエンジニアメンバー全員で定例会議を実施しているのですが、こちらの内容が薄っぺらい内容でした。
と言うのも、プロジェクト自体には課題だらけなのですが、改善をしたくても機能拡張等の納期を守る必要があり、改善活動ができなかったため、話すとしても「こうゆうのしたいよね〜」のような理想論を語る会議にしかなっていなかったため、内容が薄くなっていました。
そのため、会議の内容を根本から変えるような取り組みを実施すべく、下記を実施するようにしました。

• 開発基準書を学ぶ
  • 資料を全員で覚えるため、1つ1つ確認する時間を設けるようにする
  • 資料に対し、違和感があるところを指摘し合う
• 誰かの対応した PR をメンバー全員でレビューする
  　　* 実装した内容を全員で把握する
  　　* なぜ、その設計で実装したのかを確認する
  　　* 実装内容でいいソースなどがあれば開発基準書に追加する
• 1ヶ月に1回、LT会を定例の時間で開催する
  • 技術に対する好奇心を刺激する
  • どんなことをやったのかのアウトプットの場を設ける

上記の内容を実施することにより、理想論を語るではなく、現状の課題やメンバーそれぞれの技術レベルと向き合う場を設けることができました。

実施後の効果

PR レビューを2次レビューまで行う

こちらは、メリットもすごく感じれたのですが、デメリットである「複数人のリソースを割いてしまう」がすごく影響を出しました。。
また、レビュアーのメンバーに偏りが出てきてしまうのも問題点となりました。
偏りが出てきたりすると、レビュアーのタスクの進捗が全然進まないことが発生し、残業でカバーするような運用になるなど、放ってはおけない問題につながってしまいました。
そのため、2次レビューの方法を下記に変更することになりました。

• 1次レビューは AI に任せる（変更点）
• 2次レビューはメンバーが実施する

AI に任せるに関しては「PR Agent」を使用するよう、そちらのツールを導入しました。
こちらはメンバーでは気付けないような指摘もあったりするので、とても良いツールだと思っています。
ただ、たまに見当違いな指摘も入るため、もう少し精度が向上するのを待っていたりしてますw

上記の変更によってデメリットである「複数人のリソースを割いてしまう」が解消され、また2次レビューまで実施できるといった運用にできました。

開発基準書の作成

こちらに関しては、とにかくメンバー全員の労力が必要となり、なかなか開発基準書の内容を覚えられないといった問題がありました。
そのため、ルールを守った開発が行われない状態が長い間続きました。
メンバー全員に簡単にヒアリングしてみたところ、基準書自体が安心材料になるといった良い結果もありましたが、開発している中でルールを確認するのが大変・覚えられないといった言葉もありました。

上記のことから、下記を実施してもらう・実施するようにしました。

• 基準書の各開発ルールにおいて、勉強会を開いてもらう
• 開発ルールにおいては、Lint でカバーするように設定する

1点目の勉強会に関しては、メンバーから提案があり、確かに勉強会を開かない限り今の現状を変えることはできないなと思いました。そのため、素晴らしい提案をいただけたと思っています。
2点目に関しては、ESLint / StyleLint など、静的コード解析ツールを駆使して、「開発ルール」の量を減らすようにし、メンバーの負荷を少しでも減らすようにといったものです。
ただ、Linter のルールを変更するとソース全体に影響を出すものもあったりするため、より慎重になって対応を実施しなければなりません。

フロントエンド定例会議の内容変更

こちらに関して、実施してみたところ、下記の点次第でそれぞれのメンバーの取り組み方が変わるといったことを痛感しました。

「メンバー自体において、技術に関心・興味があるか」

技術に関心・興味がないメンバーは今回の改善内容から逃げるようになったりしました。
例えば、「誰かの対応した PR をメンバー全員でレビューする」では、その人自体の PR を絶対見ないようにうまく会議を回していたり、「1ヶ月に1回、LT会を定例の時間で開催する」では、業務が忙しいという理由で発表しなかったりと、とても残念でした。。。（ちょっと文面が悪い感じになってるかもです）
エンジニアであるのに技術に関心・興味がないは、もうどうしようもないことなので、個人的には手の施しようがありません。
ただ、プロジェクトの改革としては行ってほしいことではありました。（この点に関しては一番頭を抱えました）

メンバーそれぞれの技術に対する価値観が知れたのはとても良かったことですが、受け入れ難い事実と向き合うことにもなった機会となりました。
今回の改革の取り組み自体は現状も継続しています。

まとめ

今回行った組織改革は改革の入り口に過ぎません。
まだまだやらなければならないことはものすごく多くあります。
ただ、改革を実施するには相当な労力が必要です。
自分に関しては、業務の隙間時間を見つけ次第取り組んでいたり、土日を使って準備をしていたりしました（←）

組織改革に関しては、誰かがやるのを待つでは一生実施されません。
また、実務の中で根本を変えるような取り組みはできないとも思っています。

1日でも早くレガシーシステムから脱却できるよう来年も頑張っていこうと思います。
なので、来年のこの時期に取り組んだ内容のアウトプットもしようかなと思います。

今回の改革自体の実施はやれて本当に良かったとすごく感じているので、もし、こちらを読んで影響された方がいらっしゃったら、是非とも何かしらの改革をやってみてはいかがでしょうか？（本記事の改革内容は何かしらのヒントとして利用していただければです）

最後まで読んでいただきありがとうございました！