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.

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

栃木でScrum Fest初開催！

せっかく栃木に全国のアジャイル好きが集まったということで、みんなで話す時間を作りたいと思います！

アジャイル好きな方は他人から話題を振られるよりも、自分たちが好きな話を、自分たちで場を作って、自分たちが心地良い状態で話をしたいですよね！

プリウスやテスラの話を聞いたら、自分たちもきっとこうなんじゃないか、という話をしたくなりますよね！！

ということで！

栃木会場のライトキューブで「Open Space Technology」通称OSTを実施します！きっと初開催！

OSTってなに？って方はSlideと動画のリンクも貼っておくのでそちらをご覧ください！

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

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

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

SQiP2023の概要：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この経験を届けたい

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

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

何度でも伝えよう

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

セッション概要

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

セッション詳細

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意！

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

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

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

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

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

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

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

いくつかの景色

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

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

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

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

ベンチマーク思考

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

顧客の見えない開発

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

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

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

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

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

開発予算の減少

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

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

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

内製化能力の低下

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここまでのお話を、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

合宿をしなさい

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

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

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

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

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.実は合宿では何一つ進んでいない。
　　日常に戻ってからのスピードに違いが出るので、違いが出るまで合宿は終わらせない

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

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

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

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

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

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

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