これはモチベーションクラウドAdvent Calendar 12日目の記事です。
エンジニアとして働いていると技術的負債に悩まされたことはあるのではないでしょうか。技術的負債は開発を継続する中で発生した「理想とかけ離れたコードの状態」を指した比喩ですが、どこの開発現場でもサービスを継続する上では少なからず存在するものだと思います。
特にプロジェクトの期間が長くなってきたり、開発メンバーが増えてくると技術的負債の問題が大きくなってきます。組織構造や開発体制によって技術的負債の扱いは変わると思いますが、以下の理由で中々改善が進まない場合があります。
技術的負債のジレンマ
捉えどころの難しい技術的負債という概念
技術的負債と言ってもそれが具体的に何を表していて、どのぐらいのボリュームがあるのかを把握するのは中々難しいのではないでしょうか。代表的な負債であれば、全体のうちどの部分が複雑化していて、どのような改善を行うべきなのかは思いつくかもしれませんが、その改善の効果がどの程度あるのかを定量的に説明するのは将来の要件を予測して見積をするようなものでほぼ不可能でしょう。結果的に工数の見積や実際にコードに手を入れる際にバッファを設けたり、調査工数に時間を設けたりします。
非エンジニアと技術的負債について議論する難しさ
技術的負債というものをエンジニアも漠然と捉えているので、非エンジニアにも中々上手く伝えることができません。そのため、エンジニアと非エンジニアでは問題の大きさや優先順位の認識が揃わず、お互いストレスを抱えてしまいます。
このままでは技術的負債の返済は見送りとなり、「開発速度の低下」という形で徐々に問題が大きくなっていき、最終的には多大な工数をかけてシステムの大改修や再構築するなどの対策を打つ必要が出てきたり、改修コストと予算が見合わなければサービスを停止するなどの恐れもあります。
技術的負債についてさらに詳しく知りたい方はエンジニアリング組織論への招待を読むことを強くお勧めします。
技術的負債に立ち向かうための取り組み
では、私たちはどのようにこれらの問題に立ち向かうべきなのでしょうか。
ここからは、私たちが実際に行なっている施策について一部をご紹介します。
技術的負債を見える化する
まずは技術的負債という得体の知れないものをテーブルの上に上げるために見える化する必要があります。そのため、Code Climateというコードの品質を計測するためのツールを導入しました。
Code Climateでは複数の言語をサポートしており、循環的複雑度など10点の検査項目で特定した技術的負債によってA〜Fのランク付けをしてくれます。以下はサンプルコードで出した結果ですが、Code Climateのサマリー画面になります。
また、それらの問題解決にかかる時間を"修復時間（remediation time）"として予測値を算出してくれます。機能の詳細はここでは割愛しますが、これはコードの品質についてチームで共通認識を持つためだけでなく、開発サイドとビジネスサイドで改善の必要性を議論する上で役立ちます。
メンバー同士の物理的な距離を近くする
私たちの開発チームは社内のエンジニアだけでなく、複数のパートナー企業とフリーランサーも多数参加しています。このような多種多様なメンバーがいる開発組織だと物理的に距離が近いことで話しかけやすくなり、信頼関係の構築に繋がります。後述する様々な施策を打つにあたり、この信頼関係はとても重要な役割を果たします。
メンバー同士で問題意識を共有する
開発チームが増えてチームが分かれた頃にチーム間での連携や思想の統一が難しいことがありました。そのため、週に１回各チームのメンバーが集まり、問題になっている事や改善したい事について共有する場を作りました。私たちはこれを「改善MTG」と読んでいますが、例えば以下のような事を議題として取り上げてきました。
- コンポーネントの設計思想について
- ライブラリの導入可否やアップデートのタイミングについて
- リファクタリングをいつ・どのように進めるかについて
- LinterやCIの設定変更について
議題をもとに問題の優先順位を話し合い、解決に向けたアクションを"宿題"としてタスクに追加します。宿題は次のMTGで進捗確認にして、当初の問題が解決されればクローズします。
時にはモブプログミングを行い、各メンバーの知識共有も行いました。
最初はフロントエンドメンバーのみで始めましたが、最近ではプロジェクトマネージャーやバックエンドエンジニアも一緒に参加するようになっています。
改善する時間をつくる
最近では開発チーム全体での改善活動も始まりました。これは「改善Day」と呼ばれ、隔週に１日の改善の期間を設けます。この時間は各々が普段感じている問題の対処に時間を使って良い日です。この時間を使って、宿題として登録されたタスクをこなしたり、後回しにしていた負債コードの改修にあたります。
また、この改善Dayは能動的に参加してもらうために強制にはしておらず、スケジュールの都合などで普段の開発タスクを優先する事も可能としています。
バグをドラゴンと呼ぶ
技術的負債が溜まってくるとバグの発生率も上がりますが、エンジニアにとってバグ対応は心理的な負荷が高いものです。"バグ"という言葉はエンジニアに精神的ダメージを与え、結果的に生産性の低下に繋がる恐れがあります。※もちろん、バグを出してしまったエンジニアにも責任があることは重々承知しています...。
そんな中、とあるメンバーの発案で"バグ"を"ドラゴン"と呼ぶことにしました。また、バグのインパクトに応じて"しんりゅう"、"リザードマン"、"ドラゴンキッズ"というドラクエ譲りのラベルを付け、バグ対応にあたるエンジニアを"ドラゴンスレイヤー"と名付けるようにしました。彼らをサービスを守る勇者であると開発チームで讃えることにしたのです。これによって、開発現場で"バグ"という言葉がほとんど使われなくなりました。
モチベーションクラウドのエンジニアリングチームでは、バグや障害を「ドラゴン」と呼ぶことに決め、奴らを倒すものに伝説の剣を与えるという文化が生まれたそうです。 pic.twitter.com/MV7wu4Al6t
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) November 16, 2018
終わりに
技術的負債への取り組み方は各々の開発現場で様々な工夫をされているのではないかと思います。
上記の取り組みは私たちが現在行なっているものであり、今後も状況に応じて変化させていく可能性は十分にありますが、モチベーションクラウドの開発チームはサービスだけでなく、組織を大事にする文化があります。引き続き、より良いサービスの改善に向けて組織で一丸となっていきたいと思います。