- from: 株式会社はてな(2018年9月〜2021年3月)
- to: 元上司が起業した会社でCTOやることになりました
新しい会社は社長含めて3名の会社でかつ、会社のWebページすら無いので書ける情報があまりありません。隠しているというわけでもないのですが。
在職中にお世話になったみなさまありがとうございました。
最近、仕事で責務や業務の棚卸しをやっている。
やることがいつの間にか増えていたり、長年の歴史のうえでなぜやっているかわからない業務があったりする。責務からすべての業務を導けるものではないのだなと気がついた。
なかなか興味深い体験だと思う
最近、AWSさんからPolicy Deprecation Noticeのメールがよく来ています。そんな事言われても…と思っていたのですが、サクッと調べる方法があったのでメモしておきます。(ポリシーはDeprecationになっても、使えなくなるわけではないのですぐに対応が必要ではないようですね)
例えば以下の記事に書いてある「AWSLambdaReadOnlyAccess」 と 「AWSLambdaFullAccess」というAWS管理ポリシーってどこで使っていたかな。調べたい。というときは docs.aws.amazon.com
IAMのマネジメントコンソールで、AWSLambdaReadOnlyAccessを調べるとポリシーARNを得ることができます。 ポリシーARNがあれば、AWS CLIのaws iam list-entities-for-policyを使えば一発です。「指定したマネージドポリシーがアタッチされているすべてのIAMユーザー、グループ、およびロールを一覧表示します。」と機能説明にあります。 docs.aws.amazon.com
$ aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AWSLambdaReadOnlyAccess --profile hoge { "PolicyGroups": [ { "GroupName": "Admins" } ], "PolicyUsers": [ { "UserName": "Bob" } ], "PolicyRoles": [ { "RoleName": "testRole" } ], "IsTruncated": false }
Policy Deprecation Noticeを受け取って調査しようとするまで、この機能があることに全く気がついていませんでした。この方法であれば、複数のAWSアカウントがあってもprofileを切り替えるだけでよいのでPolicy Deprecation Noticeを受け取ってから調査までを自動化することもできそうですね。
ここで扱うレガシーシステムは、ソースコード的なものは含みません。主にサーバやシステムのことを指します。そのためレガシーソフトウェア改善ガイドや、レガシーコードからの脱却といった書籍の内容なども登場しません。メンテナンスが行き届かずOSやミドルウェアのEoLを迎えてしまい、泣く泣く再構築することになった体験による工夫がメインのお話です。
プロキシサーバ移転、メールサーバ移転、社内DNS管理システムの置き換え、Nagios廃止、NFSサーバマネージドサービス化など
レガシーシステム撤去と立ち向かっている途中からは、SREが二人組としてタスクに取り掛かるバディ制度が取り入れられました。後述しますが、レガシーシステム撤去をするうえで二人組で取り掛かれるのはとても心強かったです。複数のバディから構成されるSREチームに自分はいます。
再構築と撤去をするシステムごとに見積もりとタスク分解をしてドキュメントにまとめました。ドキュメントをもとにチームに説明しました。ボツ案もチームに共有することで、チームに対してどこまで技術的な検討をしたのかを共有できました。ボツ案という、実行可能なアイデアのうち最低のものを共有することでチームメンバーに安心感を持ってもらえる効果もあったように思います。
バディを組んだ相手が得意なムーブがこれでした。レガシーシステム撤去作業前後の図を書くことで、システムを構成する要素の変化が伝わりやすいです。我々は忘れやすいので、数ヶ月後の自分たちも助ける効果があります。
レガシーシステムについての知見はまとまっていてもドキュメントが古くなっていたり、ドキュメントが無かったり、ドキュメントされていない機能があったりします。コード管理されているのに、実際のサーバ上でコードが編集されていてドキュメントとの乖離があるということもありえます。
こうした背景がレガシーシステムの撤去を難しくしています。また、その前段階であるシステム考古学とでも言いたくなる先人の活動の調査や、システムの変化を追っていく作業を難しくしています。
こうした背景があるため、バディで行った見積もりとタスク分解の結果や、作業前後の図が、誤った前提知識や認識により作られた可能性を排除できません。そのために作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件がないか見てもらうというステップを設けています。
ここまでが自分や自分たちがやってきたレガシーシステム撤去の作業上の工夫でした。ここからは所感コーナーです。
レガシーコードの撤去は、使われるかどうかはリリースした後にしかわからない新機能開発に比べて事業貢献になりやすいと友人が言っていました。対象についてのコストやレガシーっぷりがわかっており、やればいい状況であるからということでした。自分も同意する意見でした。レガシーコードであっても、レガシーシステムであってもあてはまるように思いました。しかしアピールしやすいかどうかで言うと、単純な作業をしたと捉えられやすいためにアピール方法は工夫する必要がありそうです。(自分も良いアピールができているとは思えないので、具体的な工夫の方法については書くことができません)
レガシーシステム撤去は人によっては精神的な負荷が高いと感じました。先人の活動の調査や、システムの変化を丁寧に追っていく(システム考古学と呼びたくなる)一連の作業は、記憶力の悪い人間(自分)にとっては混乱してしまうことが多くありました。精神的に負荷でした。ここに関しては特にバディ制度に助けられました。幸運なことに僕のバディはこういった作業が得意であり、社歴が長いため知っている過去の経緯も多かったからです。
レガシーシステムの撤去は、本質的には本当に捨てていいのかという声との戦いであると思います。調査に時間と労力がかかってしまうことや、必要な確認事項はすでに完了しているのに捨てるアクションを取れていないということがレガシーシステム撤去のブロッカーとなっているのだと思います。事前に合意が取れている確認事項をつぶせたらサクッとつぶす必要があるように思います。そうしないとさらに年単位で生き長らえる可能性があります。それがレガシーシステム撤去の怖いところであるように思います。
この記事に書いた内容が、誰かのレガシーシステム撤去に役立てばうれしいです。
最近投資の勉強をしている。これまでよりも力を入れている。他の理由もあり財務諸表の見方を学んだりしている。
これまでの投資の様子を振り返ってみる。
20代後半は自由なお金が少なかった。NISAが出たばかりの頃くらいから毎月積立で投資信託を数百円か千円くらいずつ買っていた。ここらへんから投資の面白さに気がつく。
投資信託買い続けるのを数年続けていたら、ある程度溜まってきたことや、景気が良かったこともあり一部売って株を買う原資にしたりし始めた。
プチ株で買っていたのが単元化できるまでに育ち、航空会社の株主優待券をもらえるようになった。
結婚してお金を使わなくなったので、NISA枠を使い切ることにした。毎日微量の投資信託を買うようになった。マネーフォワードに証券口座や確定拠出年金の口座を登録しておいて日々成績を見るのが趣味になってきた。
PCゲームをやるのでグラボ大事だよな思っていたのと、最近のAIブームもありGPUの需要高まってるしと適当な理由をつけて微量のNVIDIAの株を買って放置しておいたら2倍以上になっていて、米国株いいじゃんとなった。とはいえバブル感あるような気がしていて怖さも感じている。
これまでの投資について振り返ってみた。ごく少額の積立から始めたけど今はその数十倍以上になっている。これから始めてみようかなという人の参考になればうれしいし、こうした会話ができる人がまわりに増えたら更にうれしいと思う。
一方自分の投資の仕方はなんとなく売買してる感じが強い。投資についてさらに勉強し、売買する理由を強化して、結果を振り返れるようにしてもっと投資やっていきたい。
https://twitter.com/hokkai7go/status/1347466542603096066
以前から人事評価というプロセスが苦手で、アピール下手だし、評価面談では手が冷えたり変な汗をかくということが何年も続いていました。社会人経験が長くなるにつれて少しずつうまくなった部分もあるでしょうし、最近は過度な期待をしないように自分の中で調整したことや、日々目標を追えるようになってきたこともあり、だいぶ安心して評価面談にのぞめるようになりました。しかし、冒頭のツイートのように再発してしまっていたようでした。
リモートでの評価面談というものに慣れていないからなのかもしれないし、単に今日は寒かったからなのかもしれません。なんとか苦手意識を克服したいけど、なかなか手強いなと感じた一日でした。うまくやれる人の方法や考え方を学びたいですね。