ふくおかフィナンシャルグループ（FFG）では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。

• アジャイル組織の変遷
• 現行ルールのしがらみとの闘い
• アジャイル開発を少しずつ組織に浸透させていく方法
• 組織を拡大していくための対内・対外的な取り組み
• 拡大していく組織で発生した問題
• 成果を出し続けていくための組織やチームの意識改革

我々LINEのSETチームは、テスト自動化の実現・推進だけではなく、プロダクト開発チームのプロセス改善・DevOpsの推進・技術戦略の策定・実施といった活動を、全社的に行っています。

CI&Tではスクラムマスター（以下SM）のキャリアパスは通常テスター役から始まります。

テスターは開発者達と日々タスクを実施するので、開発の流れ、プロダクトの使い方、技術などについて良く知ることができます。

しかし、SMはプロジェクトマネージャーやプロジェクトオーナーと仕事をすることが多いのでどちらかというと「マネージメント」グループに含まれており、ビジネス要件にしか深く関わることができません。多数の案件を管理するようになると、チームが実際何に困っているか簡単に気づいてあげられない時もあります。

お客様と開発チームとの関係性をより良くするためにはどうすればいいのか。
どちらにも偏らないように、どうすればバランスを保つことができるか。
テスターとして積み上げた知識はSMになった私にどう役立ってるのか。

現在勤めてるプロジェクトの経験も通して、テスターからSMになって感じた変化についてお話したいと思います。

On CI&T, people who are willing to become Scrum Master (SM) usually starts the career path as a Tester.
The tester works daily with the developers so they are able to follow the development process closely, they are able to know a lot about the product itself and all the technologies involved.

However the SM works closer to the Project Manager and the Project Owner, which makes the role to be considered a "management" type. Also, the SM is only able to have deep knowledge about business requirements, since they need to manage several kinds of subjects at the same time. The multi-tasking makes it hard for the SM to realize what are the real needs of the team sometimes.

As a SM, what can I do to improve the relationship between the team and the client?
How the SM should keep the balance between negotiate team advices and PO requests?
How my experiences as Tester can help me as SM?

I'd like to share my experiences on this transition from Tester to SM, and my project.

2018年の11月頃から始まり、開発手法としてScrumを採用したとあるプロジェクトは、2019年の6月に予定通りサービスのローンチを行うことができました。

このプロジェクトはお客さんとのユーザーストーリーマッピングでのMVP検討から始まり、まずはサービスの背骨にあたるMVPの実装を1ヶ月で完了。その後4ヶ月間はリリースできる状態をずっと維持し続けながら、毎スプリント着実に機能を追加していき、ローンチの1ヶ月以上前にはお客さんが希望する機能の追加を完了。ローンチ前にはいくつかのメディアに取り上げられたこともあり、多少注目されながらローンチ当日を迎えましたが、そこでも拍子抜けするほどなんのトラブルも起きず、お客さんからも開発チームからも、これほど安定したプロジェクトは今まで経験したことがないといったようなポジティブなフィードバックをもらうことができました。

その結果、お客さんからの期待値が想定以上に高まってしまい、同じやり方を他の複数プロジェクトにも早急に導入することが決定。開発者を含む関係者が一気に倍増したことで、チームは混乱状態に陥ってしまいました。

今現在も混乱中ですが、RSGT2020が開催される頃までには何とかなってると思うので、私達がこれからどのようにして再び練度の高いチームを作り上げていったかについてお話しできればと考えています。

カンバンゲーム、宝探しアジャイルゲーム、心理的安全性ゲームなどを作ってきたやっとむから、ゲームの作り方を解説します。

私が作っているゲームは、一般的な商業ゲームとは違い、伝えたい明確な内容、ゲームの体験から受け取ってほしいメッセージが入っています。そうしたゲームを作るために、以下のような順番で考えます。

1. 伝えたいものはなんなのか自分の中で整理する
2. それを伝えられるゲームの枠組みを選ぶ
3. ゲームバランスを取る

1.の項目では、アジャイル開発であるとか、心理的安全であるとか、カンバンボードといった対象を自分なりに分析し、モデリングしたりシミュレーションモデルを作ります。ここでは、ゲームでは表現しない要素、切り捨てる要素を探します。

それをもとに、プレイヤーに体験しほしいエクスペリエンスを考えます。たとえばカンバンゲームでは、以下のような体験を想定しました。

• 全体が見えているとハイレベルな判断ができるようになる
• 個人でなく全体を最適化したくなる
• タスクが見積もり以上にかかる
• タスクが片付くと嬉しい、盛り上がる
• 人が抱えてる問題を知ると解決できる
• 自分の解決法を見せると誰かが利用する
• みんなでやると早く終わる
• 早く終わると問題が起きにくい
• 仕掛で残してると問題が増える
• 終わりそうだと思ったら問題だらけになる
• 話し合うと思わぬ解決法が見つかる
• 仕事を割り振るリーダーはいらない
• タスクに価値があると優先順位を判断できる

つぎに2.の段階では、そうした体験をゲームとしてどう表現するか考えます。世の中にはたくさんゲームがあるので、そこからアイデアを借りるのがよいでしょう(商業ゲームならパクりは問題ですが、自分のワークショップで使う分にはいーんじゃないかなと思っています)。逆に言うと、ゲームを作るコツはよいゲームをたくさん知っていることです。

カンバンゲームはカンバンボードを扱うものなので、カンバンボードをそのままシミュレーションします。タスクの内容、見積もり、ToDo/Doing/Doneはリアルそのものです。こうしたリアルを写し取った要素が多いと、ゲームから仕事に役立つ学びを直接得やすくなります。

もちろん、すべて再現してしまったらそれは仕事そのものなので、デフォルメ、ゲームらしさも必要です。仕事の進み具合をサイコロで表現する、問題と解決をそれぞれカードで表現するというのはゲームとしての工夫になります。解決が有効か話し合うというところは、『キャット＆チョコレート』などのゲームから借りたアイデアとなります。

世の中のゲームを知っているから自分のゲームのアイデアも浮かぶというのと同時に、道具立てもけっこう重要です。どんな道具が使えるか(いま持っていないものも含む)、それをうまく利用できないか。カンバンゲームでは、ゲーム用の金の延べ棒を使います。これを見るだけでプレイヤーはテンションが上がりますし、カンバンがDoneになったら儲かるんだということが直感的に伝わります。このインスピレーションは、仕事におけるタスクの見方にまで影響します。カンバンゲームでは次のような道具を使っています。

• サイコロ → 仕事の進捗は予測できない
• 仕事残量をチップで見せる → 仕事の大きさが目で見える
• 問題カード → カンバンで問題が起きていることの見える化
• 解決カード → 手札に持った解決方法を適用できる
• 金塊 → 仕事には価値があることの実感

最後が、3.のバランス調整です。時間的にはここが一番かかります。ゲームの枠組みがあっても、求めている体験が本当に得られるか、違った感触のものになってしまわないか、予想外の抜け道がないかなどを考えます。バランス調整では、いろいろな人に実際に遊んでもらう必要があります。

カンバンゲームではこのバランス調整の中で、以下のような発見や出来事がありました。

• 無理筋な解決法を押し通そうとする人がいる
• 「もっとがんばる」で解決できると主張を崩さない人がいる
• ピッタリ合う解決法しか使いたくない人がいる
• EVENTカードを先読みして期待する
• 無理だと思ったらサイコロが爆走して完了する
• 自然と1人1タスクにしてしまう(習慣の力は強い)

私のゲームはプレイヤー同士の会話を重要なファクターにしていることが多く、そのためゲームとして破綻することは少ない(ルールを悪用して一人勝ちする、など)ものの、よい会話が生じるかは気をつかうところでもあります。

バランス調整はある意味永遠に続き、ゲームをやっては微調整をしたり、たまに大幅バージョンアップが起きたりもします。

当日はこのような話をします。参加者の方と一緒にゲームを作る時間があるかは、採択の結果に寄ります。

Joy,Inc.に出会う前のぼくらは、チームとして機能していませんでした。2013年ごろ、色々な問題が噴出し、会社としてどん底の状態でした。
そこから、色々な取り組みを行い、少しづつ会社の状態がよくなっていきました。その過程のなかで2017年8月「Joy,Inc.」に出会いました。
「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
この本に共感しぼくらもこんな会社に成りたい！と決意。それを実行してきました。
会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

仕事・夢・人生

モラトリアムな就職浪人、地元に近いという理由で第二新卒入社した中小SIerでプログラマ、通信キャリアの企画部署に長年常駐、海外合弁事業が初のグローバルな仕事。

アプリ開発ベンチャーでディレクター、転機となった自費40万で参加したSXSW2014、そして未払い賃金を勝ち取ったけど一瞬フリー状態に恐怖。

先輩つたってEC基盤な事業会社で良くしてもらい、そしてSXSW2014の縁がつながって現職と、20年近い仕事人生をなんとか渡り歩いてきました。

Toxic behaviours in a Team cause damage to the Team. Affecting their performance, causing high levels of stress and demotivation. Conflict Navigation is one of the biggest challenges within the Teams. Can you help them to overcome this challenge? Are there any antidotes?

When a Team member shows a toxic behaviour, how the Team reacts to it? Can we educate the team and help them as a System to overcome these challenges? As a Scrum Master or a Coach, our main mission is to help out teams to be their better selves. By the end of this workshop, you should be able to help your team to be better prepared to deal with conflict.

今年7月に開催されたAgile Japan 2019、前回600名強だった参加者は900名強に大幅に増加、様々な趣向を凝らし、実行委員としては自ら体力・気力・知力の限界に挑むがごとく「もろ刃の剣」のような様々なチャレンジがありました。

また、時勢はアジャイルやスクラムといった言葉がバズワードっぽくも市場は様々な企業・事業がアジャイル等の導入・検討するなど盛り上がってきています。

そんな状況のなか、縁がつながりAJ2019実行委員という形で出会った3名。

• CI&T 川渕洋明
• クリエーションライン 小坂淳貴
• 楽天 吉田彩奈

それぞれ異なるバックグラウンドや経験。
すでに発起から10年が経過したAgile Japanと実行委員会。
それぞれの想いと現実。

半年以上の期間を経て成立したAJ2019。
そこまでの喜怒哀楽と紆余曲折。
そして迎えたカンファレンス当日。

気づき・教訓・ぶっちゃけ・毒吐き・・・
チームとは？アジャイルでありたいのに・・・
・・そしてAJ2020へ。

そんな状況を追体験いただけるような、この3名によるパネルディスカッションをお届けしたいと思います。

In this talk, the speaker will present a brand new retrospective format which quickly became popular in Japan. This method is heavily influenced by Japanese culture, but it may work great in other cultural contexts. We are looking for your feedback.

Someone said Agile does not work in Asian Culture: https://www.infoq.com/news/2016/06/agile-asia/

We totally agree with this topic.
One of the difficulties comes from retrospectives.

We found that a positive retrospective format better fits our culture: Fun! Done! Learn! After we published the method in a blog in Japanese, many teams in Japan started using this format. We did not teach neither facilitated directly; people just adopted and started using it. We would like to share this retrospective method as well as how teams in Japan embraced it. We are eager to hear from you whether this would work with your teams or not and why.

• 「ビジネスになったアジャイルをエンジニアに取り戻せ！」

師匠：David氏からDevOpsDays Tokyo 2019で強いメッセージを受け取った直後に臨んだ認定スクラムデベロッパー研修。エンジニアがオーナーシップを持ってプロダクトと向き合うこと、スクラムをやるためにはXPが必要であるなど、私たちは師匠から熱い想いやメッセージを受け取りました。

これを経て、改めて『エクストリームプログラミング』(2015/6/26 Kent Beck (原著), Cynthia Andres (原著), 角 征典 (翻訳))に目を通すと、

“XPが価値、原則、プラクティスを用意しているのは、ガイダンス、チャレンジ、説明責任を提供するためだ”

とあり、XPは単なるプラクティス集ではなく、エンジニアは自分たちが取り組んでいることに対してちゃんと価値を理解すべきであり、それを周りの人たちに責任を持って説明していく必要性があることを強く訴えている、非常に刺激的なものであることに気づきました。

「お客様に継続して最も高い価値を届けられるのは自分たちだ！」と自負をしながら、より高いスキルやデザインを追求出来る。

スクラムとXPを最高のチームで体現していく勇気を、今こそ分かち合いましょう！

• 「社内なのに請負開発みたいだ・・・」

”ビジネス側” から言われたものを言われた納期でつくる。私達は内製のプロダクトのはずなのに、まるで請負契約のような開発をしていました。

そこから、開発チームが少しずつ変化し、プラクティスを実践し、”ビジネス側” を巻き込み、プロダクトの価値をともに考えるチームに成長してきました。

その変化の中で、プロダクトが価値を届けることにフォーカスし、チームの中心に据えることができたのは、師匠から学んだ価値、原則、プラクティスと、その実践の影響が多分にありました。

もっとより良いチームになりたい。もっとより良いプロダクトを開発出来るようになりたい。そんな想いで立ち上がり、一歩ずつビジネスと向き合えるようになったチームの今をお話します。

スクラムチームは、ホントのイノベーティブなプロダクトを作れますか？

近年、「デザイン思考」という言葉の使用が増加しており、ソフトウェア設計が戦略設計やサービス設計に取り入れられるようになるにつれ、良い設計の敵はスクラムか、という議論が多くなっています。スクラムと設計はどのようにシームレスに連携するのでしょうか?

６年でデザイン会社に働いて、スクラムとアジャイルの世界に入った時にデザインのリサーチャーから見ると、会話の中で何かが欠けているように感じられます。スクラムとアジャイル組織が単に「デザインに優しい」になるのではなく、エンジニアとデザイナが協力して構築した新しい世界を作るために、私たちはDAIKONというフレームワークを作成しました。DAIKONは、「ダイバージェンスとコンバージェンス」という「拡散・収束」のことから来ます。イノベーティブなプロダクトを作るために、デザインかスクラムだけではなくて、両方の力が必要と思います。

今回の講演ではスクラムとデザイン思考の歴史,最新の視点、そして現在クライアントとテスト中のDAIKONフレームワークについて議論します。私たちのチームが学んだことを話して、DAIKONフレームワークのテスト方法を教えます。

このトークは日本語になります。

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

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

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

1チームがそれなりに成果出すにはかなりの努力が必要です。

ましてや、普通に複数Scrumチームは難易度hardですよね…？
チームがScaleするには、どんな現実の「制約」が問題なのでしょうか？

より上の、より先のチームや開発を目指したい方にSAFeとLeSSから学んだことを伝えます。

大規模なアジャイルの難しさ

「大規模アジャイルってどんなものなの？」

大規模≒Enterpriseという認識で大規模開発にアジャイル開発を始めても多くの人が失敗しています。もしくは、そのような不安から大規模開発に踏み切れない人の相談を多く聞いています。
現場のマネージャ、チームのリーダー、その中で働くメンバーたち…悩みは、それぞれです。

私たちには何が足りなかったのでしょうか。

大規模アジャイルのエッセンスを絞って、「これだけ」分かって欲しいことをお伝えします。

大規模アジャイル開発で気を付けること

「大規模アジャイル開発で、まず何から始めたらいい？」

そんな疑問を大規模アジャイルの開発手法であるSAFeとLeSSから良いポイントを抜き出し、考えるべき重要なポイントを紹介したいと思います。

お話しするのは、実際にSAFeと LeSSを学習したり、実際に体験して気が付いた事です。
単なる手法の比較ではなく、それぞれの良いポイントを挙げたいと思います。

二つの手法から分かる、大規模なアジャイル開発でおさえておくべき“大切にしている”ことを話します。

アジャイルコーチから見た大規模アジャイル

「大規模アジャイルって、実際どうよ？」

研修や本からは読み取れない大規模アジャイル開発手法に見えた「秘訣」があります。
例えば、大規模アジャイル手法には、1チームのScrumでも使える良い考え方やプラクティスが実際、あります。

普段のアジャイル開発に役立つ考え方やプラクティスを伝えます。

参考

SAFe 日本語サイト
http://jp4.scaledagileframework.com/

LeSS 日本語サイト
https://less.works/jp/

大規模アジャイル開発手法の全体像

■SAFe4.5（英語版のみ。日本語サイトは4.0）

■LeSS

The scenario is: a company decided to run Lean/Agile in a program led in Europe (including teams from different locations).

The challenge is defined, but how to do this transition?

This is a real experience of 1 year transforming 3 teams by coaching Agile and Lean principles at CI&T.

In this session I would like to share:

• How the strategy was defined?
• How to deal with different cultures?
• Why people are so important in this journey?
• What are the key steps to get a smooth transition?

After 1 year what are the results achieved so far, what did not work and the difficulties during the transition.

手書きという行為が本当に嫌いでした。
スクラムを実践するまで、ペンを持つ機会を全力で避けて生きてきました。

そんな私が●千円もする携帯用ホワイトボードを日頃から持ち歩き、ファミレスでも客先打ち合わせでも積極的に活用するようになったことで、気づけば周囲から「ホワイトボードを書く人」としてチーム外の会議に呼ばれるようになっていました。

スクラムチーム内外での実践から得た書き手のメリットを中心に、好きが高じて非エンジニアな業界などからも学んできたお話を織り交ぜながらご紹介します。

RSGTに参加される方々は、日頃からホワイトボードを活用しながらより良い場を作られている事かと思います。
そんなみなさんの気づきや助けになるような機会になればと思い、プロポーザルを出させていただきました。

濃厚な20分間を共有しながら矢印の書き方やペンの持ち方などのちょっとしたコツを覚えることで、あなたのホワイトボード生活がグッと楽しくなること間違いなし、です！

新卒で入社し、2.5年目にスクラムマスターをやらせていただきました（もはや、やるしかなかったですw）。

元々リーダーシップやチームワークが好きとは言え、いきなり三つの国をわたるチームのスクラムマスターになり
「えええ？！」と思いながら、あっという間に一年間のプロジェクトを過ごしてきました。

国における違いの上、20人近くのチームに様々な国籍を持ち、
人間って本当に面白いなーと思わせてくれた一年でした。
「えええ？！」と思った回数も数えきれなくなったし
これまで勉強してきたスクラムやアジャイルの原理を何回も違反したけれど
「出来ないこと」ではなくて「出来ること」に集中して
常に改善を求めることが完璧なプロセスを完璧に適応するより大事だと気が付きました。

自分の経験はまだまだ浅いかもしれませんが、それに関わらず
非常に濃くてユニークな一年を過ごしてきましたので
苦労したこと、うまく行った・行かなかったこと、学んだこと、次回やりたいこと、
全てオープンに話たいと思います！

Agile開発がどんどん一般的になってる今日このごろですが

運用のことまで考えられている場合がまだまだ少ないのでは無いでしょうか。

とはいえ、運用まで考えて開発をすすめるのは難しい。

なので、「過ぎたことはもう仕方ない、どうすれば運用を良い方向にかえていけるか？というKaizenをテーマにトークします。

開発時のPOの反応は良かった。満足してくれた！と聞いていたのに、運用になってプロジェクトに入ったら・・・

あれれれ？？不満頻発？ときに炎上、ときにバグ祭りの色々ありましたぜ旦那！な経験と

ガチガチの内資と超外資な真逆の会社両方でAgile開発と運用に関わった観点からお話してみたいと思います。

こんにちは。2年前に転職してEC通販/製造企業のIT部門長をしています。元アジャイルコーチだった私は早速スクラムを導入し、持ち前の鈍いマサカリと役職権限をふりかざして覇道系プロダクトオーナーとして切磋琢磨しています。

“システムの価値は、その機能ではなく、どう使われるかで決まる”
どこで読んだか聞いたかことか忘れましたが、私はずっと意識してきました。

私が就いたIT部は、つぎはぎシステムの補修とそれが吐き出す壊れたデータを直すことで日々を追われていました。
やらなければならないことが多すぎるので、できるだけ手間をかけずに要望を満たす必要があります。しかし機能を削るだけでは利用部署の不満は増します。
私は、十分に機能するものを小さく作るために「どう使うか」に注目することにしました。そして、そのために利用部署との間に「これはいいものだ」と言える共通の認識を作りあげるよう努めてきました。

インクリメントは何かできたかよりも、いつ・どういう形でデリバリーするのかを評価します。業務で使ってもらうのに「ちょうどよい」タイミングがあり、業務部署にそう認識してもらうための過程があります。事業部との間に共に解決するという関係性を築いて、プロダクトバックログがインクリメントに変わったときにもっとも効果的に使ってもらえるよう図るのです。

また、成果に結びつけるにはチームメンバーの深いコミットメントも必要になります。指示をうけるだけでは「いいもの」にはなりません。
メンバーのそれぞれの動機やスタイルを尊重したうえで、やみくもに個人の欲求を優先するのではなく、チームの目的とどう一致するかを見いだしてもらうよう工夫しています。場合によってはテストや設計の知識の甘さを問いただすこともありますが、できるだけ共同で解決して実体験から理解してもらえることを原則にしています。

昨年のRSGT2019では、IT部が批難の的から信頼を獲得するストーリーを発表させてもらいました。いま私たちはとある次の大きなステップを目指しています。その過程として、共感をベースとした価値構築に奮闘しています。
いま、共感に基づいたマネジメントが見直されていますが、人のためだけでなく価値を高めるために重要なファクターでもあるということ皆さんと共有できたらと思います