職務経歴書

基本情報

自己PR

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

個人のミッション

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

職務経歴概要

|本業・副業|期間|会社|概要| |—|—|—|—| |本業|2023/11-現在|KAKEAI株式会社|フルスタックエンジニアとして参画。Sentryの整備等によりObservabilityを高めて計装できる状態にして、生産性に貢献。| |本業|2019/02-2023/10|ソフトバンク株式会社|アジャイル開発を経験。
技術を伝えたり、アーキテクチャを提案する等でチームメンバーを引っ張りました。| |本業|2014/04-2019/01|株式会社ISTソフトウェア|2 次受け SIer。
官公庁向けシステムに携わってきました。要件定義からリリースまで一気通貫で開発した経験あります。
チームでの開発、一人での客先常駐等の様々な経験をしました。|

職務経歴詳細

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

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

期間 規模 役割
2021/11-現在 10 名 リーダー

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

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

商材出荷システムのAPI化

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

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

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

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

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

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

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

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

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

期間 規模 役割
2019/05-2020/07 50 名 バックエンドエンジニア

テスト管理アプリの開発

期間 規模 役割
2019/02-2019/04 5 名 リーダー

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

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

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

　機能追加を担当。機能要望のリストを元に、機能の優先度や画面や動作仕様を顧客と直接話し合い、スケジュールを策定しつつ、開発。

RPA製品のサポートセンタ

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

　製品の 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/10 60 名 メンバー

規模 マイグレーションチーム人数：20人 開発チーム人数：20人

参画期間 2016年4月～2017年9月

環境 ・Windows XP, Windows7,WindowsServer 2012 ・(メインフレーム)

使用言語 ・PC 　VB6, VB.NET,(C#)

その他備考 ・GrapeCity製品(Spread, InputMan, component one等) ・Oracle DB接続ミドルウェアをoo4oからODP.NETに変更 ・クライアントサーバシステム

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

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

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

今回のプロジェクトで最も重大な障害が起こった変更点としては、VB6から.NETへの言語差異よりも、oo4oからODP.NETへのDB接続ミドルウェアの差異が大きかったです。

各事業所のローカルサーバにDBを二つ構築したり、本社でも部署ごとにDBを構築し、更に同一サービスが多重で動作している等の条件があったため、一部サーバダウンした後の復旧作業後にも、データの整合性が合わないということがありました。

この原因としては、oo4oでは編集メソッドにて、行ロックを行っていましたが、ODP.NETでは同等のメソッドが存在せず、明示的な行ロックを行う必要があったということです。

この障害は一例ですが、これらの経験から、oo4oはオンプレミスの時代に向いたDB接続で、ODP.NETはクラウドの時代に向いたDB接続であることを確信しました。

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

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

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

|期間|規模|役割| |—|—|—| |

要件定義から運用保守まで担当。2 段階リリースを行うプロジェクトで、2 段階リリースに向けた開発時にチームリーダーを担当。フルスクラッチで作成。DB 接続ミドルウェアの Hibernate には十分な日本語文献が存在しなかったため、StackOverFlow を和訳してメンバーに展開。新規参画者がスムーズな開発ができるような環境整備を実施

規模 チーム人数：6-12 人

環境 ・PC(IE8, IE9, IE10)

使用言語 ・PC 　Java, JavaScript

その他備考 ・フルスクラッチでの開発

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

法律に関するプロジェクトだったので、業務理解に大変苦労しました。 新規作成される法律と法律を更新する法律（改正法令と被改正法令）に分かれること、法律の条だけ章を跨いでも番号が継続されること等の法律自体を知らなかったことは。

私は 2 次受けとして参画し、ウォーターフォール形式の要件定義からリリースまでのサイクルを 2 回経験しました。 本格的な開発としては、これが初めての開発で、フルスクラッチで初期から開発に関わったこともあって右も左もわからない状態でした。 フレームワーク等の選定には関わることはしていませんが、 jQuery での ajax 通信や Spring の DI を使用したコーディング、Hibernate を使用した O/R マッピング等の開発の基礎を学びました。 特に Hibernate には日本語文献が少なかったため、StackOverFlow に投稿された内容を日本語訳して使用していました。 自分が 1 回目のプログラミング時に日本語に訳して資料化しておいたことで、2 回目のプログラミング時に増員された方々に渡すことで全体の工数を減らすことが出来たと思います。

その他、XML 構造を XSLT を使用して本文を表示したり、法律を更新する際に自動で改正附則（変更履歴のようなもの）を Xpath で付与する仕組み等を担当しました。 XSLT を利用しましたが、コーディング時にはサンプル自体が提供されなかったため、XSLT についてもある程度は自分で作成しました。 法律には国旗・国歌等の画像が差し込まれていることもあり、XSLT に Java から画像パスのパラメータを渡すことも行いました。 そのおかげか、XML の操作には自信があります。

新人という立ち位置でしたが、PM も PL も現場にいないことが多く、情報共有を必要なほうだけに行い、全体への周知を積極的に行う時間がなかったので、 全体のコーディングに影響する周知が特に協力会社に行われていないことに気づきました。 そのため、プロジェクト立上げから参画し、全体の仕様も把握しており、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 年
Python 1.5 年
Visual Basic 6.0 1.5 年
Visual Basic .NET 1.5 年
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 年