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

未経験からプログラマへのチャレンジ、メインフレーム用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です。
弊社のミッションは「世界の全てのスクラムをゾンビスクラムに」です。
我々はラスボスゾンビという素晴らしいリーダーを育成するコンサルティング業を生業としております。

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

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

本セッションでは、ふりかえり手法「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 を終え、これから事業を大きくしよう、売上を伸ばしていこう、というときに特に顕在化し、問題になります。
こんなとき、みんな「人手が足りない」「開発が回らない」と考えがちなのですが、その実、個人開発をやめれば人を増やさなくても開発は回るようになります。たいていの場合。

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

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

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

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

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

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

■セッション概要

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

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

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

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

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

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

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

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

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

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

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

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

エンジニア時代の私は自身の技術面の成長を優先するあまり肝心の「プロダクトの成長」にあまり関心を持っていませんでした。「何を作ればユーザーに価値を届けられるか?」ではなく「自分がいかに多くのPBIを潰し、いかに多くのコードを書く経験を積めるか」が重要だったのです。

そんな私がスクラムマスターにロールチェンジし、約１年間スクラムマスターとしての責任に向き合った結果、開発に対する考え方が当時の価値観から大きく変化している事にふと気づきました。

スクラムマスターはチームや組織を変革する存在であったはずが、無意識のうちに自分自身が大きく変革している事に気づいた瞬間でした。

本セッションは、スクラムマスターを"たったの"1年間やっただけで開発に対する価値観が180°変わるに至った経緯とその要因を深掘りする内容となっています。

これからスクラムマスターに挑戦しようか迷っている方の背中を押すようなセッションにできれば嬉しいです。

私はスタートアップが好きです。

一般にスタートアップではリソースに限りがあるので、関係者全員が目線を揃えリーンに取り組む必要があります。ビジネスが確立しておらず内部の仕組みが整っていないことがザラなため、常に不確実性やカオスと隣り合わせです。

そんなスタートアップという存在が、文化祭前夜のようなワクワクを演出し私を魅了するのです。

私自身も元々は開発者として、いくつかのスタートアップを経験してきました。
そこから様々なスタートアップに携わり、かつ視点を変えることができと考えベンチャーキャピタル(VC)に転職したのが3年前。

今では投資先支援チームの一員として、主に投資先スタートアップ企業を対象にスクラムを導入・運用を改善する業務に従事しています。

現職に来てから今日まで、濃淡はありますがDDを含めると100社以上のスタートアップの開発現場に関与しました。
支援に際しては、私自身が3ヶ月〜半年限定のアジャイルコーチとして現場に入ることもあります。

そんな私自身の経験の中で思ったのが、アジャイルコーチの能力を持つ方々にもっとスタートアップに参入してほしい、ということです。

リーンであり続けなければならないスタートアップに、アジャイルコーチの支援が必要だというのは意外でしょうか？
ですが、実際に支援でスタートアップに入っていくと、ちょっとした手助けで会社というチームがよくなることがたくさんあるのです。

そして私の場合、その視点はスタートアップで働いていた頃は持てていなかったな、と感じています。
つまり、アジャイルコーチの力が適しているのに、当人では気づきづらい何かがあるのです。

本セッションでは、以下のトピックを扱います。
まず、セッションの前提となる、会社や業務のバックグラウンドについて。
次にスタートアップの環境で、私がトライして上手くいったことやいかなかったことについて。
そして最後に皆さんがスタートアップでのアジャイルコーチを検討する際に見極めるべきポイントについてご紹介します。

セッションを通じて、みなさんにスタートアップで働くことの魅力をお伝えできればと考えています。

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

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

ソフトウェア開発のアジャイルプロジェクト自体は急速に増えてきました。そんな中、企業組織の中でアジャイルな活動がうまく根付かせ継続できていない、複数のアジャイルプロジェクトがうまく連携できていない、企業活動とアジャイルチームが噛み合っていない、アジャイルチームだけでなくそれを包含する組織自体も変わっていかなければいけない、そんな課題をお持ちではありませんか？

本セッションでは、企業組織やコミュニティ組織がどんな状態になってほしくてアジャイルをやっているんだろうか、という問いに対し、組織的にアジャイル導入を検討するリーダーのために、組織が幸せであるとはどういう状態かを言語化し、ゴールやそこに至るまでのギャップやアクションを整理・洗練させた「組織を幸せにする組織アジャイル5つの原則（略称：ソシアジャ五良核）」について概説します。その上で、各テーマについてディスカッションを通して理解を深めます。

１．同じ方向性を向いて働けている
２．お互いに協働できている
３．お互いに敬意を持っている
４．組織も個人も成長できている
５．ビジネスが持続的に回せている

組織的なアジャイル導入にこれから取り組みたい、複数のアジャイルチームを連携させたい、開発 以外の組織にアジャイル的なマインドを広げていきたい、等々で今まさに苦労している方々、ぜひ一緒に議論しませんか？

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

すぐさめLikeするシャー

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

コンサルみたいな働き方やアジャイルコーチとかをやっていると, "他のチームの事例を教えてください" と依頼いただくことがしばしばあるかと思います
その時皆さんはどのように伝えていますか？

人に何かを伝える時, "やってみせ" が結局一番伝わりやすいというのはあると思いますが, 秘密保持の観点などから情報にマスクをかけてドキュメントで伝えるしかできないようなことが多いのではないでしょうか

今の会社に入ってから２年弱, その "わずらわしさ" に何度もぶつかってきたぼくが抱いた思いは "自分のチームを持ちたい" でした

このセッションでは, わざわざ自分のチームで活動できる事業会社を辞めてまでベンダー企業に転職してきたぼくが, ここに来てどうしてこのような思いを抱くようになったのかについてお話したいと思います

"実際に活動しているチーム" こそ最強のリファレンスですよ