Share
Embed
Slide 1
Slide 1 text
#phpcon
©2021 RAKUS Co., Ltd.
20年モノの巨大Webサービス
の開発継続戦略
- ミドルウェアのバージョンアップとの向き合い方 -
やなせ たかし
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バージョンアップは改善じゃないと意識
● 生き残れば一旦勝利とする
● 意外と簡単に済むこともある
● 相手をよく知って、有利に戦う