職務経歴書

基本情報

一言で表現する

工数削減エンジニア

自己PR

　課題解決のスピードの早さが長所です。炎上気味のプロジェクトに何度か配属された経験から、同時期に複数の課題を達成しなければならない状況に立たされました。逐次、課題解決をすることを止めました。個人で業務開始と終了時に 10 分ほど PDCA の時間を設け、複数の課題を抱えていても常に 1 つの課題に注力できるように、時間管理や別課題を行わないことを徹底しています。その結果、個々の課題の解決速度が高くなり、チームでは多くの課題を任されています。チームリーダーを任されるようになってからは、課題の優先度や緊急度等も含めて伝えることで同時並行に課題が進行していても、1 つに注力できるように注意して指示しています。 　また、課題管理能力も長所です。各自が抱えている課題を、コミュニケーションをとることで引き出しています。私が解決できる課題であればそのまま解決し、他の有識者の協力が必要な場合はすぐに協力を取り付けてきました。課題の進捗が悪い場合は原因を分析し、原因によっては本人に継続して課題を実施するように指示、他の課題の優先度や期限を考慮して担当者を別の人間に変更する等、クリティカルパスの遅延が発生しないように努力してきました。1 人で開発から運用までのプロジェクトを任されることもあり、実務能力、およびプロジェクトに対する課題管理能力を会社に評価されているものと考えています。

個人のミッション

　生産性を下げないための仕組みづくりをミッションと考えています。 　タスク管理ツールを導入して各自が課題管理しやすい状況を作成する。情報を整理して資料化しておき、他の参画者が参照しやすい形で管理する。会議の際にはアジェンダ及びタイムテーブルを用意し、議事録を残す。等々の基本的なことは実施します。 　技術面には、CI/CD を導入して失敗に早く気付けて手戻りを減らす仕組みであったり、静的解析ツールを導入して個人の勘に寄らない障害を未然に防ぐ仕組みを導入してきました。その他にもドメイン駆動設計を意識して短期的な生産性ではなく、数年先を見据えた生産性を意識して行動し、設計を意識した勉強会での登壇を行っております。 　生産性を上げる方法は個人に依存することが多いですが、生産性を下げない方法は仕組みで防ぐことが可能でした。誰かが意識しなければすぐに悪習が蔓延り、生産性を下げないための仕組みは陳腐化してしまいます。1 人が短期的に 1.1 倍の生産性を出せるようにするのではなく、100 人が長期的に 1.01 倍の生産性を出せるようにする。それが私に与えられたミッションだと考えて、常日頃から行動しております。

職務経歴概要

本業

KAKEAI株式会社

フルスタックエンジニアとして参画。Sentryの整備等によりObservabilityを高めて計装できる状態にして、生産性に貢献。

ソフトバンク株式会社

アジャイルでの開発を経験。アーキテクチャを提案する等でチームメンバーを引っ張りました。

株式会社ISTソフトウェア

2 次受け SIer。官公庁向けシステムに携わってきました。要件定義からリリースまで一気通貫で開発した経験あります。チームでの開発、一人での客先常駐等の様々な経験をしました。

職務経歴詳細

KAKEAI株式会社（2023/11〜現在）

面談支援サービスの開発

期間 規模 役割
2024/02～現在 2 名 リーダー

TODO。

1on1支援ツールのKakeai開発

期間 規模 役割
2023/11～現在 25 名 リーダー

TODO。

ソフトバンク株式会社（2019/02〜2023/10）

法人商材を顧客が申込みできる画面を提供するアプリケーションの改善

期間 規模 役割
2023/06～2023/10 3 名 リーダー

システムの改善を行っている最中。

バーチャルフィッティングの開発

期間 規模 役割
2022/09～2023/05 3 名 リーダー

Unityで開発されたバーチャルフィッティングをスマートフォンのアプリケーション, デジタルサイネージ, Web上で扱えるようにするプロジェクトです。

管理画面、APIの開発を主として行いました。また、アプリをWebGL化して顧客のECサイトに埋め込むための作業も担当しています。

商材出荷システムのAPI開発

期間 規模 役割
2022/04～2022/08 10 名 リーダー

2021/01～2021/06で作成した商材出荷システムを、他システムとの連携のために追加改修するプロジェクトです。

1回の処理で両システムのライフサイクルのデータを吸収する要望があったため、複雑なシステムにはなってしまったが、その要望が叶えられる仕組みを作成した。

社内向け法人販売商材の管理アプリの開発

期間 規模 役割
2021/11～2022/03 10 名 リーダー

Salesforce 上で展開された社内向け法人販売商材を管理するシステムの商材を追加するプロジェクトです。機能ごとにベンダーが違う、マルチベンダーで開発されています。

マルチベンダーであるために、納品対象以外の詳細資料が各ベンダー内部でしか把握されていません。現在は、資料の検索性を上げるため、Google Site を使用して情報を統合しようとしております。

既存アプリの自動テスト及びCICDの作成

期間 規模 役割
2021/07～2021/10 5 名 リーダー

商材を管理するシステムのリグレッションテストの工数増加、リリース作業等が手動になっていたために工数削減を目的としたプロジェクトです。

E2E ツールとしてもっとも有力だった PlayWright を選定。リリースに関しては既存手順が Windows のため、それに合わせるため Powershell でツールを構築しました。

商材出荷システムのAPI開発

期間 規模 役割
2021/01～2021/06 10 名 リーダー

商材を管理するシステムと商材を出荷するシステムを連携するために、商材を出荷するシステム側に REST API を新規に作成するプロジェクトです。

設計・開発を担当。コードで業務の表現をすることや、コードの責務を分離することで保守品質を高めることを意識しました。プログラム言語側で用意された基本型の日付型を使用するのではなく、和暦等の特化型を作成しました。テストコードを作成する際に無視されがちなデータの制約を守ることができ、早期に障害を発見できました。

また、当プロジェクトでは画面操作していたものを API 化するため、対向システムのアカウントを早期に発行してもらい、開発初期から開発者に操作してもらうことでシステム全体の解度を高めてもらいました。

その結果、運用保守ベンダーには開発に 4 ヵ月かかると見積されたシステムでしたが、工数を 2 ヵ月に短縮させて完成させられました。プロジェクト初期の立ち上がりが遅くなろうとも、システム全体の理解度を高めるための施策を実施することが大事であると学習しました。

社内審査システムのAPI開発

期間 規模 役割
2020/08～2020/12 1 名 フルスタックエンジニア

SOAP 連携しか用意されていない審査システムに対して、REST API でも連携できるようにするための中間層となるシステムです。同時期に当システムの API を実行するプロジェクトも進行していましたので、そのプロジェクトとも連携を取りながら進行しました。

設計・開発を担当。設計を含めて開発期間は 1 ヵ月だったため、あらゆる工程を薄く結合することを意識しました。例えばサーバを用意したのち、まずはエンドポイントのみを作成いたしました。対向システムとの疎通確認を行うことで、環境設定に不備がないかを確認しています。次に、用意したサーバから審査システムに対して cURL で SOAP 連携が可能かを検証しました。次に、電文を対象審査システムにて、どのように画面表示されるかも確認しました。この例のように、徹底的に薄く結合することを意識して作業を行いました。

環境設定は別の部署で一括管理していることもあり、依頼から設定完了までのリードタイムを気にして行動しました。ファイアウォール等の環境設定だけでなく、影響する対向システムのアカウントを早期に発効してもらって操作方法を教えてもらい、画面を含めた一気通貫で動作確認できる状態を早期に作り上げました。このように行動した経緯として、過去の経験からまずは自システムの作りこみに集中してしまうことが多くありました。全ての機能を設計書の通りに作成し、それから結合することは進捗管理としては誤りではありません。しかし、対向システムが存在する場合は、対向システムが受け取った結果が正しいものとなります。対向システムが受け取った結果を開発者が画面で確認しなかったために、より後の工程で不具合が発覚し、手戻りが発生することが多々ありました。

進捗管理としては複雑にはなってしまいましたが、内部の作り込みよりもインタフェース面での確認を強く意識しながら進めた結果、当システム起因でのプロジェクト遅延や障害は発生しませんでした。

社内表彰されるほどの評価もされたプロジェクトです。

携帯購入後から審査、出荷、電話開通を行うバックエンドの開発

期間 規模 役割
2019/05～2020/07 50 名 サブリーダー・サーバサイドエンジニア

携帯購入後の審査・出荷・電話開通等の処理が手動で行われていたため、それを自動化するために立ち上げられたプロジェクトです。

大規模スクラム（LeSS）にて開発を行いました。役割としてはサーバサイドエンジニア、チームのサブリーダーとして途中から参画しました。LeSS で実施するにあたって、全ての出来事をチーム間で相談するのは時間がかかるので、技術力のある開発者をトラベラーという役割に任命し、技術的な相談事はすべてトラベラーに集約しつつ、チームを横断した品質管理をしてもらっていました。

また、各人が感じているクリティカルな問題ではないが生産性や品質悪化に繋がりかねない問題に関しては、コミュニケーションを取って技術的負債として管理しました。技術的負債に関しては開発者全員を巻き込んで棚卸や管理する場を設け、ファシリテーションを行っておりました。この取り組みは開発者に非常に好評でした。この取り組みで挙げられた問題は開発者から挙げられているものであり、人から言われて発生した問題ではありません。そのため、問題の解決に対して他人事ではなく自分事として捉えることができ、各メンバーは非常に高いモチベーションで課題解決に向かってくれました。副産物として、困っている内容を相談しやすい場を作ることで、コミュニケーションを活発にできました。テスト要因として参画していただいているメンバーからも問題を挙げてもらうことで、課題解決してくれたことの感謝から不和になりがちであった関係性の改善にもつながりました。

このプロジェクトにて、いかに個人のモチベーションを刺激しながら仕事をすることの大切さを学びました。

テスト管理アプリの開発

期間 規模 役割
2019/02～2019/04 5 名 リーダー・フルスタックエンジニア

当プロジェクトは社内で使用するテストの進捗を管理するアプリです。

アジャイルにて開発を行いました。アジャイルですのでリーダーという明示的な役割はありません。しかし、過去に使用してきたライブラリを提示したり、社内向け管理アプリでしたので見た目にこだわらずにある程度見た目が整う Bootstrap の導入しました。

株式会社ISTソフトウェア（2014/04〜2019/01）

海外法律のクローラアプリの開発

期間 規模 役割
2018/09～2019/01 1 名 リーダー

海外展開する製品を持つメーカーが、展開先の国で違法にならないように、法律の改正をウォッチするためのクローラアプリです。

機能追加を担当。機能要望のリストを元に機能の優先度や画面や動作仕様を顧客と直接話し合い、スケジュールを管理しつつ、開発しました。品質を担保するために、テストを推進して機能追加を行いました。

RPA製品のサポートセンタ

期間 規模 役割
2018/06～2018/09 20 名 メンバー

WinActor 製品の QA、製品の技術支援等を担当。基本的には常駐先にて勤務し、御客様問い合わせに回答していました。他にも御客様先に出向いて製品の支援や、御客様の業務を伺って、製品で行えるシナリオの例示等を行いました。

スポーツ選手向けアプリの開発

期間 規模 役割
2017/10～2018/05 6-25 名 リーダー

当プロジェクトは、スポーツ選手向けのアプリは複数存在しますが、各自でユーザを管理しているため、統合してスポーツ選手の基本情報を管理するアプリが欲しいという要望から作成されたアプリです。

当プロジェクトでは 2 つのリーダーを務めました。

1 つは外部連携したデータの表示機能の基本設計からユニットテストまでを担当するリーダーです。 こちらの規模は 4 人で、開発は主にスマートデバイスを担当しました。 実機確認しつつ、Chart.js を使用して連携したデータをグラフにする機能を作成しました。 Monaca で HTML5 を使用していたことから Android も iOS も大きな表示崩れも起きず、Monaca と Angular の親和性も高いことから短時間での開発を行うことができました。 また、TypeScript を業務で扱うのは初めてでしたが、自分だけ当プロジェクトへの参画が 1 ヵ月遅かったこともあり、自己学習で先に勉強していたため、苦労はありませんでした。 ただし、他の開発者は TypeScript に初めて触ったためにこちらの想定通りに開発が進まず、 2 週間で 3 画面分の機能を実装する予定でしたが、最終的に 4 画面を担当しました。 実装とユニットテストレビュー、またスケジュール管理も担当していたため、時間が足りない状況でしたが、作成することが出来ました。

もう 1 つは、プロジェクト全体の結合テストから運用テストまでのテストリーダーです。 こちらの規模は 6 人で、もう 1 つ動いていた障害修正チームが 10 人ほどでした。

苦労したのはテストチームと障害修正チームが離れた現場にいたことで、Excel での障害管理表の管理が煩雑になり、どちらが持っている障害管理表が最新なのか判断する必要もありました。 障害修正チームが追記した内容や、テストチームがより詳細に検証した結果等を互いに上書きしてしまうこともあり、よい状況であるとは言えませんでした。 その煩雑な管理を解消するため、Redmine や JIRA 等のタスク管理ツールを業務時間外で情報収集し、UI が使いやすく無料で扱える範囲の多い backlog の導入を PM に提言しました。

その結果が功を奏し、障害管理表の最新を意識する必要なく作業でき、またチームごとに管理していた障害管理表も無くなったことで、マージや更新待ち時間等の時間を減らすことが出来ました。 また、backlog 上で障害と SVN のリビジョンを紐づけるように徹底して依頼したことで、総合テストや運用テスト時に行った横展開の再調査や工数を減らすことが出来ました。 概算となりますが、20 時間ほどの工数が減っております。

労力を減らす努力を怠らずに進めてきたことで、当プロジェクトは成功に導けたのだと考えています。 また、当プロジェクトは社内にて社長賞を受賞されるほど評価されておりました。

官公庁システムのマイグレーション

期間 規模 役割
2016/04～2017/09 40 名 メンバー

当プロジェクトはサポート期限の切れた VB6 から Visual Basic.NET にマイグレーションするプロジェクトです。 2016 年 4 月から 12 月は単身で開発チームに入り、定時まではアプリ仕様を把握して新規機能・既存障害の基本設計書や詳細設計書を作成し、定時後には当社のマイグレーションチームに仕様を伝えつつ、マイグレーションチームの障害を消化しておりました。

2017 年 1 月から 9 月までは、マイグレーション完了後に新規機能や既存障害の PG や結合テスト、その他データ移行ツール作成を行いました。

VB6 や。NET もどちらも今回のプロジェクトで初めて触り、DB も Postgres を使用するプロジェクトに参画してきていたため、Oracle で開発するのは初めてでした。 今回の経験で新言語を学習することに対する障壁は無くなり、自己学習で Python を使用した機械学習等も触るようになりました。

今回のプロジェクトでもっとも重大な障害が起こった変更点としては、VB6 から。NET への言語差異よりも、oo4o から ODP.NET への DB 接続ミドルウェアの差異が大きかったです。この原因としては、oo4o では編集メソッドにて、行ロックを行っていましたが、ODP.NET では同等のメソッドが存在せず、明示的な行ロックを行う必要があったということです。

このプロジェクトで得た経験として、Visual Basic.NET 等の言語や ODP.NET 等の接続ミドルウェアが生まれる背景となった時流や思想をより掴めるようになることで、単なる経験に留まらずに汎用的な新規テクノロジーと相対するときにも流用できるということを学べました。

また、当プロジェクトは社内にて、社長賞を受賞しました。

法案承認する官公庁システムの新規作成

期間 規模 役割
2015/01～2016/03 6-12 名 メンバー

当プロジェクトは、各官公庁で独立して行われていた法律作成プロジェクトを 1 つのシステムで共通化することで、残業時間を減らすことを目的にフルスクラッチで作成されました。 当システムは霞が関働き方改革の例としても日本経済新聞でも紹介されました。

私は 2 次受けとして参画し、ウォーターフォール形式の要件定義からリリースまでのサイクルを 2 回経験しました。 jQuery での ajax 通信や Spring の DI を使用したコーディング、Hibernate を使用した O/R マッピング等の開発の基礎を学びました。 特に Hibernate には日本語文献が少なかったため、公式ヘルプを日本語訳して使用していました。自分が サイクル 1 回目のプログラミング時に日本語に訳して資料化しておいたことで、2 回目のプログラミング時に増員された方々に渡すことで全体の工数を減らすことが出来ました。

責任者が現場にいないことが多く、情報共有を必要な人員だけに行い、全体への周知を積極的に行う時間がありませんでした。 そのため、プロジェクト立上げから参画し、全体の仕様も把握しており、PM とは近い立ち位置にいた私が情報を収集し、協力会社に周知して内容を再確認するように徹底しました。早期に対応することが出来たことで、結果的な工数を削減することが出来たと考えています。

官公庁の基幹システムのリプレース

期間 規模 役割
2014/10～2014/12 6 名 メンバー

担当システムのコールセンター業務を行いつつ、連携テスト及びリプレースを担当しました。

官公庁システムのサードパーティ用API開発

期間 規模 役割
2014/08～2014/09 5 人 メンバー

サードパーティ向け API を実装及びユニットテストを担当しました。

官公庁の法律検索システムのテスト

期間 規模 役割
2014/07～2014/07 4 名 メンバー

法律の検索アプリのシステムテストを担当。また、一部機能の実装及びユニットテストも担当しました。

その他学習・登壇資料

サイト URL
GitHub https://github.com/hirotoKirimaru
SpeakerDeck https://speakerdeck.com/hirotokirimaru
技術ブログ https://nainaistar.hatenablog.com/

保有スキル

保有資格

取得時期 有効時期 資格名 備考
2014/11 - 基本情報技術者（FE）  
2017/06 - 応用情報技術者（AP）  
2019/03 - Oracle Certified Java Programmer, Silver(SE8)  
2019/05 2021/05 Certified Scrum Developer(CSD) 失効中
2019/10 - Oracle Certified Java Programmer, Gold(SE8)  
2020/07 - JDLA G 検定  
2020/09 - AZ-900  
2020/10 - Python 3 エンジニア認定基礎試験  
2020/10 - Python 3 エンジニア認定データ分析試験  
2020/11 - アジャイルソフトウェア開発技術者検定試験 Lv.1  
2021/03 2024/03 AWS クラウドプラクティショナー  
2021/06 - AI-900  
2021/10 2023/10 Associate Cloud Engineer  

言語

言語 年数
Java 7.5 年
JavaScript 4 年
Python 1.5 年
Visual Basic 6.0 1.5 年
Visual Basic .NET 1.5 年
TypeScript 1 年
Ruby 0.5 年

フレームワーク

フレームワーク 年数
Spring 7.5 年
Ruby on Rails 0.5 年
jQuery 3 年
Vue.js 0.5 カ月
React.js 0.5 カ月

その他

その他 年数
PostgreSQL 4 年
Oracle 3 年
MySQL 0.5 年
JFrog Artifactory 3 年
Git 3 年
Subversion 4 年
Docker 3 年
Ansible 1 年
Amazon Web Services 1 年
Azure 1 年
Kubernates 0.5 年
PlayWright 0.5 年