レガシーシステム・技術的負債の分類とDiverseがどう向き合っているか
レガシーシステム技術的負債 とは何かDiverseの関わり方
View Slide
who?● さむけい（藤田 雄大）● 所属はDiverse Inc. / MAEMO LLC● youbrideのサーバ・クライアントやってます● DroidKaigi 2019に登壇します！PWAの話します！https://droidkaigi.jp/2019/● 会社でPodcast配信してます。聴いてください！https://podcast.diverse-inc.com/
オンラインカジュアル シリアスオフライン
レガシーシステム技術的負債に悩まされているという方
みなさん悩んでいますね！
では、レガシーシステム技術的負債とはなんでしょうか？
レガシーシステムとは？(wikipedia引用)レガシーシステムとは、主にコンピュータの分野で、代替すべき新しい技術などのために古くなったコンピュータのシステムや技術などのことである。そのようなデバイスをレガシーデバイス、そのようなオペレーティングシステムを、レガシーOSなどともいう。
技術的負債とは？(wikipedia引用)技術的負債とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。「設計上の負債」とも言う。
ざっくり・古いシステムなどレガシーシステム・設計ミス or 設計のないソフトウェアを技術的負債ということで、悪いっぽいですね。
本当にそうでしょうか？
古いシステムということは枯れている(安定している)ということではないの？
当時は設計が適切であっても時代の流れに取り残されたら技術負債になるよね？
モヤモヤしてきましたか？
モヤモヤしてきましたね？
でも、レガシーシステム技術的負債にはみなさん悩まされていますよね？
では、レガシーシステム技術的負債を”課題”と捉えてみるとどうでしょうか？
みなさん”課題”を”解決”することは好き(面白い)ですよね？
じゃあ、レガシーシステム技術的負債という”課題”を”解決”することは、 面白いことじゃないですか！？
ということで、Diverseがどのようにレガシーシステム技術的負債という”課題”と向き合っているかを話します！
では、Diverseにおけるレガシーシステム技術的負債の”課題”を元に分類してみます
インフラ● オンプレミス● 2013年にリプレースしたままの環境(youbrideの例)○ ホスト環境のOSが古い○ 仮想環境のOSが古い○ 仮想環境内のソフトウェアのバージョンが古いアプリケーション
インフラ アプリケーション● サーバサイドの言語がPerl● 開発キャパを超えた仕様変更による改修
分類ができましたねそれぞれの課題の詳細とアプローチを考えます
● オンプレミス● 2013年にリプレースしたままの環境(youbrideの例)○ ホスト環境のOSが古い○ 仮想環境のOSが古い○ 仮想環境内のソフトウェアのバージョンが古いインフラ アプリケーション
オンプレミスの課題オンプレ = 悪ではありませんが、● 即時のスケールアップが難しい● 開発環境の増設なども保守会社への問い合わせが必要といった点がプロダクトの成長にネックになっています。
オンプレミスへのアプローチ開発を円滑に進めるためにAWSなどのクラウドへの移行を進めています。オンプレミス環境を一気に全部移行することは出来ません。そのため、機能単位でクラウド環境に移行を計画しています。現在は、STFからAWS S3に移行をしています。
2013年のままの環境の課題重大なセキュリティパッチのみ当てる運用になっていたため、● 重大なセキュリティリスクはないがソフトウェアが構成が古い● なので、メジャーバージョンアップには設定ファイルのマイグレーションも必要になる● 結果、アップデートが難しいという状況になっています。
2013年のままの環境へのアプローチ社内の文化と体制に問題があると考え、● 上長に現状の課題を認識してもらう● 認識してもらった上で、社内にSRE部隊を整備することに同意してもらうという、課題を解消するための組織作りを始めています。
● サーバサイドの言語がPerl● 開発キャパを超えた仕様変更による改修インフラ アプリケーション
サーバサイドの言語がPerlの課題Perlは年に1回アップデートされており、メンテナンスされています。そのため、Perl = レガシーではないと個人的には考えています。ただし、● 言語のシェアが減っており、Perlでの求人活動はすごく難しい● 社内に第一言語がPerlの人が少なくなったという課題を抱えています。
サーバサイドの言語がPerlへのアプローチ(youbrideの例)求人活動の課題はクリティカルになっているため、積極的にPerlから別の言語に移行する作業を進めています。youbrideではWeb/API双方が必要なため、マイクロサービス化は考えずにフルスタックなフレームワークを持つRubyへの移行を現在進めています。(仲間募集中です！)
開発キャパを超えた仕様変更による改修の課題設計や実装や単体テストへの対応の時間がないことによって1. 安易に巨大なBaseクラスが作成される2. 便利だけど黒魔術的なUtilityが大量に作られる3. Modelが強すぎて後から単体テストが難しいなどの課題が生まれていました。
開発キャパを超えた仕様変更による改修へのアプローチ１(youbrideの例)● カンバンでのタスクコントロールを行うタスクを見える化し、1スプリントで実施できるタスクを明確にすることでキャパシティを超える開発をしないように調整しています。
開発キャパを超えた仕様変更による改修へのアプローチ２(youbrideの例)● 設計方針はチームで認識をあわせてから簡易なドキュメントを作成巨大なBaseを作らないなどの意識を統一しながら進めています。ただし、どんなに設計をしても時代が変われば合わなくなっていきます。放置せず適切な形にメンテナンスし続けることが大事です！！！！
全然語り足りていないので懇親会でぜひ話しましょう〜
おわり
samukei
takahashikazutaro
motok1
nttcom
shao1555
bengo4com
bun913
kenmatsu4
aiji42
safie_recruit
megabitsenmzq
robots
miura55
bryan
chriscoyier
paulrobertlloyd
keithpitt
holman
tammielis
zakiyama
aleyda
stephaniewalter
jonrohan
dougneiner