老エンジニアたちの挽歌４
主「予定管理したい」
この時のシステムは、Googleカレンダーを駆使して、予定を登録し、
カレンダーのタイトルや詳細に、内容がわかるように、
コロン区切りで入れる。
例えば、
講師名：生徒名：内容：科目：授業時間：休みなどのステータス：・・
といった感じ。
自作の業務システムのほうで、Googleカレンダーを読み込み、
コロン区切りをばらし、正規表現を駆使して、自前のDBに当て込むことをしている。
※自作業務システムは往年のさくらインターネットを使っている
その時にの弊害として、取り込むたびに、確定していた予定が、誰かが過去のGoogleカレンダーをいじるせいで、書き換わってしまう。
自作システムのほうで操作した内容が失われる。
あげく、受講料計算などを間違えることにつながっている。
私「かなりやばいですね」
主「どうやって対応すればいいですか？」
私「業務にGoogleカレンダーは使わないっすよね。
なので、業務システムのほうで、カレンダー機能もちますよね」
主「カレンダーのUIみたいなのって作れるもんですか？」
私「Googleカレンダー通りではないですが、fullcalendar.jsとか使えば、
それっぽいものはできます」
主「作ってみてください」
私「わかりました」
１か月後、
私「とりあえず、それっぽいものはできました」
主「いいですね、これでいいや」
A「Googleカレンダーに比べ見劣りしますね」（そりゃな・・）
私「これでよければ、業務カレンダー機能をこの画面で対応する」
主「旧システムにいれられますか？」
私「旧システムは全然手をつけてないので、ノウハウ共有するので、
Aさんか、Bさんが旧システムをメンテすれば対応できるんじゃないですか？」（無理だな）
主「じゃあ、新しいシステムのほうで対応するでいいです」
私「休み判定とかどうするんですか？」
主「どうするつもりですか？」
A「・・・・」
私「API連携じゃないですかね」
A「じゃあAPI作ればいいですか？」
私「ほかに方法思いつきますか？」
A「・・・・」
A「・・・・」
私「例えば、さくらインターネット側から、AWSのDBを読むことは可能ですが、
逆はできません。将来的に、業務システムの画面が新システムになるから、
このほうが、将来性は高いと思います。
相互連携するなら、さくらインターネットやめて、全部AWSか、APIですね」
A「APIで！」
主「一応、さくらインターネットで、AWSから参照できるように対応できるかしらべてください」
：
その後、さくらインターネットの上位プランで、一応可能になるようだが、
インフラ代が５万ぐらいになるので、断念。
古いシステムがさくらインターネットで動作し、
新しいシステムをAWSで開発するプロジェクトはちなみに４回目になる。
大体末路として、古いシステムは消滅する。
私「古いシステムをAWSに移行したほうがいいです」
主「総合的にほかのエンジニアの意見を聞きましょう」
A「大変じゃないですか、（反対です）」
B「それ（AWS)は,なにか普通のサーバーと違うんでしょうか？」
私「ふつうのサーバーを仮想化して、ソフトウェアの状態で利用します。
そのため、バックアップとかが非常にしやすくなります。
中身は普通の空っぽのlinuxと変わらないので、いったん再構築は必要となります」
B「古いシステムは特別なものをインストールしてないので、動くと思うんですけどね」
私「では移行したほうがいいと思います」
主「移行するメリットは？」
私「AWSのリソースが利用できる。特にDBの共有ができるので、データ連携とかAPIとか作らず解決可能になります」
主「デメリットは？」
私「APIの開発ですね」
私「結局、移行工数と、APIの開発工数がトレードオフ要素といった感じにはなります」
B「結局何をすればいいんですか？」
私「AWS環境に古いシステムを乗せ換えてテストする感じです」
A「動作するか保証できない」
B「わかりました。検討します」
：
その後、Bさんが持ち帰って判断材料を出し、
結局動作確認が難しいとなった。
Googleリソースなどの外部連携要因が多いのはしょうがないと思う。
これにより、API開発が必要となり。
そのAPI開発工数が半年以上かかっても完成しないとは、この時点では誰も考えていない
