スクラム開発で大切な成果・課題の捉え方
メダップでCTOをしている馬場です。
メダップの開発組織では、いわゆるスクラム開発の思想を取り入れており、チームで開発を進めていくことを前提としたプロダクト開発を行っています。
スクラム開発をより効果的に取り入れるために、成果を出すことや課題と向き合う事に対してチームで大切にしている考え方があるので、今回はそのチーム開発哲学をまとめました。
成果が出る仕組みに焦点をあてる
開発チームが出す成果は色々あると思いますが、基本的に誰か1人で成果を上げるという構図になることはないと考えています。
(※ 今回は説明を単純化するために、やや乱暴ではありますが、「成果」= 「機能リリース」として話を展開します)
例えば、ユーザーへのインパクトが大きな新規機能を目標としているリリース日よりも前倒しでリリースできたとすると、一見その開発を担ったエンジニアが上げた成果と思いがちです。
しかしながら、実際はその方が開発に集中できるよう別の障害や保守周りのチケットを拾ってくれた他のエンジニア、またそのUIを作り上げたデザイナーや要求整理・要件定義を行ったPdM, はたまたレビューに協力してくれたCSメンバー等々、多くのメンバーの間接的な協力があって、リリースにたどり着いています。(もちろん、実装を担当したエンジニアの頑張りがあってこそではあります)
こうした際にメダップの開発チームでは、リリースされた機能を実装したエンジニア(人)に焦点を当てる以上に、このプロセスの中で生じたコミュニケーションや連携プレーに焦点を当てることを意識しています。どういったコミュニケーションがあったからこそ、これほどのスピードで新規機能を出せたのか？どういった定義があったおかげでブレることなく機能開発ができたのか？... といった具合です。
こうした振り返りを行うことで、チームとしてのベストプラクティスや良い仕組みを増やしていき、人に依存することなく継続的に成果を出しやすい仕組みを構築できると考えています。
課題に対して客観的に考察する
課題に対しても成果と同様ではあるのですが、成果に比べて人間の傾向として？実践に取り組むことがやや難しいのかなと感じています。
例えば、誰か一人が直面している課題があったとして、(ここでは仮にPRをマージするまでのサイクルタイムが理想と大きく乖離しているとします)、その人の能力・課題だ！と決めつけることは決してしません。
PRをマージするまでのサイクルタイムが長いことを課題とするとおそらく以下のように要因を切り分けることができます。
- 要件定義が曖昧であるために開発にフォーカスできない
- 設計が曖昧であるために開発にフォーカスできない
- ハイコンテキストなコーディングルールが多く、キャッチアップが難しい
- 悩んだときに気軽に声をかけられるメンバーがいない/声をかけられる場がない
- .... etc
このように、チームとして解決しにける課題に細かい切り分け、それぞれに対してどういった施策を打っていこうか？とチームで決めていくことができます。
「なんだ、当たり前じゃないか」と思われるかもしれませんが、実際自分自身が持っているチケットにおいて、サイクルタイムが長いとなった場合に、多くの方は、自分の技術力を上げなくちゃ、、、と思ってしまうのではないでしょうか？
※ メダップの開発文化としては、こうした思考は原則NGです。あくまで客観的になぜその課題が生まれるのかを考えることを推奨しています。
少し抽象度をあげると、自分がアサインされたチケットで出た課題は、自分で解決しなくてはいけないと考えてしまうのではないかなと思います。
メダップの開発チームでは、チケットにアサインされていることは、そのチケットをクローズできるように自分が最も主体的に進めることであって、自分が解決することではありません。
繰り返しになりますが、文章として書くと当たり前のように思うかも知れませんが、こうしたチーム思考への切り替えは慣れていないと意外と難しいです。
まとめ
成果・課題それぞれに対してチーム思考でどう考えるか？についてまとめました。スクラム開発を行う上では非常に大切な考え方だと思っていて、なによりもいかにチームで成果を出すか・いかにチームで課題を解決するかを考え抜くことは、めちゃくちゃ楽しいです。
こうした開発の考え方に共感いただける方はぜひ一度カジュアル面談しましょうー！(Twitter DM はこちら)
(Meetyもはじめました！)
(良ければ、採用ページもご覧ください！)