デザイナーだけど、認定スクラムマスター取得して良かったなぁ。
エンジニア組織内でデザインするのが大好きですので、スクラム開発を見たり聞いたり、開発内スクラムイベントの場にいる事はよくありました。しかし、スクラムへの理解があった訳ではないのでいつもチンプンカンプン。
先達であるエイマエダカツタロウさんから具体的にオススメの研修を教えてもらったので自腹で参加しました！
「スクラムマスター」という名前がカッコ良かったし、スクラムを知っておく事はムダにはならんやろ。という気楽さです。
この記事は赤ちゃんスクラムマスターである私がスクラム研修や認定を受けてか良かったな〜という点を挙げたものです。
デザイナーなのにスクラム勉強して意味あんの
現在の体制や役割について理解が深まって良かったよ
チームとして望ましい動きってのが少し見えたかな
要約すると上記のような主旨です。主に感想記事ですのでここから下は興味があれば読んでやってください。
またスクラムガチ勢の皆様におかれましては認識の誤りや補足なんかをしていただけると私が幸せになります🙇
「認定スクラムマスター」って百戦錬磨なんやろうなぁ… ← 違いました！
スクラムマスターとは役割であってスクラムでの実践経験値とイコールではありません。
実はCSMというのは「スクラムの基礎が分かった駆け出しスクラムマスター」くらいの意味でした。CSMには現場経験に基いた上位資格が複数ありまして、ガチ勢の皆さまはここら辺も取得しておられます。
デザイナーとして、どうスクラム開発に貢献していくか
スクラムでは職能によって分けることはしません。スクラム入門(PDF)を読むと、デザイナーへの言及がない。いや、プログラマ、エンジニアという言葉もなかったような…？
スクラムという軽量なフレームワークを遵守する場合は、デザイナーもエンジニアもメンバーとして一つのチームに所属することになります。その場合、デザイナーはどのように貢献すれば良いのでしょうか…？
赤ちゃんスクラムマスターである私が浮かぶのは今のところ下記の3つです。
1. デザイン視点で課題に向き合う
これは一番イメージしやすい、シンプルな貢献方法であると思います。エンジニアたちと共にありながら違う視点を持っているのはチームに多様性をもたらします。
2. ディスカバリーフェーズを区切ってデザイン思考活用
私の受けたスクラムマスター研修は講師さんがPOに向けたディスカバリー特化の研修もあるそうです。スクラムを改変 or 踏襲した上でディスカバリーフェーズがあるとすれば「探索や発見」においてはデザイナーという職能も一家言あるものです。ここで貢献するのも良さそう。
3. スクラムマスターとして活躍する
デザイナーとしてではなくスクラムマスターとして貢献することに振り切っても良いかもしれません。デザインプロセス導入など、昨今のデザイン実践家たちの潮流はチームプレイに差しかかっています。デザインプレイングで得たスキルを活用してプロジェクトを健全に漸進させるスクラムマスターはもしかしたら貴重かも…？ (やったことない)
スクラムの理解を深められて良かったこと
自分をスクラム文脈で評価できるようになった
スクラムにおいてデザイナーという職種がどう振る舞うことを期待されているのかが分からず、ずっと自分を評価が出来ていませんでした。
スクラムを完全に理解した(※)ことで、スクラム文脈ではどう動けば良いのかが分かりスッキリしたのが一番嬉しいことです。
完全に理解した
インターネットミームでは、文章とまったく逆の意味
スクラムを理解したことで各イベントを主体的に活用できた
Daily Scrum, Stands up, Sprint Planning, Review,などなど…。それぞれのイベントがどういう主旨のものかすべてを把握はしきれていません。
研修で扱われたイベントへの理解はできましたが、そこにないイベントも組織ごとにあったりします。そして外部からしれっと参加しているメンバーへは主旨も説明されていなかったり…。
ですので、スクラムとは何故存在するのか、どういう原理なのかを知れたことでそういった知らないイベントでもアウトカムを考えることができるようになりました。
個人技になりがちなデザインプロセスの民主化に役立つ予感
私が行ってきたグラフィックデザインやUIデザインは、ともすれば個人技で完結してしまいます。しかし、最近はそれを民主化していく動きがあります。モブデザインですとか、ワークショップなどを行うことで、職能限らず対話を進め「問」から「解」までを当事者たちで決めていく動きです。
これもスクラムの思想を活用できそうです。
皆で取り組むIssueに対して、私はどういう視点で物事を考え解決策を提供するか。他のメンバーはどうしているのかを共有したりはもちろん、解決策を用意するだけが貢献ではありません。対話を活性化させたり、視覚化したりすることも重宝されます。
「適切な問いを作る」もそうです。デザインでも重要視されている大切なことですよね。
ファシリテーション時の指標が決めやすくなった
スクラムに限らず、「私たちは何が明らかで、そうでないものは何か」をチームで知っておくことはとても大切です。
なので、メンバーでの様々な問いに対して「これに対する答え、または判断基準を我々は手にしているか」を問いかけるようになりました。
私のせっかちな性格では、自分で問うて自分で答えてしまいがちです。直したい…。
対話の場で、この問いを投げるように工夫することで、少しずつ「私の疑問」と「チームの疑問」を分けられてきており、分からないことへの不安耐性もついてきたように思います。
開発進捗などをファシってる時、自分が知らないことがあるというのが恐怖でしたのでコレも嬉しい収穫。
スクラムチームの役割
スクラム開発では、プロダクトオーナー、スクラムマスター、そしてメンバー(3〜7人以下)がいます。
メンバーは、全員でひとつのキーボードを使い開発を進めたりと一緒に作る・ひとつのissueに注力するを重要視しているようで、その点にも感銘を受けました。
エンジニアを7人ほど集めて、個々をコードを生産させず対話を求めるのは、かなり高級品なフレームワークである印象を受けましたが、それほどまでにチームを意識するからこそ、ラグビー由来の名前がついているのだなと。
個々に生産して良いのであればそれはラグビーではなくリレーや水泳などの個人技ですもんね。
「自分が強くなればいい」でもない
一人のデザイナーとしてプレイングしか見えていなかった自分は、何かにつけて「自分がスーパーデザイナーだったら全部解決したんだろうな」と技術の未熟さに嘆いていたのですが、視野が狭すぎましたね。
自分で解決しているだけのコトってけっきょくそれほど大きな事ではないんだなと今になって思います。なればこそ、数人で動く、チームで強くなることが大切でして。
チームで強くなるというのは、それぞれの視点や特性を活かして一人や二人で出す以上の力を発輝することなんだなと。
今の私がはたしてそれが出来ているのかは謎ですが、そういった融けあうチームになれること、それを前提とした対話や相互理解というのをしていきたいし、普通に行えるチームになっていきたいなと思いました。
スクラムの3つの柱
スクラムは「透明性」「変化」「適応」の柱のもとチームで学習したことを前提として開発をしていきます。
デザイン思考ともリンクしている
スクラムではアイデア思考と同様にプロトタイプを作り、それをテストする、価値を伝えるための成果物を主眼におく考えがあります。これはデザイン思考ともリンクしています。
いや、そのためのチームやコミュニケーションのフレームワークとしてスクラムが存在している事を考えるとデザイナーのプロセスよりもデザイン思考を活用しているかもしれません。
個人ではなくチームが主眼なのがいい!
再三書きましたが、これは個人での話ではなくチームになっているのがやはりいいですよね。
わたしはチームスポーツまったくやってこなかったので、「やっておいたら良かったかな…？」なんて思ったりしています。個人技は「全部自分」って感じが最高に楽しいので今でも好きです。でも、そろそろチームワークに向き合ってみたい。
「分からない」「失敗」が怠慢じゃないのがいい!
顧客との開発進捗会議では、知らない事が怠慢であるようなプレッシャーを感じてました。しかし、ソフトウェア開発を顧客と行うのであれば、我々は「チーム」です。
私たちチームが知っていること、そうでない事と考えるとプレッシャーではなく「なぜ明かにすべきなのか、明かにしたことによるアウトカムは何か」という問いにかえられるのがいいですよね。
おしまい
少なくとも私にとってはスクラムを理解することは、外部からパートナーとして開発に参加する身であったとしても、エンジニアではなくデザイナーとしても有用なものでした。
デザイナーとして新たなキャリアやスキルを探索しているアナタの助けになれば幸いです。
いいなと思ったら応援しよう！
