20年モノの巨大Webサービスの開発継続戦略 - ミドルウェアのバージョンアップとの向き合い方

PHP Conference Japan 2021 の登壇資料です。

Transcript

1. #phpcon ©2021 RAKUS Co., Ltd. 20年モノの巨大Webサービス の開発継続戦略 - ミドルウェアのバージョンアップとの向き合い方 - やなせ たかし
2. #phpcon 自己紹介 なまえ：やなせ たかし MailDealerというサービスを開発しています ややこしいことを中心に設計したり実装したり 好きな言語：Scala コンパイラが優秀なのと、型システムの温度感がちょうどいい 趣味：楽器/茶・コーヒー/香/自転車/… 節操なくたいてい沼にハマる
3. #phpcon セッションの前に • 本セッションはレガシーシステムネタです • 開発者としてベストなノウハウを提示するものではありません • 現実と戦う方法をお話します • ゴールは、今を生き延びることです • 「ミドルウェア」は長いので、「MW」と表記します • 内容にはフィクションを含みます
4. #phpcon お品書き • 開発はずっと続いていくもの • MWのバージョンアップがつらい理由 • 開発を継続するための戦略 • 事例紹介 • まとめ
5. #phpcon 開発はずっと続いていくもの この章で話すこと • なぜずっと続くのか • 開発は何を求められているのか
6. #phpcon なんで開発は続いていくの？
7. #phpcon ビジネスの一部だからです
8. #phpcon なぜここでビジネス？ • サービスが売れるかどうかは、企業(組織)の生存に直結する ◦ 企業の関心ごとはサービスが持っている「価値」 • 企業は存続に命を懸けるもの ◦ 利潤追求のためには当然企業の存続が前提 → つまり、サービスも売れ続けなければいけない
9. #phpcon サービスの持つ「価値」
10. #phpcon お金を稼ぐ力
11. #phpcon ユーザーにとっても「価値」があるから
12. #phpcon 開発と「価値」 開発という仕事を「価値」を軸に考えてみます • 価値を増やすための開発 ◦ ビジネスを成長させる ◦ 新機能や機能向上が目に見えてわかる • 価値を落とさないための開発 (改善) ◦ サービスの価値は上がらない ◦ 脆弱性対応、MWのバージョンアップやリファクタリングが該当
13. #phpcon こんな経験はありませんか？ • なかなかリファクタリングできない ◦ そんな暇あったら新機能の一つでも作れば？ • 技術的負債のことをわかってもらえない ◦ それをしてなんになるの？ • いつまでも化石のようなシステムを保守している ◦ いい加減作り直したほうが早い
14. #phpcon なんでこんなことが起きるのか • すぐにコストを回収できない • コスト外のメリットの可視化が難しい • 開発組織への信用の低下
15. #phpcon すぐにコストを回収できない • ユーザーにわかる変化がない ◦ ソースがきれいになっても、それ自体は見えない ◦ 大幅な高速化など、わかりやすいものは受け入れられやすい • 改善している間は、新規の価値を生み出していない ◦ これは機会損失だととらえられても仕方ない
16. #phpcon コスト外のメリットの可視化が難しい • すぐにコストを回収できない ◦ 当たり前だけど • 将来的な価値の算出・評価は困難 ◦ ともすればただのポジショントークにしかならない ◦ 本当に工数がいままでの半分になるの？ ◦ 本当に不具合件数がN％下がるの？
17. #phpcon 開発組織への信用の低下 • 積み重ねの恐ろしさ ◦ 過去十数年分の技術的負債 ◦ 何度も過ぎる納期 ◦ 年々増加する不具合 • 開発組織以外からはつらさが見えにくい ◦ 専門分野以外は誰しもそのようなもの ◦ 開発組織もゆでガエルになっているケースもありうる
18. #phpcon 組織全体としてのお気持ち • 開発組織に余裕がない、開発が上手くいっていない ◦ 曰く、リファクタリングすれば取り戻せるらしい ◦ 開発速度、品質も向上するらしい ◦ それらしい見積もりはあるが、コスト回収は数年、売上には影響しない • しかも、抜本的な改善の間は新機能の開発が滞る ◦ その間に競合に差を付けられるかも • それならば「価値」の向上を優先したい
19. #phpcon 改善のハードルは高い • 組織は「価値」の向上を優先したい ◦ 「価値を下げない」ための期間は「価値」を向上するチャンスを奪う ◦ 改善は「価値」に直結せず、すぐにコストを回収できない ◦ そもそも改善のメリットを評価できない • 実は組織全体の問題 ◦ システムの疲弊のリスクが安く見積もられている ◦ こまめに改善できる組織はレガシーシステムになりにくい
20. #phpcon 例外があります
21. #phpcon MWのバージョンアップ
22. #phpcon MWバージョンアップと「価値」 • やらないと明確に「価値」が下がる ◦ 修正されない脆弱性を突かれて情報流出 ◦ そもそも売れなくなる • つまり「やらないときの損失」がわかっている • 損失を回避することで「価値」がうまれる
23. #phpcon つまり必要になったということ • レガシーシステムの現場ではよくあるのでは • 改善そのものの価値が認められたのではない点に注目
24. #phpcon MWのバージョンアップがつらいわけ この章で話すこと • つらいこと • 逃げられないこと
25. #phpcon 前章のおさらい • 「価値」とはお金を稼ぐ力 • 開発リソースは「価値」の向上に使いたくなりがち • コードをきれいにすることは「価値」を向上させない ◦ と思われている ◦ 少なくとも簡単に見積もれない • 改善は、差し迫った損失を避けるモチベーションで承認される ◦ そして私たちはそれを改善のチャンスと誤解しやすい
26. #phpcon よくあるつらみ • 影響も規模も大きすぎて途方に暮れる ◦ 全ソースが対象なんて当たり前 • 問題が大きいのに期間が短い • 過去の作業の経験がのこっていない ◦ 数年に一度だったりするため • ソースの改善個所が多すぎてあれもこれも不安になる • つらいプロジェクトになりそうで怖い
27. #phpcon 認識のギャップに気づく • 今必要なのは「MWのバージョンアップ」 ◦ 抜本的な改善じゃないんですよね • だから、大きなコストはかけられない --------- ここにギャップがある ----------- • 開発チームの眼前には問題が山積みのソースコード ◦ 長年積み重なった技術的負債 • せっかく直せるのに・・・
28. #phpcon もう手遅れなんだ・・・けど • 今もそのレガシーシステムは「価値」を生み出している ◦ これは紛れもない事実 • どうしたってEOLはやってくるし、そこからは逃れられない • 今ある諸問題は、これまで解決できなかったもの ◦ 同時に対応するには荷が重すぎる
29. #phpcon とりあえず生き残る
30. #phpcon とりあえずでいいから生き残る システムが生きていれば・・・ • ご飯が食べられる ◦ 少なくともいきなり路頭に迷うことはない • 今回の知見が手に入る ◦ 役に立つ経験になるはず • 次のバージョンアップまでの時間が手に入る ◦ その間に手を打つ
31. #phpcon 開発が続けばチャンスは来る • チャンスとして生かせるかは組織に依存する ◦ あきらめも必要かもしれない • とはいえ改善させてもらえるよう努力は必要 ◦ 今のままでは厳しいことを開発組織外にも理解してもらう ▪ システムが限界なので直したい ▪ 長年の技術的負債で開発が厳しくなっている
32. #phpcon 開発を継続するための戦略 この章で話すこと • MWバージョンアップを乗り切る戦略 • 具体的な作戦立案 • 相手を知る
33. #phpcon まずは言葉の定義から • 戦略 ◦ 組織の目標達成へ向けた大局的・長期的な視点での計画 • 作戦 ◦ 戦略をどのような手段で実行するか ◦ 戦い方・シナリオとも言い換えられる • 戦術 ◦ 作戦遂行の具体的手法 ◦ 勝ち方とも言い換えられる
34. #phpcon 戦略
35. #phpcon 戦略 • 大局的な視点で策定される ◦ たとえば企業単位、サービス単位 • 上位の組織の戦略に縛られる ◦ 今回のケースだと、「価値」の向上を第一とする • 今ケースで考える戦略は、開発チームとしてのもの ◦ 好き勝手はできない
36. #phpcon 戦略を考える必要性 • 開発チームとしては上位の戦略に従う ◦ だから選択できる戦略はそう多くない ◦ それは普段もそう変わらないはず • 規模が普段と違うので、開発チーム全体の戦略を考える ◦ 基本的には「普段通り」やるのがベスト ◦ しかし、規模の見積もりが難しい
37. #phpcon 条件を検討する 前提 • 開発は継続する • 「価値」の低下は避ける 自分たちの現状 • リソースに余裕はない • 長年の問題が山積している
38. #phpcon 戦略立案 • 普段の開発 ◦ 組織の戦略である「価値」向上を進める ◦ いつも通り進める • NWのバージョンアップ ◦ 組織の戦略を妨げないようにしないといけない ◦ 普段の開発への影響を最小に抑える
39. #phpcon 作戦立案
40. #phpcon 状況整理 チームの状況 • リソース・時間に余裕がない • 通常開発も並行しているため、それを止められない システムの状況 • 長年の問題が山積している • 影響範囲が広く、テストが大量に必要
41. #phpcon 大まかな方針 • 人的リソースは効率的・効果的に使う ◦ 最小限のメンバーでバージョンアップをやり切る ◦ テストは過大な工数が必要なので、工夫が必要 • 通常開発を止めない ◦ 「バージョンアップ」に関する作業は最小限に
42. #phpcon 作戦立案 通常開発への影響を最小限に抑えるためにどう戦うか？ • バージョンアップ作業は最速で終わらせる • 修正は最小化する • 並行している開発案件をバグの洗い出しに活用する • 出た不具合はバージョンアップ担当メンバーが逐次修正
43. #phpcon 作戦立案 バージョンアップ作業は最速で終わらせる • 通常の開発を止める時間を最小化するため ◦ バージョンアップ中の作業が止まると、チーム全体が止まる ◦ 時間がかかるほど影響が大きくなるので重要
44. #phpcon 作戦立案 修正は最小化する • 修正箇所が多いと普段の開発と衝突しやすい ◦ 大きな変更ほど追加の修正が困難に • バージョンアップ以外の修正に囚われることを避ける ◦ 改善の気持ちになっているがぐっとこらえる ◦ 限られた期間を有効に活用する
45. #phpcon 作戦立案 並行している開発案件をバグの洗い出しに活用する • リソースの有効活用 ◦ もちろんテストはするが、全ソースの全パターンなんてテストできない ◦ レガシーシステムは思い切りもある程度いる • 修正による影響の周知 ◦ 挙動の変更などを身をもって知ってもらう
46. #phpcon 作戦立案 出た不具合はバージョンアップ担当メンバーが逐次修正 • リソースの有効活用 ◦ 知識も豊富なはず
47. #phpcon 相手を知る
48. #phpcon 相手を知る • 具体的に戦術を考えるには、相手を知ることが重要 • 未知の相手は怖いが、既知の相手は対処法を考えられる ◦ たとえ大量でも無限より有限のほうがいい ◦ この時点で戦術が不要になることもままある • 問題はなるべく分割するべき ◦ 複数の問題を一度に解決するのはつらい ◦ シンプルなほうが解決しやすい
49. #phpcon 事例紹介 この章で話すこと • PostgreSQLの事例 • PHPの事例 • PHPで実際に使った戦術の紹介
50. #phpcon PostgreSQL
51. #phpcon PostgreSQL • 9.6 => 13 へバージョンアップ ◦ oidの廃止がかなり痛手で、戦々恐々としていた • 戦術を立てるために、対象を見極める ◦ 結果想像以上に影響が少なく、あっけなく終わった • 開発チーム全体を活用した不具合検出は有効だった
52. #phpcon PHP
53. #phpcon PHP • 7.3 => 8.0 • ゆるふわPHPには厳しい挙動の変更が多い • 曖昧な比較、引数の型の厳格化・・・・ • 冗談じゃなく、まともに動かない自信しかなかった
54. #phpcon 作戦のおさらい • バージョンアップ作業は最速で終わらせる • 修正は最小化する • 並行している開発案件をバグの洗い出しに活用する • 出た不具合はバージョンアップ担当メンバーが逐次修正
55. #phpcon PHP • まずは対象を見極める ◦ 範囲は非常に多いが、ロジックを全部見直すような影響はなかった ◦ 挙動の変更などはできるだけ”なかったこと”にすればいけそう • 必要な修正はほとんど置換できるようにした ◦ そのため、一瞬で修正して並行で開発しているメンバーに展開できた • 個別でプログラムを修正したのは数えるほど • ここでもチーム展開後のバグだしが有効だった
56. #phpcon PHPで取った戦術 • 調査・設計には時間をかける • 範囲の広い修正作業は一度に終わらせる • バグ報告のフローにPHP8起因のバグかの判断を追加
57. #phpcon PHPで取った戦術 調査・設計には時間をかける • 影響範囲の見積が間違っていれば大変なことになる • 不要な修正(念のため・・・)は避けたい ◦ 設計・テストも大変 ◦ 後続の戦術全体を間違える可能性もある • 全工数のうち6割は使ったのでは
58. #phpcon PHPで取った戦術 範囲の広い修正作業は一度に終わらせる • 挙動変更はすべてラップする ◦ PHP7との挙動差がないように • ラップ関数の適用は自動でできるように ◦ PhpStrom の構造置換はとても便利 • 個別対応が必要なケースはやむなし ◦ 余裕があるならPHP7で動くコードはこまめにマージしてもいいかも ◦ ケースバイケースなのでいろいろ言えない
59. #phpcon PHPで取った戦術 バグ報告のフローにPHP8起因のバグかの判断を追加 • 真っ先に行い、バージョンアップ担当者が判断した • 他の開発メンバーに調査させないように ◦ とくにPHP8を知らない人もいるし、個別に調べるのは無駄が多い • 修正方針も立てられるので、効率が良かった
60. #phpcon まとめ
61. #phpcon まとめ • 開発を続けるのは絶対条件 • MWバージョンアップは改善じゃないと意識 • 生き残れば一旦勝利とする • 意外と簡単に済むこともある • 相手をよく知って、有利に戦う