小田上 圭吾

- 状況： - 1年近くを要する大規模なビジネスモデル変更プロジェクトの中心人物としてアサイン。ステークホルダーが多く、エンジニアへの差し込み業務による遅延リスクが高い状態でした。 - 行動・判断・成果： - 他部署からの依頼窓口を自分に一本化し、全社戦略と照らし合わせてタスクの優先順位を厳格に管理（プロジェクト後の対応に回すよう交渉等）しました。 また、エンジニアの知見を活かし、ビジネスサイドへ「なぜその機能が必要か/不要か」を情報の複雑性を調整しながら説明・教育しました。これにより、ビジネス側の理解度が深まり、手戻りがほぼ発生しませんでした。結果、全社の開発スピードを落とさずにプロジェクトを完遂させました。

- 状況： - 男女マッチングサービスにおいて、男性会員のアプローチ数を増やすために「魅力的な女性会員」をトップに表示させる必要がありました。しかし、少人数のチーム運営のため、人力で容姿を判断しラベリングすることはリソース的に不可能という課題がありました。 - 行動・判断・成果： - 「お気に入り獲得数」が容姿と強く相関するという仮説を立てました。ただし、単純な累計数では古参ユーザーばかりが表示され、新規ユーザーの機会損失や実態との乖離が生じると判断。「直近3ヶ月以内のお気に入り獲得数」に限定するロジックを策定し、エンジニアへ実装を依頼しました。 結果、トレンドを反映した魅力的な会員が自動的に上位表示される仕組みが完成。お気に入りのアクションを起こす男性ユーザーの人数が10％アップし、主にヘビーユーザーのお客様からトップページ改善に対する好評の声を直接いただくことができました。データに基づいた論理的な仕様策定で、工数をかけずに成果を出した事例です。

* **状況**： * 入社と同時にメインエンジニアが退職し、仕様がブラックボックス化。トップダウンで不透明な要件が降りてくるためバグが多発し、タスクの優先順位も整理されていない混乱状態にありました。 * **行動・判断・成果**： * まず現状を整理するため、ブラックボックス化していたロジックや運用ルールのヒアリングを行い、ドキュメントとして可視化しました。その上で、不確実性の高い開発に対応するため2週間単位のスプリント（アジャイル）を導入。PdM部門へ要件の意図や全社戦略を確認し、エンジニア側で実装の優先順位をコントロールする体制を構築しました。また、リリース・レビューのルールも整備。 結果、エンジニアチームが「言われたものを作る」状態から「適切な技術提案を行う」状態へとシフトし、手戻りの削減と安定したリリース運用を実現しました。

* **状況**： * ビジネスモデルを刷新する大規模プロジェクトにおいて、ビジネス側の要件が定まらず、チャットベースで情報が散乱。目的が曖昧なまま五月雨式に機能追加の要望が発生し、納期遅延のリスクが高まっていました。 * **行動・判断・成果**： * 散らばっていた要件とデザインを一元管理し、情報のハブとして機能しました。ビジネス目的が曖昧な点については、エンジニア視点でデータを収集・提示し「達成したい目的は何か」を具体的に引き出しながら仕様に落とし込みました。また、開発途中での要件追加に対しては、納期とのトレードオフを提示して不要な機能を削減するなど、徹底したスコープ管理を実施。 結果、当初の納期を遵守し、チームのリソースを守りながらプロジェクトを完遂させました。