レガシー業界・システムに奮闘！プロダクト改善事例LT【開発PM勉強会vol.9】
皆さんお待たせしました！3月に9回目の開発PM勉強会を開催しましたのでご報告です！
毎回、たくさんの方にご参加いただきありがとうございます。今回の勉強会はエンジニアの参加者が多く、テーマについて課題を持っている方々にご参加していただけました。
事前にいただいた質問では、「業界特有の商習慣が大変」、「技術的負債から開発がなかなか進まない」等の課題が多く寄せられていました。登壇者の方のお話しは、PMだけでなくエンジニア目線でも気になることばかりでしたので内容をシェアいたします！
開催概要
開催日時：2022年3月15日（火）19:00〜21:00
開催場所：Zoom
企画内容：レガシー業界・システムに奮闘！プロダクト改善事例LT
イベントページはこちら👇
https://peer-quest.connpass.com/event/239171/
プロダクト開発の裏側を激白！レガシー業界やシステムとの向き合い方とは？
今回は、5名の登壇者に各社の様子をお話ししていただきました。
レガシー業界の改善方法やレガシーシステムからの脱却についてTipsを共有していただいています！
| 時間 | タイトル | 発表者 |
|---|---|---|
| 18:50 | Zoomオープン | |
| 19:00 | オープニングトーク | 運営スタッフご挨拶・イベント案内 |
| 前半【レガシー業界の改善】 | ||
| 19:10 | 不動産業界が”重そう”と思われる理由 | 中村 優文 さん / 株式会社estie |
| 19:25 | 食品卸売業界向けSaaSで筋が良いと思ったけどうまくいかなかった施策の振り返り | 杉原 達也 さん / クロスマート株式会社 |
| 後半【レガシーシステムからの脱却】 | ||
| 19:40 | レガシーと戦う開発組織の作り方 | 金子 達哉 (catatsuy) さん / 株式会社PR TIMES |
| 19:55 | スクラム開発による10年モノのWebサービスの内製化 | 西島 寛さん / 朝日新聞社 |
| 20:10 | 膨大なイレギュラーを再構築するためにやったこと | 野崎 才門さん / 株式会社ネットプロテクションズ |
| 20:25 | 皆さんからの質問募集タイム | 当日質問フォームに送っていただきます |
| 20:30 | ぶっつけパネルディスカッション！ | まいどる / PeerQuest Inc. |
| 20:45 | みんなのまとめ・総評 | |
| 20:50 | 撤収！ |
不動産業界が”重そう”と思われる理由 / 中村 優文 さん
「不動産と聞いてどの様なイメージを持たれますか？」
参加者への質問から始められた、株式会社estieの中村優文さんからは、不動産業界が”重そう”と思われる理由についてお話をしていただきました。
「FAX」、「古臭そう」、「紙文化」、「アナログ」、レガシー産業を彷彿とさせるワードをイメージされる方が多いのではないか？とのこと。不動産業界が重そうと思われる理由は、完成されたビジネスモデルが既に存在するからだそうです。
レガシー産業は、言語化が容易ではない難易度の高い課題が多く存在し、難易度の高い課題に対しては、検証をどんどん回すことが重要とのこと。さらに、既存業務に寄り添いながら利用してもらえる機能を打ち出すことが有効な一手なのだそうです。
中村さんは、顧客の声を開発優先度に取り入れるため、ICE（顧客への影響度 × 課題の確度 ÷ 開発の難易度 = ICEスコア）スコアを採用し、顧客に寄り添いながら開発に向き合っているそうです。
レガシー産業に向き合うことは労力、時間がかかるかもしれません。ただし、市場規模が大きいので次の世代にも利用してもらえるサービス、プロダクトになる可能性がある！そう思うとレガシー産業は面白そうですね。
食品卸売業界向けSaaSで筋が良いと思ったけどうまくいかなかった施策の振り返り / 杉原 達也 さん
卸売業者の受注は、お店を閉めた後、人の手により夜深夜帯に行われるため、発注業務が非常にアナログで大変だそうです。
クロスマート株式会社の杉原達也さんからは、食品卸売業界向けSaaSで筋が良いと思ったけどうまくいかなかった施策の振り返りについてお話をしていただきました。
飲食店がLINEで発注し、卸売業者がデータで受注できるプロダクト施策開始も、飲食店側が行う「商品登録がめんどくさい」、卸売業者側の「商品のメンテナンスができない」等の理由により、施策をやめる意思決定をしソフトランディングに移行したそうです。そもそも、解像度が変われば、評価も変わる。検証しつつ前に進めることが重要だと感じたそうです。
失敗から学ぶことは貴重ですね。迅速な意思決定をし、次のフェーズに移行できることはすごいなと思いました。
レガシーと戦う開発組織の作り方 / 金子 達哉 (catatsuy) さん
精神論ではレガシーは倒せず、技術によってのみレガシーは倒せます。
株式会社PR TIMESの金子達哉 (catatsuy) さんからは、レガシーと戦う開発組織の作り方のお話をしていただきました。
レガシーがひどすぎて、何を聞いても「無理です」と言われる状態に陥っていたチームマインド。組織改革の手腕は、どれも参考になることばかりでした。
「〇〇だからできない」ではなく、「✗✗を遂行するために〇〇が必要だが、〇〇はどうすれば解決できるのか？」という発想を持つ組織にする。これまで諦めていた開発生産性の数値化・グラフ化。小さいプルリクエストをどんどんデプロイしていき、本番環境でも確認できるようにすることで開発生産性が向上する。など、改革案が的確かつ、実行プロセスが緻密に計算されていてすごいなと思いました。
さまざまな問題、課題を乗り越え、マインドを変えたことにより、1年もかからず開発組織が変化してきたそうです。
スクラム開発による10年モノのWebサービスの内製化 / 西島 寛さん
仕様はコードからわからない、必要なのはあるべき姿を思い描く想像力！
朝日新聞社の西島寛さんからは、スクラム開発による10年モノのWebサービス内製化のお話をしていただきました。
「仕様は実装から判り得ない」という学びから、開発メンバーだけで開発を進めない、チームやステークホルダーとのコミュニケーションを通してプロダクトの責任者が決めていくことが大切だとおっしゃっていたのが印象的でした。
歴史のあるシステムなので、内製化は大変！チームを巻き込みながら作っていくことが大切ですね！
膨大なイレギュラーを再構築するためにやったこと / 野崎 才門さん
ユースケースよりはじめよ。
株式会社ネットプロテクションズの野崎才門さんからは、膨大なイレギュラーを再構築するためにやったことについてお話をしていただきました。
ユースケースを分析・抽象化した結果、イレギュラーな要件を3つのユースケースで説明できるようになったそうです。3つのユースケースを知っていれば、何かやりたいことが生じたとしても「どのユースケースで取り扱うのか？」と議論になるそうです。
理解しやすい構造や、設計のために自分たちでロジックを考え直した結果、チーム全体が理解できている状態になったお話しは、とても参考になりました。
中でも「安易にイレギュラーにしない」ことは、PMに求められる重要な考え方だなと感じました。考えすぎると、あれもこれも入れてしまい、結局説明が難しいユースケースになってしまいますもんね。
ぶっつけパネルディスカッション
レガシーシステムを改善し、明るい未来を見るためには、どのようなプロジェクトマネジメントをすれば良いのでしょうか？実際のプロダクト改善例をいくつかご紹介いただきました！
「技術的負債を解消したいが事業案件でリソース不足。何から始めるべきか？」という質問がありました。
登壇者の方は、プルリクエストが大きすぎると改善が回らないので、小さくして改善を回していく。レビューのフローを整えたり、チームで見える化していくことが大切。など、みなさん工夫されている様子が見られました。
また、レガシープロジェクトにエンジニアを採用する際には、課題を伝えながらも面白さを伝えていくことを意識している。プロジェクトのイメージを理解できる内容で記載し、更にクライアントとの接し方や関係性まで伝えることも大切にしているようでした。
他にも、ビジネス側との調整を意識したり、チームを巻き込むことでレガシーシステムを良い方向に改善しているそうです。登壇者の方からの回答は、とても参考になるお話しばかりでした。
レガシーシステムとの向き合い方、今後の動き方
今回登壇していただいた方々のレガシー業界・システム、プロダクト改善事例にまつわるお話しは、これからの業務で参考になる事例ばかりで、有意義な勉強会になりました。
レガシー業界特有の重たそうと思われる課題に対して、優先度をつけて細かく改善していくことや、チームメンバー、ユーザーを含めた人とのコミュニケーションや巻き込む力、プロダクト改善後の明るい未来をイメージさせられる伝え方など、これらが回れば、重たい課題も改善していけそうですね！
登壇者の方々から共有していただいた事例は、どれも欠かせない内容で、日頃の業務でも意識し活用していきたいと思います。
今回の記事担当：なべ
※開発PMの採用や育成にお困りの方はdevPM運営チームにお気軽にご相談ください※
メール：contact@peer-quest.jp / DM：@devPM_io
