技術的負債の解消を困難にする「組織的負債」
株式会社Works Human Intelligence(以下、WHI)は、国内の人事パッケージ製品市場において高いシェアを持つ統合人事システム「COMPANY」を開発・提供する企業。COMPANYは約1200の大手法人グループに採用されている統合人事システムで、初代バージョンがリリースされてから既に20年以上が経過している歴史ある製品だ。
人事・給与・勤怠などの分野を中心に、これまで数多くの企業の基幹業務を支え続けてきた同製品だが、歴史が長いが故の課題も徐々に顕在化しつつあると萩田氏は語る。
![株式会社Works Human Intelligence Product Div. DX Squad Grp 萩田篤氏](http://cz-cdn.shoeisha.jp/static/images/article/17576/17576_0.jpg)
「COMPANYは20年以上にわたって価値を生み出してきた製品ですが、長年にわたり増改築を繰り返し、その都度個別最適を繰り返してきた結果、製品の複雑性が高くなってしまい、技術的負債がかなり蓄積していました」
機能を実装した当時は最適解だと思われた方式も、時間の経過とともに陳腐化してしまい、現在では技術的負債となってしまったコードが多く存在していた。そのためコードに変更や修正を加えようとするたびに多くの手間と時間をとられ、開発生産性が下がっていた。
![私たちの製品・組織の歴史(技術的負債)](http://cz-cdn.shoeisha.jp/static/images/article/17576/17576_1.png)
またこうした技術的負債があまりにも蓄積されており、開発部門単独では問題を解決できず、どうしても他部門や経営陣の協力を得る必要があったが、コードだけでなく会社の組織体制も実態とそぐわなくなっていたため、なかなか身動きが取れない状況だった。萩田氏はこうした状況を「組織的負債」と呼び、技術的負債とあわせて解決する必要があると感じていたという。
「組織と担当業務との間にミスマッチが生じていたり、組織体制からこぼれ落ちていたタスクを現場のボランティア活動に依存し続けていたりするなど、組織面でもさまざまな課題を抱えていました。こうした課題が長らく放置されてきた最大の原因としては、やはり現場と経営との間に距離があり、問題認識に食い違いが生じている点が大きかったと思います」
たった4人の改善活動が全社規模に拡がるまで
そこで萩田氏ら社内有志が集まり、これら技術的負債と組織的負債を返済しながらより良い開発者体験(Developer eXperience)を実現しようと行動を起こした。それまで社内の各所で個別に改善活動を繰り広げていた同志を集め、2021年にまずは4人のグループで活動を開始。手始めに少数の開発者にヒアリングを実施し、現場が抱えている課題を可視化する取り組みを始めた。
やがてこの自主活動は7名体制のチームへと発展し、日本CTO協会が作成したDX進捗度を評価するアセスメントシート「DX Criteria」と照らし合わせながら自社のデジタル化の現状を客観的に評価する取り組みに着手した。その結果、DX Criteriaの基準から大きく乖離していることが判明した。
この結果を受け、早急に状況を改善する必要があると判断した萩田氏らだったが、当時の組織体制では実行力のある改善活動を進めるのは困難であると思われた。その理由について同氏は次のように述べる。
「全社規模の観点からリソースを最適配置して利益の最大化を図りたい経営と、自分たちの組織が持っているリソースを活用して効率よく業務を遂行したい現場とでは、戦っているフィールドが根本的に異なります。そのため、現場視点の改善と全社規模の最適化を同時に実現するには、両者を橋渡しできる『組織全体の課題解決に責務を持つ組織』を作る必要があると考えました」
![トップマネジメントと現場でゲームが違う](http://cz-cdn.shoeisha.jp/static/images/article/17576/17576_2.png)
そこで萩田氏らが経営陣に働きかけた結果、2022年に新たな組織「プロダクトDMO」が発足する。早速この組織を中心に、社内の開発者全員を対象にアンケート調査を実施し、現場の課題を拾い上げて可視化する取り組みを始めた。記名式のアンケートだったにも関わらず300件近い回答が寄せられ、これらの内容をプロダクトDMOで精査した後に優先順位を付けた後、実際の改善活動に取り組むことになった。
開発者体験向上のための取り組みの数々
プロダクトDMOが実施した施策の1つに、「開発案件管理の改善」があった。これまでは開発案件の計画を半年ごとに作成していたが、案件ごとの優先順位を決めていなかったために予想外の事態に直面しても柔軟に計画を変更することができず、結果的に開発現場に多大な負担が掛かっていた。そこで事前に優先順位を決めてその内容を誰もが閲覧できる形で公開するとともに、社内のさまざまな改善活動を行うための工数も一定量確保するようルールを作った。
また社内の組織編成も開発作業の実態と乖離しており、実際の開発作業で必要な役割や権限が各組織で正式にアサインされていなかった。そのため現場によるボランティア作業に依存する部分が多く、これも開発者体験を低下させる一因となっていた。そこで開発作業で必要な役割を持った「組織の箱」をあらためて用意し、きちんと工数を可視化・測定できる仕組みをつくった。
![取り組みの紹介](http://cz-cdn.shoeisha.jp/static/images/article/17576/17576_3.png)
開発者が利用するシステム環境についても、PCスペックを向上させたり、オフィスの環境をフリーアドレス化したりするなどして、より快適で生産性の高い開発環境を整備するよう会社側に働きかけ、その実現にこぎ着けた。さらにはソースコードの管理をGitHub上で行えるようにしたり、ソースコードの静的分析ツール「SonarQube」を導入したりして、コードの品質管理をより効率的に行える環境を整備した。
チケット管理システムの改善にも着手し、非効率な現行システムを最新のSaaSアプリケーションに置き換える取り組みを進めている。そのほかにも、新人研修や中途採用者向け研修の改善や書籍購入補助、資格習得補助といった教育施策の改善、製品リリースのスピードアップのために自動テスト導入やCI/CD改善、製品のサポート対象バージョンの削減など、開発者体験を向上させるための全社的な取り組みを部署一丸となって進めている。
大規模開発を行う組織だからこそ、相手に寄り添った説明を
なおWHIは現在約1700人の社員を抱え、約500人の開発者がCOMPANYの開発に携わるなど、大規模な開発体制を敷いている。こうした組織において開発者体験の向上を図るには、大規模特有の難所を乗り越える必要もあったという。特に、現場と経営の間に入って改善活動の有効性を双方に理解してもらうためには、説明の仕方にもかなり工夫を凝らしたと萩田氏は話す。
「例えばGitHubを導入した際には、経営に対しては投資対効果や生産性向上、人材採用における効果、社員のロイヤリティ向上といった経営の関心事に沿って効果を強調する一方、現場に対しては開発者にとっての利便性が向上することを具体的に説明するなど、それぞれの立場に寄り添った形で導入効果を説明するよう心掛けました」
また一口に「現場」と言っても、各組織が抱える事情によって導入のモチベーションは異なる。そのため現場の意向を無視して強引に導入を進めるのではなく、現場が必要性を感じたときにすぐサポートできる準備を整えておく方針とした。また自分たちも一緒に手を動かして導入を進めるとともに、導入作業や現場への展開状況をSlackのパブリックチャンネルなどを通じて広く公開することで、より導入メリットが社内に広く伝わりやすくする工夫も凝らした。
![現場と経営をつなぐ](http://cz-cdn.shoeisha.jp/static/images/article/17576/17576_4.png)
加えて、社内のセキュリティ管理部門やガバナンス担当部門とも積極的に連携し、「相手を論破して強引に突破する」のではなく「一緒に環境を良くしていこうとする協力者」という姿勢を積極的に示すことで協力を得ることができたという。
2022年のプロダクトDMO発足から約1年の間でこうした活動を展開していった結果、現在では目に見える形でさまざまな効果が現れるようになり、多くの社員がこれらの開発者体験向上の取り組みに高い関心を払うようになってきたという。
「かつては各組織がサイロ化していましたが、現在では互いに有機的なつながりを見せ始めており、それぞれ個別に行ってきたものが相互に関連し合い良いサイクルができてきました。また開発組織以外の組織との良好なつながりも生まれつつあります。当初は小さな取り組みから始まった活動でしたが、いろんな方々の協力を得ながら進めてきた結果、現在では継続的に改善を続けながらより大きな目標に手が届くようになったと感じています」(萩田氏)