開発経験なしでプロダクトマネージャーになって、やった事②
投稿目的
これまでの経験を教訓として
アウトプットする目的で掲載しています。
拙い文章で恐縮ですが、
暖かい目で見守っていただけると幸いです。
今回は前回の続きでプロダクト責任者になった際に
やった事の続きとして記載しています。
前回の記事は下記になります。
実際にやったこと（続き）
システムのインフラ構成の確認
対象のプロダクトは主にAWS上で動作していたが
他にデータセンターにサーバがあるようなので調査。
データセンターのサーバーは
外部とのAPI連携やサブのサービス
みたいなものがあり
その用途で使われていた。
ただ、社内SEの方が一部対応はしているものの
必須だけど対応できていない
オペレーションがあるとのこと
（SSL証明書更新やログローテートなど）
これはまずいということで
Googleで検索しながら手順書を作成
実際にその手順で実施したのと
クロスチェックのため2人以上で
作業する事にするなど
マニュアルを整備する事を指示する。
社内SEの誰かがやめてもオペできるように。
マニュアル化は
社員の入社・退社した時の作業
アカウント作成・削除
事務手続き（契約関連）
システム調査・対応手順
保守運用作業
などを作成、サポートして
実際に書いた内容で作業できるか確認し、
情報足りなければ付け足していく
ことをしてブラッシュアップしていった。
プロダクトの詳細調査を実施
プロダクトのインフラ面が確認できたので
実際にサーバ単位でどのような構成で
動いているかを確認。
具体的には
書かれている言語は何か？
フレームワークに何が採用されているか？
ミドルウェア（DB、WEB）は？
各サーバのOSは？
利用されている言語などはツールを使って確認して
他に特筆する箇所はないか確認をした。
OS、ミドルウェアは
古いものが採用されているようで
ここは後にバージョンアップPJを立ち上げ、
時間をかけて対応した。
フレームワークに関しては
ベースとなるものはあるが
独自のものを利用していた。
外部の開発担当に入ってもらい
確認したが癖があり
根幹となる部分は難易度が高いので
開発標準化は後に回す事とした。
当面のインフラ目標は
セキュリティ観点、性能、耐障害性からも
古いOS、ミドルウェアのリプレイスとした。
ヒアリング結果を整理
ヒアリングしてプロダクトで
今後、対応していくものの優先順位を決める。
ヒアリングすると、今起きている不具合を
どうにかしたいというのが多く
個人的には
品質チェックテスト実施
不具合抽出
仕様のゆらぎ調整
プロダクトのあるべき姿整理
という品質面にリソースの大部分を
投入したかったが経営陣には
了承されなかった。
品質以外だと
営業中の顧客からの要望
これから営業するのに必要
既存顧客からの要望・不具合
競合にあって自社にはないもの
がある。
新規開発系と保守系案件に分けられそうだが
前述のインフラ案件や、法要件で対応が
必要なものが発覚したので
以下の3つに案件を分類。
対応するベンダー側のチームも分け
その中で優先順位を決めて
対応していくことになった。
案件の優先順位付け
案件を洗い出したところで
順番を決める作業を実施。
優先順位の付け方としては
期限が決まっているもの（EOSとか施行時期）
要望があがっている施設数
プロダクトの発展性があるものか
競合に負ける理由となりそうなもの
1に関しては期限が過ぎると
大きな問題になるもの。
2の要望は施設特有だったりで
共通機能化できなそうなものは
除外した上で対応することとした。
顧客がほしいものを作るのではなく
自分たちが作りたいものを作る
3に関しては
今のプロダクト領域が広がる可能性がありそうなもの
広げるのに必要になってくるもの
4は基本的なところは対応しているので
致命的なものはないが。。。
それでもコンペなどで
負けた際には理由を聞いて
本当かどうかはあるが
理由とされた部分は潰そうと対応した。
ただ、いざ進めると1、2の対応で
リソースはいっぱいになり
もう2チーム作るべきだったと反省。
今回の記事は以上です。
次は体制面やチームビルディング
の部分を記載したいと思います。