はらだっちのブログ

プロ意識を持ち続ける。その一環として学んだことをこのブログで日々アウトプットしていきます!

2023/2/13(月) 日記

出来事 & 感想

スプリントレビュー向け準備

  • POが不在となるため、水曜日のスプリントレビューを急遽PO以外のチームメンバで対応することとなり分担の話し合い。
  • 気になったこととして、スプリントレビューの一つ一つのやり方(画像で見せますか or 動くものを見せますか)と言うことまでPOに確認しようとしてた。
  • それ自体は、POに許可を取る話ではなく、チームで考える話なのでは?スプリントレビューが上手くいくためにはこういうやり方が良いですよね?って話した方が良いのでは?と問題提起したがあまりうまく伝わらなかった。

雑談会

  • 自主的にスパイクをやるチームになるのは?と言う話から、「そもそもなぜ成長しようと思うのか」と言う話まで行きついた。
  • モチベーションを上げるにはどうしてる?と言う話も面白かった。
    • 自分は他の人の話を聞いて気づいたのは、そもそもモチベーションは上げる必要があるのか?と言う事。
    • 仕事は元々やりたくてやってる人は少ない。だからモチベーションを上げるのではなく下がらない方法を身に着ける方が良さそうかなって感じた。
      • 最近実践しているのは、公園や広場に行って無になること。QOLに気を付けること。
      • このことで日々の仕事のストレスは軽減されモチベが下がる原因を摘むことが出来ていると感じる。

自担当のプロダクト戦略を考える会

  • 何をすべきなのかの解像度を上げる現状把握的な会だった。
  • 色々感じたこと
    • 今までの検討の経緯をあんまり把握していないと、そこを把握することから始まってしまうな、と思った。
    • プロダクト群の横のつながりがやっぱり気になる。顧客課題からプロダクトを作るきっかけになるのは理解しているつもりだが、パッケージとしてみた場合に、やはり顧客の立場からするとカバー範囲は気になる。"プロダクトパッケージ"なのか"ソリューションパッケージ"なのかも今の所良く分からないなぁ。
    • なんかもっと具体機能を出しまくって、そこから抽象化するのが良さそう。今のままだと抽象的過ぎて話が出来ない気もしている。
    • Customer ExperienceとEmploee Experienceで提供するプロダクトを分けるのはどうなんだろう?
      • マイクロサービス的な考えだと分けても良さそうだけれど、それだとプロダクトの分割はもっと細かくした方が良さそう。
    • 抽象的なプロダクト名が議論を停滞させている気もする。例えば”問合せ管理システム"というと問合せ管理に特化したシステムと言うことですごく分かりやすい。それをあえてプロダクト名を命名する必要性が本当にあるのだろうか?特定業務管理システムとは異なるセールスポイントがあるからこそ、一つ上の抽象的な名前を付けて命名するではなかろうか。
    • 話し合いの時に出ていた、プロダクト間のつながりについてフォーカスするみたいな話は良さそう。「プロダクト間の機能のすき間が、技術力によって柔軟に埋められるパッケージなんですよ」って言うような建付けのプロダクト群だと顧客も飛びつきやすい気がする。
    • そうか、なんか課題にフォーカスしすぎなのかもしれないなぁ。元々システム導入を考える時に顧客は真の課題を分かっていないことが多いから、売る側はどんな課題のも対応できますよって言う構え方でいて欲しい、と言うのが感じていることなのかも。

      プルリクレビュー

  • 異なる属性のユーザが利用する画面のフォーム修正
    • 一方のユーザ画面には対応されていたが、他方のユーザ画面は対応が漏れていたことを確認。
    • このユーザ画面は一方はスクラッチ開発、他方はSaaSの画面機能を利用しており、主の業務担当者が異なっていたりする。このような状況が仕様の確認漏れを発生させる。
    • また、ユーザーストーリーでPBIを作成していないことも一つ原因だと考える。