チームが担当する開発内容の設計がいろいろしくじって問題が起き続けた話

お疲れさまです!まっちゃんです!
前回の記事で取り組みに対してMVPキャンバスを書いてる話をしましたが、最近は少しずつビジネス領域の検証に対してMVPキャンバスを書き始めるようになりました。
仮説を立証するために「データ」ってすごく大事だなと最近痛感しています。

1年ぶりにしくじった話を書いていきたいと思います。
今回のしくじり話は「設計 x チーム」で書いていきます。

約1年前のしくじり記事

blog.engineer.adways.net

とりまく状況

チーム

前の記事にも書いているので割愛します。

blog.engineer.adways.net

サービス

チームが担当する開発案件はPdMやPOが作成したリリーストレインに則って開発しています。
チームの役割はプロダクトの新規開発や検証を行う事です。

メインの開発を行いつつ、小さな検証を並行して行っています。

f:id:AdwaysEngineerBlog:20200124162411j:plain 図:直近のリリーストレインのイメージ

開発

現在のチームの開発体制について

  • スクラム開発
    • ストーリー担当制
      • スプリントプランニング時に開発担当やレビュー担当を決める
      • スプリント内でストーリーを対応する

設計について

チームの状況も加味して、何を持って設計ストーリーが完了するのかを定義しています。

  • 何を作るのかが明確になっていること
  • 開発着手ができること

チームメンバーが開発に着手できるようにするために、調査内容や設計内容は細かく書いています。

問題

順調に設計や開発を続けていましたが、案件を進めていくと様々な問題が出てきました。
要件の考慮漏れ、実装の複雑化、リリースした成果物が障害に繋がったなどです。
自分が設計したもの、レビューしたもの関係無く、案件の規模関係無しに発生しました。

ふりかえり

各スプリントで出てきた内容です。
橙色は私ですが、毎回のスプリントでやっちまった感が出ています。
また、スプリントが進むにつれてメンバーからも「さすがに問題だよね」という声も上がっています。

f:id:AdwaysEngineerBlog:20200124162756j:plain 図:スプリントふりかえりで上がった設計に対する問題点

解決に向けて

このままではチーム的にも問題があると判断し、改善策を考えることにしました。
またマネージャーとの面談もあったのでその場でも相談を行いました。

マネージャーに相談

相談する前に自分自身で考え、それを元にマネージャーと相談します。

考えた内容

  • 問題点
    • 設計が落とし込めておらず、何かしらで問題が発生している
      • 開発時に連続で起きている
      • 問題が起きていること = タスクとして落とし込みができていない
    • 直近の案件での問題
      • 検証案件A
        • ○○機能の考慮漏れ
      • 開発案件B
        • □□の考慮漏れ
      • 分析F
        • 実装の複雑化
  • 対応案
    • タスクレベルでどこまでやるのかを明記して開発に着手する
    • (検証案件、案件)ビジネス側との認識合わせを実施

深堀り

なぜできていないのか 5whys で一緒に深堀りを行いました。

  • 問題: 設計が落とし込めておらず、何かしらで問題が発生している
    • why1:なぜ、設計が落とし込めていないか?
      • 調査が足りていないから
    • why2:なぜ、調査が足りていないか?
      • 影響範囲ではないと思ったから、調査しなかった
    • why3:なぜ、影響範囲ではないと思ったのか?
      • 実現できる流れまで見えたので、影響範囲ではないと思った
    • why4:なぜ、実現できる流れまで見えたのか?
      • 1パターンの処理の流れが考慮できていたから
      • ただ、他のパターンは考慮できていなかった

深堀りを行った結果「設計においてリスクの洗い出しができていない」という結論になりました。

過去設計の練習問題でも上記のような問題があったから実案件を通してリカバリしていこう。という話をマネージャーとしました。
確かにここは個人の課題でも上がっていたなと思い出しました。

当時の記事

blog.engineer.adways.net

1回目のふりかえりで書いてますね。
実案件で設計は多くこなしていたものの、当時の課題に対してアクションが行えなかったと反省しました。
またチームにも影響を受けるんだなと再認識しました。

再設計で気をつける

マネージャーにも相談して、チームには「リスクの洗い出し」を含めた再設計を行いたいとお願いをし、スプリントに入れました。
今まで設計で考慮ができていなかった箇所でもあり、メンバーが参考にできるような成果物を目指したいので自分が担当しました。
(ちょうど年末年始を挟んだスプリントだったので、実家でリモートワークしてじっくり考え落とし込みました)

再設計ではパターンを洗い出し、システム観点や業務フロー観点からメリット・デメリットをまとめて最適であるものを選択しました。
POにも共有し、合意も得ることができました。

まとめと今後

再設計後のMVP開発分を昨日リリースを行いました。
(問題も無さそうなのでホッとしてます)

シニア課題では個人の課題でしたが、テックリードとして携わった時にその課題がチームや案件全体に影響を及ぼし、開発が円滑に進まなくなる点は非常に課題だと思いました。
改めて気をつけて取り組みつつも、この設計の知識をチームに還元していきたいと思います。
(今モブプロ等で行っているのでチーム全体に知見などの共有ができると思っています)