TECHLEAD& PM

PROBLEM

変換対象は自社で制御できない他社サイトのHTMLです。元サイト側の構造変更で要素抽出が失敗すると表示崩れが起きます。例外を伴わないため気づきにくく、検知経路はクライアントまたはエンドユーザーからの指摘のみでした。発覚まで数日を要していました。

発生頻度は1案件あたり月1〜2回でした。月額課金制で契約案件数が増加傾向にあり、案件数に比例して緊急対応の総量が増え続ける構造にありました。

APPROACH

リードエンジニアとして裁量を得たことを機に、まず個人でSeleniumによる自動検知を実装しました。動作するものを用意した上で社内提案し、承認を経て自社サービスのオプションとして提供を開始しました。数十ページ規模のサイトでは数百件のテストケースを用意し、日次で実行する体制としました。あわせてクライアントおよび元サイト運営側とリリーススケジュールを共有する連携体制を築きました。

OUTCOME

発覚までの時間は数日から最大24時間へ短縮しました。発生自体の抑止は連携体制の側で対応し、技術による早期検知と体制による事前予防の二層構成としました。数十名規模のメンバーへ導入手順とテストケース作成方法を伝授し、自動検知は累計100件以上のプロジェクトに採用されました。導入を希望した案件へ有償で提供し（現在は終了）、品質保証の手法として定着しました。その後の運用は後任へ引き継いでいます。

PROBLEM

棚割りシステムのフロントエンド開発を4名体制でリードしました。自社のウクライナ現地法人のメンバー2名と、日本在住の外国籍メンバー1名を含む体制です。開発は1ヶ月ごとに実装する機能を定義して進めるアジャイル型で、仕様の受け渡しは最初の一度ではなく毎月発生します。拠点の間には時差があり、言語も異なります。仕様の認識のずれは店舗スタッフが毎日使う画面の品質にそのまま跳ね返ります。

APPROACH

日本の夕方とウクライナの朝が重なる時間帯に日次ミーティングを置き、時差のある体制での同期点を確保しました。伝達手段は内容の重要度で使い分けました。

OUTCOME

期間中に現地メンバーが拠点移動のため3ヶ月間離脱しました。日本側メンバーへの応援要請で体制を組み直し、1ヶ月ごとの開発サイクルを維持したまま全20画面を予定どおりリリースしました。言葉の壁をその都度しのぐのではなく、起きた問題を手がかりに伝達手段を内容ごとに決めて仕組みにする。この設計で国をまたぐ体制を2年4ヶ月にわたって回しました。

PROBLEM

取引仲介システムの開発にフェーズ1の途中から参画し、技術責任者の役割を引き継ぎました。エンジニアは3名のプロジェクトリーダーの下に分かれ、ラインごとに実装を進める体制です。共通化の考え方はあったものの、技術責任者が不在だった期間に各ラインの実装はばらつき始めていました。このままでは同じ役割の部品がラインごとに作られ、管理が二重三重になります。書き方や仕様の解釈もラインごとに分かれ、150画面の業務システムではそのずれがそのまま保守の負担になります。

APPROACH

要件定義の画面仕様と機能仕様をもとに、共通化するものと各ラインに任せるものの境界を定めました。共通化の対象は共通部品・ディレクトリ構成・コーディング規約・設計ドキュメントです。権限による表示と操作の制御、操作ログと監査ログの出力も共通の仕組みにしました。ここがラインごとにずれると情報漏洩や規制上の問題に直結するためです。参画時点ですでにラインごとに作られていた重複部品は、残せば負債になると判断しました。進捗が予定より先行していた期間を使って共通化しました。

APIは証券会社側の基盤がSOAPで提供しており、このアプリケーション向けの定義も日々追加されます。そこでWSDLから型を自動生成する方式にしました。追加のたびに手作業で実装する人的コストを避け、ラインごとの解釈のずれも防ぐためです。認証情報の付与・タイムアウト・エラーの変換を含む呼び出し処理も共通化しています。

方針はプロジェクトリーダー3名との週次の定例で進捗や課題とあわせて共有し、合議で決めています。技術面は私の判断を軸にしつつ、エンジニアやプロジェクトリーダーからの良い提案は取り入れて方針を更新してきました。

OUTCOME

参画直後にはラインごとのばらつきを直す作業がありました。共通化の後はその作業がなくなり、その分の工数が減っています。コーディング規約をそろえたことで、レビューで書き方の違いを指摘することも減りました。途中から引き継いだ開発でも仕様から共通化の境界を引き直し、その上で部品と書き方を統一する。この順序で3ラインの実装を一つの設計にそろえました。