FiNCが語る「開発者体験」（DX）の重要性――DXが悪いと生産性ガタ落ち？：FiNCのマイクロサービス開発事例

システムを気持ち良く開発、保守するための「開発者体験」（DX：Developer Experience）に注目が集まっている。なぜ開発者体験が重要なのか。ヘルスケア／ダイエットアプリ「FiNC」をマイクロサービスで開発するFiNC Technologiesの鈴木健二氏が語った。

[石川俊明，＠IT]

　開発者の間でひそかに注目が集まっている「開発者体験」（DX：Developer Experience）をご存じだろうか。開発者体験はこれからのシステム開発、特にマイクロサービスを用いた開発を続けていく上で考えなければならない要素になると、FiNC Technologiesの鈴木健二氏は語る。そもそも、開発者体験とは何か。これからますます重要になる理由とは？　2019年7月に開催された「Cloud Native Days Tokyo 2019」で鈴木氏が講演した内容を要約してお伝えする。

「開発者体験」（Developer Experience）とは

　開発者体験はひと言でいうと、システムを気持ち良く開発したり保守したりするための考え方だ。鈴木氏は気持ちが良い開発（保守）環境の例として以下を取り上げる。

• システム全体の見通しが良い
• 最新のドキュメントがそろっている
• コードの品質が良い
• 技術的負債が少ない、または適切に管理されている
• テストやデプロイを高速に行うことができる
• ライブラリやフレームワークのバージョンが正しく管理されている

FiNC Technologies 開発本部 技術開発部 SREグループ マネージャー兼技術推進グループ マネージャー兼シニアテクニカルリードマネージャー 鈴木健二氏

　「これらの要素を実現できている開発では余裕が生まれ、非機能要件に手を加えられるようになる。例えば、リファクタリングやリアーキテクトなどを検討したり、緊急ではないが重要なことに目を向けたりできる。これを繰り返すことで正のスパイラルが生まれ、開発を気持ち良くするための活動に時間を割ける」

　鈴木氏は、割れた窓を放置しているとそれが当たり前になり、いずれ他の窓も割られてしまうという「割れ窓理論」を取り上げ、「システム開発の開発者体験を良くするにはシステム開発に関わる傍ら、開発者体験が良い状態を維持する活動が大切だ」と述べる。

マイクロサービスにおける開発者体験を考えたときに起きる問題

　ヘルスケア／ダイエットアプリ「FiNC」では、機能の役割ごとにシステムを分割して開発するマイクロサービスを取り入れ、新機能の高速リリースを実現させてきた。だが、システム全体が大規模化するにつれて、違和感を持ち始めたという。それは「開発者体験は開発者だけが対象でいいのか？」ということだ。

マイクロサービスを用いて新機能を高速にリリースしてきた

　「マイクロサービスでシステムを開発する場合の登場人物には、機能開発（Dev）、品質保証（QA《Test》）、リリース（Release）、メンテナンス（DevOps）、セキュリティ（Sec）がいる。つまり、マイクロサービスを用いた開発における開発者体験を考える場合には、開発者体験を拡張して考える必要がある」

システム開発における登場人物

　鈴木氏は、マイクロサービスにおける開発者体験を「DevTestSecOps Experience」として拡張して考えた際に問題になることを取り上げた。

　1つ目は、マイクロサービスを用いた開発において、役割ごとに開発者体験の良い状態が異なることだ。開発する言語の場合、開発担当者は、マイクロサービスで開発する利点を生かして、機能ごとに最適な言語を選択したい。一方で、採用する言語とマイクロサービスの数だけパッチ対応や運用知識が必要になることから、セキュリティや運用の担当者は言語をそろえたい。このようにそれぞれの視点が衝突する。

　2つ目は、マイクロサービスとして切り出すべきか、それとも、共通基盤として開発すべきかということだ。鈴木氏はFiNCにおけるCI/CD（継続的インテグレーション／継続的デリバリー）の事例を紹介した。

　FiNCの場合、開発初期は各アプリがデプロイ設定を持っていたが、インフラ担当者がデプロイ改修を行う際、全マイクロサービスの面倒を見なければならず開発者体験が悪くなった。そこでデプロイを担当するマイクロサービスを作り、共通化した。しかし、開発する言語の多言語化が進んだ結果、担当者以外がソースコードを触れなくなり開発者体験は悪化。サービスが増加し続ける中で担当者がリファクタリングを行うのと並行して新たなマイクロサービスのデプロイに対応するなど、開発者体験は悪化の一途をたどり、再びCI/CDの設定を各アプリに戻したという。鈴木氏は「yamlファイルで記述できるくらい簡単にして分散管理できるようにすべき」と教訓を述べたが、こういった点も問題になるというわけだ。

　3つ目は、大規模化による複雑性の増加だ。開発者やQA視点だと、環境の構築時にはマイクロサービスを複数立ち上げて動作確認が必要になるため、構築難易度が上がる。複数のマイクロサービスにまたがるような機能を開発する場合は、もし芋づる式にサービスがダウンした場合、原因特定に困難が伴う。そして全マイクロサービスにセキュリティパッチを当てたり、ライブラリ更新をしたりする際には、セキュリティ担当者に負荷がかかるというわけだ。

　「マイクロサービスを用いることで最初の開発速度は速かったとしても、これらの問題を考えずに開発を続けると、それ以降の開発速度が落ち、開発者体験も悪化することになる」と鈴木氏は警鐘を鳴らす。

マイクロサービスにおいて開発者体験を向上させる方法

　鈴木氏は先述した問題などを踏まえ、マイクロサービスにおいて開発者体験を向上させる方法の一つとして「ツール（手法）の導入」を取り上げる。

　「影響範囲の可視化や障害時の問題特定速度を向上させ、複数のマイクロサービスにまたがる問題を解決するには『サービスメッシュ』や『分散トレーシング』。サービスが芋づる式に障害を起こさないようにするためには、一つの障害でシステム全体がダウンしないようにする『サーキットブレーカー』。フレームワークや言語、ライブラリのバージョンアップには『カナリアリリース』など開発担当者や運用担当者の開発者体験を向上させるためのツールを導入するのが良いだろう」

参考記事：「サービスメッシュ」「Istio」って何？　どう使える？　どう役立つ？

　FiNC Technologiesでは組織的に開発者体験を向上させる取り組みを続け、RubyやRuby on Railsのバージョンアップに24時間で対応できるようになるなど成果も出てきているという。

　しかし、チームの忙しさやスキルの成熟度によってはこうしたツールをすぐに導入するのは難しい。こうした点は「組織で段階的に取り組んでいくことが必要だ」と開発者体験を向上させるコツを述べ、講演を締めくくった。

　「まずは開発者体験の悪い部分（問題）を可視化する。その部分の粒度をなるべく小さくして開発者体験が悪い状態から0になるまでは組織全体で解決に向けて取り組む。0からプラスにさせるところはサービスを開発するチームごとに動くというように段階的に進めるべきだろう」

開発者体験を向上させるコツ