| 項目 | 説明 |
|---|---|
| 氏名 | 松林 武幸 |
| 生年月日 | 1999/3/12 |
| 居住地 | 東京 |
| GitHub | @Yowayuki |
| Qiita | @yowayuki |
2022 年 4 月より SIer 企業に新卒入社。
1 年目はスマートフォンアプリのエンハンス開発案件においてサーバサイドエンジニアとして参画し、基本設計から結合試験を担当。
2 年目は 3 ヶ月間自社の新卒研修の講師を担当し、その後 9 ヶ月間顧客先常駐で複数案件の進行管理・品質検証を担当。
3 年目は 6 ヶ月間 CSM リプレース案件のインフラ担当として、要件定義から開発を担当。
同時期 3 ヶ月間スマートフォンアプリの検証開発案件において AWS エンジニアとして参画し、開発環境の構築を担当。
その後スマートフォンアプリのエンハンス開発案件において AWS エンジニアとして要件定義から参画中。
ウォーターフォール開発・スクラム開発
Java・JavaScript・PHP・VBA・Google Apps Script
Spring Boot
MySQL・PostgreSQL
Linux・Apache
EC2・RDS・VPC・API Gateway・IAM・S3・Cognito・CloudWatch・Route53・ACM・ELB
| 項目 | 説明 |
|---|---|
| ソース管理 | GitLab・GitHub |
| コミュニケーション | Google Workspace・Microsoft Teams・Slack |
| タスク管理/チケット管理 | Redmine・Backlog |
| IDE | Eclipse・IntelliJ IDEA・Visual Studio Code |
オフィス等に軽食・飲料を販売する無人販売機を設置し、
スマートフォンアプリ上からキャッシュレスでの購入をユーザに提供するシステム。
スマートフォンアプリ、AWS 上にデプロイされたサーバシステム、無人販売機に取り付けられたエッジデバイスで構成されている。
PoC 開発として小規模にリリースされていた上記プロダクトについて、商用化リリースを目指し、 スマートフォンアプリのフルスクラッチ開発及びサーバシステムの改修を実施する。
10-20 名規模
Java・Spring Boot
MySQL
初期では、ジュニアレベルのエンジニアとして、基本設計・詳細設計・開発を担当した。
要件定義で曖昧な部分が多く、上司と相談しながら、
サーバとして追加で作成するべき API の提案や、拡張性を考慮した API の仕様の提案を顧客に対して実施し、基本設計以降の工程に落とし込んだ。
中盤以降は、PL とインフラエンジニアが離脱したため、有識者としてチームの窓口や仕様調整を対応しながら、結合試験を担当した。
当プロジェクトでは仕様考慮漏れや要件定義漏れによるバグ発生が非常に多く、それによる
別チームや顧客への説明・調整、バグ対応要員として途中参画したメンバーへの作業指示の対応を一手に担った。
また、自身もバグ対応要員として、バグ解析・バグ改修の実施や、インフラ起因のバグ調査を対応した。
プロジェクト初期では、私自身含めコミュニケーションが非活性的で、
スマートフォンアプリチームとサーバチームのコミュニケーション不足による
仕様検討ミスや手戻りがしばしば発生していた。
そのため、同期コミュニケーション・非同期コミュニケーションの両方で、
率先して課題の発信や進捗の共有を常に行うことで
チーム全体としてのコミュニケーション量を増やし、コミュニケーション不足を解消した。
このプロダクトでは、外部の決済 API を導入していたが、用意されていた仕様書が不十分であったため、
基本設計段階で仕様理解漏れによるバグが混入してしまい、結合試験で発覚した。
発覚時点で、リリースまでの時間的猶予が無かったため、自社マネージャ、顧客を巻きこんで状況説明を実施した上で、外部 API の提供元と直接コミュニケーションラインを確立し、
相互のサーバログからバグ原因の解析と修正を実施した。
上述した通り、このプロジェクトではバグの多発により工程に大きな遅れが生じ、
要所要所での要員追加が行われていた。
初期メンバーが多数離脱したことで、私が追加メンバーの管理を担うことになっていた。
最初は、自分の想定と全く違う成果物が上がってくるなどが発生し苦慮したが、
依頼する作業の前提、依頼する作業の目的を明確に伝えた上で、
作業中に複数回確認タイミングを設け、認識齟齬と手戻りを最小限にするよう努めた。
このプロジェクトで様々な課題に直面したが、その課題解決の原動力はコミュニケーションであることを痛感した。
コミュニケーションによって、ステークホルダーの担当分野・得意分野を活かし、課題の迅速な解決を実現できると考えている。
PL に課題を伝えることで、技術的解決を図ることができ、自社のマネジメント層に伝えることでリソースの調整を図ることができ、顧客に伝えることで顧客内調整を図ることができる。
そういった意味で、プロジェクトの推進にはステークホルダーの垣根関係なくコミュニケーションを密に行うことが重要であり、その円滑化のためにはまず自分自身が一番情報を発信していくことが必要であると学んだ。
現在でも、自らの情報発信の量・早さを起点としたチーム間のコミュニケーションの円滑化は私が仕事をする上で最も重点をおいていることの 1 つである。
このプロジェクトでは一人のエンジニアにインフラ業務が属人化しており、
そのメンバーが途中離脱してしまったことでインフラ作業やインフラ起因の不具合調査などに支障をきたしてしまい、工程遅延の一因となった。
また、有識者が殆ど離脱したことで私しかしらない知識や私しかできない作業が多数発生してしまい、その問い合わせが集中したことで私の業務時間の逼迫に繋がってしまった。
この経験から、メンバーは固定された役割の遂行のみに固執せず、日頃から他メンバー・他チームの業務内容も積極的に関与していくことが重要であると学んだ。
また、自身の作業が属人化している場合には、手順書の作成や他メンバーへの共有を自発的に行っていくことが重要であると学んだ。
こういった経緯から、私自身サーバ開発以外にも常日頃から関心を向けるようにしており、AWS 資格の取得や React 等のフロントエンド言語の学習を実践している。
自社の新卒研修の講師業務・運営業務を実施
講師 50 名規模 新卒 500 名規模
Google App Script
初期では、講師の半分をまとめたチームのリーダーとして、タスクの割り振りやコミュニケーション活性化に取り組んだ。
また、50 名規模のチームのタスクの見える化を行うために Google App Script を用いた
管理ツールの開発を自発的に行った。
中盤からは、特にチームの改善に重点を置き、他メンバーの作業相談や作業への考え方の浸透などメンター的な役割を担った。
また、新卒に対しては、無人コンビニシステム開発での追加メンバーの管理で学んだことを活かし、依頼する作業の前提・目的の明確化や経過での確認に重きを置いて指導を行った。
また、ポジティブフィードバックを意識して行うことで、新卒が自発的に作業の改善を行うことを促進した。
それまで面識のなかったメンバーが 50 人規模で集められて講師を担当していたこともあり、初期ではチームワークを発揮することが出来ていなかった。
具体的には、積極性のあるメンバーにタスクが集中してしまい、意見を発信するのも一部メンバーに限られていた。
そのため、私は最初にタスクの見える化を行い、誰がどういうタスクを持っているのかを全員が確認できるようにスプレッドシート上に整理した。
また、毎日の朝会では、業務の報連相以外にチームの課題・改善案を話し合う時間を設け、今のチームに足りていないことを全員で
認識するように努めた。
結果として、最終的には手が空いているメンバーが他のメンバーのタスクを巻き取ることを自発的に行えるようになり、
チームの改善について誰もが意見を発信し、対策を立てる取り組みが常態化した。
研修中では、適切なタイミングで報連相ができるようになることを個人的には大切にして教育を行っていた。
最初期は、ミスや遅延が発生した際の報告が出来ておらず、その指導方法に苦慮した。
しかし、その原因を考えた時、以下 2 点の原因があるのではないかという仮説を立てた。
① ミスしたことについて怒られるのではという懸念を持っているため
② 適切な報告タイミングを知らないため
そして、対策として、以下 2 点を心がけた。
① どのような失敗の報告でも、まずは報告した行動に対して感謝・賛辞を伝えること
② ① で感謝を伝えたうえで、よりもっといいタイミングで報告できたのではないかという問いを与え、
一緒になって考えること
また、上記取り組みを私だけでなく、新卒のチーム内でも行うように働きかけることで、
新卒同士で継続的に改善ができるようになった。
上記経験から、大規模なチームの運営の大変さ、難しさを学んだ。
特に、大人数のチームでは、タスクの偏りが発生しやすく、また課題意識の持ち方にも差が発生するということが分かった。
その対策として意識するべきと感じたのは、透明性を保つことである。
タスクの偏りや意識の乖離が発生するのは、チームの規模が大きい故に、より他メンバーが行っていることが分かりづらくなり、
他メンバーが考えていることが分かりづらくなるからではないかと私は考えている。
そのため、タスクの見える化を行ったり、毎日全員で話し合う場を設けることで意識的に透明性を持つことが重要になってくると考えている。
チームの規模が大きくなればなるほど、報連相や意見発信を活発にするために、心理的安全性の確保が重要になると考えた。
しかし、講師を統括する立場のメンバーに、様々な報告について不機嫌な態度で非難的な言動を投げる癖があり、
その結果多くの講師の報連相のスピード感が下がってしまっていると感じることがあった。
逆に、失敗をした際の報告の引き出し方で記載した内容は、報告を受ける立場の人間が積極的に報告をしやすい雰囲気作りを行ったことで
心理的安全性が確保できていたということだと考えている。
この経験から、チーム運営をする際に心理的安全性の確保をすることを心がけている。
企業ホームページの構築から運用まで一貫して対応する BtoB のホスティングサービス。
上記サービスの基盤として利用していた RHEL6 のサーバを、 EOL に向けて RHEL8 にバージョンアップを行い、
ホスティングしている各企業のサイトで使用している php についても併せてバージョンアップを行う。
20 名規模
PHP・VBA
MySQL・MariaDB
Linux・Apache
バージョンアップ対応をオフショアのベンダーに依頼し、その進行管理と品質チェックを行うチームのメンバーとして参画。
具体的な作業内容は大きく以下 4 点。
① 現行サイトの運用チームから、移行に必要な情報のヒアリングを実施
② 上記情報からオフショアに作業依頼し、進行管理・QA 対応を実施
③ 移行後の品質を確認する移行テストの作成・実施
④ 移行後のソースを動作させる検証用環境の構築とデプロイ
また、新卒メンバーを自分の元に一人付け、自分の作業と平行して新人教育を行った。
依頼されていた業務以外の取り組みとして、VBA による作業の自動化を率先して対応した。
具体的には、上記 ③ で作成する移行テストについて、取得した画面キャプチャを自動的に配置する VBA プログラムを作成し、 作業時間を 50%削減した。
プロジェクトの中盤から、メンバーの手が空いている時間が多くなっていることが多く、
お客様にとってリソース・コストの無駄が発生していることやメンバーのモチベーション低下が課題になっていると考えた。
また、私自身開発のプロジェクトに移動したいという希望があった。
上記状況から、新卒を私一人と同じ働きができるように教育した上で、私がプロジェクトを退場することが、
お客様にとっても、チームにとっても、私自身にとってもメリットになると考えた。
それに向けて、以下取り組みを行った。
① 新卒教育については、指導をする際に方法論だけでなく考え方を伝えるよう心がけた
② ① の結果私と新卒の仕事の質が近づいたことを、作業時間や指摘回数などの具体的数字を用いて見える化した
③ ② の根拠を元に、自社の部長レイヤーにプロジェクトの状況を説明し、お客様への提案方法を検討した
上記取り組みによって、私が抜けた分も新卒メンバーがカバーできるとお客様に認識していただくことができ、
円満に退場することができた。
上述した取り組みでは、お客様や自社のマネジメント層目線で考え、具体的な提案に落とし込めたことで、
自分の希望を通すことができたと考える。
自分の個人の視点・現場の視点ベースで「何をしたい」「何をしたくない」という考えではなく、
より上位の視座を持つことで、お客様の要望と自分の希望の合致点を模索することができた。
この経験から、特に提案を行う際に、高い視座で考えてメリットを提示することを意識している。
某金融系企業が社内で使用している、事務手続き関連の書類・フォーマットを管理するシステム。 15 年以上稼働しており、OS・MW が老朽化している。
使用している CMS を WordPress に差し替え、その他ミドルウェアについても最新化を実施する。 インフラについてもオンプレから顧客のプライベートクラウドに移行を実施する。
10 名規模
PHP(WordPress)
MySQL
Windows Server 2022・Apache
チーム構成として、開発未経験の若手が多く、チーム全体の管理・指導を担いながら、
自分自身はインフラ担当として要件定義・基本設計・詳細設計を実施した。
また、顧客との窓口として、定例のファシリテーションや仕様調整を行った。
このプロジェクトでは、インフラ担当としての作業自体は軽かったため、
作業のルール作りに率先して取り組んだ。
具体的には、git の運用ルールや、Redmine のチケット起票ルール、レビューフローなどの策定を行い、
チームとして作業するための基盤作りを実践した。
インフラ要員として参加しているメンバーが自分 1 人だけであり、
また参加している若手メンバーの多くがインフラ知識がない常態だったため、
属人化してしまうリスクがあった。
そのため、プロジェクト開始期から、定期的に自分が対応した作業を若手メンバーに引き継ぎ、
手順書を作成してもらって自分がレビューを行うことで、誰でもインフラ作業が行えるように取り組んだ。
結果として、プロジェクト後期で自分が別プロジェクトに移動になった際も、時間をかけることなく
スムーズに引き継ぎを行うことができた。
公営競技ファン向けに情報の発信やクーポン配布などを行うスマートフォンアプリのプロトタイプ版。 スマートフォンアプリ、AWS 上にデプロイされたサーバシステムで構成される。
展示会でのデモ実施を目的に、基本的な機能のみに絞って新規開発を行う。
10 名規模
Java・Spring Boot
PostgreSQL
EC2・RDS・VPC・API Gateway・IAM・S3・CloudWatch・Route53・ACM・ELB
AWS エンジニアとして、環境の構築を担当した。
AWS エンジニアは自分一人であったため、 ランニングコスト算出や使用リソース選定から実構築まで一手に担った。
また、割り振られた構築業務だけでなく、開発効率化の手段を検討し、以下 2 点を実施した。
①TeraTerm マクロとバッチスクリプトを使用したデプロイツール作成によるデプロイの自動化
② スマートフォンアプリの結合試験用に API Gateway を利用したモック API の作成
顧客要求が明確でないまま開始したプロジェクトであったため、機能要件が頻繁に変わっていた。
サーバ開発者の柔軟な変更にインフラ構築も合わせる必要があったため、
サーバとしてどういう実装方針にするかを日々ヒアリングし、インフラ構成に落とし込むことを行った。
運転操作をスコア化することで保険料に反映させる PHYD 型保険加入者に向けたスマートフォン用運転走行計測アプリ。
スマートフォンアプリ、AWS 上にデプロイされたサーバシステムで構成される。
AWS は、サーバレスサービスを用いたマイクロサービスアーキテクチャを採用している。
既存で動作しているスマートフォンアプリ・サーバシステムに対して、キャンペーン機能を追加する。
AWS では、新規 DB、API、バッチの開発を行う。
10 名規模
Typescript
ECS・Lambda・API Gateway・DynamoDB・RedShift
AWS チームのリーダーとして要件定義を担当した。
顧客と直接会話し、仕様調整を実施した上で要件定義ドキュメントを作成を行った。
また、チームメンバーへの作業依頼や成果物レビューを担当した。
自社内では、開発以降の工程に向けて、見積もりや要員募集、 BP 面談の対応を行った。
このプロジェクトでは、リモートワークと出社を併用していたため、コミュニケーションの取り方を特に意識した。
具体的には、チームで話し合うべき懸念点や認識合わせるべきことがある場合は積極的にリモート会議を開くことを心がけた。
また、配下メンバーに対しては、些細な疑問点でもリモート会議で会話することを奨励し、
意思疎通のミスを最大限抑えた。
プロジェクト外では、私が所属していた部門の改善活動に積極的に取り組んだ。
2 年目から自社内のリーダー職を拝命したことで、自分の開発チームだけでなく、会社組織としての改善にも目を向けるようになった。
特に力を入れて取り組んだのは以下 2 点である。
① 役職者に集中した業務のリーダー職での巻取り
② 新卒教育環境の整備
① については、役職者が実施する必要のない雑務まで行ってしまっていることで無駄に逼迫してしまっていることが
明らかであったため、業務の棚卸しを行い、リーダーの定常作業に落とし込むことに成功した。
② については、機能不全に陥っていたチューター制度改善の一環として、日報制度の導入を行った。
日報制度については、以前実施していた際に形骸化してしまったという経緯があったため、
その改善策の検討から始め、再導入について役職者に提案を行い、実現させた。
- チーム内外でのコミュニケーション活発化のために、自分が一番情報発信をすること
- 周りのメンバーが仕事しやすい環境を作ること
- 自分のやりたいことを常に発信すること
- やりたいことを任せてもらうために逆算して行動すること
| 資格名 | 取得年月 |
|---|---|
| 普通自動車第一種運転免許 | 2018/3 |
| 中学校教諭二種免許状(英語) | 2020/3 |
| Oracle Certified Java Programmer, Silver SE 11 | 2023/3 |
| AWS Certified Cloud Practitioner | 2023/5 |
| AWS Certified Solutions Architect - Associate | 2024/5 |
| TOEIC Listening & Reading Test 755 点 | 2024/10 |