takuto

## 案件概要 / 目的（案件①） 2025年1月〜現在まで、**501人月規模／開発体制40名規模**の、 スマートフォンアプリ／スマホアプリ⇆デスクトップアプリ間の **データ同期ツール刷新プロジェクト**において、 私は**プロジェクトサブリーダー兼、データ同期ツールのチームリーダー** として参画しました。 本プロジェクトは、既存システムの老朽化や設計不備に起因する **保守性・拡張性・性能・セキュリティ面の課題解消**を目的としており、 私は**QCD（品質・コスト・納期）を担保しながら、 チーム全体の生産性向上と再現性の高い開発体制の構築**を推進しました。 プロジェクト管理の観点では、QCDを意識した進行管理に加え、 各種ドキュメント（要件定義書・基本設計書・ソースコード）のレビューを通じて、 **設計不備や将来的な工数増加につながる問題点を早期に発見**しました。 担当サブシステムの責任者として、連携先システムへの出戻り影響範囲と 代替案を整理して提示し、PMおよびアプリPLと合意の上で、 設計変更タスクとしてアプリ・連携ツール全体で管理し、 設計変更を完了しました。その結果、**テーブルを1つ削除でき、 約15人日の工数削減**に成功しました。 また、私がリーダーを務めるサブシステムについては、 当初計画より**約17人日早くテスト工程まで完了**させることができました （プロジェクト全体では**約1人月の削減**です）。 実装面では、一部のレアケースについて、 要件整理から設計・実装までの意思決定をリードし、 Java／C#において品質・保守性を担保した対応を実施しました。 品質面においても、社内基準である「総不具合密度 3.5件/KLOC 以下」 「テストケース密度 40テストケース/KLOC 以上」を満たし、 **総不具合密度 0.94件/KLOC、テストケース密度 58.42テストケース/KLOC**を達成し、 高品質な成果物の提供に貢献しました。 非機能要件の領域では、以下を担当しました。 * フロントエンド（iOSアプリ）開発環境の構築 * バックエンド開発環境およびサーバ構築 * Apache・Tomcat（8 / 10.1）を含むミドルウェアのマイグレーション * WSLを用いた開発環境、Docker Composeを用いた検証環境の整備 * Wiki作成やシェルスクリプト活用による手順の標準化・自動化 さらに、レガシーシステムに内在していた**セキュリティ上のリスク（脆弱性） を発見**し、技術的観点からリスクを整理・説明した上で、 関係者と合意形成を行い、**対策方針の策定から実装・検証までを主導**しました。 加えて性能面では、仕様を担保した上でクエリチューニングを実施し、 **ボトルネック仮説 ⇒ 計測設計 ⇒ 改善 ⇒ 再計測**の手順を定義して、 誰が実施しても再現できる形で性能改善を主導しました。 --- ## アピールしたい強み（案件①） 私は、性能・運用・セキュリティ・開発効率といった「詰まり」を早期に見つけ、 関係者を巻き込んで意思決定し、標準化／自動化／再現可能な環境として定着させることで、 **QCDを守りながらプロジェクトを前に進める推進力**が強みです。 具体的には、以下の再現性を強みとして持っています。 ① **プロジェクト推進能力**（QCD担保、開発環境の構築、手順書作成による生産性向上、 工数削減につながる設計不備の発見と改善案提示） ② **サーバ構築における高い再現性**（開発効率・テスト効率向上を 目的とした環境設計、WSL＋NetBeans＋Apache＋Tomcat8＋Tomcat10.1の開発環境、 Docker Compose＋Apache＋Tomcat8／Tomcat10.1の検証環境、 Wikiによるナレッジ体系化、シェルスクリプト活用による非本質作業の削減） ③ **セキュリティ観点と対策の再現性**（脆弱性の発見、 リスク説明・合意形成のうえでの対応、運用・保守フェーズまで見据えた改善） ④ **要望を開発に落とし込む論理的思考力と実装の確実性** （要件整理⇒設計・実装へ論理的に落とし込み、Java／C#で安定した品質を担保） ⑤ **スマホアプリ開発基盤（App Store Connect／TestFlight） 構築の再現性**（証明書・Bundle ID・Provisioning Profiles定義、 TestFlight配信、内部／外部テスター権限管理、ビルド／配布手順Wiki化、 継続運用可能なリリース体制構築） ⑥ **性能改善の再現性**（仕様を担保したクエリチューニング、 効果検証と再現可能な改善、根本原因へのアプローチ） --- ## 開発言語・技術要素（案件①） Dart（Flutter）、Java（Jakarta EE 10）、C#、Apache／Tomcat、 SQLite、SQL Anywhere、さくらのクラウド、AWS、Docker を利用しました。 --- ## 体制（案件①） * プロジェクトリーダー：1名 * プロジェクトサブリーダー：1名 * ベンダーリーダー：1名 * ベンダーサブリーダー：2名 * メンバー（ベンダー含む）：32名（流動的なため現在の人数を記載しています） --- ## 役割 / スコープ（案件①） * **テックリード** （アプリ⇒連携ツール⇒ストップアプリまで含めたテスト環境・開発環境の構築を担当しました） * **プロジェクトサブリーダー** （iOSアプリ側の要件・設計仕様レビュー、アプリ側開発環境の構築を担当しました） * **連携ツールプロジェクトリーダー** （改修対象60テーブル、チーム5名の体制で、進捗管理・タスク管理・課題管理・リスク管理・開発環境整備を担当しました） --- ## 他のメンバーからどのように言われているか（案件①） 上司からは、厳しいスケジュールと限られたリソースの中でも、 チーム全体の業務効率を常に意識し、連携チームリーダーとして 予定工数・期日を達成できている点から、 **努力家で責任感がある**と評価いただいています。 --- ## チームの成果を出すために工夫したこと（案件①） 冗長・不要な仕様や設計の発見、開発環境の統一など、 チームの生産性向上による工数削減の余地がないかを常に意識しました。 また、改善案の提案から合意形成、対策実施までを一貫して進めるために、 主体的なアクションを継続することを意識しました。 --- ## 課題（苦労）・失敗したこと（案件①） ①-1（プロジェクト推進能力：QCD担保） アプリ側のDB設計書を確認する中で、仕様上、対象テーブルの 全カラムデータが不要であるにもかかわらず、不要なデータまで 連携してしまう設計になっている箇所を発見しました。このまま進めると、 データ連携量の増加による性能劣化リスクや、後続の製造・テスト工程 における工数増大につながる懸念があり、QCDの観点で問題があると考えていました。 ①-2（プロジェクト推進能力：チーム生産性向上） レガシーシステムの開発環境を流用する選択肢もありましたが、 当該環境では、NetBeansでビルドしたWARをTomcatに配置し、 アプリケーションログからコールスタックや処理結果を確認する運用になっており、 IDE上でTomcatをデバッグモード起動する仕組みがありませんでした。 そのため、原因調査や修正に時間がかかり、開発効率が著しく低下する懸念がありました。 ②（サーバ構築における高い再現性） レガシーシステムの検証環境として Vagrant＋VirtualBox＋CentOS 7.9 が 使用されていましたが、VM起動が非常に遅く、 CentOS 7.9はEOLによりmirrorリポジトリ停止でyumが実行できませんでした。 本番環境はAlmaLinux 9系でOSが異なり検証環境として不適切で、 特定担当者に属人化しており更新もされていませんでした。 これらの理由から流用は現実的ではなく、再現性のある環境再構築が必要でした。 ③（セキュリティ観点・対策の再現性） 刷新プロジェクトのサーバ構築中に、 レガシーシステムで重大なセキュリティリスクの懸念を2点発見しました。 * 画像・動画データ連携でSMB1.0プロトコルを使用しており、 暗号化不十分・署名や整合性検証が弱く、中間者攻撃に弱い点がありました。 既知の脆弱なプロトコルであり、使用継続は高リスクだと考えました。 * Tomcat 8系を使用し、Apache⇆Tomcat間通信でAJPを利用しているにもかかわらず、 secretRequiredが有効でsecret未設定、 かつ全ネットワークIFで受け付け可能な状態でした。 CVE-2020-1938（Ghostcat）では、AJPが外部到達可能な場合に任意ファイル読み取り （WEB-INF／META-INF等）やJSP強制実行、条件次第でRCEが成立し得るとされていました。 ④（要望を開発に落とし込む論理的思考力と実装の確実性） 本アプリはオフライン環境でも業務利用できることが前提で、 データ同期はアプリ内の「送受信ボタン」により実施する仕様でした。 その中で、送受信処理中にネットワークが切断された場合、 正常レスポンスを受け取れずエラーと判断され、 再送により同一レコードがデスクトップアプリ側へ重複登録される 可能性があるというレアケースを提起しました。 この点は要件定義段階で明確にしておかないと後戻りコストが高い課題でした。 ⑤（スマホアプリ開発基盤環境構築の再現性） プロジェクト初期段階ではiOSアプリの開発・検証環境が未整備で、 メンバーごとに環境が異なり、検証条件が揃っていない状態でした。 そのため、テスト時に環境差異が発生するリスクがありました。 また、営業や上流層に開発中アプリを共有してUI/UXフィードバックを 得る必要があり、統一された配布・検証手段が求められていました。 ⑥（性能改善の取り組み） 新仕様により30テーブルが新規追加され、 アプリ⇆デスクトップアプリ間のデータ連携対象となっていましたが、 対象テーブルにインデックスが未作成で、 レコード取得時にフルスキャンが発生していました。 このままではデータ増加に伴い将来的な性能劣化を招くリスクがありました。 --- ## 工夫（どのように工夫し解決したか）と成果（案件①） ①-1（QCD担保） アプリ側リーダーおよび統括PMとの打ち合わせを設定し、 課題の背景と影響範囲を整理した上で、 不要と判断したテーブルは既存テーブルと外部結合し、 必要なカラムのみ連携する方針を解決策として提案しました。 関係者と合意形成を行い設計へ反映したことで、 設計工程の段階で早期に課題を発見・是正でき、 開発工程に着手する前に不要な対応を回避できました。 結果として当該テーブル対応分について、**全体で約1人月の工数削減**を実現しました。 ①-2（チーム生産性向上） 以下条件を満たすものとして開発環境にWSLサーバを採用しました。 * メンバー全員の開発環境がWindows 11であること （WSL2＋WSLgが標準で有効でありGUIツール起動が可能） * NetBeansがGUIで起動できること * NetBeans上でTomcatをデバッグ起動できること * WSLサーバのOSが本番環境と同一のAlmaLinux 9.6系であること * 刷新前（Tomcat8）と刷新後（Tomcat10）の環境を比較できること （旧システム動作確認や新旧比較の評価観点があるため） 上記条件を満たすよう、WSLディストリビューションに NetBeans、Tomcat8系、Tomcat10系、Apacheを導入し、 httpd.conf／ssl.conf／サーバ証明書／秘密鍵配置／Tomcatのsetenv.sh／server.xml等の 設定を行いました。Java実行環境は、Tomcat8はCorretto 8、 Tomcat10はCorretto 11で構築しました。 構築後、NetBeans上でデバッグモードでアプリケーションが起動することを確認し、 WSLディストリビューションをexportしてzip形式で開発メンバーへ展開しました。 あわせて、importして自環境でデバッグ実行する手順をWiki化しました。 さらに、同一LAN内のスマホ端末からアプリ操作でWSL環境へ同期できるよう、 ホストからWSL公開ポート（HTTPS 443）へのポートフォワーディング設定、 Firewallの特定ポート許可設定もWikiへ記載し、 メンバーが同期処理の調査・検証を行える状態を整えました。 結果として、開発段階およびテスト工程で不具合調査時に活用でき、 **全体的な開発効率向上**につながりました。 ②（検証環境の再現性：Docker Compose採用） 刷新プロジェクトでは検証環境にDocker（Docker Compose）を採用しました。 結合テスト環境はAWS上に構築予定であり、ローカル・検証・本番を 通して同一構成を再現可能にする必要があったためです。コンテナ技術により 環境差異を最小限に抑えつつ、可搬性の高い構成を実現できると判断しました。 WSLディストリビューションをそのまま検証環境にする案も検討しましたが、 AWS上ではAnsible等によるホスト構築が必要となり、 コンテナと比較して構築・運用コストが高くなるため見送りました。 また、Docker Composeによる構成管理により、 どの環境でも同じ結果が得られる冪等性を担保できる点も重視しました。 構成管理はDockerfileによるIaCを前提とし、 ミドルウェアや設定を含めた構成をコンテナ単位で明確化して 理解・保守しやすくしました。さらに、 コンテナはOSカーネルをホストと共有するためVMより起動・再構築が高速であり、 Dockerfileの修正・作り直しが頻発するテスト工程でも効率を維持できると判断しました。 これらの理由から、Apache＋Tomcat8＋crontab（ログローテーション用） ＋Tomcat10.1＋crontab（ログローテーション用）をDocker Composeで構成し、 ローカル開発向けと結合テスト環境向けでComposeファイルを分離しました （Windows環境とLinux環境でvolume設定が異なるためです）。 Windows上の実行環境としてはRancher Desktopを採用しました。 Apache-2.0ライセンスで商用利用が可能であり、Docker Desktopの有償化方針を考慮した判断です。 あわせて、Rancher Desktop＋Docker Composeの構築手順をWiki化し、 メンバー全体へ共有しました。また引継ぎ資料として、 Dockerコンテナ構成フォルダの説明資料を作成し、引継ぎ対象者へ展開しました。 その結果、環境構築は**約15分〜25分程度で完了できる**ように なったというフィードバックを得ており、立ち上がり時間の短縮と開発効率向上に貢献しました。 ③（セキュリティ対策の再現性） レガシーシステムの運用保守リーダーとセキュリティリスクに関する打ち合わせを行い、 脆弱性がもたらす影響と可能性を説明した上で、 対応が必要であるという結論を得て合意形成しました。 その上で、私が中心となって具体的な対策方針を検討しました。 * **SMB1.0について** 現在使用している外部ライブラリJARがSMB1.0前提であったため、 代替として後継のjcifs-ng.jarを採用する方針としました。 互換性の観点で移行コストを最小限に抑えられると判断したためです。 SFTPも選択肢として検討しましたが、 ソース修正コストがjcifs-ng.jarより大きいため却下しました。 刷新プロジェクトにて実装・テストを実施し、問題なく対応を完了しました。 検証時にはWiresharkでパケットキャプチャを行い、 アプリ送受信時にSMB1が使用されずSMB2.0が使用されていることを確認し、 エビデンス資料を作成して関係者へ展開しクローズしました。 運用保守リーダーには方針と修正情報を展開し、事前調査・開発コスト削減にも貢献しました。 * **AJP通信について** 私が中心となり、Apache⇆Tomcat間通信をAJPからHTTPリバースプロキシへ変更し、 Tomcat側のAJP Connectorを無効化する方針を策定しました。 設定変更後にTomcatを再起動し、ss -lntpで8009ポートが待ち受けていないこと を確認しました。これによりAJPポート自体を無効化し、 Ghostcat系脆弱性の影響を構造的に排除し、構成のシンプル化と 保守性向上を実現しました。あわせて、さくらのクラウドの パケットフィルタ設定によりHTTPS（443）以外が許可されていないこと、 ホスト側FirewallでもpublicゾーンはHTTPS（443）のみ許可であることを確認し、 クラウド・ホスト・アプリの各層で攻撃面を恒久的に 排除できていることを確認しました。運用保守リーダーへ方針と修正情報を展開し、 事前調査・開発コスト削減にも貢献しました。 **成果として**、レガシーシステムに内在していた複数の重大セキュリティリスクを発見し、 技術的根拠に基づく説明で合意形成を主導し、実装・検証・ エビデンス作成まで一貫して対応しました。また、 再現性のある対策方針を整理して展開することで、 レガシー側の調査・修正コスト削減にも貢献しました。 ④（論理的思考力と実装の確実性：冪等性・追随性の担保） 本システムでは、スマホアプリ側・デスクトップアプリ側の両方に 同一構造のテーブルが存在しており、 両者とも主キーはrec_no（auto increment）ですが、 独立採番のためrec_noの整合は取れません。 アプリ側ではcmd=1のレコードを対象に同期し、ユーザー操作を起点に 「送受信ボタン押下→WebサーバへHTTPリクエスト →アプリDB（SQLiteファイル）添付→ApacheがTomcatへリバースプロキシ→Tomcat上 の連携プログラムが同期処理実行」という流れで処理されます。 解決のポイントは、①一意キーによる存在チェックによる冪等性担保、 ②内容変更を考慮した上書き更新による追随性担保の2点でした。 * 通信断による重複登録を防ぐため、UUIDを用いた一意キーで 存在チェックを行い、未存在ならINSERT、存在するならINSERTを スキップすることで、通信断・再送・重複INSERTを防止しました。 * さらに、通信断後にアプリ側で内容が変更されるケースに備え、 INSERTをスキップした場合でも内容差分チェックを行い、 差分があればデスクトップ側をアプリ側の最新内容で UPDATE（上書き）する仕組みを追加しました。 **成果として**、通信断が発生しても重複登録されない冪等性、 通信断後の変更にも追随できる追随性を実現し、 主キー整合が取れない制約下でもUUIDを軸に安全な同期を実現しました。 また、当該レアケースは設計書に明記し、 新規参画者が同様の課題で悩まないよう配慮しました。 ⑤（スマホアプリ開発基盤構築の再現性） 今回の開発対象はiOSアプリであり、実機配布・テスト・ 権限管理・履歴管理を総合的に考慮した結果、 App Store Connect＋Xcode＋TestFlightによる配布基盤を採用しました。 iOS実機への正式な配布・検証フローとしてはTestFlightが実質的に 唯一かつ公式の手段であり、Ad-hoc配布は端末取り込み手順や端末側制約の 面で事故リスクが高いため採用しませんでした。 配布基盤構築に必要な要素として、Apple ID（既存組織アカウント）、 証明書（Apple Distribution）、Bundle ID、Provisioning Profileを整理し、 XcodeのAutomatic Signingを基本方針とすることで、 メンバー間の設定差異や更新漏れを防止しました。 App Store Connect上でNew Appを作成しBundle IDを紐づけ、 Xcode側でAutomatic Signingを有効化して、 開発メンバーが同一設定でビルドできる状態を構築しました。 TestFlight基盤を整備し、開発メンバーは内部テスターとして登録し、 上位層・営業は外部漏洩禁止を前提にパブリックリンクで外部テスターとして配布しました （ビルドが増えて混乱しないよう、都度設定が必要な外部テスター運用としました）。 検証フローは「ビルド→TestFlightアップロード→実機インストール→フィードバック」 に統一し、手順をWiki化して公開しました。 **成果として**、開発中アプリをTestFlightで即時配布・ 更新可能な状態を実現し、メンバー間の環境差異を解消しました。 さらに実機ベースでUI/UXフィードバックを迅速に回せる体制を構築し、 「ビルド→配布→検証→改修」サイクルを効率的に回せる再現性の高い基盤を確立しました。 ⑥（性能改善の取り組み） 同期はユーザー操作を起点に、アプリの「送受信ボタン」押下→ アプリ側変更内容（新規・更新・削除）をデスクトップDBへ送信→ デスクトップDBデータをアプリが受信→同期完了、という流れで実行され、 iOSアプリ⇆デスクトップアプリ間の整合性が保たれます。 対象テーブルはマスタ系と予定実績系（日時カラム保持・同期期間指定可能）の2種類に分類され、 新規追加された30テーブルには両方が存在していました。 対応は、①悲観値を前提にした性能検証（最大データ量を想定、最大1億レコード規模も想定）、 ②ボトルネック特定（デスクトップDBからの取得処理が最大ボトルネックであると判断）、 を踏まえ、対策の主軸をインデックス設計に置きました。インデックス設計では、 既存PKインデックスが使える場合は流用し、 既存インデックスが利用可能な場合は新規作成を避け、 等価条件→範囲条件の順で複合インデックスを設計し、カーディナリティの高い列を優先しました。 さらに、同期処理はレコード順序に依存しない設計であり、 iOSアプリ側では参照時にORDER BYを明示していることから、 同期処理内ではORDER BYを使用しない方針とし、 ファイルソート発生を回避しました（影響箇所を洗い出し、 専用テスト項目を作成してデグレがないことを確認しました）。 検証は【修正前（インデックス未作成・ソース修正なし）】と 【修正後（インデックス作成・SQL/ソース最適化反映）】の2パターンで 同期時間を計測し改善率を算出しました。データ投入はSQL Anywhereのプロシージャで 大量データを投入し、1)大量INSERT→2)CREATE INDEX→3)統計情報更新の順で実施しました。 **成果として**、インデックス作成およびソース修正後、 同期処理時間を修正前の**約1/5に短縮**しました。 実行計画を確認し想定どおりのインデックスが使用されていることを確認し、 実行計画・計測結果をエビデンスとして取得・共有しました。 単なる体感ではなく、再現性のある性能改善としてプロジェクトに貢献しました。 --- ## なぜそのような工夫ができたのか／なぜ気づけたのか（案件①） 私は設計・仕様を確認する際に、 まず「将来コストが爆発する箇所（性能／運用／保守／セキュリティ）」を先に洗い出します。 次に、「最悪条件（最大データ量・障害時・人が入れ替わる状況）」でも破綻しないかを、 仮説と検証観点で点検します。最後に、対策を標準化（手順／Wiki／IaC）まで落とし込み、 属人化を排除することを重視しているため、他の人が見逃しやすい“詰まり”にも早期に気づけます。