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

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

【Developer eXperience Dayとは？】

一般社団法人日本CTO協会が主催するオンラインカンファレンスです。「“開発者体験”で世界をエンパワメントする1日。」 と題して、ソフトウェアサービスの開発に携わるリーダー、マネージャー、プロダクト・マネージャーなど、チームや組織の課題に日々取り組む方々に向けて開催され、約2,500名が事前登録されました。

【セッション概要】

2021年4月10日(土) 17:00~ Stream E

【登壇者紹介】

2016年、弊社リンクアンドモチベーションは、組織改善プロダクト（モチベーションクラウド）を開発・リリース。ARR（年間経常収益）20億円を3年で達成し、現在も毎年110%成長を続けています。

開発組織の内製化に舵を切ったのは2018年。社内エンジニア0名から組織を拡大するには、様々な苦労がありました。今回は、当時のリアルなエピソードも交えながら、Developers eXperience実現のポイントと具体策をご紹介します。

はじめに：技術的負債と向き合うことから始まった内製化の道

柴戸：株式会社リンクアンドモチベーション（以下、LMI）で開発責任者をしている柴戸純也と申します。私がLMIに入社した当時、開発組織が内製化されておらず私以外のエンジニアは全員開発パートナーでした。開発組織の内製化を目指すという方針で一人目のエンジニアとして参画したのですが、開発組織の実態を把握していく中で、技術的負債が多くあることに気が付きました。

まず、プログラミング言語を深く理解できる社員がいない状態で、複数の開発パートナーが入れ替わりながら開発していたため、ソースコードは解読困難な状態でした。
組織状態は悪化しており、従業員のエンゲージメント状態を表す指標（エンゲージメントスコア）は開発組織全体で43.1でした。これは「社内を歩けば退職希望者に出会う」ような危機的な数字です。他にも、「DX Criteriaのシステム評価」は27.5、「テストカバレッジ」も0%など、課題が山積みの状態でした。

この状態から、私たちがどのように開発組織を内製化し、Developer eXperienceを向上させたのか、３つのポイントに分けてお話ししたいと思います。

前提：技術的負債と組織的負債は表裏一体

柴戸：３つのポイントの話に入る前に、前提をお伝えします。技術的負債の裏側には、組織的負債も存在しているということです。

技術的負債とは、デッドコードが存在している、規約や指針がなく責任者不在の状態になっているなど、現在の開発作業を阻害する要因のことです。今は「負債」と捉えられていないコードも数年後は「負債」になっている可能性をはらんでおり、負債を一回返済して終わりというものではありません。

次に組織的負債は、部門間の対立や、組織の方針と個人のやりたいことの不一致など、組織の運営や人の活動を阻害する要因のことです。これは仕組みや制度だけで簡単に解消できるものではありません。例えば、人事制度や仕組みを整えたとしても、自分を理解してくれない上司や同僚の言葉は響かず、モチベーション向上に繋がらないことは多くあります。つまり組織的負債も制度や仕組みを整えたら上手くいくというものではないのです。

この技術的負債と組織的負債は切り離して考えるべきではなく、表裏一体で捉える必要があります。

ここで、表裏一体のメカニズムについて整理してみます。

この図を見てわかるように、実は技術的負債の裏で組織的負債が発生しています。特例対応のはずなのに、それが繰り返されて「言ったことと違う」となったり、責任者不在が続いて不満や不協和音が蔓延してしまう状況です。相互関係があることを理解し、技術的負債や組織的負債ともに解決していくことが非常に大切です。

技術的負債の裏側にある組織的負債を落とし穴としたとき、それが何でどうやって乗り越えたのか？

私たちの開発組織も2018年当時は、「不明」「風化」「断絶」といった3つの不協和が渦巻いていました。これらをどのように解消していったのか、1つずつ解説します。

組織的負債①「不明」の乗り越え方

柴戸：まず、1つ目の「不明」です。当時は、闇雲に目の前の技術課題を解決していました。目指すゴールや目標も曖昧で、改善活動に計画性や持続性がありませんでした。結果、負債の全体像が「不明」の状態が続き、「不安」という感情が湧き上がり、生産的な活動を阻害していました。

河野：ここからは、SREチームのテックリードである河野が、「不明」の状態をどのようにして乗り越えたかについてお話しさせていただきます。

ここに有名な「ブレーメンの音楽隊」の図があります。

一見、何でもない動物たちが恐ろしい化け物に見えてしまいますが、この状況は技術的負債のメタファーとして考えることができます。技術的負債の正体が明らかになれば、決して恐ろしいものではありません。

私たちはこの技術的負債を解決するために、「見える化」「優先順位付け」の2つのステップを踏みました。

まずは「見える化」です。私たちの現状を知るために科学された客観的指標を採用しました。指標には『LeanとDevOpsの科学』という書籍で紹介されていたデプロイ頻度、リードタイム、平均修復時間（MTTR）、変更失敗率の4つのメトリクスから構成される4つのキーメトリクスを採用しました。

あわせて、日本CTO協会が提供している「DX Criteria」に信頼性と品質の項目も加え、全部で15個のメトリクスを策定しました。これらを「開発組織メトリクス」と名付けて開発組織全体の共通の改善指標と目標にしました。

続いて「優先順位付け」です。「見える化」によって自分たちの現在地を知れましたが、改善すべき箇所が多く、対応優先順位をどのように関係者間で合意するかという問題が出てきました。

そこでモチベーションクラウドでも利用しているマトリクス「4eye’s」を活用することにしました。これは横軸を「ケイパビリティ」、縦軸を「期待度」とした意思決定のためのマトリクスです。「ケイパビリティ」とは、開発組織がもつメトリクスの状況を指します。開発組織メトリクスの数字から、自分たちの組織能力がどのレベルにあるかを表します。「期待度」とは、開発責任者や事業責任者といった開発に関わるステークホルダーからのメトリクスごとの期待の度合いを表します。「ケイパビリティ」と「期待度」のマトリクスから、左上を「弱み」、右上を「強み」に置き換えることができます。

これによって「優先度は高いがケイパビリティは低い」など、弱みの部分を優先的に改善する意思決定がしやすくなります。

実際にプロットしたBeforeの図がこちらです。

弱みを中心に、どのメトリクスを改善させて強みに転化するかを決め、四半期ごとに各チームや個人の目標設定に落とし込みました。その結果、弱みに位置していたメトリクスを強みに転化することに成功しました。

闇雲に改善を繰り返していた状況から、狙って改善できるチームへ進化したという手応えを感じました。表裏一体である技術的負債の裏側にあった組織的負債を改善できたと実感しています。

その結果、浸透したカルチャーとしては...

1つ目が、負債返済の目標を設定することです。改善のゴールや目標が曖昧で貢献の実感が持ちづらい状況から、改善が楽しいという勢いを作ることができました。

2つ目は、負債を課題やバックログとして捉えることです。技術的負債という言葉を使わずに、可視化して課題やタスクに落とし込むことが習慣になりました。

3つ目が、技術課題の優先度が明確になり「いつやるのか？」という不安がなく納得感を持てるようになったことです。一気にすべてを改善しようとせず、優先順位を決めて取り組んだことで、戦略的に改善ができるようになりました。


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

次回の【後編】レポートでは、「風化」と「断絶」の落とし穴についてお伝えします。

【お知らせ】

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

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

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