新しいことにチャレンジしようとすると、厄介な現実に直面することも多いです。

未経験からプログラマへのチャレンジ、メインフレーム用OS開発からインターネットサービス開発へのチャレンジ、プログラマからプロジェクトマネジメントへのチャレンジ、上場会社から数人のスタートアップへのチャレンジ、会社員からフリーランスへのチャレンジ、自己流開発プロセスからアジャイルへのチャレンジ、日本から東南アジア(フィリピン、ベトナム)へのチャレンジ、Webサービスから農業課題解決へのチャレンジ、自社サービス内製開発から受託開発へのチャンレンジ。

私は今まで12回の転職(出戻り、転籍、フリーランス含む)を繰り返しながら、様々な事にチャレンジしてきました。

新しいことにチャレンジするのは正直しんどいです。必ずといっていいほど厄介な現実に直面し、何度も心が折れそうになりましたが、それらを乗り越えたときに得られた充実感や達成感、素晴らしい人達との出会い、そして一つの機会が次の機会を引き寄せることで、人生はより豊かになるのではないかと信じています。

今回のセッションでは、直近のチャレンジであるアジャイルな受託開発、アジャイルなオフショア開発の経験を中心に、なぜチャレンジするのか、どうやってチャレンジするのか、どんな困難があるか、そのチャレンジを通して何が得られているか、今度どうしていきたいのか、その辺りのお話しをすることで、誰かの一歩を踏み出すきっかけになれば幸いです。

※ふりかえりが形容詞じゃないという部分は投げ捨てています

アジャイル、スクラムのなかで、とても親しみやすく、そして奥が深いのが「ふりかえり（Sprint Retrospective）」というイベントです。
スクラムを始めて1, 2年のチームの話を聞くと、こんな悩みをよく聞きます。

• Tryを出しても行われず、毎回似たようなTryが出てくる
• 出てきた問題がチームだと対処しようがない問題で、解のないまま終わってしまう
• ふりかえりの〇〇の手法をやっているけど、しっくりこなくて…
• どうやって自律的に（スクラムマスターが不在でも）ふりかえりが回せるようになるの？

これらの悩みの中には、下記のような潜在意識が隠れています。

• 「ふりかえりで問題を解決すべき」と思っている
• 「ふりかえりが問題を解決してくれる」と思っている
• 「ふりかえりをうまく回す」ことが目的化している
• 「特定のふりかえりの手法が問題に対しての特効薬となる」と思っている

こういった考え方は間違いではありません。ただ、それがふりかえりのすべてのように感じられてしまっている、もしくはそう思い込んでしまっている現場も少なくありません。

「Do ふりかえり」の意識では、あくまで「ふりかえりの中でなんとかする」という考え方が生まれがちです。ですが、ふりかえりの時間は仕事の時間の中ではごくわずか。アジャイル開発・スクラムにおいては、1週間で40時間働くうち、毎週1時間ふりかえりをしたとしても、たった2.5%の時間でしかありません。この時間の中で、残り97.5%で生まれた問題を解決するというのは酷です。

それではどうするのか。97.5%の時間で問題が解決される（もしくは良い方向に変化が起きる）ような状態を作り上げます。それが「Be ふりかえり」です。ふりかえりをするタイミングに合わせてふりかえるのではなく、チームの中で「自然とふりかえっている」状態を作ります。

この状態を作るには、「ふりかえり」の活動だけでは実現できません。チームビルディングを常に行い続け、チームのコミュニケーション・コラボレーションを活性化させる。「継続的チームビルディング」とも言える活動を取り入れてこそ実現できます。そして、その継続的チームビルディングを行いやすい場が、「ふりかえり」の時間なのです。

このセッションでは私が複数の現場で再現性を高めてきた、「Be ふりかえり」の状態に至るまでのプロセスと、その一歩目の踏み出し方・継続の仕方をお伝えします。ふりかえりをより楽しみ、チームとプロダクト、そして事業が成長していくための道のりと実際の事例をお話ししたいと思います。

スクラムフェスのような社外コミュニティのイベントに参加や登壇する際、会社公式として活動できるかどうかは、会社の状況に大きく依存します。既にそういった活動が当たり前になっている会社もあるでしょうし、ルールやプロセスが不明確だったり存在しなかったりする会社もあるでしょう。明示的に禁止している会社もあるかもしれません。もし、そのような活動を望む場合に道がない状況であれば、自分たちが第一人者となり切り拓いていく他に方法はありません。

私たちはDNPグループの情シス子会社であるDNP情報システムに所属しています。数年前、いくつかのきっかけが重なったことで、自身の存在意義が「チェンジエージェントとして組織を自由にしていくこと」にあることを（勝手に）見つけ、それを実現する方法を模索するなかで、私（寳田）個人として社外で活動するようになっていきましたが、最近に至るまで、会社公式ではなく個人としての社外活動することに特に不満も問題意識もありませんでした。

しかし、今年に入ってから新年度を迎える頃、マネージング・フォー・ハピネスの出版やそれに関する登壇で個人としての活動に一定の満足を得たからか、チェンジエージェントとして自分が社内で起こしてきたことに段々と自信が持つことができたからか、それによって他のことを考える余裕ができたからか、あるいはそこそこいい歳になってきたからか、はたまたその全てが合わさってか、自分がやるべきこと（すなわち、自分にしかできないこと）で今いる場に貢献していくことを考えてみると、

• 特定の人が周囲の人を動かすことでパフォーマンスを出すのではなく、皆が自律的に自分の思うままに（衝突も含めて）動いた結果の相互作用によって1人では実現し得ない総体としての結果を出すような組織に変えたい
• これまでの過去や現在ではなく、これからを支える次の世代がいきいきと活躍していけるような道筋や（ルールやプロセスや文化や風土などを生み出す構造としての）システムを残したい

の2点であることに気づき、それらを自分の仕事におけるゴールと考えるようになってきました。

一方で、社内では「情シスのメイン業務で得た業務ツールの利用促進（ときどき横連携強化）から仕事のやり方を変えていい感じの働き方ができるようにしていく」を目的にコミュニティも立ち上げていましたが、ここもコミュニティメンバーと今後の在り方や活動方針を見直す機会があり、これからは「仕事のやり方を変えていい感じの働き方ができるようにしていくこと」すなわち「セルフマネジメントの理解と実践による自律的な行動や責任に満ちた組織へのトランスフォーム」の方に重心を置くこととし、そういった変化への認識と欲求を刺激する（社内で自分たちも変わりたい、変わらなければいけないという想いが生まれるようにする）ためのロールモデルや良い意味での外圧となるべく、今年4月から「公式に社外活動に取り組んでいく」「そのためのスキームを整備する」を目標に動いてきました。

このセッションでは、そういった状況にいる「とある情シス子会社の今はまだ小さな現在進行形の物語」として、今に至る経緯、いくつかの時点でどう考えて何の行動をとったか、これから何を狙っているかについてお話します。

物語の行く末はプロポーザルの採択によっても変わるところもあると思います。当日、皆さんの前で/皆さんと一緒に話をして、一定の目標を達成した喜びが共有できれば幸いです。

　変化が激しい状況の中、組織自体もアジャイルに変化していく必要性が出ています。そのため、開発だけでなく組織運営自体もスクラムの概念を取り入れ、プランニングやレトロスペクティブをしながらバックログを消化していく事で、組織を成長させていく。そのような「組織アジャイル」の考え方が注目されています。

　その中で肝となるのが「組織バックログ」です。書籍「組織を芯からアジャイルにする」においても

>バックログでチームの「脳内」を表す
>今取り組むべきものについて、チームや部署内で共通の理解を得るための「可視化」、さらに粒度を合わせるための「構造化」、何から取り組むのかという「順序付け」を行う事で、チームの脳内を整えて行動を揃える

とバックログの重要性について記載されています。

「なんだ？チームでタスクを見える化して計画・ふりかえりを繰り返していく。普通の事じゃないか？」

と我々も「組織アジャイル」なる活動を始めてみましたが、始めてみると開発でのアジャイル適用以上にうまくいかない事の連続でした。

　本セッションでは組織アジャイルとしてバックログの管理・運用が何故難しいのか？どういった事に工夫したらよいのか？という点について実際に運営する中での気づきとTipsを報告したいと思います。特に組織バックログを対応していく上で必須と思える協働のメンタリティをどのように育んでいったかを解説したいと思います。組織を変化させたいリーダー層に参考になれば幸いです。

＜組織バックログがうまくいかなかった理由＞

1.ゴールが見えづらい

・組織のプロダクトゴールが必要だが、組織単位で意味のあるゴールを設定・共有することが難しい。結果、プロダクトゴール、スプリントゴールがうまく設定できず、単にバックログをこなしていく、いわゆるビルドトラップの罠にはまってしまう

2.バックログの構造化が難しい

・プロダクト ゴールを設定できても、バックログ化するにはゴールとバックログを紐づける構造化が必要となる。ただし、抽象的なゴールから具体的なバックログを整理するやり方が分からない

3.担当の役割分担が難しい

・組織活動を実施する場合はリーダー層が集まって対応することが多くなるが、忙しいリーダー層で効率よく作業ができるよう、タスク分担をして対応した。

　しかし、タスクの偏りやメンバーでの優先順位の違いが出て、中々進まなかった。また、当然スクラムマスターも専任できない中、バックログの見える化やメンバーの調整、ふりかえりやゴール設定のファシリテーション等、タスクは進まない中で、スクラムマスターの負荷だけが大きくなり、疲弊した

＜対応方法のTips＞

1.組織のMVVの及びゴールの設定

・ ゴールが見えないという課題については、リーダー層で合宿を実施し、MVVを策定

・MVVとバックログの関係を構造化した

2.ゴールに対してのバックログの構造化

・1年後、3ヵ月後、1か月後といった期間ごとのゴールを言語化しKPIを仮設定

・スプリント中にゴールと仮設定したKPI自体を見直すようなタイミングを設けてふりかえり・むきなおりを実施

3.協働のメンタリティ

・ メンバー間でソーシャルサポートのスキルの重要性を共有し、助けてもらうスキルを意識的に伸ばす

・モブワークの枠を多用し、集まれるメンバーで集まりながら、タスク担当者とは関係なく、モブ作業で課題解決や計画を実施

弊社では新卒の採用を活発にしています。(今年は64人の方を採用しています)
新卒のみなさんは4月に入社をすると2か月間の新卒研修を受けます。
今までは外部の研修会社に依頼をしていました。社員は会社の宝です。ですが、残念ながら、研修の内容は少なくともぼく（てらひで）にとっては満足がいく内容ではありませんでした。
そんな中、自分みたいな1社員がこの状況を変えるなんて無理だろうと思い日々を過ごしていました。

ところがです。2020年4月。COVID-19の影響で緊急事態宣言が発令し、弊社もリモート勤務を余儀なくされました。もちろん新卒のみなさんも例外ではありません。
慌てたのは研修を担当されていた講師の方です。集合研修を想定していたものが、研修開始して3日目で急遽リモートに切り替えられたからです。
講習を録画し教材を作るなどの今までやったことのない作業が研修期間と並行して行われました。
その年の新卒のみなさんには（仕方がなかったとは思いますが）残念な研修をうけてもらうことになってしまいました。

その結果を踏まえて、3年前から新卒研修を自前で行うことを計画し始めました。
変更前の研修のような形式で身に着けたハードスキルはすぐに陳腐化してしまいます。
新卒が自分達で考え自分達で行う研修。生涯学習。アクティブラーニング。チームでの研修。考えることはたくさんありました。
そこで、ぼくらが参考にしたのはスクラムでした。スクラムでは自己組織化したチームが自分たちでゴールを決めて作業を進めていきます。
このやり方を研修に生かせればと考え2021年に最初の社内による自前での新卒研修が行われました。

その後3年かけてブラッシュアップしてきた取り組みをみなさんにお伝えしたいと思います。

ふりかえり、大切だとは思いながらも形骸化してしまったり、なかなか定着しなかったことはありませんか？
また、毎日のふりかえりって開発以外の分野ではどうしてるんだろう？と気になっている方もいるかもしれません。

本セッションでは、ふりかえり手法「Fun Done Learn」の魅力、そして開発ではないマーケティングのチームが毎日Fun Done Learnを実践している事例をご紹介します。

事の始まりは、2022年11月。KAGの中島が「Fun Done Learnのうた」を発表しました。
この曲の歌詞には、KAGのPoCチームが毎日Fun Done Learnにてふりかえりをおこなっている実践知が込められています。KAGのPoCチームでは、顧客との価値検証を目的に1日単位のスプリントにて計画〜レビュー〜ふりかえりを実施。今の状態をチームで把握するために、毎日Fun Done Learnで2年以上ふりかえりを続けています。

そして、スクラムフェスでKAGと出会った、ITプレナーズのメンバー。この曲の中毒性に取り憑かれ、毎日ふりかえりをするというエピソードを知ったことがきっかけで、ITプレナーズのマーケティングチームは毎朝の朝会でFun Done Learnによるふりかえりを始めました。この取り組みは半年以上経った今でも継続され、すっかり定着しています。

何故、ふりかえりを始めようと思ったのか？その背景は？
毎日Fun Done Learnをやって感じている効果とは？
Fun Done Learnをしている際に気を付けていることとは？

チームで習慣を作ることは大変なことです。
KAGとITプレナーズ合同で、毎日実践しているFun Done LearnをFun Done Learnでふりかえることで、Fun Done Learnの魅力を更に掘り下げます！

※参加者からも随時ふせんを募集します！

先月4月に新卒として就職を果たした、社会人1年目のエイミです。

このセッションは、新卒研修を受けたばかりのエイミが、新卒研修を通して気づいた「当たり前」をもとに構成されています。

僕が受けた研修では、一番最後の関門として卒業試験がありました。その関門に至るまでは与えられた要件を満たすWEBサイトを作り、いくつかのフェーズに分けてレビューを受けつつ、早く作り終えてレビューを受けた人から通過していく形でした。それらの試練を乗り越えて、卒業試験を受けます。どのような形式かというと、CTOでもある事業本部長・配属希望先の事業部長・エイミの3人で口頭試問の形で以下の2点を見極めるものでした。

1. 研修内容をどれだけ理解できているか
2. 現場に配属されるにあたって必要なスキルがあるか

この試験を受けたのは昨日のことですが、今日1日試験でのフィードバックを受けてインプットしたり、試験や研修自体を振り返ったりしていると、あることに気がいくようになりました。

現場のエンジニアになったとき、プロとして成果を求められることになることです。

もう少し具体的にすると、ビジネスとして、それも新規事業開発のプロとして、エンジニアリングという専門性を手段にしながら事業の成功のために成果を出す必要があります。そして、その成果を出す上で必要になる「当たり前」は、大学時代に教わってきたことや実践してきたこととは色が異なりました。アルバイトでも、授業の開発でもない場、はたまたスタートアップのコアメンバーとしての開発でもない場、この事業共創カンパニーにおけるプロのエンジニアの一人であるということは、自分がこれまで経験してきたどの場とも違う印象を持ちました。

きっかけはいくつかありましたが、総じて「プロという自覚」や「求められている以上の成果」という言葉を受けたこと・考えたことに帰結しました。エンジニアとしての実践研修だけでなく、座学の研修やビジネスサイドと合同の全体研修のころからさまざまな話を聞き、日々の気づきを振り返り、思考し、試行し、フィードバックを得てきました。

どのタイミングにおいても、現場のエンジニアとしてのレベルに到達することを求められてきました。大学時代の経験とは明らかに異なる意識の仕方があり、そこに自分と現場とのギャップがありました。

もちろん、現場のエンジニアとして、プロとして働く上ではいずれも欠かせない「当たり前」ですが、ただ動くものを作りたい、ただ自分で使うものを作りたい、といった時には現れにくいものでした。現場における「当たり前」は、少なくとも大学時代の僕にとっては「当たり前」ではありませんでした。

今回僕がピックアップする、ギャップのあった「当たり前」は以下の3つです。

1. 自動テストを書く
2. パフォーマンスやセキュリティを考慮する
   1. 計算オーダーやクエリの発行回数
   2. 可用性・機密性・完全性
3. 一定水準以上の可読性・保守性

既に現場のエンジニアの経験がある方からすれば、なにを当たり前のことを言っているんだ、となると思います。

しかし、これらは大学時代に経験することのなかった「当たり前」でした。中には大学時代から現場で働いていた人もいるかと思いますので補足すると、今回ギャップがあるとみている両者は以下の2者です。

1. 現場のプロのエンジニアの「当たり前」
2. 学生エンジニア、いわばアマチュアの「当たり前」

この両者について言及します。

このセッションでは、3つの「当たり前」に対して、大学時代のエイミと、現場のエンジニアとして求められたエイミという2つの観点から、その実態・そうである背景・ギャップを埋めるために必要なこと、について語ります。

それにより、これからエンジニアとして働く学生にとっては、現場において何が求められるかがわかり、そのギャップに心構えをすることができます。

昨年、Ebackyのkeynoteで10分程お話させていただいた、アルプスアルパインの白石です。
昨年は、テストチームならではの取り組みについてご紹介しましたが、10分には収まり切らなかった話がまだまだあります。
今年は、私たちのチームメイトの矢田から詳細な内容を話してもらおうと思っています。
----
アルプスアルパインの矢田です。
皆さんのプロジェクトには、テスト専門チームはありますか?

私たちは、アルプスアルパインで製造したAndroid™ OSのカーナビゲーションに対し、Google認証を取得するためのテストを一挙に担っているテストチームです。
スクラムでテストチームと聞くと、どういうイメージを持つでしょうか。
何がプロダクトバックログになると思いますか？
何が完成の定義になると思いますか？
...

こういった具体的なプラクティスや、実際に起きた問題をお話しする予定です。
テストチームの話にはなりますが、一般的なソフトウェア開発チームを改善する発想のきっかけも得られると思います。

※ AndroidはGoogle LLCの商標です。

教育心理学概論　という本をご存知でしょうか？

アジャイルやスクラムと直接関係があるわけではないのですが、コミュニティの中で話題に挙がることがしばしばある本です。

私は、2016年頃から開催された読書会でこの本に触れ、それ以降この内容が好きになって、読み直したり、関連する本の読書会に参加するなどを続けています。

先日は Shinagawa Agile Talks に呼んで頂いて、この本に関連する内容についてお話する機会もありました。

教育心理学概論にどんなことが書かれているのか紹介するために、p.3「まえがき」に記載されている内容を引用します。

教育心理学は, 人が賢くなる仕組みを明らかにして, 人をより賢くするにはどうしたらいいのかを探る研究分野である。人は生まれつき身の回りにあるものごとや自分が経験したことの中に規則を見出す仕組みを持っている。自分の経験と他人から聞いたことを結びつけて視野を拡げる仕組みも使える。
〜中略〜
教育心理学の研究成果は, 学校など学びが起きる現場での人の賢さを育てることにつながる。

学びはアジャイルやスクラムにおいて重要な要素の1つだと思いますので、このような「人の学びについて学ぶ」ことに興味を持って頂ける方も多いのではないでしょうか。

一方で、（教育心理学概論はページ数もあまり多くないですし、やさしく書かれている本ではありますが）技術書などとは少し毛色の異なる本を自分で読むことに躊躇いがあったり、自信がない方もいらっしゃるのではないかと思います。

そのため、今回、教育心理学概論に書かれている内容がどんなものなのかを知るためのワークショップを開催したいと考えています。

実施内容は基本的には読書会の形になりますが、教育心理学概論でも紹介されている知識構成型ジグソー法 を使って、複数人が協力しあって、本に記載されている内容を理解していくことを考えています。

どのようなことを行うのか、大まかな流れを紹介します。

• まず、教育心理学概論の内容を大きく3つのテーマに分けます（詳細は検討中ですが、例えば「素朴理論」「建設的相互作用」「熟達」といった内容）
• テーマごとに2〜4人のグループを作り、教育心理学概論に記載されている内容を確認したり、理解するためにグループで話し合ったりします（エキスパート活動）
• 次にそれぞれのテーマを担当していた人たちが1人ずつ集まって、3人のグループを作り、お互いが学んだ内容を共有しながら、教育心理学概論にどのような内容が書かれているかについて話合います（ジグソー活動）
• 最後にジグソー活動で話した内容について、他のグループに対して共有を行います（クロストーク）

このワークショップを通じて、教育心理学概論に書かれている内容のおもしろさを知って頂くのと同時に、複数人で本を読むことで色んな観点から掘り下げることができる楽しさを経験して頂けたら嬉しいです。

※現地のみの開催を予定しています

※最小開催人数を6名、最大開催人数を12名としたいです（人が足りない場合には、小笠原も参加します）

※当日の参加希望者が5名に満たなかった場合、実行委員の方などで人数を補って頂けるとありがたいです

※教育心理学概論はこちらで用意しようと考えていますので、参加者で用意して頂く必要はありません

「2か月後の配属の時、自分はどうなっていたいのか」
必死に考え続けて、研修期間を駆け抜けてきました。

私たちが受けた新卒研修は、スクラムに則って行われていました。
プランニング、デイリースクラム、レビュー、レトロスペクティブ、
そしてまた、プランニング、...

サイクルを回すごとに、私たちの研修は私たちの手によって改善されていきました。

理想の自分になるための最高の研修を作り上げた先に、何があるのか...

このセッションでは、配属されてからの学びも加えて、改めて新卒研修をふりかえります！
スクラムの要領で、一週間ごとにプランニングと振り返りを繰り返し、研修中の学びの最大化を目指してきました。一週間後にどうなっていたいのか、二か月後研修が終わる頃には何を身に着けていたいのかを考えて研修期間を過ごすうちに、自分のための研修ができていきました。

新卒研修を通して私たちは大きく成長し、さらに成長し続ける土台をも築きました。その土台がまさに、スクラムのリズムです。スクラムのサイクルを常態化させることで、日常的に自分の取り組みや自分そのものを改善させていくことができるようになりました。

このセッションでは、
　どのようにして自分の研修を作ってきたのか
　研修を通して身に着けたスクラムのリズム
　日常にスクラムのリズムを取り入れる方法
についてお話します！

大企業のSIerでシステムエンジニアをしています、Katsuyaです。

本セッションでは、発信し続けることと『Fearless Change』のパターンを意識することで

• 社内で同じ志を持つ仲間を見つけられる
• 熱意や目標を見失わずに楽しく継続的に活動できる

という話をします！『Fearless Change』の第二部にはパターンの事例紹介が4人分掲載されていますが、私のストーリーが5人目の事例になれますように...!!

■セッション概要

3ヶ月ほど前から、会社の1つ上の先輩と業務時間外にWebアプリ開発を始めました。本業でアサインされているプロジェクト（メインプロジェクト）と対比して、このアプリ開発の営みをサブプロジェクトと呼んでいます。

なぜ先輩と私がサブプロジェクトを始めるに至ったか。それはメインプロジェクトに対して次のようなことを思っていたからです。

• コーディングの時間が少なすぎる（=基礎となる開発力が向上しない）
• アーキテクチャや開発プロセスレベルで試験的な取り組みをすることは工数的に不可能（相当な理由がないとクライアントが納得してくれない）
• 自分たちがアーキテクチャなどに対しての裁量を持てる職位になるまでに、試行錯誤する時間やタイミングがない
• そもそもこうしたことに興味があって意欲的に取り組める人が周りにほとんどいない

今の私たちは圧倒的に知識と経験が不足しているので、現状のシステム開発を客観的に広い視点で評価することができず、ただなんとなく「イケていない...」と感じるだけに留まっています。かと言って自分たちがそうしたことに裁量を持てる職位に上がった頃には今までメインプロジェクトで経験したことのあるアーキテクチャや開発プロセスにしか理解がないので、他のアーキテクチャや開発プロセスを採用するのはリスクが大きすぎます。

そこで！サブプロジェクトを始めようじゃないか！、と。私が先輩に声をかけたわけです。まだ始めて2ヶ月程度しか経っていないのでこれといってサブプロジェクト自体の成果は上げられていませんが、サブプロジェクトを始めるまでの過程の中にいくつか良かったと思える行動があったことに気づきました。

今振り返ると、書籍『Fearless Change』に出てくるパターンに似ているのです。例えば、

• 小さな成功
  • 自分たちの取り込みからどんな小さいことでも学びを発見し、その学びを持って自分たちの活動は成功しているのだとお互いに称え合っています。決してプロダクトとして日の目を見ないと成功とは言えないわけではないと思っています。
• ステップバイステップ
  • 本当にたくさん試したいことはあるけれど、まずは1つだけ最も興味があるトピックを選んで取り組んでいます。これによって、自分たちは今何を検証しようとしてこの取り組みを行っているのかが明確になります。
• ふりかえりの時間
  • 活動した日は必ずふりかえりを行います。自分たちの取り込みによって何が学べて何が良かったのか、逆に何に困っているのかなどをつぶさに観察します。
• グループのアイデンティティ
  • サブプロジェクト開始直後にチームの名前を決めました。自分たちがこうして集まった理由となる「システム開発に対する熱意」をチーム名に込めたこと、またチーム名を決める一連の活動を通して、アイデンティティが形成されたと実感します。
• イノベーター
  • 私が会社の先輩に声をかけたのは先輩がこのイノベーターを担ってくれると期待したからです。
• 定期的な連絡
  • 先輩と私はプロジェクトを離れたあとも定期的に連絡を取り合い、技術的な関心事などについて話していました。
• 勉強会
  • もともとこのサブプロジェクトの前身として読書会を行っていました。

これ以外にも、私がプロジェクトのSlackで自分が興味あるトピックを発信し続けていたこと、工数に影響のない範囲で改善したり試したりできることは積極的に取り入れていたことなどが、サブプロジェクトを開始するにあたって良い影響を与えていたと思っています。

歴戦のカンファレンススタッフであるAckyさんとこばせさんの二人に、カンファレンススタッフのお仕事を聞いたり、そこでの二人のやりがいを聞くことを通じて、スクラムフェスというコミュニティに潜むコントリビュータ気質のスタッフがいきいきと働ける、良さについて言語化していきます。ここで言うコントリビュータ気質とは、貢献のためにたくさん手を動かす気質を指します。

なおカンファレンススタッフ業務に関しては、スライドを用意し解説をしますが、二人のやりがいや価値観については、ばやしがインタビュー形式で聞き出していきます。

こんにちは！初プロポーザルを書いていて緊張していますので、温かい目で見てください（笑）

このセッションでは、スクラムマスターのロールに関する"兼任"と"専任"にスポットライトを当てていこうと思います！

私は、過去に開発者ロールとの兼任でスクラムマスターをしていた時期がありました。
しかし、兼任スクラムマスター特有の「やりづらさ」を感じ、転職を経て現在は専任スクラムマスターとして活動しています。
その活動の中で、感じとことや気付き、兼任スクラムマスターだった時と比べ自身のスクラムマスターとしての振る舞いがどのように変わっていったか？結局、チームに何をもたらしたのか？を実例を交えお話しできたら良いと思っています。

以下、アウトラインです。

• 持続可能なチームになるようにスクラムマスターは何をするのか？
  • なぜ、スクラムマスターの兼任は推奨されていないのか？

• 兼任スクラムマスターの時に抱えていた問題
• 実例を用いた兼任スクラムマスターと専任スクラムマスターの違い
  
  • 兼任スクラムマスターだった時に予想される振る舞い
  • 専任スクラムマスターの時の振る舞い
• 兼任スクラムマスターと専任スクラムマスターの決定的な違い
• 結局、兼任でスクラムマスターはできるのか？

現在、専任のスクラムマスターに対して興味のある方、専任のスクラムマスターの導入を検討している方、兼任スクラムマスターとして戦っている方に対して、少しでも参考になれば幸いです。

オレ、シャークレ、トークショーを開催するサメ！

すぐさめLikeするシャー

スクラムガイドには「スクラムは『経験主義』と『リーン思考』に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する」と書かれています。

そしてもうひとつ、「何かを学ぶためには、自分で体験する以上にいい方法はない。」というアインシュタインの有名な言葉があります。

この２つからわかることは「経験するということはすなわち学ぶこと」そして「経験から学ぶことは最良の選択である」ということです。

なるほど、だったらもう経験して学ぶしかないじゃない！

ということでクリエーションラインの新人研修は「新入社員よ、全て体験して学ぶのだ！」というポリシーのもとスクラムチームを結成し、実際に社内で起きている課題を解決することにしました！

とはいえ、入社したばかりの新しい環境、初めてのメンバー、やったこともない「スクラム」で顧客の課題を実際に解決しながら学ぼうなんて一見強引にも見えますよね。しかし実際に1ヶ月がすぎる頃にはチームは明らかに成長していて、それは最後にやったふりかえりからもしっかりと感じられました。

もちろん1ヶ月体験すればだれでもうまくいくわけではありません。私は「価値を出すために自分たちの行動を変える」ことにチームがフォーカスし続けることができたからこのような成長があったと感じていますが、実際にはどのようなことが起こっていたのでしょうか。

本セッションでは新人研修期間としての約１ヶ月をどう進めたか、立場が違うメンバーが感じた苦労や工夫を織り交ぜながら、以上のことを紐解いてみたいと思います。

？？「ねぇ、このサービスのメンテナンスよろしく」
notch_man「ところで、そのサイトにアクセスすると500番エラーになるのですが？」

あなたはある日、1つのサービスの開発を託されました
そのサービスは既に大きな価値を生み出しているものの前任者からの引き継ぎもなく、コードは走り続け、よく壊れる物でした。

20XX年、プロダクト開発の現場は企業に留まらず大学などの研究機関、学生団体など多岐に及んでいます。継続的に競争力のあるプロダクトを作るには良いチームが良い価値を定義し良いコードを書くことが欠かせません。しかし、大学は人の入れ替わりが激しい組織です。良いチームとはという話は色々されていますが、入れ替わりの激しい組織ではそもそもチームが成熟することすら難しいのが現状です。

ところで、今年の3月で前任だった開発者が全員卒業してしまいました。4月から新たな開発チームで開発・運用を始めましたがソフトウェア開発の経験がほとんどない、立て続けに障害が発生する、ドキュメントが無いなど数々のトラブルに見舞われました。また、スキルや経験値も全てバラバラな状態で上手くコミュニケーションを取ることが出来ませんでした。前任者が居なくなって状況は深刻になり、インシデントや数々の障害が発生する事態になりました。

このような状況の中で、私たちは文字通り「スクラム」を組み、0から開発チームを立ち上げ持続的に成長する体制を作りました。そして、本番サーバーに繋ぐ事すらままならない状況から週に1回はデプロイをしサービスを継続的に改善できるようになりました。

このトークでは、大学の研究室という特殊な環境下で0から開発チームを構築し、継続的にインクリメントを生み出すために取り組んだ事についてお話します。現場では既に障害が多発しているなか、ゼロからチームを作っていくために多くの事をやりました。当時や技術や経験の差が多く、コミュニケーションが上手くいかないことも多々ありました。その課題を解決するために私は「技術力アップ」「様々な知見を知るきっかけ作り」「振り返りとナレッジ化」などの文化をチームに根付かせ、チームのレベルを底上げしました。その結果、私たちのチームは障害・インシデントを乗り越え、価値を生み出し、持続的に成長できるチームへと成長できました。

本トークではズレからこれらを克服するための気づきやヒントが得られるようなお話をします。私はこれまで様々な現場でエンジニア同士の技術力のギャップがあるなどの理由で上手くチームが機能しないというお話も聞いてきました。しかし、私たちは学生の組織であっても様々な観点においてより良い選択を取り続ければ、大きな課題を克服しチームは成長できることを示しました。さらに、学業や進路選びと並行しないといけない大学の研究室という特異な環境で、限られたコミットメントで最大の成果を出すためにやってきた開発の知見を紹介します。

大企業のSIerでシステムエンジニアをしています、Katsuyaです。

本セッションでは、"モブ部屋"というオンライン会議を導入することで

• リーダーやマネージャーからの反発をなるべく少なくモブワークを導入できる
• リスクを抑えてモブワークを実施できる
• 作業の透明性を高められる

という話をします！

このセッションによって、聴いてくださった方が各々のチームにペアプロ・モブプロやモブワークを導入したいと思ったときの足がかりになれるよう、精一杯お話します...!!

■セッション概要

SIerはいわゆる人月商売なので、いかに稼働率を上げて工数に見合った働きをするかというリソース効率が重要です。しかし、VUCAの時代と言われる現代で早期に価値を届けたり、後続の依存タスクのために滞りなく作業を進めるためには、いかに課題解決までのリードタイムを短くするかというフロー効率という観点も重要になってきます。フロー効率を上げるプラクティスにペアプロやモブプロ、派生してモブワークなどがあるので、これらを要所要所に積極的に取り入れることで、フロー効率を改善できます。

とはいえ、今まで工数ばかりを意識していた組織の中でいきなり「モブワークをしてフロー効率を高めましょう！」と言ったところで、あまり重要性が理解されずにやんわりと却下されて終わりです。

そこで、私のチームではモブワークをチームに導入する足がかりとして"モブ部屋"というものを取り入れました。部屋とは言うものの実体は日次のオンライン会議なんですが、これが結構良いプラクティスだったので、導入方法やTipsについて共有します！

導入のポイントは

1. 場を作ってしまうこと
2. 無駄な工数を減らす目的だと伝えること

です。

1.に関しては、プロジェクトではOutlookやTeamsを使用しているので、毎日30分モブワークをする会議を設定してしまいます。2.に関しては、「関係のある人だけ参加してもらって...」とか「手戻りを防ぐために最初に会話させてください」というふうに、工数を無駄にかけるわけではなくむしろ減らすことが目的だという前置きを必ずします。

こうしてモブ部屋を導入することで、モブワークに対する距離が近くになり、自然とモブワークの解像度が上がります。なかなか定量的にモブワークの効果を説明することは難しいですが、実体験としてモブワークの効果を経験すると次第に「分担作業をするだけが効率じゃなかったんだ...!!」と気づき始め、リソース効率に加えてフロー効率の観点で作業手順を考えられるようになります。