システム開発における式年遷宮(しきねんせんぐう)
こんにちは
GENDOSUです。
今日は、普段システム開発をしていて、ふと思った事を書いてみます。
式年遷宮(しきねんせんぐう)とは
出典: フリー百科事典『ウィキペディア（Wikipedia）』
式年遷宮をやる主な想定される理由
- 建築様式を保存するため
- 神道の精神として、
常に新たに清浄であること
（「常若（とこわか）」）を求めたため。
建物がいまだ使用可能の状態であっても、
老朽化することは穢れであり、
神の生命力を衰えさせることとして忌み嫌われたため - 他にも色々あるが割愛
これ、システム開発にも言えるのでは？
システム開発を式年遷宮に雑に当てはめてみると
建築様式を保存するため
技術・知識（ノウハウ）が途絶えないようにする たいていの場合、システムに対するノウハウは人に紐付づいていきます。
そして、詳細なドキュメントを書かずに辞めてしまったりします。
すると、新しく入ってきたメンバーはその仕様やノウハウについてゼロから習得しなければならなくなります。
ロジックが複雑で変更も少なく新しく入ったメンバーが手を付けないようなところがブラックボックス化していきます。
建物がいまだ使用可能の状態であっても、 老朽化することは穢れ
システムでは、ミドルウェア等のバージョンが上げられないことによって、そのシステムは老朽化していると言えると思います。
=>維持運用しているだけでは老朽化
システムにおける式年遷宮とは？
それは システムのリニューアル！！
普通に運用していくと5年~10年くらいで・・・
普通に運用していくと、だいたい会社のビジネスが次のステージに進んで来たり
システム自体がレガシーになってきていたり
エンジニアチームに当時のメンバーがほとんどいなくなってしまっていたり
エンジニアのモチベーションが低下していたり
します。
すると・・・
エンジニア側から自然とリニューアルしたいという話が上がってきます。
たぶん
これが起きないチームはかなりシステムのリファクタリングや改善に力を入れているか、
ただ単にチーム（もしくは会社）が死んでいるかだと思っています。
システムリニューアルの動機
- 今後のスケールを想定した改修が難しい
- メンバーが入れ替わりすぎて
もう当時の仕様分からない。
なんでこんなことしてるんだっけ？？
これいらないんでは？ - ここ、どーいう仕組みで動いているか理解不能なんだけど、
今も動いているし重要な機能なんだよなー
＝＞ブラックボックス化 - 各種バージョンが古すぎてバージョン上げていくのが無理
システムをリニューアルすると良いことは？
現在の業務に合わせて、新しく作り上げることが出来るので、運用も最適化されます。
また、最新のモダンな環境を取り入れることが出来るので、モチベーションが回復するのと同時に
開発チームも自分たちで新規で作り上げているので当事者意識が生まれます。
当然自分たちで作り上げているのでブラックボックスは無くなります。
最新のモダンな環境を触れると言うことで、採用時の条件も良くなります。
工数やばくね？ 業務止まらない？？
では、いざリニューアルをする決断が出来たとして
xxx「リニューアルはしたい。でも業務は止めたくない。」
yyy「100歩譲って、改修は出来なくてもシステムは止めたくない。」
といった要望は必ず出てくると思います。
業務を止めずに少しずつやるには
- 機能毎に分割できるところは分割して
マイクロサービス化 - モノリシックを全部一気に解体しなくても良い事にする
一部マイクロサービス化して切り出すけれど
メインプロジェクトはまだ既存のシステムとする
切り出す事を繰り返していって、最終的にモノリシックな既存のシステムを解体する事を目指す
マイクロサービス化（例）
参考として認証系・外部連携系API・バッチ系など、独立して機能させられる単位毎にプロジェクトとして切り出します。
さらに、そのプロジェクトに対してプロジェクトオーナーを指名する事が出来ればなお良いです。
もう一つのプロジェクトの分け方として
フロントエンドとバックエンドで分割する方法があります。
サーバサイド管理画面やフロントエンド向けのAPIの実装
フロントエンドはReactやVueJSなどで作り、サーバサイドとはAPIで通信する形にします。
まとめ
- エンジニアチーム内で何気なく出る
「リニューアルしたいね」
という言葉に対してその裏に何があるのかを伊勢神宮の行事になぞらえて考えてみました - リニューアルは必要
- でもいっきに全部はやらなくても良いよ