この記事はリライトです、情報を追加して更新かけました
読み物としてストックしておいてもらえると嬉しいです
時々読み返すことで、システムリプレイスのヒントになるかと思います
なぜこの記事を書こうと思ったかというと、世の中でこれから動きそうな（動いている）システムリプレイスPjが成功することを祈って自分が経験したこと、こうすればよかったことを書かせていただきました。
この記事を読んだからって大成功するかというと正直難しいかもしれません。
ただ、読んだからこそ大事なポイントの発見や事前に手を打てることが増えると思いますので、是非とも活用してシステムリプレイスの成功確率を上げてもらえればと思います。
0. 導入
システムは生物（なまもの）です。
リリースしても保守をし続けて常に鮮度を保つことが重要です。
ただ、ビジネス要求や状況によってはどうしても保守よりも事業開発を優先してしまうことはどうしてもあります。
そこで出た負債を解消していく動きが後ほどしっかりと取れれば問題ないのですが、どうしても後回しになってしまい、負債が溜まって来てしまうという状況が作り出されてしまいます。
（心当たりありませんか？）
少しの負債であれば大した時間は取られませんが、大きく負債を解消しようとなったときに出てくる選択肢の一つが「システムリプレイス」です。
だからこそ、選択肢としてもっておくべきシステムリプレイスに対してどう成功確率をあげていくか事前に考えておくことは有意義です。
ちなみに、保守の必要性に関してはこちらを参考にしてください。（弊社内では保守のバイブルになってます）
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。
余談ですが、開発と保守の割合はどのぐらいがいいのかはこちらの記事で記載してます。
エンジニアの事業貢献ってなによ？
0-1. システムリプレイスの進め方
図では当たり前のことを書いております。
今回はリプレイス完了までに以下のフェーズに分けて説明していきます。
- 事前準備
- 実装
- リリース
- 振り返り
- 報告・共有
違和感がないように前提条件ですが、これは大きな単位でリリースをしていくというよりも、小さな単位で開発をしてリリースするというサイクルを取っております。
1. 事前準備
1-1. システムの問題とそれに対する課題を明確にする
あなたが関わっているシステムの問題はなんですか？
それに対する課題はなんですか？
まずはなぜリプレイスが必要なのか、明確にしておきましょう。
明確にしておくことで、多方面への説明ができるとともに、納得が得られやすくなると思います。
しっかりと整理をして文章にまとめておきましょう。
文章にまとめることのメリットは大きいです。
システムリプレイスは長期戦になりますので、途中で道に迷うことがあるかと思います。
その際は改めて文章化したものを見返してみてなんでシステムリプレイスをやっているのかを振り返るといいかと思います。
以下のものを読むことで問題・課題設定がうまくできるかと思います。
1-2. ゴールを設定する
システムリプレイスは長い戦いになることが想定されるでしょう。
ゴールがないデスマーチほど対応者のモチベーション低下や疲弊不満が溜まってくると思います。
それを防ぐためにもしっかりとゴールを設定し、終わりが見えるようにすることが大事です。
また、ゴールは大きく設定するのではなく、小さくゴールを設定することをおすすめします。
ゴールは複数持ってもよく、ゴールが達成したら次のゴールがあるような形にしてPjをすすめていくようにします。
ゴールが達成できることで、関わっている人たちに成功体験を作ることができるので、モチベーションの向上や主体性向上にも繋がります。
ゴールができたらロードマップも作成しておくといいでしょう。
1-3. ステークホルダーと握る
ビジネスにおいて、ステークホルダーと情報を共有することはマストです。
ステークホルダーはシステムの中身まで知らない人が多いかと思いますので、根気よく説明していく必要があります。
なぜシステムリプレイスが必要なのか、問題と課題、そしてどう解決させていくかのゴールがあれば説明はそこまで難しくないでしょう。
ただ、ここで問題となるのが”費用対効果”です。
そもそも今現状でシステムは問題なく動いているのになぜシステムリプレイスが必要なのか。
これを説明する必要があります。
よく上がる話としては以下のことがあります。
- 不具合が多発しており、不具合対応に対する時間の割合が肥大化している
- 開発パフォーマンスが低下している
- レガシーな構成のため、人員の確保が困難
などなど、ありますが、これはすべて事業成長につながる問題だと思います。
そのため、この問題がどのぐらいやばいのか数値化しておき、これを解決したときのメリットを数値にして表していきます。
（数値化は難しいときもあります。ここでは半ば強引でもいいので頑張って数値化して説明しましょう）
また、合わせて撤退ラインも決めておくといいかと思います。
予期しないことが起こることもシステムリプレイスです。
そのため、どういうことがあったらシステムリプレイスを凍結させる判断もあるという形で事前に定めておきましょう。
事業成長とシステムリプレイスの両側面を見てステークホルダーと一緒になって事業の将来を考えてみてください。
1-4. チームを作る
自分が理想とするチーム像を思い浮かべてみてください。
システムリプレイスは長い期間の改修が必要になってくるので、チームメンバーには”根気”がかなり必要です。
どういう人がいれば今回のシステムリプレイスが成功するのかを想像してみてください。
理想とするチーム像が浮かんだらチームビルディングをしましょう。
なぜ我々はシステムリプレイスをするのか、どういったところをゴールとするのか、というように全員が共通認識を持ち、同じ方向を向けるようにしていきましょう。
以下のようなやり方でチームビルディングができます。
チームの期待をすり合わせる方法 - ドラッカー風エクササイズ
問題解決のためのフレームワーク - すごい会議
1-5. 工数見積もりを実施する
システムリプレイス全体の工数を算出しておきましょう。
以下のようなにざっくりとした項目に分けてざっくりとした機能を洗い出し、機能それぞれに対して見積もりを出してみてください。
- インフラ
- フロントエンド
- バックエンド
- その他
あまり工数算出に時間をかけすぎても初期段階ではわからないことだらけなので、関わる人達がだいたいこれぐらいだよねという共通認識が持てた時点で終了しましょう。
見積もりの方法として3点見積もりという方法もあるので、おおよその期間を算出してみてください。
注意が必要なのは、しっかりとバッファを設けておくことです。
不確実性コーンという考え方もありますので、プロジェクトの初期段階は、わからないがだいたいこれぐらいという工数でOKとします。
徐々に中身がわかってきて解像度が上がってきてから改めて工数見積をしてアップデートをかけていきましょう。
改めてここまでできればスケジュールを組んでステークホルダーと握っておきましょう。
1-6. 資料や情報をまとめて見えるようにしておく
結構重要です。
各方面での意思決定や、思考の整理をしているとどうしても多方面に資料や情報が散らばってしまいがちです。
最初に資料を集めるところを決めておき、一定のルールを決めておきましょう。
また、システムリプレイスの全体はこれを見たらわかるというマスターの資料を一つ用意しておけば、全員がそこを見に行けば一定の理解ができるようになり、情報格差も生まれなくなくなるかと思います。
2. 実装
2-1. メンバーのモチベーションが大事
システムリプレイスは長期スパンになることが予想されます。
最初はやってやるぞという力で満ち溢れているかもしれませんが、数週間、数ヶ月、半年経つとどうしてもマンネリ化してしまったり、だれてしまったりします。
タイミングを見てメンバーのモチベーションをあげれるように風を吹き込んで行くと良いでしょう。
システムリプレイスでは、やはりメンバーの”根気”が結構大事です。
だからこそ、モチベーションを上げるための仕組みを入れてあげると成功確率が上がってくでしょう。
毎回やっている定例MTGだったり、仕組みだったり同じことを毎週繰り返しているものがあれば少しづつでもいいので買えてみましょう。
2-2. 設計が微妙なところが出たら立ち止まる
当初設計していたものが途中で微妙だなと思うときは必ずきます。
そのときはスケジュールを少し伸ばしてでも必ず立ち止まって全員で議論・意思決定をしていきましょう。
もし、微妙だけど最初に決めたしこれでいこうとなり進めてしまうと、あとから取り戻すにはそれ相応の工数がのしかかってきます。
それを防ぐためにしっかりと立ち止まって再度決めていきましょう。
たとえ、少し作ってしまっていてもそのまま進むのではなく、少し作ったやつを捨てて舵を切ったほうがよいこともあります。
わからないことだらけなのがシステムリプレイスです
立ち止まる勇気、捨てる勇気を持ちましょう。
2-3. 細かくテストをしていく
すべて作りきってからすべてマージして動かしてみると、残念なことに動かない・・ということはよくあります。
そのため、一つの機能ごとにテストを実施して動作がチェックがOKであればマージするというように、細かい単位でマージを繰り返していくと良いでしょう。
また、進捗共有の意味を込めて、できたものを他職種の人にも見てもらうといいでしょう。
もしかしたら同じ見た目かもしれませんが、SEOあげていくために仕事をしている方であればタグ構造を気にすることもあるでしょう。
見た目だけでは気づかないことも色々フィードバックをもらいながら進めていきましょう。
3. リリース
3-1. 段階的にリリースすべき
テストにも似てますが、大きな単位での切り替えはかなり労力がかかりますし、なにか起きたときの損害がとても大きいです。
画面単位での切り替え、API単位での切り替え等、少しづつリリースできるように分割していきましょう。
いきなりすべてのトラフィックを新しい方に向けなくてもいいので、少しづつトラフィックを入れていくことも検討しましょう。
3-2. エラー検知、テストの充実をさせておく
エラーはつきものです。
出てしまったものはしょうがないですが、早期に止血することが大事になってきます。
システムリプレイスでは仕様が曖昧な部分を実装すると思わぬところで様々な挙動が発生したります。
そのためにも、エラー検知の仕組みをいれておき、リリースしたらエラーを注視しておき、発生したらすぐに戻せる対応か修正対応をしていきましょう。
テストに関してはE2Eテストやファンクショナルテストといったテストコードを充実させていき、エラーを防ぐための動きをしていきましょう。
3-3. 保守計画を立てておく
リリースをしたら終わりではありません。
システムリプレイスをしてシステムの鮮度が上がってきているので、しっかりと鮮度をキープできるように計画を立てておきましょう。
例えば利用している言語やツールのバージョンアップ作業やコードのリファクタリング計画、様々な保守があると思いますので、このタイミングで計画を立てておけば工数も取りやすいでしょう。
4. 振り返り
運用方法、設計、状況色々な視点で振り返ってみましょう。
振り返りは細かく実施したほうがよく、1機能をリリースしたタイミングや1週間に1度など決まったタイミングを作って実施していきましょう。
振り返りを実施して出てきたTryを活かすことでシステムリプレイスの今後を大きく左右するでしょう。
5. 報告・共有
システムリプレイスは長期スパンになることが予想されます。
そのため、報告に関しては一定のタイミングでしておきましょう。
報告の対象として、ステークホルダーのみでいいのではと思うかもしれませんが、システムリプレイスでは周りの理解協力も必要となってくるため、その事業に関わっているすべての人に向けて発信していくと良いでしょう。
通常の開発とちがってシステムリプレイスは現状あるサービスをそのままに内部構造を変えていく場合がほとんどだと思いますので、目に見える成果がなかなか見せることができないです。
だからこそ、進捗共有をして進んでいる感を出していく必要があります。
番外. 個人的なアンチパータン
システムリプレイスと他Pjを掛け持ちで行う
システムリプレイスは一筋縄ではいかないものです。
そのため、他のPjと掛け持ちでやってしまうとどうしても中途半端な関わりしかできなくなってしまいます。
もし可能であればシステムリプレイスに専念できるように調整を組んだほうがよいでしょう。
他Pjとの掛け持ちによる脳のスイッチングコストを少なくさせて、集中できる環境を整えましょう。
新規機能を盛り込みシステムリプレイスを行う
これをやると以下のことが想定されます。
- 要件が複雑になってしまう
- 工数が膨れ上がりスケジュールが押してしまう
- システムリプレイスによる性能評価が単純比較でできなくなる
などなど色々考えられます。
まずは今動いているものがしっかりとリプレイスができてから機能追加を考えていきましょう。
まとめ
いかがでしょうか？？
結構当たり前のことも書いてますが、整理をしてみるとやるべきことは山積みになっていることがわかります。
これまで話してきたことで超大事なことははやり、”ステークホルダーとの合意”と”メンバー全員のやりきるぞ！という気持ち”が大事かと思います。
システムリプレイスは一旦のゴールではありますが、一番大切なのは、差の先にある事業成長です。
システムリプレイスをした結果、事業に対してどう貢献できるのかを考えて実施していきましょう！