初心者がスクラムチームに入った体験談

はじめてのスクラムチーム

 スクラム導入に関して、セミナーであったり、ブログ記事や書籍等では、導入しようとするための手法やいかにメンバーに浸透させるかといった側から描かれているものがほとんどです。

 今回、曖昧なスクラム開発の知識しか持っていない状態でスクラムチームに入ることになりました。この章ではそんな初心者がすでに動いているチームに途中参加した体験談と、チームに参加してどう変化があったのかを中心に紹介します。

スクラムチームに参加する前

プロジェクトメンバーとして

 受託案件が多かったため、基本的には取引先から降りてくる仕様通りに開発し納品する、という流れのプロジェクトがほとんどでした。また、開発に携わったことのない取引先から降りてくる仕様は曖昧な部分、欠けている部分が多く、プロジェクトマネージャーが取引先と話し合い、仕様を決定する形になります。

 取引先 > プロジェクトマネージャー > エンジニア

 また、プロジェクトマネージャーも開発技術に関して詳しいわけではないため、あらゆる点で衝突が起こりやすい状態です。

 一番ストレスに感じていた部分については、良くないと感じる仕様について、プロジェクトマネージャーに意見を上げるものの、取引先がこれでいいと言っているので…と、納得できないままに実装することです。

「これは良くないと思うが、それでいいと言うのであれば、もうそれで実装するけども…」

 仕様のまわりでプロジェクトマネージャーと衝突することが多いため、常にイライラしている状態が続くか、言っても仕方がないし…と、諦めの状態になることがほとんどになります。

自身と開発スタイルについて

 社内・プロジェクト内での自身の動き方として、人と話すことを苦手としています。ミーティングは基本的に参加したくない、参加をしたとしても特に意見は言いたくない、コードに集中しているタイミングで話しかけられればあからさまに態度が悪くなってしまうことすらあります。これは指摘されることに対して過度に否定感を感じ、落ちこんでしまう性格が原因です。そのような結果になるのであれば意見は言いたくないと思っています。

 常にプロジェクトの進め方・会社のあり方について不満を持っているものの、どこに所属したとしても同じ結果になるであろうという諦めの状態に近いといえます。

 また、抽象的な状態のものを完全に具体的なものに落とし込むことが苦手で、社内での目標設定などは、なかなか目標を記載することができません。

スクラムチームに対しての印象

 社内にはスクラムで開発をしている、と名言しているチームが既に複数存在していました。そのうちの1つのチームに参加することになるのですが、参加前のスクラム開発に対する印象はあまり良くありませんでした。

 ・毎週長々とミーティングが行われ、実装の時間が取られている

 ・壁にタスクの付箋を貼るチーム

 ・不満が聞こえてくることが多く、いい開発状態には見えない

 勉強会等で上手くいっているチームの事例も聞いたりしていたため、スクラムに対しての嫌悪感はないものの、社内でプロジェクトマネージャーがスクラムと言い出すことに対しては嫌悪感を感じていました。

なぜそう感じていたのか?

 チームに入っている友人から聞こえてきたスクラムは、間違っている部分が多くあったためだと思います。チームメンバーであった友人から聞いたことや、チーム外から見たことをまとめてみます。

・長々としたミーティング

  プロジェクトが大きく、メンバーは30人程度。毎週スクラムイベントと称して会議室に全員が集まり、進捗を報告する会が開かれていました。基本的に時間は6時間を超え、イベントに参加している友人は自身の報告をするだけで他のメンバーの報告はほぼ聞いていない状態で、携帯を触っている状態だったようです。

・壁にタスクの付箋

  プロジェクト開始後、壁にずらっとタスクが貼られて行くのはよく目撃していました。しかし、数週間もすれば付箋たちは管理されなくなり、ハラハラと床に落ちて放置されているのをよく見ました。また、そのチーム参加している友人の話では付箋を管理するだけのメンバーというのが存在しているとのことでした。

・聞こえてくる不満

  結局のところ、プロジェクトマネージャー・プランナーが全仕様とタスクを決め、エンジニアの意見は通らないことが多く「それでいいならそれで実装するけども…」という不満を抱えたメンバーが多くいる状態で、特にスクラムだからいって良くなる部分があるとは感じませんでした。

そんな印象を持ちつつの今回のチームへの参加ですが、参加したチームと社内で実践されていたチームとに大きな違いがありました。

チームをきちんと育成・指導をしてくれるメンバーとして、アジャイルコーチが参加してくれていました。

チームに参加してみて

 メンバー構成としては、弊社エンジニア社員数名、プロダクトオーナーとして取引先、デザイナーとして別の会社、ここにアジャイルコーチが1スプリント(2週間)で1〜2回参加してくれます。複数の企業で構成されたチームのため、スプリントイベントは同じ場所で行い、その他はSlackで随時やり取りを行います。

入った直後の衝突と変化

 開発文化が違うチームに入るため入ってすぐは納得が出来ない部分や衝突が多くありました。特に今まではほとんどの時間が開発・実装の時間だったものが、スクラムイベントの時間に費やされる点です。同じ場所で作業するための移動時間、1つのタスクに関しての作業内容や大きさの共有など、これまで一人で判断していた部分がチーム全体で共有していくことになります。自分自身がこれまでと同様のスタイルでいたため、イベントに参加することが辛く感じた部分であり、納得行かない点もこれまで通りに反論はせずに最低限の会話で済ませるため、チームと自身の気持ちとで大きなズレが発生しました。また、元々自身の作業に集中したタイプであったため、都度発生する雑談などがとにかく苦痛でした。

 チームへは徐々に馴染んでいきましたが、チームの方針、特に前任者から引き継いだ内容について、大きく衝突するタイミングがありました。これまでであれば、納得がいかなくても進めなければならないので不満を持ちながらそのまま突き進むことばかりでしたが、きちんと話し合いの場を作ることが出来ました。どのように進めて行きたいのか、どの部分が納得行っていないのか、代替案はないのか、などを話し合いました。これは既にチームがある程度出来てきているタイミングで入ったことと、この衝突した問題が重要であると感じたコーチが、話し合いについて時間を取る必要があることの説明と、話し合いのススメ方についてのアドバイスをしてくれたのが大きく影響していると思います。

 この出来事はこれまでイライラであったり不満として抱えていた部分を、チームで共有し解決する方法を模索するという形を提示してくれました。また、チームメンバーだけでの話し合いではなく、コーチが進言してくれたのも大きかったと思います。

スクラムで解決された不満点

 チームに参加して見えてきた、以前の開発での不満やイラつきの原因として見えてきた部分と、解決されたものがあります。

・工数と実作業との差

 実際に作業に費やす工数と要求される工数とに差があり、交渉の余地がないままとにかく提示された作業を提示された工数内で進める必要が出てくる場合が多々ありました。この部分が、プランニング時にタスクの大きさを共有し、プロダクトオーナーの望む締め切りに合わせて優先度を調整する機会が与えられるので、大変さは変わらないものの心の中に抱えていた大きな不満が発生しにくくなりました。

・共有されていない仕様

 開発メンバーと取引先との距離が遠く、間にプロジェクトマネージャーが挟まることで仕様にかんする伝言ゲームが発生します。開発メンバーには個別に相談し、個別に回答をすることが多いため、把握しないままに入っていた仕様や、入っていると思いこんでいたものの入っていなかった仕様が存在することがあります。こういった共有漏れの発生頻度がぐっと下がりました。

・通らない意見

 仕様に関して疑問に感じる点や不安となる要素があった場合に、取引先に説明するまでにプロジェクトマネージャーを挟むため、時間がかかってしまうことと、上手く伝わらないことがあります。取引先も理解しきれず、現状の仕様で押し切ってしまう、ということも多々発生します。最終的に先方が良いと判断したので…と納得できないままに、実装されることがあり、フラストレーションが溜まっていました。これに関して、毎スプリントでの振り返りや取引先と直接話し合う機会が持てる点において、自身で説明し、交渉することができるようになりました。

  

大きな不満が解決されることで、気持ちに余裕が出来、開発メンバー以外に実装に関することをわかりやすく説明する工夫をしてみる、求めているものを理解しようとするなどの精神的な余裕が出てくるようになりました。

全てが順調ではない

 現在もこのチームに所属している状態ですが、常に順調な状態にはありません。上手く進んでいる、と感じるスプリントもありますが、基本的には何かしら問題点を抱えています。ただ、重要だと感じるのは、この何かしら問題点を欠けている状態が健全であるということです。メンバーや環境、体調やその日の気分によって、チームの状況は刻一刻と変化します。スクラムで重要な部分は、その状況が共有されることと、これで全てが上手く進んでいると過信しないことであると思います。もちろん上手く行っていると感じることは大事です。しかし、これが全てを上手く運んでくれると感じた瞬間に、改善を考えずにその方法を続けようとしがちです。この点は十分に注意し、常にさらに良くする方法を考えていくのが大事です。




振り返りで学んだこと

 レトロスペクティブに関しては多くの記事や書籍がある通り、アジャイルにおいて大変重要な作業です。その中で学んだ最も重要であることは、振り返りは決して反省会ではなく、チームをより良くするための振り返りを行う、ということです。スプリントを振り返る時、問題点を抱えている場合は当然解決する必要があります。しかし、その問題点に注目しすぎると、どう解決するかに注力しがちになります。振り返りでは、チームをより良くするための振り返りを実施することが重要です。

> スクラムマスターは、このミーティングがポジティブで生産的になるようにする。 ※スクラムガイド

 振り返りでは上手く行かなかった部分や、良くなかった部分など、ネガティブな要素をあげ、それを解決する方法を考えがちになるので、問題解決のみに注力せずにこれがあればさらに上手く進んだ、これをすればさらに良くなる、といったことを考えるよう心がけるのが大切です。

チームに入って良かったこと

 今回入ったチームではスクラムという手法が使われていますが、大きく学んだこととしては「問題を抱えた時の解決方法へのアプローチ手法が存在している」ことに気づけたことです。もちろんネットや書籍などで沢山の情報を得ることができるので様々なアプローチがあることは頭では理解していました。しかし、これを実際に行動にするにあたっては、いくつかの障害があったり、手探り状態で進めて上手く行かなかったり、そもそもそのアプローチ自体が上手く進められているのか良くない方向に行っているのかさえ判断できなかったりなどが発生しがちです。解決されるにしろされないにしろ、それ自体の結果がわからない状態のアプローチは存在していないも同然です。この点において、一人だけで判断せず、素早く実行に移し、結果を振り返って改善する、という形は、解決へのアプローチをきちんと模索できている状況であり、自身の成長につながると実感できました。

 また、個々の行動に対して、ゴールを意識するようになりました。スクラムガイドではゴールの達成について記載されている点が多くありますが、そもそもそのタスクに対してのゴールは何なのか?を意識することで、これまで無駄に感じていた部分に改善をもたらしました。特に、ミーティングでの話し合いにおいて、脱線したり、意見を押し通そうとしたり、意見を強く否定したりという形が多かった話し合いが、きちんとゴールを設定することで、健康的な話し合いができるようになったと感じています。これは、今までもゴールは設定されていたものの、長々と延長したり、脱線したりしがちだったものが、きちんとファシリテートしてくれるメンバーがいることで、ミーティングの一人ひとりの役割と進め方を学んだ形になると感じています。

 

3つの役割+αを振り返る

開発チームの一人から見た、現チームの構成でいい部分・悪い部分を振り返り確認してみます。自身のチームやこれからのスクラムチームづくりの参考になると幸いです。

プロダクトオーナー

 取引先の1人が担当しています。形は受託になり、プロダクトの価値・重要性・機能に関して都度整理し共有してくれます。完全に取引先としてではなく、開発チームの意見を聞く機会を与えてくれること、きちんと汲み取ってくれること、さらに外部や上から降りてくる、仕様・要望との調整役をしてくれています。板挟みの状態になりがちですが、基本的に開発チームのために動こうとしてくれている分、開発チームもこのプロダクトオーナーのために動くという形が出来ており、チームとしてはいい状態にあると思います。いわゆる味方であると感じることができる状態なのはとても重要だと思います。

スクラムマスター

 現状弊社のプロジェクトマネージャーがスクラムマスターという立ち位置になります。元々は別のメンバーが担当していたのですが、弊社のメンバー変更があり、スクラム初心者の立場でスクラムマスターをすることになりました。また、弊社の方針でプロジェクトマネージャーはいくつかのプロジェクトを兼任しています。そのため、他の文化の違うプロジェクト、プロジェクトマネージャーが取引先と開発チームの調整役を全て行うプロジェクトチームと兼任することになり、自走を目指して動くこのプロジェクトに対して、あまり多く関われない現状があります。完全に自走するチームであればSMはいなくても問題ないかもしれませんが、まだ未熟な部分があるチームのため、不満であるとか距離を感じてしまう点が多くあります。この部分についてはまだまだ改善の余地があると考えつつ、より自走できるチームを目指して動くことでまかなっていければと考えています。

開発チーム

 複数の会社メンバーで構成されていることもあり、それぞれの会社の文化が存在します。しかし、現状は意見を出しやすい雰囲気づくりが上手くできていると感じるため、社内での方針の共有や、新しいツールの導入と検証など、上手くチャレンジと振り返りが出来ていると感じています。まだまだ、話し合いの時々でこの場合はどうするのがベストなのか…と悩む場面は多くあるので、より良いプロダクトとチームづくりを目指して、考えていきたいと思っています。

アジャイルコーチ

 現チームでのスクラムマスターは、前任者を引き継いで、経験のないメンバーがスクラムマスターの役割をすることになってしまったので、アジャイルコーチの役割はとても大きいものになっています。スクラムマスターの育成とチーム全体の育成を担ってくれています。チームによりますが、コーチとして入ったメンバーと、スクラムチームとの間に、信頼関係であるとか考え方が違った場合の解決方法であるとかが上手く合わないと、コーチが入ったチームでも上手くいかないことがでてくると思います。その点で、現在のチームでは適宜アドバイスをくれること、チームが受け入れられるアドバイスの量と内容が、チームととても合っていて、開発チームとしては成長を感じることができる状態にあります。弊社の他のスクラムチームとの大きな違いであると感じています。

プロダクトのレビュアー

 取引先の関係するメンバーとして、レビュー会に参加してくれる方々がいます。サービスの関係者がほとんどですが、毎スプリントのレビューメンバーや人数は完全に固定されていません。そのため、レビュー会では前回の続きでという前提ではなく、毎回、今スプリントの新たな成果物として切り分けて発表をしています。レビュー会はこのチームにとてもいい作用をしており、毎回厳しい意見や良いと感じる点を指摘してくれます。チーム内で当然のように進めていたものに対して、なぜそうなったのか?を指摘し、考え直す機会を与えてくれています。また、新しく待ち望んだ機能の追加では一緒に喜んでくれ、大きなUI改善時には様々な意見が出てくるため、きちんとユーザーレビューを行い、アンケート結果を元に決定する、という形が出来ています。そのため、さらに良いレビュー会にするように、チームメンバーはわかりやすく伝える努力をし、毎回レビュー会に対しての改善も考えています。これはとてもいい状態であると感じます。時間を割いて参加し、意見を出してくれるレビュアーには感謝しています。

まとめ

 初心者が既にあるスクラムチームに参加してみて、考え方が変わった点が多くありました。現時点でも自身の開発スタイルや考え方に変わりはなく、話し合いや意見を出すことが苦手ではありますが、きちんとゴールを設定した話し合いや、現状の共有をすることで、自分自身の心理的な部分においてメリットと感じられるようになった点が、とても大きく、自分自身の行動に変化をもたらしました。これは、弊社の他のチームに参加していたら得られなかったであろう部分で、きちんとファシリテートしてくれるコーチがいたからこそだと思います。チームごとに当然やり方は異なる、異なって当然であると思いますが、基本部分をコーチングしてくれるメンバーはとても重要であると感じます。知識のみで押し通すと間違った方向になりがちです。

 自分自身の考え方を変えてみることも重要です。考え方が変わるにはそれなりの理由や納得が必要なので、その部分について話し合えるチームは成長していくと思います。1つの問題を解決すれば、また新しい別の問題が出てきますが、それらに対して1つ1つ貪欲に改善していきたいと感じられるようになりました。

 また、スクラムチームとしての一番のいい部分は、サイクルが早いことにあると思います。とてもいいチームの状態がずっと続くことはなかなかありません。しかし、サイクルが早く、都度振り返りと改善を考えることで、とても悪い状態がずっと続くということもありません。悪い状態がずっと続いているとしたら、何かしらチームづくりとしての原因がないか考えてみてはいかがでしょうか?

 
 

Outline/Structure of the Talk

//TODO: あじぇんだみたいなやつまとめる

Learning Outcome

初心者がスクラムチームに入るにあたっての心構え

Target Audience

曖昧なスクラム開発の知識しか持っていない状態でスクラムチームに入ることになる人

Prerequisites for Attendees

スクラムの用語をわかっている人

schedule Submitted 1 year ago

  • kyon _mm
    keyboard_arrow_down

    kyon _mm - チームの再定義 -進化論とアジャイル-

    kyon _mm
    kyon _mm
    Test Architect
    オンザロード
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    チームの再定義 -フラクタルスプリントとフラクタルチーム-

    1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?

    私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。

    異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。

    そしてこれらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。なぜ人間はチームをつくるのか。

  • Takuo Doi
    keyboard_arrow_down

    Takuo Doi - モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education

    Takuo Doi
    Takuo Doi
    CTO
    Lifematics Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    現在,大学でプログラミング言語の授業を持っています.

    その授業では,文法としてのプログラミングだけでなく,プログラミングの面白さを知ってもらえるもらえるように,モブプログラミングを導入して授業を行なっています.

    ところが,企業でのモブプログラミングの導入とはまた違った課題がありました.そして,その解決策として,行動分析学を元にして,試行錯誤をしています.

    本セッションでは,その試行錯誤の課程を共有したいと思っています.

    ----

    I have a C programing course at university.

    I introduced Mob Programing technique to my class so that my student learn not only the grammar of the programing language but also the fun of programing.

    I have an experience to introduce Mob Programing to the work in our company. However I faced different problems. And Now I am trying to solve the problem using Behavior Analysis.

    I will share this experiences in my session.

  • 船戸 康弘
    keyboard_arrow_down

    船戸 康弘 / Kenta Sasa - 良いアプリを作る為にスクラムを初めたら、巨大な組織(自動車会社)の風土が変わってきた話

    45 Mins
    Talk
    Beginner

    日本の典型的な製造業で、スクラムで社内向けアプリ開発を始めて約1年。
    ソフトウェア開発をしたことのない部門が、失敗を繰り返しながら動くをソフトを作り、ユーザーに価値を提供出来るようになってきました。

    スクラムによって生まれたのは品質の高いアプリだけではありません。セクショナリズムが強い大企業の中で、部門を越えた関係者が一つのチームとして動くことによって仲間が増え、コラボレーションが生まれ、想定していなかった所でも新たな価値が生まれつつあります。

    組織風土の変化の話に加えて、開発チームの具体的改善事例やインフラ構築の取り組み、メトリクスの推移なども共有します。

    参考に7月にDASAで発表した際の資料をシェアします:

    https://speakerdeck.com/yasuhiro_funato/minnagashou-huo-wode-rareru-aziyairukai-fa

  • Yusuke Shiokawa
    keyboard_arrow_down

    Yusuke Shiokawa - 我々のゴールは何ですか? ~様々なステークホルダーとどのように共通ゴールを設定するか~

    20 Mins
    Talk
    Beginner

    AgileやScrumを問わず、組織やチームで仕事を進めていく上ためにはゴールの共通認識は重要な要素となります。
    一方で、ビジネスの現場では企画部門や開発部門、営業部門、品質管理部門など様々な立場の人が関わるため共通のゴールを設定することは容易ではありません。
    その結果、Scrumチームが目標を見失ってしまい、本来集中するべき価値に集中できていない場面を見かけることがあります。

    このセッションでは立場の異なるステークホルダーが多数存在するプロジェクトにおいて、共通のゴールを合意するためのSuccessFactorsワークショップをご紹介します。

    さらに、このワークショップの価値を最大限に高めるためのポイントを事例を交えてお伝えします。

  • Yoshihiro Yunomae
    keyboard_arrow_down

    Yoshihiro Yunomae / Ken Takayanagi - 良いチーム構成のための図解思考法お試しワークショップ

    100 Mins
    Workshop
    Intermediate
    良いプロダクトを作るためには、良いチームが必要です。
    良いチームになるためには、組織として適切なチームをデザインできていることがポイントです。
    これは、スクラムをやるためにスクラムチームを作るのではなく、今所属しているメンバーを見て、最良のプロダクトを届けるためのチームをデザインするということです。
    このためには、プロダクトの性質、メンバーのスキル、デプロイ頻度、開発拠点、文化など、様々な観点を考慮しなければいけません。
     
    しかし、これら観点が全てベストな状態であるチームを構成出来ることはまれで、ほとんどの場合、何かしらのトレードオフを受け入れながら構成していかなければなりません。
    例えば開発拠点が2つにまたがっているとき、拠点ごとにチームを作るのは良くあるやり方ですが、機能を実装するのに1つの拠点では完結しない場合はこのやり方がベストとは限りません。例えば、拠点をまたいでチームを作る、という方法もあります。しかし、この場合はコミュニケーションコストが上がるのでそれを下げるような制度や設備があるかどうかを考慮する必要があります。
     
    今回のワークショップでは、実際にこのトレードオフの関係にある項目を洗い出しながら、現在のチーム構成がどうなっているかを可視化していきます。
    さらに、より良いチーム構成の形を検討し、その構成のために今何が足りていないのか、どうすれば実現出来るかを考えていただきます。
  • Takahiro Kaihara
    keyboard_arrow_down

    Takahiro Kaihara / Ken Takayanagi - わかりあえないことから ~「あいつら」とどう向き合うのか ~

    20 Mins
    Talk
    Beginner

    目を閉じて思い浮かべてみてください。

    あなたには、「意見が合わない」「考え方が理解できない」「思い出すだけで腹が立つ!」「できることなら話したくない!」

    そんな「あいつ」はいませんか?

    プライベートであれば、その「あいつ」から、そっと離れればよいですが、取引先の担当や上司、隣の席の人がそうだったりすると簡単に離れる訳にはいかないでしょう。

    そんな時、わたしたちは毎日、息苦しい思いをして仕事を続けないといけないのでしょうか。

    居心地の悪いこの場所を離れる決意をし、転職したほうが良いのでしょうか。


    「あいつ」はいつか、考え方を変えてくれるのでしょうか?



    わたしたちが大事にしているスクラムやアジャイルの「価値観」は、世の中的にはまだ当たり前の「価値観」ではありません。
    (みなさんはそれをもうすでに知っているか経験をしていると思います)

    RSGTはとても居心地のいい場所です。でも一歩、RSGTから離れたらどうでしょうか。
    越境しようとする境界にいる人ほど「価値観」との衝突は避けることができないのではないでしょうか。

    このプロポーザルでは、そんな時に私たちはどういう選択肢があるのかを皆さんとともに考えてみたいと思います。
    (RSGTにとっても皆さんにとっても有意義な時間となるよう努めます)

    発表は、いつもつらい感じの発表をしている開原さんと、そんな人を支援するダイアログファシリテーターの高柳さんでお届けします。

    ■発表の流れ

    1.「社内のあいつら」開原ライトニングトーク(5 min)

    「ルール1:クソ野郎には近づくな」

    昔読んだ、エンジニア向けの本の「ルール1」にはそう書かれていました。
    私は教えを守りクソ野郎とはなるべく距離をとって生きてきたつもりでした。
    そのおかげか、たくさんの良い出会いがあり、人にも恵まれてきたと思います。
    それでも自分にとってしんどい出会いはあります。

    「あいつら」です。

    わたしが「あいつら」とは少し考え方が違うということは、「あいつら」は知っています。
    そして私も、「あいつら」のことを少し知っています。

    できることなら、同じ目標に向かって活動したい。
    でも、私は「あいつら」とわかりえることができるのでしょうか。
    「あいつら」が「わたしたち」にすることができるのでしょうか。

    「クソ野郎に近づくな」は正しいことだったのでしょうか。

    この数年間、考えてきたことをお話ししたいと思います。


    2.「社外のあいつら」高柳ライトニングトーク(5 min)

     企業内の研修依頼の多くは、何かしらのスキルが不足していて、もしくは課題になっていて、それを補う、解決するための研修になります。その場合の受講者は「自分にそれがないから受けてこいということか?」とか「今までのやり方は間違っているから、新しいやり方に変えろということか?」という自身を否定されたような状態で参加しているので、研修を「学びの場」として受け取るのではなく「研修内容を批判する場」として挑んで…というか、お手並み拝見とばかりにわかり合おうとしない状況が発生します。

    そんな分かり合えないことから始まる研修で、私がどのような向き合い方、選択をしてきたかをお話させてもらいます。


    3.「あいつらとの選択肢」について対話 By 高柳のファシリテート(10min)

    ホワイトボードではなく、iPadを使ってリアルタイムに書き取り、それをプロジェクターに投影しながら、2人の対話を、つなげたり、解いたり、遠ざかったりしながらお互いのライトニングトークから得た情報・状況で語り合います。

  • Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Toshihiro Ichitani / Tomoyasu Ishii - 経営者に聞く!-アジャイルと経営ー開発の現場は変わりつつある。事業サイド、経営陣はどうか?

    45 Mins
    Panel
    Beginner

    そもそもの思い

    RSGTの参加者が年々増えていることからわかるように、この間、スクラムに舵を切る開発現場が急増しています。

    波に乗って私も、スクラム的プロダクト開発手法を学ぼうと、2019年3月に、認定プロダクトマネージャー研修を受講しましたが、POの役割が広すぎて、定義していないのと同じだと感じました。また、プロダクトオーナー向けのドキュメントが具体的ではなく、事業サイドの方が、赤いピルを飲むために、手がかりがほとんどないように感じました。

    このギャップの前に、経営者はどんな手をとっているのか?というのが、このセッションを考えるきっかけでした。

    日本の経営方針は「ヒト」「モノ」「カネ」、アジャイルは「文化」が第1義。

    ナイスな開発チーム、プロダクトオーナーが自然と出てくる会社の文化をどう作っていったら良いのか、スクラムチームやアジャイル開発チームを抱える会社の経営方針は、どうきめるのかなど、本や研修には出てこない話を、デベロッパーから経営者になった方々に、この場でお話しいただき、彼らがヒリヒリした日常から何を気づき判断していったのか、お話を引き出せたらと思ってます。

    45分1本勝負。ぜひ、チャンスをいただけるとうれしいです。

    また、この場で聴いてみたいことなどあれば、コメントいただけるとうれしいです!

    登壇者

    市谷 聡啓

    ギルドワークス株式会社 代表取締役/株式会社エナジャイル 代表取締役/DevLOVEコミュニティ ファウンダー

    サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、ギルドワークスを立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。訳書に『リーン開発の現場』(共訳、オーム社)、著書に「カイゼン・ジャーニー」「正しいものを正しくつくる」がある。

    石井 智康

    石井食品株式会社 代表取締役社長執行役員

    ソフトウェアエンジニアとして、コンサルティング会社にて大企業の基幹システムの構築やデジタルマーケティング支援に従事。2014 年よりフリーランスとして、アジャイル型受託開発を実践し、ベンチャー企業を中心に新規事業のソフトウェア開発及びチームづくりを行う。2017 年から祖父の創立した石井食品株式会社に参画。地域と旬をテーマに農家と連携した食品づくりを進めている。現在のライフスタイルに合った「豊かな食」のあり方を模索中。認定スクラムプロフェッショナル。アジャイルひよこクラブ幹事。

    もう1名調整中

    進行役:岩切 晃子

    株式会社翔泳社取締役 / コンピュータ出版販売研究機構会長

  • Jean-Baptiste Vasseur
    keyboard_arrow_down

    Jean-Baptiste Vasseur / Hiroki Arai / KazuhideInano / Kenta Sasa - 「叱ってほしい!」・もし相手のスタンスが読めるならワークショップ

    100 Mins
    Workshop
    Beginner

    チームメンバー同士の会話や1to1でのコミュニケーションをより有効的でより安全にしたい方大集合!

    スタンスカードを使ってロールプレイをしながらコミュニケーションについて考えよう!

  • showwin
    keyboard_arrow_down

    showwin - ホラクラシーとスクラムは共存できるのか

    showwin
    showwin
    CTO
    LAPRAS株式会社
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    LAPRAS株式会社では全社的にHolacracy(ホラクラシー)というティール組織の1つである組織体系を導入しています。一方でホラクラシー導入前から開発チームではスクラムで開発を進めており、ホラクラシー導入の2018年4月から2つのフレームワークの共存にチャレンジしてきました。

    ホラクラシーの思想は個々人が役割(ロール)を持って責任範囲を明確にし、各人が自身で優先順位を決めて主体的に動いていくものである一方、スクラムは属人化を排除してだれでもどの役割を担えるようになる状態を理想としており、開発の優先順位決定もプロダクトオーナーが役割を持っています。根本的に異なる思想を持っているように見える2つのフレームワークが同居できるのか、実際に運用してみてわかったことをお伝えします。

  • Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi - スクラムマスターがファシリテーションを意識した時に受けるワークショップ

    100 Mins
    Workshop
    Intermediate

    スクラムでプロジェクトを進めて行く時に「ファシリテーション」という言葉は割と普通に出てくると思います。そしてスクラムで実際に「ファシリテーションをする」時になると、スクラムマスターとして見ている視点とファシリテーターとして見ている視点は少し違うのかもしれないと思うことがあります。ファシリテーターとしての役割と、スクラムマスターの役割と「帽子を被り直す」という感じで使い分けるということを考えていらっしゃる方もいると思います。

    今回のワークショップでは、スクラムイベントでのファシリテーションというポイントもありますが、その前にそもそもファシリテーションがスクラムの文脈では何をすることなのか、ファシリテーターとしての視点、捉え方が何を指すのか、改めて自分自身の引き出しに「ファシリテーション」のラベルのついた棚を明示的に増やしてみませんか?

  • Kentaro Masuda
    keyboard_arrow_down

    Kentaro Masuda - 新規事業プロダクトオーナーの現場!〜そのソフトウェアはリリースできますか?〜

    Kentaro Masuda
    Kentaro Masuda
    Software Engineer
    Freelance
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    みなさんは、新規事業に取り組んだ際、プロダクトに価値があることを感じつつも、そもそもリリースできなかったことはありませんか?

    私は、過去いくつかの新規事業に取り組んできました。無事にリリースできたプロダクトもあれば、世に出ることなくお蔵入りしたプロダクトもあります。
    また、関わった立場は、開発者、スクラムマスター、テクニカルサポートなど様々です。

    新規事業は、プロダクトオーナーが、仮説検証をおこない、価値がありそうなことを感じたとしても、世の中にリリースすることすら難しい場合があると、今までの経験から感じています。

    プロダクトオーナーが考えるべきことは、スクラムガイドに記載されているような「プロダクトがユーザーに価値があること」以外にも数多くあります。
    プロダクトを会社からリリースするには、営業、サポート、製造、出荷、総務など、様々な部門との連携が必要です。
    ユーザーがプロダクトを購入するには、営業部門がプロダクトの価値を理解し、販売網を作り上げる必要があります。また、プロダクト購入時の利用規約は法務部門が内容を精査する必要があります。
    ユーザーがプロダクトを利用する際に困った場合、QA対応ができるサポートセンターを構築する必要があります。
    ユーザーが利用するプロダクトが、ソフトウェアを通して販売される場合(ECサイトなど)は、プロダクトの製造や出荷が必要で、ソフトウェアを提供するより長いリードタイムや事前準備が必要です。

    加えて、製造、販売ルートによっては、社外との関係性も非常に重要です。
    製造が社外の工場の場合、アジリティを高めるために小ロット生産をしたいですが、万単位のロット数を最低発注する必要があったりします。
    既存の販売網を代理店を通して活用する場合は、代理店の営業部門にプロダクトの価値を理解してもらう時間が必要ですし、仕切りといった価格調整が利益を残すために大事な要素になります。

    上記はあくまで例ですが、プロダクトをリリースするためには、ソフトウェアを作り上げる以外にもやるべきことが数多くあります。


    本セッションでは、様々な立場で、様々なプロダクトオーナーのもと新規事業に関わったエンジニアとして、私の過去の成功事例、失敗事例を踏まえながら、新規事業においてプロダクトオーナーが考える必要があることを紹介します。

  • Kanako Muroyama
    keyboard_arrow_down

    Kanako Muroyama - トラブルだらけの現場から 仕事が「楽しい」現場に変わった、6か月間の話のその後

    20 Mins
    Talk
    Advanced

    2019年4月にDevLove関西で発表した「トラブルだらけの現場から 仕事が「楽しい」現場に変わった、6か月間の話」(https://www.slideshare.net/cowappa/ss-141300729)のその後の話です。

    業務改革を行ったチームがその後どうなったのか報告します!

  • Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi / Manabu Shibahashi / Mori Yuya / Yumiko Yoshida - スクラムのためのチームビルド:対話型組織診断ワークショップ

    100 Mins
    Workshop
    Beginner
    Bernard DUPONTBernard DUPONT https://www.flickr.com/photos/berniedup/32052417864/in/photostream/

    「チームのメンバーでケンカできてますか?」

    ・自分が言いたいことが相手の意見と対立しそうで、伝えなかった…。
    ・言ってもわかってもらえないと思ったので言わなかった…。
    ・このチームでは余計なことをすると指摘されそうで面倒臭いのでやらなかった…。

    そんな体験はないでしょうか?

    自分の考えをきちんと伝える。相手の主張としっかり向き合う。チーム内での会話の仕方は、チームの空気感や会社の文化に影響されます。

    「ケンカできる」とは、いがみあった対立ではなく、「互いに遠慮せずに主張し合える健全なコミュニケーション」の状態です。このワークでは、参加していただいたみなさんに組織や文化の理論をご紹介しながら、学びと体験をお届けします。対話で組織を観ることで、組織の風土が変わっていく、その第一歩を踏み出しましょう。


    【ワークショップ概要】

    『ケンカできるチームをつくるワークショップ』は一人一人は能力があるのにチームの結束がいまいちで悩んでいるリーダーに向けた実体験型ワークショップです。チームが結束する対話を実体験します。この実体験ではリーダーシップ理論やチームビルディング理論だけを学ぶ座学とは異なり、チーム内の対話の仕方を体験します。この体験によって鏡を見るように自分達の現状が分かります。前提として、チームで参加ください。

  • Yuichiro Yamamoto
    keyboard_arrow_down

    Yuichiro Yamamoto - プロダクトバックログのシステム要件

    20 Mins
    Talk
    Beginner

    プロダクトバックログを維持するのに、いい感じに使えるツールがない。

    自社事業のIT部でプロダクトオーナーを担いながらプロダクトバックログをいじり倒してます。いまのところ良いツールが見つからず、スプレッドシートで残念な感じの手動組み合わせでやりくりしてます。

    課題管理システムやタスク管理システムは馴染みませんでした。カードに書いたりタスクボードの左端に並べて飾ったりしてますが、もう少し高度な「仕組み」が欲しいと願ってます。

    そんな私なりの「あったらいいな」を、私の組織におけるプロダクトバックログのライフサイクルや、内外の共有の方法、さらにはプロダクトマネジメントを装う方法など交えながら、整理してみたいと思います。

    誰か作ってください。

  • Hiroki Hachisuka
    keyboard_arrow_down

    Hiroki Hachisuka - 話題の「価値観ババ抜き」をやってみよう!

    100 Mins
    Workshop
    Beginner

    近年、類似品が出回るほど、話題となっている「価値観ババ抜き」。

    チームにおいてのチームビルディングの観点で多くの方法がとられていると思います。特段スクラムにおけるチームには継続してプロダクトならびにプロジェクトに立ち向かう必要があり、そのチーム内の本質を理解することで、残念な衝突や顔色を伺っているだけの誤った心理的安全性の担保を回避できます。

    その要素の一つとして各人がもともと持っている「価値観」にフォーカスして向き合う手法としてご紹介できればと思っています。

    特にチームが組成した一番最初にやることをお勧めしています。

    普段は有料でのワークショップが義務付けられているこのワークショップをエンジニア、Agile界隈に広めた認定インストラクターの私がご提供します。

    価値観ババ抜きとは

    本来の自分を発見するカードワーク、それが「価値観ババ抜き」です。

    どんな人でも時に自分の人生や自分自身に迷いを感じたり、悩んだり、自信や元気をなくすことがあります。
    そんな時、「本来の自分」を、より深くわかっていたならば、そこに立ち返ることで、迷いや悩みを乗り越え、自信や元気を取り戻すことができるのではないでしょうか?
    私たちは、本来の自分を発見するための重要な要素が「価値観」ではないか?と考えています。

    価値観ババ抜きは、子供の頃に誰もが遊んだトランプゲームのババ抜きをモチーフとし、お互いのカードを取ったり・取られたり・場(フィールド)に捨てたり・拾ったりを繰り返すことにより、自分の価値観に触れてもらい、見える化するカードワークです。

    本来の自分を発見することで、自分自身が楽になり、もっと自分を好きになり、より豊かな人生を歩んでいただけるツール、それが価値観ババ抜きです。

    http://myvaluecard.com/?page_id=22 より

  • Yoshinao Ishiguro
    keyboard_arrow_down

    Yoshinao Ishiguro / Fumihiko Kinoshita - スクラムチーム 衰退の法則

    20 Mins
    Talk
    Intermediate

    いい感じにスクラムを実践していたチームがなぜ衰退したのか。

    機能するスクラムチームを一夜にしてビルティングすることができないのと同じように、スクラムチームの衰退も一夜にして起こるわけではありません。

    病気は徐々にスクラムチームを蝕んでいきます。気づいたときにはもう手遅れ。かつて機能していたスクラムチームは見る影もありません。

    本セッションではアジャイル開発実践者とアジャイルコーチが実際にあったプロジェクトを検死解剖し、どのような過程を経てスクラムチームが機能を失っていくのかを検証します。その上で、スクラムチームを蝕んでいた病気の原因を特定し、スクラムチームの衰退を防ぐためにどうすればよかったのかを検討します。

  • Kentaro Mii
    keyboard_arrow_down

    Kentaro Mii - B'zに学ぶスクラム開発 ~問題児(個性溢れるメンバー)達のSprintは続く~

    Kentaro Mii
    Kentaro Mii
    Scrum Master
    Rakuten
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    日本屈指のアーティストであるB'z
    CD売上日本一、毎年数十件行われるライブ、
    その成功の秘訣から、スクラムに応用できる部分を解説!

    する訳ではありません。

    スクラム開発の中で
    スクラムマスター、プロダクトオーナー、開発メンバーが直面した様々な問題や失敗。
    その時、どんなことを考え、どんな風に改善すればいいのか
    いつも、B'zの歌詞やメッセージが教えてくれました。

    ここ数年の開発の経験談にB'zからメッセージ(僕が勝手に思っています。
    を添えて、今スクラム開発で困っている人達に、共感と気付きをお届けします。

  • Shinya Ogasawara
    keyboard_arrow_down

    Shinya Ogasawara - 学ぶことの基礎筋力である「メタ認知」から認知科学・学習科学を始めませんか

    Shinya Ogasawara
    Shinya Ogasawara
    Manager
    Rakuten Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    私は2016年から教育心理学関係 勉強会/読書会で、継続的に認知や学びについての学習をしてきました。
    メタ認知というのはその中のトピックの1つで、認知を認知するメタ認知という考えを持つことで、気付きを得たり、よりよいやり方を見つけたりできるようになるというものです。

    ここでは認知とは、見る聞く書く読む話す記憶する考える理解する、など、頭を働かせること全般を指します。
    メタ認知によって、自分や他人の認知を捉えることは、こうした認知活動を見直し、改善していくことにつながっていきます。
    「どうすればもっとうまく話せるか」「自分はこうやって覚える方が得意だ」などの認知もメタ認知の1つです。

    学習科学の本などを参照しますと、メタ認知やメタ認知によって行われる自己調整学習は、学びにおいて、とても重要とされています。
    『メタ認知は知能なのか』という議論があるぐらい、私たちの学習に必要なものですが、一方で、メタ認知は教育可能と言われています。
    つまり、筋トレをするかのように、これからメタ認知力を鍛えて、私たちの学習の土台とすることができるのです。

    このセッションでは、まずメタ認知の概要や活用例、メタ認知の促進の仕方などについて参考書籍とともにご紹介した後、
    メタ認知は自分の心の内容やプロセスについて考えることですので、そうした内容を研究している認知科学や学習科学の内容は
    とても参考になると思いますので、私がこれまで学んだ内容について、時間が許す限り紹介していければと考えています。
    (例えば、認知バイアスの話や、モティベーション理論などについての話など)

    私自身の経験として、認知科学や学習科学などの内容に触れることで、
    ものごとの捉え方が変わったり、これまでと違う改善のアイデアが出てくるなど、有用さを感じています。
    このセッションが何か新しい気付きのきっかけになれば幸いです。

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya / Ken Takayanagi / Manabu Shibahashi / Yamato Naka / Yumiko Yoshida - 1on1フェスティバル! 自分に合ったメンタリングスタイルを見つけよう!

    100 Mins
    Workshop
    Beginner

    アイキャッチ

    コンテキスト

    1on1の導入企業や、ボトムアップで始めている現場は増えており、上司部下、チーム同士など様々な状況で用いられるようになりました。

    ところが多くの企業やチームでうまくいかなかったり、1on1疲れといった停滞が起きています。

     

    誰に向けていて何を得られるセッション?

    本セッションは1on1やメンタリングの実施に悩むリーダーや、チームとの対話に悩む方に向けた1on1体験ワークです。1on1の全体像を学ぶことに加え、5名による異なったメンターのスタイルを体験でき、自分に合ったスタイルを見つけるヒントが得られます。

    1on1が求められるようになった経緯、メンタリングとの関係との紹介、経験豊かなメンターによる1on1体験ができるセッションです。

     

    学べるスタイル

    森 雄哉「思考の整理」「認知変容」「問題解決」
    中 大和「感情の探索」「事実と感情の統合」「原初体験の探索」
    高柳 謙「思考のマッピング」「言葉の本質」「違和感の発見」
    柴橋 学「自分が主人公になる」「ニーズの発見」「事実をつかむ」
    吉田 裕美子 「ありのままの自分を受け入れる力」「感情の扱い方」「思考の整理と言語化」

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - 世界に飛び出そう!僕が海外カンファレンスから学んだこと

    Yusuke Amano
    Yusuke Amano
    ScrumMaster
    Cybozu
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スクラムを学び実践するみなさん、特にRSGTに参加して情報交換をしようという学習意欲の高いみなさんは、きっと海外カンファレンスにも興味があると思います。私も日本で学びを続ける過程で、「日本のアジャイル事情は少しずつ分かってきたけど、海外ではどうなんだろう?」という疑問を持ち続けていました。

    一般的に海外カンファレンスに行くには費用・言語・稟議など多くの問題があり、実際に行くには高いハードルがあると思います。そもそも高い費用をかけて行くほどの価値があるのか?という疑問もあるでしょう。

    価値があるかどうか判断するために、まずは飛び込んで情報を増やしましょうということで、私は1年でなるべく沢山の海外カンファレンスに参加するという実験を行ないました。直近約1年では下記のカンファレンスに参加しました。

    • Agile Conference 2019
    • LeSS Conference 2019
    • Global Scrum Gathering Vienna 2019(執筆時予定)
    • Agile Vietnam 2018/2019(執筆時予定)

    このセッションでは、実験の過程で学んだ海外カンファレンスの歩き方から、参加すべき人とその理由などを共有します。