レガシーシステム撤去の工夫と所感

ここで扱うレガシーシステムは、ソースコード的なものは含みません。主にサーバやシステムのことを指します。そのためレガシーソフトウェア改善ガイドや、レガシーコードからの脱却といった書籍の内容なども登場しません。メンテナンスが行き届かずOSやミドルウェアのEoLを迎えてしまい、泣く泣く再構築することになった体験による工夫がメインのお話です。

自分がやったレガシーシステム撤去

プロキシサーバ移転、メールサーバ移転、社内DNS管理システムの置き換え、Nagios廃止、NFSサーバマネージドサービス化など

進め方

レガシーシステム撤去と立ち向かっている途中からは、SREが二人組としてタスクに取り掛かるバディ制度が取り入れられました。後述しますが、レガシーシステム撤去をするうえで二人組で取り掛かれるのはとても心強かったです。複数のバディから構成されるSREチームに自分はいます。

  • 見積もりとタスク分解
  • 作業前後の図を書く
  • 作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件がないか見てもらう

見積もりとタスク分解

再構築と撤去をするシステムごとに見積もりとタスク分解をしてドキュメントにまとめました。ドキュメントをもとにチームに説明しました。ボツ案もチームに共有することで、チームに対してどこまで技術的な検討をしたのかを共有できました。ボツ案という、実行可能なアイデアのうち最低のものを共有することでチームメンバーに安心感を持ってもらえる効果もあったように思います。

作業前後の図を書く

バディを組んだ相手が得意なムーブがこれでした。レガシーシステム撤去作業前後の図を書くことで、システムを構成する要素の変化が伝わりやすいです。我々は忘れやすいので、数ヶ月後の自分たちも助ける効果があります。

作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件ないか見てもらう

レガシーシステムについての知見はまとまっていてもドキュメントが古くなっていたり、ドキュメントが無かったり、ドキュメントされていない機能があったりします。コード管理されているのに、実際のサーバ上でコードが編集されていてドキュメントとの乖離があるということもありえます。

こうした背景がレガシーシステムの撤去を難しくしています。また、その前段階であるシステム考古学とでも言いたくなる先人の活動の調査や、システムの変化を追っていく作業を難しくしています。

こうした背景があるため、バディで行った見積もりとタスク分解の結果や、作業前後の図が、誤った前提知識や認識により作られた可能性を排除できません。そのために作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件がないか見てもらうというステップを設けています。

 

ここまでが自分や自分たちがやってきたレガシーシステム撤去の作業上の工夫でした。ここからは所感コーナーです。

 

レガシーシステム撤去の光と闇

レガシーコードの撤去は、使われるかどうかはリリースした後にしかわからない新機能開発に比べて事業貢献になりやすいと友人が言っていました。対象についてのコストやレガシーっぷりがわかっており、やればいい状況であるからということでした。自分も同意する意見でした。レガシーコードであっても、レガシーシステムであってもあてはまるように思いました。しかしアピールしやすいかどうかで言うと、単純な作業をしたと捉えられやすいためにアピール方法は工夫する必要がありそうです。(自分も良いアピールができているとは思えないので、具体的な工夫の方法については書くことができません)

 

レガシーシステム撤去は人によっては精神的な負荷が高いと感じました。先人の活動の調査や、システムの変化を丁寧に追っていく(システム考古学と呼びたくなる)一連の作業は、記憶力の悪い人間(自分)にとっては混乱してしまうことが多くありました。精神的に負荷でした。ここに関しては特にバディ制度に助けられました。幸運なことに僕のバディはこういった作業が得意であり、社歴が長いため知っている過去の経緯も多かったからです。

 

レガシーシステムの撤去は、本質的には本当に捨てていいのかという声との戦いであると思います。調査に時間と労力がかかってしまうことや、必要な確認事項はすでに完了しているのに捨てるアクションを取れていないということがレガシーシステム撤去のブロッカーとなっているのだと思います。事前に合意が取れている確認事項をつぶせたらサクッとつぶす必要があるように思います。そうしないとさらに年単位で生き長らえる可能性があります。それがレガシーシステム撤去の怖いところであるように思います。

 

この記事に書いた内容が、誰かのレガシーシステム撤去に役立てばうれしいです。

投資の勉強

最近投資の勉強をしている。これまでよりも力を入れている。他の理由もあり財務諸表の見方を学んだりしている。

これまでの投資の様子を振り返ってみる。

20代後半は自由なお金が少なかった。NISAが出たばかりの頃くらいから毎月積立で投資信託を数百円か千円くらいずつ買っていた。ここらへんから投資の面白さに気がつく。

投資信託買い続けるのを数年続けていたら、ある程度溜まってきたことや、景気が良かったこともあり一部売って株を買う原資にしたりし始めた。

プチ株で買っていたのが単元化できるまでに育ち、航空会社の株主優待券をもらえるようになった。

結婚してお金を使わなくなったので、NISA枠を使い切ることにした。毎日微量の投資信託を買うようになった。マネーフォワードに証券口座や確定拠出年金の口座を登録しておいて日々成績を見るのが趣味になってきた。

PCゲームをやるのでグラボ大事だよな思っていたのと、最近のAIブームもありGPUの需要高まってるしと適当な理由をつけて微量のNVIDIAの株を買って放置しておいたら2倍以上になっていて、米国株いいじゃんとなった。とはいえバブル感あるような気がしていて怖さも感じている。

 

これまでの投資について振り返ってみた。ごく少額の積立から始めたけど今はその数十倍以上になっている。これから始めてみようかなという人の参考になればうれしいし、こうした会話ができる人がまわりに増えたら更にうれしいと思う。

一方自分の投資の仕方はなんとなく売買してる感じが強い。投資についてさらに勉強し、売買する理由を強化して、結果を振り返れるようにしてもっと投資やっていきたい。

被評価者が苦手

https://twitter.com/hokkai7go/status/1347466542603096066

 

以前から人事評価というプロセスが苦手で、アピール下手だし、評価面談では手が冷えたり変な汗をかくということが何年も続いていました。社会人経験が長くなるにつれて少しずつうまくなった部分もあるでしょうし、最近は過度な期待をしないように自分の中で調整したことや、日々目標を追えるようになってきたこともあり、だいぶ安心して評価面談にのぞめるようになりました。しかし、冒頭のツイートのように再発してしまっていたようでした。

リモートでの評価面談というものに慣れていないからなのかもしれないし、単に今日は寒かったからなのかもしれません。なんとか苦手意識を克服したいけど、なかなか手強いなと感じた一日でした。うまくやれる人の方法や考え方を学びたいですね。

 

 

子供の頃に持った苦手意識からの開放

最近、仕事終わりなど時間を見つけてプラモデルを作っている。JALB787-8のプラモデルだ。 小、中、高の学生時代のいつかは忘れたけど、ダッソーミラージュ2000のプラモデルを作ったことを覚えている。当時は慎重さもないし、手際も悪かったし、経験もなかったので組み立てにも塗装にもめちゃくちゃ苦労して、微妙なものが出来た覚えがあった。兄は手先が器用だったので、兄と比較してうまくできなかったことがすごく印象に残っていたので、プラモデルへの苦手意識があった。 家での過ごし方を考えているときに、プラモデル久しぶりに作るのいいかもと思ってやってみたのだった。慎重さとか、事前に入門記事調べたりなどをして、今回はそこそこのものが作れた。子供の頃の苦手意識に向き合い直してみると意外とおもしろい発見があるんだなと気がついた出来事だったので書いてみた。

2年経つ

https://blog.hokkai7go.jp/entry/2018/09/05/074008

転職してから2年が経っていました。1つの会社に2年いたことは人生初です。よく頑張っていますね自分。

長期プロジェクトとその振り返りが終わり、感情を供養することができてよかったなと感じています。Mackerelの前身である社内プロダクトの役目を終わらせるプロジェクトに関わってきました。

いろんなことがあったけど、この2年でプロジェクトをすすめる上でのタスク分解や見積もりや、実行についてうまくなったということを振り返りで確認できたのがよかったです。チームとして強くなっていることが確認できたということです。

2年という節目で成長を感じられてよかったねということで書き残しておくことにしました。

Jenkins依存からの卒業

この記事はつぶやきというか、あのときこんなことやっていたなと自分が後から思い出すための記事です。

Jenkinsとはかれこれ10年近くの付き合いになると思うのだけれど、仕事でChef関連のCI/CD(Test, Lint等)をやっていたJenkinsプロジェクトの中身をCodeBuildに移設することができた。 これで自分の部署で使っているJenkinsでは重要なものは動いていない状態になったはず。最近はこのような移設プロジェクトの見積もり、実施などを主にやっています。もうちょっと挑戦成分をまぶしていきたいところ

一つ前の記事がGitHub Actionsの記事なので、そこだけみるとモダンなものに囲まれているように見えるかもしれないが、こうした地道でかつ古びにくい仕組みへの移設をやっています。

GitHub organizationsのメンバー管理をするTerraformを整備して、そのCIをGitHub Actionsで実現した話

はじめに

GitHub Enterprise(以下GHE)から github.com へと移行するのが社内のトレンドになりつつあります。renovateの利用も活発です。自分は組織横断的なSREチームにいますが、インフラだけでなくGHEや github.com のorganizationsの管理もやっています。

なぜGitHub organizationsの管理をTerraformでやろうとしたのか

本質的な作業ではないと思うものの、入退社のたびに操作を行う人が発生します。属人化したいものではないのと、他チームメンバーでも操作しやすくするためにコード管理したいとおもいました。自分の所属している組織横断的なSREチームでは、ほかチームのメンバーの増減について詳しく知らないので、各チームからチームメンバーの追加/削除のPRがほしいと考えました。つまりセルフサービス化したいと思ったということです。terraformのGitHub providerがあったので、これでやってみることにしました。

なぜGitHub organizationsの管理リポジトリにCIが必要と思ったのか

GitHub organizationsの管理をTerraformで実現したタイミングではCI整備ができていませんでした。CI整備が遅れたのは、自分がGitHub Actions初めて触ったので、tokenの扱いや、Organizationを変更可能な権限を付与する方法にたどり着くのに時間がかかったことによるものです。CI整備が遅れたことで、github id 変更や、手作業でのメンバー追加などで簡単にtfstateとの乖離が出ていくものの、CI整備できてなかったので気がつけないことが課題になりました。

なぜGitHub ActionsでCIしようとしたのか

ここは興味本位です。社内外の流行りに乗っておくかというノリ。Terraform Cloudじゃないのは費用面の試算等が面倒だったため。

得られたこと

セルフサービス化することができました。GitHub Actionsでは、terraform fmt, init, validate, plan をやっていて、terraform applyは手元からやっています。github.comのorganization管理に自分ばかりが詳しくなっていき、属人化していくことが心配でしたがコード化したことでこの心配から抜け出すことができました。実際に自分がいなくてもコードレビューと適用が済んでいた事例が増えてきています。エンジニアの入社処理や、他職種の追加フローからもガイドされており、スムーズに回るようになったように思います。

困ったことや実現できなかったこと

この記事を書こうと思い続けている間に、hashicorp/terraform-github-actions がメンテされなくなったという出来事がありました。hashicorp/setup-terraformを使うことで解決できることは以下のメドピアさんのブログによりわかっているのですが、なかなか直す時間が取れていません…。

tech.medpeer.co.jp