ID:25091さん

# プロジェクト概要 - 新規事業垂直立ち上げに際し、会計システムを導入した - 企画から運用 - Dataformを採用した # 取り組んだ課題 - 既存の会計システムの問題点を鑑み、以下の方針にてプロジェクトを進めた - data lake / data mart化 - ワークフロー導入 - プロダクトDBの負荷を0にするためBigqueryにて連携 - 連携する際、イミュータブルデータモデルに即してモデリング # 取り組みの成果 - ワークフロー導入により下記のメリットを得られた - 仕訳ロジック等の複雑性を局所化 - data lakeを設けることによりリコンサイルを簡易化 - イミュータブルデータモデル導入による監査性の向上

プロジェクト概要 - ガバナンスの強化 - 管理画面の権限細分化 - 企画から運用 # 取り組んだ課題 - 頓挫していた個人情報の取り扱いの整理 - VPoE、CIOと連携しながら各部署と合意形成 - 各ツールで参照出来るカラムやそうでないカラムを定義 - リリース前から開発環境で各部署の代表者に触ってもらい、認識齟齬を無くしながらプロジェクトを進行 # 取り組みの成果 - セキュリティインシデント0件 - 各部署でオペレーション開始時の混乱がなかった - この取り組みを皮切りにDBのマスキング等のガバナンスが一気に高まった

# プロジェクト概要 - リリースサイクルがプロダクトにロックインされており、会計システムの刷新に時間がかかっていた - プロダクトに依存していた会計システムをマイクロサービス化 - 社内初のRuby 3系 / Rails 7系バージョンアップ - インフラをECSに切り替え # 取り組んだ課題 - リポジトリ分割と不要コードの削除 - バージョンアップについては下記の方針を採った - rubyのすべてのchangelogの机上確認 - coverageを97%までアップ - 都度レビューを行ってもらい、撤退ラインを決めながら進めた # 取り組みの成果 - 以下の点よりROIに優れた成果を残せたと考える - プロダクト影響ゼロで会計システムの改善が可能となった - バージョンアップ時のドキュメントを全て残していたため、他のリポジトリバージョンアップ時のマイルストーンとなった - ECS / Jobscheduler構成になりインフラ運用工数激減 - k8s移行のたたき台となった

# プロジェクト概要 - メール配信の追跡性が問題視されていたため、Sendgridで一元的にメールを配信する - 企画から運用まで1名で完遂 # 取り組んだ課題 - 各リポジトリでメール送信方法が統一されていなかった - インフラTと連携し通信経路を統一 - AWS SESからSendgridへ移行 # 取り組みの成果 - 内部的には通信経路が統一され、ロギングが可能となった - ユーザー様からの問い合わせについてSendgridからどんなステータスか確認可能になったためCS業務工数の大幅削減となった

# 当プロジェクトの目的 - BtoBtoCスマホアプリによる交通機関の利用増 # 当プロジェクトでの役割 - バックエンド開発 - Web API開発 - プレイングマネージャー（途中参画） # 当プロジェクトの問題点 - Laravel有識者がいなかった - 進捗に遅れが生じていた # 当プロジェクトにて発揮したバリュー - LaravelとRoRを比較、及び、Laravelのコードリーディングを行い、フレームワークの拡張、及び、共通処理を実装した - WBSを引き直してチームの開発ペースを改善した - ドキュメントが散逸していたので、ExcelからMarkdownで書き直し、Git管理を行い、一元管理を行った - 当社としてはノウハウがない状態であったが、インフラ担当者と協力してAWSにて性能テストを完遂した # 結果及び教訓 - メンバーの士気を高く保ち、品質改善を行いながら当初予定通りにリリース出来た - LaravelのValidation機能は一見便利に見えるが、業務ロジックと絡むところなので拡張（その際はリフレクションを採用した）を行ったところ、ソースコードの可読性が上がり、レールから敢えて外れる決断も必要だと痛感した - JMeter自体がボトルネックになることは事前調査で分かっていたため、負荷をかけるサーバ自体をマスター・スレイブ構成にして成功させた - タスクの整理とドキュメントの一元管理がされていないと、メンバーに諦めムードが立ち込め、自分の作業範囲を決めてしまい、チームが成立しなくなることを再認識した

# 当プロジェクトの目的 - 請求業務改善のためのシステム導入 # 当プロジェクトでの役割 - バックエンド開発 - プレイングマネージャー # 当プロジェクトの問題点 - 短納期であった - 性能を求められた - 炎上していた # 当プロジェクトにて発揮したバリュー - 5人をマネジメントしながらSQLのチューニングを行った - 債権回収は業務の一番後ろにあたるため、各業務チームと調整を行い、迅速に仕様を決定した # 結果及び教訓 - 納期通りに納品可能となった - JavaとOracleのスキルトランスファーを行えた - 性能に関してはViewを構えて可読性を向上させると共に、PL/SQLを駆使して速度に勤めた - 上述の経験のため、後のフルスタックフレームワーク内のOR Mapperを採用するべきか否か、採用するとすればどこに気を付けるべきかの判断が可能となった

# プロジェクトの目的 - レンタル機器散逸の低減 - 管理会計導入 # 当プロジェクトでの役割 - コンサルタント - クライアント側PMO # 当プロジェクトの問題点 各ステークホルダーの期待していることに齟齬が見られた #当プロジェクトにて発揮したバリュー - 各ステークホルダーの期待していることに齟齬が見られたため、それぞれヒアリングを行った。特にエンドユーザーの実際の動作に注目し、適切なシステム企画に落とし込んだ - RPF作成に当たっては、テーブル設計と画面のワイヤーフレームまで作成し、基本設計書に近いところまで落とし込んだ。経験則的にUXが悪いと使われなくなる、データ構造が悪いと拡張が困難になるからである - ベンダーコントロールにおいては、進捗管理よりもリスク管理と品質管理に重きを置いた。これは概ねオンスケジュールではあったが、各ドキュメントのレビューを入念に行い、進捗に遅延が発生しそうな記述を明らかにし、ベンダーのメンバー個々人にヒアリングを行い、理解のレベル感を統一した # 結果及び教訓 - 問題発見を早期に行うことにより、最適なシステムのご提案と完遂が可能となった - ベンダーがVB.netが得意だったのだが、1ファイルにフロントからモデルまで記述するスタイルではなく、MVCに近いアーキテクチャを採用して頂けるよう粘り強く交渉を行い、拡張性の向上を行って貰った - 進捗が芳しくない場合、当人の問題ではなく、プロジェクトの課題として扱う事により、風通しの良い環境になると共に、リスクの洗い出しが格段に楽になると痛感した

# 当プロジェクトの目的 - 各部署一気通貫の進捗管理 # 当プロジェクトでの役割 - コンサルタント - プレイングマネージャー # 当プロジェクトの問題点 - 各事業部でシステムがサイロ化しており、一気通貫の進捗管理システム導入に関してステークホルダー内でコンフリクトが生じていた - 開発時にアサインされたのが新人ばかりだった # 当プロジェクトにて発揮したバリュー - 各事業部の意思統一を行うために巨大な方眼紙とポストイットを使用し、データの流れと業務上のキーを明確にした。全員が同じ紙を見るため、同じ方向を向いて議論が可能な状況になった - 上述を受け、各事業部にはデータ取得用のAPIを用意して貰うだけでよい（システム改修や業務の仕方の変更はなし）と合意形成を行い、そこからデータを抽出して一元管理するアーキテクチャを提案し、全員が納得出来る形になった - 私とシニアエンジニアがJavaにてアーキテクチャ及びURLの設計、実装を先んじて行い、新人エンジニアのサポートを行った。 - ペアプログラミング、及び、テスト駆動開発にて迅速な開発が可能となった # 結果及び教訓 - PMBOK5版で導入されたステークホルダーマネジメントだが、クライアント内でもコンフリクトがあることが分かったので、まずそこの意思統一が必要だと痛感した - 新人育成に祭して、TDDを採用することにより、設計技法と共に良いコーディングスタイルを育むと感じた - 新人育成に祭して、5分悩んで貰うルールを設けて、自己解決出来た時の嬉しさを共有出来た