History

概要

職業プログラマーとしての履歴や展望を記載する。20241128-kijima.png

基本的な情報。

   
氏名 貴島 大悟 Kijima Daigo
生年月日 1998-03-28
居住地 東京
最終学歴 鹿児島大学 法文学部
GitHub kijimaD

技術スタック

メインでバックエンドサーバ開発、サブでインフラ領域まで業務を行ってきた。今後もバックエンド領域に注力していこうと考えている。

OSS活動

職務経歴詳細

経歴の全体像を示す。

20240430-history.drawio.svg

Figure 1: 経歴の全体像

会社ごとに、参加したプロジェクトを列挙する。

株式会社リアルグローブ(2022-11 ~ 現在)

   
概要 地図系SaaSの開発
フェーズ 仕様変更および追加開発
チーム規模 3人程度
担当範囲(横) 主にバックエンド開発
担当範囲(縦) 設計、コーディング、テスト、レビュー
使用技術 Go, React, GitHub Actions, AWS(Lambda, CloudFront, Aurora…)
期間 2024-09 ~ 現在

  • アプリケーション概要

    巨大な階層型組織の権限構造に合わせた、複雑な権限管理が可能な地図アプリケーション。REST APIによるSPA。

  • 担当詳細

    リリース後のフェーズで参加し、大規模な仕様変更…要件の変化による、権限構造の改修…を主に担当した。今後のビジネスや販売プランに合わせて変更の可能性が高い部分を見極め、今後の変更に対応できるように再設計した。 仕様変更前に、テスト全体の改修やテーブルを整理した。各ケース個別の変更が難しくなっていたテストを、各テストケースでレコードを用意するように変更し仕様変更に対応しやすくした。そのあと仕様/実装変更に着手し、バックエンド、フロントエンド、ドキュメントを修正した。

  • アピールポイント

    粒度の異なるテストで守りつつ、仕様変更にかかる破壊的変更がなるべく少なくなるよう設計/段階的に実装した。稼働中のシステムへの影響を最小限にしつつ安全に作業を進めた。実装は期限内に完了し、仕様内容にかかる不具合が発生しなかった。事前事後のリファクタリングも含めて全体で半年ほどの期間がかかったが粘り強くやり切ることができた。

    人為的ミスを防ぐための各種CIの修正や追加した。テスト追加忘れ、OpenAPIやDBスキーマドキュメントの生成忘れを検知できるようにした。

    こまめな設計の共有や相談、焦点の明確なPRの提出によって、作業の手戻りが発生しなかった。

   
概要 3D GISの開発(3DのGoogleMap的なもの)
背景 開発元企業に出向し、自治体などに納入する3D GISのデスクトップを開発した
フェーズ 開発 → 自治体への納入 → 運用および追加開発
チーム規模 バックエンド1人(自分)、フロントエンド開発者5~10人、PM1~2人
制約 クラウドサービス使用不可(AWS, GCP, GitHub)、本番環境でのインターネット接続不可
担当範囲(横) バックエンドサーバ開発、ランチャー開発
担当範囲(縦) 要件定義、設計、コーディング、テスト、レビュー
使用技術 Go, Linux, Windows, PostgresQL, Apache, GitHub Actions
期間 2022-12 ~ 2024-10
  • 開発元会社の既存製品の3D GISの仕様をもとに、新しくWebアプリケーションを開発する業務
  • バックエンドサーバ(Go)まわりを単独でシステム設計、実装、運用
  • 例: 権限、認証、ブックマーク、住所絞り込み検索、エクスポート、静的ファイル配信…
  • ※3D GISに必要な地物ファイル読み込み、描画や計測などの機能はすべてフロントエンド(Unity)がもっており、バックエンドサーバは地物データの内容と関与しない構成となっている
    • フロントエンドが生ファイルを取得し、描画する構成。バックエンドサーバはURLその他の管理データの保存を担当する

苦労したこと。

  • 自治体向け製品の制約(LGWAN)で、本番環境はインターネットを使用できず、マネージドサービスを利用できない点
  • 組織の制約で、インフラ部分は一切設定を変更できない

アピールポイント。

  • 納品を遅延なく完了した
  • 高いテストカバー率で、導入後の不具合や障害が発生しなかった
  • プロダクトの要件により、クロスプラットフォーム(Linux, Windows)、マルチDB(SQLite, PostgreSQL)対応。CIによって、複数の組み合わせで検証した
  • Web方面にもっともスキルがあるエンジニアとしてチームをリードした

株式会社資格スクエア(2021-12 ~ 2022-08) ⚠ 会社分割による移籍で、業務内容は変わっていない

   
概要 資格教育サービスの開発
背景 難関資格取得を目指す顧客の勉強や添削をサポートするサービス
フェーズ 保守、機能追加
チーム規模 5人程度
制約 会社分割/チーム縮退のため部分的に知見のある開発者がいない部分がある
担当範囲(横) バックエンド、インフラ
担当範囲(縦) 設計、コーディング、テスト、レビュー
使用技術 Ruby on Rails, ECS, EC2, GitHub Actions
期間 2021-12 ~ 2022-08

会社分割による、株式会社サイトビジットからの移籍。業務内容は変わらない。

  • プロジェクト
    • マイページをリプレイス(5人程度のチーム)
      • リプレイスのベースとなる部分のAPI担当
    • 本番サービスコンテナ移行(単独)
      • 稼働中のRailsサービスをEC2 → ECSへ移行した
      • 数年間EC2インスタンスで稼働していたRailsサービス
      • CI/CDも含めて切り替え
      • ダウンタイム・障害なし
    • サービスのメイン機能リプレイス(5人程度のチーム)
      • API担当
  • 特筆事項
    • 開発環境のdocker-composeの整備を行い、WEB開発をすべてDocker上で行えるようにした
    • CIテストで本番環境に準拠するDockerイメージを作成し使うようにした。本番環境に近い形でテストを行えるようにした
    • 本番環境のアップグレード。Ruby 2.7.1 -> 2.7.4, Rails 6.0 -> 6.1。
    • 1月度のMVPを受賞した

株式会社サイトビジット(2020-10 ~ 2021-12)

   
概要 資格教育サービスの開発
背景 難関資格取得を目指す顧客の勉強や添削をサポートするサービス
フェーズ 保守、機能追加
チーム規模 8人程度
制約 サービス開始から数年経過し、部分的に負債が溜まっている部分がある
担当範囲(横) バックエンド、インフラ
担当範囲(縦) 設計、コーディング、テスト、レビュー
使用技術 Ruby on Rails, ECS, EC2, GitHub Actions
期間 2020-10 ~ 2021-12
  • 特筆事項
    • バックエンド、フロントエンド、テスト、インフラの業務を行った。既存の中規模リポジトリの保守運用
    • テスト開発のリーダーとしてテストを書きまくり、RSpecカバレッジ率を向上(78% → 90%)させた。カバレッジ率を定期的にアナウンスすることで、チームに浸透させた。
    • 失敗率の高いテスト修正によるCI安定化
    • YouTube Analyticsを独自に詳細分析するGASプログラムを作成
    • 古いバージョンのRedashのデータ移行を伴うDocker環境移行
    • 中規模のテーブル移行を伴う機能改修プロジェクト担当

テンプレート

   
概要  
背景  
フェーズ  
チーム規模  
制約  
担当範囲(横)  
担当範囲(縦)  
使用技術  
期間  

業務の詳細。

苦労したこと。

アピールポイント。

RAQ

キャリアをどう考えているか

どういったキャリアを考えているかを示す。

  • MUST プログラマー(専門職)
    • コードを書いたり設計するのが好きだから
    • プライベートでの趣味と仕事を相互に活かせるから。何かを作るのが好きである
  • SHOULD バックエンドプログラマー
    • だけ、というわけではないがメインにしたい。必要に応じてフロントエンドでもインフラでもやる
    • バックエンドはシステムに必須だから(究極的にはフロントエンドは必要ないと考えている…)
    • 数年間実際に手を動かして開発してきて、楽しさ、やりがいを感じているから

会社選びの軸は何か

業界から候補にするケースと、ポストから候補にするケースがある。

  • MUST: 必須
  • SHOULD: あればいいくらい

業界。

よいアプリケーションを作るには、そのアプリケーションが置かれた文脈、ビジネスサイド知識が必要である。が、業務時間だけで業界の背景から学ぶのは難しいことが多いので、プライベートの時間を使わなければならない。そのとき、興味あるいは個人として役立たなければ取り組むのは難しく感じる。

  • SHOULD 知的好奇心が持てる
    • 実際に何冊か本を読むなど取り組んでみて、より深く知りたいと思える
  • SHOULD 個人として役立つ
    • 普遍的な領域は確実に役立つのでモチベーションになる。たとえば法律、会計、語学など

具体的な業界候補。

  • SHOULD 不動産
    • 不動産事業を行う予定があるため。利益関係者の多い業界で一部でも不動産業界に詳しくなっておくことは意味があることに見える
    • 大きな額が動く割に(パイが大きい割に)、まだITが食い込める余地があるように見える
  • SHOULD 金融
    • シビアな要件においてどのように設計するか、実装するかは学びになるだろうと考えている。また、個人の生活やビジネスにおいても強みになるように見える
    • 世の中を理解する視点として役立ちそうに見える

会社。

  • MUST 開発経験を活かせる
    • 経験のある技術スタックを活かせること。成果を安定して出せる可能性が高いため
    • 活かしつつ、少しづつより難しい/面白そうな分野に挑戦できるのがベスト
  • MUST 会社として優れた技術力がある
    • 熱意や優秀さは集団の中で伝播していくと考えている。経験的に、身近な優秀な人に刺激を受けることが多い
    • ナレッジを共有する文化や体制があると、自分が新しいことを得たり、他者を助けることができる

ポスト。

  • SHOULD 専門性の高いエンジニアリング分野であること
    • 配信基盤、認証基盤、超高トラフィックサーバといった技術クリティカルな分野。個人的な興味と合った高度な分野に取り組めるのはよさそうに見える。数が少なく競争率が高いので、あまり重視していない

プライベートの興味・関心

プライベートの、興味の方向性を示す。現実でやっている仕事と100%一致しているわけではない。

  • 低レイヤの知識が必要な領域

    コンピュータに関する疑問を出発点としていくつか学んでおり、おもしろさを感じている。これを仕事に活かしたいと考えている。コンピュータに関する知識は、根本のアイデアはとてもシンプルなことが多く見える。理解できたときに嬉しさと美しさを感じる。また、知的好奇心を満たしてくれるのとともに、アプリケーションレベルの問題解決に役立てることができる。直感的でない挙動を理解したり、あるいは応用可能な強力な基礎となって設計や実装に役立てることができる。あくまでアプリケーションを作るうえでの武器にしたい、そういう知識が必要になるアプリケーションを作りたいということで、低レイヤそのものを仕事にしたいのとは微妙に異なる(能力も足りていない)。

  • 自分で使うツールを作る

    プログラマーが使うツールやライブラリの開発に興味を持ち、知識を深めている。たとえば、Linter/プログラミング言語/CI/Emacsプラグイン…などがある。余暇にいくつかのツールを開発しているが、ほとんどのケースは自分が必要にかられたことをモチベーションとして開発した。Web開発者としても、プログラマーがターゲットになっている、ドッグフーディングできるようなサービスに参画できるのがベストだろうと考えている。

やりたいプロジェクトの方向性

やりたいと考える傾向があるプロジェクトを示し、価値観や方向性を表現する。細かく言い出すと無限にあるので、もっとも重視する3つを挙げる。あくまで「やりたい」であって、条件ではない。

  1. SHOULD 製品を自分で使えるプロジェクト
    • 余暇で作ってきたものはほとんど自分が使うもので、モチベーションを高く保ち続けてきた
    • 自分で使うことによって、使うプロダクトやユーザを理解できる。そして作り直しながら使うことで、モチベーションを高められる
  2. SHOULD 自分の意見を出す余地がある、出しやすい雰囲気のあるプロジェクト
    • 製品の文脈や背景を理解し、自分やチームが納得、合意したうえで開発を進めていきたい。視点の数と多様性によってよい製品になると考えていて、自分もその視点の1つとして責任を果たせると思っている
  3. SHOULD コンピューティング自体が本質的価値であるプロジェクト
    • 例. IaaS, CI, CD, Monitoring, Logging, ミドルウェア開発…
    • コンピュータに興味が強い(製品の本質的価値と興味の適合)
    • 開発に比較的低レイヤーの知識を必要とする傾向があるとよい(必要となる技術領域と興味の適合)

勤務規則に必要なこと

  • MUST ホストマシンにLinuxがインストールされたPCで仕事ができること。ウィンドウマネージャが自分の使い慣れた環境(EXWM)でないと、キーバインドがすべて違うので作業が難しい
  • MUST 週1~2回程度の出社頻度であること。移動に時間を取られたくないのと、静かな環境でないと集中できないので。また、会う頻度が少なすぎても関係を広げたり、会社やチームとしての一体感を感じるのが難しいと感じるため

プライベート年表

2025年

  • 自作RPG ruinsの機能追加した
    • 戦闘システムを追加した
  • トレーディングカード風画像ジェネレーターtcgを作成した
  • na2meを拡張した
    • タグを機械的に追加する機能を追加した
    • 画像を共通のサイズへ切り出し・フィルタ処理をかけられるようにした。背景画像の準備を楽にした
    • 夏目漱石以外のほかの本も追加した
    • しおり機能を追加した。ファイル/ローカルストレージによって永続化する
  • 長期休暇を取り1ヶ月アメリカを旅した
    • ロサンゼルス → ラスベガス → サンフランシスコ → シカゴ → ナイアガラ(アメリカ) → ナイアガラ(カナダ) → ニューヨーク

2024年

  • ElectronとGoでRSSフィードビューワsquallを作成した
  • ローカル用のPDFビューワshelfを作成した
  • 自作ローグライクRPGの機能追加した
    • 吉里吉里Zライクなシンタックスで記述できるメッセージシステムを追加した
    • インベントリシステム(使用、装備、取得、廃棄)を追加した
    • フィールド上を移動できるようにした
  • X Window System用のスクリーンルーラーxrulerを作った
  • ノベルゲームエンジンnovaを作成した
  • 自作ノベルゲームエンジンで夏目漱石の作品を記述したna2meを作った

2023年

  • GitHub Actionsライクなシンタックスで書けるタスクランナーgorunを作成した
  • CLIでパズルゲームの倉庫番を楽しめるsokobanをスクラッチで作成した
  • OpenAPIバリデーションツールoavを作成した
  • ミニマルなCPUエミュレータminicpuを作成した。本を参考に、Goで書き直した
  • nand2tetrisのアセンブラをGoで書いた
  • 高速な通知ビューワgarbanzoを作成した
  • 手作りのWebサーバgsrvを作成した
  • 環境構築スクリプトをGoで書き直して、共通部分をライブラリ化した(silver)
  • Gitタグを元にファイルに記載されたバージョンを書き換えるコマンドラインツールcarveを作成した
  • Goのアセンブリコードを出力するorg-babel拡張ob-go-asmを作成した
  • tinyfilemanagerにファイルアップロードするコマンドラインツールuplを作成した
    • ブラウザでのアップロードが制限されている特殊環境で、Tiny File ManagerがAPIリクエスト非対応だったため作成した…

2022年

  • このサイトの開発環境・自動テスト・デプロイをDockerコンテナで行うようにした(ビルドがEmacs, Ruby, Python, sqliteに依存する)。本番環境のGitHub Pagesへの展開と、ステージング用のHerokuへのコンテナデプロイ
  • リポジトリの更新されていないファイルをコメントするGitHub Actions、 StaleFileを作成した。GitHub Marketplaceで公開した
  • パーマリンクからコードを展開するEmacs拡張ob-git-permalinkを作成してMelpaに投稿し、マージされた。
  • ローグライクdigger_rsの作成(WIP)
  • 自分用にカスタマイズしたUbuntuのisoイメージを作成した。USBに焼いて、すぐ自分用のクリーンな環境のマシンを作れるようになった
  • 設定ファイルからgit管理してgit cloneを行えるgcloneを作成した
  • GitHubの活動統計をとるactを作成した
  • actを使ってリポジトリに情報を蓄積するcentralを作成した
  • GitHubの言語の色に基づいたSVGバッジを生成するmaruを作成した
  • ライフゲームwebアプリgolifeを作成した
  • GitHubのコードレビュー返信ツールgarを作成した
  • Emacsの設定ファイルを文書化した

2021年

2020年

2019年

2018年

  • 村上龍にハマり、彼のすべての小説、エッセイを読んだ。

2017年

  • WordPressでサイトを運営していた。

2016年

  • 鹿児島大学(法文学部/経済情報学科)に入学した。
  • 北京の清華大学に語学留学した(半年間)。

2015年

  • Linuxに出会い、メインOSとして使いはじめた(以後ずっと)。
  • Emacsと出会い、学びはじめた。(きっかけは図書館にあったPerlの本で推していたこと)

References

Backlinks