飯野です。
業務フロー改善・効率化を担うプロダクトでスクラムマスター兼開発を担当しています。
とある日のプロダクトオーナー
季節は遡ること数ヶ月前、チームの飲み会でプロダクトオーナーがこう発言しました。
プロダクトオーナー「このチーム、気持ち悪いんだよね」
飯野 「・・・・ふぁ！！！？？」
「私たちのチーム、気持ち悪すぎ・・！？」
「気持ち悪い」チームとは
さて、「気持ち悪い」とは、一般的にどういう意味でしょうか。
気持ち悪い
読み方：きもちわるいきみがわるい。不快な。いやな。
あまり褒め言葉じゃなさそうですね。
加えて、プロダクトオーナーが気持ち悪がっているチーム、出来れば入りたくないですよね。
ちなみに、私が所属するチームは下記ブログを執筆したスガタニさんのチームです。
彼女も4月を迎え2年目になりました。
この記事を読む限り、そんなに劣悪な環境では無さそうなんですけどね・・
（何しろ私、この記事を読んで飛び跳ねて喜んでましたし・・）
本記事では、プロダクトオーナーに「気持ち悪い」と言われた理由を、私なりの解釈と共に、チームの取り組みや考え方と合わせて掘り下げていきます。
気持ち悪さを探そう
日々の行いに気持ち悪さが潜んでいるはずなので、チームの取り組みを振り返ってみましょう。
業務理解の徹底
私たちのチームは、プロダクト開発による業務フロー改善と効率化のミッションを担っています。
手を加える必要がある業務が発生した場合、必ず現場のヒアリングを行い、現状の確認と理想の状態についてチームの認識を合わせます。
上記ドキュメントでは5W1Hを使用して現状の把握を行っています。（上記は一部作業の抜粋で、全体としては相当ボリューミーなヒアリングになりました）
このヒアリングでは開発チーム全員が出席することで、現場の生の意見を直接聞く機会を作りました。
ヒアリングの結果、カスタマージャーニーマップの作成を行いました。
また、上記それぞれの作業を行ったあとは、必ず全員の「感想」を聞くようにしています。
結果をただ受け止めるだけでなく、自分がその時何を感じたのかを言語化してチームに共有してもらうためです。
現場の把握を徹底的に行ってから、実際に行う改善業務について話し合っていきます。
あくまでも現場目線に立ち、課題の本質を捉えるためです。
このように実データを可視化して、現状把握を行うことも大切ですね。
ドキュメント文化
え！？スクラム開発なのにドキュメントも書いているの？と思われがちな部分。
スクラムだからと言って、ドキュメントを残さないでいいはずがないのです。
私たちが開発しているプロダクトは、いわゆる基幹業務システムです。
弊社の業務を行う上で欠かせないプロダクトであるからこそ、いつ誰が抜けても引き継げる状態が好ましい。
上記業務理解の項目で上げたキャプチャでも分かるように、調査にしろ、設計にしろ、勉強会の資料にしろ、基本的に何でもドキュメントに残します。
ドキュメントに残すことによって人に伝えやすくなりますし、何より自分の考えを整理するのに役立ちます。
他チームの社員がドキュメントを読んで反応をくれることもありますし、会社の資産にもなっていると感じています。
毎日勉強会
エンジニアって日々の勉強欠かせないですよね？
でも、プライベートでの勉強時間の捻出って、人や環境によって疎らになってしまいがちです。
業務を行いながら勉強が出来る、そんな状態が理想ですね。
そこで、私たちのチームは毎日1時間、勉強会の時間を確保しています。
上記ドキュメントでは個人に特化した内容になっていますが、実際には以下のような取り組みをしていました。
- 各々が興味のある本を読む
- アジャイル、マネジメント関連
- アーキテクチャー
- テストコード
- Docker環境作ってみる
- CentOSバージョン上げてみる
- マークアップハンズオン、等々
本は個人の学習になることが多いですが、「やってみる」や「ハンズオン」はチーム全員で作業を行っていました。
また、スガタニさんの記事で紹介されていた「オブジェクト指向講義」と「アーキテクチャ講義」もこの勉強会の中で実施しています。
チームの中で誰かが知っていることなら、個人で学習を進めるよりもはるかに効率がいいですよね。
困っていることに対しチームの誰かが解決できるのなら、それは必ずチーム力の底上げに繋がります。
振り返りが大好き
私は振り返りが大好きです。
振り返りが好きで、スクラム開発をしていると言っても過言ではありません。（これは多分過言です）
私たちのチームではスプリントを閉じたあとに、毎週振り返りを行っています。
何故私が振り返りが好きなのかと言うと、スプリント内であったよかったことやメンバーへの感謝、うまくいった取り組みについてチームに展開し、共有し合う時間が単純に楽しいのです。
そのスプリント内で頑張ったことや進捗が出たもの、プロダクトオーナーが喜んだこと等、お互いを認め合って進めている実感が湧きます。
前回の振り返りで、チームとして試してみようと決めた取り組みがうまく回った時は特に、「振り返りをしていてよかったなあ〜」と感じます。
定期的な改善サイクルがあるとチームとしてまとまりやすく、より強固になれるチャンスが増えると思います。
スプリントレビューへの執念
振り返りが大好きな私ですが、スプリントレビューは毎回どきどきします。
何故なら、スプリントの出来を左右する成果発表ですから！
このスプリントで頑張ってきた集大成なので、せっかくならプロダクトオーナーに褒められたいですよね！
私たちのチームではスプリントレビュー前に必ず、開発チームでリハーサル（段取り確認と認識合わせ）を行っています。
多い時は2〜3時間かかることも、、
これはこれで改善項目ではありますが、これだけの準備をして挑むので、終わったときの達成感もひとしおです。
私が嬉しいのは、チームとしてスプリントレビューにかける意気込みが皆同じという点です。
これはチームが持っている成果発表への責任感こそと思っているので、とても誇りを持っています。
コミュニケーションの機会が多い
私たちのチームは、他チームと比べコミュニケーション量が多いチームであると自負しています。
下記は私が過去に執筆した記事です。
もちろん現在も継続中の取り組みです。
単純に、上記モブレビューと勉強会の時間を合算するだけでも、1日少なくとも2時間は顔を見合わせ時間を共有していることになりますね。
コミュニケーションは多ければ多いほど、チームとして情報の認識齟齬を減らすことができます。
認識のズレが少なければ、人はお互いの期待に合った結果を得やすくなります。
私たちのチームで言うと、「仕組みがコミュニケーション機会を生んで認識のズレを最小限に留めている」ということになりますね。
基本的に前向き
チーム自体に基本的にポジティブな雰囲気が流れていると私は思っています。
「ポジティブな人が多いチームはポジティブに引っ張られやすい」ととある書籍にも書いてありました。（当然逆も然り）
チーム全員がポジティブ100%である必要はありませんが、
チームとして会社貢献を目指していく以上、生じた課題に対して真摯に取り組む必要が必ずあります。
この課題解決において、「ポジティブなアプローチ」を行うことは非常に大切で、未来にどうなっていたいかをベースに改善を進めることが出来ると思っています。
現状の課題に捉われすぎず、理想とのギャップを埋めることに対して、チームがポジティブであることは効果が高いと言えるでしょう。
また、単純に「この人と居ると仕事がやりやすいな」「楽しいな」という感覚はポジティブな人がいると多く起きうるのではないかと思います。
結局「気持ち悪い」って何なんだ
ここまで記載して気が付きます。
ん？プロダクトとチームのためのことしかしてないじゃないか！！
何で気持ち悪いの！！
答え合わせ
プロダクトオーナー「再現性が無くて、気持ち悪いんだよね。何でうまくいってるの？」
飯野 「再・現・性！！」
人は自分が思っていること、考えていることと相反する事象が起きた場合に嫌悪や気味悪さを覚えるのではないでしょうか。
つまり、プロダクトオーナーの発言の真意は「チーム開発とは課題が多いもの」という前提がある中で、「スムーズに進んでいる状態」が「気持ち悪い」ということだったのでしょう。
まとめ
改めて振り返ってみると、私たちのチームは仕組みとマインドによって形成されている部分が多いことが分かります。
その結果が、プロダクトオーナーが感じる「気持ち悪さ」＝「結果が伴うチーム開発」の要因と言えるのはないでしょうか。（本人に確認はしていませんｗ）
もちろん私たちチームが初めからこういった状態であったわけではなく、
ルールと自由さが適度に共存している状態を作り、その流れを継続したままチームが成熟しつつあることが「スムーズな開発」の大きな要因だと思っています。
対峙している環境（プロダクト内容やメンバー等、違いは様々）によってベストプラクティスが異なるのはもちろんですし、
私たちのチームにはこのやり方が合っている、ということに尽きると思いますが、この記事で少しでもチーム開発において参考になる部分があれば嬉しいです。
ちなみに、「気持ち悪いんだよね」と発言したプロダクトオーナーはこの方です。（弊社Twitterより参照）
アドウェイズ の東京本社は壁が一面ホワイトボードになってるんですが、絵が上手い社員が業務上の注意事項をわかりやすく喚起してくれています。 pic.twitter.com/E6UhLLgcXe
— アドウェイズ (@Adways_JP) 2020年1月14日
・・はい！ドキュメントまとめてきます！！！
