エンジニアとして、フロント・バックエンド・サーバーサイドの3年の保守/運用実務経験があります。
| 氏名 | 石川 哲平(いしかわ てっぺい) |
| 生年月日 | 1995年6月1日 |
| Qiita | https://qiita.com/mikohiki |
- 長所①: 探究心趣味や抽象的な問題などジャンル問わず、調べ尽くすことが好きです。
- 長所②: 負けず嫌い入社当時は誰よりもソースを書く・読む速度が遅かったが、寝る時間以外全てソースコードを読み実力がついたため、社員130人の中で10%の人がもらえる評価を得ました。
- 短所: 熱しやすくて冷めやすい 興味を持つが一気に集中して実行するため、目標を達成するとすぐに他の興味があるものを行ってしまう。
「価値のあるサービスを作る」「保守性の高いソースコードを書き続けたい」のようなことを最初は考えたのですが、休みの日に楽しくソースコードを毎週かけるかと言われたら、ゲームをやってる方がおそらく楽しいと思いますし、心の内でふつふつと湧いてくるほど保守性の高いソースコードを書きたいかと言われたら、100%の肯定をできる自分はいない気がします。(美しくて保守的なソースコードを書く喜びはもちろんわかりますし好きですが。)
それよりかは、同じチームのエンジニアに思考も知識も負けて悔しいから、「何か一つでも勝るためにガムシャラに勉強して追い抜きたい」のなどの欲求の方が強いです。メソッドの違いを調べたり、処理速度について考えたりするのも好きなのですが、プログラミングは僕自身の欲を満たすための手段としての立ち位置の方が強いです。
ですが、そのガムシャラに勉強している中で、自分自信の開発速度が上がれば結果としてチームの生産性も上がりデスマーチを回避できるかもしれないですし、最初は「負けたくない」の思いで始めたことが、巡ってみんなの幸せにつながるように生きていきたいです。
- 緊急対応・修正などの保守対応を多くこなしてきたので、ひとまず半年、1年ほど開発業務を行なっていきたいです。
- すぐに要件定義などを行うイメージよりかは、コーディング力を今以上に上げて保守性の高いコードを0→1で早く生産できるようになりたいです。その後、上流にも携われたらと考えています。
- 世界は解釈の問題
- どんなに良いプロダクトや技術があったとしても、人やチームが良くなければ物事はうまくいかない。逆に人やチームが良ければ、現状悪いプロジェクトでも未来は明るい。
- Ruby: 3.5年
- Ruby on Rails: 3.5年
- react: 3年
- redux: 3年
- JavaScript: 3.5年
- jQuery: 2年
- html: 3年
- css: 3年
- linux: 3年
- PostgreSQL: 3年
- Next.js 3ヶ月
| 年月 | 学歴・職歴 | 備考 |
|---|---|---|
| 2015年 ~ 2019年 | 獨協大学法学部法律学科 | 法哲学を学ぶ |
| 2018年 | 短期集中プログラミングスクール TECH::EXPERT(株式会社div) 入学 | Ruby on Railsを用いたwebアプリケーションを作成。TECH::EXPERT初の新卒卒業生 |
| 2019年 ~ 2022年4月 | 株式会社テモナ入社 | webアプリケーションエンジニアとして新卒入社。3年目に保守チームのリーダーに昇格 |
| 2022年4月 ~ 2022年10月 | 株式会社speee入社 | webアプリケーションエンジニア開発業務に携わる |
| 2023年7月~ | 株式会社Plex入社 | 業務効率化のチャットシステムやM&A周りのテーブル作成 |
- 2019年4月 ~ 2019年8月
- 既存通知機能の機能削除と機能開発
- 通知機能で不要なお気に入り機能の削除、「対応/未対応」確認機能の実装、通知ログ削除バッチ処理の開発
- Ruby, Ruby on Rails, JavaScript, CoffeeScript,PostgreSQL, CSS, HTML
- 通知機能に「対応/未対応」確認機能がなかったため、機能の実装
- 通知機能に新たな機能を追加するだけでは、UIが複雑になりユーザーの利便性が低下する可能性があったため、不要機能の洗い出し
- 通知機能の「対応/未対応」確認機能の実装とは別に、通知ログデータを削除するバッチ機能の開発。
- 弊社サービス利用400ショップに対して、シェルスクリプトで不要機能に関係するカラムの利用状態がfalseかつupdated_atが直近1年以上前のショップを洗い出し、利用ショップがいないことを確認した上で対象ソースコードを削除致しました。
- 通知ログのデータは、システム上CRUD処理に関する動作に紐づいて作成されることが多いため、データ量が必然的に多くなってしまうと考えました。そのため開発とは直に関係ありませんでしたが、永続的にデータを保持するのではなく、半年以上前に作成されたものは削除するようバッチ処理の実装も追加で対応致しました。
- 2019年8月 ~ 2021年3月
- 保守グループの運用/保守メンバー
- サブスクリプション実装サービスにおける、利用店舗400ショップを対応する保守チームのメンバー
- Ruby, Ruby on Rails, JavaScript, React, Redux, CoffeeScript,PostgreSQL, Zabbix, Nginx, Unicorn, CSS, HTML, Redis, Linuxコマンド, Elastic serch, BackLog
- ソースコードを読む速さやデバック、検証スキルがなく業務をスピーディーに対応することが不可能な状態。
- 保守メンバーが私と先輩エンジニア1人にも関わらず、毎日10件近くくるバグ・仕様確認やバックエンド・フロントエンド・インフラ問わずくるサービス全体の修正対応。
- デジタルオーシャンで仮想サーバーを借りて、自宅で弊社提供サービスと同じLinux, Unicorn, Nginx, PostgresSQL, Rails環境を作り、webサービス全体の大枠のイメージと流れを勉強致しました。
- 入社してから2年間,業務終了後の18:30から独学であったり、保守チームの先輩を誘い24時まで,grep,awkなどのlinuxコマンドの仕様方法やrailsのblankやpresentメソッドの違いなど必要な知識を毎日学習致しました。
- Rails, JavaScript, Reactなどの概念を頭の中でイメージできるように該当言語が生まれた歴史から学習。そのことによって、言語の特徴を理解することが早いキャッチアップにつながることを学びました。また、同じような悩みを来年度の新卒エンジニアが抱えると考え、アウトプットも兼ねて独断でドキュメントを作成致しました。
- できるエンジニアと私自身の差分が何かを客観的に観察し、キーボード・マウス・エディターなどのインターフェイスをできる人に揃えたり、どういう考え方でソースコードを読もうとしているのかなどの、指向方法まで真似ました。観察してみたところ、頭の中でバグるパターンの仮説を立てた上でソースコードを読んでいることに気付き、私自身も求めてるゴールとバグが生じる差分の原因を仮説を立てながら考えたところ、毎日10件近くくるバグ・仕様確認の対応可能件数が1,2件から5,6件に増え、先輩と2人でも保守チームを回せるようになりました。
- 2021年3月 ~ 2022年4月
- 保守グループの運用/保守メンバー兼保守グループリーダー
- サブスクリプション実装サービスにおける、利用店舗400ショップを対応する保守チームのメンバー兼リーダー
- リーダー兼バックエンド、フロントエンド、インフラを対応する1メンバーとして以下を担当
- Ruby, Ruby on Rails, JavaScript, React, Redux, CoffeeScript,PostgreSQL, Zabbix, Nginx, Unicorn, CSS, HTML, Redis, Linuxコマンド, Elastic serch, BackLog,
- 先輩エンジニアと私の2人3脚で400ショップ様の対応を行なっていたが、先輩エンジニアが抜け、私がチームリーダとなり新卒5人をまとめるチーム作り。
- 1000万円の補填になりそうな大きなバックエンドのバグ対応や、バグ対応に伴う1000~5000件のデータ更新作業。
- 会社初の協力会社様を保守作業にジョインしてもらうための外部会社との連携作業。
- リーダーとして、保守チームが回るようになるように、保守メンバーが自走できるような仕組みづくりを自ら行いました。
- 保守チームが対応すべき、修正チケットやバグ・仕様確認の未対応チケットが50件ほど溢れている状態から、半年で平均8件まで減らすことを達成致しました。
- 1000万以上の補填になりそうな保守対応は、データ数が1000~5000件だったりすることもあるため、SQLで不具合データを洗い出せるようにRuby以外の言語でも対応できるよう技術の幅を伸ばす。また、言語に対する理解が浅い場合二次被害を産むことがあるので、根底の理解をできるように再度railsの学習や、apiなどのもっと知識の幅を深める学習を行いました。
- いつでも質問していいよと言うだけではなく、質問できる環境を作ることからスタート致しました。具体的にはランチをこちらから誘い、その人となりを理解することから努め、その人の物の考え方や学習方法のスタイルなどを理解した上でその人に会う質問の答え方や勉強方法を教えました。
- 業務対応速度が上がったとしても、根本の不具合件数を撲滅しなければ本質的な解決にならないため、多い不具合のジャンルをチケットベースで洗い出し、問題となってる箇所が決済周りの不具合やデータ更新と判明。判明した上で決済周りのrspecの強化を行なったり、データ更新が必要になってしまっていた原因の、sidekiqの非同期更新時のバッチ処理対応を行いました。
- 更新対象の件数が1000件を超えると、ただupdate文で更新するだけでは、楽観ロックやデータ更新中に対象データの状態が変わることも考えられるので、トランザクションやrescue処理を設けて、ローカル検証段階で遭遇しなかった自分が想定していないパターンが生じても問題内容な更新スクリプトを作成致しました。
本当に簡単な例ですが、scriptになります。
target_user_ids = [1,2,10,20,21,22,...]
# update_failure_listsは更新失敗したUserのidとその時のエラーメッセージを格納する空配列
update_failure_lists = []
def updates_data user, update_failure_lists
ActiveRecord::Base.transaction do
# ここに正しく更新したい内容記述
user.update!(name: 'hogehoge')
end
rescue => e
# 開発だけではなく、consoleでの更新時でもイレギュラーを想定してrescue処理は欠かさない
error_message = "Reason::" + e.message
update_failure_lists << [user.id, error_message]
end
User.where(id: target_user_ids).each do |user|
updates_data user, update_failure_lists
end
- 2022年4月 ~ 2022年10月
- 既存サービスの修正と開発
- 不動産賃貸情報提供サービスの修正と開発
- 修正・開発メンバーの1メンバーとしてジョイン
- Ruby, Ruby on Rails, JavaScript, CoffeeScript,CSS, HTML
- ユーザビリティーを上げるために、既存データの回収やデザインの調整などを他事業部のデザイナーと行う
- 2023年7月 ~
- コーポレートエンジニアとして開発
- 業務効率化のチャットシステムの開発
- M&A周りのテーブル設計
- コーポレートエンジニアは私1人で開発
- Ruby on Rails, Next.js, PostgreSQL, vercel
- 弊社サービスを利用するエンドユーザーとLINEでやり取りする際の社内ツールとして、kintoneとNext.jsを繋いで該当ユーザーのデータをもとにLINEのAPIを叩いてやり取りできるチャットシステムの開発。
- 新規プロジェクトを行う上でkintoneのデータをPostgreSQLでも利用できるようにするための、Railsでのインポート処理やテーブル設計の