History

概要

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

基本的な情報。

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

技術スタック

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

OSS活動

職務経歴詳細

経歴の全体像を示す。

20240430-history.drawio.svg

Figure 1: 経歴の全体像

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

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

   
概要 3D GIS(デスクトップ版 = Windowsネイティブ版)の開発
背景 自治体などに納入する3D GISのデスクトップ版の開発
フェーズ 開発 → 自治体への納入 → 運用および追加開発
チーム規模 バックエンド1人(自分)、複数他社のフロントエンド開発者5~10人、開発元会社のPM1人
制約 クラウドサービス使用不可(AWS, GCP, GitHub)、本番環境(Windows)でのインターネット接続不可
担当範囲(横) バックエンドサーバ開発、ランチャー開発
担当範囲(縦) 要件定義、設計、コーディング、テスト、レビュー
使用技術 Go, Linux, Windows, GitHub Actions
期間 2023-10 ~ 現在

業務の詳細。

  • ↓Web版の続き
  • バックエンドサーバを全く同じAPI仕様のまま、PHP->Goへ書き直して移行した
    • Web版とデスクトップ版を共用するため
    • 顧客のPCでミドルウェアをインストールさせるのが不可能だった。バイナリ1つでアプリケーションサーバを動作できること、Webまわりのライブラリや知見が充実していることが選定理由
  • アプリケーションに関する複数のプロセスを管理するランチャー開発
    • 分離したバックエンドサーバ, GISフロント, 管理画面を直感的に扱えるようにする

苦労したこと。

  • Web版と同じ
  • ランチャーで必要な非同期処理や排他制御まわりが慣れておらず、やや難しかった

アピールポイント。

  • プロダクトの要件により、クロスプラットフォーム(Linux, Windows)、マルチDB(SQLite, PostgreSQL)対応。CIによって、複数の組み合わせでの安定動作を達成した
  • ランチャーの結合テストとしてシェルスクリプトでもテストを書いた。CIでWindowsでテストして検証できるようにした
  • 高いテストカバー率
   
概要 3D GIS(Web版)のバックエンド開発
背景 自治体などに納入する3D GISの開発
フェーズ 新規開発 → 自治体への納入 → 運用および追加開発
チーム規模 バックエンド1人(自分)、複数他社のフロントエンド開発者5~10人、開発元会社のPM1人
制約 クラウドサービス使用不可(AWS, GCP, GitHub)、本番環境(Linux)でのアウトバウンド接続不可
担当範囲(横) API仕様策定、バックエンドサーバ開発、Linuxサーバ構築/保守
担当範囲(縦) 要件定義、設計、コーディング、テスト、レビュー
主要技術 PHP, PostgreSQL, Apache, Linux, GitHub Actions, Docker
期間 2022-12 ~ 2023-10

業務の詳細。

  • 他社の製品開発の責任者から要件をヒアリングし、Webで3D GISを作る
  • バックエンドサーバ・Linuxサーバまわりを単独で要件定義、仕様策定、システム設計、実装
    • 例…
    • GIS表示および管理画面に必要な項目一式
    • 認証機能
    • 地物の段階的な絞り込み検索機能(例: 市 → 大字 → 小字 → 番地 → XY座標)
    • Apacheのチューニング。キャッシュ・接続再利用・圧縮をさまざまな拡張子ごとに設定した。非常に地物ファイルのサイズが大きく(ギガバイトレベル)、ネットワーク速度も比較的遅かったため必要となった。クラウドサービスは利用できないなかで、Webサーバのチューニングがパフォーマンスに大きく影響した

苦労したこと。

  • 自治体向け製品の制約(LGWAN)で、本番環境はインターネットに出られない
    • したがってデプロイ時は変更したソースコードさえも、手元のマシンから直接送信しなければならない状況(バージョン管理システムもつながっておらず、直接転送するしかない)
    • インターネットがつながる社内マシンでソースコードを含めたDockerイメージをビルドし、Dockerイメージをtarで固めて送る + Dockerイメージをtarからロードするスクリプトを書いた
    • パッケージインストール(yum や apt)すらできないので、依存関係を固める + ローカルインストールするスクリプトを書いた
  • 開発元会社の制約で、開発時も基本的にクラウドサービス等が利用できない
    • AWS, Docker Hub, GitHub等は チームとして 利用できない
  • 依頼元の強い要望で、新規開発ではあるが非常に古いバージョンのプログラミング言語、Webフレームワークを使用した。情報が出てこなかったりライブラリがないので苦労した
  • チームで1人の担当が多かったためコードレビュー相手がいないためセルフレビューで頑張っていた

アピールポイント。

最大のアピールポイントは、他社のプロジェクト管理者へのヒアリングで背景を理解したうえで要件定義や設計を取りまとめ、文書による合意を得ながらやった部分。自分から関係者の日程を押さえ会議を開催するところから行った。開発元会社のPMからは「積極的に提案・設計・開発を進めてもらって非常によかった、素晴らしい進め方だった」との評価をいただいた。

  • Webに知見のある開発メンバーがいなかったので、Web文脈において主導的な役割を果たした
  • OpenAPIでスキーマ駆動開発をリードした。フロントエンド用SDK/サーバコードを生成して効率的に開発した
  • ネットワークの強い制約のなかで、シェルスクリプトでデプロイを自動化した。結果、本番環境での作業ミスが発生しなかった
  • 開発元の製品開発の責任者と頻繁に会議を企画するようにした。会議に加えて文書による合意を常にとり、トラブルや認識ミスが発生しなかった
  • 積極的に背景理解のための質問をし、ビジネスを含めた文脈や制約を理解したうえで提案を行い、多くが採用された
  • 開発元 → 顧客への納品を遅延なく完了した
  • CIによってテスト漏れや生成ミスなどを防いだ
  • 高いテストカバー率

株式会社資格スクエア(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環境移行
    • 中規模のテーブル移行を伴う機能改修プロジェクト担当

テンプレート

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

業務の詳細。

苦労したこと。

アピールポイント。

どうなりたいか

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

職業キャリアは、めざす「職種 x 専門領域」で表現できると考えている。どの山に登るかと、どの峰を目指すか。

職種。自分の中でだいたい決まっている。

  • MUST プログラマー(専門職)
    • 数年間実際に手を動かして開発してきて、楽しさ、やりがいを感じているから
    • プライベートでの趣味と仕事を相互に活かせるから。何かを作るのが好きである
  • SHOULD バックエンドプログラマー(必要であれば何でも学んでやる)
    • 今までバックエンド開発をやってきて経験と実績がある。安定して価値を提供できる可能性が高い
    • 見えない業務ロジックを明らかにしていくことを楽しく感じる

専門領域。まだ曖昧である。

  • MUST 専門領域の形「T型」

    専門領域の形状は決まっている。専門領域の広さを持ったうえで、そのなかで1つコアな(興味と実績のもっともある)分野を持ったプログラマになりたい。まだ専門領域の位置は決まっていない。

    ここでいう「分野」の 例 。

    • 「高トラフィック対応に強い」
    • 「動画配信技術に強い」
    • 「WASMに強い」
    • 「レイヤの境界線(OS - ミドルウェア間など)の不具合を解決できるスキルがある」

    コアな分野を持ちたい理由。

    • 難しい問題に取り組める可能性が高くなる
    • 文脈を理解したうえで最先端を追ったり作っていくのはやりがいがありそう

専門領域は、すぐに得られない。段階を踏んで形成する必要があるように見える。

  1. 難しい、興味の持てる仕事や学習をする (👈今ここ。プライベートも多く含む)
  2. 実際にやっていくうちに、興味や縁によって「分野」が いつのまにか 決まっていく
  3. 1つ強い分野を持つプログラマとして縦横をさらに深めていく

というステップになるだろうと考えている。詳細に計画できるものだとはみなしていない。キャリアの全体観の中で、今の段階はまだ<1>である。

深めるための下準備として、コンピュータの基礎的な仕組みについてプライベートで勉強している。

会社選びの軸

軸は、じゅうぶんに振るい落とせるものでなければならない。

  • MUST 開発経験を活かせる
    • バックエンド開発という職種経験や経験のある技術スタックを活かせること
    • 成果を安定して出せる可能性が高いから
    • 活かしつつ、少しづつより難しい/面白そうな分野に挑戦できるのがベスト
  • MUST 会社として優れた技術力がある
    • 熱意や優秀さは集団の中で伝播していくと考えている。経験的に、ともに働くメンバーが自分の成長に大きく影響をもたらすことが多い
    • 会社やチームとして働き、ナレッジを共有していける体制がある可能性が高い

  • SHOULD コンピュータ資源や開発技術が商材となる業界や会社

    理由。

    • もっとも興味があり、実際に多くの時間をかけているのがコンピュータである。※今まではそういう認識がなかった
    • ビジネスに興味を持ちやすく、自分ごととして理解しやすい
    • Web開発・バックエンド開発以外にも、専門的な仕事と関連する可能性が高い。少なくとも社内でそうした職を持つ人にお近づきになれる

    チームレンタルとしての技術サービス提供、も含む。

    • 受託での新規開発の経験をして、まったく知らない分野で顧客と協力しながら新しいものを作っていく体験はよかったと感じた
    • 自社プロダクトの会社と比較して、新しめの技術経験や設計を行いやすいのを好ましく考えている
    • 多くのプロジェクトを経験しやすい

興味・関心

プライベートの、興味の方向性を示す。すぐに仕事につながるとは考えていない。

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

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

  • 自分が使うものを作る

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

やりたいプロジェクト

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

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

大切にしていること

選択するうえで大切にしていること。

  1. 好きなことをやる

    好きなことをやっているときが一番幸福で、能力を発揮できると考えている。好きにも程度があって、金を払ったりリスクを負っても追い求めるくらい好きなこと、を見つけてやり続けることが大切だと考えている。例えば昼はバイトをして夜演奏するミュージシャンは、好きの程度が非常に高いと考えている。

  2. 難しいことをやる

    難しいことを選択していれば、ほかの選択肢が閉ざされるのを後回しにできる。やりたいことに出会ったとき諦める可能性が少ない。なので、迷ったらとりあえず難しいほうを選択するのがよいだろうと考えている。

どちらもIT投資家ポール・グレアムの何かのエッセイで言っていたことで、ずっとこうやって選ぶようにしている。

プライベート年表

2024年

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

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