いくぜ、東北。いったよ、仙台。

こんにちは、カトです。弥生でQAエンジニアをしています。
5月26日に開催された、JaSST '23 Tohoku に現地仙台で参加しました。

仙台へは、東京駅から東北新幹線はやぶさに乗っていってきました。
東北新幹線はやぶさの停車駅は、東京 ⇒ 上野 ⇒ 大宮 ⇒ 仙台です。
ちなみに、弥生株式会社の本社は秋葉原にあります。東京駅でJR山手線に乗ると、東京 ⇒ 神田 ⇒ 秋葉原です。
秋葉原は（JR山手線で）東京から2駅。仙台は（東北新幹線で）東京から3駅。ほぼ一緒ですね。

JaSST '23 Tohoku

テーマはアジャイル

私は弥生で「スマート証憑管理」というサービスを担当しています。
サービスを開発するチームは、開発手法としてアジャイル開発を取り入れています。
ベータ版としてのサービス開始から1年ほどで、複数回リリースをしています。
スマート証憑管理リリースノート｜スマート証憑管理サポート情報

試行錯誤し、たくさんの改善ができているチームではありますが、まだ課題はたくさんあります。
部門間やサービス間での共有、プロダクトやプロジェクトの全体像の把握といった課題に「ユーザーストーリーマッピング」で改善していきたいと考えていた私は、オンサイトならではのワークショップがあるという情報を見つけ、JaSST '23 Tohokuに現地参加することにしました。

Vacation Photo

「もっと対話をしなければ」「チケットやドキュメントですべてがわかるように書かなければ」と思っていた私にとって、すごく印象的な共有知のお話しでした。

参画しているプロジェクトでは、「開発本部がマーケティング本部や顧客サービス本部に伝え漏れた」「要求をあげているのになかなか実現されない」ということが発生しています。
「レビューで指摘されなかったが、実際には誤っていた」「見てもらったはずなのに伝わっていなかった」ということが改善点としてあがることもあります。
私は開発本部に所属していて、開発のメンバーとはミーティングしやすい環境です。
一方で、マーケティング本部や顧客サービス本部のメンバーとは日常的に会話できていないと感じています。
会話の少なさが問題だと思っていました。
どうやって場や時間をつくるのがよいのかを考えていて、それぞれの業務があるから日常的に会話ができる状態にするのは難しいしどうやって改善するのがよいのだろう？と迷っていました。

「チケットで作業単位で区切ってタスクをこなしているけれど、このチケットが全体像のどのパーツなのかわからないことがある」という声を聞いたこともあります。

私たちチームは、共通の"Photo"を見ることができているのだろうか？"Photo"の背景の情報を語れるだろうか？

JaSST '23 Tohokuに参加してから、チームで要求や要件の全体像を把握すること、連携するシステムを含めた仕組みを伝え共有することを意識しています。

計画実行型、自己責任、自己組織化

基調講演中、「付箋をスタッフが順に配ります。」という場面がありました。
現地にいた私は「そうなんだ。待っている間、ツイートでもしようかな。」と思っていました。
「付箋をスタッフが順に配ります。」に対して「もっとはやく配り終える方法がないか？」という考えに至ることはありませんでした。
そのあと、「自分の分を自分で取りにきてください。」と言われ、「何かがおかしいぞ？」と思い始めました。

「配り方はどうしたらいいと思う？」と問われたら最適解を考えるかもしれません。しかし「配ります。」と言われたらそのまま受け取ってしまっていました。

「上司、リーダー、マネージャー、スクラムマスターが忙しそう。メンバーでできる仕事は、もっとメンバーに仕事をふっていいのに。」という意見を聞くこともあります。
それは一見、自発的な発言のようにも聞こえますが、誰かが計画して采配してくれるのを待っている状態ではないだろうか？と思い始めました。
「考える人」「作る人」と区切るのではなく、一緒に作業していくことが大事なのだということを感じました。
しかし、「アサインされるのを待つのではなく、仕事を取りにきてほしい。」と望んでも、チームがどこをめざしているのか、チームにどんな仕事があるのかわからなければ、取りにいくこともできないし、取りに行くタイミングも遅くなります。
情報を開示し共有すること、「自分がこのプロジェクトに参加することを選択している。そして、チームみんながそうであると信頼している。」と感じられるチームになること、これがスピードにつながっていくと信じて、一歩ずつ取り組んでいきます。

MVP

Most Valuable Playerではありません。Minimum Viable Productです。
現地では、付箋を使い、4人チームで2種類のワークショップを実施しました。

ワークでは、やることを洗い出したあとに、第一段階のリリース、第二段階のリリースと最小単位を考えていくことを体験しました。
私には、「機能が充実していないと売れない。」「あの機能も、この機能もほしい。」といろいろ詰め込んでしまって、開発やテストが大変になってしまった経験がありました。
「最低限必要な機能」をチームみんなで決めること、そして次の段階を見据えることで、今までの失敗を繰り返すことなく、MVPを意識したリリース計画ができそうです。

製品開発のプロジェクトは、私一人の意志だけで優先順位を決めることは難しかったので、勉強会もくテクのタスクを使って優先順位づけをしてみました。
開催回数を重ねるごとにタスクが増えてきて「やるべきことがたくさんある」状態でしたが、運営に関われる人数、運営対応できる工数を鑑みて、開催ごとにやるタスク・やらないタスクを選別できそうです。

最小単位は社内勉強会として開催、次に社外勉強会として最小限のやるべきことを追加、といった第一段階、第二段階に整理しました。
すべてのタスクが同列の優先度で一列に並んでいるように見えていたところから、だいぶすっきりしました。

今回は一人でタスクを整理しました。今後、チームで優先順位づけをすることで、目的の認識合わせ、作業優先度の確認、各タスクをやる理由も見えてきそうです。
別のプロジェクトでもユーザーストーリーマッピングを取り入れて、作業を整理していきます。

おまけ・仙台グルメ

JaSST '23 Tohoku へ出発前、5年前に開発者ブログへ投稿されていた記事を読みました。 tech-blog.yayoi-kk.co.jp 勉強会の現地参加は、地方グルメを満喫することもできます。
記事はしっかり読みました。紹介しているお店、1件も行けていませんが。

私が行ってきた、牛たんとずんだのお店を紹介します。