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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

#phpcon 自己紹介なまえ：やなせたかし MailDealerというサービスを開発していますややこしいことを中心に設計したり実装したり好きな言語：Scala コンパイラが優秀なのと、型システムの温度感がちょうどいい趣味：楽器/茶・コーヒー/香/自転車/… 節操なくたいてい沼にハマる

Slide 3

Slide 3 text

#phpcon セッションの前に ● 本セッションはレガシーシステムネタです ● 開発者としてベストなノウハウを提示するものではありません ● 現実と戦う方法をお話します ● ゴールは、今を生き延びることです ● 「ミドルウェア」は長いので、「MW」と表記します ● 内容にはフィクションを含みます

Slide 4

Slide 4 text

#phpcon お品書き ● 開発はずっと続いていくもの ● MWのバージョンアップがつらい理由 ● 開発を継続するための戦略 ● 事例紹介 ● まとめ

Slide 5

Slide 5 text

#phpcon 開発はずっと続いていくものこの章で話すこと ● なぜずっと続くのか ● 開発は何を求められているのか

Slide 6

Slide 6 text

#phpcon なんで開発は続いていくの？

Slide 7

Slide 7 text

#phpcon ビジネスの一部だからです

Slide 8

Slide 8 text

#phpcon なぜここでビジネス？ ● サービスが売れるかどうかは、企業(組織)の生存に直結する ○ 企業の関心ごとはサービスが持っている「価値」 ● 企業は存続に命を懸けるもの ○ 利潤追求のためには当然企業の存続が前提 → つまり、サービスも売れ続けなければいけない

Slide 9

Slide 9 text

#phpcon サービスの持つ「価値」

Slide 10

Slide 10 text

#phpcon お金を稼ぐ力

Slide 11

Slide 11 text

#phpcon ユーザーにとっても「価値」があるから

Slide 12

Slide 12 text

#phpcon 開発と「価値」開発という仕事を「価値」を軸に考えてみます ● 価値を増やすための開発 ○ ビジネスを成長させる ○ 新機能や機能向上が目に見えてわかる ● 価値を落とさないための開発 (改善) ○ サービスの価値は上がらない ○ 脆弱性対応、MWのバージョンアップやリファクタリングが該当

Slide 13

Slide 13 text

#phpcon こんな経験はありませんか？ ● なかなかリファクタリングできない ○ そんな暇あったら新機能の一つでも作れば？ ● 技術的負債のことをわかってもらえない ○ それをしてなんになるの？ ● いつまでも化石のようなシステムを保守している ○ いい加減作り直したほうが早い

Slide 14

Slide 14 text

#phpcon なんでこんなことが起きるのか ● すぐにコストを回収できない ● コスト外のメリットの可視化が難しい ● 開発組織への信用の低下

Slide 15

Slide 15 text

#phpcon すぐにコストを回収できない ● ユーザーにわかる変化がない ○ ソースがきれいになっても、それ自体は見えない ○ 大幅な高速化など、わかりやすいものは受け入れられやすい ● 改善している間は、新規の価値を生み出していない ○ これは機会損失だととらえられても仕方ない

Slide 16

Slide 16 text

#phpcon コスト外のメリットの可視化が難しい ● すぐにコストを回収できない ○ 当たり前だけど ● 将来的な価値の算出・評価は困難 ○ ともすればただのポジショントークにしかならない ○ 本当に工数がいままでの半分になるの？ ○ 本当に不具合件数がN％下がるの？

Slide 17

Slide 17 text

#phpcon 開発組織への信用の低下 ● 積み重ねの恐ろしさ ○ 過去十数年分の技術的負債 ○ 何度も過ぎる納期 ○ 年々増加する不具合 ● 開発組織以外からはつらさが見えにくい ○ 専門分野以外は誰しもそのようなもの ○ 開発組織もゆでガエルになっているケースもありうる

Slide 18

Slide 18 text

#phpcon 組織全体としてのお気持ち ● 開発組織に余裕がない、開発が上手くいっていない ○ 曰く、リファクタリングすれば取り戻せるらしい ○ 開発速度、品質も向上するらしい ○ それらしい見積もりはあるが、コスト回収は数年、売上には影響しない ● しかも、抜本的な改善の間は新機能の開発が滞る ○ その間に競合に差を付けられるかも ● それならば「価値」の向上を優先したい

Slide 19

Slide 19 text

#phpcon 改善のハードルは高い ● 組織は「価値」の向上を優先したい ○ 「価値を下げない」ための期間は「価値」を向上するチャンスを奪う ○ 改善は「価値」に直結せず、すぐにコストを回収できない ○ そもそも改善のメリットを評価できない ● 実は組織全体の問題 ○ システムの疲弊のリスクが安く見積もられている ○ こまめに改善できる組織はレガシーシステムになりにくい

Slide 20

Slide 20 text

#phpcon 例外があります

Slide 21

Slide 21 text

#phpcon MWのバージョンアップ

Slide 22

Slide 22 text

#phpcon MWバージョンアップと「価値」 ● やらないと明確に「価値」が下がる ○ 修正されない脆弱性を突かれて情報流出 ○ そもそも売れなくなる ● つまり「やらないときの損失」がわかっている ● 損失を回避することで「価値」がうまれる

Slide 23

Slide 23 text

#phpcon つまり必要になったということ ● レガシーシステムの現場ではよくあるのでは ● 改善そのものの価値が認められたのではない点に注目

Slide 24

Slide 24 text

#phpcon MWのバージョンアップがつらいわけこの章で話すこと ● つらいこと ● 逃げられないこと

Slide 25

Slide 25 text

#phpcon 前章のおさらい ● 「価値」とはお金を稼ぐ力 ● 開発リソースは「価値」の向上に使いたくなりがち ● コードをきれいにすることは「価値」を向上させない ○ と思われている ○ 少なくとも簡単に見積もれない ● 改善は、差し迫った損失を避けるモチベーションで承認される ○ そして私たちはそれを改善のチャンスと誤解しやすい

Slide 26

Slide 26 text

#phpcon よくあるつらみ ● 影響も規模も大きすぎて途方に暮れる ○ 全ソースが対象なんて当たり前 ● 問題が大きいのに期間が短い ● 過去の作業の経験がのこっていない ○ 数年に一度だったりするため ● ソースの改善個所が多すぎてあれもこれも不安になる ● つらいプロジェクトになりそうで怖い

Slide 27

Slide 27 text

#phpcon 認識のギャップに気づく ● 今必要なのは「MWのバージョンアップ」 ○ 抜本的な改善じゃないんですよね ● だから、大きなコストはかけられない --------- ここにギャップがある ----------- ● 開発チームの眼前には問題が山積みのソースコード ○ 長年積み重なった技術的負債 ● せっかく直せるのに・・・

Slide 28

Slide 28 text

#phpcon もう手遅れなんだ・・・けど ● 今もそのレガシーシステムは「価値」を生み出している ○ これは紛れもない事実 ● どうしたってEOLはやってくるし、そこからは逃れられない ● 今ある諸問題は、これまで解決できなかったもの ○ 同時に対応するには荷が重すぎる

Slide 29

Slide 29 text

#phpcon とりあえず生き残る

Slide 30

Slide 30 text

#phpcon とりあえずでいいから生き残るシステムが生きていれば・・・ ● ご飯が食べられる ○ 少なくともいきなり路頭に迷うことはない ● 今回の知見が手に入る ○ 役に立つ経験になるはず ● 次のバージョンアップまでの時間が手に入る ○ その間に手を打つ

Slide 31

Slide 31 text

#phpcon 開発が続けばチャンスは来る ● チャンスとして生かせるかは組織に依存する ○ あきらめも必要かもしれない ● とはいえ改善させてもらえるよう努力は必要 ○ 今のままでは厳しいことを開発組織外にも理解してもらう ■ システムが限界なので直したい ■ 長年の技術的負債で開発が厳しくなっている

Slide 32

Slide 32 text

#phpcon 開発を継続するための戦略この章で話すこと ● MWバージョンアップを乗り切る戦略 ● 具体的な作戦立案 ● 相手を知る

Slide 33

Slide 33 text

#phpcon まずは言葉の定義から ● 戦略 ○ 組織の目標達成へ向けた大局的・長期的な視点での計画 ● 作戦 ○ 戦略をどのような手段で実行するか ○ 戦い方・シナリオとも言い換えられる ● 戦術 ○ 作戦遂行の具体的手法 ○ 勝ち方とも言い換えられる

Slide 34

Slide 34 text

#phpcon 戦略

Slide 35

Slide 35 text

#phpcon 戦略 ● 大局的な視点で策定される ○ たとえば企業単位、サービス単位 ● 上位の組織の戦略に縛られる ○ 今回のケースだと、「価値」の向上を第一とする ● 今ケースで考える戦略は、開発チームとしてのもの ○ 好き勝手はできない

Slide 36

Slide 36 text

#phpcon 戦略を考える必要性 ● 開発チームとしては上位の戦略に従う ○ だから選択できる戦略はそう多くない ○ それは普段もそう変わらないはず ● 規模が普段と違うので、開発チーム全体の戦略を考える ○ 基本的には「普段通り」やるのがベスト ○ しかし、規模の見積もりが難しい

Slide 37

Slide 37 text

#phpcon 条件を検討する前提 ● 開発は継続する ● 「価値」の低下は避ける自分たちの現状 ● リソースに余裕はない ● 長年の問題が山積している

Slide 38

Slide 38 text

#phpcon 戦略立案 ● 普段の開発 ○ 組織の戦略である「価値」向上を進める ○ いつも通り進める ● NWのバージョンアップ ○ 組織の戦略を妨げないようにしないといけない ○ 普段の開発への影響を最小に抑える

Slide 39

Slide 39 text

#phpcon 作戦立案

Slide 40

Slide 40 text

#phpcon 状況整理チームの状況 ● リソース・時間に余裕がない ● 通常開発も並行しているため、それを止められないシステムの状況 ● 長年の問題が山積している ● 影響範囲が広く、テストが大量に必要

Slide 41

Slide 41 text

#phpcon 大まかな方針 ● 人的リソースは効率的・効果的に使う ○ 最小限のメンバーでバージョンアップをやり切る ○ テストは過大な工数が必要なので、工夫が必要 ● 通常開発を止めない ○ 「バージョンアップ」に関する作業は最小限に

Slide 42

Slide 42 text

#phpcon 作戦立案通常開発への影響を最小限に抑えるためにどう戦うか？ ● バージョンアップ作業は最速で終わらせる ● 修正は最小化する ● 並行している開発案件をバグの洗い出しに活用する ● 出た不具合はバージョンアップ担当メンバーが逐次修正

Slide 43

Slide 43 text

#phpcon 作戦立案バージョンアップ作業は最速で終わらせる ● 通常の開発を止める時間を最小化するため ○ バージョンアップ中の作業が止まると、チーム全体が止まる ○ 時間がかかるほど影響が大きくなるので重要

Slide 44

Slide 44 text

#phpcon 作戦立案修正は最小化する ● 修正箇所が多いと普段の開発と衝突しやすい ○ 大きな変更ほど追加の修正が困難に ● バージョンアップ以外の修正に囚われることを避ける ○ 改善の気持ちになっているがぐっとこらえる ○ 限られた期間を有効に活用する

Slide 45

Slide 45 text

#phpcon 作戦立案並行している開発案件をバグの洗い出しに活用する ● リソースの有効活用 ○ もちろんテストはするが、全ソースの全パターンなんてテストできない ○ レガシーシステムは思い切りもある程度いる ● 修正による影響の周知 ○ 挙動の変更などを身をもって知ってもらう

Slide 46

Slide 46 text

#phpcon 作戦立案出た不具合はバージョンアップ担当メンバーが逐次修正 ● リソースの有効活用 ○ 知識も豊富なはず

Slide 47

Slide 47 text

#phpcon 相手を知る

Slide 48

Slide 48 text

#phpcon 相手を知る ● 具体的に戦術を考えるには、相手を知ることが重要 ● 未知の相手は怖いが、既知の相手は対処法を考えられる ○ たとえ大量でも無限より有限のほうがいい ○ この時点で戦術が不要になることもままある ● 問題はなるべく分割するべき ○ 複数の問題を一度に解決するのはつらい ○ シンプルなほうが解決しやすい

Slide 49

Slide 49 text

#phpcon 事例紹介この章で話すこと ● PostgreSQLの事例 ● PHPの事例 ● PHPで実際に使った戦術の紹介

Slide 50

Slide 50 text

#phpcon PostgreSQL

Slide 51

Slide 51 text

#phpcon PostgreSQL ● 9.6 => 13 へバージョンアップ ○ oidの廃止がかなり痛手で、戦々恐々としていた ● 戦術を立てるために、対象を見極める ○ 結果想像以上に影響が少なく、あっけなく終わった ● 開発チーム全体を活用した不具合検出は有効だった

Slide 52

Slide 52 text

#phpcon PHP

Slide 53

Slide 53 text

#phpcon PHP ● 7.3 => 8.0 ● ゆるふわPHPには厳しい挙動の変更が多い ● 曖昧な比較、引数の型の厳格化・・・・ ● 冗談じゃなく、まともに動かない自信しかなかった

Slide 54

Slide 54 text

#phpcon 作戦のおさらい ● バージョンアップ作業は最速で終わらせる ● 修正は最小化する ● 並行している開発案件をバグの洗い出しに活用する ● 出た不具合はバージョンアップ担当メンバーが逐次修正

Slide 55

Slide 55 text

#phpcon PHP ● まずは対象を見極める ○ 範囲は非常に多いが、ロジックを全部見直すような影響はなかった ○ 挙動の変更などはできるだけ”なかったこと”にすればいけそう ● 必要な修正はほとんど置換できるようにした ○ そのため、一瞬で修正して並行で開発しているメンバーに展開できた ● 個別でプログラムを修正したのは数えるほど ● ここでもチーム展開後のバグだしが有効だった

Slide 56

Slide 56 text

#phpcon PHPで取った戦術 ● 調査・設計には時間をかける ● 範囲の広い修正作業は一度に終わらせる ● バグ報告のフローにPHP8起因のバグかの判断を追加

Slide 57

Slide 57 text

#phpcon PHPで取った戦術調査・設計には時間をかける ● 影響範囲の見積が間違っていれば大変なことになる ● 不要な修正(念のため・・・)は避けたい ○ 設計・テストも大変 ○ 後続の戦術全体を間違える可能性もある ● 全工数のうち6割は使ったのでは

Slide 58

Slide 58 text

#phpcon PHPで取った戦術範囲の広い修正作業は一度に終わらせる ● 挙動変更はすべてラップする ○ PHP7との挙動差がないように ● ラップ関数の適用は自動でできるように ○ PhpStrom の構造置換はとても便利 ● 個別対応が必要なケースはやむなし ○ 余裕があるならPHP7で動くコードはこまめにマージしてもいいかも ○ ケースバイケースなのでいろいろ言えない

Slide 59

Slide 59 text

#phpcon PHPで取った戦術バグ報告のフローにPHP8起因のバグかの判断を追加 ● 真っ先に行い、バージョンアップ担当者が判断した ● 他の開発メンバーに調査させないように ○ とくにPHP8を知らない人もいるし、個別に調べるのは無駄が多い ● 修正方針も立てられるので、効率が良かった

Slide 60

Slide 60 text

#phpcon まとめ

Slide 61

Slide 61 text

#phpcon まとめ ● 開発を続けるのは絶対条件 ● MWバージョンアップは改善じゃないと意識 ● 生き残れば一旦勝利とする ● 意外と簡単に済むこともある ● 相手をよく知って、有利に戦う