Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Courage to stop development

D61ecb299008e313b7a375e186a0d6ae?s=47 Koji Matsuura
February 19, 2021

Courage to stop development

Rakus Meetup 202102 Day2 で登壇した「開発を止めるという選択」のスライドです。

D61ecb299008e313b7a375e186a0d6ae?s=128

Koji Matsuura

February 19, 2021
Tweet

Transcript

  1. ©2021 RAKUS Co., Ltd. 開発を止めるという選択 ~かけだしPDMの失敗談~ 松浦 孝治

  2. #RAKUSMeetup 自己紹介 2 ・松浦 孝治 (まつうら こうじ) ・楽楽明細・製品開発リーダ(兼PDM見習い) ・2019年~ラクス入社。前職はメーカー系SIer。 ・とにかく楽しく仕事する。ケジメをつけて。

    ・今年の目標は10,000歩/日。 リモートワークでも体力維持!
  3. #RAKUSMeetup ・請求書、納品書、支払明細といった帳票発行業務を自動化させるクラウド型のシステムです。 ・領収書、検収書など、あらゆる帳票の発行が可能です。 ・帳票データを取り込むだけで、顧客に応じて「WEB」「メール添付」「郵送」「FAX」のいずれか の方法で、楽楽明細が自動で割り振り発行します。 楽楽明細とは 製品概要 3

  4. #RAKUSMeetup いきなり質問です。 4 「PDM」の役割といわれて、まず 最初に何を想像しますか? A.顧客に価値を届ける人 B.中長期的な製品のロードマップ(方針)を作る人 C.具体的な開発アイテムの優先順位を決める人

  5. #RAKUSMeetup ラクスの中でのPDMの役割 5 ・製品戦略、ロードマップ作成への協力 ・ビジネス、業務要求をシステム要件に正しく落とし込む ・開発スケジュールの管理 事業部が立案した製品戦略を元に、開発速度の向上 を図る。

  6. #RAKUSMeetup 顧客・市 場調査 ニーズ分 析 製品企画 要件定義 設計 実装 テスト

    リリース 効果測定 楽楽明細での役割分担(今日の話の登場人物) 6 事業部長 ぼく (PDM見習) CSリーダ 確認 確認 領域拡大中 領域 拡大中 開発メンバーメインの作業 PJM業務と兼務
  7. #RAKUSMeetup 今日の話 7 開発着手後、2週間で中止に なった話 ※機能開発で実際あったエピソードとなります。製品戦略を含む具 体的な内容は一部伏せさせて頂きます。

  8. #RAKUSMeetup 事件のダイジェスト ~事件の始まり~ 8 ある日、事業部長と会議で機能開発リストについての議論をします。 事業部長 楽楽明細の次期開発として〇〇機能の開発を検討をし てほしいです。昔からこの機能を欲しているお客様がいら っしゃって、営業時に失注するケースもあり、明確に販売 増が見込める機能なんですよ。

    うわー、めっちゃ大変そ う・・・。一定数要望もあ るし、やるしかないな・・。 承知しました。開発的に半年後までスケジュール空かないの で、次期開発アイテムとして予定しておきます! ぼく
  9. #RAKUSMeetup 事件のダイジェスト ~開発着手前の提案~ 9 ~それから3か月後~ 開発着手前に具体的に顧客に提案したいと言われます。 事業部長 例の〇〇機能ですが、現在提案中の会社が是非とも使 いたいという話を受けています。 現在想定している機能概要を伝えて、機能がある前提で

    提案しますね。 機能的には実現でき ないことはないので、 あとは納期の問題だ な。 現案件が終わり次第、優先度高くして対応という方針ですね。 かなり大きな工数になることが見込まれますが、総動員で頑 張ります。 ぼく
  10. #RAKUSMeetup 事件のダイジェスト ~そして開発へ~ 10 開発着手して、2週間。 周りから様々な悲鳴があがることになります。 開発チーム 詳細検討していったら、全機能の約8割くらいのSQLに手を入 れなきゃいけないです! 今後の開発でも〇〇機能があることで、既存機能への考慮

    が必要なので、将来的にも工数かかりますね・・・。 〇〇機能は、かなりリスクのある機能で、お客様の設定ミスで 意図せぬ動作をしたとしても、責任をとわれる可能性があり、 他の商材でも似たような機能開発はやらないこととしているよ。 開発部長 ぼく 想像以上・・・。
  11. #RAKUSMeetup 事件の発生経緯 ~開発中止へ~ 11 悲鳴から2日後 皆の意見を真摯に受け止め、総合的に判断して、中止が決定されました。 事業部長 商材の中長期視点を考えたら、開発すべきではないです ね。この開発案件は中止としましょう。 (現在の機能改修の量、今後の機能開発の影響、他商材の

    リスクを説明。)なので、開発としては中断することが望ましい と考えています。 ぼく 幸い、営業側の巧みなプレーで、失注とはなりませんでしたが、提 案中の顧客、事業部長を初めとした営業メンバーにかなりの迷惑 をかけました。
  12. #RAKUSMeetup 私の何が悪かったのか 12 受身の姿勢 お客様から言われたものは 絶対!が裏目に。開発を中 止するという選択肢が頭に なく、顧客が必要なんだから やることを前提に考えていた。 コスパ意識

    目先の利益ばかりに目が行 っていた。コスパとは、利益 からコストを引いたもの。 着手優先順位 今開発している機能開発との 優先順位づけ。もっと早く中止 していたら、関係者に迷惑を かけなかった。 中長期の視点 プロダクトはずっと続く。だから こそ、将来の開発に足かせに なる事項には慎重に。
  13. #RAKUSMeetup 教訓 13 ・顧客に導入する予定の機能は早く実現検討せよ! ・コスパの悪い機能は止めるという提案を持ち掛けよ! ・中長期な視点(将来まで抱える負債)も、考慮に入れよ! 開発を止めるという選択も、顧客の価値につながる。

  14. 14 I wish all listeners have a good product development!

    Thank You For Listening!