システム開発を内製化する企業が増える一方、さまざまなトラブルに見舞われプロジェクトが停滞してしまうケースが後を絶ちません。今回は、危機的状況が積み重なり続けていたサービスを復活させることに成功したエンジニアのエピソードをご紹介します。サービスを成長させ続けていくことのむずかしさ、一人のスーパーエンジニアではどうにもならないこと、チーム創りがいかに重要であるかがよく分かるお話です。
D.O氏プロフィール：新卒で入社したSES企業にてシステム運用と検収を6年以上経験する。システム運用の中で培われた視点を持ち味とし、それを開発に活かせるエンジニアになりたいという思いから、2016年に情報戦略テクノロジーに入社。現在はお客様社員のエンジニア以上に事業を理解し、事業会社でのシステム開発の在り方を模索している。
増え続ける技術的負債と、業界知識を持つエンジニアの離職
ー D.O氏が参画されているプロジェクトについて教えて下さい。
介護事業者の経営全般をサポートするSaaSの開発プロジェクトに参画しています。
その中で私のチームが担当しているのは、システムの中核である「介護報酬（介護するのに掛かった費用）の計算と請求」。インフラの管理以外、ほぼすべて対応しています。
ー プロジェクトの課題について教えて下さい。
介護報酬の計算ルールは、介護のサービスが多種多様であること、各自治体ごとの独自ルールが蔓延っていること、制度自体が複雑怪奇であることから、理解が非常に難しいものでした。
それに加えて定期的に訪れる介護保険法の改正という巨大な敵と戦い続ける必要があります。端的に言うと、非常に複雑な計算ルールが年度ごとに変更になり、しかも過去分の請求を行うためにすべての計算ルールを共存させる形で実装を行わなければならないという、非常に攻略難易度の高いものです。
法律に則ってお客様の業務もアプリも動かないといけませんので、アプリ側の法改正対応が遅れるとお客様の業務が連動してストップします。最悪の場合、倒産させてしまうという大きな責任を伴う仕事でした。
そのような状況下の中、最優先事項だったのが、機能追加によるユーザーの獲得と迅速な法改正への対応。どちらもスピードが必要でしたので、ありがちではありますが、コードのメンテナンス容易性や拡張性を完全に無視した開発が行われていました。
ー さまざまな課題を無視し、スピードを重視することで、どのような問題が起きていたのでしょうか。
当然のようにコードはスパゲッティーと化し、1つのデータベースを多数のシステム間で共有するという圧倒的な強依存も発生、レガシーシステム化もどんどん進み、結果として軽微な修正すらも満足に行えないような状況に陥っていました。
特にデータベースの共有が引き起こしていた事態が酷く、ユーザーがログインすることもままならないような深刻な性能問題にも何度も直面しました。
アプリは当然のようにいつでも動いていないといけないので、その当たり前の状態を実現するため、新規機能の開発（価値提供の追加）を長期間ストップしなければならないという事態に陥ってしまいました。
ー そのような問題に対し、どのような対策をとっていたのですか。
初めの一歩は、サーバーをオンプレからAWSへ移行するというアクションでした。
瀕死状態のシステムに対して延命措置を行うということが最大の目的であり、アドホックに高性能インスタンスを使うことで急場を凌げるようなインフラを目指しました。もちろん、中長期的な目線でシステムの立て直しを行うことが大前提です。
結果として、致命的なサービス停止はなんとか回避できるようになりましたが、やはりサーバー費用には悩まされますし、課金することで手に入れられるサーバースペックには限度がありますので、常に追われているかのような感覚でした。
また悪いことというのは重なるものでして、ほとんど同じ時期に業務知識を潤沢に持つ古参のエンジニアが次々に離職してしまい、致命的な業務知識の流出に頭を悩まされることになったのです。
ー 業務知識を持つエンジニアがいなくなることで、どんな問題が起きていたのですか。
「次回の法改正は本当に乗り切れるんだろうか？」
「失敗して会社が傾く可能性あるから転職を考えたほうがよいのでは？」
といった不穏な空気が全体に漂ってしまっていました。そう皆に思わせるほどに、コードの修正難易度が高かったのです。
巨大かつ複雑怪奇なコードが目の前に鎮座しており、しかもそのほとんどが開発者の意図を全く表現しておらず、これまでメンテしてきた人間以外には全く内容が理解できませんでした。昔の自分は「奇跡で動いている」と本当に思っていました。
また、仮にコードの修正が行えたとしても、そもそもこのアプリをどう育てれば良いかを判断することができませんでした。法律の改定と、それを自分達のアプリがどう表現するかはまた別の次元の話です。これまではそれを決断できる人材が在籍していましたが、もう彼らに頼ることはできないのです。
「チーム一丸」の状態を創り出すことで、危機的状況の解消に成功
ー この危機的状況を、D.O氏はどのように捉えていたのでしょうか。
「技術的負債の返却」「パフォーマンス改善」「業務知識の取得」が主なテーマだったのですが、これらは決して個人の問題ではなく、あくまでも組織としての課題となりますので、チームメンバーの全員が一丸となって課題と真摯に向き合うことが大事だと考えました。
「業務知識」は一朝一夕で身につくような分量ではありませんし、「パフォーマンス改善」に関してもボトルネックを可視化できる仕組みを取り入れるところからのスタートです。
「技術的負債の返却」ついても、非常に多く存在する改善点の中から、重要度やコストパフォーマンスの高いものを選定し、一つ一つを丁寧に進めていく必要があります。その他にも可読性、表現力の高いコーディングや、法改正を前提とした拡張性を考慮した設計の知識も必要でした。どれもそれなりに高いレベルのスキルが必要とされます。
またアプリの持続可能性を考慮すると、特定の誰かだけがこれらの課題を解決できる状態では意味がありませんので、日頃からチーム力の向上につながるタスクを実行していました。
ー 具体的にはどのような取り組みをされたのでしょうか。
例を挙げると、チームに足りていないと思われる技術の勉強会を業務の一環として実施したり、モブプロを行うことで設計やコーディングスキルの全体的な底上げをはかったり、ドキュメンテーションを意識的に行い、それを共有する時間をちゃんと設けたりしていました。
チーム内で議論を重ねたことで知識レベルの標準化が行われ、結果として質の高いコーディングやレビューの効率化に繋がりました。
法改正に対してのアプローチで言うと、ユーザーストーリーマッピングがとても効果的であったと記憶しています。非常に密なコミュニケーションの中から共通認識が生み出される感覚はとても刺激的で、その刺激が記憶の定着にも寄与したのではないかなと思っています。
それと、これは個人的にバリューが出せたかなと思っている点なのですが、運用チームとの親睦を深めて、開発チームと運用チームの架け橋のような存在になりました。
自分が運用出身であることから、彼らの関心ごとや温度感が本当の意味で理解できるので、信頼のおける関係になるまで時間はかかりませんでした。世の中には 開発 vs 運用 みたいな構図も多いかと思いますが、DevOpsの改善ループを高速で回していくためには、お互いに協力しあうことが不可欠です。
運用チームの人たちは、本当にユーザーを悩ませている課題やニッチな仕様などを熟知していますので、その観点を仕様や設計に盛り込むことによって、より質の高い開発を行うことに繋がったという実感があります。
あと、これは本当に悔しいのですが、特定のシチュエーションにおいては「運用回避」のような手段も取り入れる判断をしないといけないことがあります。このような場合においても、お互いを仲間だと思っていれば、関係者全員がその課題を自分ごととして捉えられますので、たとえどちらかのチームに負荷がかかるような判断をしても、それが原因で関係性に歪みができるなんてことには絶対になりません。
自分が所属するチームのことだけではなく、関連をもつチームすべてとの関係性を意識的に作っていくことの大切さを学んだエピソードでした。
前人未踏「介護法改正前にアプリリリース」に成功
ー チーム一丸となったことで得られた成果エピソードはありますか。
私がメインで開発を担当した法改正の対応になりますが、法改正の適用より前に対応版アプリのリリースを達成することができました。史上初です。笑
これまでは、法改正にアプリが対応できるまでデータ入力を控えてもらったり、本来はアプリで簡単に作成できるはずの帳票類を手書きで作ってもらったりと、最悪の体験をさせてしまっていたので、それを回避できたことが本当に嬉しかったです。
深いドメイン知識が支える改正内容の理解と、それを仕様へと落とし込むスピード、アプリのコード理解が導く効率的かつ正確なコーディング、チームで取り組んできた勉強会の成果が生み出した高速で精度の高いレビューとテストがこのような結果に繋がったと思っています。
サービスの成長に必要なのは、チームリーダーの「ミッション理解」
ー お伺いしてきたこと以外に、重要なポイントなどありますか。
サービスは順調であれば事業と共に成長を続けていくもので、エンジニアはそれをテクノロジーで支え続けるという責務を持ちます。エンジニアは会社の持つビジョンや、それを実現するためのミッションを正確に理解している必要があると思っています。そしてそれが仕様検討や設計判断、技術剪定の軸になるべきだと考えています。
例えば「3年後にはアクティブユーザを2倍にしたい」というミッションがあったとして、
● きっとこんな機能を追加したほうがフックになりそう
● 今のDBの負荷状況だと2倍は耐えられないから性能改善に本気で取り組むべき
● このクラスに手が入る可能性が高そうだから、積極的にリファクタリングをしておこう
● まだ3年以上稼働することが確定しているから、レガシー改善をちゃんと計画に練り込もう
のような、抽象から具象にするようなことを本気で考えて実行する姿勢が大事かなと思います。端的に言うと「業務委託だけど社員になった気持ちで働きます」ということです！
お客様の事業の成長に貢献し続けるために、本気で学び、本気で考え、本気で実現させるという姿勢を崩さずに、日々邁進していこうと思いますので、今後ともよろしくお願いします！
執筆者
リビルダーズ編集部
