リンクアンドモチベーション エンジニア広報です。

前回に引き続き、開発責任者の柴戸とSRE テックリードの河野が登壇した「Developer eXperience Day CTO/VPoE Conference 2021」【後編】をレポートさせていただきます。

▼ 「Developer eXperience Day CTO/VPoE Conference 2021」【前編】はこちらをご覧ください

【登壇者紹介】

2016年、弊社リンクアンドモチベーションは、組織改善プロダクト（モチベーションクラウド）を開発・リリース。ARR（年間経常収益）20億円を3年で達成し、現在も毎年110%成長を続けています。開発組織の内製化に舵を切ったのは2018年。社内エンジニア0名から組織を拡大するには、様々な苦労がありました。

前回のストーリーでは、リンクアンドモチベーションが開発組織を内製化していく過程で学んだ Developer eXperience 向上のポイントを3つのうち「不明」の落とし穴についてご紹介しました。
ここからは「風化」と「断絶」の落とし穴についてです。※ 前編はこちら

組織的負債②「風化」の乗り越え方

柴戸：2つ目の落とし穴は「風化」です。負債が生まれた歴史や負債に繋がる意思決定の背景・理由が現開発メンバーに伝わっておらず、「風化」していました。負債が生じた歴史や背景に触れずに、負債が存在していることを「悪」と捉えていたことで、負債を作り出した人と新しく入ったメンバーの間で対立が生まれてしまい、次第に「怒り」という感情に繋がっていきました。

この状況を端的に表しているのが、アメリカのクルーシュテン（Kruchten）氏が整理した技術的タイムラインです。左下の技術的負債が発生した時点では、短期的な犠牲を伴ったとしても、トレードオフをして資産価値を享受している状態です。しかし、右側にシフトするにつれ、徐々に生産性が下がっていき、負債のデメリットが大きくなっていきます。

私たちに起きていたことは、左側（資産価値がある状態）の頃からいた人と、右側（負債となり生産性が下がる）で入ってきた人の衝突でした。

この状況から抜け出すために行なったことは、オンボーディングプログラムの見直しです。オンボーディングプログラムでは、歴史や負債の考え方、負債の種類ごとの返済方針、Good/Badのexperienceの共有、プロダクトのメジャーバージョンアップや組織編成も共有するようにしています。

その結果、負債が生じた歴史や背景も含めて議論できたことで共通課題の理解が深まり、事業と組織に跨がる重要課題として全員で捉えることが出来ました。

組織的負債③「断絶」の乗り越え方

柴戸：最後に「断絶」です。エンジニアとビジネスサイドが自組織に向いており、結果として対立が起きていました。エンジニアはビジネスサイドへ内部品質の重要性を伝えきれず、ビジネスサイドとの相互理解が深まっていませんでした。結果として、双方に悪意は全くない状態ではあるものの、エンジニアとビジネスサイドに「諦め」ムードが漂っていました。

解決方法としては、「共通の目的設定」「客観データの提示」「言語翻訳」の3つを行いました。

まず「共通目的設定」についてです。下図は縦軸が性能、横軸が事業計画上の企業数および時間です。左下「Now」のところから何のアクションもとらず放っておくと、右上「ドクロマーク」の性能になり、結果として解約やクレームに繋がることが想定されます。その影響は金額にするといくらくらいで、その損失を生まないためにはどのぐらいの金額、工数を投資すべきです、など共通の目的に向かって説明することを心がけています。

このように共通の目的が設定されていると、解約率上昇による損失額や必要な人的リソースなどをビジネスサイドにも理解してもらいやすくなります。

次に「客観データ」です。例えば「テストコードは必要？」という疑問については、「手動テスト4回で自動テストのコストを上回る」、「内部品質への投資は一ヶ月後に結果として現れる」というデータをもとに回答することができます。また、ビジネスサイドへの説明だけではなく、自分たちの組織でも説明ができていない現状があると思います。コードの改善が本当に投資した時間と労力を正当なものにするか、これはエンジニアが常に自分に問いかけなければならないことです。

最後が「言語翻訳」です。前提として、ビジネスサイドとエンジニア間で言語や思考の違いを認め合うことが大事だと思います。具体例として「AWSの長期停止」を「JRの全線停止」に例えてビジネスサイドへ分かり易く説明をしたり、「セキュリティリスク」なら「防犯カメラの未設置による盗難」を例に出したりするなど、相手の知っているものに置き換え伝えました。

このように少しずつ壁を乗り越えて、エンジニア自身の事業理解も進み他部門との関係も改善されていきました。

まとめ：幸せを感じられることこそDeveloper eXperienceの本質

柴戸：まとめになりますが、まず技術的負債と組織的負債は表裏一体です。これを前提に負債の見える化と優先順位付けをした結果、組織的負債になっていた「不明」は「Measure（計測）」、「風化」は「Respect（尊重や尊敬）」、「断絶」は「Integrate（統合）」と、カルチャーの転化を行いました。

その結果、組織状態の偏差値（エンゲージメントスコア）は77、DX Criteriaも42.5pt、テストカバレッジは90％と大幅に改善しました。

環境や仕組みも重要ですが、それ以上に一人ひとりが成長や貢献を感じ、周囲から尊重・尊敬されることを実感できる日々を過ごせることが大事です。

これが幸せな開発者体験、Developers eXperienceを生み出すことだと思っています。

私たちは組織のプロフェッショナルとして今日ご紹介させていただいたカルチャーをこれからも大切にしていきたいと考えています。

【お知らせ】
Developer eXperience Day CTO/VPoE Conference 2021で
登壇した資料は Speaker Deck にて公開しています！

定期的にMeetupを開催しています！
Link and Motivation Engineer Meetup

開発組織やプロダクトについてまとめています！
Entrancebook for engineer.