Hideyuki Matsuyama

＜担当業務など＞ ・バックエンド要員として参画し、CRUD操作を行うRESTful APIの詳細設計と実装を担当 ・APIのPull Requestをフロントエンドチームと共有して完了 ・git flowに準じた開発フロー ＜業務内容＞ ・実装フェーズ中の参画。一人称で自走してのエンジニアリングに従事 ・既に用意されているBacklog, Github Issueから抽象度の高い要件を汲み取り、詳細設計をGithub IssueまたはPull Requestにmarkdownで清書し、レビュー依頼を発行 ・必要に応じて開発チームリーダーとのハドルミーティングを随時開催し、齟齬や手戻りを防止しつつ作業を進めた ・クライアントの担当者（非技術者）とのFAQを通して作業を進めた ＜実績・取り組み＞ ・アウトプットから属人性を排除することを常に意識しているが、雇う側の経営的リスクが抑えられるということで高い評価が得られた ・参画初日のオンボーディング以降はほぼ放置状態だったにも関わらず、2日後にはPull Requestを発行したスピード感に関しても高く評価された - Rails 7.0.3, ruby 3.1.2, Slim, Vue.js(2.x) - Ransack, Postman, - Docker, GitHub, CircleCI, Backlog, - Slack, Google Meet, Microsoft Teams

＜担当業務など＞ ・サービス開始は2015年。紆余曲折あって1人だけになってしまった開発チームにプログラマとして参画 ・アジャイル開発（スプリント、スクラム、レトロスペクティブ） ・GitHub flowに準じた開発フロー ＜業務内容＞ ・起票済みのGithub Issueをベースに一人称で自走するエンジニアリング ・ユニットテストを量産できる環境構築と、40分かかっていたビルドを5分台に短縮した ・E2Eテストの環境構築 ・開発環境が何をするにも重たいため改善した。開発当初からある魔改造が原因だった ・要件定義が必要なケースにおいて、非技術職の現場スタッフとAs-ISとTo-Beを握手しつつ開発を進めた ・自分でUIを考えたケースでは手戻りを最小限にするため、ビジネスロジックを実装する前に画面だけの紙芝居をレビューにかけるなど柔軟に振る舞った ・システムを利用する現場スタッフの目線でユースケースを考える癖があり、様々な提案が採用され喜びのフィードバックを頂くことが多々あった 　→e.g: 荷物発送時のオペレーションにバーコードリーダーを導入したケースにて、現場スタッフがバーコードをスキャンする際はPCの前に居ないよね？と予想し、エラー時にビープ音を鳴らす仕様を実装したところ大変好評だった ・Sentryからのエラー通知をSlackが受けると、メンバー各自が作業中の手を止めて調査する文化があり、Tandem上に障害調査部屋が作成、会話しつつDatadogで解析を行い、緊急性に応じてhotfixか通常リリースかの切り分けなど行った ・https://www.wantedly.com/companies/beerandtech/post_articles/201607 ＜実績・取り組み＞ ・自分にノウハウが集中していた作業に関して、ドキュメントを整備することで属人化を排除した - Ruby on Rails 4.2, Ruby 2.4, Rspec - JavaScript(ES5), TypeScript - React, Vue.js - ERB, Slim, SCSS - Capybara - Github, Zenhub, Pulse, Notion - Datadog, Sentry - Slack, Tandem, Google Meet - Figma, draw.io - CircleCI

- プログラマー（RonR）、コードレビュー、開発チームのマネージメント、他部署からの問い合わせ窓口、外注管理 - スクラム・8名、ほか営業、SE、サポートなど約30名 - 開発チームのプレイングマネージャとして、プロダクト全体を左右する職責で従事した（2011年5月までフリーランスのプログラマーとして参画していた） ▼目的を達成する上での課題 自社製品とは言え、収益の大半をカスタマイズ案件が占めるため受託開発に似たプロダクト。ユーザー企業ごとに個別の機能追加・変更、オリジナルデザインの適用などがあり、ソースコードのバージョン管理が複雑さを極めた。また、従来からある仕様の複雑さも併せて、Q&Aを受けたサポートチームとのやりとりもスムーズではなかった ▼課題に対して取り組んだこと 各カスタマイズ案件で実装したスペシャルな機能の中から、masterに入れても良い機能を選別して取り込むことを継続的に行った。これに際し、あるユーザー企業からお金を頂いて実装した機能が、別の企業も利用できるようになることの問題と、masterのデグレーション問題とがあったが、これらを地道に解決しながら進めた。 また、開発メンバーが交代で島根県松江市の某社に出張を繰り返し、Rubyコミッターとのペアプログラミングを通じてRSpecを習得。ブラウザテストも習得して、自身の経歴上初となる継続的インテグレーションを実現。仕様を共有するため、E2Eテストのシナリオを非開発者にも読んでもらうよう働きかけた ▼成果 問い合わせ対応、バグの原因調査と修正、バージョン管理の煩雑さ、リリース用branchを作る際のヒューマンミスなどが軽減できたため、機能追加に割く工数が増加しプレスリリースにもリズムが生まれ、予定通りに新機能をどんどん提供できる体制が構築できた。ユーザー向けイベントも定期的に開催できるようになり、プロダクトがどんどん健全化されていった