今年を振り返る「なんかかく」アドベントカレンダー 9 日目です。
今年というより来年、2025 年は きのこカンファレンス2025 というやつがありますね。ぼやっと、私だったら何が話せるかなと思って考えてみた内容が、2007 年か、2008 年位の頃に経験したデータベース マイグレーションの話です。きのこカンファレンス自体への手挙げは採用にいたらなかったので (私は若輩者でした。笑)、そこで考えていた話をここで少し掘り下げてみます。
結論
個人のキャリアの 8 割は予想しない偶発的なことによって決定されるということを「計画的偶発性理論」というそうです。前任者の突然の退職とか、突然の異動とかはむしろ誰がやっても失敗するという期待値最低の状況なので、むしろ新人が飛び込むには絶好のチャンス という考え方にもつながるかもしれません。何しろ私もそれで技術楽しめるようになったクチだよ、という話です。
想定読者
なんとなくこの業界に来たけど、技術ツライ、こわいと思っている人
自分は技術で何を話せるか
学生時代を振り返ると私、もともと IT エンジニアになりたい気持ちはありませんでした。単に氷河期の就職難で、たまたま見つけた就職先が IT の会社だったというだけです。しかしそのような中で組織論でもキャリア論でもない、私の経験した技術領域で、最も学びのきっかけになったもの。考えてみると私の場合、一番のきっかけはデータベースだなと感じています。
とある一つのデータベース仕様に深く依存した業務アプリを、別のデータベース向けに載せ替えるということを行うプロジェクトでした。何が大変かというと実態は、100、200 どころではないストアドプロシージャが検索効率の中で両データベースへの負荷に大きな差を生み出していて、ならばそれを再構築しよう、という作業になったから。
SQL に少し詳しい方はご存じであろう to_char、to_date といった関数を、自前でつくる作業です。何が面白かったかといえば、およそすべてのプログラムに影響が出るそんな重大な調査や作業を、たまたま私に任せていただけたのでした (たまたま手が空いていたから声がかかっただけな気がしますが、そこが偶発性)。
これです: フロントエンドを100000000倍速くした(ﾟ∀ﾟ) - Oracle10g・DB2 V8.2時代の記錄 #oracle - Qiita
だがしかし、20 年近くこの界隈に居座った今 でもこの辺の知識や経験がすごく自分の自信になっています。
技術は怖いものではなくたのしいもの
データベースはどのようにして SQL を解読して実行しているのか。例えばそれがストアド プロシージャ、関数だったら、パフォーマンスをどう効率化できるのか。キャッシュあり、リコンパイルあり、実行計画の取り方など、文字通り試行錯誤してテストしました。日本語情報も無いですし、時にはサポートに問い合わせて最終的に Patch を発行してもらうこともありました。
RBDMSごとのダミーテーブルについて #SQL - Qiita
極端な例で確認する SQL Server のストアドプロシージャのリコンパイル #SQLServer - Qiita
Hotfixes - IBM Documentation
まあ最終的にどうやって実際解決したかというと結構力業で、一個一個時間かけてテストケース書くっていう作業を地道にやりました。AI が当時あればもう少し人道的に解決できましたが。それでも当時感じた深掘りすることのたのしさ。
たのしい から 「もっとやれるかも」へ
データベースがきっかけで、周辺にある基盤部分のプログラムを解読する胆力ができました。アプリケーションサーバー、ロードバランサーの仕組み、セッション管理の仕組み等々。「先輩が退職してしまった」とか、「担当者が異動してしまった」とかいう状況もそれなりにありますが、それはどうせ誰がやっても失敗するタイミングです。思い切って手を挙げて新しいことに挑戦するのに、むしろチャンスと言えます。
人事システム「COMPANY」のバッチ処理の裏(側) の話 #トラブルシューティング - Qiita
思い切って担った技術領域は将来もずっと飯のタネになる
ソフトウェアエンジニアとしてキャリアの螺旋を駆け上がる方法 - 経験と出会いが人生を変える / Career-Anchor-Drive - Speaker Deck
出会いには人生を変える力がある
最近こんなスライドを拝見しました。それが冒頭の「個人のキャリアの 8 割は予想しない偶発的なことによって決定される。その偶然を計画的に設計し、自分のキャリアを良いものにしていこうという考え方」、計画的偶発性理論という話です。
計画的偶発性理論 - Wikipedia
関連？: セレンディピティ - Wikipedia
なんとなくで仕事をしていた私にとっての 計画的偶発性理論 の体験はまさにこのデータベース載せ替えプロジェクトで、その後のアプリケーション基盤の探求につながる旅の入り口というやつです。この経験があるので、検索、試す、英語も含めて過去の情報の在りかを探す、人に聞くなどなどすべて、解決への引き出しが増えたし、いまでもたまにデータベース関係を触ると楽しいなと思います。こういうのも楽しいよ: SQL Serverトラブルシューティング に関するドキュメント | Microsoft Learn
この
先
生
きのこる「原点」というやつの話でした。以上です～