Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

2564c99f616f1ecfc0f617a6fe87e2a9?s=47 penguin045
October 02, 2021

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

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

2564c99f616f1ecfc0f617a6fe87e2a9?s=128

penguin045

October 02, 2021
Tweet

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バージョンアップは改善じゃないと意識 • 生き残れば一旦勝利とする • 意外と簡単に済むこともある

    • 相手をよく知って、有利に戦う