次に最もやりたい仕事・役割
- 大規模なレガシー改善: 達成してきた実績があるので自身がある
- チーム開発におけるプロジェクトマネージャー的役割
- 自分にとって挑戦的である
- 自分一人が達成する作業量 よりも プロジェクト全体を通して効率化・安定化を達成することに興味が移ってきた
職務要約
自分が他のエンジニアより強いと思う仕事
- システムの機能の把握とキャッチアップ
- 機能やコードの違和感に気づいてマメに行動に移す
- レビュワーの目線に立ったcommit履歴を作る
次の環境で絶対に発揮したい価値
「AIによって爆発的に膨らむコード差分において人間が守るべき範囲や対象を文書にて明確に定義し、かつそれを徐々に減らしていくことで質とスピードを犠牲にしない開発を実現させる」
プロフィール
- 名前: 狩野紀彦
- 性別: 男
- 生年月日: 1996/06/27
- 取得資格: 応用情報技術者・基本情報技術者
- 大事なもの: 家族
職歴
１社目: 新卒入社した受託開発→自社サービス会社のWebエンジニア
薬品管理支援システムのバージョンアップ開発（2016/6 〜 2017/3）
業務概要: 通例となっていたシステムのメジャーバージョンアップ開発に開発人員の一人として参加。開発をメインに担当しつつ、開発状況に合わせてテスターとして単体・結合テストを実施。また、バッチ作成も担当。
大手中古車掲載サイト基幹システムの保守開発（2017/4 〜 2018/2）
業務概要: 中古車掲載サイトに新規作成されたAPIを組み込むため、影響範囲の調査と組み込み実装を担当。影響調査および、膨大に膨れ上がったソースコードの改修を実施。
バイクメンテナンス店掲載SPA構築＋WebAPI開発（2018/3 〜 2018/10）
業務概要: 既存の中古バイク掲載サイトに付随する形で、新規にバイクメンテナンス店掲載サイトをSingle Page Application（SPA）で構築。必要となるWebAPIを既存ソースコードから解析し、こちらも新規実装。
既存ソースコード解析、SPA技術検証
WebAPIおよびSPAの要件定義・基本設計
実装、テスト、SEO対策、リリース
影響を受けた・大事にした考え方
- 新卒社会人としての一般的な常識を学ぶ
- チャンスに対して積極的に
エピソード
専門卒新卒だったため単価が安いことをいいことに残業しつつも新技術のキャッチアップや優秀な方のコードリーディングを行った
社内LTなどを通して新技術への積極性アピールし、当時は目新しかったSPA技術の調査・検証実装を行った
採用活動のエンジニア参加の先駆けや他県にある開発部署との交流出張なども経験できとても楽しかった
2社目: 友人と立ち上げた自社サービス開発会社
自社サービス開発（2018/11 〜 2020/4）
業務概要: スポーツ施設管理サービスを立ち上げ、PaaS上に構築・運用。需要調査、プロトタイプ開発、ローンチまで一貫して開発を担当。運用フェーズ移行後は、数千人へのメールマガジン送信機能の開発や、Webpack設定の記述ミスによるキャッシュミスを現場で発見し即時修正するなどを実施
以降はフリーランスエンジニアとして独立
基本長期的に取引会社さんとの業務委託エンジニアとして実装に貢献
特に長くお取引いただいた会社さんの実績を記述
1社目
Webサービス業務委託開発（2020/6 〜 2024/5）
業務概要: 15万事業者規模で利用されていた、Ruby on Rails + Vue.jsで構築された請求書作成Webサービスの開発にアプリケーションエンジニアとして参加。不具合原因調査・対策、新規機能開発、PRレビュー、日常的なエラー監視、テストコードの追加、毎日のリリース作業を担当。主にフロントエンドの新しい技術スタックへのマイグレーション、依存ライブラリの更新、パフォーマンス改善のためのWebpack設定の改善などを実施。長年サービスメイン導線に残り続けたセキュリティホールの削除を達成し、サービス安定性に貢献した
影響を受けた・大事にした考え方
- 完璧よりフィードバックが得られるまでの速さを重視する
- PRレビューをする・される時に大事なマインドと観点
- 依存関係の更新を滞らせない
- テストコードの書き方。テストコードが充実していることの安定性
- 優良なドキュメントは働き方・プロジェクト・組織を変える
- 振り返り大事
エピソード
多くのことを学び・活かすことができた。業務委託ではあるがここで働けたことで自分のレベルが何段階も上がった認識がある
ドキュメントというのは仕様書といったものでなく、PRテンプレートであったり、git commitメッセージであったり、そういった小規模な文章のようなものでも、何故書くのか何を残すべきなのかをこだわることで資産となって積み重なっていくと感じた
2社目
Webサービス業務委託開発（2024/6 〜 2026 現在）
業務概要: 数十万人規模のユーザがいる、Python Django + Vue.jsで構築された知見マッチングWebサービスの大規模なレガシー移行開発に参加。Vue.js 2からVue.js 3、Python 2からPython 3、Django 1系からDjango 5系へ対応したアプリケーションコードの移行を担当。移行後環境のコーディングガイドラインの拡充、レガシー移行における調査・立案・計画・実装を担当。特にサービスのコアバリューを生み出す数万行規模のAngularJS画面を担当し、不具合発生後のリカバリ方法を準備したうえで、業務を停止させずに移行を成功に導いた。
影響を受けた・大事にした考え方
- 足りていないことを埋める
- AIによって最強のプログラミング言語は自然言語になった
- AIが苦手な部分は人間がなんとかしよう
エピソード
組織やプロジェクトのドキュメンテーションが足りていないためまずその拡充に着手した
利用するツールごとに別なAIが存在し、その領域での便利な使い方を発見するのが楽しい
業務委託という立場では、自分の得意な「サービスの健全性を多角的に確認すること」に必要な情報・権限への関与に限界を感じた。これまで通り長期的に責任を持ち、チーム全体の品質とスピードを高めたい。
大事にしているマインド
一般的・基本原則
- 完璧よりフィードバックまでの速さ
- 上手いドキュメントが成功の鍵
- 上手いドキュメントの例: アジャイル開発におけるインセプションデッキ10の質問
- https://abi-agile.com/inception-deck/
- 分からないことは恐れず質問する
- 特に会議では。結構みんな分かってないことが多い
- フルリモートでの愛想の良さは絵文字に現れる
- 基本テキストコミュニケーション。難しいことは同期的コミュニケーションでサクッと解決
PRレビュー
PRレビューされるとき
- セルフレビューする前提で段取りを持ってgit commitする
- セルフレビューしながら必要であれば説明コメントを追加する
- [相談]: 相談したいときのプレフィックス
- :memo: 説明メモプレフィックス。コードコメントにはWhyNotを書く。故にそれ以外でレビュワーに伝えたいことを書く
- PR説明は目的をちゃんと書く・残す
- 目的は変更そのもの・git差分より大事なものなので必ず後世に残す必要がある
- PR以外の場所に残すことも可だがリンクだけをPRに残すことはタブー。なぜならリンク切れが経験上高頻度に発生するため
- PRタイトルは目的以外も書くことがあるためそこで全部書き表わすことは最初から諦めている
- PR説明には何を確認したかテストしたかを残す
- 可能であれば画像付きが望ましい
- レビュー指摘は頑張って即レスする。レビュイーの脳メモリの揮発を防ぐ
PRレビューするとき
- PRレビューするということはPRを作った責任を一緒に持つということ
- ただし他人のレビューにそれを期待してはいけない
- 目的を読み込む。目的が分からないのに差分だけ見たりしない
- 差分はPRの本体ではない
- 目的に向かう道は一つではない。よりよい道があればそちらを提示することもレビューのしごと
- 絶対的な指標から確認していく。つまり動作が優先確認事項
- 動作が意図通りか、デグレしていないか
- コードの体裁はその後に確認する
- 理由: 動作が間違っていればアプローチたるコード差分は当然変わる。絶対的な動作という指標が問題ないことを前提にしたうえでより良い書き方が自分の中で存在すれば提示することで双方の仕事の量が減る
- Lint・規約・ガイドラインで定められていないコードの体裁はimoプレフィックスで指摘する。ただしimoは多用しないことがベスト
- imoを多用すると自分の考えをその場だけのものになってしまい、誰にとっても良くない
- imoが受け入れられるようであれば全体的なものとすべく動く
- 絵文字は愛想
- 良い点はGoodコメント
プロジェクトドキュメントについて
プロダクションコードの類似物としてドキュメントの価値はすくない
大事なのはプロダクションコードの差分が生まれる背景がサマライズされて残っていることが大事
ドキュメントはコードと同じようにとある時点での「スナップショット」に過ぎない
スナップショットは時間とともに現状との乖離が生まれるため、時間経過とともに陳腐化する
よって抽象度を上げることで陳腐化に対抗する。場合によっては詳しく書きすぎないことが大事
最も大事なことはその時点での「背景」と「目的」