前回の記事に続き偏った主観ですが、思ったことを綴ります。
大変だったこと
1. 会社が代理で実施してくれていたことを全て自分で管理するようになった
年末調整、住民税の支払い、年金の支払い、前職では会社が丸っと実施してくれていたため、自分には知識がほぼ皆無でした。
退職した翌月、たくさんの振込用紙が届き、期限付きの手続きも一つずつ理解しこなす必要がありました。
ざっと挙げるとこんな感じです。
- 厚生年金から国民年金への切り替え
- 住民税の支払い
- 401kを個人のiDeCo口座を開設し移動
- 持ち株を一般の証券口座を開設しへ移動
- 給料天引きで支払っていた生命保険を個人口座からの引き落としに変更
- 社会保険を任意継続に切り替え、その支払い
基本口座引き落としだろうと思っていましたが、住民税は振込用紙から支払うことになりました。
今は何がなんなのかを理解し管理できていますが、これらが一度に来てかつ、期限付きで対応しなければならなかったため
ヒヤヒヤしながら処理していきました。
今のところ僕はこれくらいです。ただし、もしかしたらローンを組む際などに影響あるかもしれませんがなんとも言えないです。
変わらなかったこと
1. 開発、運用や耐障害性に関する関心事に大きな差はない
細かいですが、どうしたら予期せぬサービス停止のリスクを減らせるか、どうリカバリーするかの考慮する点、考え方に大きな差はありませんでした。
むしろ、大規模システムの開発から運用までを一通り経験した僕は、多くの考慮をアプリやインフラに入れることができました。
例えば以下のことです
- DBが落ちたらどうするか？
- 非同期処理のプロセス監視と復旧方法
- ゼロダウンタイムでのデプロイ
- メモリ、CPU監視方法とチューニングの勘所
- 負荷試験の実施
- システムの状態の見える化
- ログ設計
- 障害ポイントの洗い出しとリカバリ方法の検討
- git flowでの開発運用
- Devopsツールの導入, deploypipelineの構築 ※AWSだがオンプレに近いためgithub, CircleCIでは完結できなかった
- 障害検知と通知フローの方針決め
- 手動操作を加える際の考慮 (EC2を手動でいじる際は後でCode化する)
- ドキュメントにもgit管理でCIを回す
- SLAの定義
- batch jobの運用方法、job schedulerの導入
AWSの既存機能がカバーしてくれる部分もあり手を動かす工数は削減できましたが、検討を始める入り口は同じで一つ一つ何を
使えば目的を満たせるか、理想か決めていきました。この辺りもモダンなweb開発の現場であっても、前職の現場の知識と経験を
発揮できています。
2. 大事なのはホスピタリティ
1で挙げたように多くの考慮点と向き合いながら機能開発とサービスリリース準備をバランスよく進めていくのですが、
この辺りをしっかり見れることに関してもっとも大事だと思うのはホスピタリティだと感じています。
これらを検討し、結果をドキュメント化にすることも多いのですが、
- 今考えることではない気がする
- どんなドキュメントを書けばいいのか分からない
- 自分の仕事はコーディングだ
と、理由をつけて後回しにする選択肢もありますが、これらは早い方が後々安心します。
開発終盤に後半に一気考えるとあまりの多さにモチベーションが下がったり、アプリケーションの設計のコアな部分を直したくなったりとタスクが一気に増えます。
また、これらは考えだすと毎日のように思いついたりするものなので、思いついたタイミングで話し合い、その場で方針を決められるのが良いです。
ドキュメントに関しては、ラフでも全然よく、フォーマットを待たずに自分が思う分かりやすい形ですぐ書くのが良いです。
個人的な意見ですが、システム設計関連の書籍は、ざっと流しで読んだ後、書きたいことベースで参考資料として参照用として使います。全てが決められたフォーマットで書けることはほぼないため、まずは書いてみる、伝えてみるからのブラッシュアップが、スピードが求められ、すばやく完成品を挙げる最短距離を見つけやすくしてくれます。
遅かれ早かれ必要となるこれらの非機能要件を検討していく作業は、いつ頃から考えるかが決めにくいこともありますが、
ここでホスピタリティを発揮し、方針を整えていければ、サービス開始や運用において頼れる存在になれるはずです。
次回は、自分は成長して続けられているか？について書こうと思います。
