How Japan can benefit from this new type of Agile.
How to introduce this new type of agile to hardware, leadership, and not only the software groups.
How to implement this new type of agile in the Japanese business culture and the modern context of Japan.

最新アジャイル手法から、日本はどのような恩恵を受けることができるのか。
そしてソフトウェアグループだけでなく、ハードウェア、リーダーシップへどのように導入するべきか。
また日本のビジネス文化や現代の日本の状況の中でどのように導入するか。

Direct URL:

In highly conservative hardware departments, there often exists a long history and a revered legendary work from the early days that everyone knows. Upon closer examination, it may reveal that Agile development was actually being practiced in that era's environment. To gain a deeper understanding and simultaneously explore how to implement Agile development in our present context, let's analyze the elements of Agile development observed in one of our company's legendary projects, the first-generation Prius, which is considered the precursor to Scrum. We will also consider the approach to Agile development in the modern environment.
とても保守的なハードウェア部門には、長い歴史があり、皆が知っている創業期の神格化された伝説の仕事があるものです。それって、よく見ると当時の環境でアジャイル開発していたのかもしれません。弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスにみるアジャイル開発要素を分析し、理解を深めると同時に、現代の環境でのアジャイル開発の進め方を考察してみます。

Direct URL:

どうも皆さんこんにちは, 鞍馬ぽめると申します
よろしくお願いいたします

ぼくの人生初登壇は DevLove というコミュニティの１５周年イベントでした
当時はぼくの個人発表だったためチームの情報を伏せていたのですが, 中部電力ミライズ（株）さんの中にあるスクラムチーム "コツコツ" のお話でした

スクラムフェス三河が愛知ということで, 今回ありがたいことに "コツコツ" のプロダクトオーナーとスクラムマスターに来ていただけることになりました

ということで本日の主役プロダクトオーナーそしてスクラムマスターのおふたり, ぜひともチーム "コツコツ" がどのようにもがき, そしてどのようにしてそれを乗り越えてきたのかをお二人の生の声で語ってはいただけませんでしょうか

松田）
中部電力ミライズ（株）に所属するスクラムチーム "コツコツ" でプロダクトオーナーを務めさせていただいております, 松田です

土居）
同じくスクラムマスターを務めさせていただいております, 土居です

松田）
私はもともと営業系の部署に在籍していましたが, 一年ほど前にコツコツに配属されプロダクトオーナーに任命されました
それまでアジャイルどころかプロダクト開発に携わることがない部署からの異動だったため, 新米プロダクトオーナーとしてたくさんのつまずきを経験しました
それでも良いプロダクトにするためにいろいろともがいてきましたので, 今日はその活動についてお話できればと思います

土居）
私は新卒からコツコツのスクラムマスターになり, チームが自己組織的に活動できるようになるにはどうしたら良いのかをたくさん考えたくさんもがいてきました
今日私達がお話することで, 少しでも同じようにもがいている方々が勇気を持つきっかけになりますと幸いです

Direct URL:

みなさんご存知の通り、スクラムの基本単位はスクラムチームという小さなチームです。

サイボウズという組織の内外でスクラムマスターとして約8年の試行錯誤を重ね、組織全体をアジャイルにするためには、組織の基本単位をスクラムチームのような自律的な小さなチームにすることが何よりも重要だと考えることになりました。

チームが重要であることはその通りですが、組織を見渡してみると、必ずしもすべてのチームがスクラムを実践しているわけではありません。スクラムを指導したいわけではなく、自律的に活動する小さなチームを作りたいのです。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報は存在しませんでした。

そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践しているチームでもそうでないチームでも参考にすることができる「開発チーム作成ガイド」を公開しました。

開発チーム作成ガイドを公開します - Cybozu Inside Out

本セッションでは、開発チーム作成ガイドにまとめた内容を紹介する形で、機能するチームとはどのようなものか、機能するチームを作るために整えるべき条件とは、条件を踏まえた機能するチームの基本の型などを解説します。

Direct URL:

スクラムガイドにおいてプロダクトは「価値を提供する手段」であると明記(2020年版(日本語) p.12)されていますが、多くの方はソフトウェアもしくは実体のある製品を直感的に想起するのではないでしょうか。
そして、(一般的な意味合いでの)プロダクト開発に携わっていないと、スクラムチームやアジャイルプラクティスは自身の仕事と距離があるもののように感じてしまわないでしょうか。私はそうでした。

私の所属するチームでは、ソフトウェアプロダクトや形のある製品を提供しているわけではありません。さらにいえば、ITや開発に領域を絞っているわけでもありません。

それでありながら、改めてチームの動きを振り返るとアジャイルのエッセンスが含まれるように思えるのです。

例えば、メンバーは戦略策定や営業、マーケティング、データ分析といったそれぞれ異なる強みを持ちながらもプロダクトゴールの達成のためには役割にとらわれないところや、各々が主体性を持って動くことができる文化、計画作りを大切にするが状況に合わせて柔軟に方針を適応させる運用など。

決してアジャイルを企図して導入されたわけでないのに関わらず、アジャイルに近しい運用が多々あります。私はそんな環境に面白みを感じています。

実はスクラムガイドには「プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。」とあります。この但し書きと冒頭紹介した定義を踏まえると、私たちのチームにとってのプロダクトは「投資先のスタートアップの成長に寄与する支援」だとすることができるかもしれません。

本セッションでは、全くバックグラウンドの違うメンバーがどのように協力しているのか、ソフトウェア開発に限らない「汎用的な」アジャイルチームを機能させるために必要な要素は何かを考察してみます。

Direct URL:

ライトウィングとレフトウィング

アジャイルのレフトウィングとライトウィングという表現、あなたは知っていますか？

「アジャイル」と一言で言っても、その言葉の中にはいろいろな要素が入っていて、人によってアジャイルという言葉から何をイメージしているのかが異なります。
チームワークを促進するための取り組みを指して言っているのか？それとも安心安全な開発環境を構築していくことを指して言っているのか？といった具合です。
そこで、もう10年も前になりますが2012年に平鍋さんが「アジャイルのライトウィングとレフトウィング」の絵を公開しました。

アジャイルのライトウィングとレフトウィングの図
出展：https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

• アジャイルのゴールには「ビジネス価値」「顧客満足」「市場価値」がある
• ゴールにボールを持っていくには、大きく分けてアジャイルのライトウィングとアジャイルのレフトウィングがある
• ライトウィングとレフトウィングのどちらか片方だけではアジャイルのゴールに到達できない
• 開発現場をアジャイルにしたいのなら、ライトウィングとレフトウィングを両方満たす必要がある
  
  

このセッションで伝えたいこと

アジャイルのライトウィングとレフトウィングの図を見て、あなたはどう思いましたか？

• チームへのスクラムの適用やふりかえりは積極的に進めているけど、技術的な取り組みはまだできてない
• CI/CD環境の構築やTDDは積極的に進めているのだけど、それを再現性をもって組織に広めていくの難しい
• エンジニアリングの実務経験があまり無いから、CI/CDやTDDってよくわからない

といったように、「両方できているよ！無問題！」という人は意外と少ないのではないでしょうか。

そこで私がこのセッションで皆さんにお伝えしたいのは、アジャイルのライトウィングとレフトウィングをひとりで両方できなくてもいいんじゃない？ということです。
もちろん、ひとりで両方できると素晴らしいのですが、必ずしもひとりで両方できないとアジャイルのゴールにたどり着けないわけではないということです。

もちろん、片方を無視していいわけではありません。
ライトウィングとレフトウィングの両方が揃ってはじめてアジャイルのゴールに向けて歩みが進むわけですから、できない方・詳しくない方を置いてきぼりにするわけにもいかないのです。

このセッションでは、アジャイルのライトウィングとレフトウィングを両方ひとりでできるもん！。。。というわけではぜんぜんないSatoshi Haradaが、とある開発チームにおいてライトウィングとレフトウィングをバランスよく強化していくために何をして誰に協力を求めたのか、その結果開発チームはどのように変化してきたのかをご紹介します。

このセッションを聞いてくださった方には、「アジャイルのライトウィングとレフトウィングをひとりで両方できなくてもいいんだ」という気付きを持ち帰っていただきます。
そして、自分が得意ではないウィングを認めること・知ろうとすることを諦めないこと・得意な人の協力を得ながらアジャイルのゴールに向かって歩みを進めることの重要性をまとめた形式知をセッションでお伝えします。
これらの気づきと形式知を各々の開発チームで実践してもらうことで、アジャイルのゴールに向けて歩き始めるきっかけを作ることができます。

Direct URL:

Direct URL:

私は今でこそスクラムどっぷりでアジャイルコーチなぞをしている身分ですが、その前は20年近く、JTCで社内コンサルをしつつソフトウェア工学の研究をしていました。

今からちょうど20年前、駆け出しの研究者だった私は、ウォーターフォール型開発が抱える大きな問題点をどうやって解決するか悩み、そしてあるとき独自の開発手法として、ある提案を社内にしたのです。
その内容を今見返すと、まさにそれは、プロダクトバックログそのものだったのです――

2000年代初頭、アジャイルはちょうど世間に認知され始めた頃で、しかし国内で適用された事例はとても少なく、多くの企業、特にJTCでは「ウチとは関係ないもの」と思われていました。私もその例に漏れず、自社ではウォーターフォールで開発するのが当たり前だと思い込んでいて、アジャイルに興味はあったものの、XPの本を一冊読んだ程度でした。スクラムに関しては難しくて全く理解できなかったし、理解しようともしませんでした。
そんな私ですら、プロダクトバックログを独自に思いつくに至ったのです。それはつまり、当時のソフトウェア開発にもがき苦しみ、何とか良くしよう、改善しようと考えれば、そうしたアジャイルのプラクティスに辿り着くのは必然だったとも言えるのです。

このセッションで提供するのはある種の考古学です。20年ほど前の、アジャイルやスクラムが出てきた当時のソフトウェア開発の様子を振り返りながら、ある意味アジャイルと対極にいたソフトウェア工学研究者の立場から、アジャイルが生まれてきた必然性をお話します。

Direct URL:

アジャイル開発を実践して継続的に価値を生み出していくためには、組織からの理解や支援が欠かせません。
しかし、
・組織の価値観が変わらないまま、手法だけアジャイル開発になり上手くいかない/苦労する
・アジャイルの価値観を組織に広げたいが、何からやればいいかわからない/上手く伝えられない/理解されない
こういった悩みはありませんか？

私もこういった悩みと戦ってきました。
今でもまだまだ道半ばではありますが、ここ3,4年の間に取り組んできたアプローチを通じて数多くの変化が生まれました。

最初はチーム内の小さな勉強会から始まり、他のプロダクトや組織全体に向けた活動に広げていった結果、
今では、組織からの支援を受けて、組織全体にアジャイル文化の浸透やプラクティスを推進していくミッションを持ったグループの発足にまで至りました。
上位マネージャ層ともフラットに議論ができるようになり、一緒に組織の目指す姿のエレベーターピッチを作り
「アジャイルな文化の浸透」「価値にこだわる」といったキーワードが入るようになりました。
組織からの理解や支援を得られてまさに文化が形成されてきていると感じます。

ここに至るまでに、がむしゃらに取り組んできましたが、
ふりかえってみると書籍「Fearless Change」に紹介されている様々なパターンが力を発揮していたことに気づきました。

このセッションでは、組織にアジャイルを広げるために取り組んできたアプローチ事例の紹介と、
その成功/失敗についてお話しします。そして、書籍「Fearless Change」で紹介されているパターンにもとづき学びを共有します。

組織を変えたい、楽しさをもっと広げたい、そんな熱い思いをお持ちの方の参考になれば幸いです。

Direct URL:

スクラムガイドには、スクラムは「経験主義」(とリーン思考)に基づくと記されています。

私は今まで「経験主義」という言葉に甘えて、初期のスプリントの失敗は仕方なくそこからチームは多くの学びを得れば良いよねと考えていました。
なんなら失敗した方がチームの気づきが増えるので失敗を推奨してましたし、チームメンバやステークホルダにもそのように伝えていました。

ただ、今のチームで私の意図したところもしてないところも含めて幾つかの良い要素が重なりプロダクト開発はスタートダッシュ（本セッションでは初期のスプリントでステークホルダの期待を超える早さでインクリメントを提供することと定義します）に成功したのですが、その後に起こった出来事が興味深いものでした。

スタートダッシュに成功したことでチームに起きた出来事をお話しします。

① チーム外に起こった出来事
　スタートダッシュにより受託元ステークホルダのチームへの信頼感が大幅Up！チームの活動に対し協力的に
② ①によってチームメンバに起こった出来事　
③ ①によって成果物に対して起こった出来事

特に受託アジャイルにおいては、受託元のステークホルダは、スクラムそのものや、受託先(会社・チーム）への信頼感がない状態でのスタートとなるので、①の効果が非常に大きいと感じたためタイトルにも受託アジャイルと付けています。

私のこれまでの考え方だとチームの成長は早くなるかもしれないけど、顧客に提供する価値という点では、フィードバックを繰り返さねばらなず、プロダクトの成功率を低くしていたんだろうなと気付かされたので、その辺りを皆さんに伝えられればと思います。

このセッションでは、実際にスタートダッシュを成功させるためのノウハウをお話しするものではありません。(成功率を高めるためにこんな取り組み始めましたって話題をちょっとするくらいです)
スタートダッシュを成功するメリットとその要因をお伝えし、チーム立上げ時に何を優先すべきかを考える助けとなるヒントを提供します。

Direct URL:

セッション概要

本セッションでは、自分が2年間パーソナルコーチングを受けた結果得られた自分自身の「サボタージュ」との向き合い方をお伝えすることで、聴講者が本心からやりたいはずなのになかなかできていないことに着手できるようなセッションを目指します。

セッション詳細

最初に、サボタージュに対しての理解を最低限揃えることを目的に、サボタージュとは何かを共有します。
サボタージュの定義はもちろん、いくつか具体的なサボタージュの事例を紹介することで、「サボタージュは絶対に悪いものである」をはじめとした言葉から持たれやすい勘違いの解消を目指します。

次に、サボタージュに向き合うことで何が得られるのかをお話します。サボタージュに向き合い、サボタージュを活用することが本心からやりたいはずなのになかなかできていないことに着手する一歩になることを説明します。

最後に、サボタージュと向き合う具体的な方法の一例として、自分自身がサボタージュと向き合うために行っているステップを紹介します。
具体的には、「自身のサボタージュを探る」ステップと「自身のサボタージュと付き合う」ステップに分け、それぞれでどのようなことをしているのかを紹介します。

Direct URL:

話したい事

自分の現状について誰かに相談をするにも、何かをChatGPTで壁打ちするにも、まずは自分の課題をしっかり整理して、正しく伝える事が出来なければ始まりません。

現状も思いもイマイチ伝えられない自分と比べ、登壇の中で自身の経験を丁寧に整理して話をしている方や、ちょっとした雑談でも人の話を紐解いて深く対話をしている方々を目の当たりにして、何が違うんだろうと考えました。

華々しい結果や成果の話ではありませんが、自分の考えを常に言語化しておくこと、またチーム・組織・顧客それぞれと共に何をどう言語化していくのがいいかなどなど、「言語化すること」について考えたこと、方法、実践して起きた変化をお話します。

Direct URL:

Direct URL:

先日、とある記事を書きました。
(記事はとっても良い意味でたくさんのレビューと共に、
多くの方に読みやすい内容に仕上げていただきました。)

自分自身が製造業にいた十数年間で、
日本が変わっていく様を目の当たりにしていました。
最下部の図は国内家電メーカー事情をわかりやすく表していると思います。

ちょうど自分が見てきた製造業での景色は

• 仕様通り
• 納期通り
• テストも社内レビューもOK

当たり前のことを当たり前にこなして、
いざリリースしても
「思ってたのと違う」と言われ続ける開発ばかりでした。

本セッションでは
自分が結果的にアジャイルに惹かれる背景にもなった
当時見てきた私目線での製造業の功罪を語りつつ、
記事に書ききれなかったことをお伝えした上で、
まだアジャイルへの取り組みに踏み込みきれていない現場が
前向きな一歩を一緒に踏みだせるような、
そんな想いを込めてお話しできたらと思います。

いくつかの景色

日本の電機業界を見ていて、2000年〜2010年の間、大きな変化があったと感じています。1インチ1万円だった液晶テレビの価格が3分の1程度になったり、日本メーカーだらけの携帯電話業界にiPhoneが飛び込んできたり。
さらに10年が経つと、Androidが搭載されたテレビやチューナーレスのテレビが登場しますし、携帯電話はスマートフォン一色になり、インターネット上でスポーツ観戦をリアルタイムでできるのが当たり前となりました。

「思っていたものと違う」と言われていたのも、まさに上記の間のお話でした。何が起こっていたのでしょうか。

日本製品の品質に対する誇り

他国の製品は安いがすぐに壊れる。これではお客様は買ってくれない。だから私たちは品質を大事にし続けよう。このように、自分達の魅力として掲げ続けていたと感じていました。
一方で、2010年以降に国内外で品質に関する不正が相次いだのも心に残っています。いかに社会的な品質を満たすことが大変になったか。世界一の品質を保証し続けることが大変になったのか、世の中の変化を感じる出来事でした。

ベンチマーク思考

他社に搭載されている機能にマルがつけられないと、お客様が買ってくれない、という考え方でした。「競合他社と並ぶために、他社と同じ機能を開発しよう。その上で、付加価値をつけて自社にしかない魅力を出そう。」と、号令がかかるようになります。
その裏側で、国外製品が自社や国内製品よりも機能がたくさん搭載されているものが安価で手に入るようになっていました。すると、いつの間にかベンチマークが自社では追いつかなくなってしまいます。

顧客の見えない開発

社内のレビューや上司からのフィードバックに対応することに終始していましたが、顧客となるユーザーさんは納品する企業のそのまた先でした。仕様とユーザーさんの期待する製品にギャップがあったとしても、それに開発する人が気付くことが難しかった状態でしたし、その状況に気付いていても、直接ユーザーさんと交流ができるのは、不具合対応で現地に伺った時だけでした。

ーーーーーーーーーーーーー

ここで一つ、大きな変化があります。
2000年から2020年にかけて、テレビも携帯電話（スマートフォン）も、国内メーカーのシェアが下がり、国外メーカー中心の市場になったことです。

製品の価格が下がって起きたこと

機能が豊富な製品が十分な品質で販売価格も低価格。国内メーカーのシェア低下の裏側にあった事実だと私は考えています。この過渡期で何が起きていたのでしょうか。

開発予算の減少

開発した製品に対して、投資した予算以上に利益を出さなければ、企業は赤字になってしまいます。製品の価格が下がると、投資する金額を少なくするか、これまで以上に大量に販売しないと企業が存続できなくなるロジックが、簡単に成り立ちます。
また、同様に「短納期」というキーワードが聞こえてくるようになります。開発期間が短くなれば投資する予算も少なくなります。それに加え、市場に対して素早いリリースは競争力を高めることは多くの方が感じているようでした。一方で、手戻りを避けようとするあまり試作前に石橋を叩くようになりますが、作ってみてから学ぶ回数が減っている現場を目の当たりにしていました。その結果、これは開発予算が減少する前から起きていたことかもしれませんが、期待した品質が得られなかったり、土壇場で手作業したりと、コストや期間に影響する追加作業がプロジェクト後期に遭遇することとなります。

海外メーカーの買収やOEM(Original Equipment Manufacturer)

豊富な機能で低価格な製品を作れる企業が増えてきた頃、海外のトップシェアメーカーを買収により傘下に入れたり、他社が開発した製品を自社ブランドとして販売するOEMをするメーカーが現れてきました。企業の競争力を取り戻すための投資が社外に向けて行われました。
自社ブランドとして販売するためには品質も重要でした。既に市場に投入されている製品に対して、追加の評価や修正依頼を実施してリリースされた製品もありました。自分たちで開発する能力は身につかないまま、追加作業のやりとりでリリースされないまま1年が経過した頃、流通や企業戦略の都合に伴い、OEMメーカー側から性能に直結する部品の変更や、次機種のリリースに伴う製造終了のお知らせが届いたりもしました。

内製化能力の低下

何度も作ってはリリースを繰り返す挑戦をしたメーカー社外(国外)に現れた結果、社内では市場についていくことが出来なくなり、社内に投資することも出来なくなり、製品を開発する経験や、魅力ある製品を生み出す能力が失われてしまったように見えました。これは技術力のみでもたらされたのではなく、ビジネスや企業戦略としての意思決定が伴って陥った状況だったと考える方が自然だと考えています。

Direct URL:

本セッションではチームで合宿を実施することに対して、合宿の効果や実際の事例を基にした合宿を企画・実施するまでのノウハウを紹介します。チームビルディングの一手として参考になれば幸いです。

合宿をしなさい

合宿をし、一緒に飯を食い、泊まって徹底的に話をする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いまでたどり着けるだろう。そこから始めて、一つの共通理解が生み出される。この過程をみんなで踏みなさい

「アジャイル開発とスクラムより」　平鍋健児　野中郁次郎

野中先生も合宿の重要性についてこう話しています。

今回は私が会社で企画・実施した２つの合宿の事例を基に、１泊２日の「合宿の効果」や実際に実施した「合宿のコンテンツ」を紹介します。

1.合宿の効果

　・お互いの関心の醸成が得られる
　（合宿後にやって感動したと意見が出た）

2.合宿の印象をアンケートで聞いてみた

　・合宿参加前後の印象について
　　(合宿実施前には合宿の良さはなかなか伝わらない)

3.今回紹介の事例の組織

　1.　40人程度の組織のチームリーダー層7人で組織のバックログを洗い出す
　2.　300人程度の事業部リーダー層7人でミッションを検討する

4.合宿の準備

　1.メンバーと日時の決定：現地実施を基本とするもオンラインを切り捨てない
　2.場所の決定：Airbnb等空間占有出来ることがお勧め
　3.しおりの作成：しおりで合宿のノリをだす
　4.必要な持ち物：模造紙、マスキングテープ、強粘着の付箋　等

5.合宿の実施

　1.初日の飲み会が勝負ポイント
　　・自己開示のワークショップをやろう

　　　ー偏愛マップ、ドラッカー風エクササイズ、ムービングモチベーターズ等
　　　ーお勧めはドラッカー風エクササイズB面
　2.アジェンダは気にしない
　3.ゴール感を合わせるためにお勧めのワークショップ
　　・サクセスファクター
　　・From-Toキャンバス
　　・ラディカルプロダクトビジョン

6.○○が終わるまでは合宿です
　1.合宿終わりに一言ずつ話そう
　2.実は合宿では何一つ進んでいない。
　　日常に戻ってからのスピードに違いが出るので、違いが出るまで合宿は終わらせない

参考資料.合宿のしおり_ひな型

Direct URL:

製造業の強い愛知、そしてトラディショナルな企業が多い愛知。

そんな愛知で育ち、ガチガチな製造業プロセスの中でソフトウェア開発を行ってきました。

もし別の世界線があるのであれば、今もアジャイルを知らず、20年間以上変わらないプロセスで開発し続けていたかもしれません。

しかし私はその世界線にはいません。なぜならば、そんな環境の中でアジャイルを知ることができ、チーム開発を身をもって体験することでチームのすばらしさを知ることが出来たからです。

製造業時代で出会ったアジャイルとチームのすばらしさ

当時は自動車関係の子会社で、カーナビ向け地図を制作する社内SEとして地図製作システム開発に従事していました。

ソフトウェア開発プロセスは製造業の流れに沿ったガチガチのストロングスタイル。

どうすれば、増え続ける膨大な地図コンテンツを高速に扱い、そして次回のシステム刷新まで耐えられるシステムにするかを常に追求する日々でした。

そしてユーザー企業の社内SEは非常に狭い世界で生きています。自社のドメインを扱えれば良いので、無理に変わる必要がないからです。

当然、今どきの開発とはかけ離れた開発となります。

そんな自分にある転機が訪れます。アジャイルに出会ったのです。

そのころ、上層部から今までの殻を破るような次世代の地図編集システムを作れと無茶ぶりでプロダクト責任者に任命されます。

システムリプレースではなく、全く新規で今までの殻を破るシステム、一体何を作れば…途方にくれました。

そんな時、当時の後輩がアジャイルを知り、Scrum Boot Campから興奮して帰ってきました。そしてこんな無茶ぶりなシステムこそアジャイルなのではと。

2015年、初のアジャイルは、DAD(Disciplined Agile Delivery)でオフショアを含めた3チームで始まりました。

今考えると無謀でしかないです。製造業の世界しか知らない私たちの初めてのアジャイルが、複数チームそしてスクラムではなくDAD。さらにオフショアメンバーも居る状態です。

付き合いのあるベンダーもアジャイルに強いわけではない。1枚の写真にしたら情報量が多くパニックを起こしそうですが、実際めちゃくちゃ苦労しました。

苦労しましたが、2年後には自分の中で成功体験となったチーム達が出来上がっていました。

チーム開発の楽しさを知った私は、もっと開発に寄り添いたいと思いを馳せます。

最高のチームを求めてOver40でユーザー企業からベンダー企業へフィールドチェンジ

既に40才を超えていましたが、ユーザー企業からベンダー企業への転職を決意します。最高のチームを求めて。

そこで出会ってしまいました。きょんさん達の基盤チームと呼ばれる "最強" のチームです。

半年という短い期間でしたが、一緒に仕事をさせてもらうと分かる技術力の高さと営業含めて自律して動けるチーム。本当の意味でのフルスタックと感じたチームでした。

ここでの体験は今後の私に大きな影響を与えました。基盤チームは既に活動しているチーム。自分の手で1から基盤チームのような最強なチームを作ってみたいと感じるようになりました。

三河でアジャイルなチームを作り続ける難しさ

そして、現職のIIJ名古屋支社のアジャイルな取り組みに感銘を受けて転職します。

ここでは、開発ベンダーでありながら安定したアジャイルチームを運営して全員が幸せになれるように日々奮闘しています。

しかし、開発ベンダーでチームを維持し、お客様の期待に応えるチームを作っていくのは非常に困難です。

製造業が強い愛知、エンジニアのスキルセットもゴリゴリの業務アプリケーションに沿った方が多いです。

さらに、人の入れ替わりが当たり前に起きるベンダーでは安定したアジャイルチームを作るのは難しいです。

しかし不可能ではありません。三河でアジャイルなチームを作っていく知見を貯めながら今日も奮闘しています。

製造業が強いこの地でもアジャイルチームが作れる

アジャイルに出会った2015年から8年。この愛知で様々なチームを見て、様々なチーム作りをしてきました。

本音を言うと製造業が強いこの地でアジャイルチームを作るにはいろいろ課題があります。

キラキラしたIT業界のスキルセットとは違い、泥臭いスキルセットが多い名古屋。しかしアジャイルを知り丁寧に導くと、驚くほど生き生きしスキルを習得してチームにフィットしていきます。

この8年で見てきた現場から、幾つかのチームにフォーカスを当てて、製造業が強い愛知でのチーム作りについてお話したい思います。

今回は今までの発表とは異なり、メッセージ性が強い内容ではないです。

私の地元愛知でのチーム作りに対する想いから、アジャイルに躊躇している方や、誰かに背中を押してほしいと思っている方に勇気を与えることが出来ればと思っています。

Direct URL:

フリーライダー：《ただ乗りする人の意》不労所得者。必要なコストを負担せず利益だけを受ける人。（goo辞書より引用）

チームでアプリ開発を行う授業において、「プログラミングつよつよ」「知見広すぎつよつよ」「デザインセンスつよつよ」というすごい3人に囲まれた「無わたし」。（つよつよ＝スキル、センスがありすぎる人（当社比））

武器を持っていない私の脳内には、「自分には何もできないのではないか？」「自分がいなくても組織は回っていくのではないか？」「なんなら自分がいない方がいいんじゃないかな、」という思いが何回もよぎりました。

しかし、そんなことはなかった！　わたしにしかできないことがたくさんあったのです。

本セッションでは、プログラミングや開発経験、デザインのセンス、スキル皆無、初心者である私が、

チームとして上手く機能するためにはどうしたら良いかについて考え、感じたことを自由気ままにお話しします。

Direct URL:

はじめに

初めてアジャイル開発に触れて、失敗したり、模索したり、衝突したりしながらチームとして初めてのリリースをする駆け出しスクラムマスターの物語です。

断っておきますが、スクラム理論云々を語れるわけではないし、サクセスストーリーでもありません。

もしかしたらほとんどの人には全く参考にならないかもしれません。

なお、情熱はある。

なかみ

2022年10月、転職を機にプロダクト開発をアジャイルな状態へ持って行くために、やったことないアジャイル開発をすることになりました。

守破離の守すらやらずに、「自分たちの最強のアジャイル開発」を目論んで実践すること3ヶ月。

様々な苦労を経て「いや、やっぱ守やろうぜ」ということになり、チームはスクラムを始めます。

しかし、事はそう素直に運ばれてはくれない。

• わたし「みんな、このミーティングってしゃべりづらい？」
• わたし「みんなに勝手に期待していた、ごめん」
• わたし「すいません、ぶっちゃけ忖度していました」
• わたし「我々は足かせになってはいけない」
• わたし「みんなでスクラムガイドよもーよ」
• わたし「1週間スプリントの方が良くないかな？」
• わたし「自分はプロダクトオーナーなのか？スクラムマスターなのか？」
• わたし「プロダクトの価値は何なんだろうか」
• わたし「とりあえず1回タイムボックス死守で」
• わたし「パッションってなんで湧き上がるんだろうか」
• わたし「クソな話か、良いねぇ！」

まだまだ駆け出しスクラムマスターが情熱をもってチームやプロダクトに向かう、道半ばな物語です。

※現在進行形なので、新しい言葉が出てくる可能性もあります。

Direct URL:

Direct URL:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 「_ _ _ _ _ _ _ _ _ 、_ _ _ _ _ _ _ _ _ _ _ _ _ 、_ _ _ _ _ _ _ _ _ _ _ _ 」_ _ _ _ _ _ _ _ _ _ ？

参考 : 【0文字クイズ】クイズ王、文字がなくても正解できる説

みなさんはどれくらいアジャイルリーダー、リーダーシップを知っているのか？すっとその知識を出せるのか？不安になったり、どうやって成長すればいいのか悩んだりしたことがあるかと思います。

資格取得、読書、ワークショップ、業務での取り組みさまざまなものがありますが、その中でもライトに取り組めるのがクイズです。今回はみなさんにアジャイルリーダーのクイズを出してその知識や引き出し方を確認してもらえればと思います。

当日は10問前後からなる問題をだしてDiscordで最も早く回答してくださった方を勝者とします。また誤答によるペナルティはありません。

Direct URL:

Direct URL:

僕だけじゃない。
誰にでもある自分自身の弱い部分。
見ないようにしても嫌と言うほど突きつけられる。

世の中で強そうな人は言う。
準備をしたら大丈夫、習慣にしたら大丈夫。
訓練したら大丈夫。努力したら大丈夫。
わかるよ。
あなた達はそうやって結果が出したんだよね。
結果を出せない人の身にもなってよ。
毎日足掻いても、全然変わらないじゃないか！

でも、それは真実じゃない。
僕は何度もチームと成長できている。
もしかしたら、チームが成長して僕は成長していないかも知れない。
それでも、一緒に進んで幾つかの成果を出してきた。
でも虚空のようだ。キャリアも成果も僕の物じゃない。

このプロポーザルを出すまでに何も浮かばない。
飾る気力もない、演じる熱もない。
それでも、それだからこそ絞り出した何かに
誰かの役に立つことはあるかも。
そう願いたいだけかも知れない。
自分自身に期待をしたいだけかも知れない。

そんな中、今回は周囲の人と一緒に進む中で見えてきた何かを
とりとめもなく話してみようと思う。

僕にチャンスをくれた世界に恩返しできるなんて思えないけど
僕にとって失敗が許されると感じることができた世界を守るために
僕は今回も失敗をしに行こうと思う。

Direct URL:

みなさん、こんにちは！私たちの「チャレンジャー募集！やる気スイッチワークショップ」に興味を持ってくれてありがとうございます！このワークショップは現地参加者限定の体験ワークショップとなります。

私たちは、アジャイルの世界でチームワークを強化するManagement3.0のライセンスファシリテーター、”ステファン”と”なお”です！このワークショップでは、やる気スイッチをONにする「ふりかえり」に焦点を当て、チームの成長を後押しします。

「ふりかえりはしているけど、やる気につながるアクションに繋げられない」という悩みをよく耳にします。しかし、そんな課題に立ち向かう解決策があります！

このセッションでは、自分と相手のやる気スイッチを見つけ、お互いにスイッチを入れるためのヒントを共有します。直接対面で交流しながら、皆さんと共に学び成長する貴重な機会です。

さあ、一緒に刺激的な時間を過ごしましょう！やる気スイッチをONにして、Management3.0の世界に飛び込んでください！心躍るプレゼン、体験豊かなアクティビティ、そして有意義なコミュニケーションを通じて、新たなスキルとモチベーションを手に入れましょう。

お会いできることを楽しみにしています！

Direct URL:

採用に悩めるマネージャーとリクルーターに捧ぐ

部門マネージャー「採用担当が全然いい人を連れてきてくれなくて、採用が進まない」

採用担当「たくさんレジメを送っているのに、書類選考が通らない」

ちょっとそこのマネージャーさん、採用担当さん！聞いてください。まずはマネージャーさんに伺いますが、

• 採用活動は人事採用担当だけの仕事だと思っていませんか？
• 採用活動を、書類選考と面接をする作業だと思っていませんか？
• 採用担当に任せられるのは、せいぜい採用管理ツールの操作と、求人票の媒体掲載くらいだと思っていませんか？

次に採用担当さんに伺います。

• ハイヤリングマネージャーと、どのくらい頻繁に会話してますか？
• 目の前の求人についてだけでなく、組織課題や未来のあるべき組織図についても、話したりしていますか？
• 採用活動をより良くするために、ハイヤリングマネージャーに次々と「提案」ができていますか？

特に日本においては、採用活動は人事採用部門に丸投げされるケースが往々にしてあり、募集部門と人事採用部門が一体となれていないケースが多く見受けられます。ひどいケースでは、まるで発注者と下請けのような関係性になってしまっているような話も聞いたことがあります。特に人材獲得が難しいとされるエンジニア採用においては、そのような状況ではとても、採用を成功させることは難しいでしょう。

本セッションは、QA部長と採用担当が、採用成功に向けてタッグをくみ（二人の間ではよく「スクラム採用」と言っています）、それぞれの得意分野で力を合わせてコラボレーションをすることで、中途採用でも新卒採用でも満足いく結果を残すことができた、そのプロセスや実践、考え方を紹介します。

ハイアリングマネージャーと採用担当は、共に学び合うことができる

私たちが一番伝えたいメッセージはこれです。

つながり続けることの価値

また、本セッションは仲間集めを題材にしながらも、コミュニティ活動のキャリアにおける重要性についても話を膨らませたいと思っています。QA部長である「じゅんぺー」こと伊藤は、長らくコミュニティ活動の運営や、自身も登壇するなど、積極的につながり続けることを実践しています。

コミュニティ活動では、社内外の人々と、フラットな関係性のもと、良き場づくりを目指して協働していく中で、様々な形で、思いがけないご縁や助け合い、新しい出会いにつながることがありました。その経験を社内の採用担当である「けんさん」こと南に話したところ、

けんさん「それって、社会関係資本っていうキャリア論の概念と近いかもですねー！」

という話になり、一通り話が盛り上がった末に、１つの仮説にたどり着きました。

じゅんぺー／けんさん「コミュニティ活動って、キャリアじゃね？」

セッションでは、コミュニティ活動とキャリアの関係性についても考える中で、コミュニティ活動を日々頑張っている方々にとって、「大変なこともあるけれど、楽しみながら頑張り続けよう」と思っていただけるようなお話ができればと思っています。

仲間集めに大切なことを、2つの "Ties" として考える

ここまでのお話を、

• ハイアリングマネージャーと採用担当の絆＝strong ties
• コミュニティ活動でゆるくつながり続けることの重要性＝weak ties

として整理し、人材獲得難時代の仲間集めについて、語ります！

Direct URL:

スクラムでもなんでも、一緒に働く仲間と関係性が悪いとうまくいかない

これは人間関係を軽視していた結果一緒に働く仲間から避けられていたマネージャーが、アジャイルに向き合うことで、慕われるようになるまでの奮闘記です。

元々はスクラムチームが取り組んでいるプロダクト（およびプロジェクト）のマネージャーだった私は、メンバーとの関係性を軽視した状態でプロジェクト推進を優先し続けた結果、スクラムマスターによってスクラムセレモニーから追い出されてしまいました...。

自分は良かれと思ってチームに関わっていましたが、むしろ私がいることでチーム内のコミュニケーションや意思決定が効果的・効率的になっておらず、ある意味自分がボトルネックになっていたようでした。

このままではいけないと思い、人との話し方やチームが大切にしているアジャイル、スクラムについて改めて学び直していったところ、チームが自己組織化することが重要と知りました。

またアジャイルソフトウェア開発宣言に記載の "Individuals and interactions"が 「個人と対話」と訳されていることを自分なりに解釈しなおし、うまく「対話」することで関係性やコミュニケーション問題が改善し、より効率的に成果が生み出せると考え始めました。

この「対話」をするために、まず自分の考え・言動の癖を認知バイアスを絡めて捉え直し、都度「自覚」「捉え直し」「改善」を繰り返していき、ある時からチームや関係する方々から雑談・相談を持ちかけられるようになったりと、徐々に慕われてきたと実感するようになりました。

またチームだけでなく他事業部の方からも「とりあえずなんか困ったら相談する相手」というなんともマネージャー冥利に尽きる称号を得ることもできましたw

ここに至るまでの奮闘記を「嫌われ期」「気づ期」「改善期」に分けてお伝えできればと思います。

このセッションを通して、同じようにスクラムチーム外のマネージャーでも、良い関係を保ちつつ成果を最大化したい方の後押しになればと思います。

Direct URL:

本セッションで伝えたいこと

• 新しいことに取り組みたいならコミュニティで相談しよう！
• 現在進行形のことは自分を語り、先人たちからの問いかけに答えよう！
• 問いかけの末導き出した次の一歩を踏み出し、業務の質を向上しよう

と言うことで、皆さん、コミュニティ、参加してますか？

2022年のスクラムフェス大阪に参加したことを皮切りにコミュニティへの参加を始め、1年が経過しました。
たくさんのカンファレンス、コミュニティに参加してきました。

社外で得られた知見を組織に持って帰り、有効活用してこそ、その価値を得られます。

そこで、本セッションではコミュニティ活動と組織での取り組みに結びつけた話を語りたいと思います。
それぞれの活動が組織にどんな影響をもたらすのか、どんな取り組み方がより高い効果を得られるか、学びを得られるセッションにしたいと思います。

今回このテーマで語りたいと思ったきっかけ

スクフェス新潟2023・スクフェス大阪2023と「プロポーザルを出す」と言うテーマでことねさんが登壇されました。
この登壇を経て、プロポーザルを出し、プロポーザルYY会に参加する方が爆増すると言う様子を見てきました。

一方で私はコミュニティに対して、どんな貢献ができているのか、と考えた時、自らは受け取る立場になることが多く、コミュニティの活性化のための活動を十分にできていないのではないかと思いました。

そんな中、私の経験を思い返すと、アジャイルコーチに稚拙な質問をしては、それに対して夜中まで真摯に向き合ってくれる経験値の高い人たちとの会話から得られた知見を業務に活かせていると言う実感がありました。

このような経験を語ることで、ことねさんがコミュニティに貢献しているような貢献を私もできるのでは無いかと思い、本テーマで語ることを決めました。

「アジャイルコーチ達の問いかけを自ら受けに行く」と言うコミュニティの活用戦略

私自身、コミュニティで何かを質問するということはとても怖いことです。自分の学びの浅さ、経験の浅さが露呈することがたくさんあります。
時には「こいつアホなんじゃないか」と思われる不安に駆られながら質問していることもあります。

しかし、そんな中、自分の悩みを打ち明け、相談することによって得られた学びがたくさんあります。

私は「アジャイルコーチ達の厳しい問いかけを自ら受けに行く」経験を経ることによって自身の業務に価値を生み出すことができていると思っています。

そういったコミュニティの活用方法について、私自身の経験に基づいてお話したいと思っていました・・・。

しかし。。。。

「アジャイルコーチ達の厳しい問いかけを自ら受けに行く」と言うコミュニティの活用戦略の誤りに気づく

資料作成する中で、自分の認識が私自身の偏った認識であることに気づきました。
そして、その認識を改めるべく、アジャイルコーチ達にアンケートを取りました。

そして見えてきた私のコミュニティへの認識とアジャイルコーチ達のコミュニティへの認識の違い。

見えてきたコミュニティ活用の真実。プロポーザル提出時点では見えて来なかった話をお話をさせていただきたいと思います。

Direct URL:

最近『チーム転職』という言葉も目新しくなくなってきました。一人で転職するより「チームごと」転職したほうがパフォーマンスが維持されるという研究結果もあるそうです。（『Chasing Stars: The Myth of Talent and the Portability of Performance』より）

しかしながら日本国内で言えばまだまだ事例は少なく、みなさんが見聞きするチーム転職成功事例も界隈で有名な人達のキラキラとしたものがほとんどではないでしょうか？

そんな中で有名でもなくキラキラもしてない人物たちが、チーム転職活動なるものを実際にしてみた実体験・そしてそこから手に入れたものをお話したいと思います。

これは経験・知識の共有かもしれませんし、ただの私小説かもしれません。

Direct URL:

スクラムマスターは、スクラムチームを様々な形で支援していますね。

そして、スクラムを導入し効果的に活動できるよう支援・指導を行い、尚且つメンバーのコーチでもあるのです。

そうです！スクラムマスターのみなさんは、多くの役割を担いながら

• スクラムというゲームのルールをよりよく学べる場
• 開発者が自らの能力を十分に発揮できる場

このような場を提供しながら、メンバーと共に自立管理型のチームを形成し、目指すゴールに向かって進むことを支援するコーチでもあるのです。

さて、みなさんは、コーチとしてどのようなことを意識して活動されていますか？

そもそも、コーチとは何でしょうか？

スポーツで言うコーチ、最近では企業内でもコーチングというワードが出てきていますよね。そして、コーチングの基礎研修としてさまざまな研修も存在していて、「傾聴する」とか「質問をする」ことがコーチだという声もありますね。

スクラムマスターとしては、メンバー全員がイキイキと働けるチームだったら素敵ですよね。

様々な人が集まるスクラムチームで、より早く求心力のあるチームになるためのコーチになれたらいかがですか？

メンバー ひとりひとりの能力を引き出しながら、イキイキと働くチームになっていくための支援をするためのコーチング。

今回は、チーム形成を加速化するためのヒントとなるコーチングの考え方のレクチャーに加え、みなさんそれぞれ自分自身を再認識するための簡単なワークをいたします。

ぜひこの機会に、コーチングについて学んでみませんか。

注意！

• 当ワークショップは会場を中心に行いますが、リモート向けも予定しております。
• 座席数に限りが有る予定です。

Direct URL:

Direct URL:

こんにちは、皆様！

私は個人事業主として、数年にわたり様々なアジャイル開発のプロジェクトに携わってきました。エンジニアから始まり、スクラムマスター、アジャイルコーチなど役割は案件に寄れど、日々、アジャイルの探求、鍛錬を続けています。

そのなかでも、私が初めてスクラムマスターとして参加したプロジェクトは忘れられないものでした。

初めてのスクラムマスターとしてその任務に飛び込んだ私を待ち構えていたのは、予想を超える厳しい現実でした。

スクラム未経験者ばかりのメンバー、新たな技術に対する困難、そして納期厳守という圧力。それらはチームを次第に追い詰めていきました。

そして時間が経つにつれ、MTGの多さやメンバーの対立が増し、残業が増加、顧客の信頼を失うという危機に直面することとなりました。

その時、私は自問しました。「この状況では、スクラムをやめた方が良いのではないか」と。

その後は、緩やかにスクラムのフレームワークから離れていき、ミニウォーターフォールに近いような開発にシフトしていきました。

このセッションでは、その時々の状況や心情を赤裸々に語りながら、初めてスクラムマスターとしてどのように振る舞い、何を学んだか、そんな私の経験を共有したいと思います。

また、アジャイルコーチとなった今、当時の自分やチームに対してどうアドバイスをすればうまくいっていたか、スクラムマスターとしての自分の振る舞いのどこに改善すべき点があったかもお話しできればと思います。

私の経験が、皆さんのスクラムやアジャイルに対する理解や実践の一助となれば幸いです。どうぞ、よろしくお願いいたします。

Direct URL:

こんにちは世界

私は、スクラムチームのテスターとして、開発の現場に取り組んでいます。

突然ですが、皆さん、テスターに​​どんなイメージを持っていますか。

• テストする人
• 自動テストを作る人
• 製品の品質を考える人

それぞれ、イメージがあると思います。

いまだに、私は、テスターがなんなのか、まだよくわかっていません。

ちなみに、私はプロダクト開発でテスターとして働いています。

今回は、テスターに​​ついて絶賛まよい中の私が、テスターとは何かという話をしたいと思います。

現時点（2023夏）では、プロダクト品質とプロセス品質をいい感じする人だと思いますが、これから仕事をする中で、内容は変わるかもしれませんので、悪しからず。

Direct URL:

by 関将俊、深谷美和、米澤慎

栃木の基調講演に誘われました！

今回はSQiP2023の再演を軸にしたパネルディスカッションをやります！30分の再演パートと60分のパネルパートで構成します。

SQiP2023の概要：

反復開発やテスト駆動開発を基礎としたアジャイル開発は世界中で広く普及している。その一方で、アジャイル開発の個々のプラクティスはうまくできているのに、製品開発がうまくいかないといったケースも見受けられる。うまくいかないチームの様子を聞いてみると、基礎となる反復開発の実践に問題があるように感じた。

私たちのチームは製造業でミッションクリティカルな領域のソフトウェアをエクストリームプログラミングで開発している。私たちの20年以上にわたるアジャイル開発の豊富な経験から、反復開発をうまくやる方法を伝えたい。本発表では、反復開発に適したプラクティス「忍者式テスト」を説明し、ストーリーを計画するテクニックや製品を磨く様子やチーム内のロールなど、忍者式テストを中心とした私たちのさまざまな活動について説明する。

Direct URL:

本セッションでは、ユーザーからのフィードバックをもとに、プロジェクトメンバー全員で「ユーザーにとって分かりやすいUI」を追求し改善した話を紹介します。

ご紹介するプロジェクトの事例、実際の効果、チームがぶちあった壁やどう乗り越えたのか？という話を通して、UI改善活動の参考になれば幸いです。

「ユーザーにとって分かりやすいUIとは？」

「ユーザーが抱えている課題に対して一番効果があるUIとは？」

という議論は、サービス開発においてよく出てくる話かと思います。

この問いに対して、自信をもって「絶対にこのUIが一番だ！」と解が出る人はいるでしょうか。

私自身はデザインのプロではないですし、ユーザーの生活や業務を365日24時間張り付いてい見ているわけではないので、解は持っていません。

とはいえサービス開発においては、ユーザーにとってより分かりやすく、ユーザーの課題をより効果的に解決する必要があるので、この問いは常に考えなければいけません。

私はとあるプロジェクトを通して、ユーザーにとって分かりやすく効果的なUIが何かは、

実際にユーザーにぶつけてみないと分からない

という結論に至りました。

そのためには、

できるだけ小さい単位で、

できるだけ早くリリースし、

ユーザーにぶつけて効果を検証し、

改善していくサイクルが重要である

ということに気づきました。

今回の登壇では、この結論に至るきっかけとなったプロジェクトの話をしたいと思います。

このプロジェクトでは、リリースしたサービスをユーザーに業務の中で操作してもらい、そのフィードバックを参考にプロジェクトメンバー（デザイナー、エンジニア、ビジネスメンバー、プロデューサー）全員でサービスをUIを改善し、分かりやすいUIを追求しました。

■私の経歴とプロジェクトの詳細

私は新卒で入ったSIの会社でがっつりウォーターフォールのプロジェクトを経験しました。
数年かけて大掛かりに作ったサービスを、さぁどうだ！とユーザーに公開すると、
ユーザーの反応がイマイチだったり、いざ使ってみると業務に合ってない部分が多かったりと、
「どうすればユーザーが使いやすいサービスを短い期間で作れるのか？」を悩んでいました。

転職後、今の会社で事業者向けの管理画面を作成する新サービス開発のプロジェクトにプロデューサー※として携わりました。
デザインにおいては超初心者の私ではありますが、その中で、ユーザーにフィードバックをもらいながら短期間でUIを改善する取り組みを行いました。

実際に日々の業務の流れの中でサービスを使ってもらい、その中で出たフィードバックを元に、プロジェクトメンバー全員で分かりやすいUIとは何かを考えました。

ユーザーにフィードバックをもらうことは良いことだというのは自明ではありますが、
副次的な効果として、エンジニア、デザイナー、ビジネスメンバー、プロデューサーが共通のゴールをもって、UIを改善するために奮闘したことでチームビルディングにもつながりました。

「ユーザーに分かりやすいデザインて何だ？」「ユーザーにフィードバックをもらいたいけど、どう進めていいか分からない」という状況だった私ですが、今回の新サービス立ち上げ・UI改善の経験で得たプロデューサーの話が、少しでもお役に立てれば嬉しいです。

※プロデューサー：当社ではプロジェクトマネジメントとプロダクトマネジメントを担っている職種をプロデューサーと呼称しています

Direct URL:

「仮説、構築、計測、学習、意思決定のサイクルを丁寧に回し、ユーザについての学びを積み上げながら本当に価値のある、必要とされるプロダクトに近づけていく」このようなプロダクト開発を実践できる組織にするため、組織体制やチームのミッションなど、チームの外部環境を整えていった事例を共有します。

昨今では多くの人が同意する理想的なプロダクト開発の進め方であり、実践のためのプラクティスも多数共有されていますが、現実に実践していくことには一定のハードルがあり、理想として抱きながらも実践はできていないという組織が多いのも事実です。この要因として、方法論やチームの練度の問題ではなく、組織構造やチームに与えられたミッションなど、チームの外部環境によるところという言説も共有されるようになってきました。

このセッションでは、スピーカーの所属するLAPRAS株式会社において実践例を紹介しながら、学び得た考え方、うまくいったこと/いかなかったことなどを赤裸々に共有します。

Direct URL:

40人を超える開発チームでモノレポ開発。当然のようにカオス化していくアーキテクチャ。生産性は伸びない伸びない。

カイゼンのために、Team Topologyを参考にチームを分割したものの、効果が見えない見えない。

そんな中で、Four Keysの計測に取り組み、生産性の可視化とカイゼンに取り組んでいるナウな話をします。ぶつかっている課題とその解決の取り組みの共有をしたいと思います。現在進行形なので、課題は解決できているのか、それとも暗礁に乗り上げているのか。まだ誰にもわかりません。

Direct URL:

プロダクト(サービス) 開発において品質向上・生産性向上をめざして、様々なプロセス、手法を取り入れて取り組まれていると思います。

新規開発、保守 (バグ修正、リリース業務)は、1つの組織 (チーム) で行われていることも多く、最近でフルサイクルエンジニアなども呼ばれています。

この組織(チーム) では、QA も組織 (チーム) の一員として製品(プロダクト)、プロセスの両方に対しての品質の維持、改善などを直接行うことも多いかと思います。

このような立場は QA ファンネルのインプロセス QA という役割になるかと思います。

ところが、組織 (チーム) の体制によっては、QA 部門が開発とは独立し Dev と Ops が切り離されている場合があります。

この場合、Dev と Ops でギアの組み合わせ、切り替えがうまくかみ合わないと以下のような様々な問題が発生してきます。

• 開発チームがやり残した(忘れていた) やつでしょ？開発チームでやれば？
• 保守チームがリアクティブ (後出しすぎる)
• ドキュメント(設計など) の意味がわからない (わからないのはお前が悪い)
• ユニットテスト (テスト環境、データ)など作ったものが活かされない

そもそも、品質管理チームからの開発チームへのフィードバック・エンパワーメントするシステム (プロセス) がなく、まずは、開発チームと組み合わせることを考慮した品質管理チームのプロセス (ギア) を定義をし、実践するところから始めています。

理想 (桃源郷) は、開発チーム、顧客からのフィードバックをもとに、品質を向上させるプロセス(システム)を用意したり、技術・手法などを取り組んで生産性をあげて効率よく製品をリリースできるようにしていくことです。

どこでも同じだとは思いますが。。。

そこで、上記のような課題や事態を1つずつ解決していき、いいかんじでWhole-teamアプローチとなる状態 (QM クリスタル) を模索していく道のりをお話しします。

QM ファンネルにつきましては、JaSST 2021 の発表の資料をご参考にしてください。

https://jasst.jp/symposium/jasst21tokyo/pdf/B8-2.pdf

https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties

QM クリスタルについては以下の JaSST 2023、 Scrum Fest 新潟の資料をご参考にしてください。

https://jasst.jp/symposium/jasst23tokyo/details.html

https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18328/whole-team-approach-whta-for-babies

Direct URL:

このセッションでは、10数年間のアジャイル開発を実践を経た私が、野中スクラムに回帰しようと考えるようになった理由と、野中スクラムを実装する活動の実践知を共有します。道半ばではありますが、日本によいプロダクトを生み出すスクラムチームを増やしたいという想いを持ってお話させていただきます。

私がスクラムに出会ってから10数年が経ちました。

よいプロダクトを生み出すよいチームをつくるために、日々の実践を重ねてきました。その過程で現在所属しているチームSilver Bullet Clubを立ち上げ、チーム転職を経て、組織やドメインを超えて、安定したチームとして活動しています。

しかし、さまざまなプロダクトや組織に関わっていく中で、私たちが本当によいプロダクトを生み出すことに寄与できているのか疑問に感じるようになりました。

これまでスクラムチームの一員として、どのようによいチームをつくるのか（チーミング）、どのようによいプロダクトをつくるのか（エンジニアリング）に取り組んできました。これらの活動は間違っていなかったと思う一方で、よいビジネスアイデアを持っているプロダクトオーナーをつくり手の立場から支援するというポジションをとることでプロダクトマネジメントを自分たちの活動の外に置いていた一面もあったように感じます。

そして、もう一度「よいプロダクトをつくるよいチームをつくる」という原点に戻ってきました。

私たちはつくり方にこだわるだけでなく、何をつくるのかにこだわる必要があります。そのためには私たちがプロダクトに入り込み、オーナーシップを持ってプロダクトづくりに取り組むことが必要です。

野中先生の書かれた『The New New Product Development Game』を読み直したところ、まさに「考える」と「つくる」を共にするスクラムの原点が書かれていました。

このことに気づくまでに10数年かかったがまだ遅くないはずです。

Direct URL:

私たちは数カ月前から、開発生産性を可視化し、得られたフィードバックからシステム開発プロセス等を見直す運用をスクラムにインストールし、試行錯誤してきました。当初持っていた期待、課題感は以下のようなものでした。

• プロダクト、事業の成長速度を上げたい。そのために開発生産性ののび代、ボトルネックが知りたい。
• 開発プロセスに対する漠然とした不安。
  • 雰囲気でスプリント振り返りをしてしまってないか。
  • 雰囲気でマネジメントしてしまってないか。
  • 実際のところうまくいっているのか、うまくいっていないのか。
• エンジニアの内省を支援したい。

• スクラムで開発を行っている。
• 計測、評価、改善活動は5名程度のチームごとに行っている。
• 経営層からのトップダウンではなくて、エンジニア組織からのボトムアップでスタートした。
• 開発生産性の向上を主導するチームがあるのではなく、開発チーム内で可視化から改善活動まで行っている。
• つまり、数字を評価するだけではなく、開発プロセスに参加しており定性的な情報も体感している。
• 可視化を主導するのはEMの役割の一つ。改善活動はチームで、場合によってはエンジニア組織全体で実行する。

Direct URL:

みなさん、締切は好きですか？私は嫌いです。
アジャイル開発をやる中で機能のリリースに関しては締切を設定せず出来た時がリリースをする時だと考えそのように開発を行ってきました。それはエンジニアリングマネージャーとしてプロダクトのリリーススケジュールに説明責任を求められるポジションの今でもそういう風に行動しています。
しかし一方私は社内では別の帽子も被っています。それはテックブログの編集長という帽子です。テックブログの編集長として、みんなにテックブログを書いてもらう際にまずやることは「締切をきること」でした。
この行動の違いに何があるのか自分で不思議に思ったため書籍などを参照したり、自己を内省したりして出てきたものを発表したいと思います。
本セッションでは、締切が発生させる良い効果/悪い効果、混同されがちな締切とターゲットとスケジュールの違いを解説する予定です。

Direct URL:

スクラム開発は、高速で変化するビジネス環境に対応するための強力なフレームワークですが、その実践には様々な課題が伴います。

本プレゼンテーションでは、実際のプロジェクトでの経験から学んだスクラム開発の現実的な問題と、それらを解決するための具体的なアプローチについて共有します。

スクラムイベントの運用、ストーリーポイントの付与、エピックとストーリーの管理、POとチームの連携、レトロスペクティブの実施など、スクラムの各要素について深く掘り下げ、理想的なスクラム開発に向けての道のりを探求します。
※ こちらに関しては時間によってはどこかにフォーカスして話す可能性もあります

また、プロジェクトが途中で終了した場合の対応策や、今後のスクラム開発で試みるべき新しい取り組みについても議論します。このセッションは、スクラム開発に興味がある方々にとって、実践的な知識と具体的な改善策を得るための貴重な機会となることでしょう。

Direct URL:

Direct URL:

皆さんは毎日楽しく仕事をしていますか？

私たちは最初、そうではありませんでした。毎日残業しても中々開発が進まない。積みあがるタスク。

その4か月後、私たちは真逆の姿になっていました。チームとしてみんなで1つの目標に向かって進み、結果も出し、何よりもチームメンバーと働くことが楽しい！

スタートから4か月の間に何をやってきたのか、またそんなチームを作るために私が大切にしていたことをお話しできればと思います。

Direct URL:

Direct URL:

アジャイル/スクラム開発を取り入れている開発チームで、「特定の詳しいメンバー以外は何が何だかよく分かっていない」「一応導入しているものの、イマイチ上手く回っていない気がする」といった課題をお持ち出ないですか？

弊社の開発チームも少し前までそれに近い状態で、開発は進んでいるものの開発プロセスの改善があまり進まない状態でした。

本セッションでは、弊社の開発チームが輪読会を通してスクラム開発の基礎知識を獲得し、それによって起こった変化について発表します。

Direct URL:

「レビュー待ち」という状態を聞いたことがありますか？スクラムやカンバンなどの Agile な手法を使っていてもどうしても「待ち」の状態が発生することは避けられないでしょう。そうした「待ち」のうち、「レビュー待ち」という状態が存在します。これは、「実装は終わった。その実装に対するコードレビューを待っている」という状態です。

このとき、コードレビューを行うのが開発チームの外のメンバーであれば、たしかに待たないといけないことは多そうです。そうした場合は開発メンバーでコントロールすることができない状態なので、「レビュー待ち」になるのは仕方がないかもしれません。

では、コードレビューを行うのが同じ開発チームメンバーであればどうでしょうか？その場合、実は「ちょっとレビューしてくれますか？」というコミュニケーションだけで「レビュー待ち」はなくせそうな気がします。

そもそも、同じ開発チームメンバー内のレビューなのになぜ「レビュー待ち」になるのでしょうか？様々な理由はありますが、その一つとして「コードレビューは非同期で行うもの」という心理があるのでは、と推測しています。一般的にコードレビューといった場合、 Modern Code Review 、つまり、カジュアルにツール（GitHub など）を使った形で行われるものを指しますが、そうしたツールを使う前提だと非同期でのコードレビューを前提にすることが多いはずです。実際のところ、そうしたツールのおかげで多くの Open Source Software は世界中からのコントリビューションを集めることができたのだと思います。

しかし、そうした非同期性はタイムゾーンを同一にする開発チームにおいても必要かというとそうではないと思います。実装に至った背景などの情報はメンバー同士で直接口頭でやりとりすればスムーズに伝わります。

本セッションではコードレビューを口頭などで同期的に実施することを推奨します。また、そもそもコードレビューの形式をとらなくても、モブプログラミングなどの手法を利用することでコードレビュー相当のフィードバックを反映させられるのではないか？ということを伝えていきます。しかし、口頭などでの同期的なコードレビューだけを行うとレビューのコンテキストがメンバー間の頭の中にしかない状態になりがちです。口頭でのやりとりは情報伝達がスムーズな反面、実装の背景や意思決定が埋もれてしまい、時間が経って忘れ去られてしまう恐れがあります。そうしたことを防ぐために、コンテキストを文書に残していくことの重要性を伝えていきます。具体的には、 pull request の description にしっかり理由や背景を書こう、という内容を伝える予定です。

Direct URL:

100年に一度の変革の代名詞として用いられる「CASE」。しかし、その言葉は、市場から出てきたものではない。ならば、本当の変革は、どこにあるのか？私は、それは、「クルマ業界内」ではなく、CASEにより繋がりが生まれる「クルマ業界以外」との関係性の中にあると考えている。本発表では、それを「シン・CASE」として独自に定義する。

従来から、クルマ業界は「ハードウェア重視のものづくり」が得意であり、「ソフトウェア」は苦手だと言われていたが、最近では、さまざまな取り組みにより、手法だけでなく、一部では文化も変わりつつある。しかしながら、車載の組み込みソフトウェアの作り方の変化、電子システムのアーキテクチャの変化の速度は、未だにモデルチェンジの速度に律速されている。

一部、OTA（Over the Air：無線ソフト更新）も実用化されているが、限定的と言わざるを得ない状況であり、IT業界のようなアジャイル、スクラムの展開とは全く異なる状況から脱出できていない。

それは、内向きとも言える「CASE」を対象にしているからではないか？そして、もし外向きの「シン・CASE」の分野であれば、最新のソフトウェア開発の手法が適用できるのではないだろうか？

ここでは、最近、北米の急速充電規格を統一したことで話題になったTeslaのSuper Chargerを事例にして、充電器／充電アプリという、クルマ以外の外部とのつながりの部分におけるHardware/Software設計思想からの学びを共有する。

最後に、何故、通信機能付きZaurusがiPhoneになれなかったのか？何故、リーフがModel3になれなかったのか？という歴史からの学びをまとめ、今後の勝ち筋について私見を述べる。

Direct URL:

本講演では、Project-Based Learning（PBL）とアジャイル開発の原則を活用した新卒研修の実施とその成果、そして研修の継続的な実施が組織全体に与える影響について議論します。

まず、PBLとアジャイル開発を組み合わせた新卒研修のアプローチについて説明します。新入社員は少人数チームを組み、自己組織的にソフトウェアプロダクトを開発することで、協調作業、問題解決、外部サポートの活用といった実務能力を養います。この過程では、特定のトピックを教え込む伝統的な座学型研修とは異なり、参加者自身が企画を考え、必要な技術を調べ、実装し、品質保証と運用も担当することで、総合的なソフトウェア開発プロセスを体験します。

このプロセスにおける重要な要素として、アジャイルコーチによる研修のサポート体制について詳述します。アジャイルコーチは、スクラムイベントを通じて参加者の活動を観察し、適切なタイミングで介入を行います。コーチは、レトロスペクティブを通じて見える化されたチームの課題に対して、適切な講義コンテンツを提供し、プロダクトへのフィードバックを与え、早期のリリースを促進します。これにより、参加者は不確実性が高い職場環境での不安への対処方法を学ぶことができます。

次に、このプログラムが新卒者と企業の間のギャップを埋め、OJTの負荷を減らす効果について考察します。また、マネジメント能力の向上という観点からも、新入社員自身、そして事務局として参画する若手エンジニアの双方がマネジメントの実地経験を得ることで成長します。

さらに、研修が実務的なプログラミングスキルの習得を支援するために、実際の企業のソフトウェアインフラを模した環境で行われます。この環境は最新のクラウドインフラ、ソースコードやプロジェクト管理に関するインフラ（例えばGit）、ブランチ戦略、テスト自動化、リファクタリングといったアジャイル開発における技術プラクティスの理解とスキル獲得を促進します。特にシステム運用部署に配属される予定の新入社員に対しては、開発者としての視点を持つための重要な体験の機会となります。

そして、研修の継続的な実施により、本研修のアジャイル開発の効果を認識し、現場での業務を経験した参加者が事務局として研修の実施側に参加することで、モダンなソフトウェア開発組織でのマネジメントについて深く理解する機会を得るという側面も説明します。これは、より広い視野でマネジメントを行うためのきっかけを提供し、ただ仕事を指示するだけの人材ではなく、現場の苦労を理解し、成果を出すリーダーとしての素質を育むことに繋がります。

このように、PBLを活用した新卒研修は、新入社員の成長だけでなく、組織全体の持続的な成長を促進します。そして、アジャイル開発の原則、すなわち顧客価値に向けて直接的で公正な意思決定を行うことを、社員全員が実感として理解する機会を提供します。これは、組織全体が真にアジャイルを理解し、それに基づいて行動するための基盤を形成します。

Direct URL:

「プロポーザルを出してみたい」

そう思っても実際に提出に至ることができる人は多くありません。それは普通のことです。なぜならプロポーザルを書いて提出するという行為は自らが生み出したモノを人の目に触れる場所に曝け出すことであり、それはとても勇気のいることだからです。それでも私がプロポーザルを提出できたのはコミュニティの皆さんが背中を押してくれたからでした。

はじめてのプロポーザルを書き上げるまで

私が初めてプロポーザルを投稿したのはスクフェス福岡でした。そこで私は初めて参加したRSGT2023に会社の仲間たちと一緒に参加して学んだことについて書き綴りました。書きながら私はいくつもの「内なる悪魔の声」と戦いました。「別にこの話は会社の他の誰かがしても同じじゃない？」や「こんな個人的な話を聞きたい人なんて本当にいるの？」といった声が脳内に響き渡りました。

そういった自己否定の気持ちと戦い抜くことができたのは、RSGT2023で「初めてのプロポーザルで自信がないのでアドバイスをください」と発言したのがきっかけで「スクフェス福岡のプロポーザルを読んでYYする会」の存在を知ったからでした。そこに草稿でもプロポーザルを持ち込めばフィードバックをもらえる。その気持をモチベーションにしてなんとか書き上げました。

フィードバックに背中を押された

プロポーザルを読んでYYする会で書いてきたプロポーザルについての話をする中で私は本文に書かなかった色々な気持ちを自然と口にしていました。RSGTに参加するまではカンファレンスに参加する強い意志がなかったこと、誘われて初めて「みんなで行くなら......」と腰を上げることができたこと、頭取に言われるまでプロポーザルを書いてみようという発想すらなかったこと。そんな何気なく言葉として紡がれた「私のストーリー」を皆さんは拾い上げて「それそれ！」「その話が聞きたい！」と言ってくださいました。

そしてその時に一緒に初めてのプロポーザルを書いた烏帽子さんとおーのAさんにも、今度は私も同じようにプロポーザルを書くに至った経緯を聞く中で「ぜひそれを語って下さい！」と言う側になっていました。この時に私は「結論が一般的でも経験は唯一無二だ」ということ、そして「私が誰かをすごいと思ってもその人にとってはそれが普通で、私が自分を普通だと思ってもそれは誰かにとってはすごいことがある」ということを学びました。そうしてYY会で受け取ったフィードバックを元にプロポーザルのリファインメントをし、ありがたいことに採択していただき登壇することができました。

この経験を届けたい

スクフェス福岡に参加した後、その次のスクフェス新潟の情報について調べていく中で「テストやメンタルヘルス」といった私が個人的にとても興味のあるテーマを取り扱っていることを知りました。私は「そこでプロポーザルを書いて得た学びを共有したい！」と思い締め切りが迫る中プロポーザルを書き始めました。「スクフェス新潟のプロポーザルを読んでYYする会」の当日も無我夢中で書き続けて『「あなたすごい人、私ふつうの人」を乗り越える！経験をプロポーザルにしてみよう』の原案を投稿しました。

YYする会に間に合わせるために気合でなんとか最後まで書きましたがこの時も私は「プロポーザル書いたなんて話私じゃなくてもできるし......」「もっとすごい人がプロポーザルを書いてるし......」という気持ちに負けそうでした。でもいざYYする会でプロポーザルの話をしていると「ぜひ聞きたい！」という声や、より伝わるようにするための具体的なアドバイスをいただくことができて取り下げずにがんばろうと思うことができました。そして再び得たフィードバックを元にプロポーザルをリファインメントし、再度登壇の機会をいただくことができました。

何度でも伝えよう

嬉しいことに新潟での発表を見て「プロポーザルを書いてみよう」と勇気を出してくださった方々がスクフェス大阪にプロポーザルを書いてくださりました。そして「スクフェス大阪のプロポーザルを読んでYYする会」で背中を押してもらっている姿を見て「ああ、あの時勇気を出してプロポーザルを書いて良かった」と心の底から思いました。でも同時に「自分じゃなくてもいいんじゃないか」という感情はそう簡単に克服できることではないということを改めて痛感しました。とても素敵なストーリーを持っているのになかなかプロポーザルを書く手が進まない。であれば何度でもこの想いを伝えよう。「あなたの唯一無二の経験にはきっと価値があるはずだ」というメッセージを送り続けようと思いました。

経験をプロポーザルとして言語化している時に私がどういうアプローチを取っているのか。プロポーザルを書き切る為にどういうことを考えているのか。採択されるためにどういう書き方をするのがいいのか。スクフェス大阪に向けて改めてプロポーザルを書きながら気がついたことについても盛り込みつつできる限りの私の想いをぶつけます。

Direct URL:

このセッションは、メンバー間にスキル差があるペアプロやモブプロの中で、教育と開発スピードのバランスの取り方に悩んでいる開発者を対象としています。

このセッションを通して、ドライバーやナビゲータ以外のロールの分け方やスキル差が緩和されるタイミングに関する自分の知見を共有することで、聞き手となる開発者がチーム内で協力的プログラミングをもっと扱えるようになることをゴールとしています。

改めまして、全世界のみなさまこんにちはこんばんは、やたです。

普段はクリエーションラインという会社で内製化支援として開発者のリスキリングを支援したり、社内のどこかのチームにジョインして開発者にたいしてユニットテストの教育などをしたりしています。ちなみに、アジャイルコーチではなく、開発者として入っていくことにポリシーを持ってやっています。

基本的にペアプロやモブプロ（以降、ペアモブ）を中心に支援をしているのですが、

自分自身の説明力とメンバーとのスキル差が噛み合っていない時、教育と開発スピードのバランスをとりながらペアモブを行うこともあり、扱う変数が多くて悩むことが多いです。

みなさんも新人の開発者が入ってきたときなどで同じような曲面で直面したことがあるのではないでしょうか？

よくある始め方として、

• 1セッション25分でナビゲーターとドライバーに分かれる。
• 知識差がある場合は、知識を教える側がナビゲーターにいる。

なんてことがあると思いますが、長年同じメンバーでやっていて個々人がコラボレーション慣れしているメンバーが揃っている強いチームでない限りなかなか難しいのではないかと考えていて、いろいろ試行錯誤しています。

自分の場合、いろいろ試したみて以下のようなロールの分け方でペアモブを進めるとうまくいくことが多いです。

• とりあえず実装するまで書き続ける人とリファクタリングする人
• 自分で実装しながら全て説明する人と観察する人
• 頑張って実装してみる人と見守る人

セッションが採択されたら、上記のようなロール分けをやってみたときの学びや良さ、そしていくつかのチームを渡り歩いて感じたスキル差が緩和されるタイミングについてお話しできたらと思います。

Direct URL:

私のいるプロダクト部門では、数年前に大規模スクラム（LeSS）を導入して、それなりの期間運用した後、理由があって一度とりやめました。そして、今また LeSS の導入に向けて歩みを進めています。そんな現場にスクラムマスターやEMとして関わり続けてきた経験（現在進行形）から、しみじみと理解したり学んだりしたことを共有させていただければと思います。

本セッションでは、LeSS 実践者として様々な課題に直面し、探求・議論を重ねてきた経験から得た学びを共有することで、みなさんが LeSS をはじめとしたスケーリングスクラムの導入判断を行ったり、導入に向けた計画を立てたりする際に参考になる知見を持ち帰っていただくことを目指します。

次のような内容をお話しする予定です。

• 背景となる対象組織の超サマリ
• 前提知識としてLeSSの超サマリ
• 第一次LeSSのふりかえり（なぜLeSSを解体することになったか？ふりかえりからの考察）
• 第二次 LeSS 導入への再始動にあたって議論し整理したこと（導入チェックリスト的な話）

奇しくもこの発表の前週に、日本で久しぶりに行われる『認定LeSS実践者研修（CLP）』を受講予定で、LeSSの生みの親 Bas Vodde との学びを経たフレッシュな知見を共有させていただけるスケジュールです！

Direct URL:

Direct URL: