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

未経験からプログラマへのチャレンジ、メインフレーム用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.協働のメンタリティ

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

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

Abstract

ラスボスゾンビとは「ゾンビスクラムサバイバルガイド」に触発され、私が独自に定義した言葉です。
「チーム・組織をゾンビスクラムに陥れるリーダーやマネージャー」です。

スクラムフェス福岡にてお話しした「ゼロからスクラムを推進したスクラムマスターがラスボスゾンビEMになるまでの失敗と心の中」でラスボスゾンビのチェックリストを紹介いたところ、ご好評をいただきました。

このセッションは、ラスボスゾンビ株式会社（架空）が世の中にラスボスゾンビを普及するというストーリーに沿って、コミカルにラスボスゾンビにならないためのポイントをチェックリストに沿ってお話しします。

* ラスボスゾンビSMのチェックリストの項目の紹介
* それぞれの項目がなぜこのポイントがゾンビスクラムを招いてしまうのか
* どのような行動がゾンビスクラムに招いてしまうのか

ラスボスゾンビ株式会社からのメッセージ

こんにちは、世界の皆さん、私はラスボスゾンビ株式会社の代表取締役CEOのおーのAです。
弊社のミッションは「世界の全てのスクラムをゾンビスクラムに」です。
我々はラスボスゾンビという素晴らしいリーダーを育成するコンサルティング業を生業としております。

本日はお集まりの皆様に、特別にラスボスゾンビトレーニングを提供いたします。
弊社独自に開発したラスボスゾンビトレーニングにより、皆様を立派なラスボスゾンビへと育成したいと思います。
皆様と共に世界をゾンビスクラムの脅威に陥れていきましょう。

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

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

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

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

15年間働いていた会社を辞めて、2019年の5月から2022年の5月までの3年間、
C国の会社に入社し、ソフトエンジニア、PO/PMとして働いていました。
その中で経験した事や、気づきをお伝えします。

また自分の調査出来る範囲で、海外のスクラムやアジャイルに関する情報を
シェア出来たらと思っています。

海外に出てみると、日本での普通が、普通に思えなくなることがあります。
色々な価値や考えに触れることで、より選択肢の多い自分になっていった経験。

このセッションを通して、海外に出るのも良いかも、グローバルな気持ちになってもらえたら
嬉しいです。

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

本セッションでは、ふりかえり手法「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の魅力を更に掘り下げます！

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

私は社会に出てから20年近く、非アジャイル（いわゆるウォーターフォール的な）のシステム開発や運用保守の仕事をしてきましたが、縁あってアジャイル開発・スクラムと出会いました。現在は新規事業やスタートアップのPoC開発を行なうスクラムチームの開発者として多様な案件に取り組んでいます。

スクラムでは、プロダクトオーナー（PO）がプロダクトゴールの策定、プロダクトバックログの作成と優先順位付けなど、プロダクトの価値を最大化するための重要な役割を担っています。

しかし、開発者がPOから与えられたバックログをただ消化するだけのチームは、本来の価値を十分に発揮できません。全ての意思決定をPOに任せるのではなく、開発者がPOの判断を支援し、より効率的にプロジェクトを進めることが重要です。

私たちのチームでは1週間〜1ヶ月程度の期間内に仮説検証のフィードバックループを高速で回しています。そのため開発者は十分な品質を保ちつつ、半日〜1日でリリースできるような開発スピードを求められます。限られた時間内にプロダクトの価値を最大化するために、開発者はPOの意思決定を軽くする役割を果たすことが重要です。

• POの意思決定を軽くした一例

あるユーザーストーリーについて開発者で話し合い。
「技術的な難易度が〜〜〜」「ここつくると工数が〜〜〜」「実際にユーザーがこの機能をどのくらい使うの？」「もしこの機能がなかった場合にどの程度の価値が損なわれる？」などを議論。

その内容をPOに共有して、判断材料が十分に揃った状態でPOに意思決定してもらう。
開発者「・・・というわけでこの部分は別ストーリーにできると思うけど、どう？」
PO「OK、そうしましょう」
といった感じで、数分の会話でユーザーストーリーの一部を分割して優先度を下げることを決めた。

本セッションでは、私が過去に経験した非アジャイルな開発とアジャイルな開発を比較しつつ、POと開発者がどのようにコミュニケーションを取り問題解決に取り組んでいるかを共有します。そして、スクラムチームの開発者として私自身がどのように考えて行動しているかをお話しします。

このセッションが、POから信頼されチームに貢献できる"まじサーバント"な開発者になるための知識とスキル、マインドセットを身につけるヒントになれば幸いです。

スタートアップでの開発形態は、ウォーターフォールに依存しがちなJTCと違って、プロダクトバックログやカンバンぽいものを使ったアジャイル風の開発をしていることが多いです。
特にSaaSだとそもそもウォーターフォールがそぐわないので、自然とそういう形態になりがちです。

しかし一方で、そういったスタートアップにはプロダクトバックログはあっても、たいていPBIの1つ1つがやたらでっかくて、1つ1つにしっかり担当者がアサインされてて、何ならデッドラインまで記されています。

これを引き起こすのは、スタートアップ特有の個人分担制です。
多くのスタートアップ企業はたいてい、エンジニア1〜2名からスタートし、個々のエンジニアの馬力で開発をこなしていくところから始まります。このときのバリバリ個人開発なノリが、エンジニアが増えても継続してガチガチの個人分担制に移行しがちです。 

しかし、個人開発の延長で大きくなったスタートアップはそのうち大きな壁にぶち当たります。

• 特定のエンジニアに負荷が集中する
• 開発のリードタイムが異様に長くなってしまう
• etc.

それは、事業がいわゆる Product Market Fit を終え、これから事業を大きくしよう、売上を伸ばしていこう、というときに特に顕在化し、問題になります。
こんなとき、みんな「人手が足りない」「開発が回らない」と考えがちなのですが、その実、個人開発をやめれば人を増やさなくても開発は回るようになります。たいていの場合。

こんなチームを救うのは、協働です。協働を意識したチーム開発への移行がこの危機を救うのです。

このセッションでは、個人開発をこじらせたスタートアップ企業がどうやって個人開発からスクラム流のチーム開発に移行すればいいのか、を、実際そういった傾向を持った複数のスタートアップ企業にアジャイルコーチ／スクラムマスターとして関わった経験を元にお話しようと思います。

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

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

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

※ AndroidはGoogle LLCの商標です。

なぜ今バスケ？

仙台の皆さんこんにちは！8/25、いよいよ2回目のスクラムフェス仙台が始まりますね！

でも今回の目玉はそれだけなんでしょうか…？
いえ、他にもあるんです！何を隠そう…

FIBAバスケットボール・ワールドカップ2023も8/25に開幕するんです！！

今回はフィリピン、インドネシア、そして日本の3カ国で史上初の共催です。
日本はグループステージで

• ドイツ（世界11位）
• フィンランド（世界24位）
• オーストラリア（世界3位）
• 日本（世界36位）

というグループEに所属し、「死の組」とも言われています。
しかし！日本代表のAKATSUKI FIVEは18年にはオーストラリアに、19年にはドイツに勝利した経験もあり、その時も試合に出ていた八村塁が今回も出場してくれるはずです！

今年のバスケといえばスラムダンクの映画が盛り上がりもしましたが、歴代最強とも言えるAKATSUKI FIVEを応援しもうひと盛り上がりしようではありませんか！！

えっ？なんでそんな話をスクラムフェス仙台でするのかって？
そんなの、バスケがアジャイルなスポーツだからに決まってるじゃないですか！
ラグビーがアジャイルなスポーツという話もありますが、バスケも負けないくらいとてもアジャイルなスポーツなんです！

本セッションでは会社も住んでる地域も応援するチームも違うけれどバスケが好きという強い絆で結ばれた二人が、

• バスケを知らない人でも
  • 8/25から始まるバスケワールドカップを存分に楽しめ
  • ワールドカップ終了後も継続的にバスケットボールを応援したくなる
• バスケを知ってる人は今まで気づかなかったアジャイルな魅力に気づきより楽しめるようになる

ような、バスケのアジャイルな魅力をお届けします！

我々が考えるバスケのアジャイルな魅力

• 5vs5のスモールチームで戦うスポーツであり、交代も自由であるためチーム全体アプローチで総合力を発揮することが重要です。
• 10分クォーターや24秒以内にシュートを打たなければいけないなど、試合中様々な長さのタイムボックスがあります。
• クォーター間の休憩やタイムアウトで検査と適応を重ねながら戦います。
• 試合相手や試合状況に応じて様々な戦術(プラクティス、カタ)を柔軟に選択し、170cm未満の選手が200cm超の選手を相手する瞬間も生まれます。
• 試合数が多く、連戦が基本なので出場時間をシェアしながらシーズンを戦い抜く持続可能性が重要です。

ワールドカップが終わったらどうなる？

ご安心ください、各地にチームがあります。
スクラムフェス・RSGTが開催されている札幌、仙台、新潟、東京、三河、大阪、福岡、沖縄のなんと全てにBリーグ所属のバスケットチームがあるんです！
ワールドカップは9/10まで開催されますが、そこから数週間後の9月末〜10月頭には2023-24シーズンが開幕します。
すぐそこまで迫った新シーズンに向けて、スクフェス・RSGT開催地のチームをご紹介します！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私たちは無限の可能性がある価値あるプロダクトを作るためにこれまで学んできた！
私たちはこう習った、道具もある、よしっ！これで行くぞ！！
（と、威勢の良かったチームが1ヶ月後にアマゾンの奥地に迷い込み連絡が途絶えた...）

現代のソフトウェア開発は荒れ地を整え、価値のある建物を作り、継続的に繁栄するように外敵から身を守る・手入れをしなければならないです。そのため、とても難しい問題になっています。そのために、新規のソフトウェア開発は様々なステークホルダーの様々な想いを整理し、ゴールを定め、バックログを組み立てる必要があります。ただ、そもそも要望が曖昧だったりゴールが変わったりバックログは捻じ曲げられる事が多々あるでしょう。私たちのような新米開発者も、このような荒れ放題の要求から本質を見定めて価値のあるサービスを作ることが求められます。

ここで朗報、私たちはベテランから荒れ地を整えるための道具や知恵を多く教わってたばかりです。これを上手く使えば、どんな荒野でも怖くない！しかし、実際に現場に向かうとたくさんの知らなかったことに出くわします。そもそも、チーム内でも学んだ事に対する理解が異なっていることもあります。例えば「チームビルディングをやりましょう！」と聞くと、各々自分が学んだときに使った唯一無二の方法を持ち出してくるでしょう。そうして、チームビルディングも出来ていたはずなのに、ストレートに意見が言えない、認識の差違などが生じます。

私たちは5月からとあるハッカソンに参加するためにチームを結成しました。メンバーは実務経験や大学で開発経験を多く身につけてきた人たちでした。しかし、いざチームとして走り出すと「音信不通になった」「お腹が壊れて動けない」「絶起しました」という些細なことがきっかけに全体のでコミュニケーションが上手くいかなくなりました。そして、提出ギリギリまでアイデアがまとまらず右往左往する状態に。数々のアイデア発想フレームワークを学び、多くのアンチパターンを経験してきた私たちが何故このような状態になったのか？私たちは何も分かりませんでした。

本セッションでは、これまで異なる環境でソフトウェア開発について学んだ筑波大と東京理科大との合同チームが「荒野を頑張って整地しサービスの起案ができる」チームになるまでの軌跡とそこから得られた「新たな旅人」へ道しるべとなる知見をお話します。教科書をなぞれば上手くワークした環境から、自分たちの足で立ったときに直面した「チーム間のコミュニケーション」「お互いの前提知識・認識」の違いを克服するために試みたことについて紹介します。また、これから自分の足で前に進む事になる新人の方の生存戦略を考えるきっかけになったり、シニア層の研修プログラムの設計だったりコミュニケーションなどに活かせるお話をします。

弟くん(仮名)は、身寄りのない保護猫です。
三重県のさる民家の木屋で生まれ、祖母猫・母猫ほか三兄弟と保護されました。他の家族みんなで保護された際に、夜に嵐となり1匹だけ取り残され、にもかかわらず翌日無事保護された強運の持ち主です。昨年(2022年)10月家に来たとき、まだ５ヶ月、子猫でした。

当時、わが家には、すでにおねえさん(仮名；10歳)妹ちゃん(仮名；当時5歳)の猫たちがいました。いずれも保護猫です。
おねえさんはそろそろシニアです。気力・体力的にもこれ以上年齢を重ねると子猫を迎えるのは難しいだろうなと思っていました。妹ちゃんは、保護した当時、1匹で現れ、母猫に育てられた形跡がうかがえない不思議な子です。子猫でしかも男の子が加入した際、どんな反応をするか想像もつかない状況でした。

ところで。
子猫を迎える際、ゲージを準備します。ゲージは安心安全を確保するためのものです。いきなり環境が変わり、見知らぬ人だけでなく見知らぬ猫たちがいる中、ただひとり放り込まれる訳ですから、隠れ家（アジール）なものがどうしても必要です。
一方で、ゲージには文字どおり檻の機能もあります。本猫の意志に関係なく、閉じ込めることもでき、隔離することもできます。
猫も動物である以上、それぞれの性格があり、どうしても相性が出てきてきます。時には派手な喧嘩をすることもありえ、相性が悪くて喧嘩が絶えないことも、一方がストレスを抱えるあまり病気になってしまうこともあります。また、人が手が離せない時や寝ている時に問題行動を防止するためにも使うこともあります。
閉じ込めること・隔離が必要な場合がどうしてもありえるのです。

閉じ込める。
今回、弟くんを迎えるにあたって、何とも もやもやしたこと は、そのことでした。
閉じ込めることだけは絶対したくない、とはいえ、男の子で子猫、やんちゃで食いしん坊、激しく動き回る。そもそもお互いがお互いを知らない、そのこと自体も恐怖。子猫といっても1歳で成猫になりすぐおっさん猫になる。体力の差はどうしてもでてくる。また、自分たち夫婦が外出したり寝ているとき手が離せないとき、もし3匹の身に何か起こったらどうしよう。やっぱりその期間だけでも閉じ込めることは必要悪なのではないか。

正直悩みました。悩みに悩みました。
悩みに悩んだ結果、わからないことはわからない。わからないことをわかるようになるところから、みんにゃで実験し検証していくほかなかろうと、思い至りました。
つまり、当初は完全に閉じ込めることがあっても、時間を区切って閉じ込め、段階的に閉じ込める時間を減らしていく、そんなふうに進められたらと考えたわけです。

具体的には以下です。
最初は隔離し、匂いの交流から始め、姿をほのかに見せるだけにし、お互い興味を持たせます。ゲージにいる弟くんを姉妹を抱っこして見せることから始め、そこから徐々に交流する時間を増やし、お互いがどんな行動をしているか家族皆で確認していきます。毎日、twitterで保護主さんはじめ保護猫活動をやっていらっしゃる方々と共有・ふりかえりをし、次の日のアクションを決める。
透明性、検査、適応、スクラムの三本柱を忠実に実行し、家族全員で実験を繰り返す。このこはこんな行動をするけど、こんなことはまずしないだろう、お互い信頼貯金を少しずつためていく。

もちろん全く問題がなかったわけではありません。
ここでは３つ取り上げて話したいとおもっています。おねえさん・妹ちゃんのご飯を割って入ってむしゃむしゃ食べる、壁をバリバリ、NotePCにのってキーを連打の３つです。とくに困ったのは キーボード連打でした。
いずれも、何が起こったか(行動)、わたしたちだけでなく猫さんたちからみた困りゴト、根本原因の３つに分解して、とくに、困りゴトに着目して工夫を行いました。導き出した工夫は、食べる時間を分ける、椅子を用意する、お盆を用意して NotePCのキーボードにのせるの３つです。
いずれもよく観てよく聴いて試してみてやってみました。よその事例をそのままもってくるのではなく、切実な思いで実際にやって導き出しました（なので、おそらく、皆さんのお家でそのまま適用できないかとおもいます）
が、工夫を導き出す「考え方」は参考になるかと、自分はおもっています。

そして、今ふりかえって、ここでのまなびは何だろうかと考えました。
まず、スクラムの理論には、３本柱：透明性・検査・適合の実現がありますよね。
透明性はわかりやすいですよね、できるだけ情報公開していこうという話なのかなと。
一方、検査と適合とは一体何でしょうか。
とくに適合とは・・適合というからには、何かに適合していくですよね、では何と適合していくのでしょうか。

わたしはこう考えています、
一つは現実との適合です。今ここで起こっている現実を受け入れみつめる必要があります。ただ、単にこれだけだと「できませんでした」で終わったしまいますよね。いわゆる現実への迎合です。
と考えると、もう一つ、本当の願いへの適合があるのではないでしょうか。
ただ、現実は日々流転するものであり、本当の願いはなかなか出てくるものではありません。
そのために、今ここで起こっていること、本当の願いって何だろうという検査をする必要が出てくるのだろうと。
今ここで起こっていること・見方は、人により解釈の枠組が異なる以上どうしても異なってきますし、本当の願いは弱々しいものになりがちです。
その解釈の枠組を乗り越え弱々しい声ならぬ声を拾うために、透明性が必要になってくるのではないでしょうか。

今、わたしたちの身の上で、誰かを閉じ込めることがなにかおこっていないでしょうか。
わたしはマネジャーという役割をになってきました。34歳からなのでかれこれもう20数年以上たってしまいました。
人と人が協働して価値あることをなす以上、何かしらの分担が必要、継続していく以上わたしという以外の役割ラベルが必要となってくる。また再現性上、そのラベルは何かしらの拠り所が必要になってくる、つまり拠り所はマネジャーにとっての一つのアジールなわけです。

思いおこすと、マネジャーが、単なるラベルであり、単なるアジールであり、で機能してきた場合は、うまくいってきました。
一方で、単なるアジールや単なるラベルが「檻」に変貌したとき、どうしてもうまくいきませんでした。それは、たまたま他所でうまく行ってきた「方策」がそのまま「正義」になって展開されてきたとき、MTGのときの「アジェンダ」が「戦略」となっているとき、なにより場をなんとか制御したいと願ったとき、それは「檻」となっていました。つらかったし、何よりも楽しくなかった。

今回、弟君をむかえて、いろいろな可能性があり、適用しうる方策もさまざまありました。よく聴きよく診て一緒に行動してきた。
その中でとってきた方策は、最初ぼんやりと思い浮かべていた方策とはまるで違ってきたものだったのです。楽しかったし、それは自分にとって大きな「発見」でした。

このセッションでは、つい「檻」に閉じこもりがちで、弱気で、言葉がでてくるのがとても遅い おっさんと、皆さんと一緒に「檻」から外にでていけたらという話をしたいと願っています。
どうかよろしくお願いします (_ _)

私たちのチームでは、有志が集まって自分たちのコードを一緒にわいわい読む活動をしています。ここでは、この活動を「モブコードリーディング」と呼ぶことにします。この活動は、コンポーネントチームからフィーチャーチームへの移行を支援するためにはじめたものです。

私たちは、4つのコンポーネントチームでNexusをベースとしたスクラムを導入し、1つの自社サービスを開発していました。開発を続けるうちにビジネス状況によりすばやく対応する必要性が高まり、私たちはフィーチャーチームへの移行を目指すことにしました。この移行に際しては、チームの構成を維持したまま、これまで担当外だったコンポーネントの開発を徐々に手掛け、各チームが開発できる範囲を拡大するアプローチを選びました。この状況の中で、普段の開発による学び以外でも自分たちのコードについて理解を深める機会があるとフィーチャーチーム化が加速するだろうと考え、モブコードリーディングを企画しました。

私たちのモブコードリーディングでは、特定の「お題」を設定し、そのお題に沿ってコードを読み解きます。参加者は各自でエディタを開く、もしくはVSCodeのLiveShare機能を利用して、その場でコードを読みながら動作や疑問について話し、理解を共有し進めていきます。モブコードリーディングにより、コードの理解が深まり、リファインメントやトラブル対応で効果的な議論ができる人が増え、また暗黙知なども共有されました。

このセッションでは、私たちがモブコードリーディングをはじめた背景と目的、そしてどのように実践し、その効果をどのように感じたのかについてお話します。

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

• ビジネスやチームへの期待、メンバーのキャリア、ライフステージなど、チームの環境や状況は良くも悪くも変化し続ける
• 大事なことは、変化をコントロールしようとするのではなく、チームが変化に適用して価値提供を続けられること
• そのためにはスキルやプラクティスの前にチームのマインドセットが醸成されていることが肝要

---

僕たちはチームの立ち上げから1年でチームの形が6回も変えました。1チームスクラムから始まり、3チームスクラム、2チームスクラム、2チームスクラム+1チーム、2チームLeSS+1チームスクラム、3チームLeSS、そして今は2チームLeSSの体制です。メンバーの増減も頻繁なので毎月変化がありました。ビジネスの変化は対応するため、期待に応えるため、はたまた自分たちの挑戦のため、個人のキャリアのため、そのときどきの状況に応じて適切だろう体制を選択し続けてきました。

こんなにチームをいじりつづければ、チームはてんやわんや。成果も出ず、スクラムは破綻し、チームは空中分解…みたいになると思いませんか？

しかし、僕たちはちゃんと機能しているチームしてるんです！チームの形は安定させていないけど、安定した価値提供と成長を続け、社内で参考にされるプロダクトチームに成り上がりました！

なぜこんなことができたのか。それはマインドセットに力を入れてきたからです。アジャイルマニフェスト、スクラムやXPの価値基準、モダンアジャイル、テスティングマニフェスト、HRT、LeSSの原則…。そんなマインドセットをチームで理解し、それをベースにプラクティスに取り組んでいるから、形に拘らず変化に適応できるチームになれました。

このセッションでは

• なぜマインドセットが大切なのか
• 僕たちが大事にしているマインドセット
• どうやってマインドセットを当たり前にするのか
• 何を考えてチームの形を変化させてきたのか

などを共有します。変化に強いチームをつくる参考になれば嬉しいです。

ぜひ、チーム自慢させてください！