世の中、さまざまな陰謀論やフェイクニュースが世間をにぎわしています。Scrum をはじめとしたソフトウェア開発の考え方、世界的に有名なサービスやツールの多くはアメリカから排出されています。ですので、「ソフトウェアの先端の国はアメリカである。」というイメージを持たれている方も多いかもしれません。

…　で、本当のところはどうなのよ？

そこで、元アジャイルコーチの私が自ら、ガチ三流プログラマとして米国に移住して米国の超巨大クラウドのサーバーレスプラットフォームの中の人になってみましたので、アメリカのシステム開発の本当のところを、皆様から多くいただく質問に答える形でシェアしてきたいと思います。

秘密さえ知れば、恐れるに足らず！日本を最高にソフトウェアに強い国にするための一歩を一緒に踏み出してみませんか？

こんな質問に答えてほしい！というリクエストがある方は twitter @sandayuu までお知らせください。

プロダクトバックログのすべてを完全解説!!

スクラムにおいて、プロダクトバックログは肝となる要素の1つです。プロダクトバックログがなければスプリントは始められないですし、単に要件を切り刻んで並べたようなプロダクトバックログでは変化にも対応できません。

スクラムガイドを見ると、プロダクトバックログの作り方、書き方、維持や管理の仕方については、多くは触れられておらず、多くの人は実践で試行錯誤しながらより良いプロダクトバックログを目指して改善を続けられているのではないかと思います（それはそれで素晴らしい）。

一方でプロダクトバックログを誤解しているのもよく見かけます。すべてをユーザーストーリー形式で書く必要もないですし、全部を同じ具体性にする意味もありません。すべてのプロダクトバックログアイテムをプロダクトオーナーが作らなければいけないわけでもないですし、すべてのプロダクトバックログアイテムを実装しなければいけないわけでもありません。Webアプリケーションでログイン機能がプロダクトバックログの上位に必ず来るわけでもありません。

本セッションでは、プロダクトバックログをうまく使えるようになるための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

成長しているプロダクトには"いい感じ"のチームが関わっていることが多くあります

"いい感じ"のチームとなっていくには、それなりの時間が必要であり、その時間の中でどのようなマインドセットでどのような活動をしていくかによってその行く末は変わってきます
もちろんチームの行く末によってプロダクトの成長にも影響が出てくることもあります

2020年版のScrumGuideでは、スクラムチームの説明として以下のように記述があります

スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究 開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、 自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続 可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上す る。

では、"いい感じ"のチームになるにはどのような活動を行い、どのような関心を持てばいいのでしょうか？

このセッションでは、「 "いい感じのチーム"に近づくヒント」を中心にチーム活動に関するいろいろなトピックについて、元ギルドワークスのアジャイルコーチとして70チーム以上を支援してきた自分なりの経験や考えをお話できればと思います

『スクラムガイド』2020年11月版より登場した「プロダクトゴール」。ガイドによれば、以下のように説明されています。

プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットとなる。（中略）プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。（後略）

ここでだけみても非常に重要なゴールであることがわかります。しかしながら、自分たちのプロダクトにとってのゴールを具体的に設定するには、考慮すべきパラメータが多いのではないかという印象をどうしても受けてしまいます。それでいてあらかじめ決められた目標や予算、期日にロックオンされ、有名無実なプロダクトゴールにならざるをえなく、建設的なプロダクトゴールを諦めてしまっていないでしょうか。はたまた硬直化したプロダクトゴールは経験主義と矛盾した概念や結果につながりかねず、従来思考の経営者やマネジメントへの誤解の元にもなるという議論も積み重ねてきました。

このセッションでは、「プロダクトゴール」を解説しつつ、できるだけ具体的で成果につながるプロダクトゴールを設定するために、アジャイルコーチが支援先でも共に取り組んでいる「エビデンスベースドマネジメント」を用いたプロダクトゴールの設定と達成（あるいは放棄）についての考察を共有します。

エビデンスベースドマネジメント（EBM）とは
EBMは、組織が不確実な条件のもとで顧客の成果や、組織の能力、ビジネスの結果を継続的に改善するために役立つ経験的アプローチです。組織が価値を提供する能力を向上させ、戦略的ゴールに向けた道筋を模索するための経験主義に基づくフレームワークで、Scrum.orgによって考案されたものです。

セッションの提案するために書いたポンチ絵:

このセッションで取り扱わないこと：

• 正解・正答（考察セッションです。正解は聞いていただき、実践の中で見つけてください）
• プロダクトバックログの作り方
• エビデンスベースマネジメント（EBM）の自体の詳細解説

English follows Japanese.

私は2013年から、自社サービスを展開する事業会社で、社内アジャイルコーチとして活動してきました。

チームビルディングから、開発生産性向上のための（テスト自動化・DevOpsなどの）技術支援、新規プロダクトの共創、さらには経営層を巻き込んだ組織改革と、活動範囲は多岐に渡りました。そして、多くの失敗と、いくつかの成功とを重ねてきました。

この度、社内アジャイルコーチを辞めるにあたり、改めてこれまでの活動結果およびそれらの自分なりの分析結果とを整理し、社内／外のアジャイルコーチ、および同世代／次代のアジャイル実践者へ提供することが、自分を育ててくれたアジャイルコミュニティへの貢献になるのでは？との考えに至りました。

そこで当セッションでは、特に事業会社の社内アジャイルコーチというコンテキストで、自身が悩み、試し、伝える価値があると判断したものを、特にチーム・技術・組織の3点から整理してお話しします。

I had worked as an internal Agile Coach in several internet service companies since 2013.

I had done a wide variety of activities such as team building, implementing technical foundations for enhancing developer productivity, founding totally new products, and leading organizational changes with the management. There were lots of failures, and some successes.

I convince that sharing ideas and knowledge earned through the experience of those my internal Agile coaching activities will contribute to the Agile community.

In this session, I will talk ideas and knowledge earned through my internal Agile coaching activities from 3 aspects like 1) team, 2) technology, and 3) organization.

学生のころからScrumを実践する機会があり、RSGT2017でその事例をスピーカーとして話したことをきっかけにコミュニティ活動を始め、 就職後もScrumの勉強を続けてきました。

その一方で、配属先で導入されていた"Scrum"は、それまでの経験が活かせるものではなく、自分が思う開発チームのイメージとのギャップがある状態がずっと続いていました。

そのギャップを埋めるためには、これまでに経験してきたScrumの良さを伝えてチームを変えていくしかないと思い込んでいました。しかし、コミュニティでいろんな話を聞く中で、今いる組織だけが組織ではないと気づくことができました。

そこで、業務上のつながりはないものの、社外のコミュニティで出会った同じ会社の人に相談してみようと思いました。結果的に社内異動の希望が通り、Scrumに組織的に取り組んでいる部署で働くことができるようになりました。

異動後は実践的な学びを得ることができ、プロダクトもプロセスも楽しむことができています。

本セッションでは、Scrumで開発をするために異動という選択肢をとった経験と、異動後に得られた気づきや喜びについてお話しします。

2001年にアジャイルソフトウェア開発宣言が世に出てから約20年の月日が経ちました。

15th State of Agile Reportに寄ると、ソフトウェア開発チーム内でのアジャイルの採用が大幅に増加し、
2020年の37%から2021には86%にまで増加したそうです。マイノリティだったアジャイル開発は、ソフトウェア開発のスタンダードになりつつあります。実際にここ数年で企業から出ている求人を見ても、アジャイル開発やスクラムに由来する職種の名前をたくさん見かけるようになりました。

ところで、
5年後、10年後、20年後もアジャイル開発はアジャイル開発なのでしょうか。
5年後、10年後、20年後も私たちはアジャイル開発に携わっているのでしょうか。

もちろん目の前の仕事やプロダクトやチームのことを考えることも大切ですが、たまには少し未来のことを考えてみることも多角的な視点をもつという意味で大切なことです。

私は、10年以上、企業内でエンジニアとしてチームの中でアジャイル開発を実践し続けてきました。その中でSilver Bullet Clubというチームを結成し、2019年にはチーム転職をして企業を越えていまもなおチームで活動を続けています。また、パラレルワークで、さまざまな組織やチームを支援するアジャイルコーチもしています。

そんな自分が、さまざまな経験を経た現在アジャイル開発をどう捉えていて、アジャイル開発のミライをどう見ているのかについてお話してみます。

未来が実際にどうなるかは誰にもわかりませんが、未来をソウゾウすることは誰にでもできます。
アジャイル開発の未来がどうなるのか想像を膨らませながら、自分たちの未来をどのように創造していくのか一緒に考えてみませんか？

みなさんの周りに「生き生きとした繰り返しあらわれる構造」はありますか？

RSGTをはじめとするカンファレンス、書籍、ブログ、Wiki、コミュニティ、チーム、会社、学校。様々な場所でおたがいの知見が共有され議論され、モチベーションをあげて現場にむきあうということをしてきました。そのなかでいくつもの工夫、プラクティス、パタンを発見し、共有し、教えてもらい、試してみて、試されてみてということの連続で徐々に自分達の実力があがっていることを実感し、またエンゲージメントの高い状態を保てていることにも気付きました。

そこからアジャイルコーチをして気付いたことがあります。あまりにも形式知と現場での導入にギャップがあることです。それゆえにアジャイルコーチとして仕事があるわけですが、これはアジャイルコーチによるアジャイル実践知の独占ではないでしょうか。。。パタンはデザインの民主化であり、アジャイルはプログラマーの復権という側面がありました。ですが、現在のスクラム界隈、アジャイル界隈は元の理念から遠い場所にいるのではないだろうか。。。そんなことを思うようになりました。

そして、47機関はパタンランゲージとむきあうようになりました。アジャイルコーチとして活躍している自分を、アジャイルチームとして活躍している自分達を、一度リセットするためにです。いまこそソフトウェア工学を、コンサルティングを、コーチングを、ナレッジ共有を変えたいと。

その一端として、パタンランゲージの解像度を極限にまで高くすることにしました。わたしたちのパタンは数百を超え、非常に繊細で柔軟で美しくその形を表してくれるようになりました。パタンにはヒエラルキーがあり、その大きさは様々です。

アジャイル開発で共有されているパタンやプラクティスのおおくは10分から60分程度の活動をまとめたものがおおくみられます。47機関ではその大きさだけではなく、6秒単位までのパタンを発見し、自分たちの振舞いを、チームをデザインし、実践するようになりました。600秒単位でしかアドバイス、共有、フィードバックできなかった私達は6秒単位で自分たちについて考えられるようになりました。

このような取り組みをへたことで、アレグザンダーが提唱している空間に無数に存在する生命構造を、調和するということを徐々に理解でき、私達がさまざまなものとつながっていることを理解し、実践できるようになりました。

みなさんの周りに「生き生きとした繰り返しあらわれる構造」はありますか？

アジャイル開発はその一部にすぎません。47機関がチームを100倍理解できるようになったその経緯、事例、そしてみなさんにオススメのはじめかたを紹介しようとおもいます。

English follows Japanese

私たちが現在開発しているシステムの元となったものは、テストがなく、ドキュメントに乏しく、独自フレームワークで動いている、バス係数が1の、10年以上の歴史を持つwebサービスでした。いわゆるレガシーシステムであり、ビジネスの変化に対応するための柔軟な変更を行えない状態です。一つの変更がどこに影響を及ぼすのか分からず、テストもないので自信を持って開発を進めることができません。

そんなレガシーシステムから脱却するために行ってきたことは、関係者と対話を頻繁に行うことで達成したいことと優先順位を決め、状況が変わったら柔軟に計画をしなおし、少しずつ動くソフトウェアを作り込んでいくことでした。

今では、簡単な内容なら要望を受けてから40分未満で開発〜本番環境への反映が完了するまでになりました。自信を持って開発を進め、変更をリリースできています。

このセッションではレガシーシステムからの脱却を進めている私たちが、どのようなことを気にしながらシステムリプレースをしているのか、お話します。

私は10年以上の歴史があるwebサービスのシステムリプレースに、これまで2回関わってきました。初めて関わったシステムリプレースは「読書メーター」というwebサービスで、現在関わっているシステムリプレースは「ニコニコ漫画」というwebサービスです。読書メーターのシステムリプレースでは失敗したことも多くあり、そこから学んだ内容を現在行っているニコニコ漫画のシステムリプレースで活かしています。初回の失敗との差分を含めてお話できればと思います。

The original system we are developing now was a web service with a history of more than 10 years, with no tests, poor documentation, running on a proprietary framework, and a bus factor of 1. It was a so-called legacy system that could not be flexibly changed to respond to business changes. We don't know where a single change will affect, and without testing, we can't proceed with development with confidence.

What we did to get rid of such a legacy system was to have frequent dialogues with the people involved to determine what we wanted to achieve and what our priorities were, to flexibly re-plan when the situation changed, and to gradually build a working software.

Now, we can complete development of simple content in less than 40 minutes from the time we receive the request to the time it is reflected in the production environment. We are able to proceed with development and release changes with confidence.

In this session, I will talk about how we are moving away from legacy systems, and what we are paying attention to when we are replacing our systems.

I have been involved in two system replacements for web services that have been around for more than 10 years. The first one I was involved in was a web service called "Reading Meter", and the one I'm currently working on is a web service called "Nico Nico Manga". There were a lot of mistakes in the replacement of the Reading Meter system, and I'm taking what I learned from those mistakes and applying it to the current replacement of the Nico Nico Manga system. I'd like to talk about the differences between the first failure and the current one.

Translated with www.DeepL.com/Translator (free version)

セッションのやりとりはMiroを使うぞ！
https://miro.com/app/board/uXjVOYf05MM=/

よぉ人類！はじめまして。我々はフリカエリ星人である。

我らが星では「ふりかえりエネルギー」が発展のために必要である。
そんな中、遠く離れた星で「ふりかえりエネルギー」が近年増大しつつあるのをキャッチした。それが地球だ。私たちはふりかえりエネルギーの増加を図るために、地球へ向かっている。到着予定日は、地球で言う2022年1月5日―そう、RSGT2022だ。

地球の同志とは、フリカエリ星との初邂逅となるこの喜ばしい日に、ふりかえりに関する話をみんなで情報共有したいと思っている。

我々からは、地球の同志にふりかえりに関するTIPS集を紹介する。
ふりかえりをするとハマるポイント、新しい発見につながるヒント、オンラインでのコミュニケーション、手法。
これらのTIPSは、我々フリカエリ星で複数の仲間たちから収集する、新鮮でかつ実体験に基づくものばかりだ。

地球の同志からは、ふりかえりの悩みをその場で収集したい。その場で我々の知恵を授けたいと思う。地球人同士でDiscordやMiroなる機器を用いて情報を交換すれば、より大きな「ふりかえりエネルギー」が生まれるはずだ。

それでは、同志に会える日を楽しみにしている。

機械学習は、現在のITにおいて欠かせなくなりつつあるテーマの一つです。しかしながら、受託ソフトウェア会社は、顧客から求められない限り、投資のためのリソースが割き難いという現状があります。このような状況を打破すべく、2020年8月より、部門横断での技術獲得活動（所属部門を離れ、獲得したい技術を活用したプロダクトを作ることで学ぶ）を始めました。実際にモノづくりをしながら学んだメンバーが、近い将来、各部門で新しい価値を生み出してくれることを願って。

未知の分野の探索は、アジャイル・Scrumの得意分野です。私たちはこの命題を信じて、一貫してアジャイルな活動を継続しています。さらに、年度をまたぎメンバーを入れ替えていく状況においては、組織的な知識の獲得・移転・拡大も大きなテーマとなりますが、その実現に向けては、野中先生のSECIモデルを大いに参考にしています。

2021年10月より、2年目の活動が始まります。RSGT2022が開催されるころには、2年目の活動にも成果が見え始めるころでしょう。それも前提におきつつ、「機械学習とアジャイルの相性」「事業化を目的としないモノづくり活動におけるビジョン形成」「誰もわかってない分野での学習方法」「多様な価値観を持つ幅広い世代のメンバーでの合意形成」「学習成果の移転」などのトピックについて、1年半の活動で得られた知見をベースにお話できればと思います。

チームの中にある個々人をそれぞれコーチングすることと、チーム全体の関係性をコーチングすることには大きな違いがあります。
個々に1on1したり対話するわけではなく、そのメンバを全体性として扱う方法をシステムコーチングというやり方を通して学び、感じてみたいと思います。

※本セッションは現地会場のみの参加型セッションとして開催します。参加人数には限りがあります。
オンライン参加の方や人数制限で参加できなかったりした方で、興味をもたれたり、独自に開催して欲しいなどのご要望などあれば相談できるかもしれないので、諦めずにお気軽に一度ご連絡ください。

---

本セッションは参加者のみなさん自身が システムコーチング® を実施・提供できるようにトレーニングすること目的とするものではありません。体験セッションを通じてよりシステムコーチング®に馴染みを持ってもらうことを目的としています。
トレーニングを受けたい方は CRR Global Japan へどうぞ !!


以下のものは、CRR Global Japan 合同会社の登録商標です。 http://www.crrglobaljapan.com
システムコーチング®
関係性システム™

みなさん、KPT（けぷと）はご存じですか？きっと、名前を聞いたことや、一度はやったことがありますよね。
2021年9月、「KPT」のやり方・あり方が、Twitterを賑わせました。

• KPT (Keep/Problem/Try) 等のふりかえりで、K (Keep) ネタを増やすみんなの工夫 - Togetter

Twitterの反応を見るとわかるように、「KPTがうまくいかない」という声はたくさん耳にします。

でも、それはKPTだからなのでしょうか。
そのKPTのやりかたは正しいのでしょうか。
KPTとは本来、どのような方法なのでしょうか。

KPTは有名な手法です。だからこそ、聞きかじりで知ったやり方や、深く調べずに出てきたやり方で、なんとなーく行ってしまうケースも少なくありません。

私たちもKPTにうまくいかないという経験をしてきました。
そこからいろんな現場を経て、多くの人が「うまくいかないんだよねー」と言うKPTでも、うまくいくポイントがあることがわかりました。ポイントをおさえておけば、KPTというステキな道具を扱いやすくなるんです。
これだけ日本中に普及したということは、KPTにはいいところがあるからなんです。

今だからこそ、KPTを再訪していく。

みなさんに改めてKPTの良さを伝え、KPTを効果的に行う方法をいちばんやさしくガイドします。

In September 2021, I was certified as a Certified Team Coach by the Scrum Alliance.

I've heard that there are still very few Certified Team Coaches in Japan, so I'm sure many of you may be interested.

I will introduce the path I took to become a Certified Team Coach in this session.

If you just listen to a talk, your brain will forget most of it.

This session will be in the form of a workshop to create a relationship among the participants and to help them learn and take action.

The application for the CTC is structured in a way that strongly encourages self-reflection. My path to the CTC is the result of exploring the skills needed to be a ScrumMaster, seeking out opportunities, practicing, reflecting, and exploring again. This is just my path. I am sure that each participant has his or her own path. I would like to conduct a workshop where participants can think about the skills needed to be a Scrum Master and how to develop them to the guide level, and lay out their own path.

2021年9月に Scrum Allianceの Certified Team Coachに認定されました。

日本ではまだ少ないと聞いていますので、ご興味がある方も多いのではないでしょうか。

本講演では、私がCertified Team Coachに認定されるまでに、どのような道のりを歩んできたのかをご紹介します。

ただ話を聞くだけだと、人の脳はほとんどのことを忘れてしまいます。

本講演はワークショップ形式にし、参加者同士の関係性を創り、参加者ご自身の学びと行動に繋げられればと考えております。

CTC取得のアプリケーションは、自身の内省を強く促す構成になっています。私がCTCを取得した道のりは、スクラムマスターに必要なスキルを探求し、場を求め、実践し、ふりかえり、また探求し、を繰り返した結果になります。これはあくまで私の道です。参加者の皆様にはそれぞれの道があると思います。スクラムマスターに必要なスキルと、それをガイドレベルまでどのように伸ばすのかを、参加者の皆様で考え、ご自身でご自身の道を敷いていくようなワークショップを実施できればと考えております。

クラスメソッド社では、スクラムを使ったベトナムオフショア開発をモダンオフショアと定義し、過去2年間で5プロジェクトの実践を通して、数多くの知見をためてきました。

今回はそのモダンオフショアの中でも特にキーマンとなる、グローバルアーキテクトの役割、実際にやっていることとその効果について、お話しします。

皆さん、チームに新しいメンバーがジョインする際（もしくは自分自身が新しいチームにジョインする際）、オンボーディングに手間取った経験はありませんか?

異なるバックグラウンドを持つ人間が集まり、一つのチームになるのは簡単なことではありません。そして、一度できあがったチームに新しく人がジョインし、新たにチームとしてまとまっていくことはさらに難しいことです。We（私たち）としてまとまっているところに、I（私）がやってくる。やってきたことも価値観も異なり、両者の間にまだ信頼関係はありません。新しい価値観が入り込むことで、もしかしたらまとまっていたWeもバラバラになってしまうかもしれない。

もう一度いいます。一度できあがったチームに新しく人がジョインし、新たにチームとしてまとまっていくことは難しいことです。

チームメンバーはなるべく固定したほうがよいー。それは一つの真実でしょう。しかし、現実には異動や転職など様々な理由でチームは代謝していきます。
そしてチームが代謝するということは新しい風が入るということでもあり、うまくオンボーディングを設計することでチームは人の入れ替わりをポジティブなものとして受け入れられるようになります。

私のチームには毎年、新卒採用の方が配属されます。期中に異動してくる人もいます。新しい風を受け、ときには飛躍しときには失敗しながら自分たちなりの
オンボーディング・パターンが形成されてきました。このプロポーザルではそのパターンが形成されていった過程、そしてパターンがもたらす効果について
話したいと考えています。

プロダクトオーナーの仕事は意思決定であると言っても過言ではないかもしれません。
しかし、その意思決定についての体系的な知識や方法論については注目度が低いように感じています。
より良い意思決定ができるのであれば、より良い価値をユーザに届けることもできるのではないでしょうか？

本セッションでは、そんな意思決定の方法論、特に「ディシジョンマネジメント」をプロダクトオーナー支援に活用した事例をご紹介します。

案件選定やプロダクトの戦略を考える際にはもちろん、プロジェクトのリスクの洗い出しにも、開発プロセスにだって意思決定は必要です。
意思決定とは何か、その意思決定という武器をどう現場で使うのかをお伝えできればと思います。

MSDは、これまでも常に患者さんや顧客に対し、サイエンスや革新的な医薬品やワクチンをお届けするために取り組んでいました。しかし、急速に変化する医療環境の中で、さらに患者さんや顧客に最大の価値を提供するために、2020年1月にエンタープライズ・レベルでアジャイル組織を発足して以来、あらゆる場面でもアジャイル目線で物事を進めるように心がけています。

アジャイルの要素は開発、Business Agilityだけでなく、プロジェクトをマネージする際にも効果的な役割を果たすと考えています。弊社では、新型コロナウィルスワクチン職域接種プロジェクトを立ち上げ、この秋に無事に完了しました。その成功の陰には、組織を跨ぐメンバーで発足されたプロジェクト・チーム、それを支えるリーダシップとボランティア社員。そしてアジャイル・マインドセット。

このセッションではプロジェクト・チームが如何にアジャイルの要素を取り入れ、無事に成功させた過程、チャレンジ、そして学びをお話しします。

東京オリンピックの思い出

皆さん東京オリンピックをご覧になりましたか？

日本にとっては歴史的な成績で、金メダルは史上最多の27個、メダルの総数も史上最多の58個でした！ぱちぱちぱち！

そんなオリンピックですが、皆さんはどんな競技が記憶に残りましたか？

私は色んな競技を見ましたが、その中でも特に「すごく素敵！」と思い記憶に残った競技がありました。それはスケートボードです。

何が素敵かって言うと、国境を越えて選手たちが励ましあい、認めあい、喜びあう姿でした！むしろ、国境を越えているのではなく、最初から国なんか意識していないようでした。

私は「日本人に生まれたからには日本人を応援する」と言う固定概念があったことに気付き、もっと違う視点で考えることもできることにハッとしました。

（日本人が活躍したことを喜び盛り上がるのを否定しているわけではないですし、めっちゃ楽しいことだと思います）

さて、オリンピックの思い出の世界から現実の世界へ戻りましょう。

アジャイル開発の現場事例

Scrum Fest や XP祭り に参加し様々な事例を聞いているとアジャイル開発を実施している現場は増え続けており、徐々に普通になってきているようです。

いわゆるイケイケのスタートアップやIT企業だけでなく、歴史のある老舗やハードウェアが絡む製造業といった大企業の事例も増えています。

さらに、最近では1チームでのアジャイル開発だけではなく、大規模なシステムを複数のチームが協働して開発しているところも増えてきています。

さらにさらに、そんな複数チームが何組も在籍している企業も増えてきているようです。

色んな苦労を乗り越え、キラキラした状態に辿り着いた事例には勇気をもらえます！

チームの結束が強くなったその先を予想

アジャイル開発が広まり、イキイキしたチームが増えていると思います。そんなチームを色々な位置から眺めてみようと思います。

1チームでアジャイル開発を始めたチーム

チームメンバー間の関係性に目線を移してみましょう。コミュニケーション頻度は高く、困ったことがあればすぐに協力することができていると思います。プロダクトに目線を移してみると、価値のあるものを開発し、ちょうど良いタイミングでリリースし、利益も上がっていると思います。

ではこのチームと他のチームの関係性に目線を移してみましょう。アジャイル開発を行なっていないチームが隣にあるかもしれません。UIデザインやQAを専門にするチームもあるかもしれません。他のチームと共通で使うインフラやもあるかもしれません。チームを超えたところでどのくらい協力できているでしょうか？

スケールして複数のチームでアジャイル開発を始めたチーム

まずは複数チームになりたての時期に目線を移してみましょう。LeSSや[email protected]などを参考に、自分たちのやり方を検討・決定します。最初は上手くいかないことも多くわちゃわちゃしていましたが、カイゼンを重ね今ではスムーズに仕事が流れる状態になってきました。

ではもうちょっと将来的なところに目線を移してみましょう。チーム間のやり取りもスムーズになり、効率的に作業ができるようになっている一方、チーム間の会話が減っているかもしれません。チーム毎の仕事はうまくできるようになった一方で、他のチームの状態が見えなくなり、チーム全体に効果的な改善活動がやりづらくなっているかもしれません。複数のチーム間でどのくらい協力できているでしょうか？

色んなチームが存在する組織や企業

開発や運用を行うチームはもちろんですが、人事・総務・経理・情シス・営業・マーケティング・経営…様々なチームが存在しています。

新規メンバーの目線で考えてみると、人事や経営と協力しながら採用活動を行い、評価制度を検討することができているでしょうか？

営業やマーケティングと連動して動けているでしょうか？経営戦略に則したビジネスを展開できているでしょうか？

会社内の国境

オリンピックのスケートボードと比較してみると、同じ会社内ですら国境があるように感じます。

社内のチームはそもそも競い合うものではなく協力して目標を達成していく仲間のはずが、無関心な他人であったり、自分の評価を上げるために倒さなければいけない敵のように扱われることもあります。

こんな世界は息苦しく、楽しくなく、逃げ出したくなってしまいます。

そんな貴方にスケートボードワークショップ

私が所属するクリエーションライン株式会社では、そんなに厳しい国境はありません。ただ、チーム毎に向き合っている顧客が違い、その顧客に集中していることもあり、チーム間でのコミュニケーションや共同作業がそこまで多くないかなと思っています。

そこで！社員全員で行うシンプルなワークショップを作りました！

CODE NAME : SKATEBOARD 

ワークショップ名：やれたらやりたかったけど時間がなくてやれなかった事をやってみるワークショップ

ここではいつもは違う仕事をしている人達が共同作業を行い、いつもやっている仕事ではない何かが実施されます。

※まだ一部のメンバー向けに素振りをしている状況で全社員向けには実施できていませんが、10月末に全社員向けに実施する予定です。

　素振りの感想は上々で、実際にワークショップで出たアイデアから新しい取り組みがスタートしている人たちもいるのできっと上手くいくと思います。

実際にやれたらやりたかったけど時間がなくてやれなかった事をやってみた例

• 他社の面白い制度探し（特に採れたて野菜支給制度が良さそう）
• 採用のミスマッチを減らしたい（人事メンバーがエンジニアに仕事の仕方や雰囲気をインタビューして回ることに）
• 人事や総務部門でスクラムを採用している他社事例を読んでみる（海外の事例はドイツ語が難しかったそうです）
• Slackチャンネルが多すぎるのでどうにかしたい（セクションを作って優先順位で並べると良さそうなどのアイデア）
• リモートワークのコツを知りたい（結論：世の中金、良い椅子・ディスプレイ・部屋・土地をゲットしよう）
• oVice（バーチャルオフィス）に常駐する派としない派の意見交換（意見が交換された）
• 犬はなぜ可愛いのか（ただの雑談）

では新しい出会いと新しい何かを生み出す時間の始まりです！

Let's play やれたらやりたかったけど時間がなくてやれなかった事をやってみるワークショップ！

自己組織化したチームとマネジメントはどのように力を合わせることができるか？そのような疑問に対する解答の１つとなるのがJurgen Appeloさんが提案するManagement 3.0である。Management 3.0のモデルは6つの視点で構成されているが、本セッションではポスターを用いて3つの視点を中心に説明する。