ID:81518さん

アピールしたい強み： ・プロジェクトマネジメントスキル（QCD担保、チームメンバーのモチベーション維持、プロジェクト推進力、リスク管理） ・ベンダーコントロールスキル（要件定義・設計のレビュー、クライアントの要求とベンダー側の要件定義に齟齬があるときの立ち回りなど） 期間： 2025年１月~ 現在 案件概要/目的： スマートフォンアプリ／データ同期ツールの刷新プロジェクトにおいて、私はプロジェクトサブリーダー兼サブシステムチームリーダー として、 要件の整合性確認、チームマネジメント、ベンダーコントロールを担いました。 ・プロジェクト規模：501人月 ・開発言語：dart(Flutter)、Java、C#、apache/tomcat, SQLite, SQL Anywhere,さくらのクラウド、AWS 体制： ・プロジェクトリーダー：１名 ・プロジェクトサブリーダー：１名 ・ベンダーリーダー：１名 ・ベンダーサブリーダー：２名 ・メンバー（ベンダー含む）：32名　※流動的なため現在の人数を記載 役割/スコープ： ・プロジェクトサブリーダー兼サブシステムチームリーダー ・ベンダーコントロール ・連携ツールの課題対応（設計、製造を一部対応） 他のメンバーからどのように言われている？： （上司から） 厳しいスケジュールと限られたリソースの中でチーム全体の業務効率を常に意識し連携チームリーダーとして予定工数、期日を達成できている点より、努力家で責任感のある人だと評価いただきました。 どのようなモチベーションでそのような取り組みをしようと思ったのか： 全体的に課題が多く発生し、スケジュール遅延が発生していたため、 プロジェクトの遅延をなるべく解消したいと思って取り組んでおりました。 成果を出せるようになるまで苦労したことはありますか： メンバー層の自走力がプロジェクト推進の鍵だと考え、 メンバー層に向けて、よりシステムの理解を深めてもらうため、情報整理や資料作成に時間をかけていたこと。 チームの成果を出すために工夫したこと： ・冗長的、不要な仕様や設計を見つけ、工数削減を図るために、レビューをする気持ちで設計書類を参照していた。 課題(苦労)： ① レビュー済みの設計書にて、連携仕様の不整合が多数存在し、後工程で大きな手戻りが発生するリスクがあった └連携先システムのDB定義やAPI仕様と整合が取れていない部分を複数発見 └設計段階で気づかないと、後続の製造・テスト工程で大幅な工数増加が見込まれた ② チーム体制が未整備の状態でプロジェクトが開始 └開発環境（WSL、IDE 等）が未構築 └新規参画者が仕様理解に苦しみ、立ち上がりに時間がかかる状況だった 工夫(どのように工夫し解決したか)： ① すぐに連携先システムのリーダー（ベンダーリーダー、自社のリーダー）に情報を整理して展開し、 なぜそれが課題だと思うのか？（仕様上、対象のテーブルは不要で、こちらのテーブルで情報を管理できる等）課題を解決した場合、どのような効果があるのかを説明し、話し合いを得て合意いただいた。 上位工程（基本設計）で早期発見できたため、後続の工程（製造、単体テスト等）の工数削減、品質向上につながった。 なぜその工夫をしたのか？：冗長な仕様の排除は工数削減につながると考えたため ② 開発環境(WSL, visual studio)の刷新、レガシーシステムのモダナイゼーション（Java8 ⇒Java11、tomcat8 ⇒ tomcat10.1）、開発環境構築手順書、デバッグ手順書、アプリケーション仕様書を自発的に作成。 新規参画者や初学者が参画しやすいような環境を作り、なるべく各々が自走してタスクを消化できるように工夫した。 メンバー事に進捗状況については随時会話して認識合わせを実施。不明点や質問事項があった場合はその場で回答し、相手が理解しているかどうか（Output内容より判断）反応を見ながらコミュニケーションをとる工夫をした。 なぜその工夫をしたのか？：新規参画者や今後の運用保守メンバーが参画しやすいようにと、属人化解消につながると考えたため 成果： 後工程の工数削減と品質向上 └ 上位工程での仕様不整合を早期解決でき、製造・テストの手戻りを大幅に防止 チームが自走できる体制の構築 └ 新規参画者でも短期間で立ち上がれる環境を作り、チームの生産性向上に寄与 ベンダー含む関係者との調整力を評価され、プロジェクトサブリーダーとして継続的に任用

アピールしたい強み： ・リスク察知能力：重大な観点漏れに気づく ・プロジェクト推進力：改善提案し、合意形成まで行う ・当事者意識：品質と現場の安全性を重視 期間： 2024年10月 – 2024年12月 案件概要/目的： 介護事務処理システムの更改プロジェクト 介護老人保健施設・介護医療院のお客様からの要望対応。 常勤医師が現職のシステムの記録機能を使用する際、申し送り事項や利用者ごとの記録（バイタル情報等）をシステム上で登録するが、そのシステムにログイン可能な全職員が、医師が登録したデータを編集できてしまう状態にあった。 それだと、医師が登録した情報を書き換えられ、介護・医療現場において重大なオペレーションミスを招く可能性があり、対応が必須であった。 開発言語：Power Builder ,SQL Anywhere 規模：9.3人月 体制： プロジェクトリーダー：１名 メンバー：5名 役割/スコープ： メンバー 他のメンバーからはどのような人だといわれるか： 主体的なアクションがあり、プロジェクト全体の品質向上を考え実践できる人 どのようなモチベーションで他の人と違う取り組みをしようと思ったか： 重大事故につながるような要件の対応だったため、リリース後の失敗はできないと思い、 品質重視でプロジェクト全体を見ようと考えておりました。 成果を出せるようになるまで苦労したことはありますか： 自分の提案とその提案から得られる効果を説明する際の情報整理に時間をかけた チームの成果を出すために工夫したこと： リリース後に問題なく稼働することがプロジェクト成功の鍵だと考え、 品質向上に重きを置いて全体の動きを見るようにしておりました。 課題(苦労)：テスト仕様書を作成する中で、参考にした他メンバーのテスト仕様書に 重大なテスト観点漏れがあることを発見。 このまま進めると、重大事故につながる重要機能で不具合を見逃す可能性が高く、 プロジェクト品質・現場オペレーションに深刻な影響が出る懸念があった。 工夫(どのように工夫し解決したか)： ① リスクを即座にリーダーへエスカレーションし、改善案までセットで提示 ただ報告するだけでなく、 「テスト観点の全体見直しを行うべき」 という提案まで行い、合意を獲得 医療・介護現場での誤編集リスクの重大性を論理的に説明し、優先度を引き上げ なぜその工夫をしたのか？：メンバーとして説得力のある提案を実施し、 優先度高めで最優先で実施していただくため ② テスト観点を再構築し、漏れのない仕様書作成に貢献 権限制御、編集不可パターン、境界条件などを網羅的に洗い出し チーム全体のテスト観点を統一し、複数メンバーの品質差を調整 なぜその工夫をしたのか？： テストケースを網羅的に再構築し、テストで検出されるべき不具合を発見し、 品質向上を図りたかったため

アピールしたい強み： ・性能改善・障害復旧の高い再現性 ・課題の根本原因を技術的に深掘りできる能力 期間： 2023年11月 – 2024年3月 案件概要/目的： 訪問系介護事業所向け Web／スマートフォンアプリの更改・運用保守プロジェクト に参画。 既存システムでは、訪問中の実績記録・スケジュール管理が紙媒体に依存しており、 施設に戻ってからの入力作業や紙の持ち歩きなど、現場職員の負担が非常に大きかった。 これらの課題を解決するため、 現地訪問時の記録入力を スマートフォンアプリ（Flutter/WebView） で完結させ、 データを Webアプリ（Spring Boot＋REST API）/ Aurora MySQL で即時参照できる仕組みを構築・改善。 開発言語：Dart/Flutter、Vue.js、Spring Boot、eginx、Java、Aurora My SQL、AWS 体制： ・プロジェクトリーダー：１名 ・ベンダーリーダー：１名 ・メンバー(ベンダー含む)：11名 役割/スコープ： ・メンバー/品質改善：性能改善業・障害解析担当 他のメンバーからはどのような人だといわれるか： 技術の吸収が速く、未知の課題に対する分析能力が高い人 責任をもってやり遂げてくれるから、任せられる安心感があると評価をいただいております。 どのようなモチベーションでそのような取り組みをした？： レスポンス低下はクライアントのUXを著しく低下させるものであり、 早急に対処し、恒久対策を実施し、深刻な状況を正確にいち早く解決したいと思っていました。 成果を出せるようになるまで苦労したことはありますか： 未知の不具合に対してのアプローチだったため、原因調査と、原因となっている処理や複合的要因をまとめるのに時間を要しました。 チームの成果を出すために工夫したこと： チーム全体でその障害を認識し、もしもの時に各々が問題に気づけるように 障害の内容と原因⇒原因となっている処理の言語化⇒対応策の言語化 を実施した資料を作成したこと 課題(苦労)： ① Push通知を実現するバッチAPIにより、 DB負荷が異常上昇し、アプリ全体の応答性能が低下していた 5分毎に定期実行されるバッチAPIにて、 Aurora MySQLでI/O負荷の急増が発生し、 Webアプリ／スマホアプリでレスポンス低下が発生。 ② Push通知処理の仕様がブラックボックス化していた 古い実装が長年放置されており、どの条件でレコードが生成されるか どの処理が Push通知対象として扱われるのかといった仕様が不明瞭で、原因の直感的把握が困難だった。 ③複数の要因が絡む複雑な障害で、単純な修正では解決できなかった 作成日が古いレコードが現在も処理対象となる 不要なレコードが毎日自動生成され、負荷が蓄積 抽出クエリが非効率でフルスキャンが発生 レコード量が増えるほど負荷も雪だるま式に増加 問題の構造が複数レイヤー（バッチ・クエリ・DB・運用）にまたがっていた。 ④本番環境で発生していたため、影響を拡大させずに原因特定が必要だった 処理を止めたり大胆な修正ができないため、 安全性を担保しつつ段階的に原因を切り分ける必要があった。 工夫(どのように工夫し解決したか)： ・まず、本番環境にて、原因となっているレコードを特定し、 その対応が問題ないことを確認の上、論理削除を実施。急激な負荷増を解消 ① 処理全体を分解して因果関係をファイルに記載し可視化（提案資料としても有効なため） Push通知の一連の仕組み（タスク → mapping 生成 → 抽出クエリ → バッチ本体）を 実データ・コード・ログを照合しながら分析。 → 古い レコードがそれに紐づくテーブルにおいて大量のレコード を生成していたことを特定。 ② Performance Insights・クエリログを用い、負荷原因を定量的に特定 以下を数値で可視化： 負荷を生んでいた特定クエリ スパイクが起きた時刻帯 レコードが無駄に生成されていた処理ステップ → 根拠に基づき “どこを直すべきか” を特定。 ③ 抽出クエリの最適化を実施 処理対象とする必要がないレコードを対象外にする条件追加 不要な古いレコードを処理対象外にするプロシージャの実装提案⇒合意⇒実施 原因となっているバッチ処理の一部をアプリ稼働率が低い夜間帯に実行するように切り出し 抽出 SELECT、必要に応じてインデックスを作成する等によるフルスキャン解消 → DB負荷の恒常的削減を実現。 ④ 原因 → 改善案 → 恒久対策を体系化し、運用部門へ安全に引き渡し 対策案を構造化し、プロジェクトリーダーと合意。 障害パッチとしてリリース後、 数週間 DB負荷をモニタリングした結果、再発なし。 → アプリケーションの安定稼働を継続的に実現。 なぜその工夫をしたのか？： ① 自身の情報整理を実施するためと、後の対応策の提案時に資料として使用するため ② 原因を定量的に分析し、提案資料に説得力を付与したかったため ③ ＤＢ負荷の恒久対策を実施するため ④ 双方が納得しながら対応を進めるため